Using Management Center for Cisco Security Agents 6.0 - Automatic Signature Generation [Cisco Security Agent]

Table Of Contents

Automatic Signature Generation

Overview

Basics

Automatic Signature Generation

Preventing Denial of Service Attacks

Stack Recovery

Protected Interfaces

Untrusted vs. Unchanged Payloads

Signature Confidence Levels

Signature Grouping and Tagging

Refining Signatures

Permanent and Expiring Signatures

Offline Agents and Correlated Signatures

Differences Between Signature-based AntiVirus and Automatic Signature Generation

Managing Global and Local Signatures

Managing Global Signatures

Viewing Global Signatures

Global Signatures Operations

Managing Local Signatures

Importing, Exporting, and Upgrading Signatures

Upgrading to Refined Signatures

Upgrading Signatures Due to CSA MC Upgrade

Signature Reporting

Deploying the Signature Feature

Distinguish Legitimate Signatures from False Positives

Use the Wizard to Create Exceptions for Generated Signatures

Use the Event Management Wizard to Allow the Application to Operate

Disabling an Unwanted Correlated Signature

Automatic Signature Generation

Overview

The automatic signature generation feature provides several new functions for hosts running on Windows platforms:

•Automatically generated signatures

•Denial of Service attack protection

•Process stack recovery

The Cisco Security Agent now responds to certain attacks by identifying malicious payloads used in an attack, dynamically creating a signature that represents those payloads, and then using the signature to prevent further attacks from similar payloads.

These automatically generated signatures are intended to catch a variety of attacks, primarily buffer overflows, including highly specific, targeted, and polymorphic ones. Currently, the automatic signature generation feature focuses on protecting LPC and MSRPC interfaces.

The automatic signature generation feature works by using rules that look for categories of suspicious behavior. When suspicious behavior is seen, the rules trigger and suspicious payloads are simultaneously sent to the CSA MC and analyzed by the agent. Once enough similar payloads are received, the agent can create a signature locally to defend one host, or the CSA MC generates a signature based on all the payloads it has received and distributes the signature to all hosts.

Automatic signature generation is effective because it does not rely on static signatures being downloaded at intervals. Signatures are created in real-time and can be distributed to all agents automatically or after they are reviewed by an administrator. CSA MC rules do not need to be generated in order for the signatures to be distributed.

The denial of service (DoS) protection function detects a denial of service attack on an MSRPC or LPC interface. Malicious payloads sent to that interface can be identified and dropped.

If you are using the Stack Recovery action in a System API control set rule, you are configuring the system to try to recover from unhandled exceptions. Stack recovery discards the malicious payload and unwinds the stack to the point where the program was called to process that payload. CSA tries to recover the application by handing the control of execution back to the application under attack instead of allowing it to crash or the exploit to take control.

Note During the process of testing the automatic signature generation feature, CSA automatically generated several signatures that successfully defended against attacks on MSRPC and LPC interfaces. We have included these signatures in the product for the benefit of our customers. Were Cisco not to provide these signatures, the automatic signature generation feature would have dynamically created them for you.

Though Cisco provided some signatures in this release, we will not regularly distribute additional signatures in the future. The automatic signature generation feature creates signatures "on the fly" to protect against immediate attacks. It does not depend on distributed signature updates.

This chapter contains the following sections:

•Basics

–Protected Interfaces

–Automatic Signature Generation

–Preventing Denial of Service Attacks

–Stack Recovery

–Untrusted vs. Unchanged Payloads

–Signature Confidence Levels

–Signature Grouping and Tagging

–Refining Signatures

–Permanent and Expiring Signatures

–Offline Agents and Correlated Signatures

–Differences Between Signature-based AntiVirus and Automatic Signature Generation

•Managing Global and Local Signatures

–Managing Global Signatures

–Managing Local Signatures

–Importing, Exporting, and Upgrading Signatures

•Signature Reporting

•Deploying the Signature Feature

–Distinguish Legitimate Signatures from False Positives

–Use the Wizard to Create Exceptions for Generated Signatures

Basics

This section describes the basic concepts behind automatic signature generation stack recovery, and interface blocking.

Automatic Signature Generation

When an MSRPC or LPC interface is attacked on a host, the local agent retrieves the payload associated with the attack, marks it as "untrusted," and forwards it to the CSA MC. The CSA MC correlates similar untrusted payloads and creates a signature representing the attack. The local agent also correlates the same untrusted payloads and creates its own signature if it has not already received a signature from the CSA MC. The signature is referenced by a signature tag and the signature payload is made up of the substrings common to all the attack payloads.

Once a signature is created, either as a global signature or a local signature, it is associated with the @signatures token. Once associated with the @signatures token, a CSA rule can be written to act on every signature associated with that token the same way. For example, rules in the Firewall - Centrally Managed (desktops), Firewall - Centrally Managed (servers) and Firewall - User Managed policies will drop an incoming attack payload if it matches any of the signatures associated with the @signatures token. This stops the attack for which the signature was generated.

Global and local signatures are created after the number of untrusted payloads received exceeds a configurable threshold. The default configuration for correlating a global signature is after two agents have sent two similar payloads in 1,440 minutes (24 hours). Local signatures are generated after the agent gathers three untrusted payloads within 1,440 minutes.

Globally correlated signatures are distributed to agents when they poll in. If a globally correlated signature is distributed and it matches a locally correlated signature already on the agent, the globally correlated signature replaces the locally correlated signature.

Preventing Denial of Service Attacks

If an MSRPC or LPC interface is attacked continuously without a signature being generated, CSA treats this as a denial of service attack. Future payloads attacking the interface are associated with the @highrisk_signatures token. Once associated with the @highrisk_signatures token, a CSA rule can be written to act on every signature tag associated with that token the same way. For example, rules in the Firewall - Centrally Managed (desktops), Firewall - Centrally Managed (servers) and Firewall - User Managed policies supplied with this release, will drop an incoming attack payload if the payload tag matches any of the signature tags associated with the @highrisk_signatures token. This stops the denial of service attack using that payload.

Signature tags are associated with the @highrisk_signatures token after an MSRPC or LPC interface has triggered local signature correlation a configurable amount of time without success. By default, signature tags are added to @highrisk_signatures after an MSRPC or LPC interface has triggered local signature generation 10 times within the last 30 minutes.

Stack Recovery

