diginotar response, plus ca bcp/dr planning

I have two more thoughts on this whole DigiNotar mess before I hopefully never post about it again.

First, DigiNotar gets breached and trust in their process is broken. We shun them like the lepers they are! Earlier this year, RSA gets breached and trust in their process is (arguably) broken. We wring our hands and wait. The reaction to DigiNotar is not scalable. Sure, it perhaps is the correct approach for various reasons (a- protect yourself, b- give them an economic lesson in the risk of insecurity, c- trust is never “slightly” broken, it’s all broken!…), but it just doesn’t scale to a more important CA or 3rd-party trust provider.

That bothers me. There are lots of innocent victims of DigiNotar who could have done nothing to prevent this issue or better vet DigiNotar. Is that the fault of the people/orgs who shunned DigiNotar, or the fault of DigiNotar? If we, as reasonable security practioners hold fast to the idea that Breach is inevitable, then it’s the fault of the trigger-happy fingers who shunned them, right? Otherwise, why are we placing trust in anything outside our walls at all?

I’m not entirely sure I buy my own arguments yet, but that’d be discussion-for-thought…

Second, I listened to the Cyber Jungle podcast (my first time even hearing about them) specifically to hear the interview of Venafi’s Jeff Hudson who recommends an SSL Certificate breach response plan (keeping in mind his company offers solutions in this space). I was a bit keen to hear what insight someone might have on such a response plan. His plan (min 27:00) takes three general steps/questions (I’m not sure if he’s talking only about SSL certs or more broadly in what he calls your overall 3rd party trust):

1. Who are you using for trust?
2. Where are the certificates?
3. Be ready to replace certificates in response to a problem.

These make sense, but I guess I was already mentally past the first two items and really wanted to hear a strategy for #3. No such luck, and I guess I’m not surprised since that’s really the problem.

At my day job I manage over 100 web sites, most of whom have SSL certificates (to keep this simple). If my CA (Network Solutions) happens to get breached and their roots shunned, in the short term I’m fucked no matter what I do or how much I plan. This is because my domains are hosted by Network Solutions, and I cannot buy a certificate for one of those domains from a different registrar.* I mean, that’s the whole point about making sure certificates are valid! So if tomorrow NetSol is shunned, I have to “quickly” move all my domains elsewhere, and initiate the SSL process. By the way, almost all of my certs are EV SSL certs (yes, I hate them) and they’re not quick to issue, by design. I’d probably have to short-term downgrade them and then field any questions about lack of pretty green colors in the damn address bars.

And that’s just the “simple” 3rd-party trust that is web-borne SSL.

There’s really no BCP/DR plan other than having a pre-existing relationship with another CA that you can migrate to quickly. There’s no high availability, though, and no quick failover. You also need to at least have a few domains/certs on the second provider so that your staff is used to working with them (and they’re used to working with you!), but clearly that increases administrative overhead just a bit.

This gets even worse for those people (not me) who not only use their CA just for domains and certs, but also for their actual hosting. Now there’s a nightmare I don’t want to imagine!

* Strictly speaking, you can do this, but it illustrates and puts further pressure/exposure on a process that is flawed. If I go to an SSL provider and ask them to issue me a cert for a domain hosted by NetSol, their only recourse is to email the publicly listed contact and use that response as the full authorization. This process does not make any reasonable security person feel joyful and has been the source of abuse in the past (we’re talking reliance on automated processes and/or low-on-the-pay-totem-pole customer support).