Establishing security policies, guidelines, and procedures is a critical step in securing an infrastructure and its information. The lack of well-designed viable security policies and documents is one of the biggest vulnerabilities many organizations have. Policies put everyone on the same page and make it clear where senior management stands on policy issues. They also set the overall tone and define how security is perceived by those within an organization. Policy must flow from the top. Bill Gates gave us a good example of this when he wrote a memo addressed to all employees in 2002. In this memo, Bill Gates spoke about how security was to become Microsoft's number one priority. What's most important about this story is that Bill Gates did more than just state that security was an objective; he provided a strategic roadmap that detailed how these goals would be met.
Building a policy framework is not easy. Some surveys show that only 40% of companies have written and implemented security policies. Those that haven't stated that their failure to do so was because of not knowing where to start, worries that the policies wouldn't work, and a fear that the policies wouldn't be enforceable. Therefore, the following sections will discuss the types of security policies, how to define appropriate policies, how to deploy policies, and the policy life cycle. After all, nothing lasts forever.
Types of Policies
Policies come in many shapes and sizes. With so many types of policies, how can you keep track of them all? The National Institute of Standards and Technology (NIST) special publication 800-12, the Computer Security Handbook, breaks policies into three broad categories:
Within these categories of policies are many individual policies. Combined, these policies control every aspect of security within an organization. Policies are not technology specific. This type of control is left for lower-level documents such as procedures.
Note
Although the term policies is used generically here, the types of security documents that an organization maintains include policies, standards, baselines, guidelines, and procedures.
Policies should do six things for a company:
It should be noted that most of the preceding items deal with preventing or reducing risk. Therefore, some type of risk assessment is usually performed before policies are created. Nothing happens in a void.
Defining Appropriate Policy
Before beginning the drafting of an actual policy, you'll need to clearly define what the objective of the policy is. You must also determine who the policy applies to, and finally, you must determine who is responsible for the policy. These three key sections are shown next:
When the draft policy is developed, it must be approved by upper management and evaluated to ascertain that the objectives that drove the policy development have been met or exceeded. Following are questions that can be asked to verify this:
Tip
SANS has a great collection of policies templates at www.sans.org/resources/policies. These can help ease the burden of policy creation.
Finally, you will want to build in some means to update and change the policy as needed. This revision history provides a mechanism to control the change process. Policies are like everything else in the world and will require periodic change.
Deploying Policy
After the policies have been created, you will need the help of the entire organization to get them deployed and put in place. Three critical items are needed for success: implementation, employee awareness, and employee buy-in.
Implementation
Rolling out new policy may seem to be no more difficult than dictating the date of expected compliance, but that is not the case. Consider a major change to the authentication and authorization policy. You mandate that everyone must change to complex passwords on the first day of the next month. So, on Monday morning, all your employees attempt to change passwords and many experience problems. The result is that the help desk is flooded with calls and many individuals experience an unproductive morning, waiting to log in and begin work. Policies should be implemented in such a way that the change is gradual, staged, or piloted. Many individuals already have the belief that security policies inhibit work and slow things down, so you want to make sure that any change you make does not contribute to that sentiment.
Employee Awareness
Employees need to know about policy changes and how the changes affect them. Depending on the policy, they may also require training. Human resources and training can help, but it's also up to the security department. Take, for example, a policy that dictates how the Internet is to be used by employees. HR can make employees sign an acceptable use policy, provide training to inform employees on what type of Internet activities are acceptable and unacceptable, and/or place a warning banner on all user computers that make them click through or agree to usage rights each time they access the Internet. This type of control goes a long way in ensuring compliance.
Don't fall into the trap of just writing policies and forgetting about them, because that won't build real security. Also, never think that employees don't watch the actions of management. Policies that have the "do as I say, not as I do" look and feel will never be successful. Management must not only support security policies, but also follow them. Otherwise, don't expect the employees to.
Employee Buy-In
Employee buy-in is another important piece of deploying policy. The individual department heads who are affected by the policy and their employees must buy in to the process. Think of it this way: senior management has determined that strong access control should be used to prevent unauthorized individuals from accessing critical parts of the organization. Therefore, an iris scanner is installed. Because some employees are uncomfortable with having their eyes scanned, and others feel the system is too close to "big brother," these individuals figure out that it's possible to piggyback into the areas by following an authenticated person in while the door is open. So, the zeal of implementing stronger security has actually led to a situation that is not good for the organization and may have opened it up to more potential risk than it originally faced.
By implementing systems that employees will accept and gaining the support of mid management, companies can implement stronger security. These policies go a long way toward showing due care. Due care is the act of analyzing the risks an organization faces and responding to those risks by developing policies and procedures to counter those risks.
Policy Life Cycle
After policy has been implemented, you may think that the job is done, but unfortunately, it is not. The final piece to the policy framework is periodic maintenance, change management, and disposal. Even a good policy won't last forever. Therefore, policies need to be monitored and periodically reviewed. The goal is to make sure the policy is still relevant and applicable. The policy written 10 years ago that prohibited employees from attaching modems to internal computers may still be applicable, but it may need to be updated to include wireless access points (WAPs). Many organizations use some type of change review to examine changes and make sure that they don't cause more problems than they cure. This may be no more than a single meeting that has representatives from those groups affected. After an agreement is reached that the change is needed, the process starts anew because you must again deploy the updated policy, get employee buy-in, and complete awareness training.
Introduction to Assessing Network Vulnerabilities
Foundations and Principles of Security
Why Risk Assessment
Risk-Assessment Methodologies
Scoping the Project
Understanding the Attacker
Performing the Assessment
Tools Used for Assessments and Evaluations
Preparing the Final Report
Post-Assessment Activities
Appendix A. Security Assessment Resources
Appendix B. Security Assessment Forms
Appendix C. Security Assessment Sample Report
Appendix D. Dealing with Consultants and Outside Vendors
Appendix E. SIRT Team Report Format Template