Signal Correlation Rules

Overview

Signal correlation rules combine multiple signals together to generate a new signal so that you can alert on more complex use cases and reduce alert fatigue. For example, you can correlate events or signals to identify a specific issue or generate an alert only if a specific low severity signal is combined with a specific high severity signal.

As another example, you can create a signal by combining these two rules:

  1. Detect if an access attempt was made from an expired account
  2. Detect if there was an attempt to authenticate into a host or resource

And use the expired account ID attribute to correlate the two rules.

You can correlate log detection rules, as well as log detection rules with Cloud Security Management Threats and Application Security Management rules.

Create a Signal Correlation rule

Navigate to Detection Rules and click + New Rule. In the Select a rule type section, click Signal Correlation.

Set rules

  1. Select a rule for Rule a. Click the pencil icon to rename the rule. Use the correlated by dropdown to define the correlating attribute. You can select multiple attributes (maximum of 3) to correlate the selected rules. See Time windows for more information about the sliding window.

  2. Select a rule for Rule b in the second Rule editor’s dropdown. Click the pencil icon to rename the rule. The attributes and sliding window time frame is set to what was selected for Rule a.

Set rule cases

Trigger

The set rule cases section showing the trigger, severity, and notification fields

Rule cases are evaluated as case statements. Thus, the first case to match generates the signal. An example of a rule case isa > 3, where a is the rule name. Click and drag your rule cases to manipulate their ordering.

A rule case contains logical operations (>, >=, &&, ||) to determine if a signal should be generated based on the event counts in the previously defined queries. The ASCII lowercase rule names are referenced in this section.

Note: The query label must precede the operator. For example, a > 3 is allowed; 3 < a is not allowed.

Provide a name, for example “Case 1”, for each rule case. This name is appended to the rule name when a signal is generated.

Severity and notification

In the Set severity to dropdown menu, select the appropriate severity level (INFO, LOW, MEDIUM, HIGH, CRITICAL).

In the Notify section, optionally, configure notification targets for each rule case.

You can also create notification rules to avoid manual edits to notification preferences for individual detection rules.

Time windows

An evaluation window is specified to match when at least one of the cases matches true. This is a sliding window and evaluates cases in real time.

After a signal is generated, the signal remains “open” if a case is matched at least once within the keep alive window. Each time a new event matches any of the cases, the last updated timestamp is updated for the signal.

A signal closes once the time exceeds the maximum signal duration, regardless of the query being matched. This time is calculated from the first seen timestamp.

Click Add Case to add additional cases.

Note: The evaluation window must be less than or equal to the keep alive and maximum signal duration.

Say what’s happening

Add a Rule name to configure the rule name that appears in the detection rules list view and the title of the Security Signal.

In the Rule message section, use notification variables and Markdown to customize the notifications sent when a signal is generated. Specifically, use template variables in the notification to inject dynamic context from triggered logs directly into a security signal and its associated notifications. See the Notification Variables documentation for more information and examples.

Use the Tag resulting signals dropdown menu to add tags to your signals. For example, security:attack or technique:T1110-brute-force.

Note: the tag security is special. This tag is used to classify the security signal. The recommended options are: attack, threat-intel, compliance, anomaly, and data-leak.

Further reading

PREVIEWING: may/unit-testing