Thoughts on Security Policies
Introduction
I was asked to write my thoughts about security policies down by a good friend of mine and spent the better part of a Sunday morning in April thinking about the topic. This post is the unedited version of the thought process. I'm sharing it here because it might prove useful for some of you.
How we got here
Security policies, for most organizations, came in vogue in the early 2000s as it became apparent that IT infrastructures became more and more important to businesses. Describing how they needed to be operated seemed like a good idea. Since then, technology has developed at an incredible speed and the policies (or the people writing and maintaining them) largely failed to keep up. Firstly because the policies we wrote ended up being very fragmented, losing consistency along the way, and secondly because the knowledge gap about the systems and technology that we rely on has widened beyond control.
Current state
Many organizations have a large set of documents that, together, form their "Information Security Policy". We see two main sources of policies. Namely ISO27001 (last updated in 2013), as a global standard for Information Security Management Systems, and NIST SP 800-53 (last updated in 2015), which is aimed at US Federal organizations.
There are many problems to note about the majority of Information Security Policies: 1) They often exists as a monolithic book that nobody completely understands. As technology moves faster and we see the adoption of approaches such as Agile and Dev(Sec)Ops, policies just can't keep up and they might even become contradictory. The biggest problem here is that the intent of the policy is not represented by the implementation of controls.
2) Very few Information Security Policies were instrumented with the right metrics to measure effectiveness and adoption. Without the ability to measure the described processes it is impossible for organizations to identify deficiencies and adapt where necessary.
3) Ideally, in policies, we define the difference between a policy, a process/procedure, and a standard. This difference is lost in many policies we see implemented today, leading to a large body of knowledge that is ambivalent in its purpose. Where the policy should describe intent on a high level, processes/procedures and standards prescribe how that intent is represented across the organization.
4) Exceptions are the standard. Due to a combination of the points above, and most importantly point #2, most organizations have a large number of exceptions to their policies. A policy that leads to many exceptions is, by definition, ineffective. However, the exception policy is usually the best known in organizations. 5) Compliance as a driver. I don't have data on the percentage of organizations actually certified against a framework like ISO27001:2013 but based on anecdotal observation, the majority of policies in organizations that do not have Federal requirements is based on this framework. The reasons I see are three-fold :
(1) Organizations want or have to be certified;
(2) Organizations think that, at some point, they want or have to be certified, and;
(3) Organizations hired consultants that used ISO27001-based templates to "develop" their policies. "Compliance isn't Security" is the dead horse we have been beating for a while now, but that doesn't make us wrong. I still posit that a secure infrastructure should attest to its compliance with certain requirements at any point in time. Compliance should not be determined by the mere existence of policies and anecdotal evidence of its implementation.
What is next?
We've already seen quite a few organizations move to a different approach on implementing their information security policies. The NIST Cyber Security Framework is very much a disruptor in this space. It is largely focused on "capabilities" and does not purport to be a compliance standard. It champions for risk-based decisions more than pure compliance with a "gold standard.
In February 2018, The ISO SC27 - responsible for the ISO 27k standards - published ISO27103:2018. This is a guidance document for achieving ISO27k compliance with security programs based on NIST CSF. There is positive collaboration between both groups so we can only hope that there will be positive outcomes from this.
That said, there are also technological evolutions that have promise in this space.
Move to Infrastructure-as-Code
We now have the ability, through tools such as Terraform and Ansible, to properly describe our infrastructure (cloud or on prem) in line with policies. This should lead to a restructuring of policy frameworks to a state where they should always have been : high level intent on the policy level and provable implementation at all times.
Move to Observability
IT infrastructures have grown to be complex systems that are determined by their outcomes. As we develop them further, instrumenting them to inform us about their state and health, compliance with policies will become more provable. "Observability" was initially a term devised to indicate the need for more insight from a monitoring perspective. Where we focused on "use cases" and gathering data in function of those use cases, observable systems start from the data and help us understand their outcomes.
Executive buy-in
There is no doubt that executives and board have information security set as a big priority on their shared agendas. These audiences are not interested in a list of vulnerabilities or knowing about the mere existence of policies. They need data that allows them to make risk-informed decisions. This too should drive security teams to review their policy frameworks such that the right metrics are identified.