---
title: "Sigma Rules"
description: "Vendor-agnostic, YAML-based detection language for SIEMs — write the rule once, translate to Splunk, Elastic, Sentinel, or any supported backend."
pubDate: 2026-05-09
updatedDate: 2026-10-12
tags:
  - "detection"
  - "siem"
  - "detection-as-code"
domain: "devsecops"
source: "https://zapf.dev/atlas/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"*, a classic [LOLBin](/atlas/lolbin/) pattern — 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

```yaml
title: Suspicious csc.exe Compilation From Temp
id: 74a8e2cf-fa3b-4f0a-978e-a94bacb8b8a5
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](/atlas/mitre-attack/).** Tooling can compute your detection coverage by traversing tags across your rule corpus. Tags follow Sigma's own appendix, which can lag behind ATT&CK: it still writes TA0005 as `attack.defense-evasion`, although ATT&CK v19 renamed that tactic to Stealth.
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.

The `id` is optional but worth setting: a random UUID (version 4) gives the rule a stable identity across renames, forks, and backends.

## 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.**

## Common misconceptions

- **"A Sigma rule runs anywhere as-is."** The logic is portable; your field names aren't. Converting for a real environment means a processing pipeline (in [pySigma](https://github.com/SigmaHQ/pySigma)) that maps Sigma's field taxonomy onto your log schema.
- **"Community rules work out of the box."** The [SigmaHQ repository](https://github.com/SigmaHQ/sigma) is a baseline, not a deployment. Every rule needs tuning against your own environment's normal activity, or it drowns analysts in false positives.
- **"Sigma means vendor independence."** It covers the common denominator of detection logic. Your logging, enrichment, and response still live in the SIEM.

## Retrieval prompts

**Q:** What problem does Sigma solve that vendor-specific rules don't?
**A:** **Portability.** Vendor query languages (Splunk SPL, Kibana KQL, Sentinel KQL, Elastic ES|QL) are mutually incompatible. Sigma is a vendor-neutral abstraction: write the rule once in YAML, use a converter (sigmac, pySigma) to emit the equivalent native query for whichever SIEM you're running. This decouples your detection logic from your SIEM choice.

**Q:** What are the three required top-level fields in a Sigma rule?
**A:** **title**, **logsource** (which data source the rule operates on — e.g., `category: process_creation` for Windows process telemetry), and **detection** (the matching logic, expressed via selections and a `condition` field). Other fields like `id`, `tags`, `level`, `falsepositives`, and `references` are recommended but optional.

**Q:** How does Sigma fit into a detection-engineering workflow?
**A:** It's the lingua franca for sharing detections across teams and vendors. SigmaHQ maintains a public repo of community-vetted rules; teams fork these as a baseline, customize for their environment, and version-control the result alongside their code. The pipeline is: write rule → convert to backend query → deploy → tune → commit changes back.

## References

- [SigmaHQ — official rule repository](https://github.com/SigmaHQ/sigma)
- [Sigma specification](https://github.com/SigmaHQ/sigma-specification)
- [pySigma — translation toolkit](https://github.com/SigmaHQ/pySigma)

## Prerequisites

- [MITRE ATT&CK](https://zapf.dev/atlas/mitre-attack/)

## Discussed in

- [Accidental LOLBin: Controlling Media Keys with csc.exe](https://zapf.dev/blog/accidental-lolbin-media-keys/)