Individual security policies frequently look and feel alike. This makes them easy to read and understand. The challenge is how to organize policies as a collection. Policies need to be easily accessible and align to how an organization manages its IT environment.

There is no limit to the number of ways to organize collections of policies. Three common ways, though, are to organize by functional area, by layers of security, or by domain. Of course, you don’t have to utilize these methods, but they are easy to understand and logical.

Creating policies by functional area of responsibility is a challenge. The advantage of this method is that the policies can be tailored for a specific audience. The disadvantage is that functional areas may change due to organizational realignment. This means policies may have to change, too. Typically, organizing policies by functional area is the approach used in mature companies whose processes rarely change.

Creating policies by layers of security is also a challenge. A core principle in information security is the concept often referred to as layers of security, layered security, or defense in depth. Examples of layers are simple security controls placed within the network perimeter (a firewall), in an operating system (a server), in code (an application), and in secure storage (a database). Ideally, these controls collectively provide layered security. The challenge is that technology is constantly changing and evolving. Additionally, the number of layers depends on the company. For example, should telecommunications be considered a perimeter layer or its own layer? There is no one right answer or industry norm.

Defense in depth is not the only aspect of layered security. It is also important to have multiple controls for the same vulnerability. For example, if your concern is malware, antivirus is one control to mitigate that risk. Email usage policies are, too. External media (USB) policies will also aid in mitigating that risk. The goal is to have multiple, overlapping controls that address the same concern.

The third approach is to organize policies by domains. The seven domains of a typical IT infrastructure are shown in FIGURE 10-1. This is one logical way to view requirements and policies. The seven domains are a common taxonomy, or classification system, used across the industry. This taxonomy clearly illustrates how each domain can be used to create a layered security approach. For example, the Workstation domain may involve pirated software. The LAN domain can scan emails for viruses, while the Remote Access domain deals with virtual private network (VPN) tunnels. Different domains can have different security requirements.

The problem with organizing policies by domain is that many issues pertain to multiple domains. For example, virus control is a concern for workstations and servers. The requirements may vary a bit; however, the core need and control solutions are the same. There are few crisp bright lines between these domain areas.

Because there are no clearly drawn lines between domains, you need to ensure that requirements between the domains do not conflict. To give a simple example, a conflict could arise from requiring passwords of six characters on a workstation but eight characters on a server. This minor difference can make it difficult or impossible to implement a single sign-on solution. Single sign-on generally refers to the ability to authenticate once to get onto the network and then be automatically authenticated on different devices and applications after that.

A common approach is to organize policies to align with industry-standard frameworks. Examples of these frameworks include those provided by the International Organization for Standardization (ISO) and Control Objectives for Information and related Technology (COBIT). This is the most practical approach. First, many samples are easily accessible over the Internet. Second, once policies align with best practice frameworks, it becomes easier to demonstrate compliance to regulators. Industry-standard frameworks comply with regulations. By adopting the policies that use core concepts from these frameworks, you then demonstrate compliance.

The basic anatomy of a policy starts with understanding the different types of documents that capture the domain security control requirements. Five common documents are:

• Control standards—Policy documents describing core security control requirements
• Baseline standards—Technical documents describing security controls for a specific technology
• Procedure documents—Processes to implement control and baseline standards
• Guidelines—Optional documents that include parameters and recommended policies, standards, or procedures
• A dictionary—A common taxonomy used in the policies that defines the scope and meaning of terms used

Organizations use different terms to describe control standards. Some describe them as core policy statements. A baseline standard is also called a technology minimum security baseline (MSB). The key point is that policy documents make a distinction between core policy requirements and requirements unique to technology. For example, a core requirement may be to change passwords every 30 days. You might have two different baseline documents describing how to configure Microsoft and UNIX servers to achieve the core requirement.

The number of documents can also vary greatly between organizations. Some organizations combine related issues into a single policy document; for example, a workstation policy may combine preventing pirated software with virus protection requirements. Other organizations may treat this as two separate policy standards. The number of documents an organization uses depends on its need and capacity to deploy.

The goal is to develop a cohesive set of documents that do not require constant revisions to stay current and relevant. When there is overlap, reference the corresponding document rather than duplicating content. Here are a few common reasons why policy documents vary from one organization to another:

• Organizations use unique sets of technical tools and hardware.
• Risk management practices are often customized to an organization.
• The size of IT departments varies according to business needs.