"I'm not proud of being a congenital pain in the ass. But I will take money for it."

Why deploying security is hard

Sun 18 March 2018 | -- (permalink)

Jeff Haas gave a talk at today's IEPG meeting which, oversimplified, boiled down to "TCP AO still looks like the best match for solving a whole bunch of security problems related to routing protocols, but nobody uses it because nobody has implemented it because nobody uses it." This got me thinking about why it's always so hard to deploy any kind of protocol security improvement.

The eternal generic security equation is:

  1. What resources are you trying to protect?

  2. Against what threats?

  3. And how much are you willing to pay?

To which the usual answers are:

  1. Whatever I've got, which I may not entirely understand.

  2. The ones I know about which could hurt me badly.

  3. As little as possible, doh.

The problem is that the answers to (1) and (2) can and do change overnight when Something Bad Happens.

It takes a long time to implement something better, what you end up with is more complex, more expensive, and often more fragile, and the whole security aspect is mostly a negative benefit (nice protocol you've got here, be a shame if something happens to it...).

So either:

  • You don't do anything until hurt, at which point you're in a mad scramble to catch up, which often results in something half-assed; or

  • You're developing a complex fix before demand for it exists, and your deployment plan is Waiting For Kaminsky.

In practice, we usually take the first of these options, perhaps because the latter requires forward planning, budget, and a strong belief that water which has been running downhill since forever is finally going to hit bottom.