Today, we are adding Sigma Correlations support to the SEKOIA.IO threat detection capabilities! In this post, we discuss what can be done with it, and why it was needed.
Limitations of STIX and STIX Patterning
When we first created our threat detection engine, we looked at existing data formats to determine if we could use one of them. Because our vision is that cyber threat intelligence is essential to threat detection, we turned to STIX and found out that it was a good candidate:
- Observed Data objects can be used to describe events
- STIX Patterning can describe detection rules
But as our product and our use cases evolved, we had to face some limitations.
First of all, the Observed Data objects we used to represent events were far from ideal. We faced issues to correctly index the events and the STIX model is not suitable for searching. For these reasons, we decided to use Elastic Common Schema (ECS) instead.
Then, we tried to design complex detection scenarios based on several events. As an example, let’s say we would like to detect the use of several reconnaissance commands in quick succession. Each command alone is not suspicious but together they may indicate reconnaissance activity:
([process:command_line LIKE ‘quser%’] AND [process:command_line LIKE ‘dir%’] AND [process:command_line LIKE ‘net%’]) WITHIN 30 SECONDS
At first glance, this pattern may look like it is doing what we want. But there is a major issue: there is no way with STIX Patterning to limit the scope of events this detection logic applies to. When we are monitoring the whole perimeter, what this really means is: “quser“ anywhere and “dir“ anywhere and “net“ anywhere within 30 seconds. What we really wanted was to apply this logic to the same hostname and potentially the same user.
Don’t get us wrong though, we still think STIX is the best way to model Threat Intelligence and our Threat Intelligence Platform is using it intensively. But for powerful detection, we needed something else.
Lapsus$: when kiddies play in the big league
Sigma to the rescue!
At the time, there seemed to be no obvious replacement that provided every feature we envisioned until this came out:
Sigma was already the most adopted format for detection rules, so the addition of these correlation features made it the complete option we were looking for. This started a long process of transitioning our detection logic to Sigma that came to an end this week with the release of native Sigma Correlations support in SEKOIA.IO. The main improvement from Sigma Correlations, when compared to STIX Patterning, is the addition of a “group-by“ feature. Our previous example could be fixed with the following rule:
name:quser_recon
detection:
selection:
process.command_line|startswith:quser
condition:selection
–––
name:dir_recon
detection:
selection:
process.command_line|startswith:dir
condition:selection
–––
name:net_recon
detection:
selection:
process.command_line|startswith:net
condition:selection
–––
action:correlation
type:temporal
rule:
-quser_recon
-dir_recon
-net_recon
group-by:
-user.name
-log.hostname
timespan:30s
ordered:false
This relies on a “temporal“ correlation rule matching a sequence of events. You can see below an example of an alert generated by this rule in our lab. As you can see, the alert was created in a matter of seconds.
Sigma Correlations also supports an “event_count“ type to match several similar events. As an example, here is a rule to detect when a “user.name“ fails to log in more than 5 times in the space of 5 minutes:
–––
name:login_failed
detection:
selection:
event.category:authentication
event.outcome:failure
condition:selection
–––
action:correlation
type:event_count
rule:login_failed
group-by:user.name
timespan:5m
condition:
gte:5
Finally, the “value_count“ correlation type can be used to create detection rules based on the number of unique values in a field. As an example, here is a rule to detect when a “user.name“ fails to log in to more than 5 different “log.hostname“ in the space of 5 minutes:
name:login_failed
detection:
selection:
event.category:authentication
event.outcome:failure
condition:selection
–––
action:correlation
type:value_count
rule:login_failed
group-by:user.name
timespan:5m
field:log.hostname
condition:
gte:5
Notable Differences
We are really happy to now support Sigma and Sigma Correlations in SEKOIA.IO. That said, there are a few points that make our implementation different from a typical Sigma support that are worth mentioning:
- We are directly using normalized fields from the ECS format inside the rules.
- The Sigma Correlations specification is not yet included in Sigma’s current release. As far as we know, we are the first to support it.
- We added an `aliases` property to cover more complex use cases.
- While Sigma is usually used to convert rules into a query language, our support of Sigma is built right in our real-time detection engine. This means faster detections, enabling you to react quickly to cyber attacks.
Additional details about our support of Sigma can be found in our public documentation.
Read also:
Chat with our team!
Would you like to know more about our solutions?
Do you want to discover our XDR and CTI products?
Do you have a cybersecurity project in your organization?
Make an appointment and meet us!