Security Policy Components

People often refer to a corporate security policy as if it is a single document. Even in this book I have done that. The truth, however, is that much like TCP/IP is a combination of a number of different protocols, your security policy is actually a combination of any number of specific policies, such as a wireless access policy and an ingress filtering policy. There are common components to all security policies, however, as well as a common methodology to developing your security policies. We are going to look at these components and methodologies.

Where to Start?

As previously mentioned, one of the big reasons to have a security policy is to define where you are and where you want to go. This is a three-step cycle that involves the following components:

Security policy design
Security policy implementation and enforcement
Security policy monitoring and review

Security Policy Design

The first step involves designing your security policy. For all intents and purposes, this is the beginning of the security policy design process. This is where a security policy design committee works to develop the overall policy strategy.

Your security policy design committee should consist of representatives from every aspect of your organization. Upper and middle management, local and remote users, human resources, legal, information technology, the corporate security team, and any relevant data owners and stakeholders should all be represented in the design committee. The reason for this is that whether we like it or not, politics will play a role in virtually all security policies. Ensuring that everyone is represented and has input in the policy design will make it easier politically to enforce the policy down the road.

Designing your security policy begins with a high-level overview that gradually gets more granular as the policy is formulated. To initiate the design of a security policy, you should address the following points:

Identify the critical business resources. For example, you should identify the servers and networks your human resources or financial data is located on.
Identify the critical business policies. Are there any general corporate policies that exist in regard to the resources you have identified?
Identify the threats to the resources. Is unauthorized access an issue for the resources? Could the resources provide access to sensitive or proprietary data? Do you need to secure your wireless access and, by extension, your wireless access hardware and software?
Determine the roles and responsibilities of key personnel in the company or organization. Who is responsible for the resources being addressed by the security policy? Who are the users of the resources being addressed by the security policy? What are the administrators of the resources expected to do? What are the users expected to do?
Determine the type of policies to create. Do you need a wireless access policy? Do you need a remote access policy?

An important aspect of designing a security policy is to conduct a risk analysis. A risk analysis is the process of identifying the threats to your company s assets and the likelihood of those threats being realized (in other words, the risks) as well as identifying cost-effective measures to minimize those risks.

You need to identify where your risks are ”risks to the network, to the resources, and to the data. Risk analysis doesn t mean you need to be a hacker, though. You don t need to identify every single possible method of attack there is. However, you do need to identify the portions of the network that exist, assign a threat rating to each portion, and then apply a level of security to address the threat level. Many security administrators fail to grasp this concept. Not everything needs to be defended like Fort Knox.

The most basic method of risk analysis is to assign one of three levels of risk (sometimes called threat ratings) to your network resources:

Low risk These are systems or data that if compromised would not disrupt the business, cause legal issues, or result in any financial ramifications . The targeted system can be easily rebuilt and cannot be leveraged to provide further access to systems. In many cases, contrary to popular opinion, devices such as bastion hosts could fall into this category.
Medium risk These are systems that if compromised would cause a moderate disruption to the business, minor legal or financial ramifications, or that could be used to provide access to other resources. These systems require moderate effort to restore, and the restoration, too, could be disruptive to the system.
High risk These are systems that if compromised could cause significant disruption to the business and could result in significant legal or financial ramifications. In extreme cases, they could even threaten the safety of personnel. These systems would take significant effort to restore, at a significant disruption and cost to the business.

Assign one of these three risk levels to each network resource, including core network devices, distribution network devices, access network devices, network monitoring devices, network security devices, e-mail systems, network file and print servers, network applications servers (such as DNS or DHCP), data application servers (such as Oracle or SQL), desktop computers, and other network devices not already covered.

When you go to assign risk levels, make sure you think outside of the box. For example, what is the risk level of a DHCP server being compromised? Not high, you say? Consider that it contains a mapping of every single in-use IP address and MAC address on your network. Sounds like spoofing made easy in the wrong hands to me. Once hackers know your IP address scheme and/or the MAC addresses of important systems, it becomes much easier for them to masquerade as that system and potentially compromise your data.

Once you have assigned the risk levels, the next thing to do is identify the types of users you have and then assign what privileges they will have on each system. There are generally five types of users:

Administrators These are trusted internal users responsible for network access. I remember a customer one time asking me what could be done to restrict what the administrators could do on the network. I replied, Better hiring practices. These are your administrators. If you don t trust them, they shouldn t be your administrators.
Privileged internal users These are users with a need for greater access (for example, technicians and help desk staff).
Users These are your general access users.
Partners These are external users with a need to access some resources. This may be access to Enterprise Resource Planning (ERP) systems, websites , or other data. This could also be vendors who provide support.
Others This is everyone else.

Once you have identified and assigned the threat level to your various network resources and then identified the types of users you have and the privileges those users require on your network resources, you can begin writing and building your security policy in preparation of implementing it on your network.

Security Policy Implementation and Enforcement

Once a policy has been designed, it should be implemented and enforced. This last part is particularly critical to the success of any security policy. A security policy is only effective if it can be enforced, including the need to have appropriate repercussions in the event that the policy is not adhered to.

To ensure that you can successfully implement and enforce a security policy, you should ensure that the security policy enhances the business process, not interferes with it. Your security policy should be usable, not only for you but for your users. The quickest way to ensure that your users will attempt to undermine or otherwise not adhere to your security policy is if it makes their daily jobs so difficult that they don t feel like they can effectively perform them. By getting your users involved in the security policy design, you can help prevent this situation from occurring.

Another aspect of ensuring that your security policy can be enforced is to make sure it takes into account local, state, and federal laws. This is where your legal department comes into play. Make sure your legal department reviews all the policies that make up your security policy to ensure not only that they are enforceable but that your organization is not legally liable as a result of anything contained in these policies.

