-
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
-
Table Of Contents
Filtering Events by Defining a Custom Filter
Event Aggregation and Suppression
Graphing Similar Events by Time
Graphing Similar Events by Differences
Viewing Events Using the Event Analysis Filter
Configuring An Event Analysis Filter
Configuring Allowed Number of Securitylog.txt Files
About the Event Management Wizard
Creating Allow Exception Rules
Creating Logging Exception Rules
Enabling, Disabling, and Deleting Exceptions
Perform an Application Behavior Investigation
Viewing Event Suppression Filters
Generate an Alert Log File for Third Party Applications
Event Logging and Alerts
Overview
Events and messages logged by Cisco Security Agents can be viewed from CSA MC. You can also control the type of alert sent out based on the severity level of the logged event, the specific event, and the host that generated the alert. You can configure CSA MC to send email, issue SNMP traps, log to a text file, and execute custom programs.
Note
Cisco Security Agent events are also stored in the NT event log on an agent system in a localized format.
This section contains the following topics.
–
•
–
–
–
The Event Log
The Event Log view lets you view system events provided by registered agents according to designated time frames, event severity levels, and the system that generated the event. To reach the Event Log screen, begin at the CSA MC menu bar and navigate Events > Event Log.
Figure 10-1 Event Log Screen
The event log screen (see Figure 10-1) displays event messages within the time frame and severity level you specify and optionally by a specific host. These event messages explain the event that occurred and they provide a link to the rule that triggered the event. They also provides the exact time the event was recorded and a link to the registered host view for the host that generated the event.
Some Event Log messages contain a Details link you can click to view more information about the event that generated the message. (The details contained here can be useful to customer support.) Read Reading Event Details, for more information. The Details link also provides packet information when appropriate. By installing Wireshark (http://www.wireshark.org) on the same server in which CSA MC is installed, you will be able to read the contents of a packet in a human-readable form rather than in hexadecimal notation. Read Reading Packet Details for more information.
Log messages also contain a Rule number link. Clicking a Rule number link takes you to the rule that was triggered when the message in question logged.
Use the Wizard link, where available, to edit the rule that caused the event. See About the Event Management Wizard for details.
A System State link appears with an event when the rule in question has triggered due to a system state condition. (Note that it is not always advisable to generate a wizard exception based on an event that is appearing due to a system state condition triggering. Rather, if you intend to configure an exception, you should create it for the original rule that caused the system state to apply.) Use the pop-up that appears when you click System State from an event to trace back to the original rule (if available) that triggered the system state condition.
Use the Find link to open the Find Similar Events dialog box and search for messages similar to the one displayed in the Event log. Use the Graph link to display similar events graphically.
The information displayed on the Event Log page is controlled by the settings defined in the Change Filter window. The Change Filter window allows you to sort information by event set or by defining a custom filter. The way the events are filtered is presented at the top of the Event Log page.
Figure 10-2 Event Log Filter Summary
The event log filter summary provides this information depending on the settings in the event filter.
•
•
•
•
•
•
•
•
•
•
•
Note
•
Filtering Events
Events can be filtered either by event set or by defining a custom filter. Click the change filter link in the event log filter summary area to display the Filter Events dialog box.
Figure 10-3 Filter Events dialog box
Filtering Events by Event Set
An event set is a pre-defined set of search criteria. To learn more about event sets see "Event Sets" section.
Step 1
Step 2
Step 3
Filtering Events by Defining a Custom Filter
Searches defined by search criteria are "and" searches. That is, the more attributes you specify to search by, the fewer number of events are likely to be found by the search.
Step 1
Step 2
•
–
–
–
•
–
–
–
–
–
–
–
•
•
•
•
•
Note
•
•
Note
•
Step 3
Event Aggregation and Suppression
When first deploying rules to agents, it is not unusual to have an overwhelming flurry of events appearing in the event log. In some cases, most of these events are similar events or simply "noisy", not useful events to view. If this is the case, the event log provides two mechanisms for paring down the number of events that appear:
•
When event filtering is enabled, the event log displays an aggregation of events. This aggregation means that one representative event is displayed for all events that are considered similar on the MC. Similar events are defined as having the same rule ID and the same application name and path (excluding drive letter).
When similar events are filtered from the event log view in this way, there is italicized text below the viewable, representative event. This text displays the number of filtered events that are not visible. Clicking the Find link allows you to search for all events of this similar type. Clicking the Graph link allows you to graph similar events.
Figure 10-4 Event Log Find Similar
Note
A "similar" event meets the following criteria:
–
–
–
•
When event suppression is enabled, all chosen events are no longer displayed in the event log. Event suppression is best used when you have a reoccurring event that is more noisy than useful to you. This is something you are aware of, but no longer wish to see. Suppressing the event removes all viewable instances of that event and causes further events of the same type to be hidden. Note that these events remain in the database, they are simply not displayed. The visibility of the suppressed events is controlled by Administrator Preference settings. Refer to Configuring Role-Based Administration, page 2-14.
Note
Graphing Similar Events
When using the advanced view of the CSA MC, administrators can graphically display similar events using the Graph link in the Event Log.
Events may be graphed to show when similar events occurred over time or they may be graphed to show a breakdown of the differences in aggregated events.
Events graphed by time are filtered via a set of criteria, counted per unit of time, and graphed versus time. For example, you could create a graph of Events vs. Time where each day is represented in a point and the value of the "y" axis is the number of events that occurred that day. This filtering is very similar to the Find option.
Events that have a host associated with them can be graphed in the format Hosts vs. Time. In this case the "y" axis value indicates the number of hosts that generated an event meeting the criteria during a day.
Differences in aggregated events are broken down and displayed in a bar chart. This could give you a visual image of how, for example, one application has been denied or allowed access to a variety of different files.
Each point on a graph, or line in a chart, is also a hyperlink. You can mouse over to see summary information about that data or you can click the data point, to display the events it represents.
Graphing Similar Events by Time
Step 1
Step 2
Step 3
•
•
•
•
•
•
•
Step 4
Step 5
After the graph has been created you will be able to change graph criteria, print the graph, and download the graphed data as a .csv (comma separated value) file by clicking for that task.
You will also be able to analyze a data point on the graph by clicking it. Mousing over a data point on the graph pops up summary information about the data point. Clicking on the data point will show you all the similar events that it represents.
Graphing Similar Events by Differences
Step 1
Step 2
Step 3
Step 4
Step 5
Figure 10-5 Image of rule with highlighted box
Figure 10-5 shows how many different files MCSHIELD attempted to access on host Client221, and how often MCSHIELD attempted to access them.
Reading Event Details
To view the details of an Event Log entry, follow this procedure:
Step 1
Step 2
Step 3
•
•
Reading Packet Details
CSA MC provides a mechanism which allows you to use "Wireshark" software to translate packets into a readable format. Wireshark is a third-party tool that analyzes protocols and works with WinPcap to analyze packets. Before you can view packet information in readable form, you must first install Wireshark on the same server that runs CSA MC.
To install Wireshark, follow the installation instructions found at http://www.wireshark.org. Install the latest released version of Wireshark and the version of WinPcap recommended by Wireshark.
After you have installed Wireshark, you can read packet details by following this procedure:
Step 1
Step 2
Step 3
Event Monitor
Similar to the Event Log, the Event Monitor, available from the Events category in the menu bar, lets you view system events provided by registered agents according to designated severity levels, and the host that generated the event. You can also enter the number of events to be displayed (default value is the last 50 events). Click the Change link to access a pop-up window from which you can edit these values and change the event filter. Refer back to The Event Log for more information on these fields.
Unlike the Event Log page, the Event Monitor page automatically refreshes itself at set intervals. The event list is updated with the latest events each time the page refreshes.
The footer of this page provides a Refresh button and a Pause button. Use the Refresh button to refresh the page immediately without waiting for the set refresh interval to occur. Use the Pause button to immediately stop the page from refreshing. The set refresh interval will then stop at wherever it is in the countdown. This pause feature is useful when you are testing policies and you want to mark a certain place as a starting point for receiving new events. When you click it, the Pause button becomes a Resume button.
Note
The Event Monitor will continue to refresh even after the timeout expires. However, you will not be able to navigate to any other page. This allows you to leave the Event Monitor on screen without worrying about anyone being able to access CSA MC after the session timeout.
Event Analysis
The Event Analysis tool shows you the applications that are producing the most events and the hosts on which those applications are running.
Viewing Events Using the Event Analysis Filter
Step 1
Step 2
•
•
•
Configuring An Event Analysis Filter
Step 1
Step 2
Step 3
Step 4
Step 5
•
–
–
–
•
•
•
•
•
•
•
•
•
Step 6
Event Managing Tasks
The Event Managing Tasks feature, available from the Events menu bar, lets you create event database management tasks to manage the size of your event log. As your event log grows, specifying parameters for deleting events will help prevent this log from growing too large and from maintaining stale information.
Note
To access the global Event Insertion Tasks page:
Step 1
Step 2
This page displays the total number of events in the Event Log. It also breaks events out to the number of events that exist for each severity level. Beneath this graphical event display are the default threshold settings for each event level. These thresholds represent the upper limit of events which must be reached for each severity level before no more events of this type will log. Event pruning must occur in order for these event types to once again be written to the Event Log.
To configure an event auto-pruning task, do the following. See Figure 10-6.
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
•
•
•
Step 7
Note
Figure 10-6 Event Auto-Pruning
Figure 10-7 Event Insertion Task
Local Event Log File
CSA records, in a local log file named securitylog.txt, the events that it sends to CSA MC. Securitylog.txt is located in the Program Files\Cisco\CSAgent\log directory.
Securitylog.txt file can reach a maximum size of about 1MB. If CSA generates an event after the securitylog.txt file has reached 1MB, CSA backs up a copy of the existing securitylog.txt file and begins a new one. This is the naming convention for the backed-up securitylog.txt files:
securitylog-YYYYMMDD-HHMM.txt.For example, CSA could backup securitylog.txt with the file name securitylog-20100331-1512.txt indicating it was saved on March 31, 2010 at 15 hours 12 minutes.After CSA backs-up the old securitylog.txt file, it writes new event messages to the new securitylog.txt file. CSA saves up to four of the backed-up securitylog.txt files at a time. You can configure the number of backup securitylog.txt files CSA can create by changing the value of the esl_file_limit parameter in the sysvars.cf file.
Note
In CSA 6.0.0.214 and subsequent builds of CSA, this behavior is different: CSA continues to create new securitylog.txt files whenever the existing securitylog.txt file reaches 1MB. CSA saves up to four of the past securitylog.txt files depending on the configuration of the esl_file_limit parameter in the sysvars.cf file.
Configuring Allowed Number of Securitylog.txt Files
CSA saves up to four of the backed-up securitylog.txt files at a time. You can configure the number of securitylog.txt files CSA saves by editing the esl_file_limit parameter in the sysvars.cf file.
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
How Logging Works
The CSA MC Event Log does not contain every occurrence of an event from a system. Duplicate events are not logged for an hour after the first occurrence.
Caution
The following information is logged for each rule type.
•
•
Note
•
•
A duplicate event is defined as follows:
•
•
•
•
Verbose Logging
Enable Verbose Logging Mode in the Group configuration view to change the event log timer to log all recurring events rather than only logging recurring events once every hour. Verbose logging applies to all policies that are attached to the group that have logging turned on.
For normal operations, you would not want to enable Verbose logging. Verbose logging is useful for troubleshooting and for analyzing how applications work with rule sets, i.e. related processes and subprocesses. In the latter case, using Verbose logging with Audit Mode can be very useful for monitoring how a rule set would work before deploying it.
Note
Logging and Query User Rules
When a user responds to a Query User box (by pressing Yes, No, or Terminate), the agent remembers the response and caches it for an hour. This way, if the same rule is triggered again within that hour, the action is allowed or denied based on what the user answered previously, with no pop-up query box appearing again. When the user responds to a triggered Query User pop-up box, the system action that triggered the pop-up, as well as the user's response, are logged in the CSA MC event log. With Verbose logging turned on, all subsequent automatic allows or denies are logged as well. Otherwise, the one hour logging timer prevents agents from logging the automatic allowed or denied system action if it occurs again within the hour.
About the Event Management Wizard
When you click the Wizard link from an event in the Event Log page, you launch the Event Management Wizard. You can use the Event Management Wizard to accomplish the following tasks:
•
•
•
•
•
•
When administrators in Advanced Mode use the wizard, they have the option of stepping through several configuration screens when performing their task or accepting at once all the choices made by the wizard. Administrators in Simple Mode choose the task they want to perform and then click Finish to accept all the configuration choices made by the wizard.
In most cases, unless you are certain of the behavior that will result from your choices, accept the default choice offered by the wizard when performing your task.
Figure 10-8 Event Management Wizard Link
Creating Exception Rules
When you click the Wizard link from an event in the Event Log page, you can create an exception rule which will "Allow" an action that was previously "Denied" or stop logging an event. The Event Management Wizard is the tool that creates these exceptions. Figure 10-9 shows the initial page of the Event Management Wizard.
Once the exception rule is created, it is placed in a new rule module, which is attached to the same policy as the rule that triggered the event. The rule module is named, PolicyName - exceptions and every subsequent exception for a rule in that policy will be placed in that rule module. If the rule that triggered the event belongs to more than one policy, then an exception is created for every policy to which the rule belongs.
The PolicyName - exceptions rule modules are not configurable like other rule modules. All editing of the exceptions must be done in the Exceptions page. Advanced mode users may, however, edit the content of the exception rules.
Figure 10-9 Event Management Wizard
Creating Allow Exception Rules
You can create "Allow" exception rules for the following rule types:
•
•
•
•
•
•
•
•
•
To create an exception Allow rule, follow this procedure:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
•
•
Step 7
Step 8
•
•
Step 9
Unless you are certain of the behavior that will result from your choices, accept the configurations offered by the wizard in order to create the exception rule.
The Allow exception rule is added to a PolicyName - exceptions rule module and the module is attached to the policy which includes the originating rule.
The exception is then listed with its policy in the Exceptions page. You can reach that page by mousing-over Configuration on the CSA MC menu and selecting Exceptions.
Note
Step 10
These are some special use-cases pertaining to "Allow" exception rules:
System API Control/Buffer Overflow:
If the action of the triggering rule is to:
Set - Data payload trust status - as - untrusted
the exception rule will not be to "Allow" the action. Instead the exception will:
Set - Data payload trust status - as - unchanged
If a payload is marked as both "unchanged" and "untrusted," the rule marking the payload as "unchanged" takes precedence.
Additionally, if the event is triggered by the "Handle exceptions" or "Access system functions from code executing in data or stack space" sub-rules and a signature was created as a result of the Set - Data payload trust status - as - untrusted action, the matching signature (or signatures, if the exception rule is configured to consider "similar events") will also be purged to prevent Data Access Control rules from denying an action based on an existing signature.
Data Access Control:
This use case is similar to the previously described System API Control/Buffer Overflow use case but describes what happens when the exception is created from the Data Access Control rule (DACL).
"Allow" exceptions to DACLs can be created if the event was triggered because CSA matched a payload with an existing automatically generated signature and the DACL denied the action based on the presence of that signature.
When you attempt to create an "allow" exception for a DACL, the Event Management Wizard does not actually create a DACL exception rule; it will deletes the automatically generated signature(s), that matched the payload, thus preventing further deny actions based on an existing signature.
If the corresponding System API Control "Set-data payload trust status-as-untrusted" event and triggering rule are found, the wizard will also create a System API Control exception rule to Set - data payload trust status - as - unchanged since the user considers the payload harmless. This prevents further signature generations for that payload.
Rootkit/Kernel Protection:
If the rule that triggered the event was configured with the action to:
Set - detected rootkit trust status - as - untrusted
the exception rule will not be to "Allow" the action. Instead the exception will:
Set - detected rootkit trust status - as - unchanged
If the detected rootkit trust status is marked both "unchanged" and "untrusted," the rule marking the payload as "unchanged" takes precedence.
Creating Logging Exception Rules
When you create an exception logging rule you create a rule that is an exact copy of the rule that triggered the event. The one difference is that the rule created by the wizard has the Take precedence over other <action type> rules checkbox selected and the Log checkbox is unselected. This causes the rule created by the wizard to remain in effect, in the correct precedence within the policy, but not log an event when triggered.
See Rules: Manipulating Precedence, page 5-22 for more information on the manipulating precedence feature.
"Stop Log" exceptions can be created for all the rules containing the "Take precedence over other...rules" checkbox, provided that the rule's action is not Set, Monitor, or Add/Remove Process from an application class, and provided that logging is not enabled.
Therefore you cannot create exception logging rules for these rule types:
•
•
•
•
•
•
To create a logging exception rule, follow this procedure:
Step 1
Step 2
Step 3
Step 4
Step 5
•
•
Step 6
Step 7
•
•
Step 8
Unless you are certain of the behavior that will result from your choices, accept the configurations offered by the wizard in order to create the exception rule.
The logging exception rule is added to a PolicyName - exceptions rule module and the module is attached to the policy which includes the originating rule.
The exception is then listed with its policy in the Exceptions page. You can reach that page by mousing-over Configuration on the CSA MC menu and selecting Exceptions.
Note
Step 9
Configuring Exceptions
The Exceptions page lists the policies that contain exceptions to rules. Expanding the policy listing displays the exception rule.
Exception rules are maintained in the policy for which they were created. All exceptions for a particular policy are attached to a special rule module called PolicyName - exceptions.
Advanced Mode users will see all the exceptions that have been created. Simple Mode users will see the exceptions that have been created for the policies that are visible in Simple Mode.
Exceptions are created by using the Event Management Wizard. See Creating Exception Rules, Creating Allow Exception Rules, and Creating Logging Exception Rules for more information on how to create an exception.
Editing Exceptions
Generally speaking, users are expected to accept the configuration choices offered by the wizard in order to create the exception rule. However, even after the exception is created by the wizard, Advanced Mode users can still edit the rule.
This gives the administrator the flexibility of turning on logging or broadening the scope of the exception if it is warranted.
To edit an exception, follow this procedure:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Note
Enabling, Disabling, and Deleting Exceptions
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Moving and Copying Exceptions
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
If an exception is moved to a policy it retains its Rule ID. If an exception is copied to another policy, the exception receives a new Rule ID.
Step 7
Perform an Application Behavior Investigation
When you click the Wizard link from the Event Log page, you can choose to Analyze Application, which configures a behavior analysis to investigate the application that triggered the event (see Figure 10-9). This wizard option is available for users of Advanced Mode only.
If you select Analyze Application, to create a behavior analysis, optionally you can choose to Disable policy rule enforcement for the time frame of the analysis. Otherwise, the analysis takes place only within the confines of enforced policies. In that case, some events may be denied by rules during the analysis and therefore the analysis may not be complete.
If you select the Disable policy rule enforcement checkbox, when the logging agent receives an analysis, any policies relevant to the application being analyzed are disabled on the selected host until the behavior analysis is completed. You should understand that if the application being analyzed is untrusted or potentially a virus, you will allow it to run unimpeded during the analysis if you disable policy rule enforcement.
Figure 10-10 Behavior Analysis Wizard Step 2
If you decide that the application is not dangerous and it can run without any policy restrictions, you can begin to configure the behavior analysis.
Figure 10-11 Behavior Analysis Wizard Step 3
The next behavior analysis wizard page (see Figure 10-11) displays the application that triggered the event. This is the application the behavior analysis will investigate. Optionally, you can select other application classes to be analyzed. But in that case, the policy created would apply equally to all applications included in the analysis. For example, if the application class you are analyzing contains both Microsoft Word and Microsoft Outlook, the policy generated by the behavior analysis would be a combination of the resources required by both applications.
Continuing to click the Next button through the behavior analysis wizard configures the analysis with chosen defaults for analysis workstation and time frame. You can choose to edit these defaults or to accept them by making no changes.
When the wizard completes, it takes you to the new behavior analysis configuration page as it appears in CSA MC. You can edit it at this time or you can deploy the analysis by doing the following:
•
•
•
•
Suppressing Similar Events
When you click the Wizard link from the Event Log page, you can choose to Suppress Similar Events based on the event from which you click the wizard link (see Figure 10-9). "Similar events" have the same rule ID, are of the same event type, and are reported for the same application. For the purpose of grouping similar events, CSA MC ignores the drive letter or share name of the application.
Event suppression is best used when you have a reoccurring event that is more noisy than useful to you. This is something you are aware of, but no longer wish to see. Suppressing the event removes all viewable instances of that event and causes further events of the same type to be hidden. Note that these events remain in the database, they are simply not displayed.
Simple Mode users select Suppress Similar Events in the Event Management Wizard and then Finish to suppress the events.
Advanced Mode users select Suppress Similar Events in the Event Management Wizard and can click Next to view a summary of the rule type, rule ID, and application for which the event was reported. Clicking Finish suppresses the events.
Figure 10-12 Event Suppression Filter Wizard Step 2
Viewing Event Suppression Filters
Once you create the event suppression filter using the Wizard, that filter is viewable from a link in the Show suppressed events field at the top of the Event Log page. In Figure 10-13, find the Show suppressed events: No [2 event suppression filters defined] link.
Figure 10-13 Show suppressed events link
When you click the Show suppressed event <#> event suppression filters defined link, a pop-up window appears from which you can either remove the filter to once again show all the events or purge all the events that have been filtered out. See Figure 10-14.
Figure 10-14 Remove Filter or Purge Events Pop-up
Purge Similar Events
When you click the Wizard link from the Event Log page, you can choose to Purge Similar Events based on the event from which you click the wizard link (see Figure 10-9). This purges all similar events but leaves one, most recent, representative event in the event log. All but one of these events are purged from the Event Log. Once purged, they cannot be recovered.
Simple Mode users select Purge Similar Events in the Event Management Wizard and then Finish to purge the events.
Advanced Mode users select Purge Similar Events in the Event Management Wizard and can click Next to view a summary of the rule type, rule ID, and application for which the event was reported. Clicking Finish purges the events.
Event Sets
Configure event sets for use in alerts, reports, and event logs. When configuring alerts, event sets cause CSA MC to trigger alerts based on specified events. Once configured, these event set configurations become available in corresponding alert selection fields.
Note
When creating your event sets, it's a good idea to adopt a naming convention that lets you quickly recognize event sets in your Alert configuration view.
Note
To configure event sets, do the following.
Step 1
Step 2
Step 3
•
•
Under the Event Specification section, enter optional filtering parameters.
Note
Step 4
Leave the Include all event types radio button selected to have events of all types included or select the Include only the following selected event types radio button. If you select the second radio button, then you must also select specific event log messages to filter by. These messages represent the spectrum of generated events that appear in the Event Log view.
Step 5
Leave the Include all severity levels radio button selected to have events of all severity levels included or select the Include only the following selected severity levels radio button. If you select the second radio button, then you must also select the severity level(s) that will trigger an alert for this event set. Available levels are: Information, Notice, Warning, Error, Alert, Critical, Emergency.
Step 6
Leave the Include all hosts radio button selected to have events generated by all hosts included or select the Include only hosts in the following selected groups radio button. If you select the second radio button, then you must select the group(s) that trigger an alert for this event set. Any groups selected here that log the event in question will trigger an alert.
Step 7
Leave the Include all rule modules radio button selected to have events generated by all rules modules included or select the Include only rules in the following selected rule modules radio button. If you select the second radio button, then you must select the rule module(s) that trigger an alert for this event set. Any rule modules selected here that log the event in question will trigger an alert.
Step 8
Note
Leave the Include all timestamps radio button selected to have events generated at all times included or select the Include only these timestamps radio button. If you select the second radio button, then you can create a custom time here or select from available times, Today, Last 24 hours, Last 7 days, Last 30 days, and Events older than <you specify #> days to trigger an alert when an event occurs with the specified time range.
You can also enter Custom start and Custom end times in the following manner:
•
•
•
Note
Step 9
In the Event Sets configuration page, the CSA MC frame at the bottom of the page provides a View button and a Purge events button.
•
Caution
Figure 10-15 Event Set Configuration View
Third Party Access to Events
To access events in the database for exporting to a different format (or for your own reports), connect to the database using ODBC DSN "csamc60dsn."
You can access events through the database view EventListView. (This is a SQL server view.) The columns defined in this view are as follows:
Note
Table 10-1 EventList View Fields
Configuring Alerts
You can configure CSA MC to send various types of alerts to specified recipients when a policy triggers an event. Available alert types include: Email, SNMP, Log to file, Named pipes and a Custom program that you provide.
Each alert type requires you to enter specific information. See Table 10-2 for details.
To configure CSA MC to issue alerts when specified system events occur, do the following.
Step 1
Step 2
Step 3
Step 4
Note
To select multiple items in a list box, hold down the Ctrl key as you select each item. To unselect a single item, hold down the Ctrl key when you click on the item in question. Press the Shift key to select multiple successive items.
If the available options here do not meet your needs, you can configure event set variables which become selectable in this field.Step 5
For each alert type you want to send, select the corresponding checkbox and enter the required alert-specific information.
Note
Step 6
Note
Figure 10-16 Alert Configuration View
Table 10-2
Recipient
Sender address to use
Address of SMTP server
Enter the email address of the mail recipient. Using brackets is optional. CSA MC will automatically enter them if you do not. You can enter multiple addresses separated by commas:
<dpaul@example.com>
Enter the mail sender in brackets. Some mail servers require this to be specified:<jsmith@example.com >
Enter the IP address or DNS name of the SMTP server.Community Name
Manager IP Address
Enter the community name. This is a text string agreed upon by the SNMP manager:
publicEnter IP address of the system where the SNMP trap should be sent. Optionally, you can put a colon and a port number (":<port number>) after the IP address if you are using a non-standard port. (Standard port is 162.)
Refer to the CSAMC-SNMPv2.mib document in the
CSAMC\CSAMC60\docdirectory for SNMP-MIB definitions for Cisco specific objects.Also see Third Party Access to Events for third party event management details.
Log file name (using full path)
Enter a name for the flat logging file that events will be written to.
c:\alerts\logfile.txt
This file can then be used by third party event management applications. See Third Party Access to Events for details.
*In a distributed configuration, the path must correspond to the polling server system.
Custom Program
Enter a custom alert program name here.
The server calls the program as it appears in this field. You must enter the full pathname so that CSA MC can locate the program.
Your custom program must be an executable file.
c:\Program Files\Cisco\CSAMC\CSAMC60\program.exeThe program passes the event message in a file whose name is passed to the program as its first parameter. Alternately, the program can also read the event message from its standard input. The file containing the event is automatically deleted when the program exits or closes its standard input.
FEATURE NOTES:
* The custom program must exist on the same system as CSA MC in the CSAMC60 directory or subdirectory.
*Custom programs cannot require any user input.
*If a custom program is triggered and fails for some reason, it could take several minutes before the program closes itself and attempts to launch again. (If you are testing custom program alerts, one way to tell if the program has launched and is running, is to watch for it in the Task Manager.)
*In a distributed configuration, the path must correspond to the polling server system.
Named Pipe
A named pipe is a form of internal communication. This alert type allows the integration of third party software for the purpose of receiving alerts over Windows named pipes. Consult your third party documentation for further configuration details.
Note that this feature is for use with third party vendors that support alerts over Windows named pipes.
Alert Type Descriptions
Generate an Alert Log File for Third Party Applications
Using the Log checkbox and the Log file edit field in the Alerts configuration page (see Figure 10-16), you can have CSA MC generate a flat logging file to which events are written. Third party event management applications can then parse the information found in this file.
To generate this file, select the Log checkbox and enter the Log file name, using the full path that you want to write event data to. For example, enter
c:\alerts\logfile.txtEvent data is written to this file as follows:
EventId,EventTime,HostId,HostName,
CurrentHostIPAddress,HostOSType,Severity,EventType,
EventText,EventCodeTag,FileName,ProcessName,
SourceIPAddress,DestinationIPAddress,SourcePort,
DestinationPort,RuleId,RuleDescription,RulePriority,
RuleModuleId,RuleModuleName,ButtonCode,UserNameEntry fields are separated by a delimiter of a comma. Event entries themselves are separated by a carriage return/line feed (ASCII Hex 0D 0A).
Once a log file exceeds 1 MB, it is closed and its name is suffixed with a time stamp. A new file, using the same file name entered in the CSA MC Alerts Log file field, is then created. Events continue to be written to this new file until it reaches 1 MB. The third party application that consumes the log files is expected to manage the deletion and archiving of these files once processing is complete.
Note
