Sigma

Sigma#

Sigma is a vendor-agnostic detection rule language. You write the detection once in YAML; Sigma’s converters translate it into your SIEM’s native query language (Splunk SPL, Elastic EQL/ES|QL, Microsoft Sentinel KQL, Sumo Logic, QRadar AQL, Chronicle YARA-L, and many more).

The “write once, deploy everywhere” detection format; the de-facto exchange format for community-shared detections.

A Minimal Rule#

title: Suspicious PowerShell Encoded Command
id: 1f3c4321-aaaa-bbbb-cccc-1234567890ab
status: stable
description: PowerShell -EncodedCommand with hidden window
author: operator
date: 2026-04-27
tags:
  - attack.execution
  - attack.t1059.001
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\powershell.exe'
    CommandLine|contains:
      - ' -EncodedCommand '
      - ' -enc '
    CommandLine|contains|all:
      - ' -WindowStyle '
      - ' Hidden'
  condition: selection
level: high

A Sigma rule is YAML with a fixed set of top-level fields. metadata at the top, log source in the middle, detection logic at the bottom. The detection block is the heart – named selectors describe field/value tests and a condition expression composes them into the boolean that fires.

  • title / id / status / description / author – metadata.

  • tags, usually MITRE ATT&CK technique IDs (attack.t1059.001).

  • logsource, which log type / product / service this applies to. The Sigma converters use this to choose the right backend mapping.

  • detection, the rule body:

    • named selectors, field/value tests.

    • condition, Boolean expression over the selectors: selection, selection and not filter, 1 of selection_*.

  • level, informational / low / medium / high / critical.

  • falsepositives, known FP sources (free text).

Modifiers#

Pipe-separated suffixes on a field name change how the value is matched (substring, regex, base64-decode, case sensitivity, all-or-any semantics on lists, Windows dash normalization). The right modifier is often what makes the difference between a noisy rule and a precise one.

The pipe-separated suffixes on field names.

Modifier

Meaning

contains

substring

startswith / endswith ditto

re

regex

base64

decode then compare

base64offset match a Base64 substring at any offset

cased

case-sensitive

all

every value in the list must match

windash

accept -- and - for arguments

Lists OR by default; |all makes them AND.

Translation: sigma (or pysigma)#

$ pip install sigma-cli
$ sigma convert -t splunk rule.yml
$ sigma convert -t microsoft365defender rule.yml
$ sigma convert -t elasticsearch rule.yml -p ecs_windows
$ sigma convert -t loki rule.yml

Each backend has pipelines that map Sigma’s generic field names (Image, CommandLine) to the backend’s actual fields (Splunk’s process, ECS’s process.command_line).

Detection Engineering Workflow#

  1. Write the rule in Sigma YAML, mapped to ATT&CK.

  2. Test against historical data in your SIEM.

  3. Tune false positives via filter selectors.

  4. Convert to your SIEM’s language; deploy.

  5. Track the rule (version, ATT&CK coverage, FP rate, last validation).

  6. Re-validate with adversary simulation (Atomic Red Team).

The same rule moves between SIEMs as your stack changes.

Tooling#

The Sigma toolchain centers on sigma-cli and the pySigma library, with backend plugins for every major SIEM. The community rule set is the largest detection repository in the open ecosystem; pinning a fork is the standard way to consume it without surprises in CI.

  • pysigma, the Python library.

  • sigma-cli, command-line conversion.

  • SigmaHQ rules, thousands of community rules; fork and pin a snapshot for your environment.

  • Backends, Splunk, Elasticsearch / Kibana, Microsoft Sentinel, Microsoft 365 Defender, Loki, Sumo Logic, QRadar, Chronicle, CrowdStrike, ArcSight, Sigma → Snowflake, and others.

  • Uncoder.io, web-based translator.

Best Practices#

The habits that turn a Sigma rule from a one-off into a durable detection. ATT&CK tagging gives the rule a place in the threat model; pipeline files let one rule live across multiple environments; FP tracking is the difference between a detection that operators trust and one they ignore.

  • Tag with ATT&CK, every rule should map to a technique.

  • Test against the SigmaHQ rule set before reinventing.

  • Use named selectors for filters so they’re explicit; avoid inline not blocks.

  • Pipeline files for your environment so generic rules pick up your field names.

  • Track noise, a rule that fires hundreds of times a day per host is not a detection.

Pitfalls#

The traps that catch teams adopting Sigma. The biggest is forgetting that generic field names mean nothing without a pipeline mapping; YAML quoting subtleties come second; backend feature gaps and toolchain version skew round out the list of problems that operators learn the hard way.

  • Generic field names, Image etc. only mean what your pipeline says they mean. Pipelines are not optional.

  • Wildcards in YAML, single quotes vs. double quotes vs. unquoted strings have subtly different YAML parsing. Stick to single-quoted strings.

  • Backend feature gaps, some Sigma features don’t translate losslessly. The converter warns; read the warnings.

  • Version skew, rules written for sigma v1 don’t always work with v2; pin the toolchain version in CI.

See Also#

  • detection.

  • YARA, Sigma’s malware-side cousin.

Contents