Composite detections

Supported in:

Composite detection lets you interconnect rules so that the output of one rule acts as the input for another rule. This capability lets you create rules with more complexity and flexibility. By correlating and analyzing events across different data sources and timeframes, composite detection overcomes the limitations of isolated event detection.

Benefits of composite detection

  • Unmasking Multi-Stage Attacks: Cyberattacks are often multi-faceted and interconnected. Composite detection helps to reveal the attack narrative by linking 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 input rules, enabling a more focused response, which can help priortize high-impact incidents and minimize alert fatigue.

  • 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.

Composite detection terms and concepts

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

  • Composite: a series of interconnected rules where the output of one rule serves as the input for the next. For example, in the composite rule sequence rule1 -> rule2 -> rule3, the detections generated by rule1 are passed to rule2, which processes them to generate new detections. These detections are then consumed by rule3 to produce its final output.

  • Input rule: a rule whose detections are used as input for another rule. Any rule can function as a input rule, and there is no specific designation required. Input rules use entities and events as a input. They don't use detections as input.

  • Composite rule: a rule that uses detections as input in the rule text. Composite rules must have a match section.

Advanced concepts

Single-event detection rules

Google SecOps does not allow single-event composite rules. This means that any rule that uses detections as an input source must have a match section.

Detection latency

We recommend composing composite rules only on single-event input rules due to scheduling behavior. Single-event rules run in near real-time, so their detections are typically available by the time the composite rule executes. If a composite rule depends on a multi-event rule as input, there's a risk that the input rule might run after the composite rule's scheduled execution. This can lead to delays or missed detections in the composite rule.

TestRule and Retrohunt

Testing or running a retrohunt on a composite rule only runs the specific rule that you selected using existing detections. To run the entire composite, you must manually start retrohunts from the first rule in the sequence, wait for each run to finish, and then proceed to the next rule.

Running a test on a rule does not persist or write the detections to the database and composite rules require the input detections to exist in the database.

Running a test on a rule does not persist or write the detections to the database. Because composite rules require the input detections to exist in the database to function, you can't use TestRule to validate an entire rule chain.

Construct composite rules

You create composite rules using combinations of input rules and composite rules.

Input rules

Input rules are the foundation of your composite rule. They detect specific events or conditions that, when combined, indicate malicious activity. To configure an input rule, do the following:

  1. Create a new rule or reuse an existing one.

  2. Disable alerting. This prevents these input rules from generating individual alerts. By using this configuration, you can prioritize the more critical alerts generated by composite 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:
   $target_user = $e.target.user.userid

  condition:
    $e
}

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

Composite 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

Composite detection lets you create a hierarchical detection system. Lower-level input rules identify isolated suspicious events. Higher-level composite rules then consume the output of these input rules to correlate across time, entities, and data sources. This approach helps 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 composition, providing a balance between detection deep detection logic and manageable complexity.

For example:

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

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

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

Considerations when writing composite rules

When you update an input rule that is used in one or more composite rules, the system automatically creates a new version of that input rule. This applies to both logic updates (condition, events, outcomes) and metadata updates (name, description, severity). Composite rules continue to operate using the new version. We recommend to test updated input rules and their downstream composite rules to ensure the intended behavior.

Limitations

Composite rules have the following limitations.

Detection-only rules and entity risk score

Detection-only rules (rules that use only detection data as a source, and not event or entity data) don't contribute to entity risk score. Any risk score that is set for a detection-only rule only applies to the detections created by that rule. It won't contribute to any aggregate entity risk score.

Need more help? Get answers from Community members and Google SecOps professionals.