LinkedIn
Twitter
In our previous post, we covered how Chronicle SIEM can aggregate events into a single detection and alert within YARA-L rules.
In this post, we’ll focus on how to set rule thresholding in Chronicle SIEM using the conditions section in YARA-L.
Follow along in the video below.
Previously, we introduced the condition section of YARA-L as a mandatory section for every rule.
However, in our initial rules, the only thing in our condition section was the event variable for the criteria in the events section. Basically if the criteria exists, trigger the rule.
But as we get into using multiple events to evaluate our rules, we can start counting events that meet our criteria, and if the number of events of fields exceed a defined threshold, we can trigger the rule.
We can use the outcome variables in our condition section as well, but we’re going to save that for another time.
To demonstrate how these thresholds in condition can be used to trigger a rule, let’s use an example with failed logins.
It’s safe to assume that everyone has generated a failed login event at least once in their life - we forget our password, we mistype something - no problems there. But if an individual user generates too many failed logins, perhaps that isn’t someone who just came back from vacation and is just getting settled back in, but an adversary attempting to gain access to an account.
Let’s trigger a rule to address this concern. Follow along in the video demonstration starting at 1:25.
We have a starter rule that is looking for failed Windows login events with a specific event code of 4625. We have a match section to aggregate our events by user ID over a five minute window, so we don’t get a detection for every failed login attempt.
However, when we test our rule, we still end up with a bunch of detections and they seem to vary on the number of failed logins in that five minute period.
Perhaps for this specific rule, we want to only be alerted when a certain number of events have occurred - such as, more than five failed events.
To do this, we can modify the condition section of our rule and change the condition from a $fail, which basically means, “do we have an event variable that meets our criteria?” to #fail > = 6 which means we’re going to count the number of events that meet the criteria in the events section that have our specific event variable associated with it, and if that count exceeds our threshold (six or more), trigger our rule.
And when we run our rule, we can see that our overall number of detections have dropped (we use the test rule to make that happen).
Another way that this count with any condition can be used, is to trigger a rule based on a distinct count of a specific value within a field, and if that threshold is met, trigger your rule.
This time we’re going to go ahead and change our rule a bit and add in a second placeholder variable for principal.hostname. We’re going to group our failed events by this hostname over the course of five minutes, but this time we’re going to take the placeholder variable for target.user.userid and count the number of unique values in that specific field, meaning the unique usernames.
While we haven’t touched on the outcome section and its variables, I’ve gone ahead and added one outcome variable that we can see the array of the users that are part of our detection.
The first time we test this rule we’re going to specify our condition as #userid > 0, which is basically saying if we have one or more usernames in our failed event logs, trigger the rule. Not surprising, we should see plenty of these.
So when we run our rule and test it, we can see that we have 11 detections and that our first detection has six supporting events with it, but only a single user, frank.kolzig, in it.
Our next detection has a number of distinct users, including frank. This is because the window of events was set for five minutes and the first detection window completed was just frank meeting that criteria, and the next detection window had a number of other users associated with it.
Now let’s modify our rule to only detect when we have more than 10 distinct users within a detection window on the same host.
And when we test this rule, we only have six detections overall. Using that outcome variable, we can see that we have a list of usernames that had failed logins to a specific host in a five minute window.
We’ll get further into outcome variables and building out conditions a little bit later, but hopefully these examples illustrate some of the possibilities that the condition section can provide to detection engineers.
Remember, as you start building rules that leverage thresholds in the conditions section, you can generate these counts based on the number of events seen or number of unique values. We didn’t cover this, but in fact, you could build a rule based on both.
The conditions section can accept event or placeholder variables, but not UDM fields. Yes, they will support outcome variables too, but that’s for another day.
Finally, thresholds with conditions are used with rules that are evaluating multiple events and are being grouped by one or more values in the match section. After all, how can we decide if a threshold is exceeded without grouping events together?
