Creating Behavior Analysis Rule Modules

 < Day Day Up > 

In addition to producing a report as a result of application behavior analysis, the CSA MC server can create a rule module from the reported information. This feature is separately licensed and is not available in the base product. If you have a valid license installed, you will notice a new button at the bottom of the Behavior Analysis Configuration page upon completion of the analysis process: the Import button. (See Figure 11-27.) In addition, you see that all completed analysis jobs in the list display with a status of Policy Ready for Importing, as shown in Figure 11-28.

Figure 11-27. Locating the Import Button


Figure 11-28. Policy Ready for Importing Status


NOTE

The rule module creation feature was named Profiler in previous versions the CSA product.


Importing the Behavior Policy

To import the policy, click the Import button on the configuration page. Once selected, the policy components are imported to the local CSA MC system through the process displayed in Figure 11-29. The import does not only contain a set of rules but also a comprehensive collection of rule modules, various sets, query settings, and groups. The resulting imported rule module displays after the import process completes, as do all imported variables; but at this point, they have not yet been applied to any systems within the architecture. In addition, you must go through a generate rules process to commit all the changes imported into the system.

Figure 11-29. Importing the Rule Module and Variables


NOTE

Notice that the behavior analysis job has a status of Policy Imported after the import has taken place.


Understanding Imported Rule Module Methodology

The rule module that is created as a result of behavior investigation is not automatically deployed to CSA agents. The approach taken with rule modules created by the investigation process follows a different methodology than the other CSA enforcement processes. A typical CSA policy allows all interaction to occur and only prevents what the policy specifically states. In other words, typical CSA policy "allows all" while "preventing specific" actions.

The methodology used by the rule creation process uses the exact opposite process by allowing only the interaction observed by the investigation processes and preventing all other interaction. Because of the extremely strict policies created by this process, the policies are not applied and need to be thoroughly reviewed by qualified personnel.

Reviewing and Tuning the Imported Rule Module and Components

The easiest way to review items that were imported is to perform a search on all items. In the text field for the search, enter the name of the analysis job as the criteria, and then click the Find button. The created rule module and its associated variables will display for review. (See Figure 11-30.)

Figure 11-30. Searching for the Imported Items


NOTE

The rule module created will be named the same as the analysis job, with the word Analysis prepended and the words Rule Module appended.


You can link directly from the search screen to the rule module and from there directly to the included rules. The rules that belong to the module are a combination of access control rules limiting the interaction the application has with the system and the interaction the system has with the application and its data.

As another precaution in the implementation of this new policy, some of the rules created are disabled by default to prevent unnecessary restrictive lockdown of specific system resources. You must understand that the rules created for this discussion were deemed appropriate only as part of the analysis of the specific application alone in a controlled environment. Other applications on the endpoint may require some access to the same resources, whether it is registry keys, COM objects, files, or network services. To verify the rule module created during the earlier illustration using Microsoft Word, refer to the rules created, as shown in Figure 11-31.

Figure 11-31. Created Rule Module


NOTE

The rules contained in Figure 11-31, although based on an actual investigation of the Word application, are not to be misconstrued as a correct rule set for this application. An exhaustive application testing procedure was not followed during this investigation process, and the rule module created is only displayed as a sample of what is to be expected.


The rule module displayed is ordered with allow actions preceding deny actions. The allow actions are the actions observed to occur during the investigation that were determined to be appropriate. The deny actions are those actions that should not occur, because they are determined abnormal interactions. You also can see the several rules that are currently disabled.

NOTE

Throughout the various rules, the application that was monitored is identified in the same manner it was identified in the investigation process. It is identified using the same application class that was created early on in the application behavior investigation process. It is therefore imperative that this application class be as accurate as possible.


Figure 11-32 shows the file access control rule 650. This rule allows applications matched by the Word application class to read a list of several files and directories. An interesting point to understand here is that the rule creation process tends to open up access fairly wide considering the restrictiveness of its charter. To better understand this last statement, review the list of files the application is allowed to read. You see many "blanket" statements within the file set and literals listed in this rule. An example is the literal entry for \\*\Shared\*.ini, which is a loose representation of what was actually viewed occurring. Although only specific INI files were accessed, you are allowed read access to all of them in this example.

Figure 11-32. Understanding the Created Rules (650)


You might want to further restrict this rule based on the information in the Behavior Analysis reports for various resources. Regardless of the approach you decide to take, it is important you understand the types of rules that will be created, the nature of the rules, and the absolute need to verify the rules created before implementation.

You will need to tune many of the rules, if not all of the created rules, to ensure you end up with the policy desired. Not just file access control rules require tuning but also network access control rules and others.

TIP

Always review the rules created to further refine them as necessary. You should also, as with any other new rule module, deploy this module to a pilot group in Test Mode.


As a final note regarding the policies that you create as part of the licensed Rule Module Creation feature, you typically should combine these imported rule modules with other rule modules to round out an endpoint policy. In many cases, you must include application programming interface (API) rules, agent interaction, and agent UI rules as part of a deployed policy, which will not be part of the dynamically created and imported rules.

     < Day Day Up > 


    Cisco Security Agent
    Cisco Security Agent
    ISBN: 1587052059
    EAN: 2147483647
    Year: 2005
    Pages: 145
    Authors: Chad Sullivan

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net