On 13/02/13 05:15 AM, Kevin W. Wall wrote:
On Tue, Feb 12, 2013 at 5:00 PM, ianG <[email protected]
<mailto:[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.
If a business is not a commodity, then it is a service, which generally
aims to include some measure of lock-in. A more useful question is
whether the degree of lock-in (aka "switching costs") is worth the
overall benefit of the service.
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.
I agree that this is what it sinks to.
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.
OK, so perhaps it only takes someone like Judge Posner to ask why a
company applied "best practices" without some thought as to whether the
techniques applied ... to change all that.
http://www.nytimes.com/2013/02/09/opinion/nocera-innovation-nation-at-war.html?_r=1&;
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.
Indeed. Are there any quotable sources on those damages? RSA would do
a power of positive benefit to the security world if there were some
up-front figures and analysis.
It also may be that given the size of the exposure that RSA and its
customers had, that the airgap was a good technique. But that doesn't
mean that every other small competitor and corporate imitation also
needs that airgap.
This is perhaps a fallacy of security practice: because we can show
that one company needed security measure X, all companies should
purchase it.
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.
Yeah - this is why competition in security processes is so important,
and why best practices and herd behaviour -- everyone doing what
everyone else does -- is so important. By allowing experiments to
happen in the market place, we can analyse over time what the effects
are. What the better trade-offs are. Or, cut thru the marketing crap,
to use other words.
Microsoft is the greatest example of this. In the 1980s and 1990s,
people stuck with their pathetic security because the overall balance
was still better. But this just allowed Apple to pull a switcheroo on
them. In the 2000s, Apple maintained a "better security than Microsoft"
posture, and the users that switched earnt an immediate and ongoing
bonus -- peace from the nightmare. Bill G realised it with his famous
2003 memo, but he still wasn't able to spin MS around, c.f. Vista.
And now we the market know it, security makes a difference to our lives.
Competition was therefore the greatest friend of security, perhaps its
only friend. Standardisation, monoculture, best practices, various and
noisy assembled security experts, departments governmental, guilds and
other ghouls in their pontificated wisdom ... were the enemy of security
because they locked it down and it couldn't move.
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.
I see. Analysis is very expensive. So if that is part of the Bit9
model, I can see that would be a concern. If there is no analysis, and
Bit9 offered a suitably sandboxed signing environment, maybe this would
work. I see your point, tho.
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?
One of many debates, one of the fat handful of attacks starting to
appear in 2011. I personally think it is only worth reading if you are
trying to figure out why little or nothing is done.
| 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.
At which point it becomes a competitive question for the buyer -- do I
pay much more money to run my own internal signing, or do I get the
cheap&cheerful simple service from them?
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.
Indeed. But I'd home the promise of Bit9 was to make customers less at
risk, and thus transferring the risk to Bit9 was something worth paying
for :) If we analogise with an insurance company, it helps its
customers pay less for disasters, which naturally means it pays more for
disasters...
iang
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
