Background

When we talk about technical debt that conversation is usually about old code, or the legacy systems that run it. I’ve observed another type of debt, which comes from policies, and seems to be most harmful in the area of security policies.

Firewalls or encryption?

A primary purpose for this post is to put out a statement I’ve been using in discussions for the past few years:

Any company that wrote its security policy prior to the advent of SSH is doomed to do with firewalls things that should be done with encryption

I’m using SSH as a marker for the adoption of public key cryptography. The protocol itself is irrelevant to the discussion, and most likely it’s TLS that’s being used in systems that we care about.

I’ve also presented a false choice here – it’s not firewalls or encryption, it can be firewalls and encryption (belt and braces).

The point is that if your policy says that you must use firewalls then you’re going to need a bunch of firewalls, and a bunch of the network segments that they imply; and that’s a bunch of extra cost and complexity that a newer organisation might forego in favour of having a policy that tells them to use TLS.

Cloud natives

‘Cloud native’ organisations and their architectures will usually favour encryption over firewalls. In fact the insistence on firewalls (and hardware security modules [HSMs] {and especially HSMs behind firewalls}) will ruin a cloud native architecture, or maybe cloud adoption itself.

Password cycling

Another clear example we can look at is periodic password resets. For a long while it was accepted best practice that passwords should be cycled (every 90 days or so), and that practice found its way into policies.

A few years back CESG and NIST decided (within a few weeks of each other) that periodic password cycling wasn’t helpful, and changed their guidance accordingly. They now advise that passwords should only be changed when there is evidence of compromise[1].

The best practice has changed, but largely the policies have not. In part this is inertia, and in part it is fear that a change in policy might violate some compliance requirement. The problem here is that regulators have a nasty habit of using practice by value rather than practice by reference, so there will be cases where the older NIST or similar guidance has been hard coded. This is compounded by the fact that most published policy demands ‘what’ (and sometimes ‘how’) without bothering to explain ‘why’, so the threads of connection to the regulation that shaped policy get cut, making it much harder to determine the impact of a policy change.

That we’re mostly still cycling passwords every 90 days, years after the standards bodies announced that this was a bad practice, serves as ample evidence of policy debt.

Why does this matter?

Organisations are less agile, because they can’t embrace new technology and approaches.

Organisations are also less secure. Not just because they can’t embrace new technology and approaches, but also because they can’t stop doing bad things after overwhelming evidence emerges that those things are bad.

What can be done?

Policy debt needs to be tackled alongside of other aspects of organisational and cultural change, otherwise it impedes change. If culture is ‘the way we do things around here’ then policy encodes that, so if culture needs to change (for a DevOps adoption or Digital transformation or whatever else) then the policy needs to be dragged along with it.

Conclusion

There is clear evidence of policy debt accumulating in older organisations, and it’s getting in the way of them adapting to the realities of the business context and threat landscape they now operate in. Policy debt will continue to get in the way until it’s understood and tackled as part of larger change.

Note

[1] See The Problem With Passwords