Now that the agent is running in Test mode on the hosts, perform a full battery of tests against the applications running on that host. Try every function and option that is reasonable. Look at the logs on the CSA MC to see what actions ran against an applied policy. Build exceptions for legitimate actions that the applied policies would block.
Create Basic Exception Policies, Modules, and Rules
You need to create exceptions that are evident from the first boot of host systems after the installation of the agent. For example, processes such as mouse and multimedia or special function keyboard drivers appear to be trapping keystrokes, when they are simply monitoring for a combination of hotkeys to be pressed. Build exceptions for these things, so that events that require your attention are not covered up by all these benign events.
The first time you build an exception for a group use the Exception Wizard because it automatically builds the policy, module, and rule, and attaches each one correctly. When using the wizard, build the exception policy based on a custom group that you create for your organization. Doing this makes the rules more easily identifiable. In addition, the rules are retained with the custom group when the CSA MC is updated with newer versions. This issue is discussed in greater detail later in this appendix.
After that, it pays to be able to build exceptions manually, so that the rules can have wildcards where appropriate, and you understand exactly what the exception does. Even though the wizard allows you to modify the rule before it is saved, in most cases, it is easier to create the rule manually from the beginning. With practice, you will find it is actually faster than using the wizard.
Now that the basic system and driver exceptions are built and out of the way, put your applications through their paces with a full battery of system tests. Make an application test plan that details all the commonly used and critical functions of your applications. Test the application according to your plan and make exceptions when needed.
Most office or productivity applications require little tuning. You might need to build some system API control rules to allow buffer overflows in some applications, but these applications generally do not do anything that CSA would find suspicious. Systems management and operations applications are different. These applications require indepth tuning and testing because many of the functions of these applications are in direct violation of some of the default rules. Automated software distribution applications, such as Patchlink or WinInstall, exhibit virus-like behavior to CSA and many of the actions that they take, such as writing to the registry or system directories, are flagged by CSA while in Test mode.
In addition to looking at the logs during application testing, take time to inspect in detail the logs captured over several days or a week. Other applications that you did not test might have caused a warning or alert event, or system backups might cause log events when trying to back up CSA itself on some of your servers. When reviewing the logs, take advantage of the filter options. Filter out duplicates, so that you do not see the same event repeatedly and can see different events that might require exceptions.
Another log review technique is to view the top 10 active hosts and rules from the Status Summary screen. Seeing the top 10 hosts lets you know where to focus your tuning efforts, and knowing the top 10 rules shows you what type of events cause the most alerts. Keep building exceptions based on the top 10 hosts and rules until the log records activities that are out-of-the-ordinary and therefore, either do not take place often, or are actually malicious.
NOTE Repeat the process described in this section several times to make sure that the conversion from Test mode to Protect mode is smooth.
Was this article helpful?