Using Management Center for Cisco Security Agents 6.0 - Using Global Settings [Cisco Security Agent]

Table Of Contents

Using Global Settings

Overview

Application Trust Levels

Setting Application Trust Levels

Using the Event Management Wizard to Set Trust Levels

Identifying Members of the White List, Grey List, and Black List

AntiVirus Exemptions

Event Correlation

Correlation

Manage Dynamically Quarantined Files and IP Addresses

Signature Settings

Scanning Data Tags

Static Data Tags

Report Configuration

Configuring Reports

Deleting Report Configurations

Using Global Settings

Overview

Management Center for Cisco Security Agents provides configuration tools from the Global Settings section that are used to categorize and apply tags to processes, files, and IP addresses and to correlate events across multiple systems. When tags are applied and certain correlation rules are triggered, the MC registers this occurrence and automatically builds application classes and sends out new process categories to Cisco Security Agents. In some cases, the MC can prevent actions from executing on any additional systems based on noticing the action taking place on a small number of systems. The Cisco Security Agent also scans agent systems for applied tags and can apply rules informing users of data loss possibilities on that basis. This chapter contains these sections:

•Application Trust Levels

–Setting Application Trust Levels

–Using the Event Management Wizard to Set Trust Levels

–Identifying Members of the White List, Grey List, and Black List

•Scanning Data Tags

•AntiVirus Exemptions

•Event Correlation

•Signature Settings

•Scanning Data Tags

•Static Data Tags

•Report Configuration

Application Trust Levels

Application trust levels refer to an application's placement on a "White List," "Grey List," or "Black List." After an application is placed on one of these lists, there are different rules provided in this release that permit or restrict the application from acting.

Applications in the White List are generally trusted and allowed to run, however, they are continuously monitored and if they commit a severe violation, they are immediately restricted.

Applications in the Black List are not trusted and are prevented from running. If they are running, they are terminated. If a user needs to use a black-listed application, then the application must be added to the white list. In such a case, it is recommended that the user adds rules that restrict the application to the minimum set of privileges required.

Applications are placed on the white list, grey list, or black list in one of these ways:

•Administrators place the applications on a list by using the global Application Trust Levels page.

•Some members of a list are static. We have already classified some applications and placed them on one of these lists.

You do not need to ensure that every application on a host is placed on one of these lists.

Setting Application Trust Levels

CSA MC Administrators can add files to the White List, Grey List, and Black List through the global Application Trust Level page.

Step 1 Log on to the CSA MC as a user with configure privileges. This procedure can be performed by users in Advanced Mode or Simple Mode.

Step 2 From the Configuration menu, navigate Global Settings > Application Trust Levels.

Step 3 On the global Application Trust Levels page, click New.

Step 4 In the File Name field, provide the path and filename for the application you are listing. You can use wildcards (**) to generalize the location of the file. For example:

C:\Program Files\Cisco\CSAgent\bin\**\*Indicates every file in every subdirectory of
C:\Program Files\Cisco\CSAgent\bin.

**\Program Files\Cisco\CSAgent\bin\**\*

Indicates every file in every subdirectory of CSAgent\bin no matter what drive it is installed on.

See Using the Correct Syntax, page 2-41 for more information about how to properly use wildcards.

Step 5 In the Trust Level field, select White List, Grey List, or Black List from the pull-down menu.

Step 6 In the OS field, specify the type of operating system this trust specification applies to. Windows indicates any supported Windows platform. UNIX indicates any supported UNIX or Linux platform.

Step 7 In the Justification field, explain why you are creating setting the trust for the application.

Step 8 Click Save. The new trust level designation is displayed on the Application Trust Level page.

Step 9 Generate rules when you are ready to deploy this configuration to hosts.

Using the Event Management Wizard to Set Trust Levels

Step 1 Log on to the CSA MC as a user with configure privileges. This procedure can be performed by users in Advanced Mode or Simple Mode.

Step 2 From the Events menu, select Event Log.

Step 3 Find the event which identifies the process for which you want to set a trust level.

Step 4 Click the Wizard link.

Step 5 In the Classify Application area, note that the Application that triggered this event field is already populated with the directory path and file name of the application.

Step 6 In the Action field, select I trust this application, I am not sure I trust this application, or I do not trust this application. These choices place the application on the White List, Grey List, or Black List, respectively.

Step 7 In the Justification field, explain why you are creating setting the trust for the application.

Step 8 Click Finish. The new trust level designation is displayed on the Application Trust Level page.

Step 9 Generate rules when you are ready to deploy this configuration item.

Identifying Members of the White List, Grey List, and Black List

Applications are assigned to the White List, Grey List, and Black List; they are not added dynamically if a rule triggers.

The White List, Grey List, and Black List are defined by the contents of these application classes: Administrator defined - White List Applications, Administrator defined - Grey List Applications, and Administrator defined - Black List Applications.

Each application class is made up of file sets and has at least one file set that references its own list's token, such as @whitelist, @greylist, and @blacklist. For example, the Administrator defined - White List Applications application class contains the Administrator defined - White List files file set. One component of this file set is defined as any file associated with the @whitelist token. The @whitelist token is defined as any file on the global Application Trust Level page that is described as being on the white list. The Grey List and Black List applications are defined in similar ways.

