When a policy isn't a policy

Clarifying your security whys, whats and hows

Overuse any word, and it begins to lose meaning in a way that obscures important aspects of the discourse. Political apparatchiks tossing around the word terrorism have experienced this in the past few years, befuddling conversations about acts of war and fear with acts of criminal mischief and civil disobedience. Information security practitioners, by the same token, have overused policy as a label for just about any formal discussion of security control, thoroughly confusing discussions of governance with performance standards and technical implementation.

A "router policy" is not a policy. Neither is a Group Policy Object (GPO) in Active Directory.  A password policy document is most certainly not a policy in the normal sense of the word.  All too often, I’m presented with a collection of policy documents during an organizational governance review, and the documents turn out not to be policies at all. What’s gone wrong, and how can organizations and their management get right with the governance gods? 

Organizations are widely subject to legal and contractual requirements that demand formalization of the requirements and imperatives. We call these polices. Yet somewhere along the line, some also started calling the implementation documents -- or even the implemented controls themselves -- "policies." This creates a tremendous amount of confusion when an organization tries to come into compliance with the likes of the Health Insurance Portability and Accountability Act (HIPAA) Security Rule, the Payment Card Industry Data Security Standard (PCI DSS [PDF format] -- recently updated to version 1.1), or broad standards such as ISO 17799  and 27001. 

For example, Section 11.1.1 of ISO 17799:2005 says, "An access control policy should be established, documented, and reviewed based on business and security requirements for access." It goes on to recommend controls for user access management and password management, among other things.  However, an organization that successfully implements and produces documentation of every named control still does not have a policy.

Digging a little deeper, what ISO 17799 -- and any other standard that requires a policy -- is prompting is a formal directive or statement of intent regarding a control objective.  In other words, "You must protect sensitive assets with access control" is an acceptable policy directive, but "You must use 8-character passwords" is not a policy statement, because it lacks an objective. 

Policies vs. controls

Policy documents should answer a question of "why."  They establish that we’ve got some rules around here. They need to be supported by documentation that describes what a security control has to do or produce in order to be compliant with the policy, and that in turn has to be supported by documentation of what happens or has actually been put in place. While one might have a personal policy of eating dinner, the menu that describes all the things that might be dinner, and the meatloaf that actually arrives on tonight’s plate, are clearly different things.

That’s not to say that policies must be completely disconnected from technical and process controls, whether we’re talking about fiscal management, information security -- or dinner. On the contrary, a good system ought to simultaneously separate requirements from controls while demonstrating that they are synchronous. Each policy sets forth an achievable goal, and the control ought to provably meet that goal.

If the control is stuffed into the body of a policy -- e.g., "Our policy requires installation of F-Prot AV Version 6" -- there’s no connection to a business requirement.  If a policy has no specific or feasible controls -- e.g., "We keep all data secret" -- there’s no way to prove that the policy is implemented or even meaningful.

If policy documents answer a question of "why," then control documents should answer a question of "how." This brings us back to the issue of policies that are not really policies.

Configurations in disguise

Many examples of "router policy" or "firewall policy" are little more than configuration documents that define specific TCP and UDP ports to be opened for egress and ingress, along with other operational details.  For example, a configuration file from a Cisco router is sometimes referred to as a "router policy." Clearly these fail the policy test because they don’t answer the question of why the firewall has these rules, or even define the functional goal of any particular firewall or set of firewalls. (A good example of valid firewall policy is described in the NIST Special Publication 800-41 [PDF format].)

Microsoft defines Group Policy as "an infrastructure used to deliver and apply one or more desired configurations or policy settings to a set of targeted users and computers within an Active Directory environment." That sure sounds like a control to me. Digging further, the same materials say Group Policies "use templates to modify the registry settings for policy-enabled components included in Windows."  A policy is supposed to be a directive or assertion, but Group Policies don’t seem to tell me anything about why they exist or what requirement they meet -- just how a database object is modified.  On Microsoft’s Technet, one reads that  "security policies are rules that administrators configure on a computer or multiple computers for protecting resources on a computer or network." 

This is a little twisted, but it’s from the same people who tried to say that DNA stands for Digital Network Architecture. Yes, security polices are rules, and those rules ought to be implemented by configuring a computer (in this context).  However, when the rule is the same thing as the configuration, how does one check that the configuration correctly implements the rule?  You can’t, because you don’t have a rule anymore -- you just have a configuration. A GPO is nothing like a policy; it is a control implementation, even if it does have a nifty software interface and some comment text saying what it does.

