Rule chaining

Supported in:

Rule chaining lets you interconnect rules in such a way that the output of one rule acts as the input for another rule. This capability lets you create rules with more complexity and flexibility. Rule chaining overcomes the limitations of isolated event detection by correlating and analyzing events across different data sources and timeframes.

Benefits of rule chaining:

  • Unmasking Multi-Stage Attacks: Cyberattacks are often interconnected. Rule chaining helps to uncover the attack narrative by showing the links between seemingly isolated incidents. For example, rule chaining can identify the entire attack sequence, such as an initial breach followed by privilege escalation and data exfiltration.

  • Taming Alert Fatigue: Prioritize critical threats and mitigate alert fatigue by implementing consumer rules. These rules consolidate and filter noisy alerts generated by producer rules, enabling a more focused response.

  • Enhancing Detection Accuracy: Combine insights from UDM events, other rule detections, entity information, UEBA findings, and data tables to create accurate detection logic.

  • Streamlining Complex Logic: Break down complex detection scenarios into manageable, interconnected, and reusable rules to streamline development and upkeep.

Rule chaining terms and concepts:

  • Detection: is the result of a rule and can also be referred to as an alert.

  • Chain: is a series of rules where the output of one rule serves as the input for the next rule. For example, in the chain rule1 -> rule2 -> rule3, the detections generated by rule1 are used by rule2 to produce new detections, which are then used by rule3 to generate its own set of detections.

  • Producer rule: is a rule whose detections are used as input for another rule. Any rule can function as a producer rule, and there is no specific designation required.

  • Consumer rule: is a rule that uses detections as input in the rule text.

  • Chaining rule: is also known as a consumer rule.

Advanced concepts

Single event detection rules

Google SecOps does not allow single event detection rules. This means that any rule that uses detections as a data source must have a match section.

Detection latency

We recommend only chaining consumer rules on single event rules due to scheduling concerns. Single event rules run near-real time, so detections from these rules will almost always be available for the first execution of a consumer rule. If you create a rule chain using a multi-event rule, it's possible that the producer rule would execute after the consumer rule, delaying the generation of detections in the consumer rule.

TestRule and Retrohunt

Testing or running a retrohunt on a consumer rule only runs the specific rule that you selected using existing detections. To run a full chain, you must start retrohunts at the beginning of the chain and wait for each run to finish before running the next rule.

Running a test on a rule does not persist or write the detections to the database and consumer rules require the input detections to exist in the database. Therefore, you cannot test a chain of rules in test rule.

Construct rule chains

You create rule chains using combinations of producer rules and consumer rules.

Producer rules

Producer rules are the foundation of your chain. They identify specific events or conditions that, when combined, indicate malicious activity. To configure producer rule, do the following:

  1. Create a new rule or reuse an existing one

  2. Disable alerting and set $risk_score to 0 in the outcome section. This prevents these rules from generating individual alerts or impacting entity risk scores. By using this configuration, you can prioritize the more critical alerts generated by consumer rules, which assess the entire chain of events.

  3. Use the outcome section to define the variables accessible to chaining rules.

The following producer rule example detects failed logins.

rule failed_login {
  meta:

  events:
    $e.metadata.event_type = "USER_LOGIN"
    any $e.security_result.action = "BLOCK"

  outcome:
   $risk_score = 0
   $target_user = $e.target.user.userid

  condition:
    $e
}

This rule identifies logins that are blocked and provides the associated user.

Chaining rules

Writing a rule that uses detections is mostly the same as a rule that uses UDM, except that the source and the available fields are different. To reference a detection field use the keyword detection as the source: $eventname.detection.field1.field2.

The subfields that are available under the detection source can be found in the collection resource.

Following are the common fields in collections

  • $d.detection.detection.rule_id

  • $d.detection.detection.detection_fields["match_var_name"]

  • $d.detection.detection.outcomes["outcome_name"]

The following example rule detects logins without MFA, enumeration, and exfiltration.

rule login_enumeration_exfiltration {
    meta:
description = "Detects when a user logs in without multifactor authentication (MFA) and then performs enumeration and exfiltration"
        rule_name = "Login Without MFA, Enumeration, Exfiltration"
        severity = "High"

    events:
     // Detection with name "Console Login Without MFA"
        // The affected user is saved as $target_user
        $login_without_mfa.detection.detection.rule_name = /Console Login Without MFA/
        $target_user = $login_without_mfa.detection.detection.outcomes["target_user"]

     // Any detection with a rule name containing 'enumeration'
     // The user performing enumeration is the user that logged in without mfa
        $enumeration.detection.detection.rule_name = /enumeration/ nocase
        $enumeration.detection.detection.outcomes["principal_users"] = $target_user

     // Any detection with the mitre tactic 'TA0010' (Exfiltration)
     // The user performing exfiltration is the user that logged in without mfa
        $exfiltration.detection.detection.rule_labels["tactic"] = "TA0010"
        $exfiltration.detection.detection.outcomes["principal_users"] = $target_user

    match:
     // Looks for detections over a 24 hour period
        $target_user over 24h

    condition:
     // All 3 must occur for a single user
        $login_without_mfa and $enumeration and $exfiltration
}

Hierarchical detections

Rule chaining lets you create a hierarchical detection system. Lower-level producer rules identify individual suspicious events. Their output is then fed into higher-level chaining or consumer rules. These rules correlate this information with data from other sources to detect multi-stage attack patterns that single-event rules might miss. Google Security Operations supports up to three levels of chaining, providing a balance between detection sophistication and manageable complexity.

For example:

  • Level 1: Producer rules detect individual suspicious events. For example, failed login, unusual file access.

  • Level 2: Chaining rules correlate Level 1 detections. For example, failed login followed by suspicious file access.

  • Level 3: Higher-level chaining rules combine Level 2 detections and other data for even more sophisticated detection. For example, a level 2 detection regarding the authentication as well as a level 2 detection regarding the security posture of the device being used.

Considerations when changing producer rules

When a producer rule is updated in a rule chain, a new version of the producer rule is created. This applies to both logic updates (condition, events, outcomes) and metadata updates (name, description, severity). Consumer rules continue to operate using the new version. It is important to test updated producer rules and their downstream consumer rules to ensure the intended behavior.