In order to identify which applications are part of which trust level list, you need to look in two places: in the application class for the trust level and on the Application Trust Level page.

To view the contents of an application class, follow this procedure:

Step 1 Log on to the CSA MC as any user type and switch to Advanced Mode.

Step 2 From the Configuration menu, navigate Applications > Application Classes and search for the Administrator defined - White List Applications, Administrator defined - Grey List Applications, or Administrator defined - Black List Applications application classes.

Step 3 Click the link for the application class. The applications that define this class are listed in the file sets listed in the when created from one of the following executables file sets.

Step 4 Double click a file set to view the applications that belong to it.

To view the applications administrators have assigned to trust lists, follow this procedure:

Step 1 Log on to the CSA MC as a user with any level of privileges and view the CSA MC interface in either Advanced Mode or Simple Mode.

Step 2 From the Configuration menu, navigate Global settings > Application Trust Level. Applications' memberships in trust level lists are clearly identified on the Application Trust Level page.

AntiVirus Exemptions

AntiVirus exemptions can be created for signature-based AntiVirus tags that you have determined to be false positives. Creating an exemption for a tag prevents any files, that have been given the tag, from being restricted by AntiVirus rules that pertain to that tag. Creating an exemption for an individual file, with a particular AntiVirus tag, prevents that file from being restricted by AntiVirus rules that pertain to that tag.

You can create an exception for a virus tag through the Event Management Wizard or through the AntiVirus Exemptions page. See Creating AntiVirus Exemptions Using the Event Management Wizard, page 15-14 and Creating AntiVirus Exemptions Using the Global AntiVirus Exemptions Page, page 15-15 for these procedures.

Here is an example of how an end-user and a CSA MC administrator would be affected by an AntiVirus exemption: Assume that files have been quarantined on various hosts because they have been tagged with an AntiVirus tag. The CSA MC administrator determines that the tag represents a false positive and then creates an exemption for that tag either using the wizard or by hand. The exemption is then listed on the AntiVirus Exemptions page on the CSA MC. When the administrator is ready, he or she generates rules.

The next time the host's CSA polls in to the CSA MC, it receives the AntiVirus exemption information. Within the next minute, any files with that AntiVirus tag that have already been quarantined are removed from the Quarantined files tab of the agent. The files are not put in the Restored tab. The AntiVirus exemption is global and individual users are not given the opportunity to re-classify the file as Quarantined.

To open the AntiVirus Exemptions list page, mouse-over the Configuration menu on the CSA MC and navigate Global Settings > AntiVirus Exemptions. The list page provides these columns of information to describe an AntiVirus exemption:

•Virus: This is the name of the virus as reported in an event or as determined by the Event Management Wizard. It is also the AntiVirus tag name for the virus. The name of the AntiVirus tag specified in the AntiVirus Exemptions page must match the tag attached to a file exactly in order for the file to be exempted from AntiVirus rule restrictions.

•Target: This indicates <All files> if the AntiVirus tag has been exempted, and therefore any file with the tag will be exempted from AntiVirus rule restrictions that pertain to that tag. The Target may also indicate a path to a particular file in order to exempt only that file from AntiVirus rule restrictions. Two wildcards (**) may be specified at the beginning of the directory path to generalize where this file might be found. For example:

**\Documents and Settings\Administrator\Desktop\Temp\virus.doc indicates the virus.doc file on Administrator's desktop.

**\Desktop\Temp\virus.doc indicates virus.doc on any desktop.

•Justification: The field displays the explanation the Administrator provided for creating the exemption.

•Creation time: Indicates the time the exemption was made.

•Source: Indicates the user name that created the exemption and if the exemption was created using the wizard.

•OS: Indicates the operating system for which the exemption pertains.

Event Correlation

The Management Center for Cisco Security Agents lets you enable correlation functions for particular types of events. In each case, you must have a corresponding rule enabled in a policy for the global event correlation to take place. If you do not enable global event correlation, individual events are logged by system agents but similar events across multiple agents are not correlated by the central CSA MC.

Correlation

The Global Event Correlation page, accessible from the menu bar as follows Configuration>Global Settings>Global Event Correlation (see Figure 7-1), provides the following capabilities:

•Correlate network scans

With this checkbox enabled, correlated port scans and ping scans across multiple agent systems are logged separately as a correlated event in addition to the individual port scan and ping scan events that continue to be logged.

Note that you must have a Network shield rule with Port scan detection and Ping scan enabled in a policy deployed to the agent(s) in question for these event types to be detected and logged.

The threshold and time frame for correlating network scans are values you can configure.

•Correlate events received from operating system event logs and generate a summary event

•Log individual events in addition to summary event

With this checkbox enabled, events from multiple systems are correlated based on the NT event code, NT event severity, NT event source, and NT event log type. If 2 systems log the same NT event type within 30 minutes, a correlated summary event is logged.

Note that you must have an NT event log rule in a policy deployed to the agent(s) in question for these events to be uploaded to the CSA MC log.

If you do not enable this checkbox, NT event correlation does not take place, but individual NT events are logged in accordance with the NT event log rule you have configured.

