The Role of a Security Policy

All too often, corporate technology initiatives fail due in large part to a lack of planning and consideration of the impact such changes will make on a network. A corporate security initiative is no different. When I was in the Marine Corps, they used to talk about the seven P s: Proper prior planning prevents pretty poor performance. This holds true for networking. You need to plan and prepare before you implement anything. As they say, an ounce of prevention is worth a pound of cure. Your security is part of that prevention. The reason why most initiatives fail is because no one has taken the time to define exactly what the goals of these initiatives are; therefore, no one truly knows what they are working toward. Without that knowledge, you can t possibly know what to do to accomplish your goal. For example, it isn t good enough to simply say that you need a firewall to be more secure. You must define precisely what you want to secure and how you want to secure it. What kind of filtering do you want to put in place? What kind of access do you want to grant users? Do you want to authenticate and log user Internet usage? Only by answering these and other questions and defining explicitly what the goals and objectives are can you truly identify, purchase, and implement a firewall that will actually do what you want it to do.

Two predominant schools of thought exist regarding what a security policy should contain. The first school of thought is that a security policy is an all-encompassing document that should contain the simple commandments and recommendations as well as the detailed specifications and configuration examples. In essence, the security policy is not only the policy but the procedures as well. The second school of thought differs in that it holds that a security policy should contain the simple commandments and recommendations and leave the detailed specifications and configuration examples to additional procedural documentation that may or may not be referred to in the security policy. Both approaches have their pros and cons, and the truth is that either approach will work depending on your environment. The benefit of the all-encompassing security policy is that all your information regarding security and implementation is contained in a single document, thus making it easier to keep track of. A downside of this, however, is that your security policy is much more susceptible to change, because the policy itself must be updated for simple procedural changes. The benefit of the security policy is only the policy method is that your security policy can effectively be written in stone because it leaves the details of how to perform the various tasks to other documents, simply stating what must be done. The downside of this method, however, is that you can wind up having multiple documents containing all your security implementation information, making it more difficult to keep track of everything.

I am going to approach the security policy largely from the all-encompassing method. The reason for this is simple: You have to detail your procedures at some point. Whether you do it in the security policy itself or in additional documents, it must occur. By addressing those points from the all-encompassing perspective, I can make sure we talk about them, and you can decide whether you want to keep them as part of the security policy itself or you want to break the procedures out into other documents. In practice, the all-encompassing approach is better suited for smaller organizations, whereas the separated approach is better suited for large organizations where changing the security policy is a very laborious task.

One Step Further

For you to properly understand the role of a security policy, we need to define some of the terminology used:

• Policies Policies simply state what should occur. For example, a policy might state that all traffic traversing a public infrastructure (such as the Internet) must be encrypted.

• Standards Standards define how something works. For example, as part of the preceding policy, we may require 3DES and IPsec as the standards used.

• Procedures Procedures define how a device will be configured, in accordance to the policies and standards defined for the device. For example, you might have a procedure that defines how to configure 3DES and IPsec on a router that is used to pass data over the Internet so that the data is encrypted.

 

The Purpose of a Security Policy

At its most fundamental, a security policy exists to convey the corporate vision and commitment to security and to define the standards and procedures regarding what is considered acceptable while working with or on corporate resources. Your security policy needs to specify what your corporate standards are. Should all systems be implemented to authenticate against a TACACS+ server? If so, your security policy should mandate that this must occur. Your security policy should also lay out what your corporate security goals are. Is your organization trying to reduce the impact of viruses and worms? Are they trying to mitigate external access threats? If so, don t leave these statements as assumptions or common sense. Write them out and define them. Having a stated corporate security objective can be critical in cases where corporate politics come into play and you have folks who don t want to adhere to the security policy. It allows you to point to a written document signed off by your CEO that tells the user, This is why you need to do what we are asking.

This last point brings up another important element of your security policy ”the fact that for a security policy to have any chance at success, it must have upper management s support, including C-level support. Security is constantly at odds with usability. In some cases, usability is going to win over security. In other cases, security is more important than usability. Without upper management s support, you stand virtually no chance at making changes with users or departments that do not want to sacrifice any usability for increased security.

Security Policies and Problem Users

I once worked at a company that had a particularly problematic user when it came to running virus protection. This individual saw the computer that he used as his computer, and he wasn't interested in anyone telling him what he could do with his computer. According to him, running virus protection per the corporate standards made compiling take too long to perform, so he wasn't going to do it. Because the company lacked any kind of written and enforceable policy, the security team and this individual went round and round on a monthly basis with no progress ever being made, up until the time I left the company. Having the buy in from the R&D director could have put a quick end to the discussion, but no one bothered to get that. Do not underestimate the influence that an executive or director has in ensuring that employees adhere to the corporate security policy.