What a Security Policy Is

An organization's security policy often contains a number of policies, each addressing a particular problem, such as remote access, encryption, email retention, and password management. (You can view examples at the SANS Web site in the resource list at the end of the chapter.) But taken as a whole, a security policy answers some very basic questions for an organization:

• Assets What do you want to protect?

• Threats What are you protecting them from?

• Risks accepted What threats are you choosing to not counter (or not counter completely)?

• Security technologies How will you protect your assets?

• Authorities Who has the power to implement these policies?

• Acceptable use What responsibilities does everyone have?

• Audit How will you know if you're compliant with your security policy requirements?

• Incident response What will you do if something goes wrong?

• Revisions How will you make changes?

As you can see, a security policy is based on security concepts, which build in a logical sequence, but it actually covers quite a bit more. The "quite a bit more" is necessary, though, to make the security choices work. Among the additional material is the endorsement of the organization's highest management, which gives the policy its teeth.

Especially in the current litigious environment, enforcing policies that have been adopted to protect the organization is important. Of course, this means that the security policy adopted must be enforceable. Often the real world doesn't work quite the way you expect, so you have to go back and refine your plans. Cisco uses a concept called the security wheel to address that problem. We'll cover the security policy itself, and then how it is managed and improved via the security wheel.

Assets

Every organization has a unique set of assets to protect. However, the protection starts with enumerating them, understanding what they are, and why they are valuable . Typically, assets are described by a combination of location and hardware and/or software type. Some security policies spell out the risk to the organization if this asset is compromised, corrupted, or lost (as in a physical disaster). For another look at enumerating assets, review Chapter 2, "Information Assets."

Threats

This portion of the security policy describes the threats to the organization's assets. Not all threats are network threats, per se. Physical security matters, toophysical access by an unauthorized person makes many cybersecurity technologies irrelevant. The threats listed are those that can make the assets less valuable to the organization, and they depend partly on what assets the organization has. Threat types were discussed in more detail in Chapter 3, "Threats."

Risks Accepted

Most organizations do not choose to protect against every possible threat (for instance, the threat of flooding in Las Vegas, Nevada). Two questions must be addressed:

• Is the threat likely to materialize? If so, what will it cost?

• Can you protect the threatened asset at a cost less than the financial risk involved?

Both questions must be answered affirmatively before it becomes prudent to counter the threat. Business resourcesand security resourcesare limited and must be used where they will actually do the most good.

Some organizations simply do not mention the risks they choose to accept. Others clearly state the threats they have chosen not to counter and the reasons why. This might offer them protection in legal proceedings because they can show that they considered the matter (as opposed to being negligent, or worse ) and that they applied their limited resources to more likely risks. That choice should be taken only after consulting the organization's legal adviser because laws and liability practices vary widely.

Security Technologies

This portion of a security policy covers the technical means by which an organization protects its assets. These can include networking architectures, encryption, firewalls, intrusion-detection system (IDS) sensors, and antivirus protection.

Not all security technologies need to be used, and not all assets need to be protected in the same manner. For instance, some data, such as empirical test data, might be costly to replace, and security technologies should include those needed for disaster recovery. Other data must be protected from unauthorized access, requiring strong use of access controls and possibly encryption. The appropriate technologies depend on the nature of the assets, the threats to the organization involving those assets, and the level of risk the organization has chosen to bear.

Authorities

This section declares the security policy to be a matter of policy for the organization, and it designates who within the organization has the authority to implement the policy or portions of it. That first part might seem a little vague, but it is the key to the policy's teeth. The organization's management specifically endorses the security policy and requires compliance with it. As a result, violations of the policy are not condoned (which is usually more legal protection for the organization).

More of interest to most network administrators and engineers is the designation of who has the authority to implement given technologies. This is usually IT or IS, but some portions, such as physical access control, might be given to other organizations.

Acceptable Use

This portion describes what activities are and are not allowed with the organization's information assetsthose that are and are not acceptable use (AU). Amazingly, outside auditors have discovered pornography sites hosted on organizations' networks, and those businesses have been able to do nothing more than remove the materials: They could not terminate the people who ran the site or even reprimand them. The reason? The organizations never stated that such use was not acceptable, and legal counsel advised that they would not win a challenge.

More mundane, but also important, is whether the organization allows personal use of the network and other information assets. Is all personal email verboten? Is IM/IRC (Instant Messaging/Internet Relay Chat) allowed, but only approved IM software and for business use only? Some AU policies are very detailed; others simply require that the business assets be used only for business purposes. There should also be statements concerning whether email, IM, and/or IRC will be monitored .

Audit

No one loves an audit. But just as in financial matters, an audit determines whether things really are as good as they seem or whether trouble lurks beneath the placid surface. This part of the security policy specifies who is authorized to perform security audits (which implicitly rules out people doing their own checks, including unsolicited penetration tests). It might specify audit frequency requirements as well (such as having the full network audited annually but critical systems audited quarterly). Much of IT audit efforts depend on system and activity logs, so policies addressing logging are likely to be in this section.

Incident Response

Despite the best of plans and implementation, sometimes something goes wrong (also known as "things happen"). A good security policy plans for this with an incident response section. This details who will respond and in what ways: who will constitute the team to respond to the incident, who will gather which data, how the data will be handled, what checklists will be prepared in advance, and so on. The quality of the organization's response is generally directly proportional to the degree of preparation, a general truth amplified by the fact that incidents are inherently disruptive to normal operations.

Revisions

"No plan survives contact with the enemy" is one of the principles of military thought, and the general idea behind it applies to the security policy as well. The business network will evolve, some assets will be added, and other assets change character. The security policy must have a mechanism to evolve and change with the network. That mechanism might simply be a general statement that changes discovered in the annual audit will be incorporated into the operating security policy. It could also lay out a formal change-management system, complete with proposal, review, and acceptance procedures. But revision as well as implementation is the idea behind the security wheel.