Creating Policy

Policy means different thing to different people. To security practitioners and auditors, the word policy typically refers to a document that outlines how an organization plans to secure both physical and informational assets. This document is a living document that is ever changing as the business evolves, acquisitions occur, applications are deployed, and systems are installed.

Policy can also refer to the implemented rule sets of a product that is meant to enforce those rules. You will often hear of the rule set implemented by a firewall as the firewall policy. The CSA also implements a policy in the same manner as the firewall. The local CSA agent software monitors system usage and prevents actions requested by the user or system that violate the defined policy. For a review of CSA policy, see Chapter 4, "Understanding CSA Policies, Modules, and Rules."

How Policy Relates to CSA

When speaking of CSA, policy is the centrally defined grouping of rules that identify how systems can be used. This policy is derived from the enterprise security policy document that specifically states how systems are allowed to interact. The security agent policy is a direct mapping of written policy to CSA-defined rules that accomplish the preventive or accepted nature of the written policy statements. The items mapped from the written policy into the CSA enforcement policies relate to approved application lists, approved use of products and systems, and allowed network interaction.

In most environments, written policy cannot be enforced at the endpoint completely, and the enforcement mechanism attempted is simple trust of the user base. It has been proven over and over that whether or not you trust your users to take the correct actions regarding corporate resources, even a single deviation can severely impact the confidentiality, integrity, and availability of your most important data. CSA provides many of the functions necessary to comply with the internally written security policy as well as the externally enforced written policies such as HIPAA.

The First Steps in Policy Creation

To successfully define policy for an organization, you must understand how the company functions daily. You must have detailed knowledge of the information flow among the various entities, partners, and customers. You must also be concerned with locating the company assets from an electronic information perspective. This information must be protected both at rest, when it is stored, and in transit, whether it is being moved or used via remote application.

The three most important concepts relating to security policy creation are as follows:

• Confidentiality Confidentiality is the concept of keeping data and information private and controlled so that only those who should have access can have access. This involves securing storage, transit, and use of this information.

• Integrity Integrity is the concept of maintaining confidence in information and ensuring that it has not been manipulated in an unauthorized way.

• Availability Availability is the concept of making certain that data and data access mechanisms are ready to be used when and where necessary, which requires the access methods and paths to be available.

The CSA and its policies enable you to maintain confidentiality, integrity, and availability. The various rules that are part of the deployed policy can guarantee that applications are used only as designed or allowed, ensure network connectivity and network services are available when necessary to whom and what should require them, and provide a mechanism to prevent unauthorized modification of data. To ensure that the rules created for the CSA deployment are accurate, you must have an approved security policy document on hand at the time of policy creation.

Creating New Policies Versus Using Predefined CSA Policies

The CSA MC includes a number of policies that you can use as a starting point for your own policy development or as the policies installed natively in your architecture. These policies range in their use from base security policies for protecting various operating systems to specifically developed policies that protect and control various types of applications. In most cases, the predefined policies serve as a staring point from which you can fine-tune and further develop them to suit your business needs.

Figure 12-1. Predefined CSA Policies

Brief Review of Policy Component Hierarchy

The CSA hierarchy is important to understand when attempting to efficiently create or modify policies for deployment. The components are rules, rule modules, policies, groups, and hosts. Rules are targeted enforcement mechanisms. This component controls specific interaction on a system. Rules can control whether a file can be accessed by a process, or possibly whether an application can use a certain TCP port for outbound access to the network.

Rule modules are groupings or rules that collectively satisfy a common security enforcement goal. A rule module may group rules that protect a specific operating system from abnormal behavior, or possibly group rules that control how a specific application is allowed to function. Rule modules may also be composed of rules that will be enforced based only on system and user state profiles.

Policies are collections of rule modules. You might have various rule modules that serve many purposes in implementing the enforcement of your written policy. Gathering these rule modules into policies enables you to group rule modules that serve a common pur-pose to be collectively paired with one another and therefore applied to systems as a whole. Policies are applied to groups. Groups take the various policies applied to them and formulate a combined policy from all of the derivative components.

