If you need a one off example this week of why internal policies are important, or why failure to adhere to them could spell trouble, look no further than Bit9. According to the application whitelisting company, it was their failure to follow organizational deployment mandates, which led to one of their code-signing certificates being hijacked by an attacker.
Many know Bit9 for their claims to have prevented notable headline-grabbing attacks, such as Flame and Gauss, due largely to their software’s ability to prevent unknown software from executing within an environment. In short, they offer whitelisting, if the code is unknown or isn’t approved – it won’t run.
In their mea culpa, Bit9 clearly outlined the cause and effect of their recent security problems. Once the sugar coating is removed, Bit9 admitted that failure to follow internal policy led to three customers being infected by malicious code flagged as legitimate by their product.
“…We simply did not follow the best practices we recommend to our customers by making certain our product was on all physical and virtual machines within Bit9…”
Temporary is a misnomer, since the bottom line is the attackers had control over the certificate – the length of time in this instance is irrelevant. The code signing process is the key element to Bit9’s entire operation. Even if the certificates were compromised for a few hours – that is a few hours too long.
The blog post doesn’t explain why the signing keys were seemingly on the production network, rather than an isolated one. In any event, once the keys were accessed, the attackers had the ability to sign their malicious code deliver it to the three customers.
While Bit9’s blog post attempts to shift focus, away from their faults and into the realm of APTs and “sophisticated” attacks, there is too much missing from the bigger picture to assume anything. This could have been a targeted attack, or a botmaster who got lucky after a log day of automated scanning and exploiting.
When it comes to their mitigation, Bit9 would only outline the steps that security professionals were expecting:
The compromised certificate was revoked; Bit9 will push a product patch to prevent the compromised cert from being used on any signed code; and they have been monitoring their internal data for signs of other attacks using the compromised certificate.
The rest of the blog post is unfortunately little more than marketing fluff. After all, in the aftermath of a compromise such as this, most security professionals don’t need to know that the breached company operates “a complete security stack and a security operations center with a full-time staff monitoring all activity.” Clearly this wasn’t the case at the time.
Bit9’s mea culpa missed a major opportunity. Instead of talking about their security stack, or how their software wasn’t exploited, they could have addressed how policy enforcement is a major link in the security chain. Enforcement is just as important as development, and when the chain breaks, breaches such as this are a likely outcome. The fact that their own product wasn’t deployed first and foremost is a severe break in policy, and something that deserved more than a sentence on a blog.
They also missed a chance to address the need for layered security. Given the fact that they detected the policy failure and certificate compromise themselves, they have layers in place to compensate for policy oversight – which limited the damage done in this case. That’s another hot topic issue, and one that is worth discussing.
A tip of the hat should go to investigative journalist Brian Krebs, who by all accounts seems to have pushed this story towards the light. An hour after he emailed Bit9 with questions about the incident (his source was one of their customers), the company published their account for the public record.