Sigma Rules

Sigma is an open format for writing detection rules independent of a specific SIEM. A Sigma rule can be translated into the query languages of various platforms.

How it works

A Sigma rule is a text file in the YAML format. It describes the log source, searched fields, and values. It also includes metadata like the title, severity, and ATT&CK technique. Tools translate the rule into the native language of the target system. Examples include Elastic, Microsoft Sentinel, or Splunk. A large community maintains a public repository with thousands of rules.

For example, a new attack technique uses a built-in Windows tool to download files. A corresponding Sigma rule appears shortly after the technique is publicised. The SOC tests the rule, customises exceptions, and translates it for the SIEM. The new rule is operational within a day.

What to look out for

• Public rules are a good starting point but are rarely useful without customisation.
• Test each rule with real data before it generates any Alerts.
• Check that the field names in your logs match the rule's requirements.
• Maintain your own rules in a repository, complete with versioning and reviews.

Benefits

Sigma makes detection rules portable between different platforms. This simplifies a future SIEM migration and reduces vendor lock-in. Teams can also easily share rules using CTI platforms, for example.

Limitations

Not every SIEM function can be represented in the Sigma format. Complex correlations over long periods often require the platform's native language. The translation process is also not always perfect and should be reviewed.

Typical mistakes

A common mistake is activating many public rules without prior testing. This approach generates a lot of noise and erodes confidence in Alerts.

How we implement it

We manage our detection rules as code: versioned, tested and tuned to your environment. Each rule is mapped to ATT&CK techniques.