Preparing for the CSA Tuning Process
The CSA tuning process is more an art than a science, and you might need some practice before you become efficient. Understanding the points discussed in this section will make you more effective. These include understanding the components of CSA Policy, knowing what protection each rule type provides, and understanding how to use advanced components such as state sets and dynamic application classes. The following sections explain those components and provide a process to follow when you tune or create a custom policy.
Understanding Rule Capabilities
It is imperative that you know the protection provided by each rule type, so that you can quickly write rules without using the Tuning Wizard or researching endlessly. The following is a list of rules most commonly used when tuning. The list is ordered by frequency of use in tuning. You should memorize these components to save time when tuning an environment because memorization greatly simplifies your workload.
-
System API Control— This rule provides many types of protection to hosts and is by far the most common rule tuned in any deployment. This rule applies to processes as defined by the associated application class and can provide the following common protections or exclusions:
- - Inject code into other applications— To function, some applications need to insert themselves or DLL's into other applications. This type of injection can be malicious, however, because viruses often attempt to inject their DLL into a privileged process to gain administrative rights to the system. Be certain that this process is normal before you tune!
- - Write memory owned by other applications— Occasionally applications attempt to use another application's memory space. This is somewhat uncommon but has been seen in off-the-shelf software.
- - Access systems functions from code executing in data or stack space— Although this is a common buffer overflow action and should be treated with care, some applications do this to check their licensing. Verify that this is repeatable and normal through active testing or by confirming with the vendor, then tune appropriately. You can tune this rule granularly through the use of pattern matching, which the Tuning Wizard commonly performs.
- - Trap keystrokes— Some software attempts to capture keystrokes as part of normal behavior. Verify this is not malicious before proceeding.
- - Monitor media devices— You can control which devices in your system control or access media devices, such as video cameras and microphones.
- Application Control— This rule provides the ability to control whether an application is allowed to run. It also controls what applications can start other applications. It is an important rule type, especially when combined with dynamic application classes, which you see later in the chapter in examples of advanced custom policies.
- File Access Control— This rule controls which applications are allowed to read and write files and create directories.
- Network Access Control— This rule controls how a process is allowed to initiate, terminate, or listen for network connections.
Although you will become familiar with several other rule types through daily use of the product, you should completely understand the rule types in the previous list before beginning to tune and create customer policies in your own environment.
Discovering State Sets
State sets provide a level of granularity and control not provided by many other Host Intrusion Prevention System (HIPS) products. Become familiar with two types of state sets: user and system state sets. These sets provide mechanisms that enable a CSA administrator to deploy policy to endpoints that are enforced only when a specific environment is encountered, such as the administrator logging into the system or a specific IP address used by the computer.
User-State Sets Overview
User-state sets are matched on an endpoint when specific users or groups are in use on the system. You can both define as many of these sets as you want and use the state sets that are pre-installed with the CSA MC. These objects allow you to enforce policy that is not normally allowed. The following examples illustrate this, and a sample User-State Set configuration screen is shown in Figure 9-1:
- Administrative access to manual installations— Although your average user might not be able to install software locally, you could allow the administrator to log in and perform the installation. The state set would identify this user account and allow the installation by applying specific allow rules to the system temporarily while the administrator is logged into the system.
- Remote access to the registry— You might use management tools to set registry settings remotely that CSA would normally prevent. You could use a user-state set that matches a specific account or group used to authenticate to the local system and override the preventative policies.
- Administrative CSA control— You might define a rule module that allows the CSA to be viewed or stopped only when the matching state set is active.
)
Figure 9-1 User-State Set Configuration
System State Sets Overview
System state sets are matched on an endpoint when various criteria are matched. There are several reasons to build a system state set, such as identifying when a system is on or off a specific subnet, when the CSA MC is reachable, when an installation is currently in progress, or when your Network Admission Control (NAC) posture token is changed or set among others. The following is a list of common settings that can be used alone or in conjunction to match a specific state and a sample image of what the System State Set configuration screen looks like in Figure 9-2.
- Cisco Trust Agent posture for NAC— You can define a set that matches the various posture settings that NAC provides, such as Healthy, Quarantine, and Infected. You might decide to enforce different rules when the state matches, such as preventing Outlook from opening attachments when NAC has determined the system is infected.
- Security level— If you allow users to see the CSA in the system trays of their computers, you can also allow them to use the security-level selector that allows them to change the setting to Off, Low, Medium, or High. These settings can enforce different policies as defined by the CSA administrator.
- Network address ranges— This identifies the network to which the user is currently attached.
- DNS suffix matching— This identifies the users' DNS suffix, such as ServiceProvider.net, Company.com, and VPN.Company.com.
- Management Center reachable— This matches if the agent determines that the CSA MC can be contacted or not. This is a good way to know if the user is currently connected to your network or not connected. You might use this to enforce restricting inbound connectivity for the system if it is not connected to your network.
- Installation process detected— This matches when a process is placed into the <*Installation Applications> special dynamic application class. This state allows the alteration of the current running policy, so that the installation can continue without too many user-required query responses, if any at all.
)
Figure 9-2 System State Set Configuration Options
Using the combinations of the variables that create system state sets is powerful when building custom policies for your environment. You should try to use these objects when creating policy to ensure granular security policy enforcement as an alternative to creating a policy that is too loose and allows negative actions to occur for all system states. An example of using multiple variables for a system state is determining if a user is VPN-connected. You could match on the system IP address, the DNS suffix, and the CSA MC reachable parameters to determine that a system is connected to authorized VPN concentrators. After this state matches, you can alter the system security policy to allow or deny system functions, such as file transfers or remote control functions if necessary.
Discovering Dynamic Application Classes
Just as state sets can provide great distinction in levels of policy enforced, dynamic application classes can also provide granular policy manipulation. If you use the dynamic application classes effectively and efficiently, you can simplify the amount of work you need to perform and the number of rules you need to create when tuning processes. In addition to simplifying the number of rules required to maintain your environment, dynamic application classes can provide much stronger security to the endpoint. The following examples describe some common uses of dynamic application classes and Figure 9-3 shows the configuration of a dynamic application class.
- Telnet applications— You can automatically add processes to this class when they attempt to access remote IP addresses over TCP/23.
- Limit executable actions after accessing a protected file— You could place processes in a special class after they read or write to a specific folder. You could then limit the capabilities of this process to ensure it cannot transmit files or perform other actions.
)
Figure 9-3 Dynamic Application Class Configuration