Finally, you absolutely must have upper management s support in order to implement and enforce your security policy. In many cases, the punishment for violating the security policy is termination of employment. You have to have upper management s support in these cases. If people know that violating the security policy has no real punishment attached to it, they will quickly start dismissing the need to adhere to the policy.

Security Policy Monitoring and Review

Finally, you should continuously monitor the performance and effectiveness of the security policy to ensure it is addressing the issues it was designed to address. Remember how I said that your security policy has a beginning? That statement does not imply that there is an end. Once your policy has been designed and implemented, you will need to periodically review it and make changes to it according to the information discovered while monitoring the policy s performance and effectiveness, thus starting the cycle anew.

The review process should include allowing all stakeholders and members of your security policy design committee to provide input on the process. In particular, you should make it a point to pay special attention to the information and feedback your user representatives provide. A measure of just how effective a policy is can often be determined by whether your user community is actively trying to find ways around the policy because it makes their life too difficult.

The Characteristics of a Good Security Policy

All good security policies contain a number of common characteristics. A good security policy must be implemented through the use of system administration procedures, published acceptable-use policies, and other methods as defined in your organization. Your security policy must also be enforceable with security tools, where possible, and with repercussions when actual prevention is not possible. Finally, your security policy must clearly define who is responsible for all aspects of the security policy and the business resources identified in the security policy.

In order for your security policy to adhere to these characteristics, it should consist of the following seven sections:

Overview
Purpose
Scope
Policy
Enforcement
Definitions
Revision History

Security Policy: Overview Section

The overview section should contain a brief explanation of what the security policy addresses and what the problems are. The overview section could also include background information regarding the technology or resources the security policy will address. Details of the security policy are left for further explanation in the other sections. This section is where you briefly explain what the security policy will do.

Security Policy: Purpose Section

The purpose section should explain exactly why the security policy is being created and what the goals of the security policy are. You should be as clear and concise in this explanation as possible to ensure that everyone who reads the security policy will clearly understand the purpose and function of the security policy. This section is where you clearly explain the reason for the security policy.

Security Policy: Scope Section

The scope section should define who the security policy applies to, as well as who is responsible for creating and maintaining the security policy. The scope section should also define what the security policy applies to. This is the section where you identify the resources the security policy was written for.

Security Policy: Policy Section

The policy section is where the actual policy details are addressed. This is the section that clearly explains what the security policy is and what to do to ensure compliance with the security policy. Items such as guidelines, configuration examples, education, training and awareness, backups , and business continuity plans should all be addressed in the policy section. Here are some specific points to address in the security policy section:

Threat definition You should identify what the threats are that exist for the resources the security policy addresses. Identifying the threats ensures that you address how to protect against or deal with those threats.
Resource configuration and guidelines You should provide information about how to configure your resources, including specific configuration examples as much as you can. Also provide specific recommendations and guidelines as well as references to any standards or external documentation and best practices.
User training and education In many cases, the security policy may require that users learn new ways of doing tasks . The security policy should address these training and education needs by identifying the issues and defining the appropriate training and education mechanisms to address these needs.
Administrator training and education Like users, your administrators may require training and education to address learning new technologies or products that may be required by your security policy.
Security notices and warnings (logon banners, and so on) You should have security notices and warnings for all your resources that, at a minimum, establish that there is no expectation of privacy, that unauthorized access is prohibited , and that monitoring of the resources will occur and the use of the resources is consent to monitoring. Ensure that all your security notices and warnings have been reviewed and signed off on by your legal department.
Notification processes You need to define who should be notified and what the notification and escalation process is in the event that a security exploit or event occurs.
Backup and recovery procedures Regardless of how well you plan and attempt to prevent a security incident, it will occur. Your security policy needs to define what your backup and recovery procedures are in the event of a security violation, device failure, or natural disaster.
Business continuity or disaster-recovery plans One of the most important things a security policy can address is how to make sure the business can keep running in the event of a catastrophe or natural disaster. Your security policy should address what to do to ensure that the business gets running as soon as possible after a catastrophe or disaster. Your business-continuity or disaster-recovery plan usually complements the information in your backup and recovery procedures plans.
Physical security requirements Your security policy should also address the physical security of the resources, such as air regulation, temperature, and fire-safety equipment and measures.
Security incident response Practice makes perfect, and planning how to respond to a security violation will make your response much more effective. Let s face it, when it has hit the fan, things are hectic enough that you need something to guide you in your actions. By making the decisions on how to react to security violations before a violation has occurred, you are going to make it that much easier to deal with when a violation happens. In a sense, having the plan ahead of time is like doing fire drills. It makes it that much easier to find the door in all the smoke.

The policy section is where you clearly explain what must be done to comply with the security policy and how to respond in the event that a security incident occurs.

Security Policy: Enforcement Section

The enforcement section is where you define how you plan on enforcing the rules and recommendations from the policy section. This includes defining what software or other mechanisms exist to ensure that the threats identified in the policy do not occur as well as defining the repercussions of violating the security policy. This section is where you define how to make sure the policy is adhered to. Something not to be overlooked in the enforcement section is that a social or administrative method can sometimes be much more cost effective than a technical method. For example, it might be more cost effective to log the websites a user has visited and provide that report to the user s manager than to try to filter out those websites via a technical solution. Often, the best solution to a people problem is not a technical one.

Security Policy: Definitions Section

The definitions section is where you define any terms or concepts you used in the security policy to ensure that everyone understands what was meant . You should also use this section to clarify any acronyms used in the policy.

Security Policy: Revision History Section

The revision history section is where you track all updates and changes made to the security policy. Not only should you document the current date and version of the security policy, but you also need to provide a brief explanation of the changes made to the security policy.