"A call stack is a dynamic stack data structure which stores information about the active subroutines of a computer program. This kind of stack is also known as an execution stack, control stack, function stack, or run-time stack, and is often shortened to just `the stack'." (http://en.wikipedia.org/wiki/Call_stack)

If you are using the Stack Recovery action in a System API control set rule, you are configuring the system to try to recover from an unhandled exception. Stack recovery discards the malicious payload and unwinds the stack to the point where the program was called to process that payload. CSA tries to recover the application by handing the control of execution back to the application under attack instead of allowing it to crash or the exploit to take control.

This feature may be appropriate for vital applications that respond to user requests for information but do not process transactions or interact with a database. Allowing non-vital services to fail until a signature can be generated is a more conservative, though still effective, approach to protecting these services safely.

Warning An application saved from crashing using stack unwinding may have some residual corruption. The Stack Recovery feature is not appropriate for protecting database applications, applications that process transactions, or applications that maintain their own record-keeping in order to recover from a failure. If you are not certain of all the behaviors of an application, do not protect it with the stack recovery feature.

Protected Interfaces

Currently, the agent can analyze payloads reaching MSRPC and LPC interfaces.

•MSRPC (Microsoft Remote Procedure Call)

The MSRPC protocol encapsulates various services from Microsoft. These are out-of-the box Microsoft OS interfaces to the network, which can be targeted for attacks.

•LPC (Local Procedure Call)

The LPC protocol is used for inter-process system communications. LPC could be used to elevate privileges of malware or used in a remote exploit.

Both MSRPC and LPC signatures are specific to the targeted application, running on a particular operating system.

Untrusted vs. Unchanged Payloads

Data payloads are gathered by the agent when a System API Control "Set" rule indicates that a payload, matching certain criteria, should be marked either "unchanged" or "untrusted."

Signatures are only generated from "untrusted" payloads. Marking payloads "unchanged" prevents a signature from being created for that payload. If a payload is marked both unchanged and untrusted, the unchanged tag takes precedence and the payload will not be used for signature generation.

Signature Confidence Levels

When a signature is automatically generated, CSA MC assigns it a confidence level of Low by default. When a signature is imported to the CSA MC, its confidence level is imported with the signature. Administrators can change the confidence level assigned to a signature to Low, Medium, or High.

Assigning signatures confidence levels allows them to be associated with data sets that specify signature confidence level. This allows you to create data access control rules (DACLs) that act on the payload based on the confidence level of the signature. For example, you may create a DACL that drops a packet that matches a signature in which you have high confidence or notify the user when a packet matches a signature in which you have low confidence.

DACLs in the Firewall - Centrally Managed (desktops), Firewall - Centrally Managed (servers) and Firewall - User Managed policies, provided with this release, reflect this strategy.

Signature Grouping and Tagging

CSA gives the payload, identified in an attack, a tag which identifies the target of the attack. The tag consists of the operating system under attack, the process being attacked, whether the attack was a buffer overflow or a result of exception handling, the protocol used in the attack, the API, the interface or the port being attacked, and the rule ID which captured the payload.

Payloads with the same tag are grouped together to form a signature. The tag used to compare the payloads become the signature tag. See Viewing Global Signatures for more information about global signature tags.

Refining Signatures

All the common substrings of two or more payloads attacking the same interface, create the signature of an attack. As more payloads attack the same interface, the substrings in the latest payload are compared to the common substrings in the signature. CSA refines the signature by keeping in the signature only the common substrings from the latest payload and the existing signature.

Signatures that are marked Permanent in the Manage Global Signatures dialog cannot be refined.

Permanent and Expiring Signatures

Signatures that "expire" are deleted from CSA MC after a configurable period of time. By default, automatically generated signatures expire. Signatures identified by @signatures expire based on the value of the Expire signatures after X days field in the <Common> area of the Signatures Settings page. The default expiration period is 30 days.

"Permanent" signatures are not deleted from the CSA MC and they are not refineable.

Payloads identified by @highrisk_signatures token expire based on the settings in the "Local" section of the MSRPC and LPC protocol areas of the Signature Settings page. The default expiration period for interfaces identified by @highrisk_signatures is 60 minutes.

See the "Global Signatures Operations" section for more information about how to set signatures as permanent or expiring.

Offline Agents and Correlated Signatures

If an agent can not reach its CSA MC for some reason, it will still benefit from local signature correlation but it will not benefit from globally correlated signatures until it can reach the CSA MC and polls in. The local functionality of an agent will protect the host from buffer overflow, exception handling, and denial of service attacks that use MSRPC and LPC protocols.

Differences Between Signature-based AntiVirus and Automatic Signature Generation

Signature-based AntiVirus protection in this release of CSA is a traditional antivirus security feature. It scans the contents of files and compares the content to a library of known virus signatures. If a file contains a virus, the file is rendered inert by CSA policies which prevent the file from being read, written to, or executed.

All local files are scanned periodically. Some files are scanned when they are opened or closed, based on rules in the AntiVirus - Signature based policies for desktops and servers. Regular updates of virus signature files are required to ensure that AntiVirus properly identifies the latest known viruses residing in files.

The Automatic Signature Generation feature is designed to protect MSRPC and LPC interfaces from buffer overflow and denial of service attacks. As one of these interfaces is being attacked, the Automatic Signature Generation feature dynamically creates a signature that identifies the attack. That signature is then used by rules to prevent other similar attacks.

Automatically generated signatures are created in real time, this feature does not depend on static signatures which you need to download periodically.

Managing Global and Local Signatures

The Signature Settings page is accessible from the CSA MC menu bar by navigating Configuration > Global Settings > Signature Settings. You can use this page to set the values for global and local signature correlation, thresholds to prevent denial of service attacks, globally enable new signatures and other managerial tasks related to signature correlation. The Signature Settings page is only viewable in Advanced Mode.

Figure 14-1 Signature Settings page

The following sections are included in the Signature Settings page:

•Common - This section contains signature settings that are common to all hosts that benefit from automatic signature generation.

The Expire signatures after X days field indicates when a local or global signature expires. By default, signatures correlated locally or globally expire after 30 days.

The Enable new local signatures check box is enabled by default. This allows local signatures to be generated locally. If Enable new local signatures is not selected, then no local signatures are generated.

The Enable new global signatures check box is enabled by default. When Enable new global signatures is enabled, signatures are automatically generated after the MSRPC or LPC correlation thresholds are met and they are assigned a confidence level of Low. Globally enabled signatures are distributed to hosts when they next poll in.

Note If you want new global signatures disabled automatically, select the Enable new signatures checkbox and generate rules on the CSA MC.

•MSRPC - The Correlate untrusted MSRPC payloads received by Cisco Security Agent systems checkbox, turns on untrusted MSRPC payload signature generation. The checkbox is selected by default. The next section determines how many agents within a specific time frame, with similar events for receiving untrusted MSRPC payloads, are required to trigger a global signature correlation. The default is two systems reporting two similar MSRPC payloads within 1440 minutes (24 hours).

The next section for MSRPC signature generation deals only with local payloads associated with Denial of Service (DoS) attacks. Administrators define DoS attacks as a specified number of attacks on an interface, over a specified period of time, without a signature being correlated. Once that threshold is met, future payloads attacking the interface are associated with the @highrisk_signatures token. After a configurable amount of time, the payloads are no longer associated with the @highrisk_signatures token.

By default, an interface is considered receiving a DoS attack if ten payloads are received within 30 minutes and a signature could not be created for the attack; after 60 minutes, the payloads are disassociated with the @highrisk_signatures token.

•LPC - The Correlate untrusted LPC payloads received by Cisco Security Agent systems checkbox, turns on untrusted LPC payload signature generation. The checkbox is selected by default. The next section determines how many agents within a specific time frame, with similar events for receiving untrusted LPC payloads, are required to trigger a global signature correlation for all agents. The default is two systems reporting two similar LPC payloads within 1440 minutes (24 hours).

The next section for LPC signature generation deals only with local payloads associated with Denial of Service (DoS) attacks. Administrators define DoS attacks as a specified number of attacks on an interface, over a specified period of time, without a signature being correlated. Once that threshold is met, future payloads attacking the interface are associated with the @highrisk_signatures token. After a configurable amount of time, the payloads are no longer associated with the @highrisk_signatures token.

By default, an interface is considered receiving a DoS attack if ten payloads are received within 30 minutes and a signature could not be created for the attack, and after 60 minutes, the payloads are disassociated with the @highrisk_signatures token.

•The links labeled Expand all and Collapse all allow you to display or hide all the settings for the <Common>, <MSRPC>, and <LPC> areas of this page.

•The Tasks menu has one menu item. Clicking Manage Global Signatures allows you to see the list of globally correlated signatures and manage them.

Managing Global Signatures

From the Signature Settings page, click the Manage global signatures link under the Tasks menu. This opens the Global Signature Management page. This window contains all the globally generated signatures managed by the CSA MC and all the signatures delivered by default in CSA 6.0.

Figure 14-2 Global Signature Management Page

The Global Signature Management page contains the following columns of information:

•Exploit - This column briefly describes the exploit that generated the signature. It provides the process name, the kind of exploit, the interface that was attacked, and the GUID or port name. (MSRPC signature tags are identified by a Global Unique Identifier (GUID) and an API number. LPC signature tags are identified by a port name and an API number.)

You can click the details link to view the signature tag in an easily readable format along with the common substrings that comprise the signature. See Viewing Global Signatures for more information about the Attack Details dialog.

•Enabled - Enabled signatures are distributed to agents when they poll in. If the Enable new signatures in the <Common> area of the Signature Setting page is selected, globally correlated signatures will be enabled after they are created. By default, globally correlated signatures are enabled.

•Confidence - When a signature is automatically generated, it is assigned a confidence level of Low. The confidence level indicates the likelihood that the generated signature has been derived from a dangerous attack. You can set the confidence level to Low, Medium, or High using the drop down menu.

•Permanent - Permanent prevents the signature from being deleted at the time defined by the Expire signatures after X days field in the <Common> area of the Signature Settings page. If you don't want a signature to be deleted, set Permanent to Yes.

•Source - This indicates whether the signature was automatically generated by CSA rules or whether it was imported from another source.

•Last Updated - This is the date that the signature was added to the global correlation list.

At the bottom of the table is an Operations button and a Refresh button. See the "Global Signatures Operations" section for instructions on how to use these command buttons.

Viewing Global Signatures

To view the details of a global signature follow this procedure:

Step 1 Log on to the CSA MC and switch to Advanced Mode.

Step 2 From the Configuration menu, navigate Global Settings > Signature Settings.

Step 3 Expand the Tasks menu and click Manage global signatures.

Step 4 Find the signature you want to examine and click its details link. The Attack Details page opens.

Step 5 Clicking the signature tag displayed in the Global Signature Management page opens the Attack Details pop-up window; it displays the signature in text format.

Figure 14-3 Attack Details pop-up window

The Attack Details pop-up window provides you with this information:

•The signature tag is displayed in an easily readable format in the top section of the Attack Details pop-up window:

–Platform: The operating system and service pack level on which the application was attacked.

–Process: The name of the application or process that was attacked.

–Violation: This identifies the form of attack. Figure 14-3 shows that the form of this attack was by exception handling.

–Protocol: Indicates if the MSRPC or LPC protocol was used for the attack.

–GUID: This is the Globally Unique Identifier (GUID) of the interface under attack. Clicking the link performs an Internet search for information about this GUID using the Google search engine.

–Port: Name of the LPC port being attacked.

–API Number: Displays the method number within the object.

–Tag: This is the label that identifies this signature.

•Audit Mode: Indicates whether or not this signatures was found by rules running in audit mode. Mousing-over the Yes or No link the link tells you how many systems were running in audit mode.

•Common Payload Substrings: Shows the number of payloads that have been correlated thus far. Clicking the Expand or Collapse link displays or hides the payload substrings that have been correlated.

•Correlating events: Shows you the events in the Event Log which correlated the signature. Clicking the View link displays these events.

Global Signatures Operations

You can also manage the signatures in the Global Signature Management window. To do so, follow this procedure:

Step 1 Log on to the CSA MC as a user with configure privileges and switch to Advanced Mode.

Step 2 From the Configuration menu, navigate Global Settings > Signature Settings.

Step 3 Expand the Tasks menu and click Manage global signatures.

Step 4 Click the check box next to the signature(s) you want to manage.

Step 5 Click the Operations button at the bottom of the Global Signature Management page.

Step 6 Select one of these operations and the list box and click Execute:

•Remove - This operation deletes the signature from the list.

•Enable - This operation allows the signature to be distributed to all agents. This is the same as selecting Yes in the Enable column for that signature.

•Disable - This operation prevents the signature from being distributed to all agents. This is the same as selecting No in the Enable column for that signature.

•Import - This adds signatures to the list of global signatures. After selecting Import, browse to the location of the signature file. Select Importing refinable signatures exported from the same MC if it is appropriate, and click Execute

If you don't select the Importing refinable signatures exported from the same MC, then the RuleID is stripped from the signature when it is re-imported. This prevents the signature from being further refined.

Do not select Importing refinable signatures exported from the same MC when importing signatures generated from one CSA MC to another CSA MC.

If you select Importing refinable signatures exported from the same MC then the same CSA MC will be able to continue to refine the re-imported signature definitions if there are more reported instances of the attack.

•Export - This exports the selected signatures to the local MC. After you have clicked Execute, and confirmed your intention to export the file, you receive a message saying that the export was successful with a link to download the exported signature. Click the link to locate the signature list and save it. Click Done to close the export signature box.

Note If you want to prevent a signature from being further refined by the signature correlation process, export the signature and then re-import it without checking the Importing refinable signatures exported from the same MC.

•Make permanent - Selecting Make permanent, prevents the signature from being deleted at the time defined by the Expire signatures after X days field in the <Common> area of the Signature Settings page. This is the same as selecting Yes in the Permanent column for a signature.

Permanent signatures can still be manually deleted using the Remove operation described previously.

•Make expiring - Selecting Make expiring, allows the signature to expire after the value of the Expire signatures after X days field, in the <Common> area of the Signature Settings page, has been reached. This is the same as selecting No in the Permanent column for a signature.

When a signature is changed from Permanent to Expiring, the signature is deleted based on its creation date, not the date that it was changed from Permanent to Expiring.

•Set confidence - By selecting Set confidence, you can change the confidence level in the signature to Low, Medium, or High. This is the same as choosing Low, Medium, or High in the Confidence column of the signature. When a signature is created, it is automatically given the confidence level of Low.

Clicking Refresh in the Global Signature Management screen updates an open screen with the latest correlated global signatures.

Managing Local Signatures

Local signatures can not be managed individually as global signatures can. A signature that has been generated locally can only be deleted by resetting the local agent.

Caution Resetting the local agent in order to remove local signatures will affect more than just the local signatures; it returns almost all the agent settings to their original state when the agent was installed.

To reset the local security agent, navigate:
Start>Programs>Cisco>Cisco Security Agent>Reset Cisco Security Agent.

Importing, Exporting, and Upgrading Signatures

Signatures can be imported and exported using the operations menu in the Global Signature Management window. See the "Global Signatures Operations" section for more information about importing and exporting signatures.

Upgrading to Refined Signatures

As signatures are refined, they are distributed to the local agent when the agent polls in for updates. Generally, the attributes of the signature tag and the signatures permanence setting are retained if a signature is upgraded.

Globally correlated signatures are distributed to agents when they poll in. If a globally correlated signature is distributed and it matches a locally correlated signature already on the agent, the globally correlated signature replaces the locally correlated signature.

Upgrading Signatures Due to CSA MC Upgrade

How signatures are upgraded from one release of CSA MC to another depends on whether or not the System API Control "Set" rules shipped with CSA MC have changed.

A CSA MC upgrade fully compares new rule modules to existing rule modules with all their dependencies. If there are no differences, the CSA MC re-labels a rule module with the latest version and leaves rule ids intact. If there are any differences between rule modules, CSA MC creates a new module with the new kit version number appended to the name, and puts the new rules there.

Your private exceptions modules are not upgraded, so any signatures you generate would stay refineable.

Signature Reporting

You can generate reports that describe various aspects of signature creation and protection using signatures. See the "Signature Information Detail" section on page 11-19 for the various signature detail reports you can create.

Deploying the Signature Feature

The simplest way to deploy the Automatic Signature Generation feature is to deploy the default Windows Desktop or Windows Server agent kits and then evaluate the signatures that are generated. Then elevate legitimate globally correlated signatures to Medium or High confidence and make exceptions for signatures created from false positives. (A false positive occurs when CSA interprets a benign payload as malicious and creates a signature to prevent that payload from being delivered again.)

The System API control rules that deny an action or terminate a process attempting to access system functions from code executing in data or stack space, or run an exception handling routine, are spread throughout other rule modules or are written by you to protect a particular application.

The default Windows Desktops or default Windows Servers agent kits contain the policies that generate locally and globally correlated signatures after one of those System API rules is triggered. These policies are Firewall - Centrally Managed (desktops), Firewall - Centrally Managed (servers), and Firewall - User Managed.

Distinguish Legitimate Signatures from False Positives

Global signatures are created with a confidence setting of Low. See (confidence levels) for more information. When using the default policies shipped with this release, when a signature of Low confidence is matched to an application's attempt to access system functions from code executing in data or stack space or an application's attempt to handle exceptions, a DACL reports an event but the application's action is allowed.

Use these guidelines to determine of the signature is legitimate or a false positive;

1. Open the CSA MC Event Log and look at the application generating the event. Applications vulnerable to attack are often network servers (for MSRPC) or applications interacting with network servers (for LPC).

2. Examine the information in the matching signature, cross-linked with the Set-Untrusted event. The tag in the Global Signature Management screen (also present in the details of the event) gives you the interface ID (GUID) or LPC interface name, the application name, and the policy violation (exception, buffer overflow, etc). Search the Internet for the GUID to see if it corresponds to a known vulnerability or attack.

3. Return to the CSA MC Event log and examine this host's and this application's other events in close proximity to the signature generation event. Suspicious activity (e.g., an unusual outbound connection or registry modification attempts) suggests that the signature corresponds to a real threat.

After analyzing the events that come from the DACL, if you determine that the signature is legitimate, elevate your confidence in the signature to Medium or High and the application's actions will be denied. See Global Signatures Operations.

If you determine that the signature is a false positive, create an exception to the rule that denied the application's action and disable the global signature. See Use the Wizard to Create Exceptions for Generated Signatures for these procedures.

If there are signatures that have been correlated on the local agent, you can use the Reset Cisco Security Agent feature to remove it. See the "Managing Local Signatures" section.

Use the Wizard to Create Exceptions for Generated Signatures

If you feel that a signature, that has been automatically correlated, is stopping benign traffic, you can use the Event Management Wizard to create an exception in order allow the traffic.

Once the signature has been generated, you need to perform two tasks in order to allow the benign behavior:

1. Use the Event Management Wizard to Allow the Application to Operate. This will prevent a signature from being generated.

2. Disable the globally correlated signature. See Disabling an Unwanted Correlated Signature for more information.

Use the Event Management Wizard to Allow the Application to Operate

Figure 14-4 shows a series of events surrounding a global signature correlation:

Figure 14-4 Signature Generation Event Sequence

•Event 8 shows msrpc_s.exe attempted to call an exception handling routine and the event was denied.

•Event 9 shows that the data payload was marked as untrusted.

Events 8 and 9 are the last events in a series (not shown) that lead up to the correlation of a global signature. Making an exception to the rule that triggered Event 8 would "white-list" msrpc_s.exe and would prevent any other such actions from creating a globally correlated signature.

•Event 10 reports that the CSA MC has generated a signature for an attack on the MSRPC interface; this is the globally correlated signature.

•Event 11 shows that msrpc_s.exe attempted to receive data and that the action was not prevented. This form of event was reported because the rule matched the msrpc_s.exe payload to a correlated signature. This event is able to display the data the msrpc_s.exe collected that ultimately causes the exception handling.

The rule that lead to CSA MC creating a globally correlated signature blocking your application from acting will likely be different from the one in this example. The important thing to remember is to accept the settings suggested by the Event Management Wizard when creating an exception.

Step 1 Log on to the CSA MC as a user with configure privileges.

Step 2 From the Event menu, select Event Log.

Step 3 Click the Wizard link in the rule that triggered the Alert event. In Figure 14-4, this is rule 762 in Event 8.

Step 4 In the Event Management Wizard box, accept the choices offered to you by the wizard:

–Select Classify Application.

–The Application that triggered this event field shows the path to the application you are going to classify.

–In the Action field, accept the setting I trust this application.

–Enter the reason you are creating this exception in the Justification field.

Figure 14-5 Event Management Wizard

Step 5 Click Finish. The global Application Trust Levels list view opens and lists the application which you have just added to the "White List." The application's white-list status will be recognized after you generate rules and the agents poll in to the CSA MC.

Disabling an Unwanted Correlated Signature

Disabling the global signature in order to prevent it from causing CSA to deny benign or desirable actions is a better strategy than deleting the signature right away.

If you delete the signature you lose the payloads and information associated with it. If the global signature is marked as "Expiring" then CSA MC will delete the signature when it expires in 60 days.

See Global Signatures Operations for more information about disabling signatures and setting the expiration setting for a signature.

	Using Management Center for Cisco Security Agents 6.0
	Automatic Signature Generation
Using Management Center for Cisco Security Agents 6.0 Preface Overview Management Center for Cisco Security Agents Administration Configuring Groups and Managing Hosts Building Policies Rule Module Configuration Available Rule Types Using Global Settings Using Application Classes Configuring Variables and State Conditions Event Logging and Alerts Generating Reports Using Management Center for Cisco Security Agents Utilities Using Cisco Security Agent Analysis Automatic Signature Generation AntiVirus Protection Data Loss Prevention Cisco Partner and Third Party Product Integration Using the Scripting Interface (CSAAPI) Cisco Security Agent Overview System Components Open Source License Acknowledgements and Third Party Copyrights	Download this chapter Automatic Signature Generation Download the complete book Using Management Center for Cisco Security Agents V.6.0 (PDF - 8 MB) Table Of Contents Automatic Signature Generation Overview Basics Automatic Signature Generation Preventing Denial of Service Attacks Stack Recovery Protected Interfaces Untrusted vs. Unchanged Payloads Signature Confidence Levels Signature Grouping and Tagging Refining Signatures Permanent and Expiring Signatures Offline Agents and Correlated Signatures Differences Between Signature-based AntiVirus and Automatic Signature Generation Managing Global and Local Signatures Managing Global Signatures Viewing Global Signatures Global Signatures Operations Managing Local Signatures Importing, Exporting, and Upgrading Signatures Upgrading to Refined Signatures Upgrading Signatures Due to CSA MC Upgrade Signature Reporting Deploying the Signature Feature Distinguish Legitimate Signatures from False Positives Use the Wizard to Create Exceptions for Generated Signatures Use the Event Management Wizard to Allow the Application to Operate Disabling an Unwanted Correlated Signature Automatic Signature Generation Overview The automatic signature generation feature provides several new functions for hosts running on Windows platforms: •Automatically generated signatures •Denial of Service attack protection •Process stack recovery The Cisco Security Agent now responds to certain attacks by identifying malicious payloads used in an attack, dynamically creating a signature that represents those payloads, and then using the signature to prevent further attacks from similar payloads. These automatically generated signatures are intended to catch a variety of attacks, primarily buffer overflows, including highly specific, targeted, and polymorphic ones. Currently, the automatic signature generation feature focuses on protecting LPC and MSRPC interfaces. The automatic signature generation feature works by using rules that look for categories of suspicious behavior. When suspicious behavior is seen, the rules trigger and suspicious payloads are simultaneously sent to the CSA MC and analyzed by the agent. Once enough similar payloads are received, the agent can create a signature locally to defend one host, or the CSA MC generates a signature based on all the payloads it has received and distributes the signature to all hosts. Automatic signature generation is effective because it does not rely on static signatures being downloaded at intervals. Signatures are created in real-time and can be distributed to all agents automatically or after they are reviewed by an administrator. CSA MC rules do not need to be generated in order for the signatures to be distributed. The denial of service (DoS) protection function detects a denial of service attack on an MSRPC or LPC interface. Malicious payloads sent to that interface can be identified and dropped. If you are using the Stack Recovery action in a System API control set rule, you are configuring the system to try to recover from unhandled exceptions. Stack recovery discards the malicious payload and unwinds the stack to the point where the program was called to process that payload. CSA tries to recover the application by handing the control of execution back to the application under attack instead of allowing it to crash or the exploit to take control. Note During the process of testing the automatic signature generation feature, CSA automatically generated several signatures that successfully defended against attacks on MSRPC and LPC interfaces. We have included these signatures in the product for the benefit of our customers. Were Cisco not to provide these signatures, the automatic signature generation feature would have dynamically created them for you. Though Cisco provided some signatures in this release, we will not regularly distribute additional signatures in the future. The automatic signature generation feature creates signatures "on the fly" to protect against immediate attacks. It does not depend on distributed signature updates. This chapter contains the following sections: •Basics –Protected Interfaces –Automatic Signature Generation –Preventing Denial of Service Attacks –Stack Recovery –Untrusted vs. Unchanged Payloads –Signature Confidence Levels –Signature Grouping and Tagging –Refining Signatures –Permanent and Expiring Signatures –Offline Agents and Correlated Signatures –Differences Between Signature-based AntiVirus and Automatic Signature Generation •Managing Global and Local Signatures –Managing Global Signatures –Managing Local Signatures –Importing, Exporting, and Upgrading Signatures •Signature Reporting •Deploying the Signature Feature –Distinguish Legitimate Signatures from False Positives –Use the Wizard to Create Exceptions for Generated Signatures Basics This section describes the basic concepts behind automatic signature generation stack recovery, and interface blocking. Automatic Signature Generation When an MSRPC or LPC interface is attacked on a host, the local agent retrieves the payload associated with the attack, marks it as "untrusted," and forwards it to the CSA MC. The CSA MC correlates similar untrusted payloads and creates a signature representing the attack. The local agent also correlates the same untrusted payloads and creates its own signature if it has not already received a signature from the CSA MC. The signature is referenced by a signature tag and the signature payload is made up of the substrings common to all the attack payloads. Once a signature is created, either as a global signature or a local signature, it is associated with the @signatures token. Once associated with the @signatures token, a CSA rule can be written to act on every signature associated with that token the same way. For example, rules in the Firewall - Centrally Managed (desktops), Firewall - Centrally Managed (servers) and Firewall - User Managed policies will drop an incoming attack payload if it matches any of the signatures associated with the @signatures token. This stops the attack for which the signature was generated. Global and local signatures are created after the number of untrusted payloads received exceeds a configurable threshold. The default configuration for correlating a global signature is after two agents have sent two similar payloads in 1,440 minutes (24 hours). Local signatures are generated after the agent gathers three untrusted payloads within 1,440 minutes. Globally correlated signatures are distributed to agents when they poll in. If a globally correlated signature is distributed and it matches a locally correlated signature already on the agent, the globally correlated signature replaces the locally correlated signature. Preventing Denial of Service Attacks If an MSRPC or LPC interface is attacked continuously without a signature being generated, CSA treats this as a denial of service attack. Future payloads attacking the interface are associated with the @highrisk_signatures token. Once associated with the @highrisk_signatures token, a CSA rule can be written to act on every signature tag associated with that token the same way. For example, rules in the Firewall - Centrally Managed (desktops), Firewall - Centrally Managed (servers) and Firewall - User Managed policies supplied with this release, will drop an incoming attack payload if the payload tag matches any of the signature tags associated with the @highrisk_signatures token. This stops the denial of service attack using that payload. Signature tags are associated with the @highrisk_signatures token after an MSRPC or LPC interface has triggered local signature correlation a configurable amount of time without success. By default, signature tags are added to @highrisk_signatures after an MSRPC or LPC interface has triggered local signature generation 10 times within the last 30 minutes. Stack Recovery "A call stack is a dynamic stack data structure which stores information about the active subroutines of a computer program. This kind of stack is also known as an execution stack, control stack, function stack, or run-time stack, and is often shortened to just `the stack'." (http://en.wikipedia.org/wiki/Call_stack) If you are using the Stack Recovery action in a System API control set rule, you are configuring the system to try to recover from an unhandled exception. Stack recovery discards the malicious payload and unwinds the stack to the point where the program was called to process that payload. CSA tries to recover the application by handing the control of execution back to the application under attack instead of allowing it to crash or the exploit to take control. This feature may be appropriate for vital applications that respond to user requests for information but do not process transactions or interact with a database. Allowing non-vital services to fail until a signature can be generated is a more conservative, though still effective, approach to protecting these services safely. Warning An application saved from crashing using stack unwinding may have some residual corruption. The Stack Recovery feature is not appropriate for protecting database applications, applications that process transactions, or applications that maintain their own record-keeping in order to recover from a failure. If you are not certain of all the behaviors of an application, do not protect it with the stack recovery feature. Protected Interfaces Currently, the agent can analyze payloads reaching MSRPC and LPC interfaces. •MSRPC (Microsoft Remote Procedure Call) The MSRPC protocol encapsulates various services from Microsoft. These are out-of-the box Microsoft OS interfaces to the network, which can be targeted for attacks. •LPC (Local Procedure Call) The LPC protocol is used for inter-process system communications. LPC could be used to elevate privileges of malware or used in a remote exploit. Both MSRPC and LPC signatures are specific to the targeted application, running on a particular operating system. Untrusted vs. Unchanged Payloads Data payloads are gathered by the agent when a System API Control "Set" rule indicates that a payload, matching certain criteria, should be marked either "unchanged" or "untrusted." Signatures are only generated from "untrusted" payloads. Marking payloads "unchanged" prevents a signature from being created for that payload. If a payload is marked both unchanged and untrusted, the unchanged tag takes precedence and the payload will not be used for signature generation. Signature Confidence Levels When a signature is automatically generated, CSA MC assigns it a confidence level of Low by default. When a signature is imported to the CSA MC, its confidence level is imported with the signature. Administrators can change the confidence level assigned to a signature to Low, Medium, or High. Assigning signatures confidence levels allows them to be associated with data sets that specify signature confidence level. This allows you to create data access control rules (DACLs) that act on the payload based on the confidence level of the signature. For example, you may create a DACL that drops a packet that matches a signature in which you have high confidence or notify the user when a packet matches a signature in which you have low confidence. DACLs in the Firewall - Centrally Managed (desktops), Firewall - Centrally Managed (servers) and Firewall - User Managed policies, provided with this release, reflect this strategy. Signature Grouping and Tagging CSA gives the payload, identified in an attack, a tag which identifies the target of the attack. The tag consists of the operating system under attack, the process being attacked, whether the attack was a buffer overflow or a result of exception handling, the protocol used in the attack, the API, the interface or the port being attacked, and the rule ID which captured the payload. Payloads with the same tag are grouped together to form a signature. The tag used to compare the payloads become the signature tag. See Viewing Global Signatures for more information about global signature tags. Refining Signatures All the common substrings of two or more payloads attacking the same interface, create the signature of an attack. As more payloads attack the same interface, the substrings in the latest payload are compared to the common substrings in the signature. CSA refines the signature by keeping in the signature only the common substrings from the latest payload and the existing signature. Signatures that are marked Permanent in the Manage Global Signatures dialog cannot be refined. Permanent and Expiring Signatures Signatures that "expire" are deleted from CSA MC after a configurable period of time. By default, automatically generated signatures expire. Signatures identified by @signatures expire based on the value of the Expire signatures after X days field in the <Common> area of the Signatures Settings page. The default expiration period is 30 days. "Permanent" signatures are not deleted from the CSA MC and they are not refineable. Payloads identified by @highrisk_signatures token expire based on the settings in the "Local" section of the MSRPC and LPC protocol areas of the Signature Settings page. The default expiration period for interfaces identified by @highrisk_signatures is 60 minutes. See the "Global Signatures Operations" section for more information about how to set signatures as permanent or expiring. Offline Agents and Correlated Signatures If an agent can not reach its CSA MC for some reason, it will still benefit from local signature correlation but it will not benefit from globally correlated signatures until it can reach the CSA MC and polls in. The local functionality of an agent will protect the host from buffer overflow, exception handling, and denial of service attacks that use MSRPC and LPC protocols. Differences Between Signature-based AntiVirus and Automatic Signature Generation Signature-based AntiVirus protection in this release of CSA is a traditional antivirus security feature. It scans the contents of files and compares the content to a library of known virus signatures. If a file contains a virus, the file is rendered inert by CSA policies which prevent the file from being read, written to, or executed. All local files are scanned periodically. Some files are scanned when they are opened or closed, based on rules in the AntiVirus - Signature based policies for desktops and servers. Regular updates of virus signature files are required to ensure that AntiVirus properly identifies the latest known viruses residing in files. The Automatic Signature Generation feature is designed to protect MSRPC and LPC interfaces from buffer overflow and denial of service attacks. As one of these interfaces is being attacked, the Automatic Signature Generation feature dynamically creates a signature that identifies the attack. That signature is then used by rules to prevent other similar attacks. Automatically generated signatures are created in real time, this feature does not depend on static signatures which you need to download periodically. Managing Global and Local Signatures The Signature Settings page is accessible from the CSA MC menu bar by navigating Configuration > Global Settings > Signature Settings. You can use this page to set the values for global and local signature correlation, thresholds to prevent denial of service attacks, globally enable new signatures and other managerial tasks related to signature correlation. The Signature Settings page is only viewable in Advanced Mode. Figure 14-1 Signature Settings page The following sections are included in the Signature Settings page: •Common - This section contains signature settings that are common to all hosts that benefit from automatic signature generation. The Expire signatures after X days field indicates when a local or global signature expires. By default, signatures correlated locally or globally expire after 30 days. The Enable new local signatures check box is enabled by default. This allows local signatures to be generated locally. If Enable new local signatures is not selected, then no local signatures are generated. The Enable new global signatures check box is enabled by default. When Enable new global signatures is enabled, signatures are automatically generated after the MSRPC or LPC correlation thresholds are met and they are assigned a confidence level of Low. Globally enabled signatures are distributed to hosts when they next poll in. Note If you want new global signatures disabled automatically, select the Enable new signatures checkbox and generate rules on the CSA MC. •MSRPC - The Correlate untrusted MSRPC payloads received by Cisco Security Agent systems checkbox, turns on untrusted MSRPC payload signature generation. The checkbox is selected by default. The next section determines how many agents within a specific time frame, with similar events for receiving untrusted MSRPC payloads, are required to trigger a global signature correlation. The default is two systems reporting two similar MSRPC payloads within 1440 minutes (24 hours). The next section for MSRPC signature generation deals only with local payloads associated with Denial of Service (DoS) attacks. Administrators define DoS attacks as a specified number of attacks on an interface, over a specified period of time, without a signature being correlated. Once that threshold is met, future payloads attacking the interface are associated with the @highrisk_signatures token. After a configurable amount of time, the payloads are no longer associated with the @highrisk_signatures token. By default, an interface is considered receiving a DoS attack if ten payloads are received within 30 minutes and a signature could not be created for the attack; after 60 minutes, the payloads are disassociated with the @highrisk_signatures token. •LPC - The Correlate untrusted LPC payloads received by Cisco Security Agent systems checkbox, turns on untrusted LPC payload signature generation. The checkbox is selected by default. The next section determines how many agents within a specific time frame, with similar events for receiving untrusted LPC payloads, are required to trigger a global signature correlation for all agents. The default is two systems reporting two similar LPC payloads within 1440 minutes (24 hours). The next section for LPC signature generation deals only with local payloads associated with Denial of Service (DoS) attacks. Administrators define DoS attacks as a specified number of attacks on an interface, over a specified period of time, without a signature being correlated. Once that threshold is met, future payloads attacking the interface are associated with the @highrisk_signatures token. After a configurable amount of time, the payloads are no longer associated with the @highrisk_signatures token. By default, an interface is considered receiving a DoS attack if ten payloads are received within 30 minutes and a signature could not be created for the attack, and after 60 minutes, the payloads are disassociated with the @highrisk_signatures token. •The links labeled Expand all and Collapse all allow you to display or hide all the settings for the <Common>, <MSRPC>, and <LPC> areas of this page. •The Tasks menu has one menu item. Clicking Manage Global Signatures allows you to see the list of globally correlated signatures and manage them. Managing Global Signatures From the Signature Settings page, click the Manage global signatures link under the Tasks menu. This opens the Global Signature Management page. This window contains all the globally generated signatures managed by the CSA MC and all the signatures delivered by default in CSA 6.0. Figure 14-2 Global Signature Management Page The Global Signature Management page contains the following columns of information: •Exploit - This column briefly describes the exploit that generated the signature. It provides the process name, the kind of exploit, the interface that was attacked, and the GUID or port name. (MSRPC signature tags are identified by a Global Unique Identifier (GUID) and an API number. LPC signature tags are identified by a port name and an API number.) You can click the details link to view the signature tag in an easily readable format along with the common substrings that comprise the signature. See Viewing Global Signatures for more information about the Attack Details dialog. •Enabled - Enabled signatures are distributed to agents when they poll in. If the Enable new signatures in the <Common> area of the Signature Setting page is selected, globally correlated signatures will be enabled after they are created. By default, globally correlated signatures are enabled. •Confidence - When a signature is automatically generated, it is assigned a confidence level of Low. The confidence level indicates the likelihood that the generated signature has been derived from a dangerous attack. You can set the confidence level to Low, Medium, or High using the drop down menu. •Permanent - Permanent prevents the signature from being deleted at the time defined by the Expire signatures after X days field in the <Common> area of the Signature Settings page. If you don't want a signature to be deleted, set Permanent to Yes. •Source - This indicates whether the signature was automatically generated by CSA rules or whether it was imported from another source. •Last Updated - This is the date that the signature was added to the global correlation list. At the bottom of the table is an Operations button and a Refresh button. See the "Global Signatures Operations" section for instructions on how to use these command buttons. Viewing Global Signatures To view the details of a global signature follow this procedure: Step 1 Log on to the CSA MC and switch to Advanced Mode. Step 2 From the Configuration menu, navigate Global Settings > Signature Settings. Step 3 Expand the Tasks menu and click Manage global signatures. Step 4 Find the signature you want to examine and click its details link. The Attack Details page opens. Step 5 Clicking the signature tag displayed in the Global Signature Management page opens the Attack Details pop-up window; it displays the signature in text format. Figure 14-3 Attack Details pop-up window The Attack Details pop-up window provides you with this information: •The signature tag is displayed in an easily readable format in the top section of the Attack Details pop-up window: –Platform: The operating system and service pack level on which the application was attacked. –Process: The name of the application or process that was attacked. –Violation: This identifies the form of attack. Figure 14-3 shows that the form of this attack was by exception handling. –Protocol: Indicates if the MSRPC or LPC protocol was used for the attack. –GUID: This is the Globally Unique Identifier (GUID) of the interface under attack. Clicking the link performs an Internet search for information about this GUID using the Google search engine. –Port: Name of the LPC port being attacked. –API Number: Displays the method number within the object. –Tag: This is the label that identifies this signature. •Audit Mode: Indicates whether or not this signatures was found by rules running in audit mode. Mousing-over the Yes or No link the link tells you how many systems were running in audit mode. •Common Payload Substrings: Shows the number of payloads that have been correlated thus far. Clicking the Expand or Collapse link displays or hides the payload substrings that have been correlated. •Correlating events: Shows you the events in the Event Log which correlated the signature. Clicking the View link displays these events. Global Signatures Operations You can also manage the signatures in the Global Signature Management window. To do so, follow this procedure: Step 1 Log on to the CSA MC as a user with configure privileges and switch to Advanced Mode. Step 2 From the Configuration menu, navigate Global Settings > Signature Settings. Step 3 Expand the Tasks menu and click Manage global signatures. Step 4 Click the check box next to the signature(s) you want to manage. Step 5 Click the Operations button at the bottom of the Global Signature Management page. Step 6 Select one of these operations and the list box and click Execute: •Remove - This operation deletes the signature from the list. •Enable - This operation allows the signature to be distributed to all agents. This is the same as selecting Yes in the Enable column for that signature. •Disable - This operation prevents the signature from being distributed to all agents. This is the same as selecting No in the Enable column for that signature. •Import - This adds signatures to the list of global signatures. After selecting Import, browse to the location of the signature file. Select Importing refinable signatures exported from the same MC if it is appropriate, and click Execute If you don't select the Importing refinable signatures exported from the same MC, then the RuleID is stripped from the signature when it is re-imported. This prevents the signature from being further refined. Do not select Importing refinable signatures exported from the same MC when importing signatures generated from one CSA MC to another CSA MC. If you select Importing refinable signatures exported from the same MC then the same CSA MC will be able to continue to refine the re-imported signature definitions if there are more reported instances of the attack. •Export - This exports the selected signatures to the local MC. After you have clicked Execute, and confirmed your intention to export the file, you receive a message saying that the export was successful with a link to download the exported signature. Click the link to locate the signature list and save it. Click Done to close the export signature box. Note If you want to prevent a signature from being further refined by the signature correlation process, export the signature and then re-import it without checking the Importing refinable signatures exported from the same MC. •Make permanent - Selecting Make permanent, prevents the signature from being deleted at the time defined by the Expire signatures after X days field in the <Common> area of the Signature Settings page. This is the same as selecting Yes in the Permanent column for a signature. Permanent signatures can still be manually deleted using the Remove operation described previously. •Make expiring - Selecting Make expiring, allows the signature to expire after the value of the Expire signatures after X days field, in the <Common> area of the Signature Settings page, has been reached. This is the same as selecting No in the Permanent column for a signature. When a signature is changed from Permanent to Expiring, the signature is deleted based on its creation date, not the date that it was changed from Permanent to Expiring. •Set confidence - By selecting Set confidence, you can change the confidence level in the signature to Low, Medium, or High. This is the same as choosing Low, Medium, or High in the Confidence column of the signature. When a signature is created, it is automatically given the confidence level of Low. Clicking Refresh in the Global Signature Management screen updates an open screen with the latest correlated global signatures. Managing Local Signatures Local signatures can not be managed individually as global signatures can. A signature that has been generated locally can only be deleted by resetting the local agent. Caution Resetting the local agent in order to remove local signatures will affect more than just the local signatures; it returns almost all the agent settings to their original state when the agent was installed. To reset the local security agent, navigate: Start>Programs>Cisco>Cisco Security Agent>Reset Cisco Security Agent. Importing, Exporting, and Upgrading Signatures Signatures can be imported and exported using the operations menu in the Global Signature Management window. See the "Global Signatures Operations" section for more information about importing and exporting signatures. Upgrading to Refined Signatures As signatures are refined, they are distributed to the local agent when the agent polls in for updates. Generally, the attributes of the signature tag and the signatures permanence setting are retained if a signature is upgraded. Globally correlated signatures are distributed to agents when they poll in. If a globally correlated signature is distributed and it matches a locally correlated signature already on the agent, the globally correlated signature replaces the locally correlated signature. Upgrading Signatures Due to CSA MC Upgrade How signatures are upgraded from one release of CSA MC to another depends on whether or not the System API Control "Set" rules shipped with CSA MC have changed. A CSA MC upgrade fully compares new rule modules to existing rule modules with all their dependencies. If there are no differences, the CSA MC re-labels a rule module with the latest version and leaves rule ids intact. If there are any differences between rule modules, CSA MC creates a new module with the new kit version number appended to the name, and puts the new rules there. Your private exceptions modules are not upgraded, so any signatures you generate would stay refineable. Signature Reporting You can generate reports that describe various aspects of signature creation and protection using signatures. See the "Signature Information Detail" section on page 11-19 for the various signature detail reports you can create. Deploying the Signature Feature The simplest way to deploy the Automatic Signature Generation feature is to deploy the default Windows Desktop or Windows Server agent kits and then evaluate the signatures that are generated. Then elevate legitimate globally correlated signatures to Medium or High confidence and make exceptions for signatures created from false positives. (A false positive occurs when CSA interprets a benign payload as malicious and creates a signature to prevent that payload from being delivered again.) The System API control rules that deny an action or terminate a process attempting to access system functions from code executing in data or stack space, or run an exception handling routine, are spread throughout other rule modules or are written by you to protect a particular application. The default Windows Desktops or default Windows Servers agent kits contain the policies that generate locally and globally correlated signatures after one of those System API rules is triggered. These policies are Firewall - Centrally Managed (desktops), Firewall - Centrally Managed (servers), and Firewall - User Managed. Distinguish Legitimate Signatures from False Positives Global signatures are created with a confidence setting of Low. See (confidence levels) for more information. When using the default policies shipped with this release, when a signature of Low confidence is matched to an application's attempt to access system functions from code executing in data or stack space or an application's attempt to handle exceptions, a DACL reports an event but the application's action is allowed. Use these guidelines to determine of the signature is legitimate or a false positive; 1. Open the CSA MC Event Log and look at the application generating the event. Applications vulnerable to attack are often network servers (for MSRPC) or applications interacting with network servers (for LPC). 2. Examine the information in the matching signature, cross-linked with the Set-Untrusted event. The tag in the Global Signature Management screen (also present in the details of the event) gives you the interface ID (GUID) or LPC interface name, the application name, and the policy violation (exception, buffer overflow, etc). Search the Internet for the GUID to see if it corresponds to a known vulnerability or attack. 3. Return to the CSA MC Event log and examine this host's and this application's other events in close proximity to the signature generation event. Suspicious activity (e.g., an unusual outbound connection or registry modification attempts) suggests that the signature corresponds to a real threat. After analyzing the events that come from the DACL, if you determine that the signature is legitimate, elevate your confidence in the signature to Medium or High and the application's actions will be denied. See Global Signatures Operations. If you determine that the signature is a false positive, create an exception to the rule that denied the application's action and disable the global signature. See Use the Wizard to Create Exceptions for Generated Signatures for these procedures. If there are signatures that have been correlated on the local agent, you can use the Reset Cisco Security Agent feature to remove it. See the "Managing Local Signatures" section. Use the Wizard to Create Exceptions for Generated Signatures If you feel that a signature, that has been automatically correlated, is stopping benign traffic, you can use the Event Management Wizard to create an exception in order allow the traffic. Once the signature has been generated, you need to perform two tasks in order to allow the benign behavior: 1. Use the Event Management Wizard to Allow the Application to Operate. This will prevent a signature from being generated. 2. Disable the globally correlated signature. See Disabling an Unwanted Correlated Signature for more information. Use the Event Management Wizard to Allow the Application to Operate Figure 14-4 shows a series of events surrounding a global signature correlation: Figure 14-4 Signature Generation Event Sequence •Event 8 shows msrpc_s.exe attempted to call an exception handling routine and the event was denied. •Event 9 shows that the data payload was marked as untrusted. Events 8 and 9 are the last events in a series (not shown) that lead up to the correlation of a global signature. Making an exception to the rule that triggered Event 8 would "white-list" msrpc_s.exe and would prevent any other such actions from creating a globally correlated signature. •Event 10 reports that the CSA MC has generated a signature for an attack on the MSRPC interface; this is the globally correlated signature. •Event 11 shows that msrpc_s.exe attempted to receive data and that the action was not prevented. This form of event was reported because the rule matched the msrpc_s.exe payload to a correlated signature. This event is able to display the data the msrpc_s.exe collected that ultimately causes the exception handling. The rule that lead to CSA MC creating a globally correlated signature blocking your application from acting will likely be different from the one in this example. The important thing to remember is to accept the settings suggested by the Event Management Wizard when creating an exception. Step 1 Log on to the CSA MC as a user with configure privileges. Step 2 From the Event menu, select Event Log. Step 3 Click the Wizard link in the rule that triggered the Alert event. In Figure 14-4, this is rule 762 in Event 8. Step 4 In the Event Management Wizard box, accept the choices offered to you by the wizard: –Select Classify Application. –The Application that triggered this event field shows the path to the application you are going to classify. –In the Action field, accept the setting I trust this application. –Enter the reason you are creating this exception in the Justification field. Figure 14-5 Event Management Wizard Step 5 Click Finish. The global Application Trust Levels list view opens and lists the application which you have just added to the "White List." The application's white-list status will be recognized after you generate rules and the agents poll in to the CSA MC. Disabling an Unwanted Correlated Signature Disabling the global signature in order to prevent it from causing CSA to deny benign or desirable actions is a better strategy than deleting the signature right away. If you delete the signature you lose the payloads and information associated with it. If the global signature is marked as "Expiring" then CSA MC will delete the signature when it expires in 60 days. See Global Signatures Operations for more information about disabling signatures and setting the expiration setting for a signature.
	Terms & Conditions \| Privacy Statement \| Cookie Policy \| Trademarks