A Requirement By Any Other Name….
Since we’ve covered FISMA and NIST recently, I thought it would be a good time to discuss policies, standards, guidelines, and procedures. Hopefully I can provide some meaningful guidance regarding what should and in some cases shouldn’t be in each of these documents.
I will preface the rest of this post by saying that have learned some of these things only after violating the ‘rules’ of policy writing myself.
A policy should state a high-level goal; an executive-level goal to achieve a desired outcome. Supporting the policy are standards, more detailed documents identifying specific requirements that must be met in order to support the higher-level policy. Beyond standards are guidelines and procedures.
Policies are very general statements with very few details. They essentially establish an overall goal, like winning the war, or protecting company data. It is necessary for the documents at this level to be nearly devoid of details. Even though we use the term policy to refer to documents with much greater detail, which are actually standards.
Standards are the documents that should be relied upon to define specific requirements that have been deemed necessary to support and accomplish the stated policies they relate to. It is here that details such as password complexity requirements and disk sanitization methods are identified. Although standards provide considerably more detail than policies, they too should avoid the system-specific level of information that is reserved for procedures.
Guidelines can be considered at the same basic level as standards, except that guidelines are not mandatory. By definition, guidelines are just that, guides. Though not required, they provide guidance to assist in meeting policy requirements. In some cases an organization may choose to provide guidelines rather than standards, but I prefer the blended approach of defining standards when you can and using guidelines where appropriate.
Procedures define specific steps to implement policies and standards within a specific system and/or environment. They are necessarily low-level system-specific documents. One would expect to see multiple procedures in an organization that employs multiple platforms. The procedures for implementing access control in a Windows Active Directory system is much different from the procedures for doing the same task in a Linux system.
Let me take a moment to present a military example of the policy -> standard -> procedure hierarchy:
Suppose America is the victim of an unprovoked attack and the President makes a public statement that we will defeat our enemy. He essentially makes this policy statement to the Joint Chiefs of Staff; ‘Win the war!’
Now, there’s a lot contained in that very simple, very direct, and very general 3-word statement. How exactly do we go about doing that? Well, easy, sort of. The generals of the respective armed forces set goals. Air Force – Destroy their ability to fight in the air; Navy – Destroy their ability to fight on the water; Army – Destroy their ability to fight on the land; Marines – Destroy them period 😉
Within each service the generals and colonels and captains identify more and more specific goals and tasks until you get down to the basic fighting elements that actually carry out tasks in specific environments, against specific enemy forces.
The President and Joint Chiefs define policies; the officers within each component define standards and guidelines; the fighting elements follow specific procedures. Each supports the tier above, and in this way, the President’s policy of ‘Win the war’ is upheld.
Hopefully that analogy will help you see the roles of policies, standards, guidelines, and procedures. Just in case it doesn’t though, I’ll provide a summary:
Policies should be relatively short, general statements that provide little in the way of details. For information security a policy might be something like ‘All departments shall design, develop, and operate systems in a secure manner that protects both the information and the mission of the agency.’
Standards contain specific requirements related to a specific aspect of information security. A password standard (yes, even I almost typed ‘policy’) would provide specific information related to password length, complexity, and life-time. It may also address how passwords are delivered to their appropriate owner, how and under what conditions a password or authenticator is revoked, and address protection of individual passwords. Adherence to standards is formally required.
Guidelines also contain specific requirements related to a specific aspect of information security but differ from standards in that adherence to guidelines is not formally required. A Password Guideline would provide information regarding how you should do something but not how you must do something. In other words, a guideline will ensure that you meet the standard but it likely won’t identify every possible way to meet the requirements.
Procedures provide step-by-step instructions to successfully adhere to standards and will vary, sometimes widely, depending on specific hardware and software platforms. Procedures provide the implementation of a standard or a guideline. Creating a password on a MS Windows(r) system can vary greatly from creating a password on a Unix system or even a router.
I am planning to discuss the economics of security in my next post, so stay tuned…