The hosts in the architecture are placed into groups. The hosts inherit the rules within the various assigned group policies and apply them as required on the endpoint, as shown in Figure 12-2. In addition, a host can participate in multiple groups, including the mandatory groups, and combine rules and settings from those groups as well.

Figure 12-2. Combined Hierarchy of a Host

Where to Apply Policies

Polices are best deployed in a manner that will be efficient within your architecture. This means reusing the building blocks rather than recreating new components. Another way to gain efficiency is to group necessary components together that will apply cross platform and to use the mandatory CSA groups effectively. A couple of ways to efficiently deploy and create new policies are to use mandatory groups and the cloning feature.

Using Mandatory Groups

As you learned in Chapter 3, "Understanding CSA Groups and Hosts," with mandatory groups you can implement the pieces of your written security policy that are global in nature. It is important to understand that any policy applied to the mandatory group also becomes mandatory to all members of that group. As part of a combined policy for a host, any rules applied through a mandatory group will be at the top of the list of the rule set when the rule priority is calculated. These rules cannot be overridden by any other less or more restrictive rules. They are what they are, and they are absolutely enforced.

You want to write or use specific rules in your deployment. You should maintain these specific rules regardless of another policy. You might want, for example, to guarantee that no system under CSA agent control can ever use the Telnet protocol on port 23, because it is unencrypted. You could write a network access control list rule to prevent any application from creating a client-side connection to that port and apply it to the mandatory groups. This rule ensures that even another policy that specifically allows an application to use this sort of connectivity is not allowed and that your written policy is maintained. You can also use the various mandatory groups to implement global rules specific to worm prevention and other selectable system application programming interface (API) rule features.

Cloning CSA Components

Sometimes it is best to start with a framework instead of attempting to build a rule module from the ground up. Therefore, CSA provides a cloning feature. Cloning is a method to select an object within the hierarchy and re-create an exact copy with a new name. You can then edit the new object without impacting the integrity or application of the existing object. Cloning can prove useful when creating a similar policy to one that has already been built.

To clone a rule module, follow these steps:

Step 1.	Open the rule module listing from the Configuration menu.
Step 2.	Check the check box associated with the rule module you want to clone.
Step 3.	Click the Clone button at the bottom of the page.
Step 4.	When asked "Are you sure you want to clone this item?" click OK. The newly cloned copy displays at the top of the list. As shown in Figure 12-3, the name of the object is the same as the cloned object except the words Copy of are prepended. The cloned module will also temporarily be designated with <new> immediately trailing the name. Figure 12-3. A Newly Cloned Rule Module
Step 5.	Click the name of the rule module now to rename and modify it appropriately.

You can easily clone certain modules or other objects for testing or for a new purpose. Cloning can save a great deal of time, especially if the objects cloned are complex with a great number of included rules and objects.

NOTE

Cloning only clones the object selected and links that new object to the same included objects as followed by the hierarchy. Cloning one object does not create clones of all additional included objects.

Creating a Simple CSA Policy

To illustrate the work flow required and hierarchy used, this section shows how to create a very basic policy. This section does not cover every step necessary in detail, but it does mention all steps required. To create a test policy, follow these steps:

