Network documentation must include a security operations guide

You should have documentation for everything on your network, including security. Creating a security operations guide allows you to document every element of your security policies for both users and administrators.

Most of the time, network documentation consists of things like hardware inventories, connection maps, IP addresses, and so on. However, a security operations guide is just as important as the hardware-related documentation. A security operations guide is crucial to your network's well being. Here's what you need to know to create an effective security operations guide.

What's a security operations guide?
Put simply, a security operations guide is a document that clearly defines your network's security-related policies and procedures. Over the years, I've done security-related consulting for a number of organizations. In these real-world environments, I've always found that the organizations that seem to have the best security actually have two security operations guides. One of these guides is intended for the people who are actually in charge of security management. The other is intended for the end users.

The end user security guide
The end user security guide is by far the simpler of the two documents. The first company that I saw publish an end user security guide was a large insurance company. It compiled guides that were 10 to 15 pages long. Each of these guides explained exactly what was expected of employees when it came to security. The employees were then required to sign a form saying that they had received a copy of this guide before they were given a user name and password.

Although I think this company had the right idea, the guides had small print and a lot of legal mumbo jumbo, and were very hard to read. The company may have kept the lawyers happy, but I doubt many employees actually took the time to read and try to understand the guide.

A couple of years later, I was working for a different insurance company. The CIO had just ended a 13-year enlistment with the U.S. Marines. Naturally, the military takes security seriously, and so did this CIO. He also realized that most of the company's employees were not lawyers or IT people. He designed a tough but very effective user-oriented security guide.

