A rule type determines the underlying behavioral patterns that a rule uses to identify a match. For example, if the rule type is set to Single Event, the rule evaluates each event for a criteria match. It only requires a single event to trigger a conclusion. A rule that uses the Many to One rule type evaluates each event against the criteria. However, it then creates a conclusion when a specified number of matching events have aggregated over a predetermined period of time.
See“About rule conditions”on page 88.
Conclusions that involve more than one event use the One to Many and Many to One event correlation tables. In addition, the Tracking field is provided. It identifies the element that is used as the basis for additional events to be correlated to existing events and conclusions.
Table 5-1describes the rule types that are available and provides examples.
Table 5-1 Rule types
Possible Scenarios Trigger Condition
Rule Type
Denial-of-service events can often be identified using this rule type.
A Smurf attack uses ICMP Echo Reply events from a large number of source computers to a single target.
Predefined rule examples:
Distributed DoS High Volume, Smurf Attack Creates a conclusion when the events
that match the specified criteria are detected from multiple unique source IP addresses to a single destination IP address within the specified period.
Many Sources, One Target
A rule that detects a vulnerability scan can use this rule type.
Within the criteria for that rule, EMR values can be set to identify multiple exploit events (such as Mechanism: Buffer Overflow, or Application Exploitation). In this example, the criteria for this rule includes multiple types of Mechanisms.
Therefore, the rule would track multiple types of exploit events coming from the same source.
Predefined rule example:
Vulnerability Scan Detector Creates a conclusion when the events
of different types that match the specified criteria are detected from a single source IP address within the specified period.
Many Symantec Signatures, One Source
A rule that detects malicious IP hopping activity can use this rule type.
To conceal scanning activity, an attacker may attempt one type of attack from one IP address. The attacker then changes to a different IP address to try a different attack until the most useful vulnerabilities have been identified. Attackers use this method to avoid detection as a vulnerability scan. Attackers know that vulnerability scanners often operate from a single source. Using this rule type, you can detect conditions where multiple attack types are targeted at a single host, regardless of the attack origin.
Creates a conclusion when events of different types matching the specified criteria are detected to a single destination IP address within the specified period.
Many Symantec Signatures, One Target
A rule that detects a Malicious Code Outbreak can use this rule type.
To identify a Malicious Code Outbreak, a rule can be configured to identify instances of a particular virus on multiple targets. Using the EMR fields, the criteria can be set to Virus. Since the rule looks for the same event type, this rule would trigger only if it was the same virus event on each target.
Creates a conclusion when events of the same type matching the specified criteria are detected from many unique destination IP addresses within the specified period.
Many Targets, One Event
A rule that identifies a reconnaissance attack on multiple targets (such as a port scan) can use this rule type.
To configure this example, you would choose the Many Targets, One Source rule type, and then set the EMR criteria value to Portscan.
Predefined rule examples:
Block Scan, IRC Bot Net, Ping Scan Detector Creates a conclusion when events
matching the specified criteria are detected from a single source IP address to multiple unique destination IP addresses within the specified period.
Many Targets, One Source
Table 5-1 Rule types (continued)
Possible Scenarios Trigger Condition
Rule Type
A rule to create a port sweep can use this rule type.
A port sweep is typically described as a single IP address that scans for a specific port on multiple computers. After you choose this rule type and set the event criteria for the rule, you set the One-Many and the Many-One field options. In the One-Many Fields area, select IP Source Address and IP Destination Port. This selection means that the event originates from the same IP address that is evaluating the same port). In the Many-One Fields area select the IP Destination Address option. (Note that the event destination can be a different IP address for each event.)
Predefined rule examples:
Malicious Code Outbreak, Spyware Outbreak, DoS High Volume, External Port Sweep, Internal Port Sweep, Port Scan Detector, Intrusion Threshold, Multiple Files Modified, Account Guessing Attack, Password Guessing Attack
Creates a conclusion when events matching the specified criteria are detected in a pattern that is set using the Many To One Fields, and the One To Many Field options.
In addition to the Event Criteria, the fields that must contain the same information for each event (One-Many Fields) and the fields that can contain different values in each event (Many-One Fields) are used to correlate similar events occurring within a predetermined timeframe.
The Many to One rule requires the Tracking field to be populated. For this type of rule, the Tracking field generally matches a One-Many Fields entry.
Many to One
User logs on to a Windows computer and establishes an SSH connection to a UNIX computer.
The user then logs on the FTP server, and downloads files from the FTP location.
Creates a conclusion when a sequence of specified patterns is detected for one combination of one-to-many fields within a specified time period.
Multi-condition
Predefined rule examples:
AntiVirus Disabled, Malicious Code Not Quarantined, Spyware Not Quarantined, Check FTP Transfers, Malicious URL, Trojan
Connections, Attempted DNS Exploit, Attempted FTP Exploit, Attempted WWW Exploit, TFTP from WebServer, WindowsSecurityViolationWindows Account Lockout, Windows Audit Log Cleared, Windows Privileged Activities by User Creates a conclusion if an event
matches the specified criteria. This rule type requires the Tracking field to be populated.
Single Event
A rule that identifies BackOrifice exploit traffic between a single target and source can use this rule type. To monitor for BackOrifice symmetric traffic events, after you choose the Symmetric Traffic rule type, set the criteria to Symantec Signature for BackOrifice (attackID 1414). The rule triggers if an Intrusion Detection System logs both the connection from a source to a target, and from that target back to the source as being BackOrifice traffic.
Predefined rule example:
Return Trojan Traffic Creates a conclusion when the specified
pattern of events is detected from a single source IP address to a single destination IP address, then from that destination IP address back to the original source IP address within the specified period.
Symmetric Traffic
A rule that identifies the BackOrifice exploit traffic that moves from one source to a target backdoor, and then the targeted computer becomes the source that accesses the backdoor of a new target can use this rule type.
To monitor for BackOrifice transitive traffic events, after you choose the Transitive Traffic rule type, set the criteria to Symantec Signature for BackOrifice (attackID 1414). The rule triggers if an Intrusion Detection System logs both the connection from a source to a target as BackOrifice traffic and then identifies the target connecting to a new target with the same event signature.
Predefined rule example:
Malicious Code Propagation Creates a conclusion when the specified
pattern of events is detected from a single source IP address to a single destination IP address. Then, the pattern is detected from that destination IP address to a new destination IP address within the specified period.
Transitive Traffic
Predefined rule examples:
Scan Followed by Exploit, Null Login Authentication Violation
Note:This rule is deprecated and is not supported.
Use a Multi-condition rule type.
Creates a conclusion when a specified pattern is detected from a single source IP address to a single destination IP address. This pattern is followed by a different pattern from the same source IP address to the same destination IP address within the specified time period.
X followed by Y
Table 5-1 Rule types (continued)
Possible Scenarios Trigger Condition
Rule Type
A rule to monitor user authentication failure for a specific period of time can use this rule type.
User logon fails for a specific period of time and the user does not log in again.
Creates a conclusion when an event that matches the defined criteria cannot be detected in a pattern during a predefined number of times during timeout.
X not followed by X
A rule to detect a non-occurrence of a user action after a valid user action can use this rule type.
User logs on to a critical server but does not log off for a long time.
Creates a conclusion when an event occurs that is defined by an X rule criteria. However, an event that is defined by the Y rule criteria does not.
X not followed by Y
A rule to detect a deletion of user before the user is added can use this rule type.
Creates a conclusion when an event that is defined by an X rule criteria does not occur. However, the next event that is defined by the Y rule criteria occurs.
Y not preceded by X
A rule to dynamically update the lookup table with the configured event field values for the specified event criteria.
Updates the configured lookup table if an event matches the specified criteria.
Lookup Table Update