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.