Originally published 24 August 2001. Republished with permission from WatchGuard Technologies, Inc.


Secrets of Security Policy Development Revealed!

by Fred Avolio, Avolio Consulting

I'm hardly the first to cover the topic, but whenever I've written a LiveSecurity article mentioning the need for security policies and the dangers and problems of neglecting policy development, readers have answered back. The e-mails generally follow these lines: “Is there such a thing as a 'typical' policy? What should it cover?” “No one here knows how to write a policy. Where do we begin?” 

I help companies develop their policies. So, at the risk of hurting my business, I will reveal secrets heretofore known only to the "Arch Mages" of Internet Security. (Please don't tell.)

All in the same boat

In the February 2001 issue of the USENIX Organization's ;login, security expert Tina Darmohray said in an editorial that she sees an increasing unwillingness to share professional information. She laments, "Often when I approach colleagues to write about their organization … they are restricted from sharing information, citing how it could somehow reveal trade secrets. This has been the case with Computer Use and Security policies for years."

In my experience, there is only one real reason people won't share security policies: they believe theirs is no good. Nearly everyone is in the "I think our security policy rots" camp, or perhaps even the "I wonder if people can tell by the expression on my face that we don't have a policy" camp.

If you're one of those campers, there are three different solutions to the problem. The first two are uninteresting for our discussion, so I mention them without fleshing them out: 1) You can hire the help of an outside security consultant. 2) You can buy an expensive book with policy templates and samples of real policies.

But let's talk about another option: 3) You can be tough and just do it yourself.

Doing it

Anyone reading this can draft a corporate security policy, using the secrets I reveal in this column. All you need is a bit of guidance, which I provide herein by discussing where to begin, what components are needed, and what procedures to follow. Due to space limitations, my advice is fairly high level, but it should be enough to get you started.

Often, the hardest part of beginning is getting senior management buy-in. Secret #1: You must present security expenditures as a cost of doing business, similar to equipment purchases and postage. If the threat does not seem real to your executives, try explaining in terms of these real world cases caused by lack of a security policy.

After the "go ahead," you need a clear idea of the task at hand, and then a breakdown of that task into manageable pieces. It doesn't matter how many you have or how you do it, as long as it makes sense to you. Secret #2: You can't just "write a security policy" and be done; it is a process.

I like to look at this process as tasks, and break the process down into:

  • selecting the policy development team (8-12 people)

  • assessing business needs

  • assessing risk

  • developing the security policy

Your policy development team should be made up of people who work with your network and the Internet, but come from different functional areas of the company. Each manager in your company has a unique view of the needs and the risks. You need people who know something about the technology, but also some who know about business. Include some people from the trenches, too; there is nothing less useful than a painstakingly documented security policy that, when implemented, makes the shipping department un able to track packages, or blocks the sales reps from network resources they need while on the road.

The most difficult part is the business needs assessment. This is the phase where you determine, "What do we need from the Internet?" The difficult part is centered on the word "need." Notice the word isn't "want." Secret #3: People tend to come up with solutions rather than requirements. Someone states that she requires NetMeeting, when what she really needs is cheap teleconferencing. Someone says, "We need port 2092 allowed through the firewall," when what he really wants is to play a multi-player game on the Internet with friends.

Once you know the business requirements, you have to assess the risks. This involves identifying assets -- anything that is worth something to your company. Assets will include everything from product plans to company phone books, from customer names and credit card numbers, to computer systems and printers. And don't forget the intangibles, such as corporate image and stockholder confidence.

Here is where you can shortcut. Secret #4: On the Internet, 90 percent of the possible threats are the same, no matter who we are. The Code Red worm doesn't distinguish between the company who makes widgets, and a non-profit organization promoting literacy. All those security holes in Microsoft Outlook and Internet Explorer don't become more or less weak depending on who you are. Script kiddies scanning huge IP blocks for their favorite exploit often have no idea who they're attacking. No matter who you are, the vast majority of possible threats you face are identical to the threats every other company faces. The only differences in the risk can be adjusted by some fudge factor, taking into account things such as likelihood of a targeted vs. random attack, the cost to secure, and so on. For example, a site like CIA.gov can expect more intentional attacks than tinyinnocentbusiness.com. An e-commerce site should add extra reinforcement to the server that holds customer credit card records, because that is the company's crown jewels. But overall, you can copy a lot from sample or existing policies (see Resources, below).

Finally, you get to write the policy. Do it in pieces, starting with a "General" or "Root" policy document that refers to every other document you will write. If you want a template, you might try either of these:

Your policy should begin with an introduction that states what you are protecting and how. It will have a "General Policy," or top-level policy. (Remember Secret #4.) Other documents might include the incident response procedures (for more, see "Intruder Alert! … Or Is It?"), acceptable use policies (such as for e-mail; see "Corporate E-mail: What's Your Policy?"), and system administration procedures. In addition, your policy must state how to change the policy, how often it will be reviewed, and by whom.

The Introduction then becomes your To Do list. The first thing "to do" is, assign people to write the drafts. Next to each section, you write, "To Be Written By <NAME GOES HERE>."  Base the sections on other documents, then tailor them for your organization using common sense. The responsible individuals write the individual documents, the group reviews them, and management approves and adopts them.

Secret #5: You cannot get this perfect. Not the first time. Not the hundredth. Everyone involved is fallible. Everything is constantly changing. But a policy with some omissions today is better than a perfect policy never.

Next steps

I am not a Buddhist, but the last secret could come from the life and story of Siddhartha Gautama. Secret #6: Nothing remains the same, everything changes, everything returns. You must review, assess, and make changes. Security is a cycle. Start writing your policy, and join the never-ending story.

Resources

Guides and suggestions

Sample policies



Copyright © 1996 - 2001 WatchGuard Technologies, Inc. All rights reserved.
Legal Notice/Terms of Use