Over the next few months, I'll be digging a bit deeper into what goes into formulating and publishing the various items that should appear in any organization's collection of security policy documents. In today's tip, I highlight a few helpful points in RFC (Request for Comments) 2196, entitled "Site Security Handbook." Its abstract does such a peachy job of explaining what this document covers that I quote it here in its entirety:

This handbook is a guide to developing computer security policies and procedures for sites that have systems on the Internet. The purpose of this handbook is to provide practical guidance to administrators trying to secure their information and services. The subjects covered include policy content and formation, a broad range of technical system and network security topics, and security incident response.

In fact, this whole RFC remains dead on target, even though it's now been six years since it was released (as an update of the still older and now obsolete RFC 1244). The information in Section 1.5 "Basic Approach" is by itself worth the price of admission: a short, cogent and highly compelling rendition of the security process in five simple steps.

Likewise, the three tradeoffs described in Section 2.1 "What is a Security Policy and Why Have One?" still explain the key dynamics at work in designing and maintaining balanced and workable security policies today:

• "Services offered versus security provided." Because every service offered also carries attendant security risks, the relative weights of risks and benefits must be considered very carefully.

• "Ease of use versus security." Because what's easiest to use is inherently least secure and what's most secure is inherently very hard to use, a safe and workable balance between these two extremes must be struck in every case.

• "Cost of security versus risk of loss." When weighing security versus loss, the costs of security have to be compared to the losses risked by a failure to implement security. In particular these costs include monetary, performance and ease of use weighed against loss of privacy, loss of data and loss of services.

The key role of security policy as a vehicle for informing people about the rules whereby they may access organizational technology and information assets is stressed throughout and should inform the letter and spirit of any policy documents you might create. Take a look at this great resource; you'll find it stimulates your thinking on this subject as much as it stimulated mine!

Next time, I'll return to the policy document library with a discussion of remote access policy statements and documentation.

Please feel free to e-mail me with feedback, comments or questions at etittel@iLearning.com.

About the author
Ed Tittel is VP of Content Services at iLearning, a CapStar company, and is based in Austin, Texas. As creator and series editor for Exam Cram 2, Ed's worked on numerous titles on Microsoft, Novell, CompTIA and security certifications, including Security+, CISSP and TICSA.

• Security Policies Tip: The security policy document library: E-mail policy
• Security Policies Tip: Security policy by example
• Ask the Expert: Kevin Beaver