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 organisations. In these real-world environments, I've always found that the organisations 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 realised 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 unauthorised 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 unauthorised device to the network.
- All computer equipment purchases must be authorised 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!
Name:
Date:
Signature:
Witness:
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 unauthorised 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.
4%
1%
