Running Historical Searches to Test Rule Sub Patterns

If you are trying to analyze why a rule is triggering an excessive number of incidents, or why it isn’t triggering any, you can run an historical search with the rule sub patterns to see how the sub pattern behaves in relation to past events. If the search has interesting results, you can then generate a report for further investigation. This is a way that you can test rules without having to deactivate them.

1. Go to Analytics > Rules.
2. Select a rule and then click Edit.
3. Click Edit next to the sub pattern you want to use in the search.
4. Click Run as Query.
5. Enter information for the time period you want to search.
6. Click OK.

An historical search will run based on the sub pattern filters, aggregate conditions, and group by conditions.

Using a Sub Pattern in a Report

If the search includes results that you want to share or investigate further, you can save the rule as a report.

1. In the sub pattern you want to save, click Save as Report.

The report will be saved in Analytics > Reports, and will have the phrase From Rule in the report name.

2. Select the report and click Run Now to generate a report from the sub pattern.

Cloning a Rule

You can clone a rule to use it as the basis for creating another rule, or to use in testing.

1. Log in to your Supervisor node.
2. Go to Analytics > Rules.
3. Search or browse to select the rule you want to clone.
4. Click Clone.
5. Enter a new name for the cloned rule and click OK.

The cloned rule will be added to the same group as the original rule but will be inactive.

Adding a Watch List to a Rule

1. Go to Analytics > Rules.
2. Select the rule you want to add the watch list to, and then click Edit.
3. Next to Watch Lists, click Edit.
4. Select the watch list you want to add, and use the Add >> button to add it to the rule.
5. For Incident Attribute, select the incident information you want to add to the watch list.

Watch List Attribute Type Must Match Incident Attribute

The Type that you set for the watch list must match the Incident Attribute Types for the rule. For example, if your watch list Type is IP, and the Incident Attribute Type for the rule is string, you will not be able to associate the watch list to the rule.

6. Click OK.

Next to Watch Lists, you will see Watch List has been defined.

Activating and Deactivating Rules

When you create a new rule, you must activate it before it will start to monitor events. You may also want to deactivate a rule, for example to test it, instead of deleting it from the system.

1. Log in to your Supervisor node.
2. Go to Analytics > Rules.
3. Browse or search to find the rule that you want to activate or deactivate.
4. Select Active for the rule you want to activate, or clear the Active option if you want to deactivate a rule.

Testing a Rule

After you’ve created or a edited a rule, you should test it to see if behave as expected before you activate it. This topic describes how to test a rule using synthetic events.

Procedure

Test Results

Test Example

Troubleshooting for Rule Testing

Rule Syntax Error

Rule Semantics Error

Event Parsing Error

Procedure

1. Go to Analytics > Rules, and deactivate the rule you want to test.
2. Select the rule, and then click Test Rule.

This will open the Rule Debugger.

3. Enter a Reporting IP where the synthetic event should originate from.
4. Under Raw Event, enter the raw event log text that contains the triggering conditions for the rule.
5. Under Pause, enter the number of seconds before the next test event will be sent, and then click + under Action to enter additional test events.

You will need to create as many events as are necessary to trigger the rule conditions.

6. Click Run Test.

If the test succeeds you are now ready to activate the rule.

Test Results

The test will run through a four stage process, which you can observe in the Test Results tab of the rule. A yellow icon will also appear in the Stat us column for the rule to indicate that the test is running.

1. Rules are checked for syntax errors.
2. Events are parsed and sent to Rule Workers.

If there are errors in the rule syntax or event parsing errors, see the examples under Troubleshooting for Rule Testing for suggestions on how to correct them. As events are being parsed, you can view their Event Details by clicking on the Raw Event Log icon next to the event.

3. Rule Worker nodes evaluate the events against the rule conditions, and if they match, they are sent to the Rule Master.
4. The Rule Master creates incidents, which then appear in the Incidents dashboards.

When the test successfully completes, a green icon will appear in the Status column next to the rule name.

Test Example

This screenshot shows the example of a test for the rule Multiple Admin Login Failures: Net Devices. The conditions for this rule are that the the Reporting IP must belong to a network device, and there must be 3 login failure events from the same IP and user.

Troubleshooting for Rule Testing

If the test fails, a red icon will appear under the Status column next to the rule name, and you will see the error message in the Test Results tab for the rule.

Rule Syntax Error

Rule Semantics Error

This means that the conditions of the rule were not met by the event. For example, if five events were required to meet the condition, but only one was sent.

Event Parsing Error

This means that some text in the raw event log did not pass the event parser. For example, if “denied” is the term expected by the parser in the test example, but the raw event log contains the term “deny,” then the event will not pass the parser.

Defining Clear Conditions

Clear conditions specify conditions in which incidents will have their status changed from Active to Cleared. You can set the time period that must elapse for the clear condition to occur, and then set the conditions based on the triggering of the original rule, or on a sub pattern based on t he Incident Attributes.

1. In Analytics > Rules, select the rule you want to add the clear condition to, and click Edit.
2. Next to Clear Condition, click Edit.
3. Set the Time Period that should elapse for the clear condition to go into effect.
4. If you want the clear condition to go into effect based on the firing of the original rule, select the Original Rule Does Not Trigger. For example, if you wanted the clear condition to change the status of Active incidents to Cleared after the original rule had not been triggered for ten minutes, you would set Cleared Within to 10 Minutes and select this option.
5. If you want to base the clear condition on a sub-pattern of the incident attributes, select the following conditions are met.

The incident attributes from your rule will load and the clear condition attributes will be set to match.

6. Define the pattern to use by clicking the Edit icon next to the clear sub pattern.
7. Click Save.

Defining Rule Exceptions

Once you activate a rule, it continuously monitors your IT infrastructure for conditions that would trigger an event. However, you may also want to define exceptions to those conditions. For example, you may know that a server will be going down for maintenance during a specific time period and you don’t want your Server Down – No Ping Response rule to trigger an incident for it.

1. In Analytics > Rules, select the rule you want to add the exception to, and click Edit.
2. Next to Exceptions, click Edit.
3. Select an Attribute and Operator, and enter a Value, for the conditions that will prevent an incident from being generated.

The values in the Attribute menu are from the Event Attributes associated with the incident definition.

4. Click the + icon to set an effective time period for the exception.

You can set effective time periods for single and recurring events, and for durations of time from hours to days.

5. Enter any Notes about the exception.

Defining the Incident Generated by a Rule

Defining an incident involves setting attributes for the incident based on the subpatterns you created as conditions for the rule, and then setting attributes for the incident that will be used in analytics and reports.

1. In the rule you want to define an incident for, click Edit next to Actions: Generate Incident.
2. Enter an Incident Name, Display Name, and Description.
3. Under Incident Attributes, you will define attributes for the incident based on the Group By and Aggregate Conditions attributes you set for your sub patterns. Typically you will set the Incident attributes to be the same as the Group by attributes in the subpattern. a. Select the Event Attribute you want to add to Incident.
   1. Select a Subpattern.
   2. This will populate values from the Group By attributes in the subpattern to the Filter Attribute
   3. In the Filter menu, select the attribute you want to set as equivalent to the Event Attribute.
4. Under Triggered Event Attributes, select the attributes from the triggering events that you want to include in dashboards and analytics for this event.

This is pre-populated with typical attributes you would want included in an incident report.

5. Click OK.