Using Monitoring Center for Security 1.2
Defining Notifications
Download this chapter
Defining NotificationsDefining Notifications
Download the complete book
Using Monitoring Center for Security 1.2 (whole book PDF)Using Monitoring Center for Security 1.2 (whole book PDF) (PDF - 2 MB)
give_us_feedback

Table of Contents

Defining Notifications
About Executing a Script from a Database Rule or Event Rule
 About Intervals and Thresholds
 Adding an Event Rule
 Viewing Event Rule Details
 Editing an Event Rule
 Activating an Event Rule
 Deactivating an Event Rule
 Deleting an Event Rule

Defining Notifications

When one or more security devices are deployed to protect a network, they can generate large amounts of event data. Monitoring this data for specific events or a specific pattern of events can be difficult. Security Monitor uses event rules to monitor for specific events or patterns of events.

Event rules have three parts:

  • Event filters.
  • The action that you want to occur when filter conditions are met.
  • The thresholds and intervals for the actions you define.

Event rules allow you to define filters for the event data generated by your monitored devices and to specify an action to occur when filter conditions are met. The actions available are:

  • Sending an e-mail notification.
  • Logging a console notification to the audit log.
  • Executing a script.
    • Note   Event rules use IDS events, which can come from a sensor (appliance or module), a PIX Firewall, a Cisco router running Cisco Intrusion Detection System software, or a Cisco IDS Host Console. Event rules do not use firewall events, which can come from a PIX Firewall or a Cisco IOS device running the firewall feature set. However, firewall events are collected and stored in the database by Security Monitor.

Refer to the following topics for more information about defining notifications:

About Executing a Script from a Database Rule or Event Rule

One of the actions you can select from the Choose the Actions page is Execute a Script. If you select Execute a Script, you must select a script from the Script File list box.

Security Monitor has the following scripts:

Tip All available scripts appear in the database rule wizard and the event rule wizard. However, the LegacyIf.pl script is applicable only to event rules. The remainder of the scripts should be used for database rules.
  • LegacyIf.pl—Provides an interface to the scripts. The LegacyIf.pl script executes a query against the database and outputs all matching alarms for the event filter to a temp file. It then finds the most recent alarm in the set, parses the alarm fields, and calls the Security Monitor script with the alarm field arguments.
Note    The alarm data passed to the script is not necessarily the exact alarm that crossed the threshold due to the intervals used for threshold processing.
Note    Security Monitor provides local and UTC timestamps in time_t format, but this data is not available via the LegacyIf.pl script. These values are passed to the script as 0 every time.

Use as follows:

ScriptName "${Query}" ${MsgCount}

You can use the following options in the script argument:

    • ScriptName (Required)—Specifies the full path to the script that you want to run. The script is a user-authored script that must be saved on the Security Monitor server. We recommend that you save it in the X:\Program Files\CSCOpx\MDC\etc\ids\scripts folder, where X is the drive where Security Monitor is installed.
    • ${Query} (Required)—Specifies a time-bounded, syntactically correct SQL expression that can be used in the WHERE clause of a database query to select the set of alarms that caused the rule to trigger this time. You must surround this option in quotation marks (" ") for the script to execute correctly.
    • ${MsgCount} (Required)—Specifies the number of matches that occurred in the current interval to trigger this rule.
  • PruneDefault.pl—Prunes the table until the specified number of events remains. Pruning begins when the number of events in the table exceeds a defined amount. By default, the script orders the events in the table based on time and prunes the oldest events. Use as follows:

PruneDefault.pl number tablelist [-o] [-w"archive location"]

  • number—Prunes the table to this number. The default is 1,800,000.
  • tablelist—Specifies the type of table to be pruned. You can choose from the following table types:
  • syslog—SYSLOG event table.
  • alert—Alert table.
  • auditlog—Audit log table.
  • deploy—Deployment jobs table.
  • sysconfig—System configuration table.

The default is alert,syslog.

  • -w"archive location"—Specifies the directory where pruned data is archived before it is deleted from the database. To specify the archive directory, use the -wd:\temp argument format, where d: specifies a mapped disk drive and \temp specifies the directory where the archive data is stored.
