Writing Your First Sigma Rule
Sigma is to log detections what YARA is to files: a generic, vendor-neutral way to describe what you want to detect, which you then convert into the query language your SIEM actually speaks.
Why a portable format?
Detections written directly in one query language are stuck there forever. Sigma lets you write once and compile to many backends:
- One rule, many targets (Splunk, Elastic, Sentinel, …)
- Reviewable in pull requests like any other code
- Shareable with the community without leaking your stack
A detection you cannot test, version, and review is a liability, not an asset.
Anatomy of a rule
The core of every rule is a detection block with one or more selections and a
condition that combines them:
title: Suspicious whoami Execution After Service Install
status: experimental
logsource:
product: windows
category: process_creation
detection:
selection:
Image|endswith: '\whoami.exe'
ParentImage|endswith: '\services.exe'
condition: selection
level: medium
Field reference
The modifiers after the pipe (|) change how a value is matched:
| Modifier | Matches | Example |
|---|---|---|
endswith | suffix of the field | Image|endswith |
contains | substring anywhere | CommandLine|contains |
re | a regular expression | CommandLine|re |
all | every value in a list | CommandLine|contains|all |
Once it compiles cleanly and fires on a known-bad sample, commit it. The cheapest detection is the one you never had to debug in production at 3 a.m.