Sigma Detection Rules
Every SIEM has its own query language: SPL for Splunk, KQL for Microsoft Sentinel and Defender, EQL and ES|QL for Elastic, and others. Detection logic written directly in one of them is hard to share, review, and move when the organization changes platforms. Sigma is an open, vendor-neutral format for describing detections on log data in YAML. A Sigma rule says what to look for in which kind of log; converters translate it into each SIEM's query language.
Sigma has become the lingua franca of detection engineering: thousands of community rules in the SigmaHQ repository, threat intelligence reports that publish Sigma rules, and teams that manage their detections as code — reviewed, tested, and deployed through CI like software. Writing good Sigma rules still requires understanding the underlying logs, field mappings, and the false positives of your environment.
TL;DR
- A Sigma rule declares a log source (category, product, service), detection blocks (selections and filters), and a condition.
- Field modifiers (
contains,endswith,startswith,re,all,base64offset, and others) express matching precisely. - Metadata — status, level, falsepositives, references, and ATT&CK tags — makes rules reviewable and searchable.
- Convert rules with sigma-cli and pySigma backends, using processing pipelines to map fields to your log schema.
- Test rules against known-good and known-bad sample logs, and manage them as code in CI.
- Start from the SigmaHQ repository, adapt rules to your environment, and tune with documented filters.
Quick Example
A Sigma rule for PowerShell launched with an encoded command:
Converting the rule for a specific SIEM and log schema with sigma-cli:
Core Concepts
Rule Structure
Detection Logic
Selections are maps of fields to values: multiple fields in one selection are combined with AND, and lists of values with OR. The condition combines named selections with and, or, not, parentheses, and helpers like 1 of selection_* or all of selection_*. Field modifiers refine matching:
The Sigma specification also defines correlation rules for counting events, combining rules over time windows, and value counts.
Conversion and Field Mapping
pySigma is the library behind conversion; backends generate queries for SIEMs (Splunk, Microsoft Sentinel and Defender KQL, Elastic, OpenSearch, and others), and processing pipelines map Sigma's generic field names and log sources to your actual schema — Sysmon versus Windows Security events, Elastic Common Schema, or custom parsers. Most conversion problems are mapping problems: a rule that converts cleanly but never fires usually targets field names your logs do not have.
Detections as Code
Keep rules in a repository with review, linting (sigma check), conversion in CI, and tests:
- Positive tests: sample events that must trigger the rule.
- Negative tests: benign events, including known false positives, that must not trigger.
- Deployment: converted queries pushed to the SIEM through its API, with version tracking.
- Metrics: alert volume, true positive rate, and time to triage per rule.
See Security Detection Engineering and CI/CD.
Community Rules and Tuning
The SigmaHQ repository contains thousands of rules organized by platform and log source. Treat them as starting points: check that you collect the required logs, test volume in your environment, and add documented filters for legitimate activity rather than disabling rules. Track coverage against ATT&CK techniques to find gaps. See MITRE ATT&CK.
Best Practices
Know Your Log Sources First
Confirm that the logs and fields a rule needs are collected and parsed before deploying it.
Write Narrow Selections and Explicit Filters
Prefer precise conditions and named filters with comments explaining each exclusion.
Test Every Rule With Real Samples
Keep positive and negative test events with each rule and run them in CI.
Keep Metadata Honest
Update status, level, false positives, and references as rules mature, and retire noisy rules deliberately.
Common Mistakes
Rules That Never Fire
Over-Broad Matching
Unreviewed Exclusions
FAQ
What is Sigma in cybersecurity?
An open, vendor-neutral format for writing detection rules on log data in YAML, which can be converted into the query languages of many SIEM and log analytics platforms.
How do I convert Sigma rules to my SIEM?
Use sigma-cli or pySigma with the backend for your platform and a processing pipeline that maps Sigma field names and log sources to your log schema.
What is a processing pipeline in pySigma?
A set of transformations applied during conversion — field name mappings, log source conditions, value changes — that adapt generic Sigma rules to a specific data source or schema.
Should I deploy all SigmaHQ rules?
No. Select rules for log sources you collect and threats relevant to you, test their volume and accuracy, and tune them before enabling alerts.
How do Sigma rules relate to MITRE ATT&CK?
Rules are tagged with ATT&CK tactics and techniques, which helps map detection coverage and prioritize gaps.
Related Topics
- Security Detection Engineering — Building and maintaining detections
- MITRE ATT&CK — Mapping detections to adversary techniques
- Security Information and Event Management — Where converted rules run
- CI/CD — Detections as code pipelines
- Suricata — Network-based detection rules
- Zeek — Network logs that Sigma rules can query