Sigma is to detections what YARA is to files: a generic, tool-agnostic way to describe what bad looks like in log data. You write a rule once, then convert it to Splunk SPL, Elastic, Microsoft Sentinel KQL, and more.
The anatomy of a rule
Every Sigma rule has a few key parts:
- logsource - which logs the rule applies to (e.g. Windows process creation).
- detection - one or more selections (the patterns) plus a condition that ties them together.
- condition - the boolean logic:
selection,selection and not filter,1 of them, etc.
Here is a minimal rule that flags PowerShell launched with an encoded command:
title: Encoded PowerShell Command
logsource:
category: process_creation
product: windows
detection:
selection:
Image|endswith: '\powershell.exe'
CommandLine|contains:
- '-enc'
- '-EncodedCommand'
condition: selection
level: high
Field modifiers are where the power is
|contains, |endswith, |startswith, |re (regex) and |all change how a value matches. A classic mistake is matching only the long form -EncodedCommand - attackers use -enc or -e, so list the variants (as above) or you'll ship a false negative.
Good rules balance precision and recall
- Precision - of everything the rule fires on, how much is truly malicious?
- Recall - of all the malicious activity, how much does the rule catch?
A rule that fires on every PowerShell launch has great recall and terrible precision (alert fatigue). A rule that only matches one exact string has great precision and poor recall. Detection engineering is the craft of tuning that trade-off.
Practice it
Reading rules is one thing; writing them against a live event corpus and getting scored on precision and recall is how it sticks.