Even Password Policy documents, often trotted out as the shining example of a company’s policy set, are frequently befuddled and confused collections of information.  More often that not, the author can’t decide whether a password policy is about the need for passwords as a means of access control (which might make for a passable policy) or about the required complexity of standard passwords on every system except for some old AS/400 that needs a six-character alphabetic password ... which has nothing to do with policy directives or compliance.  Roll these together, and you don’t have a policy, you have a mess of control description and procedural documentation.

What, then, are these other imperative-seeming statements and documents we see in relation to IT security and privacy?  There are lots of interpretations, but the most common break out the control documents -- that answer question of "how" -- into two levels.

Standards, guidelines and documentation

Behind each policy, one might find "standards" or "guidelines" documents that support the policy, establishing metrics by which one can determine if a particular control satisfies that policy. In a larger IT security operation, these still don’t define a particular firewall product or version of antivirus software. 

A "standard" just says, for example, what AV software -- any AV software -- must do in order to meet the requirements of the desktop security policy.  Where a security control involves a process, a "guideline" can provide the steps through which the control -- again, any particular control -- can be made to meet the requirements of a policy.  For example, a standard or guideline for wireless access points can provide steps for securing any brand or version of access point to the level required by a network security policy.  Most password policy documents actually fit the definition of a standard.

Beyond the standards and guidelines, one finds (or hopes to find) the actual documentation of security controls.  "Procedures" or "implementations" contain the real details of what’s protecting your organization.  Version numbers of software, latest vendor patches, build documentation, incident response call lists and GPOs all fit into this category.  Even more than answering the question of how your organization is protected, they go on to describe "what" and "where."

Why it matters

I’ve been accused of being didactic and nitpicky about these distinctions, but let's try another analogy: Are financial organizations allowed to casually self-audit in these post-Enron days?  Of course not.  Requirements for fiscal management have to be clearly stated and reviewed as appropriate. We call these fiscal policies.  Those policies then have to be implemented in money management mechanisms and processes.  These are controls. The correct function and effectiveness of the controls are reviewed and reported back to executives, who then sign off on assertions that the policy is being followed.  Verifying the truth of these assertions is an audit.

Executives’ butts will be in a proverbial sling if an audit turns up false assertions, but can executives do the auditing themselves?  No.  In fact, that would be a violation of standard accounting practices in itself.  Why?  Because self-auditing is a non sequitur. As an individual, you can say you’ve double-checked yourself, but to assert you’ve ascertained that your previous statements are truthful by cross-examining yourself. ... Talk like that and some string hanging out of your mouth will get you a seat by yourself on the bus.

One might also get the feeling from this tirade that I’m against combining policies, standards and implementation information into a single document for simplicity.  I am, but only because I’m a fan of clarity and I think a larger structure trumps a smaller heap.  But that’s not to say it’s unreasonable or inefficient to do so, especially for astute organizations afraid of too much documentation.  However, practical worries include omission of required information, or confusion between revision cycles for important documents.  For instance, you don’t want to be revising your desktop computer security policy every time the OS vendor issues a service pack.

Revision rules of thumb

The rules of thumb I find useful are these:

  • In a midsize to large organization, policies ought to be concise directives in very short documents, and they ought to change along with adjustments to the core business -- maybe every year or two.  If your core policies change more frequently than that, then there’s confusion over the basic information security goals, or the organization is in chaos and it’s time to polish the resume. 

  • A security standard might change every six to 18 months, as risk crests and troughs.  However, if your standards -- such as those defining minimum functions of your firewalls or authentication systems -- change much more frequently than that, there’s confusion over what constitutes proper operation of a security control.  If they’re pretty stable documents and you want to reduce document maintenance, append them to the policy documents where appropriate.

  • In contrast, procedures and implementations can change every time the wind blows with few repercussions; threats and vulnerabilities are unpredictable, and who knows what vendor patch will head your way tomorrow. When that vendor patch does arrive or you switch to new AV software, the only things that should change are the procedures and implementation documents.

One has to use a bit of judgment here; it might only offend my sense of technical elegance to combine a policy with its technical standard. However, combining a policy document with the as-implemented documentation of your security controls can lead to real trouble. This might range from operational confusion over repeatedly modified documents to auditors rejecting the policy document as being an as-built record rather than a policy, or not having being approved by management in its current form.  For organizations that’ll be subject to any kind of information security governance review, it’s far safer to consider combining policy, standards and procedures after they’re all in order than to create a pile of security information and slap a "policy" label on it.

Jon Espenschied has been at play in the security industry for enough years to become enthusiastic, blasé, cynical, jaded, content and enthusiastic again. He is currently a senior security consultant in Seattle, where his advice has been ignored by CEOs, auditors and sysadmins alike.

Copyright © 2006 IDG Communications, Inc.

Download: EMM vendor comparison chart 2019
Shop Tech Products at Amazon