I’d like to take a look at a new type of rule that detection engineers and threat hunters can take advantage of within Google Security Operations (SecOps). This type of rule is called a composite rule and provides users greater flexibility to build out their corpus of detections.

For anyone who has ever built a detection in any SIEM, there are the very straightforward rules like the process launch whoami rule. This is the Hello World! version of a detection and at the other end of the continuum, we have rules that are looking at multiple log types, joining data, waiting for thresholds to be met and analyzing the order events were generated.

The challenge is that the whoami rule isn’t something we want to put in front of an analyst to work and the very complex rule, while powerful when it triggers, may be too brittle. If an adversary makes a slight change to their procedures, the rule could be bypassed. Yes, there may be a bit of hyperbole here, but hopefully you catch my drift.

To bridge this gap, composite rules provides a multi-layer structure where detection rules can be built on smaller, more bite size atomic style detections and composite rules can be written to identify commonalities in those detections that become alerts to be triaged and investigated by analysts.

Terminology

This new capability introduces a few new terms. The first is a producer rule. A producer rule leverages UDM event data to generate a detection. Could it generate an alert? Of course it could, but then you may end up with an alert for a specific activity and that alert could find its way into a composite alert downstream as well. That’s not a bad thing, if that singular action is enough to merit an alert but it is something to be mindful of so that alert triage and investigation isn’t being duplicated.

Producer rules will generally be classified as single event rules in Google SecOps, which means that the rule is triggered on a single event or a set of events that are grouped by one or more match variables. Think of these as aggregated rules where we are grouping our event criteria by a common hostname or username over a five minute window, for instance. These producer rules could also include curated detections, which are written and maintained by Google Cloud Threat Intelligence (GCTI) team.

One key point to make about producer rules, and I feel like in the nearly three years I’ve been writing this blog, I’ve mentioned this more than once. It is important to add context to all rules, but particularly your producer rules. In upcoming blogs, as we build examples, we will illustrate how meta section labels and values as well as outcome variables can be used when building composite rules.

The second term is a composite rule. We’ve used the term a few times already but this is a rule primarily based on data drawn from the detection dataset.

Composite rules are classified as multi-event rules and most will contain YARA-L rule logic to return detections that meet defined criteria over a defined aggregation (match) window. The structure of these composite rules is just like every other rule you may have written, the big difference is that it references the detection dataset.

When we couple these together, at a high level, the event flow looks something like this:

Those are the fundamental concepts, but here’s where it gets fun! Composite rules can not only use data from the detections dataset, but it can also use data from the entity graph, UDM events and detections of detections. This creates a wider set of data that a composite rule has access to and generates more flexibility for the detection engineer to craft the rule needed for their use case.

I realize there are a number of new concepts that I’ve introduced in this blog, so let’s start shifting to the practical application and move away from the theory. Here are a few examples of how composite rules can be used:

• Identify when a defined set of detections trigger with a specific time window


• Create aggregated risk scoring where multiple low risk detections can be compiled to identify a higher risk asset or user to investigate


• Associate multiple MITRE ATT&CK techniques that are part of the same tactic being utilized


• Identify a broader intrusion where multiple MITRE ATT&CK tactics are being observed as an adversary moves across a kill chain

Today is just the first in a mini-series where we will be going deeper into composite rules. Over the next few blogs, we will start working through different methods that a composite rule can be written and leverage the different data sets that Google SecOps has to offer to create higher fidelity alerts for users to take advantage of.