enrichments in detection rules - outer joins and ECG

This is a real limitation for detection engineering at scale. Native left outer joins in detection rules would reduce SOAR-side enrichment and avoid the match/throttling side effects of current workarounds. Support for custom UDM fields in ECG would also make enrichment far more useful for organization-specific schemas.

There’s a strange pattern in rules you can use for left joins. Effectively the conditions section is where the left join is implemented, and the underlying compiled query is a literal left-join semantic. I tried to outline how it works via comments - let’s see if Gainsight’s code block renderer is any good :)

 

rule DetectionUDMLeftJoinExample {
  meta:
    description = "Left Outer Join a UDM event with a Detection event"

  events:
    // from our UDM events, assign principal.hostname to $hostname value
    $e1.principal.hostname = $hostname
    // filter events from our detection table 
    // to just those that have a matching hostname
    // value from our UDM events
    // this is effectively the start of the join
    // via the equality of hostname between events
    // and detections tables
    $e2.detection.detection.outcomes["hostname"] = $hostname

    // you can even add filtering if you want
    // this is commented out for this example
    // $e2.detection.detection[0].rule_id = "ru_123"

  // aggregate by hostname every 5 minutes
  match:
    $hostname over 5m

  // Below is the left-outer-join syntax
  // that is avaialble in the conditions section
  // Whichever side has the negation prefix will
  // be the side that is allowed to be NULL from the outer join.
  // In this case !$e1 triggers "$e2 LEFT OUTER JOIN $e1" 
  // under the hood since the compiler detects that $e1 may not exist.
  condition:
    !$e1 and $e2
}

Please give it a try and let me know if this helps at all. We are also looking to introduce the simpler syntax that is available in search, but I don’t have an ETA for that.

UPDATE 2026.07.31

Chatted with another community member and the poster for this thread - there are some limitations to the approach I provided:
 

1. This only works for event to event cases - above is a join between the UDM Events table and Detections table. If you’re trying to use this pattern with Data tables today, it won’t perform a left outer join (drops nulls in the DT rows).
2. Some of the limitations are due to the syntax being pretty fragile - the difference between `!e1 and $e2` and `$e1 and (#e2 >= 0)`  seems to be significant (join type changes, but Im verifying this now).
3. Rule types - Single Event vs Multi Event - we have specific suppression/throttling techniques that are different between the two rule types - so if this join syntax forces your rule into an ME rule,  you have to pick a sometimes less effective suppression strategy.