On my evening walk with my best friend this evening, I pondered the disconnect between security policies and security outcomes.  Every organization I’m aware of has well intentioned security policies that enumerate important security objectives, for example the maximum amount of time to apply security patches to systems and applications.

My hypothesis is that information security staff believe that IT and business teams will translate those policy requirements into functional requirements when developing systems, while IT and business teams are developing systems based on a set of business objectives.  Hard security requirements, for example, minimum password lengths, usually do end up in IT’s design requirements, whereas security requirements that are process-based are not included, or not included in a meaningful way.

Let’s consider patching.  For the sake of argument, let’s assume our security policy mandates applying high severity patches on Internet facing systems within 48 hours.  What does the IT team do with this requirement when developing a new system?  Likely not much.  Patching is an operational process, not a requirement on how systems are built.  All systems need to be patched, they all can be patched, we have teams to apply patches, good enough.

In practice, though, I don’t know of a single organization that doesn’t struggle with applying patches on time.  There aren’t enough people, or the system can only be taken down once a quarter and never between Thanksgiving and Christmas, and so on.  This made me wonder: would adding policy requirements that enumerate operational expectations, in addition to traditional security objectives, help this situation.

For example, rather than a policy that says:

“Apply high severity patches to Internet-facing systems within 48 hours”

We instead have one that says:

“Internet-facing systems must be designed in a manner to enable applying high severity patches within 48 hours, including during change freezes.

Support teams must be appropriately staffed to consistently perform patch testing and apply patches on all relevant Internet facing systems within 48 hours.

Operational processes, including change management, must support the 48-hour requirement for applying patches on Internet facing systems within 48 hours.

Appropriate test environments must be maintained to support the 48-hour requirement for applying patches on Internet facing systems within 48 hours.”

This is only a simplistic example; however, it provides very objective requirements to include in IT development plans.

Does anyone do such a thing?  Has it helped?