Alerting: Step 3. Add Conditions to a Rule Statement

Document created by RSA Information Design and Development on Sep 12, 2017Last modified by RSA Information Design and Development on Oct 10, 2017
Version 5Show Document
  • View in full screen mode
 

This topic provides instructions to add conditions, such as specifying a certain time frame, to a rule statement. When you build a statement, you specify what a rule detects. You add conditions to make further stipulations, such as how many times or when the criteria must occur.

Example

The following graphic shows an example of the conditions for Rule Builder statements. Combined, the statements and conditions comprise the rule criteria.

Example of Rule Builder conditions

This rule detects 5 failed logon attempts followed by one successful logon, which could be the sign that someone has hacked into user account. This is the criteria for the rule:

  1. 5 failed logons are required.
  2. 1 successful logon must follow the failures
  3. A password was changed.
  4. All events must occur within 5 minutes.
  5. Group alerts by user (user_dst), because steps A and B must be performed on the same user destination account. Also, group by machine (device_class) to ensure that the user logged in from the same machine attempts to log into an account multiple times.
  6. The match is a strict pattern, meaning that the pattern must match exactly with no intervening events.  

Procedure

To add conditions to a rule statement:

  1. In the Conditions section, select a statement and click Edit icon.
  2. For Occurs, enter a value to specify how many occurrences are required to meet the rule criteria.
  3. If you have multiple statements, in the Connector field select a logical operator to join one statement to another:

    • followed by
    • not followed by
    • AND
    • OR
  4. Correlation Type applies only to followed by and not followed by. If you choose a correlation type of SAME, select one meta to correlate on, and if you choose a correlation type of JOIN, select two meta to correlate on. You may want to use JOIN if you are trying to correlate on meta from two different data sources. For example, say you want to correlate an AV alert with an IDS alert. See the examples below for a use case where two meta from different sources are joined.

  5. If events must happen within a specific timeframe, enter a number of minutes in the Occurs Within field.
  6. Choose whether the pattern must follow a Strict match or a Loose match. If you specify a strict match, this means that the pattern must occur in the exact sequence you specified with no additional events occurring in between. For example, if the sequence specifies five failed logins (F) followed by a successful login (S), this pattern will only match if the user executes the following sequence: F,F,F,F,F,S. If you specify a loose match, this means that other events may occur within the sequence, but the rule will still trigger if all of the specified events also occur. For example, five failed login attempts (F),  followed by any number of intervening successful login attempts (S), followed by a successful login attempt might create the following pattern: F,S,F,S,F,S,F,S,F,S which would trigger the rule despite the intervening successful logins.  
  7. Choose the fields to group by from the dropdown list. The Group by field allows you to group and evaluate the incoming events. For example, in the rule that detects 5 failed logon attempts followed by 1 successful attempt, the user must be the same, so user_dst is the Group By meta key.  You can also group by multiple keys. Using the previous example, you might want to group by user and machine to ensure that the same user logged in from the same machine attempts to log into an account multiple times.  To do this, you might group by device_class and user_dst.

Example

The following graphic shows an example of the conditions for a rule that allow you to evaluate the same entities across multiple devices so you can accomplish complex use cases. For example, you can create a rule that triggers if an IDS (Intrusion Detection System) alert is followed by an AV(Anti-virus) alert for the same workstation. The work station key is not the same between the two (IDS & AV) sources, so you can perform a JOIN in order to evaluate the different entities.

In the IDS alert, the workstation is identified by the source IP address from the IDS alert, and would be compared to the destination IP address from the AV alert.

Anti-virus (AV) Intrusion Detection System (IDS) rule

This is the criteria for the rule:

  1. An IDS alert occurs.
  2. The destination IP address from the AV alert and source IP address for the workstation from the IDS alert are joined to allow you to view the same entities across different sources.
  3. An Antivirus alert follows the IDS alert.
You are here
Table of Contents > Add Rules to the Rules Library > Add a Rule Builder Rule > Step 3. Add Conditions to a Rule Statement

Attachments

    Outcomes