On Tue, Feb 12, 2013 at 5:00 PM, ianG <[email protected]> wrote: > On 12/02/13 04:49 AM, Kevin W. Wall wrote: > > <snip>
> > 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. >> > > > Well, that all depends on their business models and their security models. True, that. And I think their business model was vendor lock-in. Fair enough. > Two points: > > 1. There is no absolute security, and all that nonsense in the past about > air-gapping and HSMs and triply redundant secret sharing with Adi sauce was > based on a models ineptly stolen from the NSA and similar spooks. All > models are unique to their owners, and it is high time we started > recognising that "best practices" means "I don't know what to do." > In reality, the whole point of claiming to follow "best practices" is to limit your potential liability in case you get your ass sued. Generally it is a good defense against claims of negligence, so in effect it is a CYA policy, especially when applied without thought and context. > 2. And, somewhat related, these models borrowed from the military/spook > lore of the 1990s are now challenged by 2 decades of Internet experience, > which was mostly peace until 2011, and is now mostly war. > > Having heard the story of the RSA SecurID breach first hand, had they kept their original "air gap", they likely would not have been as fully compromised as the were. Instead, they chose to trade convenience for security. That may be the right trade-off under certain circumstances, but in the case of RSA it cost them between $320 to $680 million (depending on whose figures you believe) to, er, atone, for the breach. In the end, the RSA told us that their air gap is back in place like it originally was. Note that no one claims that makes it _impossible_ to hack in and steal the SecurID seeds, but it likely increases the difficulty. > > > 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.) >> > > People sell stuff that people want. It is beyond arguable that nobody in > commercial or business life wants to secure an own key pair and use it to > conduct various voodoo ceremonies in the moonlight with assembled monks and > others in white pointy hats. > Shit. I thought the pointy hats were supposed to be _green_. My bad. Maybe I can sell it to a Leprechaun / Witch cross-dresser. > What customers want is compliance and cost. If Bit9 can manage all the > certs from the HQ, this sounds fine. (until it doesn't, in which case > we're all agreed it is another selling opportunity :) > > Depending on how well the PR department can spin it. Kind of like the time that Microsoft had a string of remotely exploitable vulnerabilities and rather than owning up to it, instead they pointed to their wonderful Windows Update service and claimed how successful their patching was. Patches that shouldn't have been necessary in the first place. Pay no attention to the man behind the curtain. > > 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. >> > > Are you sure about that? > > Well, sure, some companies will do anything. But I also know of companies who refuse to use Veracode for SAST because you have to upload your source code so that their analysts can see it. If Bit9 signed some contract saying they would take responsibility for any of your company's source code being disclosed as a result of a breach in Bit9's servers, then perhaps that would convince a few more. But Veracode wouldn't sign anything like that and I doubt that Bit9 would either. Have you seen the debates going on over at Mozo central about the subCAs? > Enough to cool the stock price of many a CA ... You mean this?: < http://groups.google.com/group/mozilla.dev.security.policy/tree/browse_frm/month/2011-11/b1b7aec522583ffc?rnum=81&_done=/group/mozilla.dev.security.policy/browse_frm/month/2011-11?&pli=1 > I haven't; is it worth reading? | Then Bit9 would not have been a target to start with. > Ah, but then the customer would be a target. Now, what is the business > model approach here were you protect the supplier and put the customer at > risk? > > Well, that all sounds fine in theory, but until a software vendor is actually willing to put into their license or some other legally binding contract that *they* are willing to accept liability for any breaches resulting in your companies loss of data, it's all just talk. And I've not seen a single software vendor willing to do that. In reality, I don't think that this points any specific customer anymore at risk than they already are and it arguably would have reduced risk to Bit9 by making them a less enticing target. -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 Borenstein
_______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