Note In this case, there is an additional checkbox (Log individual events in addition to summary events) to control whether the individual events are logged in addition to the summary event. If you do not enable this checkbox, but you do enable the Correlate events checkbox, only correlated summary events will log, NOT individual events. This can be useful if NT event log messages are filling up your CSA MC logfile.

•Correlate suspected virus application events and add contaminated files to list of dynamically quarantined files

With this checkbox enabled, when processes are added to the dynamic <Suspected Virus Applications> application class (see Built-in Configurable Application Classes, page 8-7) and this event is logged across multiple agent systems, these events are correlated and the contaminated file that triggered the event is added to a dynamic list of quarantined files that CSA MC maintains. If you have a rule configured to stop dynamically quarantined files in a deployed policy, no further agents can access the contaminated file. See page 6-23 for information on using @dynamic in File access control rules.

If you do not enable this checkbox, suspected virus correlation does not take place, but individual virus events are logged.

Note that you must have a corresponding policy deployed to the agent(s) in question for these event types to be detected and logged.

•Correlate events received from virus scanners and add contaminated files to list of dynamically quarantined files

With this checkbox enabled, events logged by virus scanners running on agent systems are received and correlated by CSA MC. Contaminated files detected by virus scanners are added to the list of quarantined files. If you have a rule configured to stop access to dynamically quarantined files in a deployed policy, no further agents can receive the contaminated file. See page 6-23 for information on using @dynamic in File access control rules.

Note This feature works with Norton, McAfee, and Trend AntiVirus. To receive these virus events, you must have an NT event log rule in a policy deployed to the agent(s) in question for these events to be uploaded to the CSA MC logfile. In the NT event log rule, you must enter the name of the antivirus software in the Event Source field. See NT Event Log, page 6-57 for details.

The threshold and time frame for correlating events received from virus scanners are values you can configure.

Note To view the files that are added to the dynamically quarantined files list, click the numbered link beside dynamically quarantined files. It takes you to the pertinent event log messages. Read the messages there to locate the names of quarantined files. You can also click the Manage dynamically quarantined files link at the bottom of the page.

•Correlate communications with untrusted hosts and add peer addresses to list of dynamically quarantined IP addresses.

With this checkbox enabled, when the "Set" action is used in a rule to mark a host address as Untrusted (globally) (see Using the Set Action, page 5-25) and this event is logged across multiple agent systems, these events are correlated and the untrusted peer address that triggered the event is added to a dynamic list of quarantined IP addresses that CSA MC maintains. If you have a rule configured to stop dynamically quarantined IP addresses in a deployed policy, no further agents can communicate with this peer address. See page 6-23 for information on using @dynamic in Network access control rules.

If you do not enable this checkbox, untrusted host correlation does not take place, but individual untrusted host events are logged.

Note You must have a corresponding policy deployed to the agent(s) in question for these event types to be detected and logged.

Note To view the IP addresses that are added to the dynamically quarantined addresses list, click the numbered link beside dynamically quarantined IP Addresses. It takes you to the pertinent event log messages. Read the messages there to locate the quarantined IP addresses. You can also click the Manage dynamically quarantined IP addresses link at the bottom of the page.

Manage Dynamically Quarantined Files and IP Addresses

You can use the @dynamic token in the File set text field and in the Network address set text field where they are available in rules to control access to files and addresses that have been quarantined by CSA MC. Files are quarantined as a result of suspected virus application events, correlated virus scanner log messages, or files that were added manually. This list updates automatically (dynamically) as logged quarantined files are received. Addresses are quarantined as a result of communication with a suspected untrusted host (this updates dynamically) or by being added manually.

To view the files that are added to the dynamically quarantined files list and to manually add files to be quarantined, click the Manage dynamically quarantined files link on the Global Event Correlation page. See Figure 7-2. Add and Remove files from this list using the provided buttons on the bottom of the window that appears.

To view the addresses that are added to the dynamically quarantined IP addresses list and to manually add addresses to be quarantined, click the Manage dynamically quarantined IP addresses link on the Global Event Correlation page. Add and Remove IP addresses from this list using the provided buttons on the bottom of the window that appears. See Figure 7-3. The "Source" column in this window describes how the address was added to the list (manually by the administrator or through a correlation event).

Changes made to the quarantined file and IP address lists are not received by agents until they next poll in to the management center. You can send a hint message to hosts to poll in sooner than the set interval. See Configuring Groups, page 3-4 for poll hint details.

Confidence Ratings

When you click the Manage dynamically quarantined files and IP addresses links, items that are not added manually by the administrator, but are added automatically through event correlation will have a "high" or a "low" confidence rating. This rating indicates the "danger" likelihood of the item that has been quarantined. This rating is based on the detected file type and the network protocol involved.

Note The events to quarantine a specific file or address are subject to event suppression like other components on the system. Duplicate correlation events are suppressed for one hour. This means that a given object can be quarantined, at most, once an hour.

Figure 7-1 Global Event Correlation Page

Figure 7-2 Quarantine Files Window

Figure 7-3 Quarantine IP Addresses Window

Signature Settings

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 following sections are currently included in the Global Signature Settings page:

