Sigma Rules

Sigma is to SIEM detection what Markdown is to documentation: a portable abstraction over a fragmented landscape of vendor-specific tooling.

A SIEM (Splunk, Elastic, Sentinel, QRadar, Chronicle, Wazuh) ingests logs and lets analysts query them. Each one has its own query language, none of them compatible with the others. The same logic — “alert when csc.exe runs from a temp directory with a non-developer parent” — has to be rewritten from scratch every time you switch SIEMs or share rules cross-org.

Sigma fixes that with a YAML-based rule format and a converter ecosystem that emits the native query for whatever backend you target.

Anatomy of a Sigma rule

title: Suspicious csc.exe Compilation From Temp
id: 8d-some-uuid
status: experimental
description: Detects csc.exe invoked from or writing to user-writable temp paths
references:
    - https://attack.mitre.org/techniques/T1027/004/
tags:
    - attack.defense-evasion
    - attack.t1027.004
logsource:
    category: process_creation
    product: windows
detection:
    selection_image:
        Image|endswith: '\csc.exe'
    selection_path:
        - CommandLine|contains: '\Temp\'
        - CurrentDirectory|contains: '\AppData\Local\Temp'
    condition: selection_image and selection_path
falsepositives:
    - Legitimate development from temp build directories
level: medium

Three things make this powerful:

1. tags map directly to MITRE ATT&CK T-codes. Tooling can compute your detection coverage by traversing tags across your rule corpus.
2. logsource abstracts the data source. You don’t say “splunk index windows” — you say “process_creation events on windows,” and the converter knows where to look in each backend.
3. detection uses selections + conditions. Each named selection is a set of field-value matches; condition combines them with boolean logic.

Detection-as-code workflow

In practice, Sigma rules sit alongside source code in a Git repository:

detections/
├── windows/
│   ├── proc_creation_csc_temp.yml
│   ├── proc_creation_certutil_download.yml
│   └── ...
├── linux/
└── tests/

Each rule is reviewed via PR. The CI pipeline converts to backend queries, deploys to staging, runs against historical data, measures false-positive rate, and only then promotes to production. This is detection-as-code, and it requires a portable rule format — which is why Sigma exists.

When NOT to use Sigma

Sigma’s portability comes from constraining what it can express. Highly backend-specific features — Splunk’s tstats over accelerated data models, Elastic’s painless scripts, Sentinel’s KQL materialize for query optimization — don’t fit cleanly. For those, write native queries.

A pragmatic split: most baseline detections in Sigma; a small number of high-volume / high-cost rules in native query language.

Where to learn more

• The SigmaHQ public repo — thousands of community-vetted rules, browsable by ATT&CK technique.
• The Sigma specification — the formal grammar of the rule language.
• pySigma — modern Python toolkit for parsing, validating, and converting rules. Successor to the older sigmac.