Applies to Product:

USM Appliance™

LevelBlue OSSIM®

A correlation rule defines a condition to match incoming events. Refer to How Does Correlation Work? for details. The table below summarizes the attributes used in the rules.

Correlation Rule Attributes

Attribute	Attribute Type	Description
Name	String	Name of the rule. Each rule has its own name within the directive, and they can be the same.
Reliability	Number	The reliability value that the rule assigns to the event. It ranges from 0 to 10.
Timeout	Number	The waiting time (in seconds) before the rule expires and the correlation process using that rule stops. The default value is 300 seconds. The Timeout value for the first rule is None, indicating that the rule does not expire. None is not a valid entry for subsequent rules in the directive.
Occurrence	Number	Number of times an event has to occur in order for the rule to match.
From	String	Source IP and port(s) that the rule tries to match. In addition to a specific host name or IP, you may also see variables used in this field, such as ANY, HOME_NET (defined in Environment > Assets & Groups > Networks), SRC_IP, SRC_PORT, DST_IP, or DST_PORT.
To	String	Destination IP and port(s) that the rule tries to match. In addition to a specific host name or IP, you may also see variables used in this field, such as ANY, HOME_NET (defined in Environment > Assets & Groups > Networks), SRC_IP, SRC_PORT, DST_IP, or DST_PORT.
Data Source	String	Data source (or plugin) name and ID that the rule tries to match.
Event Type	String	Event type ID (SID) that the rule tries to match. When there are multiple SIDs specified, the rule tries to match any of them.
Sensor	String	The USM Appliance Sensor that sends the events.
Protocol	String	The protocol specified in an event. Accepted values are ANY, TCP, UDP, and ICMP.
Sticky Dif	List	Attributes in directive rules are sticky by default. This means that when a new event arrives at the correlation engine, USM Appliance correlates it with the previous event if the event attributes (such as IP address or port number) are the same. However, attributes in a directive can also be sticky different. When set, an arriving event needs to have a different value than the previous one in order to be correlated. For example, in port scanning attacks, if you set the destination port as sticky different, only events with different destination ports are correlated for the directive. Accepted values for this attribute are None, Plugin_sid, SRC_IP, DST_IP, SRC_Port, DST_Port, Protocol, and Sensor.
Username	String	The username specified in the event.
Pass	String	The password specified in the event.
Userdata1-Userdata9	String	The user data fields specified in the event.

By default, USM Appliance only displays the attributes up to Event Type. To see the additional attributes, click the More button. The majority of the built-in directives do not use these attributes.

To change which attributes to display

1. Click the […] next to the Event Type column.

   

   The Customize Columns window opens.

2. Select which attributes you want display in a rule.

   

3. Click Save.

Indentation of Rules

When a correlation directive contains multiple rules, the indentation of the rules reveals the relationship between the rules. Indented rules have an AND relationship while parallel rules have an OR relationship.

For example, the screenshot below shows one of the built-in directives, AV Network attack, too many dropped inbound packets from DST_IP, which detects network attacks by observing dropped packets from any source IP address to a specific destination IP address on the Cisco PIX firewall. This directive has three correlation levels (denoted by the black triangles) and four rules (all named Firewall dropped packets).

The first rule is matched when the cisco-pix plugin identifies a "PIX:Deny inbound (No xlate) string" (SID 106011) event. AND, if the second rule also matches, 3 more such events occur within 10 seconds toward the same destination, the reliability of the directive event increases to 4. AND, if the third rule also matches, 5 more such events occur within 20 seconds toward the same destination, the reliability increases to 6. OR, if the last rule matches, 10 more such events occurred within 30 seconds toward the same destination, the reliability of the directive event increases to 8.

Using Negation and Commas

You can use negation (inserting an exclamation point before an item) to exclude items in a rule. Commas can be used to separate items when creating lists. Specific considerations must be made when using commas and exclamation points together in lists. When using commas to separate multiple elements in a list, the list must consist of exclusively non-negated items, or only negated items, and not a combination of both. Because a negation implies anything which is not the item being negated, the inclusion of non-negated items in the same list will create a contradictory logic for the scope of the list. For example, using a negation such as plugin_sid="5901, !5902" states that the rule will occur when matched with the plugin signature ID of 5901, while simultaneously stating that everything that doesn't match plugin signature ID 5902 should be used to match the rule, creating a contradiction in what will trigger the event. This logic also extends to subsequent rules in the directive.

Using Attribute Values from the Previous Rule

When there are multiple rules in a directive, subsequent rules often use the same value set in the previous rule. In the example above, the "1:DST_IP" notation in the TO attribute means to keep using the same destination IP selected in the first rule, to look for attacks against the same host. You can manually select the destination IP again, or you can use the option From a parent rule: Destination IP from level 1:

You will find this option available when setting the Source, Source Port, Destination, Destination Port, Event Type (must select the data source first), and Sensor attributes. In addition, when editing String type attributes (see Correlation Rule Attributes), you can use the same <rule number>:<attribute name> notation. For example, "2:USERNAME" would mean to use the same user name chosen in the second rule.