It was a one-page document written in large print that outlined basic security policies. I don't remember the exact contents of the document, but it looked something like this:
  • I agree to change my password every 30 days.
  • I will not write my password down or tell it to anyone.
  • The main computer room and the wiring closets found throughout the building are off limits to all non-IT employees. I will not attempt entry into these areas.
  • I will not attempt to gain access to any unauthorized area of the system.
  • I will not attempt to disable the system in any way.
  • I will not install any software onto any computer belonging to the company.
  • I will not attach any unauthorized device to the network.
  • All computer equipment purchases must be authorized by [manager's name] prior to submitting the request to purchasing.
  • I will scan all floppies for viruses using the approved antivirus software.
  • I will not use the company's computer equipment for anything other than official company business.
  • Violating any of these rules will result in the immediate termination of employment!

My list probably doesn't include every rule that was on the form, but there are enough rules here for you to get a good idea of the form's purpose. The form outlined exactly what was required of each employee in plain English. It also explained that any employee found violating these rules would be immediately fired. Finally, the employee was required to sign and date the form in front of a witness before being granted a user name and password.

The administrative security operations guide
An administrative security operations guide is a little tougher to assemble than the user guide. Most people tend to think of security preventing hackers and viruses. While that is certainly true, another aspect of security is protecting users from themselves and protecting the network from users who don't know what they are doing. The end users never see or deal with the vast majority of the security that you put into place. The users must simply follow a few basic rules. You, on the other hand, have to design an elaborate system of defenses. Consequently, the administrative documentation must be a lot longer and more detailed.

The good news is that there's no right or wrong way to create an administrative security operations guide. Every company's needs are different. While one company may need 200 pages of security policies and procedures, a smaller company might be able to get away with five. I'll explain what I like to include in security operations guides. What actually is included is up to you.

Template definitions
When I talk to people about security policies and procedures, they tend to think of things like minimum password lengths and designated logon hours. These are certainly aspects of security policies and should unquestionably be defined in your security operations guide.

However, I try to stay away from statements like "each password should be at least eight characters long." I don't want to apply the same security policies to the IT staff and the rest of the users. The IT staff has a higher level of access than everyone else and needs greater security. Likewise, some servers contain more sensitive information than others and require a greater level of security. Because of these differences, I recommend using security templates.

A security template is a file that contains predefined settings that can be applied to a group policy. You might include a section in your security operations guide that says something like "Administrators use template A. Managers use template B. Users use template C."

You could then define the settings found within each template. This would include password lengths, password expiration times, and all of the other security settings that are applied to a user.

You should also define which templates should be applied to which machines. At the very least, you'll need one template for workstations, one for member servers, and one for domain controllers. If you have application servers, you'll probably also want to create templates for them. Keep in mind that workstation templates should keep users from installing unauthorized software or deleting system files. Domain controller templates should protect Active Directory.

If you've been applying the steps I've described, you've defined which templates get applied to which users and which templates get applied to each machine, and then listed the settings found in each template. One important step is left. If a template's settings were to change, undesirable settings could be applied to users or computers. It's important to check the contents of your template files periodically, and, once a template's integrity has been verified, to use the template to audit the existing settings. Your security operations guide should list how often this task occurs, who conducts the task, to whom the results are presented, and what happens if discrepancies are found.

User rights
Another important aspect of computer security is access control. Normally, permissions to a resource are granted to groups rather than to individual users. Because of this, I recommend including a section in your security operations guide listing all of your groups. The listing should contain a description of the group's permissions and what the requirements are for a user to become a member of the group.

This listing is a lot of work and must constantly be maintained. You'll reap a couple of benefits from having this documented. First, if you have a written copy of what a group's permissions are supposed to be, you can spot check for discrepancies. This is a great way to make sure that no one has tampered with group rights. I also recommend making it policy to run these checks at certain intervals.

The other advantage to this type of documentation is that it gives you ammunition in a fight with a stubborn manager. At one of the companies I used to work for, the manager in the marketing department was on a real ego trip. She demanded that her people be included in all of the security groups. When we told her no, she told us that we had no basis for denying her request. Someone got out our security operations guide, and there, in black and white, were the words "to qualify for membership in the Administrators group, a user must…."

Service packs and hot fixes
Another huge security issue is that of service packs and hot fixes. During my time with the military, someone in my office was dedicated to the task of checking the Microsoft Web site three times a day for new security hot fixes. For civilian life, that's probably a little extreme, but you do need a policy describing how this task will be handled. Because there is no one way for dealing with service packs and hot fixes, you'll have to figure out what is right for your organization. When designing the policy, here are some questions that you must answer:
  • Who checks for new service packs and hot fixes?
  • How often are these checks performed?
  • Are the hot fixes and service packs applied immediately or is there a testing period?
  • If there is a testing period, how are the tests performed?
  • When the patches are applied, which machines get the patches first (if the process isn't automated)?
  • Who applies the patches?
  • Are the patches applied during the day, at night, or on the weekend?

Antivirus software
Obviously, you probably want each machine to run some kind of antivirus software. Your policy needs to state what software is being used and what your policy is for dealing with viruses. These questions will help you come up with a virus policy:
  • What antivirus software is run on the workstations?
  • What antivirus software is run on the servers?
  • What antivirus software is run on your e-mail server?
  • What is the schedule for downloading and installing updates for the virus definition files?
  • Is this process automated or does someone do it manually?
  • If the update process is manual, who is responsible for doing it?
  • When viruses are found, are they quarantined or deleted?
  • What is your policy for users who frequently receive infected e-mail attachments?

Chances are that your e-mail policy is going to be one of the biggest parts of your security operations guide. Here are some basic questions that you can use toward developing your own e-mail policy:
  • Do you allow inbound attachments?
  • Do you allow outbound attachments?
  • If attachments are allowed, is everyone allowed to use them or just certain people?
  • What is the maximum size of a user's mailbox?
  • What happens if an employee uses e-mail for illegal purposes, to threaten or harass someone, or to send or receive pornography, jokes, or other offensive materials?
  • What happens to an employee caught sending bulk e-mail through the company's mail server?
  • Does the company monitor e-mail usage?
  • If so, who does the monitoring, who do they monitor, and how often?
  • Are employees told that the e-mail is monitored, or does the monitoring occur secretly?

Security breaches
One area of your security policy that you'll hope you never have to use is a section on security breaches. While this section might be short, it is of vital importance. Because there are a lot of different types of security breaches, this area will require you to do some thinking. After all, an unauthorized employee entering the computer room could be considered a security breach, just as a hacker breaking into a server would certainly be a breach.

For this section, I recommend thinking of different types of security breaches and how to deal with them. For example, if you catch an unauthorized person in the computer room, your reaction might be to have security escort him or her from the building and terminate employment. If a hacker breaks into a server, you might format the hard drives and restore the server from a backup that was made prior to the security breach. These aren't necessarily recommendations, but they are meant to get you thinking about the kinds of solutions you might enforce.

Physical access
You must also design a policy for the physical security of your equipment. These are the types of questions that your physical security policy might address:
  • Who has access to what rooms?
  • What types of locks are on the doors?
  • Is access restricted to certain days or times?
  • Do you have your equipment's serial numbers on file in case of a theft?
  • Do you have a way of logging who has been in secure areas and when?
  • Who reads the access logs and when?
  • Will you use video surveillance?
  • If so, who changes the tapes and how often are the tapes rotated?

Don't let your conscience be your only guide
You probably noticed that most of the items that I discussed related to the prevention of security breaches by employees. According to both Microsoft and Gartner, insiders are responsible for the majority of security breaches. That doesn't mean your security policy should ignore the possibility of a hack or other type of attack from the outside world, though. You must remain vigilant on all fronts—and a good security operations guide will help you do just that.

Editor's Picks

Free Newsletters, In your Inbox