Caution   Verify that the archive directory has sufficient disk space to store the archive data. If you use the PruneDefault.pl script to prune data from the database due to insufficient disk space, do not specify an archive directory on the same disk drive as the database.
  • -o—Archives the data without pruning it from the database.
Note    To use the -o option, you must specify a value for -w"archive location".
  • PruneByAge.pl—Prunes alarms older than the specified number of days from the specified tables. Use as follows:

PruneByAge.pl age "tablelist" [-o] [-w"archive location"]

You can use the following options in the script argument:

  • age—Specifies the number of days. The default is 20.
  • tablelist—Specifies the type of table to be pruned. You can list multiple tables in a comma-delimited list. You can choose from the following table types:
  • syslog—SYSLOG event table.
  • alert—Alert table.
  • auditlog—Audit log table.
  • deploy—Deployment jobs table.
  • sysconfig—System configuration table.

The default is all tables ("syslog,alert,auditlog,deploy,sysconfig").

  • -w"archive location"—Specifies the directory where pruned data is archived before it is deleted from the database. To specify the archive directory, use the -wd:\temp argument format, where d: specifies a mapped disk drive and \temp specifies the directory where the archive data is stored.
Caution   Verify that the archive directory has sufficient disk space to store the archive data. If you use the PruneByAge.pl script to prune data from the database due to insufficient disk space, do not specify an archive directory on the same disk drive as the database.
  • -o—Archives the data without pruning it from the database.
Note    To use the -o option, you must specify a value for -w"archive location".
  • PruneByDate.pl—Prunes alarms from the specified tables generated on and before the specified date. Use as follows:

PruneByDate.pl "date" "tablelist" [-o] [-w"archive location"]

You can use the following options in the script argument:

  • date (Required)—Specifies the date to delete alarms on and before. The date format is "MM/DD/YYYY,HH:MM".
  • tablelist—Specifies the type of table to be pruned. You can list multiple tables in a comma-delimited list. You can choose from the following table types:
  • syslog—SYSLOG event table.
  • alert—Alert table.
  • auditlog—Audit log table.
  • deploy—Deployment jobs table.
  • sysconfig—System configuration table.

The default is all tables ("syslog,alert,auditlog,deploy,sysconfig").

  • -w"archive location"—Specifies the directory where pruned data is archived before it is deleted from the database. To specify the archive directory, use the -wd:\temp argument format, where d: specifies a mapped disk drive and \temp specifies the directory where the archive data is stored.
Caution   Verify that the archive directory has sufficient disk space to store the archive data. If you use the PruneByAge.pl script to prune data from the database due to insufficient disk space, do not specify an archive directory on the same disk drive as the database.
  • -o—Archives the data without pruning it from the database.
Note    To use the -o option, you must specify a value for -w"archive location".
  • PruneBySeverity.pl—Prunes alarms of the specified severity from the specified tables. This script is order specific. You must specify the severity before you specify the table list. Use as follows:

PruneBySeverity.pl "severitylist" "tablelist" [-o] [-w"archive location"]

You can use the following options in the script argument:

  • severitylist—Specifies the severity level of the alarms to prune. You can choose from the following severity levels:
  • h—High severity.
  • m—Medium severity.
  • l—Low severity.
  • i—Informational severity.

The default is "i,l,m".

  • tablelist—Specifies the type of table to be pruned. You can list multiple tables in a comma-delimited list. You can choose from the following table types:
  • syslog—SYSLOG event table.
  • alert—Alert table.
  • auditlog—Audit log table.

The default is all tables ("syslog,alert,auditlog").

  • -w"archive location"—Specifies the directory where pruned data is archived before it is deleted from the database. To specify the archive directory, use the -wd:\temp argument format, where d: specifies a mapped disk drive and \temp specifies the directory where the archive data is stored.
Caution   Verify that the archive directory has sufficient disk space to store the archive data. If you use the PruneByAge.pl script to prune data from the database due to insufficient disk space, do not specify an archive directory on the same disk drive as the database.
  • -o—Archives the data without pruning it from the database.
