Policies – The traps you don’t see

PolicyImageIt’s that time of year again: time to update the policies! This annual exercise is always a source of great enjoyment for me (no, not really). After all, there’s nothing like having the non-technical flailing about as they try to force-feed technical requirements down the throats of IT without explaining, justifying, or providing any factual basis for asking. If there’s something most techies love, it’s an over-the-top policy recommended by external auditors.

Quite frankly, policies are the precursor to, an embodiment of, the checkbox-compliance mindset. We all know how well that’s worked out for us thus far. I mean, looking at all the data breaches we’re not having thanks to compliance and policies, right? Hahaha… oh.

One of the biggest problems with these annual policy-update exercises is that “policies” are rarely defined properly within the enterprise. Instead, you get a jumble of policies, standards, baselines, processes, and rules, all crammed into some monolithic document that some know about, few review, and even fewer follow.

Policies should, definitional, be a statement on desired risk management strategy. They must articulate the business case and basis for understanding operational risk and how the enterprise desires to manage that risk. These statements should create the limits known as risk tolerance, risk capacity, and risk appetite with means for measuring against those limits to make sure that IT is operating within the defined parameters.

Policies are not the place to document specific technical controls (or practices). Those statements must exist within the other lower levels of documentation, and for the most part should be owned by the operational teams, which will make sure that they have a wish to adhere to their own defined practices.

A quick path to failure is having non-technical compliance people telling technical people how to run their IT without actually understanding what they’re talking about. As if we didn’t have enough credibility challenges, let’s just make it worse by trying to inject incompetence and misunderstanding into a technical environment. That should work out great.

This line of thought leads me to three significant fallacies I’ve consistently met.

Fallacy #1: If You Write Them, They Will Comply

One of the most amusing notions is that of the aspirational security policy. “If we write this policy at this level, then everyone will come into line. We just need the strength of a policy to force people into a new way of behavior.” All good and fine until you then immediately start issuing exceptions to the policy because people can’t comply. Or, worse, your policy isn’t really a policy, but rather a standard, baseline, etc.

The fact of the matter is that policies should not be viewed as “something to follow” rather than as “the risk management boundaries within which we must work.” Policies should clearly articulate the risk management strategy and then everything else (such as technical standards) should offer the implementation details that demonstrate those expectations.

A perfect example is the SOX audit. SOX 404 does not specify technical controls. It establishes a high-level aim to guard against fraud in financial systems. Unfortunately, the AICPA, ISACA, and auditor community has spun that to mean specific technical practices when, really, the focus should be on a handful of specific, auditable capabilities like monitoring for configuration state changes, monitoring for attacks and anomalous access/traffic, and demonstrating overall process integrity through automated methods/mechanisms. However, these things are a bit more “squishy” and require a lot more technical savvy to audit, which leads to devolving the requirements to checklists, which in turn can be adopted by people lacking cluefulness, forced down the throats of ops teams that are already under siege from other quarters. It’s a lose-lose proposition, and I marvel that anybody willingly enters the IT space any more, figuring they just don’t realize what they’re in for… but I digress…

Fallacy #2: Policies Stop Incidents

Show me a documented policy that has stopped a data breach. No, really… I’ll wait. Policies don’t stop breaches, nor should they! Policies establish the overall risk management context within which specific practices should be established.

Technical and administrative controls stop incidents. Policies are neither of these things. Processes and procedures are administrative controls. They align to desired performance characteristics set forth in policies. So it also is for technical controls. What this means is that a policy, at best, provides a one-off means of protection against incidents, but because you don’t implement policies so much as align to the standard of performance, they do not prevent anything.

Maybe it’s nitpicking, but the point is this: the policy statement/objective is to reduce the incident of compromised accounts because it has negative impact on the business, and one of the administrative controls implemented to meet this objective is the awareness initiative telling people not to give out their passwords. Undoubtedly, there will be several other technical and administrative controls to further meet that high-level goal.

Fallacy #3: You Can Just Adopt Standard X For Policies

First, why would you want to abdicate decisional authority for how your organization functions to a third-party entity that knows nothing about your organization? Second, most standards start with a “scoping” phase that need you to first understand and define your business requirements, which is what your policies should be articulating (anything more than that gets beyond the role of a policy and into the land of standards, baselines, etc.). Third, while various standards and lists of practices can be instructive, such as for security architecture, it’s rarely a good idea to blindly adopt them wholesale without heavily customizing them to meet your organization’s needs.

Yes, it’s true that lists of practices like the CCS Critical Security Controls (SANS) can be informative in terms of making specific technical architecture decisions, but this is most definitely not the realm of policies. Policies must articulate why specific changes are necessary/important and what business risk management goal is being achieved. It’s a common misconception among certain populations(coughauditorscough) that one can simply checklist-away all the world’s ills. Of course, if this were true, and if securing the enterprise were really so easy, then we wouldn’t need to have this conversation.


Policies typically are nothing more than a trap. Some folks mistakenly believe in aspirational policies, which cannot be enforced, which means that they’re null and void (and, enforcing them arbitrarily can lead to legal issues). Others think that writing a policy will magically change practices or corporate culture. Again, a logical trap in that the policies don’t actually do anything. If the policy isn’t a direct change in practices, then it’s a one-off, which we know definitely does not result in change.

The proper use of a policy is articulate business requirements and objectives, which are then met through the implementation of technical and administrative controls. These controls should be owned by the implementing teams, which allows them the flexibility to come up with feasible solutions. The policy should offer a means for measuring that “risk” is within the defined limits, but must stop short of specifying the “how.” Sadly, this perspective is often misunderstood and misrepresented, leading to the annual circus of “policy updates.”

What do you think?

Share & Comment below…