|
|
The Configure Logging and Notifications panel enables you to define event filtering rules, which specify which audit records are retained for specific events that transpire within the Cisco Secure Policy Manager system or during a network session. In addition, you can define notification rules, which specify notification/alert settings, to keep your staff informed of security-related events detected by Cisco Secure Policy Manager.
Within Cisco Secure Policy Manager, reporting and monitoring are closely related, because the information that is processed by the Reporting Subsystem for reports and evaluated by the Monitoring Subsystem depends on which audit records you select to store in the Policy Database. The following two concepts are central to both of these subsystems:
Before setting up reporting and monitoring, you must determine the following:
1. Which audit events you want to generate records for so you can define the event filtering rules.
2. How and when you want to notify someone on your staff if a particular audit event occurs so you can define your notification rules.
By defining your event filtering and notification rules, you are defining Cisco Secure Policy Manager's monitoring settings.
Because the Reporting Subsystem provides statistical and summary information about the audit events that occur, how you define your monitoring settings affects the details of the many reports that you can generate about the operation of the security system or a specific network service. After you have defined the monitoring settings (specifically your event filtering settings), you can specify which reports you want to generate on a periodic basis.
In addition to generating audit events that are used by the Reporting and Monitoring Subsystems, Cisco Secure Policy Manager provides the ability to export all generated audit events to an ODBC-compliant database. Using this feature, you can perform custom analysis and summary of network traffic and firewall activity. Many organizations require custom reports and summaries when studying Internet access costs, network and bandwidth usage, and comprehensive security issues. For more information on exporting audit events to an ODBC-compliant database, refer to Cisco Secure Policy Manager Administrator's Guide: System Configuration and Maintenance.
For e-mail notifications to work properly, you must configure a MAPI profile on each primary and secondary server that has an operating Policy Monitor Point. This requirement exists because the Policy Monitor Point that detects an event for which you want to be notified is responsible for generating that notification and delivering it. MAPI is a Messaging API, developed by Microsoft, that provides a standard interface for messaging-based software like Microsoft Exchange and Lotus Notes. MAPI is included with your Windows NT operating systems and enables different e-mail clients to distribute mail. MAPI is installed when you install Windows Messaging. For more information on installing MAPI and creating a user profile, refer to Cisco Secure Policy Manager Administrator's Guide: System Configuration and Maintenance.
For pager notifications to work properly, you must have a modem installed on each primary and secondary server that has an operating Policy Monitor Point, due to the constraint described in the previous discussion on MAPI. By installing and configuring a modem, you automatically configure the Microsoft Telephony API (TAPI) settings that Cisco Secure Policy Manager uses to deliver pager-based notifications. For more information on defining your TAPI settings, refer to Cisco Secure Policy Manager Administrator's Guide: System Configuration and Maintenance. For more information on installing and configuring a modem, see the documentation that came with your modem.
Three categories are used for events: event classifications, specific events, and service statistics. More detail for each category follows.
Event Classifications. Audit events in this category are grouped according to general status and severity. The priority color identifies the severity of audit events, where red is severe, yellow is important, and green is normal. By defining audit record generation rules for audit events under this category, you determine the availability of audit records that can be used by the Policy Report Point to generate warning and system status reports. See the Event Classifications, for definitions of these classifications.
Specific Events. Audit events under this category identify individual events regarding the state of the agents and components that compose the Cisco Secure Policy Manager system, as well as the state of the Cisco Secure Policy Manager servers and Policy Enforcement Points installed on your network. By defining audit record generation rules for audit events in this category, you determine the availability of audit records that can be used by the Policy Report Point to generate warning and system status reports.
Service Statistics. Audit events under this category are grouped according to the network service in which they can occur. By defining audit record generation rules for audit events in this category, you determine the availability of audit records that can be used by the Policy Report Point to generate detailed user and network service reports about the network activity traversing the Policy Enforcement Points installed on your network.
 |