Note    To use the -o option, you must specify a value for -w"archive location".
  • PruneMarkedForDeletion.pl—Prunes alarms already marked for deletion from the specified tables. Use as follows:

PruneMarkedForDeletion.pl "tablelist" [-o] [-w"archive location"]

You can use the following option in the script argument:

  • tablelist—Specifies the type of table to be pruned. You can list multiple tables in a comma-delimited list. You can choose from the following table types:
  • syslog—SYSLOG event table.
  • alert—Alert table.
  • auditlog—Audit log table.

The default is all tables ("syslog,alert,auditlog").

  • -w"archive location"—Specifies the directory where pruned data is archived before it is deleted from the database. To specify the archive directory, use the -wd:\temp argument format, where d: specifies a mapped disk drive and \temp specifies the directory where the archive data is stored.
Caution   Verify that the archive directory has sufficient disk space to store the archive data. If you use the PruneByAge.pl script to prune data from the database due to insufficient disk space, do not specify an archive directory on the same disk drive as the database.
  • -o—Archives the data without pruning it from the database.
Note    To use the -o option, you must specify a value for -w"archive location".
  • PruneSpecifyCmdLine.plxd1 Prunes alarms from the specified tables using the specified alarms. Use as follows:

PruneSpecifyCmdLine.pl -r"tablelist" [-p] [-t"date"] [-a#] [-s"severities"] [-w"dirname"] [-o]

You can use the following options in the script argument:

  • -r"tablelist" (Required)—Specifies the type of table to be pruned. You can list multiple tables in a comma-delimited list. You can choose from the following table types:
  • syslog—SYSLOG event table.
  • alert—Alert table.
  • auditlog—Audit log table.
  • deploy—Deployment jobs table.
  • sysconfig—System configuration table.

For example, -r"alert,syslog".

  • -p (Optional)—Prunes all records marked for deletion in the specified table. By default, alarm records are not pruned from the database.
  • -t"date" (Optional)—Prunes all records created before the specified date from the specified table. The date format is MM/DD/YYYY,HH:MM.
Note    You cannot use -t"date" and -a# in the same argument.
  • -a# (Optional)—Prunes all records that are older than the specified number of days from the database, where # is a positive integer representing the number of days old.
Note    You cannot use -t"date" and -a# in the same argument.
  • -s"severity" (Optional)—Prunes all records with the specified severity from the specified table. You can list multiple severities in a comma-delimited list.
  • h—High severity.
  • m—Medium severity.
  • l—Low severity.
  • i—Informational severity.

For example, -s"i,l,m".

  • -w"dirname" (Optional)—Outputs comma-delimited files to the specified directory. There is one file output for each table specified.
  • -o (Optional)—Outputs all records to a file. No records are deleted if you select this option. You must also specify -w"dirname" for a location to save the output file.

Additionally, you can add your own custom scripts. To add a custom script, place your script file in the X:\Program Files\CSCOpx\MDC\etc\ids\scripts folder, where X is the drive where Security Monitor is installed. If you add your script to this folder, it appears in the Script File list box.

Caution   Security Monitor cannot verify the validity of scripts or that scripts execute as expected. A poorly written custom script can potentially crash your system.

About Intervals and Thresholds

A combination of two types of intervals is used for threshold processing: sliding intervals and stand-off intervals. The first interval is a sliding interval to detect the initial trigger threshold, which prevents an initial threshold from being missed due to the expiration of a fixed interval. For example, given an interval of one hour and an initial threshold of 100, if 99 matches were detected in minute 59 of interval A and another 99 were detected in minute 1 of interval B, no threshold would be triggered. This is in all likelihood not what the user intended. Using a sliding interval, however, the threshold would be triggered any time 100 matches were detected in the past hour.

The sliding interval is divided up into a fixed number of discrete sampling intervals or buckets. Each database query returns a count of matches within that bucket. A running total of all buckets is maintained and compared against the initial threshold. The value of the oldest bucket is subtracted from the total before the newest bucket is added in, thus providing the sliding interval.

If Security Monitor does not gain control of the processor for an amount of time greater than a sampling interval, it loops until it catches up to current time. Thus, an initial threshold trigger that occurred while Security Monitor was blocked from the processor is still reported (along with the time it occurred), although late.

Note   The discrete sampling mechanism introduces some error versus a pure analog count, but because the interval times are typically on the order of hours and the sampling interval is on the order of minutes, this error is negligible. The use of a sliding interval mechanism reduces this margin of error by an order of magnitude over the error potential with the fixed interval approach.

When the initial threshold is crossed, the repeat threshold in the stand-off interval begins, anchored at the current time. This interval is used for handling repeat threshold(s), and provides a means for allowing a particular activity to return to normal levels. This interval is the same length as the sliding interval.

When the stand-off interval expires, a new sliding interval is established and detection of the initial threshold resumes. All counters are reset at this time.

When a rule is read from the database for the first time, its sliding interval begins at that time. At subsystem initialization time, then, all activated rules have a common starting point for their intervals. If you edit a rule, its sliding interval is reset to the current time. However, the intervals of other (unchanged) active event rules are not disturbed.

Adding an Event Rule

Adding an event rule defines the parameters and actions for the event rule. For the actions that you specify to occur, you must activate the event rule.

To add an event rule, follow these steps:

Step 1   Select Admin > Event Rules.

The Event Rules page appears.

Step 2   Click Add.

The Identify the Rule page appears.

Step 3   Enter a name for your event rule in the Rule Name field. You can also describe the rule in the Description field. Then, click Next.

The Specify the Event Filter page appears.

Step 4   Specify the clauses for the event filter of the event rule. You can specify up to five clauses per event filter. Define one clause per line.

Note    The event filter that is part of an event rule in Security Monitor should not be confused with filters for a sensor in the IDS MC.

a. Select an option from the list box in the first column. You can choose from the following options:

  • Originating Device
  • Originating Device Address
  • Attacker Address
  • Victim Address
  • Signature Name
  • Severity
  • Signature Id

b. Select a relational comparison operator from the list box in the middle column.

c. Depending on the option you selected in Step a, you will either select an option from a list box or enter a value for the field in the third column.

  • If you selected Originating Device, select a device from the list box. The list includes monitored devices that you have added to Security Monitor.
  • If you selected Originating Device Address, you must enter the IP address.
  • If you selected Attacker Address or Victim Address, you must enter the IP address.
  • If you selected Signature Name, select a signature from the list box.
  • If you selected Severity, select a severity from the list box.
  • If you selected Signature Id, enter a number between 1 and 65,535. By default, all subsignature IDs are included for the signature that you enter. To specify a specific subsignature ID, enter a number between 1.x and 65,535.x, where x is the subsignature ID. The value of x must be between 0 and 65,535.

d. Repeat Step a through Step c for each clause you want to add. If you add more than one clause, you must also specify a logical operator from the list box between the rows of each clause you define. The logical operators specify the relationships between the clauses. Click Show Filter to incorporate the clauses into the filter.

Tip You can also enter and edit clauses directly in the box at the bottom of the page. If you enter and edit clauses directly in the box, do not click Show Filter. If you click Show Filter, your changes are lost.

e. Click Next.

The Choose the Actions page appears.

Step 5   Specify the action that Security Monitor should take when the event filter defined in Step 4 is detected. You can specify multiple actions. Then, click Next.

a. To send an e-mail notification when the specified threshold is met, select the Notify via Email check box. Then, enter the e-mail address for the recipient in the Recipient(s) field. Use commas to separate multiple e-mail addresses. Enter the subject for the message in the Subject field and the message text in the Message field.

Note    The e-mail message text is limited to 32,765 characters. If you enter more than that, Security Monitor notifies you that the message is too long and will be truncated to the maximum number of characters allowed.

You can use the keyword substitutions listed in Table 5-1 to fill in the Subject and Message fields:

Keyword Description

${RuleName}

The name of the event rule.

${RuleDescr}

The description of the event rule.

${Filter}

The query filter for the event rule.

${Interval}

The query interval for the event rule.

${Initial}

The initial threshold for the event rule.

${Repeat}

The repeat threshold for the event rule.

${DateStr}

Date stamp for when the event rule was triggered, based on the server local time. The date stamp is in YYYY/MM/DD format.

${TimeStr}

Time stamp for when the event rule was triggered, based on the server local time. The time stamp is in HH:MM:SS time zone format, where HH is in 24-hour form.

${GmtDateStr}

The Coordinated Universal Time (UTC) date stamp for when the rule was triggered, in YYYY/MM/DD format.

${GmtTimeStr}

The UTC time stamp for when the event rule was triggered in HH:MM:SS time zone format, where HH is in 24-hour form and time zone is always UTC.

${MsgCount}

The number of matches that occurred in the current interval causing this rule to be triggered.

${Threshold}

The threshold that was met, causing the event rule to be triggered. This value is the same as the value for either ${Initial} or ${Repeat}.

${Query}

A time-bounded, syntactically correct SQL expression that can be used in the WHERE clause of a database query to select the set of alarms that caused the rule to trigger this time.

${IntervalCount}

The number of new matching alarms that have been detected causing the rule to trigger this time. This is the number of records that is expected to be returned by a query using the ${Query} keyword.

${RepeatCount}

The number of times the rule has triggered on the repeat threshold. A value of 0 indicates that the rule was triggered on the initial threshold.

Note The keyword matching (inside the braces) is case-insensitive.
Keyword Description

${RuleName}

The name of the event rule.

${RuleDescr}

The description of the event rule.

${Filter}

The query filter for the event rule.

${Interval}

The query interval for the event rule.

${Initial}

The initial threshold for the event rule.

${Repeat}

The repeat threshold for the event rule.

${DateStr}

Date stamp for when the event rule was triggered, based on the server local time. The date stamp is in YYYY/MM/DD format.

${TimeStr}

Time stamp for when the event rule was triggered, based on the server local time. The time stamp is in HH:MM:SS time zone format, where HH is in 24-hour form.

${GmtDateStr}

The Coordinated Universal Time (UTC) date stamp for when the rule was triggered, in YYYY/MM/DD format.

${GmtTimeStr}

The UTC time stamp for when the event rule was triggered in HH:MM:SS time zone format, where HH is in 24-hour form and time zone is always UTC.

${MsgCount}

The number of matches that occurred in the current interval causing this rule to be triggered.

${Threshold}

The threshold that was met, causing the event rule to be triggered. This value is the same as the value for either ${Initial} or ${Repeat}.

${Query}

A time-bounded, syntactically correct SQL expression that can be used in the WHERE clause of a database query to select the set of alarms that caused the rule to trigger this time.

${IntervalCount}

The number of new matching alarms that have been detected causing the rule to trigger this time. This is the number of records that is expected to be returned by a query using the ${Query} keyword.

${RepeatCount}

The number of times the rule has triggered on the repeat threshold. A value of 0 indicates that the rule was triggered on the initial threshold.

Note The keyword matching (inside the braces) is case-insensitive.

b. To log a console notification to the audit log when the specified threshold is met, select the Log a Console Notification Event check box. Then, enter your user name in the User Name field. Select an alarm event level from the Severity list box and enter a message in the Message field. You can use the keyword substitutions listed in Table 5-1.

Tip To view the console notification messages, run the Console Notification Report on the Reports > Generate page.

c. To execute a script when the specified threshold is met, select the Execute a Script check box. Then, select a script from the Script File list box. You can enter any required arguments in the Arguments field.

Note    The scripts included with Security Monitor are for database pruning and are more applicable for database rules than event rules. However, you can add custom scripts to the list.
Tip You can use the keyword substitutions listed in Table 5-1 in the Arguments field. If you use a keyword substitution that contains spaces in its replacement value, surround the keyword in quotation marks to preserve the atomicity of the data. For example, a script specified as
myScript ${RuleDesc}
might be expanded to
myScript This is a description.
However, a script specified as
myScript "${RuleDesc}"
would be expanded to
myScript "This is a description."
Depending on whether you use quotation marks, the script has different behaviors.

The Specify the Thresholds/Intervals page appears.

Tip Keyword substitution applies only to e-mail notification sent from event rules—not e-mail notification sent by database rules (or by reports).

Step 6   Specify the thresholds and intervals that determine when Security Monitor takes the action you defined in Step 5. Then, click Finish.

a. To take the specified action after the event filter occurs more than a specified number of times, specify a number in the Issue action(s) after (#event occurrences) field. This value specifies the initial trigger threshold.

b. To repeat the specified action at regular intervals after the initial trigger threshold in Step 6a is met, specify a number in the Repeat action(s) again after (# event occurrences) field.

c. Specify in minutes how often to reset the count for measuring when the threshold is met in the Reset count every (minutes) field.

The event rule is added.




Viewing Event Rule Details

This procedure provides the basic steps for viewing detailed information for an event rule. You cannot edit event rules from the View Event Rule page.

To view a event rule detail information, follow these steps:

Step 1   Select Admin Event Rules.

The Event Rules page appears.

Step 2   Click the radio button next to the event rule that you want to view.

Step 3   Click View.

The View Event Rule page appears. Detailed information about the event rule appears in the View Event Rule text box.

Step 4   Click OK to return to the Event Rules page.




Editing an Event Rule

You can edit any event rules that you have added to Security Monitor.

Note   You can edit active and deactivated rules. However, if your edits make an active event rule invalid, the rule is deactivated. For example, if you remove the filter or action of an event rule, the rule becomes deactivated.
Note   In Security Monitor 1.0 (but not 1.1 and later), if you create an event rule that references an originating device and you then change the name of that originating device, you will no longer be able to access event rules. If you attempt to access the event rules page, the following error message will result: The object could not be reset—invalid filter—device not found: old name. To avoid this problem (which occurs in Security Monitor 1.0 only), delete the event rule before renaming the device and then rebuild the event rule.

To edit an event rule, follow these steps:

Step 1   Select Admin > Event Rules.

The Event Rules page appears.

Step 2   Click the radio button next to the event rule that you want to edit. Then, click Edit.

The Identify the Rule page appears.

Step 3   Click Next and Back to navigate between the event rule pages.

Note    If you make changes on the Specify the Event Filter page, you must click Show Filter. If you do not click Show Filter, your changes to the filter clauses are not saved.

Step 4   To save your changes, click Finish.




Activating an Event Rule

For the actions that you specify in an event rule to occur, you must activate the event rule. You can have up to ten activated event rules.

Note   If the event rule does not contain an event filter and an action, you cannot activate it, and you receive an error message. Edit the event rule to complete the missing fields, and then activate it.

To activate an event rule, follow these steps:

Step 1   Select Admin > Event Rules.

The Event Rules page appears.

Step 2   Click the radio button next to the event rule that you want to activate.

Tip If you see the word "yes" in the Active column for the event rule, the event rule is already activated.

Step 3   To activate the selected event rule, click Activate.

The selected event rule is activated. The word "yes" appears in the Active column of the activated event rules.




Deactivating an Event Rule

Deactivate an event rule if you do not want the specified action to occur for the specified event.

Tip If an event rule is active, the word "yes" appears in the Active column on the Event Rules page.

To deactivate an event rule, follow these steps:

Step 1   Select Admin > Event Rules.

The Event Rules page appears.

Step 2   Click the radio button next to the event rule that you want to deactivate. Then, click Deactivate.

The selected rule is deactivated.




Deleting an Event Rule

You can delete any unwanted event rules.

To delete an event rule, follow these steps:

Step 1   Select Admin > Event Rules.

The Event Rules page appears.

Step 2   Click the radio button next to the event rule that you want to delete. Then, click Delete.

Warning You are not prompted to confirm the deletion. Additionally, you cannot recover a deleted event rule.

The selected event rule is deleted.