Happy New Year! Since this is my first column of 2002, I was thinking about New Year resolutions. Those made me think about corporate security-related resolutions. Some people might promise to back up their data more often or promise to write a business continuity plan for 2002. Those are good resolutions, but if I were going to revisit the security controls in my company, where would I start? Would I start with how my users authenticate to the network, how the data is protected or how the company handles a security event? Somehow, starting in the middle does not seem like a good place.
It's a good idea to take a step back and start at the beginning. In the next series of articles, I will cover the basic foundations of a security infrastructure. So, where do we start? There are six key elements required in a security infrastructure: security policy, user authentication, encryption, access control, audit and administration. The foundation of the security infrastructure starts with the development and adoption of a security policy.
What exactly is a security policy? It's a document (or a set of documents) that describes at a high level the security controls that will be implemented in a company. They are the method of communicating company guidelines to employees. Some companies implement more than one policy to address specific security concerns in the organization. The SANS Security Policy Project contains templates
The main purpose of a policy is to protect your resources. That requires an understanding of what resources need protection (e.g., workstations), what are the threats to those resources (e.g., viruses) and how much protection they need (e.g., antivirus software). These are the basic six steps you need to follow with developing the policy:
- Classify the systems -- This is the first step and probably the most time consuming. It requires doing an inventory of all of the systems, large and small, and determining how they are being used in the organization.
- Determine the security priorities -- The next step is to determine the security priorities for each system. For instance, if you have a Web server, the security priority might be to limit access to only HTTP connections. How this security priority is implemented will be covered in later articles.
- Assign risk factors -- Knowing you need a security policy is one thing, but you (and your employees) need to understand what the risks are if the policy is NOT followed. For instance, if the antivirus policy is not followed, the risk could be to render the corporate e-mail inoperative.
- Define acceptable activities -- This part of the policy addresses not only what activities are acceptable but also what activities are NOT acceptable. For instance, an acceptable activity is to make sure antivirus software is installed on the workstations. An unacceptable activity is to open attachments from unknown sources.
- Provide security awareness training -- Writing policies is important, but you also need to train employees on the policies -- what they are, where they are located and why following the policies is important.
- Determine the administrator of the policy -- Policies need to be updated and revised periodically. But more important, someone needs to enforce the policy. It is like having highway speeding laws but not having anyone to enforce them. Without adequate enforcement, you might as well not have a policy at all.
The next few articles will talk more about security policies, the various types of policies needed and additional tips on how to implement a security policy in your organization.
SANS Security Policy Project -- This is a great resource for "read-to-use" template security policies.
Site Security Handbook -- This handbook is a guide to setting computer security policies and procedures for sites that have systems on the Internet. It lists issues and factors that a site must consider when setting its own policies. It makes some recommendations and gives discussions of relevant areas.
About the author
Mark Edmead CISSP, SSCP, is president of MTE Software Inc. and has more than 22 years of experience in software development, product development and network systems security. He is co-author of the book Windows NT: Performance, Monitoring and Tuning published by McMillan Press. In addition, he has written numerous articles for technical publications and is currently writing a book on Internet security certifications.
This was first published in December 2001