Policy plays three major roles. First, it makes clear what is being protected and why. Second, it clearly states the responsibility for that protection. Third, it provides a ground on which to interpret and resolve any later conflicts that might arise. What the policy should not do is list specific threats, machines, or individuals by name—the policy should be general and change little over time. For example:

In this example policy, note particularly the definition of what will be protected, who is responsible for protecting it, and who is charged with creating additional guidelines. This policy can be shown to all employees, and to outsiders to explain company policy. It should remain current no matter which operating system is in use, or who the CIH may happen to be.

Standards are intended to codify the successful practice of security in an organization. They are generally phrased in terms of “shall.” Standards are generally platform-independent, and imply at least a metric to determine if they have been met. They are developed in support of policy, and change slowly over time. Standards might cover such issues as how to screen new hires, how long to keep backups, and how to test UPS systems.

For example, consider a standard for backups. It might state:

This standard does not name a particular backup mechanism or software package. It clearly states, however, what will be stored, how long it will be stored, and how often it will be made.

Consider a possible standard for authentication:

Guidelines are the “should” statements in policies. The intent of guidelines is to interpret standards for a particular environment—whether it is a software environment or a physical environment. Unlike standards, guidelines may be violated, if necessary. As the name suggests, guidelines are not usually used as standards of performance, but as ways to help guide behavior.

Here is a typical guideline for backups:

Guidelines tend to be very specific to particular architectures and even to specific machines. They also tend to change more often than do standards, to reflect changing conditions.

The role of policy (and associated standards and guidelines) is to help protect those items you (collectively) view as important. They do not need to be overly specific and complicated in most instances. Sometimes, a simple policy statement is sufficient for your environment, as in the following example:

Other times, a more formal policy, reviewed by a law firm and various security consultants, is the way you need to go to protect your assets. Each organization will be different. We know of some organizations that have volumes of policies, standards, and guidelines for their Unix systems.

There are some key ideas to your policy formation, though, that need to be mentioned more explicitly. These are in addition to the two we mentioned at the beginning of this chapter.

The key to successful risk assessment is to identify all of the possible threats to your system, and to defend against those attacks which you think are realistic threats.

Simply because people are the weak link doesn’t mean we should ignore other safeguards. People are unpredictable, but breaking into a dial-in modem that does not have a password is still cheaper than a bribe. So, we use technological defenses where we can, and we improve our personnel security by educating our staff and users.

We also rely on defense in depth: we apply multiple levels of defenses as backups in case some fail. For instance, we buy that second UPS system, or we put a separate lock on the computer room door even though we have a lock on the building door. These combinations can be defeated too, but we increase the effort and cost for an enemy to do that...and maybe we can convince them that doing so isn’t worth the trouble. At the very least, you can hope to slow them down enough so that your monitoring and alarms will bring help before anything significant is lost or damaged.

With these limits in mind, you need to approach computer security with a thoughtfully developed set of priorities. You can’t protect against every possible threat. Sometimes you should allow a problem to occur rather than prevent it, and then clean up afterwards. For instance, your efforts might be cheaper and less trouble if you let the systems go down in a power failure and then reboot than if you bought a UPS system. And some things you simply don’t bother to defend against, either because they are too unlikely (e.g., an alien invasion from space), too difficult to defend against (e.g., a nuclear blast within 500 yards of your data center), or simply too catastrophic and horrible to contemplate (e.g., your management decides to switch all your Unix machines to some well-known PC operating system). The key to good management is knowing what things you will worry about, and to what degree.

Decide what you want to protect and what the costs might be to prevent certain losses versus the cost of recovering from those losses. Then make your decisions for action and security measures based on a prioritized list of the most critical needs. Be sure you include more than your computers in this analysis: don’t forget that your backup tapes, your network connections, your terminals, and your documentation are all part of the system and represent potential loss. The safety of your personnel, your corporate site, and your reputation are also very important and should be included in your plans.