Note You cannot define notifications for audit events based on the Service Statistics category. However, you can define notifications for audit events based on the Event Classifications and Specific Events categories. |
Audit events in the Event Classifications category are grouped according to general status and severity. The priority color identifies the severity of audit events, where red is severe, yellow is important, and green is normal.
By defining audit record generation rules for audit events under this category, you determine the availability of audit records that can be used by the Policy Report Point to generate warning and system status reports.
Table 2-1 classifies the events based on what an audit event means from the perspective of Cisco Secure Policy Manager:
| Category/Priority | Description |
|---|---|
Info/Green | Normal Activity. Indicates audit events that are the result of standard activity of the security system. Example: A new security policy is downloaded to one or more Policy Enforcement Points, a particular system service started up correctly, or a cable is found to be OK, or an interface is performing a self-test. |
Info/Yellow | Interesting Activity. Used for information of interest about the device-specific activities of a Policy Enforcement Point. Example: A Policy Enforcement Point switches to standby or an interface is down on the device. |
Info/Red | Not used. |
Exception/Green | Minor Integrity Issues. Indicates a possible problem on the primary or secondary server or a Policy Enforcement Point, but the problem is not critical to operation. You should investigate these events at your first convenience. Example: An icon file used by the system cannot be found. |
Exception/Yellow | Integrity Issues. Indicates a definite problem on the primary or secondary server or a Policy Enforcement Point that is causing a major loss in functionality. Requires prompt attention. Example: Low resource availability on the Primary Policy Database server or a Policy Enforcement Point cannot read a particular cable. |
Exception/Red | Major Integrity Issues. A primary or secondary server or a Policy Enforcement Point has experienced a system failure. Requires immediate attention. Example: The firewall service does not start. |
Security/Green | Normal Security Issues. Indicates normal, expected security-related activities. Requires periodic review. Example: A Policy Enforcement Point has denied a TCP session because it includes a Java applet, which is not permitted based on the assigned security policy. |
Security/Yellow | Possible Security Issues. Indicates a possible attack against a Policy Enforcement Point or a hardware failure. Requires prompt attention. Example: A Policy Enforcement Point has experienced a power failure. |
Security/Red | Major Security Issues. Indicates a definite attack against a Policy Enforcement Point. Requires immediate attention. Example: Failed to look up the public key to perform secure communications between a primary and secondary server. |
You can perform the following tasks from the Configure Logging and Notifications panel. For step-by-step procedures on performing a specific task, refer to the corresponding section.
You can specify which audit events are recorded on the basis of the classification of the events. Setting event filtering rules based on event classification, combined with any other event filtering rules based on specific events or service statistics, identifies the information that is available for on-demand and scheduled reports.
To define event filtering rules based on event classifications, perform the following task:
Result: The Configure Logging and Notifications panel appears in the View pane.
Step 2 To specify that you want to define event filtering rules based on event classifications, click Event Classifications under Select Event Category.
Result: The list of event classifications appears under Event Description. Audit events in this category are grouped according to general status and severity. The priority color identifies the severity of audit events, where red is severe, yellow is important, and green is normal. By specifying event filtering rules that log events under this category, you determine the availability of audit records that can be used by the Policy Report Point to generate detailed and summary event reports about the primary and secondary servers and Policy Enforcement Points installed on your network. See the Event Classifications, for definitions of these event classifications.
Step 3 To specify the audit event for which you want to define the event filtering rule, click that audit event in the Event Description list.
Result: The options under Event Disposition become available and can be edited.
Step 4 To specify what you want Cisco Secure Policy Manager to do when an audit event of this type is triggered, click that option under Event Disposition.
For each audit event, you can define one of three rules:
Step 5 If you selected Discard event or Log event, skip to Step 6. If you selected Log event and issue notification specified below, continue with the Specify Pager and E-mail Notification Settings task in Cisco Secure Policy Manager Administrator's Guide: System Configuration and Maintenance.
Result: The Notification Scheduling, Notification Message, and Notification Methods group boxes appear in the Configure Notifications and Logging panel.
Step 6 To define the event filtering rules for additional audit events based on event classification, repeat Steps 3 through 5. Otherwise, continue with Step 7.
Step 7 To accept your changes and close the Configure Logging and Notifications panel, click OK.
Step 8 To save any changes that you have made, click Save on the File menu.
You can specify which audit events are recorded on the basis of specific audit events that are generated by agents and subsystems of Cisco Secure Policy Manager, including the Policy Enforcement Points installed on your network. Setting event filtering rules based on specific events, combined with any other event filtering rules based on event classifications or service statistics, identifies the information that is available for on-demand and scheduled reports.
To define event filtering rules based on specific events, perform the following task:
Result: The Configure Logging and Notifications panel appears in the View pane.
Step 2 To specify that you want to define event filtering rules on the basis of specific events, click Specific Events under Select Event Category.
Result: The list of events that is specific to the operation of Cisco Secure Policy Manager and the Policy Enforcement Points appears under Event Description. Audit events under this category identify individual events regarding the state of agents that compose Cisco Secure Policy Manager, as well as the state of the servers on which they run and the Policy Enforcement Points. By specifying event filtering rules for audit events in this category, you determine the availability of audit records that can be used by the Policy Report Point to generate summary and detailed event-based reports about the primary and secondary servers and Policy Enforcement Points installed on your network.
Step 3 To specify the audit event for which you want to define the event filtering rule, click that audit event in the Event Description list.
Result: The options under Event Disposition become available and can be edited.
This list of audit events identifies the audit events that can be detected by the Policy Enforcement Points and Cisco Secure Policy Manager servers installed on your network.
Step 4 To specify what you want Cisco Secure Policy Manager to do when an audit event of this type is triggered, click that option under Event Disposition.
For each audit event, you can define one of three rules:
Step 5 If you selected Discard event or Log event, skip to Step 6. If you selected Log event and also issue notification specified below, continue with the Specify Pager and E-mail Notification Settings task in Cisco Secure Policy Manager Administrator's Guide: System Configuration and Maintenance.
Result: The Notification Scheduling, Notification Message, and Notification Methods group boxes appear in the Configure Notifications and Logging panel.
Step 6 To define the event filtering rules for additional audit events based on specific events, repeat Steps 3 through 5. Otherwise, continue with Step 7.
Step 7 To accept your changes and close the Configure Logging and Notifications panel, click OK.
Step 8 To save any changes that you have made, click Save on the File menu.
You can specify which audit events are recorded for specific network services, such as HTTP and FTP. Setting event filtering rules based on service statistics, combined with any other event filtering rules based on event classifications or specific events, identifies the information that is available for on-demand and scheduled reports.
To define event filtering rules based on service statistics, perform the following task:
Result: The Configure Logging and Notifications panel appears in the View pane.
Step 2 To specify that you want to define event filtering rules based on service statistics, click Service Statistics under Select Event Category.
Result: The list of available network services appears under Event Description. Audit events under this category are grouped according to the network service for which they can occur. By specifying event filtering rules for audit events in this category, you determine the availability of audit records that can be used by the Policy Report Point to generate user-based and network service-based activity reports about the network sessions traversing the Policy Enforcement Points installed on your network.
|
Note You cannot define notifications for audit events based on the Service Statistics category. However, you can define notifications for audit events based on the Event Classifications and Specific Events categories. |
Step 3 To specify the network service for which you want to define the event filtering rule, click that network service in the Event Description list.
Result: The options under Event Disposition become available and can be edited.
This list of services corresponds directly to the list of services under the Network Services branch of the Tools and Services tree.
Step 4 To specify what you want Cisco Secure Policy Manager to do when an audit event of this type is triggered, click that option under Event Disposition.
For each audit event, you can define one of two rules:
Step 5 To define the event filtering rules for additional audit events based on service statistics, repeat Steps 3 and 4. Otherwise, continue with Step 6.
Step 6 To accept your changes and close the Configure Logging and Notifications panel, click OK.
Step 7 To save any changes that you have made, click Save on the File menu.
For audit events that are based on Event Classifications or Specific Events, you can specify event-specific notification rules that alert your staff via a pager service, e-mail, or the GUI client. In addition, you can execute custom scripts or executables that reside on the primary or secondary server that detects that the audit event has been triggered.
This procedure assumes that you have started defining an event filtering rule in the Configure Logging and Notifications panel and that you have selected a specific audit event based on either the Event Classifications or Specific Events category in the Event Description list.
If you have not begun defining a rule, refer to the corresponding section for step-by-step procedures that prepare you for this task:
To specify notification settings for event filtering rules, perform the following task:
Result: The Notification Scheduling, Notification Message, and Notification Methods group boxes appear in the Configure Notifications and Logging panel.
Step 2 To specify how many times the selected audit event can be triggered before the first notification is sent, type that value in the Issue first notification after box under Notification Scheduling.
Step 3 To specify how many times after the first notification the selected audit event can be triggered before another notification is published, type that value in the Notify again every box.
Each time this threshold value is reached, an additional notification is published to the targets that you specify for this notification rule.
Step 4 To specify how many hours should pass before the audit event count is reset to zero, type that value in the Reset count every box.
The audit event count is a system value that specifies how many times the selected audit event has occurred. When this value is reset, the system acts as if the audit event has never been triggered, which means that the first notification value must be satisfied before another notification is sent. This feature can be useful when you are aware of a recurring event, such as a TCP_SYN flood attack. In this example, you may want to set the repeat value to a large number so that you are not notified incessantly about something you are aware of; however, you may want to be notified once every hour if the attack is still in progress. Specifying one hour for this value would provide you with this information.
Step 5 To include a description of the event in the notification message, click Include event description under Notification Message.
Step 6 To define a custom message to include in the notification message, click Message under Notification Message.
Result: The Notification Message Content dialog box appears.
|
Note You can define custom messages that instruct the recipients of the notifications as to how they should respond to notifications of this type, or you can explain in greater detail the significance of the audit event so that the recipients do not overreact to notifications of lower importance. |
Step 7 To specify a description of the contents of this notification message, type that description in the Subject box and press Tab.
Result: The cursor appears in the Message box.
Step 8 To specify the message that you want to deliver to e-mail, alphanumeric pager recipients, and/or the GUI client each time a notification is published for the selected audit event, type that message in the Message box.
Step 9 To save any changes that you have made and close the Notification Message Content dialog box, click OK.
Step 10 To require that notifications of activity concerning the selected audit event be acknowledged by an administrator before being removed from the View Notifications panel, click Require confirmation under Notification Message.
The View Notifications panel is also available on the Tools menu. It maintains a list of audit events that are generated by the security system and provides a central location for evaluating activity of the security system. Currently, this option applies only to notifications that are published to the GUI client. You can specify which notifications are published to the GUI client under Notification Methods in Step 11.
Step 11 To specify which methods should be used to notify recipients of the selected audit event, select the check box for each option that applies under Notification Methods.
You can select one or any combination of four options:
Step 12 If you selected only Popup Window, skip to Step 24. However, if you selected E-Mail, Pager, or Script, continue with Step 13.
Step 13 If you selected E-Mail, continue with Step 14. Otherwise, continue with Step 17.
Step 14 To specify to whom the selected notification message should be delivered each time this notification is published, click Addresses under Notification Methods.
Result: The E-Mail Recipients dialog box appears.
Step 15 To specify the e-mail address of the recipient to whom you want to deliver the notification message, type that e-mail address in the Recipient(s) box.
Format all e-mail address entries like the following example:
username@domain.com
|
Note For the e-mail notifications to work, a MAPI client must be installed and running on the primary or secondary server that detects the audit event. An example MAPI client is the Microsoft Exchange client. For more information on installing MAPI and creating a user profile, see the Cisco Secure Policy Manager Administrator's Guide: System Configuration and Maintenance. |
If you wish to specify more than one recipient, click Add after you have typed the first entry. Repeat this process until you have defined the complete list of recipients. To delete a specific entry in the Recipient(s) list, select the entry and press the Delete key or click Delete. To modify an entry, select the entry and modify the value in the Recipient(s) box.
Step 16 To accept the changes that you have made and close the E-Mail Recipients dialog box, click OK.
Step 17 If you selected Pager, continue with Step 18. Otherwise, continue with Step 20.
Step 18 To specify the pager numbers to which the selected notification message should be delivered each time this notification is published, click Numbers under Notification Methods.
Result: The Pager Recipients dialog box appears.
Enter the pager number. Do not enter the "call-back" number or any other information here. Example: 5559876
|
Note Alphanumeric paging is not supported in this release. |
|
Note For the pager to work, a TAPI client must be installed and running on the primary or secondary server that detects the audit event. An example TAPI client is a modem. For more information on defining your TAPI settings, see the Cisco Secure Policy Manager Administrator's Guide: System Configuration and Maintenance. |
|
Note The modem must be installed on COM1. |
If you wish to specify more than one pager number, click Add after you have typed the first entry. Repeat this process until you have defined the complete list of pager numbers. To delete a specific entry in the Phone Number(s) list, select the entry and press the Delete key or click Delete. To modify an entry, select the entry and modify the value in the Phone Number(s) box.
Step 19 To accept the changes that you have made and close the Pager Recipients dialog box, click OK.
Step 20 If you selected Scripts, continue with Step 21. Otherwise, continue with Step 24.
Step 21 To specify the path and name of the scripts that should be executed each time this notification is published, click Name.
Result: The Notification Script(s) dialog box appears.
Step 22 To accept the changes that you have made and close the Notifications Script(s) dialog box, click OK.
Step 23 To define notification settings for additional audit events, select a different audit event in the Event Description list and return to Step 1. Otherwise, continue with Step 24.
Step 24 To accept your changes and close the Configure Logging and Notifications panel, click Apply.
Step 25 To save any changes that you have made, click Save on the File menu.
Posted: Fri May 26 14:13:33 PDT 2000
Copyright 1989 - 2000©Cisco Systems Inc.