[Full-disclosure: I am not a Bit9 customer; I just get their spam^H^H^H^H, er, informative product emails, thanks to a colleague who signed me up for their mailing list.]
Security company, Bit9, has been hacked and have had their private code-signing keys for their flagship software stolen. This was discovered only after Bit9 had received reports from its customers who were using their whitelisting-application software that malware had been installed on their Bit9-protected networks. Bit9's explanation is here: https://blog.bit9.com/2013/02/08/bit9-and-our-customers-security/ They claim they got hacked because they weren't running their own software...a bit embarrassing to say the least. In addition to using their own software, you would have thought that they at least would have air-gapped their code-signing private key, or at a minimum, secured the private key with a strong passphrase. What no one seems to be questioning in the first place is why Bit9 had a *central* code-signing key used to white-list all the applications in the first place. That pretty much set them up to be a primary target. I don't know anything about the _details_ of how Bit9's software works, but I am aware of how Tripwire works. With Tripwire, each company generates their own key pair and then use it. The private key is generally kept offline whenever possible. (For home use, I stored mine on a dedicated flash drive.) What I am trying to still figure out is what the Bit9 security model was. Certainly they would not have had the customers upload their entire _proprietary_ executables, DLLs, etc. only to have Bit9 sign their software as most sane companies would simply not stand for that and for third party software, it might even imply licensing violations. So it's doubtful that was Bit9's approach. Perhaps they just upload file information such as the full path name, permissions, ownership, etc. along with a SHA1 or SHA256 hash of the code and send that to Bit9 for signing. (Presumably Bit9 would return the result and cache it and validate it locally with their public key rather than having to validate remote signatures, but who knows?) However, I think that a centralized signing private key that would only make sense if what Bit9 was really offering were some subscription-like service, without which their software would be useless. (That is, the true Bit9 goal being vendor lock-in, similar to what you get with AV subscriptions.) I guess that's one business model and has some advantages (such has not requiring an initial scan of all the OS files, etc.), but creating Fort Knox and stashing all your gold there is not really secure unless you truly build a fortress. For software, we rarely can achieve that (especially for something on this grand of a scale) and developers should realize that convenience usually trumps security when it comes to business as usual operations. Personally, I think it would have made for a better security model if all of Bit9's customers generated their own code-signing certificate. Then Bit9 would not have been a target to start with. This is not the first time that private keys have been stolen and it is likely to not be the last. So the best way to avoid this sort of thing is not to hold the keys to the kingdom and then you won't become such a huge target to begin with. Sure, Bit9 probably still needed to sign their own software and distribute a certificate and along with self-validating code to their own software, but beyond that, it seems to me to take more sense to take the approach that Tripwire took. So am I totally off base here in thinking that Bit9 would have better off requiring that their customers generate their own key pairs? If so, I'd like to know why. Thanks, -kevin -- Blog: http://off-the-wall-security.blogspot.com/ "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We *cause* accidents." -- Nathaniel Borenstei
_______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
