While it's possible that their product might have protected them, that angle is merely self-promotional spin. The real reason that this happened is because Bit9 didn't properly secure their assets in the first place. It shouldn't matter if "a malicious third party was able to illegally gain temporary access." A perimeter defense can be a useful deterrent, but you should still keep your jewels in a safe.
Like an HSM? I would have expected that any security company would be using those to store private keys, in which case "we should have used our own software" doesn't make much sense.
Reminds me of the RSA response to their extreme compromise. Even quite some time after the incident the EVP & Chairman, Art Coviello, only would state how close "on the tail" they were to the perpetrator(s) thanks to their technology & skill. They're still a viable security organization, so apparently the market was easily able to disregard the core issues.
This is a pretty transparent attempt by a PR team to try to spin this into something positive by saying "it was operations fault! if only we installed our own product!"
The fact is that Bit9's product wouldn't have prevented the type of attack they were hit by.
While I agree that it's an awful PR spin, it's actually likely that the product would have stopped the attack. I don't know any of the details, but usually these sorts of things are a result of an APT. At the very least, it's likely that some executable was written to disk. In that case, Bit9's product would have prevented the attack.
If it were an active hacker that didn't rely on writing an executable to disk for privilege escalation, then all bets are off.
This seems to confirm the hypothesis that Bit9 does not store the private keys it uses to sign executables on an HSM. If it's appropriate, can you describe the system that stores those keys? Is it somebody's desktop? Is it in a secure area? How many people have access to it? What other software is installed on it? Is it connected to a network?
Perhaps this is a trivial point, but bragging about all their controls and audits and whatnot while reporting this sort of failure seems to call into question the value of all those controls and audits and whatnot. If any procedure in that company should be audited until it's airtight, then the process of securely generating, storing, and using keys should be. I doubt a more in-depth analysis will be forthcoming, but it would be nice to find out not only why they're not doing their main thing in the proper fashion but also why it took an actual breach to find that out.
14 comments
[ 3.1 ms ] story [ 42.1 ms ] thread(https://blog.bit9.com/2013/02/08/bit9-and-our-customers-secu...)
The fact is that Bit9's product wouldn't have prevented the type of attack they were hit by.
While I agree that it's an awful PR spin, it's actually likely that the product would have stopped the attack. I don't know any of the details, but usually these sorts of things are a result of an APT. At the very least, it's likely that some executable was written to disk. In that case, Bit9's product would have prevented the attack.
If it were an active hacker that didn't rely on writing an executable to disk for privilege escalation, then all bets are off.
Gosh, can we please stop copying The Register's randomly-capitalized words in the title? This isn't reddit.