Step 3. Add Conditions to a Rule Statement

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.

netwitness_rbcond5f1spwdchngrllow_672x155.png

​​

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 (ip_src) 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.

Add Conditions to a Rule Statement

  1. In the Conditions section, select a statement and click netwitness_edit_icon_22x22.png.
  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 in to an account multiple times. To do this, you might group by user_dst and ip_src.

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.

netwitness_av_ids_rule_617x107.png​​

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.

Validate an ESA Rule

You can confirm that an ESA rule generates the expected alerts by testing the rule logic using JSON input data. You can view the alerts in the output, but this test does not send any alert notifications.

Validate an ESA Rule

  1. If you are not already in the rule, go to netwitness_configureicon_24x21.png (Configure) > ESA Rules > Rules tab and in the Rule Library, open the ESA rule that you want to test.
  2. Scroll down to the Test Rule section.
    netwitness_testrulesection_576x252.png
  3. In the ESA Service field, select the ESA Correlation service to process the rule. Use the same ESA Correlation service that you plan to use in the ESA rule deployment that contains the rule.
  4. In the Input Data field, enter the input events to test the rule. Download the events from the Investigate view in JSON format, copy the events, and paste them in this field. You can do this from the Investigate > Navigate view or the Investigate > Events view.

    To download the events from the Investigate > Navigate view:
    1. In the main menu, go to Investigate > Navigate in a new tab, select a data source, and click Navigate.
    2. In the Navigate view, click Load Values and click a meta value to filter the events.
    3. Save the events as meta in the JSON file format [Save Events > Meta > (name the file) > Export Meta Format: choose JSON].
    4. In the toolbar click the netwitness_jobsicon_22x21.png (Jobs) icon and then click View Your Jobs.
    5. In the Jobs panel, download your extracted meta, for example: investigation-2020-May-19-08-30-20.json.
    6. Go to back to the netwitness_configureicon_24x21.png (Configure) > ESA Rules tab opened previously and copy the contents of the JSON file into the Input Data field in your ESA rule.

    To download the events from the Investigate > Events view:

    1. In the main menu, go to Investigate > Events in a new tab.
    2. In the Events view, enter a query for the ESA rule test.
    3. Select the events to use and in the Download or Download All menu, select Visible Meta as JSON or All Meta as JSON, depending on the size of your selection.
    4. In the main menu, go to Dashboards and in the toolbar click the netwitness_jobsicon_22x21.png (Jobs) icon and then click View Your Jobs.
    5. In the Jobs panel, download your extracted meta, for example: Concentrator_ALL_EVENTS_ALL_META.json.
    6. Go to back to the netwitness_configureicon_24x21.png (Configure) > ESA Rules tab opened previously and copy the contents of the JSON file into the Input Data field in your ESA rule.
  5. Click Test Rule. The Output field shows the output of your rule and you can determine if the results meet your requirements.

netwitness_rb_testrulesection_576x472.png

The following table describes the test rule output Engine Stats.

Field Description
Engine Version Esper version running on the ESA service
Events Offered Number of events processed by the ESA service since the last service start
Offered Rate The rate that the ESA service processes current events / The maximum rate that the ESA service processed events
Runtime Errors If applicable, this field can contain a link to runtime error messages related to the ESA rule deployment.

The following table describes the test rule output Rule Stats.

Field Description
Deployed A green checkmark indicates that the rule is deployed on the selected ESA service.
Statements Fired The number of statements that fired the alerts
Alerts Fired The number of alerts generated from the test data
Events in Memory The number of events placed in memory by the rule
Memory Usage The total amount of memory used by the rule
CPU % The percentage of the deployment CPU used by the rule. For example, a deployment with 1 rule shows 100% CPU usage for that rule and a deployment with two equally CPU heavy rules show 50% each.
Events Matched The number of events that matched the rule
Alerted Events If applicable, this field can contain a link to events that caused an alert.
Runtime Errors If applicable, this field can contain a link to runtime error messages related to the rule.
Debug Logs This field contains a link to Esper debug (audit) logs.