Writing a security policy

Last time I blathered about how important a security policy is, and that it would be hard to write one. Now, I guess I have to pony up with some guidelines on how to do it. The first resource I point people to who want to write a policy is Charles Cresson Wood's tome, "Information Security Policies Made Easy" -- usually referred to as ISPME (Baseline Software, ISBN 1-881585-01-8). What Wood has done in ISPME is list every possible policy he can think of --- my edition has over 600 of them, with each policy is some associated commentary. There are also resource lists as well as a nice introductory chapter to help you get started.

The obvious danger of ISPME is that a lazy author could just grab pieces and slap them together without having any coherent thought or match to the organization's needs. However, the value of ISPME is far greater because it gets the creative juices flowing by giving the policy author some starting points and a language that they can begin to craft into a good policy. ISPME is a little expensive, but if all you've been doing is stare at a blank screen wondering how to get started, then this book is an excellent push.

Even better guidance on the construction of a policy comes in a brief, but well-written, chapter in Brent Chapman and Elizabeth Zwicky's, "Building Internet Firewalls." (O'Reilly & Associates, ISBN 1-56592-124-0, www.ora.com/) The chapter on security policies outlines in brief and understandable technical terms what a policy is, why you need one and how to get started putting one together. Chapman and Zwicky point out some important things that a security policy should contain: clear, explicit and understandable language; expectations and responsibilities from both users and staff; a stick to go along with the policy ("share your password and you're outta here"); and a wrapper which explains how the policy gets reviewed and updated. They also include some good advice on what the policy should not have particularly for the technical people who are their audience: don't include technical details; don't be constrained to do things "because that's the way we've always done them"; and don't borrow someone else's policy and change the names around.

Chapman and Zwicky also include a 17 item list (I won't include it here to inspire you to buy or borrow their book; you should probably have a copy anyway if you're in the firewall business). This list could be your starting point for a security policy: answer all 17 of their questions, and you'll have an excellent outline for your policy. Brent has spent a lot of time consulting at big companies, because of this he is able to offer some wise guidance on how a technical person should approach their CIO/CEO about making the important decisions it will take to write a successful security policy.

To keep you messaging and groupware people satisfied that this isn't turning into a security column, I'll talk about setting up e-mail policies next week. In any case, if you've got advice, questions, or fun horror stories about security or e-mail policies, let me know!

Joel Snyder is a senior partner with Opus One, a consulting firm in Tucson, Arizona. He spends most of his time on the road helping people build larger, faster, better, and more reliable networks. His professional travels have taken him from San Francisco to St. Petersburg, where he always carries his trusty Macintosh and modem, neither of which have cute names. He is also a member of the Network World Test Alliance and writes extensively on networking topics. Reach him at joel.snyder@opus1.com.

A Buyer's Guide to Firewalls
Network World, 6/1/98

Network World Fusion Focus: Secure e-mail for corporate lawyers
Network World Fusion, 9/22/98

Five basic security necessities
Network World, 2/2/98

Security Net Resources: primers and more
Network World Fusion

Archive of Network World on Groupware and Messaging newsletters