security policy development, Writing Security Policies
How to Structure Information Security Policies
We talk to customers every day about security policies. One of the most common questions we receive is this: How should we structure our information security policies? When we dig deeper, we usually find that this is a really a two-part question regarding policy structure.
- First, how should we name and organize our documents.
- Second, what content or detail should go in each policy document. These are both great questions and we will address each separately.
Why the Confusion? HIPAA, PCI, FERC, NIST – Oh My!
Why do people struggle with this basic starting point for developing policies? In our opinion, this has to do with the various and confusing outlines of different information security frameworks and laws such as ISO 27002, HIPAA,PCI-DSS and NIST. People who (quite naturally) want to base their security policies on an established standard fall into a trap. These common frameworks are designed to organization information security requirements, not form an outline for security policies. For example, the NIST 800-53 outline is heavily biased toward technology. The first major section of PCI-DSS is devoted almost entirely to managing firewalls.
These common frameworks are designed to organization information security requirements, not form an outline for security policies.
As an example, the first control objective (5.1 Information Security Policy Document) of ISO 27002 requires that an organization have a written security policy. It does not specify how they will organized or grouped. If you simply adopt the ISO 27002 outline, you will find it very difficult to place certain items, such as Acceptable Use of Assets, which are targeted at end-users. The topic of IT Risk Management (which is called out in HIPAA and NIST) is not even part of the 11 domains listed. The NIST outline specifies that written policies and procedures are required in each of the 17 different domains. But if you simply adopt the NIST 800-53 outline, you will have challenges addressing common items like Third Party Security or Internet Acceptable Use.
The Common Policy Approach
We recommend a simple approach that is based on subject matter and target audience. We use this approach in our Common Policy Library (CPL). Using the CPL approach, information security policies are broken into a set of 10-20 policy documents, each covering a specific topic. These topics are chosen to overlap with the most common requirements of various laws and regulations. (Notice, we didn’t say ALL of the topics, but most of them.) Here is a sample list of documents using the CPL outline:
- IT Risk Management Policy (Risk Assessment)
- Security Program Policy (Policy, Planning, Personnel)
- Asset Management Policy (Inventory, Acceptable Use, Protection)
- Information Management Policy (Collection, Classification, Storage, Disposal)
- Third Party Security Policy (Assessment, Contracts)
- Personnel Security Policy (Screening, training, termination)
- Access Control Policy (Systems, Accounts, Passwords)
- Network Security Policy (Firewalls, Structure, Wireless)
- Physical Security Policy(Visitors, IT Systems)
- Operations Management (Configuration, Change Control, Malware)
- Application Security Policy (Development, Testing)
- Security Incident Management Policy (Reporting, Response, Investigation)
- IT Business Continuity Policy (backup, Business Continuity)
- Security Monitoring Policy (Logging, Audit, Monitoring)
- Customer Privacy Policy
- Employee Data Privacy Policy
Using this approach, each policy document contains all of the essential controls fora broad security topic (or domain using ISO terminology.) Each documents contains a set of more specific policies, usually between five and twenty statements per document. This provides enough detail to mitigate the risks of each category, but does overwhelm the stakeholders with information. (This is the approach we use with our information security policy library.)
In many cases, these topics align nicely with major categories of the ISO 27002 standard or NIST 800-53. Just as important is the fact these topics also have a specific target audiences (or “stakeholders”. For example, a Security Program Policy is generally targeted at management, oversight committees or external auditors. A Personnel Security Policy is targeted at hiring manager and the Human Resources department. Having a well-defined set of stakeholders makes each policy easier to review, update, approve and manage. This point is worth repeating:
Having a well-defined set of stakeholders will make any policy easier to approve and manage.
Avoid The One-To-Many Policy Approach
Some information security practitioners use what we call the “One to Many Approach”. In this approach, the organization has a single, overarching policy document with a group of very high-level policy statements. An example would be, “Company X protects access to all sensitive data”. These documents then refer to a group of “standards” documents to provide more detail. In our experience, this approach simply creates another level of abstraction that does not help get security policies written and approved.
Information Security Policies Versus Standards and Procedures
Another key to this approach is to make sure that these documents contain only “policy” statements. In other words, these documents describe very specific rules for what behavior and processes and technologies will be implemented within the organization. But they don’t specify how they will be implemented. For example, the Incident Management Policy can (and should) require that the organization develop specific incident response procedures. But these procedures should be in separate documents that refer back to the policy they are designed to support. (Procedures support and implement policies.) As another example, a baseline standard for an operating system can list the specific settings for parameters, accounts, and services. But these details should never be part of a security policy. Standards can be updated as frequently as needed.
Off the Shelf and Into Action
One of the great advantages of organizing security policies by topic and stakeholders (organizational roles) comes during implementation. For example, most information security regulations specify that personnel should be training on the policies that apply to them. When an organization mixes technical management and personnel policies in a single document, this becomes very difficult. When you limit each document to a limited set of policy statements, and then limit those to a specific audience, the process is very simple. Using this approach makes it very simple to use automated policy management tools.
Summary: Effective Security Policy Structure
In summary, break your security policy development into a series of policy documents covering various topics. Anywhere from 10 to 30 documents is common, depending on the size and scope of the organization. Within each document, have a group of specific security policy statements (from 5 to 25 is common.) Try to break up the topics to match the requirements of your business as well as the target audience. This approach not only makes it easy for your organization to demonstrate compliance with a specific law, but it will dramatically reduce the effort required to manage each policy.