•Common - This section contains common signature settings. This includes an expiration time for global and local signatures and a check box to control whether new global signatures are immediately distributed to all agents. The default setting is that the Enable new signatures check box is not selected and signatures expire in 30 days.

When the Enable new signatures check box is not selected, signatures are automatically generated after the MSRPC or LPC correlation thresholds are met but they are not automatically distributed to agents. You must individually enable signatures in the Manage global signatures page when the Enable new signatures checkbox is not selected.

If the Enable new signatures checkbox is selected, signatures are automatically generated after the MSRPC or LPC correlation thresholds are met and the signatures are distributed to all hosts when they next poll in.

Note If you want new signatures enabled 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.

For more information about how to manage global signatures and local signatures, and how these settings are used when administering the automatic signature generation feature, see Chapter 14, "Automatic Signature Generation".

Scanning Data Tags

Scanning Data Tags represent text-matching patterns and built-in number patterns. If a rule triggers file scanning, CSA searches the file for all of the enabled scanning data tag patterns visible in the Data Classification - Scanning Tags page. If the pattern is found often enough in the file, the scanning data tag is attached to the file. Once the tag is attached to the file, other rules can control access to that file.

From the Configuration menu navigate Global Settings > Scanning Data Tags to reach the Data Classification - Scanning Tags page. See Managing Scanning Data Tags, page 16-9 for a full description of that page and the administrative tasks associated with it.

Static Data Tags

A static data tag can be assigned to a file if a particular application accesses the file. Static data tags are built-in data tags distributed with this release and are listed on the Data Classification - Static Data Tags page on the CSA MC. You cannot change the names of these tags and you cannot create new static data tags.

You define the rules, based on your enterprise's needs, that assign static data tags to files. There are no Data Loss Prevention policies that come pre-configured to assign static data tags to files.

Static data tagging can be useful if, for example, you have a specialized application. Perhaps your enterprise is a hospital and you know in advance that any file that your specialized application reads falls under HIPAA guidelines. There is a <HIPAA Controlled> static data tag that you can apply to the file. This type of tagging method may also be useful when a file type is not scannable for a text-matching pattern, such as an audio file or a graphics file.

From the Configuration menu, navigate Global Settings > Static Data Tags to reach the Data Classification - Static Tags page. See Managing Static Data Tags, page 16-14 for a full description of that page and the administrative tasks associated with it.

Report Configuration

Using the Report Configuration page, you can customize the look of all of your reports. For reports you generate as PDF, you can specify a font and an image for a watermark. For both PDF and HTML reports, you can specify an image for a logo. These customizations will be reflected on every report you generate.

The customizations are all optional. If you do not choose to customize your reports, they will be created using the default settings on the Report Configuration page.

The Report Configuration page is available in advanced mode only.

Configuring Reports

Follow this procedure to configure your reports:

Step 1 From the Configuration menu, navigate Global Settings > Report Configuration.

Step 2 For PDF output report types, you can specify a font in the Font Name field. Only true type fonts (.ttf), true type collections (.ttc), and open type fonts (.otf) may be used.

a. Fonts can not be imported directly from the \Windows\Fonts directory. If the font you want is in the \Windows\Fonts directory, copy it from that directory and place it on your desktop or in some other location.

b. Click the Add button next to the Font Name field.

c. Browse to the new location of your desired font.

d. Select the font and click Open.

e. Click Upload.

Step 3 If you specified a font in the previous step, you must define its font type in the Font Type field. In the Font Type field select Non-unicode Font or Unicode Font depending on the font you chose in the previous step.

Step 4 For PDF output report types, you can specify an image to be used as a watermark. The optimum size for the watermark images is 600 x 400 pixels. You may upload image files with .bmp, .gif, .jpeg, and .jpg file extensions. To add an image to serve as your watermark:

a. Click the Add link next to the Watermark field.

b. Browse to the image you are going to use for your watermark.

c. Select the image and click Open.

d. Click Upload.

Step 5 For both PDF and HTML output types, you can specify an image to be used as a logo. The optimum size for the logo image is 920 x 520 pixels. You may upload image files with .bmp, .gif, .jpeg, and .jpg file extensions. To add an image to serve as your logo:

a. Click the Add link next to the PDF Logo or HTML Logo field.

b. Browse to the image you are going to use for your logo.

c. Select the image and click Open.

d. Click Upload.

Note The logo is displayed in the top right corner of the report and it replaces the default Cisco logo.

Step 6 Click Save. Rules do not need to be generated for these configuration settings to take affect.

Deleting Report Configurations

You can delete any fonts, watermark, or logo images that you have added to the Report Configuration page. This removes these fonts and images as a choice on the Report Configuration page but does not delete the font or image from your disk.

Note You cannot delete the default font or logo image nor can you delete fonts and images that are being used by a report.

Follow this procedure to delete an image or font:

Step 1 Make sure the image or font you want to delete is not in use:

a. From the Configuration menu, navigate Global Settings > Report Configuration.

b. Assume that the fonts and images displayed in the list boxes is in use by the reports.

c. If the font or image that you want to display is in use, change the font or image to another choice from the list box.

d. Click Save.

