Anatomy of an Infrastructure Policy

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.

WARNING

No matter how good any single security control is in place today, you must assume it can and will be hacked at some point. There is someone, or some group, out there with enough time and resources to hack the control. This is why common security practice suggests multiple lines of defense, layers of security, or in-depth security, from the perimeter through the network layers to ultimately protecting the data.

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.

An illustration of the seven domains of a typical I T infrastructure.

FIGURE 10-1 The seven domains of a typical IT infrastructure.

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.

NOTE

To keep the discussion at a high level, this chapter discusses policies as they align with a typical IT infrastructure. This allows for a discussion of domain requirements that drive policies. It does not mean this is the best way for every organization to organize its policies.

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.

Format of a Standard

Typically, standard and process documents have a well-defined format. A common format includes the following sections:

  • Document Number—Uniquely identifies the document and usually categorizes the document as a policy, standard, or procedure, or as guidance
  • Title—Identifies the topic of the document
  • Version/Date—Identifies the version and date of the document
  • Purpose—Provides measurable objectives and goals
  • Background—Explains why the standard was put in place
  • Standard/Process—Describes the standard or process to be implemented
  • Roles and Responsibilities—Identifies who is responsible for implementation and adherence
  • Effective Dates—States when the standard must be implemented
  • Information and Assistance—Defines teams within the organization that can explain the standard and assist in coordinating its implementation
  • Approval—Specifies the approving authority; this can be either an individual executive or a group of individuals such as a standards committee
  • Associated Resources—Provides any related resources

The exact format may vary among organizations. For example, some organizations may describe whom the standard affects in a separate scope section. In the example listed, this is bundled under Roles and Responsibilities. Other possible sections are Revision History, Key Terms, and Supporting Attachments. The format varies by need and source of material. Often, samples of policy templates are based on industry-standard frameworks or vendor-supplied samples. These samples usually define the initial format. The format changes over time to adapt to an organization’s individual needs.

TIP

It’s important to use a consolidated calendar to track the dates when new policies and policy changes take effect. Organizations can have large numbers of policy changes taking effect each month. Having a calendar that is reviewed by stakeholders every month works well to prepare for policy implementation. For example, it helps the developers know what further changes are needed to support the implementation of a new policy.

Standards need to be highly structured to be understood quickly. It is common for an individual to scan a dozen standards looking for a particular piece of information such as scope or responsibility. A well-defined format will allow that individual to quickly sort through a large amount of data and focus on information of interest. Online tools can help make the collection of documents more manageable and searchable. Use online collaboration tools such as Microsoft SharePoint. Many of these tools come out of the box as preconfigured and searchable document libraries.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
13.59.160.92