Bit9 Security Breach – Lessons Learnt

News broke on Friday evening that the security vendor BIT9 suffered a security breach. BIT9 offers a solution to clients whereby they will whitelist applications to run the PCs of their clients. This is done by digitally signing each approved application to allow it run on the protected computer. The theory behind this method is that only the whitelisted software will run on the PC. If an attacker tries to infect the computer with malware they will not succeed as it will not be on the authorised list of applications and therefore not run.

Brian Krebs broke the news that somehow attackers broke into the BIT9 network and then used BIT9’s own digital certificates to sign and push malware out onto the networks of some of BIT9’s customers. So far there is no indication as to how BIT9’s customers who were attacked detected the intrusion. It would be highly ironic if the malware was detected by anti-virus software, particularly so given this blog post “It’s the Same Old Song: Antivirus Can’t Stop Advanced Threats”.

From BIT9’s own blog post on the incident they sat “Due to an operational oversight within Bit9, we failed to install our own product on a handful of computers within our network. As a result, a malicious third party was able to illegally gain temporary access to one of our digital code-signing certificates that they then used to illegitimately sign malware”. While it would be very ironic if it was anti-virus software that detected the malware sent by BIT9, this incident is a classic example of why relying on one technology to protect your network can be so risky.

Should that technology fail then your whole security can be undermined.  This is commonly referred to a “brittle security”, a term coined by Bruce Schneier. It also highlights a phrase I have used with my clients when highlighting the trust they place with staff, partners or vendors; “those you trust the most are the ones that can end up hurting you the most”

The Bit9 breach is a classic illustration of those two statements in action. Bit9’s security was breached because of an “operational oversight” they did not manage to use their own product on all of their systems. It also shows how attackers are now using the supply chain of high value targets to attempt to breach their networks. I have no doubt that this attack, similar to other attacks such as the one against RSA in 2011, was done to leverage the trust Bit9’s customers placed in the Bit9 solution.

The lessons we should learn from this are;

  1. No software, including security software, is 100% secure (as per this old blog post). Regularly review your security software to ensure it is up to date.
  2. A layered defense, as outlined in this whitepaper I wrote for Tripwire, will help reduce the impact of a security layer failing.
  3. Ensure your security infrastructure is not reliant solely on software. Remember People, Process and Technology are the three pillars to a secure environment.
  4. Develop a patch management process that should be specific to your security software. Remember this is the software you depend on to protect your information, networks and systems so you will need to treat it differently from the accounting package deployed within your company.
  5. When selecting a product do not be afraid to question the vendor on how they manage vulnerabilities, patches and updates for their products. Also ask them how they will alert you, their customer, to security issues with their software.
  6. Your security assurances need to extend beyond your own perimeter and include your suppliers, partners and any other organisations with access to your data and/or systems that you trust and rely on.
  7. There is no such thing as 100% security. Someone or something and some particular point in time will fail and provide a potential exposure, so plan accordingly.

UPDATE 11th February

SC Magazine have covered this story with quotes from this blog post.

Likewise The Register has quoted this post in their coverage of the breach.

DarkReading interviewed me and included this post in their coverage of the breach.

UPDATE 12th February

Eric Schurr from Bit9 has commented below on the blog post to clarify how Bit9 works. My apologies if I caused any confusion in my own explanations.

3 thoughts on “Bit9 Security Breach – Lessons Learnt

  1. We read your post about the Bit9 security incident, and in the interest of accuracy we wanted to explain more clearly how the product works and why readers might get the wrong impression from your post.

    Here’s an excerpt from the post, with some key text highlighted:

    “BIT9 offers a solution to clients whereby they will whitelist applications to run the PCs of their clients. This is done by digitally signing each approved application to allow it run on the protected computer. The theory behind this method is that only the whitelisted software will run on the PC. If an attacker tries to infect the computer with malware they will not succeed as it will not be on the authorised list of applications and therefore not run.”

    The main thing to understand is that our trust-based model is policy-driven. It’s not actually a list of files; it’s a set of policies. Each customer determines their own policies.

    With that understanding, here are some clarifying points:

    1. We don’t determine the trust policies for a customer. Each customer determines the policies that define what software is “trusted” in their organization. We give them a starting set of policies and help them if they want, but they ultimately determine what they trust.
    2. We don’t “whitelist applications” for customers. We determine “trust ratings” for apps, and the customer decides if they want to use those ratings when building their set of policies that determine what they trust. This is totally optional.
    3. We don’t digitally sign applications (other than our own). Digital signing is relevant when a customer wants to trust a specific software publisher (e.g., Microsoft, Oracle). The signing is done by the publisher of the software, not Bit9. At Bit9 we digitally sign our own software so it is automatically “trusted” by itself and allowed to run.

    For further details, please see the “Trust Methods” tab of this page on our website https://www.bit9.com/products/trust-based-security-platform/trust-based-application-control/.

    We hope this clarifies any possible misconceptions.

    Thanks,
    Eric Schurr
    CMO
    Bit9

    • Hi Eric

      Many thanks for taking time to clarify the whay Bit9 works and apologies for any confusion caused on my part.

      Will Bit9 be providing more details in time of the breach and how the attackers managed to get into your network? I ask simply to see if there are lessons that many of us can learn from the incident so we can all better protect our systems, data and intellectual property.

      Brian

  2. I am always upset to see that production software are signed without the supervision of a human trusted operator. The actual volume of software going out in the field as product should be low enough to allow such supervision without going through an automatic process.
    Of course, for development, it may be useful to have an automatic signature through a server. but the development signature key should use a root key different from the production root key. this would provide proper isolation and avoid potential contamination.
    Only verified, human approved, production software would go in the field.

Comments are closed.