Step 2 Go back and select the font or image you want to delete from the list box.

Step 3 Click the blue Delete link next to the list box. The font or image is deleted.

	Using Management Center for Cisco Security Agents 6.0
	Using Global Settings
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 Using Global Settings Download the complete book Using Management Center for Cisco Security Agents V.6.0 (PDF - 8 MB) Table Of Contents Using Global Settings Overview Application Trust Levels Setting Application Trust Levels Using the Event Management Wizard to Set Trust Levels Identifying Members of the White List, Grey List, and Black List AntiVirus Exemptions Event Correlation Correlation Manage Dynamically Quarantined Files and IP Addresses Signature Settings Scanning Data Tags Static Data Tags Report Configuration Configuring Reports Deleting Report Configurations Using Global Settings Overview Management Center for Cisco Security Agents provides configuration tools from the Global Settings section that are used to categorize and apply tags to processes, files, and IP addresses and to correlate events across multiple systems. When tags are applied and certain correlation rules are triggered, the MC registers this occurrence and automatically builds application classes and sends out new process categories to Cisco Security Agents. In some cases, the MC can prevent actions from executing on any additional systems based on noticing the action taking place on a small number of systems. The Cisco Security Agent also scans agent systems for applied tags and can apply rules informing users of data loss possibilities on that basis. This chapter contains these sections: •Application Trust Levels –Setting Application Trust Levels –Using the Event Management Wizard to Set Trust Levels –Identifying Members of the White List, Grey List, and Black List •Scanning Data Tags •AntiVirus Exemptions •Event Correlation •Signature Settings •Scanning Data Tags •Static Data Tags •Report Configuration Application Trust Levels Application trust levels refer to an application's placement on a "White List," "Grey List," or "Black List." After an application is placed on one of these lists, there are different rules provided in this release that permit or restrict the application from acting. Applications in the White List are generally trusted and allowed to run, however, they are continuously monitored and if they commit a severe violation, they are immediately restricted. Applications in the Black List are not trusted and are prevented from running. If they are running, they are terminated. If a user needs to use a black-listed application, then the application must be added to the white list. In such a case, it is recommended that the user adds rules that restrict the application to the minimum set of privileges required. Applications are placed on the white list, grey list, or black list in one of these ways: •Administrators place the applications on a list by using the global Application Trust Levels page. •Some members of a list are static. We have already classified some applications and placed them on one of these lists. You do not need to ensure that every application on a host is placed on one of these lists. Setting Application Trust Levels CSA MC Administrators can add files to the White List, Grey List, and Black List through the global Application Trust Level page. Step 1 Log on to the CSA MC as a user with configure privileges. This procedure can be performed by users in Advanced Mode or Simple Mode. Step 2 From the Configuration menu, navigate Global Settings > Application Trust Levels. Step 3 On the global Application Trust Levels page, click New. Step 4 In the File Name field, provide the path and filename for the application you are listing. You can use wildcards () to generalize the location of the file. For example: `C:\Program Files\Cisco\CSAgent\bin\\`Indicates every file in every subdirectory of C:\Program Files\Cisco\CSAgent\bin. `\Program Files\Cisco\CSAgent\bin\\` Indicates every file in every subdirectory of CSAgent\bin no matter what drive it is installed on. See Using the Correct Syntax, page 2-41 for more information about how to properly use wildcards. Step 5 In the Trust Level field, select White List, Grey List, or Black List from the pull-down menu. Step 6 In the OS field, specify the type of operating system this trust specification applies to. Windows indicates any supported Windows platform. UNIX indicates any supported UNIX or Linux platform. Step 7 In the Justification field, explain why you are creating setting the trust for the application. Step 8 Click Save. The new trust level designation is displayed on the Application Trust Level page. Step 9 Generate rules when you are ready to deploy this configuration to hosts. Using the Event Management Wizard to Set Trust Levels Step 1 Log on to the CSA MC as a user with configure privileges. This procedure can be performed by users in Advanced Mode or Simple Mode. Step 2 From the Events menu, select Event Log. Step 3 Find the event which identifies the process for which you want to set a trust level. Step 4 Click the Wizard link. Step 5 In the Classify Application area, note that the Application that triggered this event field is already populated with the directory path and file name of the application. Step 6 In the Action field, select I trust this application, I am not sure I trust this application, or I do not trust this application. These choices place the application on the White List, Grey List, or Black List, respectively. Step 7 In the Justification field, explain why you are creating setting the trust for the application. Step 8 Click Finish. The new trust level designation is displayed on the Application Trust Level page. Step 9 Generate rules when you are ready to deploy this configuration item. Identifying Members of the White List, Grey List, and Black List Applications are assigned to the White List, Grey List, and Black List; they are not added dynamically if a rule triggers. The White List, Grey List, and Black List are defined by the contents of these application classes: Administrator defined - White List Applications, Administrator defined - Grey List Applications, and Administrator defined - Black List Applications. Each application class is made up of file sets and has at least one file set that references its own list's token, such as @whitelist, @greylist, and @blacklist. For example, the Administrator defined - White List Applications application class contains the Administrator defined - White List files file set. One component of this file set is defined as any file associated with the @whitelist token. The @whitelist token is defined as any file on the global Application Trust Level page that is described as being on the white list. The Grey List and Black List applications are defined in similar ways. In order to identify which applications are part of which trust level list, you need to look in two places: in the application class for the trust level and on the Application Trust Level page. To view the contents of an application class, follow this procedure: Step 1 Log on to the CSA MC as any user type and switch to Advanced Mode. Step 2 From the Configuration menu, navigate Applications > Application Classes and search for the Administrator defined - White List Applications, Administrator defined - Grey List Applications, or Administrator defined - Black List Applications application classes. Step 3 Click the link for the application class. The applications that define this class are listed in the file sets listed in the when created from one of the following executables file sets. Step 4 Double click a file set to view the applications that belong to it. To view the applications administrators have assigned to trust lists, follow this procedure: Step 1 Log on to the CSA MC as a user with any level of privileges and view the CSA MC interface in either Advanced Mode or Simple Mode. Step 2 From the Configuration menu, navigate Global settings > Application Trust Level. Applications' memberships in trust level lists are clearly identified on the Application Trust Level page. AntiVirus Exemptions AntiVirus exemptions can be created for signature-based AntiVirus tags that you have determined to be false positives. Creating an exemption for a tag prevents any files, that have been given the tag, from being restricted by AntiVirus rules that pertain to that tag. Creating an exemption for an individual file, with a particular AntiVirus tag, prevents that file from being restricted by AntiVirus rules that pertain to that tag. You can create an exception for a virus tag through the Event Management Wizard or through the AntiVirus Exemptions page. See Creating AntiVirus Exemptions Using the Event Management Wizard, page 15-14 and Creating AntiVirus Exemptions Using the Global AntiVirus Exemptions Page, page 15-15 for these procedures. Here is an example of how an end-user and a CSA MC administrator would be affected by an AntiVirus exemption: Assume that files have been quarantined on various hosts because they have been tagged with an AntiVirus tag. The CSA MC administrator determines that the tag represents a false positive and then creates an exemption for that tag either using the wizard or by hand. The exemption is then listed on the AntiVirus Exemptions page on the CSA MC. When the administrator is ready, he or she generates rules. The next time the host's CSA polls in to the CSA MC, it receives the AntiVirus exemption information. Within the next minute, any files with that AntiVirus tag that have already been quarantined are removed from the Quarantined files tab of the agent. The files are not put in the Restored tab. The AntiVirus exemption is global and individual users are not given the opportunity to re-classify the file as Quarantined. To open the AntiVirus Exemptions list page, mouse-over the Configuration menu on the CSA MC and navigate Global Settings > AntiVirus Exemptions. The list page provides these columns of information to describe an AntiVirus exemption: •Virus: This is the name of the virus as reported in an event or as determined by the Event Management Wizard. It is also the AntiVirus tag name for the virus. The name of the AntiVirus tag specified in the AntiVirus Exemptions page must match the tag attached to a file exactly in order for the file to be exempted from AntiVirus rule restrictions. •Target: This indicates <All files> if the AntiVirus tag has been exempted, and therefore any file with the tag will be exempted from AntiVirus rule restrictions that pertain to that tag. The Target may also indicate a path to a particular file in order to exempt only that file from AntiVirus rule restrictions. Two wildcards () may be specified at the beginning of the directory path to generalize where this file might be found. For example: `\Documents and Settings\Administrator\Desktop\Temp\virus.doc` indicates the virus.doc file on Administrator's desktop. `\Desktop\Temp\virus.doc` indicates virus.doc on any desktop. •Justification: The field displays the explanation the Administrator provided for creating the exemption. •Creation time: Indicates the time the exemption was made. •Source: Indicates the user name that created the exemption and if the exemption was created using the wizard. •OS: Indicates the operating system for which the exemption pertains. Event Correlation The Management Center for Cisco Security Agents lets you enable correlation functions for particular types of events. In each case, you must have a corresponding rule enabled in a policy for the global event correlation to take place. If you do not enable global event correlation, individual events are logged by system agents but similar events across multiple agents are not correlated by the central CSA MC. Correlation The Global Event Correlation page, accessible from the menu bar as follows Configuration>Global Settings>Global Event Correlation (see Figure 7-1), provides the following capabilities: •Correlate network scans With this checkbox enabled, correlated port scans and ping scans across multiple agent systems are logged separately as a correlated event in addition to the individual port scan and ping scan events that continue to be logged. Note that you must have a Network shield rule with Port scan detection and Ping scan enabled in a policy deployed to the agent(s) in question for these event types to be detected and logged. The threshold and time frame for correlating network scans are values you can configure. •Correlate events received from operating system event logs and generate a summary event •Log individual events in addition to summary event With this checkbox enabled, events from multiple systems are correlated based on the NT event code, NT event severity, NT event source, and NT event log type. If 2 systems log the same NT event type within 30 minutes, a correlated summary event is logged. Note that you must have an NT event log rule in a policy deployed to the agent(s) in question for these events to be uploaded to the CSA MC log. If you do not enable this checkbox, NT event correlation does not take place, but individual NT events are logged in accordance with the NT event log rule you have configured. Note In this case, there is an additional checkbox (Log individual events in addition to summary events) to control whether the individual events are logged in addition to the summary event. If you do not enable this checkbox, but you do enable the Correlate events checkbox, only correlated summary events will log, NOT individual events. This can be useful if NT event log messages are filling up your CSA MC logfile. •Correlate suspected virus application events and add contaminated files to list of dynamically quarantined files With this checkbox enabled, when processes are added to the dynamic <Suspected Virus Applications> application class (see Built-in Configurable Application Classes, page 8-7) and this event is logged across multiple agent systems, these events are correlated and the contaminated file that triggered the event is added to a dynamic list of quarantined files that CSA MC maintains. If you have a rule configured to stop dynamically quarantined files in a deployed policy, no further agents can access the contaminated file. See page 6-23 for information on using @dynamic in File access control rules. If you do not enable this checkbox, suspected virus correlation does not take place, but individual virus events are logged. Note that you must have a corresponding policy deployed to the agent(s) in question for these event types to be detected and logged. •Correlate events received from virus scanners and add contaminated files to list of dynamically quarantined files With this checkbox enabled, events logged by virus scanners running on agent systems are received and correlated by CSA MC. Contaminated files detected by virus scanners are added to the list of quarantined files. If you have a rule configured to stop access to dynamically quarantined files in a deployed policy, no further agents can receive the contaminated file. See page 6-23 for information on using @dynamic in File access control rules. Note This feature works with Norton, McAfee, and Trend AntiVirus. To receive these virus events, you must have an NT event log rule in a policy deployed to the agent(s) in question for these events to be uploaded to the CSA MC logfile. In the NT event log rule, you must enter the name of the antivirus software in the Event Source field. See NT Event Log, page 6-57 for details. The threshold and time frame for correlating events received from virus scanners are values you can configure. Note To view the files that are added to the dynamically quarantined files list, click the numbered link beside dynamically quarantined files. It takes you to the pertinent event log messages. Read the messages there to locate the names of quarantined files. You can also click the Manage dynamically quarantined files link at the bottom of the page. •Correlate communications with untrusted hosts and add peer addresses to list of dynamically quarantined IP addresses. With this checkbox enabled, when the "Set" action is used in a rule to mark a host address as Untrusted (globally) (see Using the Set Action, page 5-25) and this event is logged across multiple agent systems, these events are correlated and the untrusted peer address that triggered the event is added to a dynamic list of quarantined IP addresses that CSA MC maintains. If you have a rule configured to stop dynamically quarantined IP addresses in a deployed policy, no further agents can communicate with this peer address. See page 6-23 for information on using @dynamic in Network access control rules. If you do not enable this checkbox, untrusted host correlation does not take place, but individual untrusted host events are logged. Note You must have a corresponding policy deployed to the agent(s) in question for these event types to be detected and logged. Note To view the IP addresses that are added to the dynamically quarantined addresses list, click the numbered link beside dynamically quarantined IP Addresses. It takes you to the pertinent event log messages. Read the messages there to locate the quarantined IP addresses. You can also click the Manage dynamically quarantined IP addresses link at the bottom of the page. Manage Dynamically Quarantined Files and IP Addresses You can use the @dynamic token in the File set text field and in the Network address set text field where they are available in rules to control access to files and addresses that have been quarantined by CSA MC. Files are quarantined as a result of suspected virus application events, correlated virus scanner log messages, or files that were added manually. This list updates automatically (dynamically) as logged quarantined files are received. Addresses are quarantined as a result of communication with a suspected untrusted host (this updates dynamically) or by being added manually. To view the files that are added to the dynamically quarantined files list and to manually add files to be quarantined, click the Manage dynamically quarantined files link on the Global Event Correlation page. See Figure 7-2. Add and Remove files from this list using the provided buttons on the bottom of the window that appears. To view the addresses that are added to the dynamically quarantined IP addresses list and to manually add addresses to be quarantined, click the Manage dynamically quarantined IP addresses link on the Global Event Correlation page. Add and Remove IP addresses from this list using the provided buttons on the bottom of the window that appears. See Figure 7-3. The "Source" column in this window describes how the address was added to the list (manually by the administrator or through a correlation event). Changes made to the quarantined file and IP address lists are not received by agents until they next poll in to the management center. You can send a hint message to hosts to poll in sooner than the set interval. See Configuring Groups, page 3-4 for poll hint details. Confidence Ratings When you click the Manage dynamically quarantined files and IP addresses links, items that are not added manually by the administrator, but are added automatically through event correlation will have a "high" or a "low" confidence rating. This rating indicates the "danger" likelihood of the item that has been quarantined. This rating is based on the detected file type and the network protocol involved. Note The events to quarantine a specific file or address are subject to event suppression like other components on the system. Duplicate correlation events are suppressed for one hour. This means that a given object can be quarantined, at most, once an hour. Figure 7-1 Global Event Correlation Page Figure 7-2 Quarantine Files Window Figure 7-3 Quarantine IP Addresses Window Signature Settings 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 following sections are currently included in the Global Signature Settings page: •Common - This section contains common signature settings. This includes an expiration time for global and local signatures and a check box to control whether new global signatures are immediately distributed to all agents. The default setting is that the Enable new signatures check box is not selected and signatures expire in 30 days. When the Enable new signatures check box is not selected, signatures are automatically generated after the MSRPC or LPC correlation thresholds are met but they are not automatically distributed to agents. You must individually enable signatures in the Manage global signatures page when the Enable new signatures checkbox is not selected. If the Enable new signatures checkbox is selected, signatures are automatically generated after the MSRPC or LPC correlation thresholds are met and the signatures are distributed to all hosts when they next poll in. Note If you want new signatures enabled 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. For more information about how to manage global signatures and local signatures, and how these settings are used when administering the automatic signature generation feature, see Chapter 14, "Automatic Signature Generation". Scanning Data Tags Scanning Data Tags represent text-matching patterns and built-in number patterns. If a rule triggers file scanning, CSA searches the file for all of the enabled scanning data tag patterns visible in the Data Classification - Scanning Tags page. If the pattern is found often enough in the file, the scanning data tag is attached to the file. Once the tag is attached to the file, other rules can control access to that file. From the Configuration menu navigate Global Settings > Scanning Data Tags to reach the Data Classification - Scanning Tags page. See Managing Scanning Data Tags, page 16-9 for a full description of that page and the administrative tasks associated with it. Static Data Tags A static data tag can be assigned to a file if a particular application accesses the file. Static data tags are built-in data tags distributed with this release and are listed on the Data Classification - Static Data Tags page on the CSA MC. You cannot change the names of these tags and you cannot create new static data tags. You define the rules, based on your enterprise's needs, that assign static data tags to files. There are no Data Loss Prevention policies that come pre-configured to assign static data tags to files. Static data tagging can be useful if, for example, you have a specialized application. Perhaps your enterprise is a hospital and you know in advance that any file that your specialized application reads falls under HIPAA guidelines. There is a <HIPAA Controlled> static data tag that you can apply to the file. This type of tagging method may also be useful when a file type is not scannable for a text-matching pattern, such as an audio file or a graphics file. From the Configuration menu, navigate Global Settings > Static Data Tags to reach the Data Classification - Static Tags page. See Managing Static Data Tags, page 16-14 for a full description of that page and the administrative tasks associated with it. Report Configuration Using the Report Configuration page, you can customize the look of all of your reports. For reports you generate as PDF, you can specify a font and an image for a watermark. For both PDF and HTML reports, you can specify an image for a logo. These customizations will be reflected on every report you generate. The customizations are all optional. If you do not choose to customize your reports, they will be created using the default settings on the Report Configuration page. The Report Configuration page is available in advanced mode only. Configuring Reports Follow this procedure to configure your reports: Step 1 From the Configuration menu, navigate Global Settings > Report Configuration. Step 2 For PDF output report types, you can specify a font in the Font Name field. Only true type fonts (.ttf), true type collections (.ttc), and open type fonts (.otf) may be used. a. Fonts can not be imported directly from the \Windows\Fonts directory. If the font you want is in the \Windows\Fonts directory, copy it from that directory and place it on your desktop or in some other location. b. Click the Add button next to the Font Name field. c. Browse to the new location of your desired font. d. Select the font and click Open. e. Click Upload. Step 3 If you specified a font in the previous step, you must define its font type in the Font Type field. In the Font Type field select Non-unicode Font or Unicode Font depending on the font you chose in the previous step. Step 4 For PDF output report types, you can specify an image to be used as a watermark. The optimum size for the watermark images is 600 x 400 pixels. You may upload image files with .bmp, .gif, .jpeg, and .jpg file extensions. To add an image to serve as your watermark: a. Click the Add link next to the Watermark field. b. Browse to the image you are going to use for your watermark. c. Select the image and click Open. d. Click Upload. Step 5 For both PDF and HTML output types, you can specify an image to be used as a logo. The optimum size for the logo image is 920 x 520 pixels. You may upload image files with .bmp, .gif, .jpeg, and .jpg file extensions. To add an image to serve as your logo: a. Click the Add link next to the PDF Logo or HTML Logo field. b. Browse to the image you are going to use for your logo. c. Select the image and click Open. d. Click Upload. Note The logo is displayed in the top right corner of the report and it replaces the default Cisco logo. Step 6 Click Save. Rules do not need to be generated for these configuration settings to take affect. Deleting Report Configurations You can delete any fonts, watermark, or logo images that you have added to the Report Configuration page. This removes these fonts and images as a choice on the Report Configuration page but does not delete the font or image from your disk. Note You cannot delete the default font or logo image nor can you delete fonts and images that are being used by a report. Follow this procedure to delete an image or font: Step 1 Make sure the image or font you want to delete is not in use: a. From the Configuration menu, navigate Global Settings > Report Configuration. b. Assume that the fonts and images displayed in the list boxes is in use by the reports. c. If the font or image that you want to display is in use, change the font or image to another choice from the list box. d. Click Save. Step 2 Go back and select the font or image you want to delete from the list box. Step 3** Click the blue Delete link next to the list box. The font or image is deleted.
	Terms & Conditions \| Privacy Statement \| Cookie Policy \| Trademarks