Step 1.	Create a rule module to provide a location for grouping the rules, as shown in Figure 12-4. Figure 12-4. Step 1: Create and Configure the Rule Module a. Choose Configuration > Rule Modules [Windows] to open the rule module list. b. Click New. Optionally, you can clone a similar module. c. Provide the necessary configuration parameters for a rule module, such as name, description, and operating system. You could select Test Mode here as well because it is a best practice to test new rules before activating them in a production environment to verify that no critical systems are adversely impacted. d. Save the rule module and its changed parameters.
Step 2.	Add the necessary rules to this rule module, as shown in Figure 12-5. Figure 12-5. Step 2: Add and Configure the Rules a. Choose Modify Rules from the Rule Module Configuration page. You are presented with an empty rule set. If you had cloned another rule module, you would see several rules here. b. To add the first rule, choose Add Rule > File Access Control. (You are selecting this rule type only as an example.) c. Configure the rule parameters as necessary for the rule you are adding. d. Repeat as necessary to solidify the rule module. Note To easily add your next rule to the same rule module, use the navigation bar across the top of the rule configuration page to maneuver back to the Rules section. This navigation option is located just below the main navigation bar and just above the rule configuration window.
Step 3.	View the rule set included in the rule module to verify its accuracy, as shown in Figure 12-6. Figure 12-6. Step 3: Verify Rule Set Accuracy a. You can accomplish this task in several ways, but the easiest way to view the rules and their actions is to return to the Rule Module Configuration page and click the Explain Rules quick link. b. Verify that the rules configured appear accurate.
Step 4.	Create a new policy and assign the rule module to it or assign this rule module to a current policy, as shown in Figure 12-7. To add the policy to an existing policy, click the Modify Policy Association quick link on the Rule Module Configuration page to assign it to a known policy. To create a new policy, follow these steps: Choose Configuration > Policies. Click the New button at the bottom of the page. Enter the necessary configuration for this policy, such as name, description, and target architecture. Save the changes. Click the Modify Rule Module Associations quick link. Move the appropriate rule modules from the unattached side of the screen to the attached side of the screen by choosing the modules and clicking the Add or Remove button. Figure 12-7. Step 4: Attach the Rule Module to a Policy
Step 5.	Attach this new policy to a group or groups as necessary for deployment to the users, as shown in Figure 12-8. Figure 12-8. Step 5: Attach the Policy to a Group a. Return to the Policy Configuration page and click Modify Group Associations from the quick links menu. b. Choose the appropriate groups and move them to the right side of the screen by clicking the Add button.
Step 6.	As an optional step, you might need to move hosts into this group for the policy to be pushed to that particular host. Otherwise, view the host or group to verify the policy, rule module, and rules are being displayed as attached, as shown in Figure 12-9. Figure 12-9. Step 6: Verification of Attached Hierarchy
Step 7.	As the final step in this configuration process, you must click Generate Rules to propagate the changes to all necessary hosts in the architecture. (See Figure 12-10.) Figure 12-10. Step 7: Propagate Changes Through Generate Rules

Investigating Predefined Policies

Earlier, you learned that you can use the predefined policies as a starting point in developing your own purpose-driven policy. To better understand what you should expect when building your own policy, you should investigate some of the predefined CSA policies and their composition. This section briefly looks at three native policies to establish your own foundation:

• Base Operating System Protection Windows

• Microsoft Office

• Instant Messenger

Base Operating System Protection Windows Policy

The Base Operating System Protection Windows policy provides various basic protective mechanisms for any supported Windows platform. As shown in Figure 12-11, this policy includes 6 combined rule modules (2 specific to Windows XP) with more than 40 total rules.

Figure 12-11. Base Operating System Protection Windows

Click Explain Rules on the quick links menu to see a screen containing the verbose description of the rules that are combined. The rule modules include various types of rules ranging from agent service control to application control rules and system API rules. You can also use several rules pertaining to file access control to protect the Windows operating system and the local command shell and registry files. This is a very deep policy with many control mechanisms that will serve as an excellent learning tool for a new security administrator.

Microsoft Office Policy

The Microsoft Office policy is application specific and only serves to protect the system from Microsoft Office issues that might arise and to protect the Microsoft Office components from the system. This particular policy only includes a single rule module to accomplish this task. Ten rules are included in the rule module, and consist of the following types, as shown in Figure 12-12:

• COM component access control

• File access control

• Network access control

• Registry access control

Figure 12-12. Microsoft Office Policy

Instant Messenger Policy

The Instant Messenger policy is an application-specific policy geared toward limiting instant messenger applications from being compromised. This policy also only requires a single rule module and just seven rules to accomplish its focused task, as displayed in Figure 12-13. The rules are a combination of network and file access control rules, which use variables where possible. Clicking Explain Rules enables you to view the locations and uses of the variables throughout the configuration. One of the variables used is instant messenger executables. This file set includes msmsgs.exe (Microsoft Messenger), aim.exe (AOL Instant Messenger), and ypager.exe (Yahoo! Instant Messenger). You can easily edit this file set to include other instant messenger applications discovered in your network so that they too benefit from the same protective policy.

Figure 12-13. Instant Messenger Policy