What Is a Security Policy?

This section gives you a working definition of a security policy and a discussion of the key policies you should care about as a security architect. Request for Comments (RFC) 2196, "Site Security Handbook," defines security policy as follows:

A security policy is a formal statement of the rules by which people who are given access to an organization's technology and information assets must abide.

Let's examine how this definition relates to what a security architect or operator must do. If you are in the business of keeping your networks "secure," you should be one of the biggest advocates of security policies. The reason is twofold: first, a security policy acts as a road map to guide you in the design and operation of the security within your network. This includes the requirements and risk as defined at the business level, but it also enables you to distill these business requirements and risks to a set of actionable items. Second, the security architect can use a security policy as a benchmark for the security system that results. Informing management that your security system implements the requirements of the policy is a much safer statement to make than saying, "The network is secure" (which, in most cases, is an impossible goal).

Consider the following example: assume your network was recently infected by an HTTP-based worm that spread primarily through internal, nonproduction web servers. Thanks to a security policy that mandates bandwidth protections for critical applications, you are able to ensure that the business stays up and running, even as nonessential systems are severely affected by the worm. Without a security policy that states explicitly that bandwidth protections are possible only for critical systems, how could you explain the outage of the nonessential systems? With a security policy in place, you can measure the security of the network against conformance to that policy. This, of course, doesn't guarantee a secure network but rather that you have a starting point to measure the execution of your security strategy. To make the policy work in this way, you must ensure you have the right stakeholders involved in the policy development so that there is awareness of the security goals of the organization. (More on this later in the chapter.)

Paring the previous definition of a security policy down to the essential elements, we arrive at the following definition:

A security policy is a set of documents detailing the computer security rules of an organization.

Mapping these rules to the specific requirements of an organization's security system is both your role as a security architect and the focus of several of the sections that follow in this chapter.

Security Policy Enforcement Considerations

Many security policy guidelines place emphasis on the notion of effective enforcement, the idea being that if you have no way of enforcing the policy, there is little use in having the policy. For example, why specify in an acceptable use policy (AUP) that users should not visit inappropriate websites if you have no way of enforcing such a policy? From a security designer's perspective, it is important to understand that there are several different ways that a policy can be enforced and not all of them are in the domain of the security architect. The next sections examine the following methods in more detail:

• Real-time technology enforcement
• Passive technology-assisted compliance checking
• Nontechnical compliance checking
• Contractual compliance checking

Real-Time Technology Enforcement

Real-time technology enforcement is the easiest and most comprehensive method of ensuring policy enforcement. In this method, an established technology is able to ensure, without operator intervention, that a given policy is followed. Blocking outbound Telnet access at a firewall to comply with an organization's AUP is an example of such an enforcement method. The filter can be easily put in place at the firewall, and it requires little operator intervention to ensure its smooth operation.

It is important to note that although you should always strive for technology that offers 100 percent assurance, you must realize that this is an unattainable goal. This doesn't mean you should settle for marginal technology, only that an enforcement method mustn't be perfect. Instead, when selecting a technology for a given purpose, consider the accuracy with which it is able to enforce aspects of your policy.

Passive Technology-Assisted Compliance Checking

In this category, technology assists the security operator with the enforcement of the policy, playing a supporting role. To fulfill the requirement of operator intervention, this sort of checking is rarely, if ever, real time and instead is usually historical or "pseudo real time." Often, the same technology can provide both time categories, with the only distinction being how often an operator reviews the data. An intrusion detection system (IDS) alerting an operator of suspicious network activity is an example of pseudo-real-time checking. A system that regularly cracks user passwords in an attempt to find users who select weak passwords is generally regarded as a historical compliance tool because it examines password strength long after the passwords have been selected.

Nontechnical Compliance Checking

Nontechnical compliance checking falls more in the realm of managers and human resources (HR) staff than it does network designers. In this method, managers can perform random compliance checks by occasionally walking up and down the aisles, checking on employees' network usage. As a note, once the manager sits down at a user's desk and pulls up the user's web browser history cache, the compliance checking becomes an example of passive technology-assisted compliance checking.

Contractual Compliance Checking

Contractual compliance checking is based on each user understanding his or her role in computer security and promising to abide by the rules by way of a contractual agreement. This is actually closely tied to nontechnical compliance checking. In this example, the only form of "enforcement" is through the addition of phrasing to each policy that informs users of the ramifications of policy violations. As an example, here is the phrasing at the end of one company's security policy:

Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

Provided that every employee has to sign off on such policies prior to the start of employment, this can be an effective method of implementing security policies. As an aside, to enforce the violation clause in such a policy, you generally must establish proof of noncompliance, which is handled by one of the previously defined checking mechanisms.

Next Steps

Security enforcement is a key element in any security policy. Just as security systems employ defense-in-depth, so can enforcement plans employ a similar posture to ensure that there is more than one method of enforcing a given policy. For example, almost any policy involving users can have an element of contractual compliance checking and still combine with any of the more active compliance methods.