Policy debt



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 their 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.


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.


[1] See The Problem With Passwords

4 Responses to “Policy debt”

  1. 1 Mark H

    I couldn’t agree more. A lot of security gets into a mess because of poor governance – no where does this resonate more than with policy. Policy is part of the security strategy, not the strategy in itself. It needs to respond to changing threats and changing infrastructure, and in many ways is becoming less relevant in some of the current approaches to today’s IT.

  2. 2 mgnelsonwp

    There is also a financial incentive to move high change requirements to high change mechanisms. Policy, in and of itself, is neither good nor bad.

    The after effect from using a technology, based on a policy, incorrectly – could be massive.

    In the technology realm, it can force a bad approach to solving a problem.

    In the financial realm, it ties the user need to custom or product rather than commodity/utility capability.

  3. We are going through polices to assist organizations in transitioning to cloud-native and DevOps operating models. Another major form of debt is assumption of waterfall lifecycle stage gates where controls can be inserted. Dedicated QA and security reviews, for example.

  1. 1 InSpec and the Too-Long(?) Life of Security Policies - Chef Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: