15.1 Security Policies and Procedures

     

Network administrators are truly amazing. They have to master numerous technologies. They must know user environments better than the user , even though they may never use them personally . Most must memorize the layout of server rooms and portions of the corporate network infrastructure. With this incredible amount of information in their brains , there's always the chance that minor details could be forgotten or unimportant housekeeping tasks could be put off. That's simply what happens when network administrators get busy or overloaded.

Overloaded administrators who attempt to perform tasks from memory or rely on their brains to remember to do routine jobs are the enemies of security. Invariably, the tasks that are put off are security-related tasks, such as backing up Audit Logs or verifying current patch levels on servers. These tasks are routine, after all, and there's no current attack or vulnerability to be concerned about. Putting off security- related tasks is unfortunately common and often leads to vulnerable networks and successfully attacked servers. When tasks are delayed and then attempted from memory, this problem could be compounded by tasks being performed incorrectly or incompletely, such as updating a virus scanner but not reenabling it. Although technology is ultimately the vulnerability, human error is directly responsible for many of the computer security problems we experience.

To mitigate the problems of human error when performing security-related tasks, policies and procedures should be developed. They act as documentation to tell administrators exactly what to do and when to do it, as well as what tasks can and cannot be done. These policies and procedures help ensure that complacency does not create vulnerabilities in your network security.

A policy is a high-level statement of requirements. Policies do not define exactly how do to something, but rather they broadly state that something must be done. Policies often come from management or cross-organizational groups with the support of upper management.

A procedure is a repeatable series of steps that define a task. Procedures should naturally flow from well-written policies as the low-level step-by-step processes that actually implement policies. This is the distinction between policy and procedure: policy defines what to do, and procedure defines how to do it.

Some policy references define a third component of overall security policy called standards , which define normal practices. Many organizations consider standards to be part of both policy and procedure. This helps simplify the policy process. For the purpose of this book, I will discuss policy and procedure, which together include standards.

The relationship between policy and procedure is not 1:1. For example, one of your company's security policies may state, "All web clients must authenticate using Windows integrated authentication." Many procedures must be written to configure clients and servers to enforce this policy. Policies are broader in scope and provide direction, while procedures are very focused on accomplishing a specific task.

There are also security standards . Standards are specifications or exact configurations for various elements of your IT infrastructure. They may include software and hardware requirements for computers in different roles or they may work with policies and procedures to define some external control (for example, a standard might dictate how long a procedure takes).

For security considerations, a standard is usually implemented as a baseline ”a beginning configuration for a computer or user based on established policy. Your company may already have a baseline configuration that requires a virus scanner to be installed on all computers, that the latest service packs and hot fixes are installed, and so on. These often vary by computer role but usually have a great deal of commonality across the company.

15.1.1 Benefits of Establishing Security Policies and Procedures

Well-defined security policies and procedures are critical to the total security of the enterprise. As stated before, security is partially a technology problem and partially an administrative problem. The administrative portion of the problem cannot be solved without specific rules, which in this case are our policies and procedures. In helping to solve the administrative portion of the security problem, security policies and procedures provide the following benefits:

Define acceptable behavior

People cannot comply with arbitrary policy unless they know what it is in advance. For example, an administrator cannot tell a user to use a more secure password without having defined parameters for that secure password in advance. The administrator also cannot give different employees different rules about their passwords. Having a policy created in advance allows the administrator to simply refer to that document to ensure that the appropriate rule is applied evenhandedly across the organization.

Provide a forum for collaboration of all interested parties

These parties all have input into the policies, which are formed by consensus. This collaboration often involves upper management, network administration, IT management, and user representatives. This helps to ensure that security policy is well balanced and provides needed security without imposing an undue burden on the users of the secured systems.

Legally assign ownership of actions to appropriate parties

Without clearly documented policies and procedures, a security breach could be argued to be unintentional or without malice . From a legal perspective, you must clearly establish what behaviors are unacceptable in an organization and what liability is associated with noncompliance .

Reduce the likelihood of security breaches

Once policies and procedures are defined and applied throughout an organization, the opportunity for security breaches is severely limited. As long as the policies are implemented as designed, the threats they were designed to reduce remain in check. For example, a policy that states that all firewall software must be updated every 30 days helps reduce security breaches by ensuring that the firewall software is current and can deal with the latest known threats.

Reduce the likelihood of misconfigurations

As I'll show throughout this chapter, administrator-caused misconfiguration is a leading cause of network security holes. Policy is designed to identify those potential holes, and detailed procedures ensure that holes are not created accidentally .

Establish penalties for noncompliance

Unless upper management decides in advance to apply evenhanded penalties for noncompliance with established policy and procedures, they are ineffective . Involving these decision-makers in the policy creation process assures all levels of the organization that the policies are appropriate, fair, and well documented. These decision- makers will ultimately be the ones who must discipline or terminate employees who do not follow these procedures, or enforce whatever penalties are established. Therefore, their involvement from the beginning is beneficial.

There are few downsides to creating security policies and procedures. The one of most concern is the time involved. Because careful examination of computer environments and configurations is required, the creation of these documents can take a very long time and become a costly endeavor. Once created, these documents must be approved by upper management before being put in place, which can consume even more resources. Often upper management presents concerns not previously considered , which will require revision of the documents and another full round of approvals .

15.1.2 Creating Security Policies

The policy creation process is not a simple lockstep process like those for installing and configuring software. Administrative decision-making and documentation are often a lengthy and iterative process.

First, you should decide on a process to follow. Guidelines are available to help you design, document, and implement administrative policies. These include the Microsoft Solutions Framework (MSF) and the Microsoft Operations Framework (MOF), both of which are extensively documented on Microsoft TechNet at www.microsoft.com/msf. The guidelines will help ensure you do not miss any components of planning or implementation while driving toward a solution.

Once you've decided on a strategy for designing the policies, you must assemble a working group. This group should represent all aspects of the policy process and should include representatives of the following functional groups:

Senior management

To provide authorization and support of policies as well as strategic guidance. Management must also agree to enforce any policy created by the body, so their involvement is critical.

Human resources representation

To ensure policies do not interfere with employees' liberties as a whole and to ensure that policy enforcement is possible.

Legal representation

To provide guidance on policies that are designed to provide forensic evidence as well as ensure that proper wording is used.

Network and security administration

To verify that policies can actually be implemented and are specific enough to derive procedures from.

Representative(s) of users affected by the policy

To determine whether policies will interfere with their work.

These teams normally have five to eight members . Too many representatives might bog the group down in debate, and too few might not represent all interests. This number may vary depending on the size of the organization.

Speaking of groups bogging down, there should be provisions in place for "emergency response" working groups that can quickly assemble and make authoritative decisions in times of crisis. For example, if a simple patch can resolve a spreading worm on your network but it takes six weeks for the full process to authorize this patch, there should be a method to immediately decide to take action.

Now that the group is assembled , a decision must be made on the goals and scope of the policy. The goals will define what the policy will do, such as a data privacy policy with a goal of protecting client data from unauthorized access. Most policies also contain a scope statement that clearly defines who the policy applies to and under what specific conditions, if any.

Once the goals and scope of the policy are documented, the policy can be written. Policies should:

Be separate atomic objects

Most companies employ one or two broad policies that encompass all users, and then they write several policies specific to different activities or technologies. For example, you might create one broad policy for handling of sensitive customer data that applies to all employees. Because the loss or compromise of this sensitive data would impact your entire business, the policy should apply to everyone. However, a policy regarding data encryption on portable company laptops is far narrower in scope. Both should be created, but you should avoid trying to group all administrative policy into one large blanket policy.

Be enforceable

It is easy to create a policy that simply cannot be achieved. An example might be, "All data will be secured at all times against all attacks, both known and unknown." While this is a great goal, we cannot create procedures to achieve this goal. Therefore, this is not a policy that can actually be implemented. The administrative resources on the policy team should provide input to ensure the written policy can be implemented with available technology within the current infrastructure.

Balance usability and productivity with security

As I've discussed several times throughout this book, all security is an informed trade-off between usability and security. Realistic analysis should be done to ensure that a policy is not written that stops users from completing their jobs, or that impedes them so that their productivity is significantly impacted.

Be specific

Vague references lead to misinterpretation at all levels and can cause a policy to become unenforceable and potentially backfire. An example might be "No knives or guns can be brought to the workplace" versus "No dangerous objects can be brought to the workplace." The former is specific and easily enforceable, while the latter is completely open to debate and presents an enormous gray area that includes letter openers, screwdrivers, and toothpicks.

Describe the penalties for noncompliance

This is often handled by a lawyer with words similar to "Noncompliance may result in disciplinary action or termination." Management should not approve any policies without specific penalty descriptions, as they have agreed to enforce these policies.

Should not specifically state steps for implementation

Policies are not technology-specific implementation guides; they are high-level administrative documents. The implementation details are documented in procedures, which are discussed in the next section.

Once the policy is created and approved by all members of the policy creation team, it should be made available for review for a brief period. This allows the team to review and possibly incorporate feedback from affected users, management, and other concerned parties. It also gives notice that this policy is being created and will be implemented in the near future. This often has a positive effect, encouraging currently noncompliant users and administrators to become compliant before the written policy provides formal penalties.

The final phase of policy creation is the publication of the policy and handoff to the procedure team. This is the team that will create detailed procedures for the implementation and management of the policy.

Remember that once a policy is created, it should periodically be reviewed to ensure it still reflects the state of the business and the security needs of the organization. A stale policy is sometimes worse than no policy at all. Users and administrators alike will dismiss an inappropriate or stale policy and may apply that dismissal to all policies. Ensuring the continual refreshing of policy actually helps enforce that policy. For that reason, you should consider adding a "seal of freshness" to your policy that requires defined reviews over time and provides for expiration of the policy without such reviews. This provides both business justification for periodic reviews and allows you to plan accordingly .

For more information on creating security policies, consult the SANS Security Policy Project at http://www.sans.org/resources/policies. This web site contains a wealth of information on creating security policies and provides numerous examples of both focused and broad security policies. Reviewing the material available from SANS on security policies should be required for all members of your policy team as the first step in your policy creation process.

15.1.3 Creating Procedures

You already know how to create and follow a procedure. You've read numerous procedures in this book. A documented security procedure is not very different. You simply document the steps necessary to complete the tasks that must be done and verify that these steps satisfy the security policies that you've established.

Creating security procedures is a simple process that can be accomplished by following these steps:

1. Complete the security policy creation and acceptance process. Appropriate security procedures cannot be created until policies are finalized.

2. Examine the security policy to determine what tasks must be accomplished to comply with the policy.

3. Create a top-level procedure that will enforce the policy. This procedure will almost always be broken out into smaller tasks. The application of all tasks defined in the procedure must enforce the associated policy.

4. Document the steps required to accomplish each task. These tasks should be focused and narrowly scoped to ensure their portability. For example, applying ACLs on a file should be defined as its own task to allow this task to be reused for all policies that require ACL application. Often a single task will be broken out into subtasks to provide this portability. Each task should define, at a minimum, the following variables :

   1. User rights and privileges required to accomplish the task. For example, a user who is a member of the Domain Admins group may be required to complete the task.

   2. Number and role of individuals required to complete the task. Many sensitive tasks may require that more than one administrator be present to ensure accountability.

   3. Any other tasks that must be completed before this task, as well as any tasks that must follow the completion of this one. Some tasks, for example, might leave a computer in a semiunprotected state and must be immediately followed by a task that corrects that condition.

   4. The exact steps required to accomplish the task. For example, "Launch ADUC" is a vague step, while "Click Start, click Programs, click Administrative Tools, then click Active Directory Users and Computers" is far more precise. It may seem that these procedures are unnecessarily wordy, but in these cases, it takes far less effort to be precise than to have a task fail due to imprecision. At the very least, links and references for proper tasks should be provided.

5. Verify that the documented tasks, when applied in the defined order, complete the procedure and enforce the written policy. This verification must be done with a variety of computer configurations to ensure it will always work.

6. Obtain senior-level corporate approval (not just IT management approval) to use the defined procedures and require their use as part of standard operating procedures.

   

   Just as with policy, senior-level management approval is critical to procedure creation. Without commitment that the procedure is correct and will be supported by all levels, it could be circumvented or completely ignored by employees. Senior management can also scrutinize the procedures to determine if they cannot apply through contractual relationships such as vendor-based computer management. This type of information may not be known to the procedure creation team, and procedures may not be enforceable universally unless modified by senior management.

   
   

7. Publish the procedures. Procedures cannot be a secret, especially from the administrators who must use them. However, distribution of the procedures may be limited on a need-to-know basis in some cases, such as forensic or auditing practices that might give an attacker useful information. Review of these procedures should be required whenever the tasks are performed.

8. Educate all parties affected by the procedures. This allows confusion to be resolved prior to the procedures being applied and helps ensure smooth application and continued security.

9. Audit the tasks regularly as they're accomplished to ensure the procedures are being followed. Just auditing the result isn't enough ”you must ensure that the actual procedure is being used correctly. Many companies use either video surveillance or direct on-the-job observation to ensure compliance with procedures.

Once you've got your procedures in place, you're ready to securely configure and maintain your environment. You can be reasonably certain that the policies create a secure environment and that the procedures fully implement the policies. However, a good administrator must be ever vigilant. The policies and procedures, when properly implemented and enforced, are great tools. But how can you be certain that they are being implemented correctly? You must monitor your systems and analyze all pertinent activity to ensure it conforms to the policy. Monitoring identifies deviations from policy and procedure as well as alerts you to potentially dangerous conditions. One way to implement this monitoring is through auditing.