LinkedIn
Twitter
In our previous post, we covered building a single event rule in Chronicle SIEM using a regular expression.
In this post, we’ll focus on how Chronicle SIEM can aggregate events into a single detection and alert within YARA-L rules.
Follow along in the video below.
To aggregate events into a single detection, we’re going to introduce a new section to our YARA-L rule. This section is called match, which is used in addition to the meta, events, and condition sections we’ve previously covered.
The match section provides a method to group data over a time boundary that can range from one minute to 48 hours. With the introduction of the match section for aggregating events into a single detection, we’re also going to start using match variables.
Match variables are basically taking placeholder variables from the event section and using one or more to match like events in our detection.
Now, as we build rules in Chronicle, you’ll likely have the match section in many of your rules. You might be wondering why. Well if I’m logging Windows events and using an EDR or Sysmon on the same host, and I detect a process execution, I would likely get a detection for each of these data sources.
While it’s great that we can detect this, presenting our analyst with what is basically a duplicate detection - one for each event source - is not ideal. But by adding the match section to our rule, we can aggregate these events into a single detection.
Let’s take a look. Follow along in the video starting at 1:36 to see the example in action.
We’re going to use our whoami rule and demonstrate how we can aggregate our detection.
We already have our rule in place, so we just need to make a few tweaks. One of the biggest considerations we need to take into account is what field or fields to use for the match condition.
To see what our current detection looks like, we’ve already run our test rule to examine our results. By clicking on the columns button, we can add additional fields into our detection to view values.
Here we can see that principal.hostname and principal.user.userid both have the same value occurring roughly at the same time and there are different product event codes and event sources - 4688 for Windows events and 1 for Sysmon events.
With that background, we need to ask ourselves how we want to aggregate our detections. Maybe we want to group by the command line that was executed. We could add our match section below the event section in our rule and add our field. But, we can’t add a UDM field here - we need a match variable.
In the events section, let’s add a placeholder variable for the field target.process.command_line and then take that placeholder variable and apply it in the match section of our rule.
The match condition time range is one minute to 48 hours. For our example, we’re going to use one hour.
When we test our rule, we can see we get a single detection with four events in it. This is because all four events with the same common match variable occurred within the same time range.
Let’s change our match to the principal.hostname field by setting our placeholder and match variables. We’ll keep our time window the same and then test our rule.
Notice this time, we have two detections - one for each hostname. Remember that matches don’t need to be based on a single variable.
This time, let’s match on both the hostname and the user ID. To do this, we can add a placeholder variable for the user ID in the events section and then use that variable in the match section. We’ll separate the match variables with a comma.
When we test our rule this time, we get two detections again, grouped by both the host and the user ID.
As always, once we’re happy with our rule, we can click “Save” in the top right corner of the rule editor and close out.
When aggregating events and rules, remember that we want to go ahead and add the match section to our rule. Without this, we’ll trigger a detection every time our criteria is met, which might get unwieldy for our analysts.
When we build that match condition, we are grouping common events by time. This time range can be between one minute and 48 hours using the syntax of, variable over time.
Finally, UDM fields do not appear in the match section. Instead, we use placeholder variables that we define in the events section, and can use one or many separated by commas in the match section.
