Cloud Parts

Sigma

An open YAML format for detection rules over log events, with a community repository of more than 3,000 rules and tools that convert them into each SIEM’s query language.

What it is
Threat detection (SIEM)
Type
Open source
Made by
SigmaHQ
License
DRL 1.1 (rules); LGPL 2.1 (pySigma, sigma-cli); specification public domain
Facts checked
12 October 2026
Website Source code

What it is

A Sigma rule describes suspicious log events in YAML. logsource says which logs it applies to in generic terms, such as product: aws with service: cloudtrail, or category: process_creation on Windows, rather than naming an index or a product. detection holds named selections: a map of fields that must all match (AND) or a list of alternatives (OR), with modifiers such as contains, endswith or re after a pipe. condition combines the selections with and, or, not and patterns like 1 of selection_*. Metadata such as level, status, falsepositives and MITRE ATT&CK tags travels with the rule. The project’s README puts it this way: “Sigma is for log files what Snort is for network traffic and YARA is for files.”

Since specification 2.0 (August 2024), correlation rules sit on top. A correlation references other rules by id or name, groups their matches by fields such as User, and fires on a count of events (event_count), a number of distinct values (value_count) or a set or sequence of rules (temporal, temporal_ordered) within a timespan such as 10m. Version 2.1 (August 2025) added sums, averages and percentiles of a field.

Sigma itself runs nothing. pySigma, a Python library, parses rules and converts them through backends into a target’s query language: Splunk SPL, Elasticsearch Lucene or EQL, Kusto (KQL) for Microsoft Sentinel and Defender XDR, and more than 30 others on the Sigma backends page. Processing pipelines map Sigma’s field names and log sources onto the target’s schema, such as the Elastic Common Schema. The sigma command (sigma-cli) wraps pySigma, and engines such as RSigma evaluate rules directly against events.

Why teams pick it

  • Write once, run on many SIEMs: the same rule converts to Splunk, Elasticsearch, Sentinel, QRadar, CrowdStrike and more than 30 backends in all
  • A large free rule set: more than 3,000 peer-reviewed rules in the SigmaHQ repository (generic, threat hunting, emerging threats, compliance), released as packages every quarter
  • Plain YAML files suit detection as code: they live in Git, get reviewed in pull requests and deploy through CI/CD
  • Built into other tools: MISP, VirusTotal, Security Onion and IBM QRadar, among others, support Sigma rules natively

Watch out for

  • No engine of its own: results depend on the backend, type modifiers such as re work only where the backend supports them, and pySigma and sigma-cli still carry a pre-release status badge
  • Field mapping is the hard part: rules use Sigma’s generic field names, so every data source needs a pipeline that maps them to the names in your logs
  • Deliberately limited: basic searches plus a few correlation types, chosen to cover most day-to-day needs; anything beyond needs the target’s own query language
  • Licenses differ by part: the rules’ Detection Rule License 1.1 requires keeping the rule’s author attribution when you share rules and in alert messages based on their matches

Alternatives

What all threat detection (siem) have in common →
RSigmaOpen sourceA Rust toolkit that parses Sigma rules, compiles them into matchers and evaluates them against log events in real time, correlations included, as one self-contained binary.

How it fits with other technologies

A real rule from the SigmaHQ repository: use of the AWS root user · yaml

title: AWS Root Credentials
id: 8ad1600d-e9dc-4251-b0ee-a65268f29add
status: test
description: Detects AWS root account usage
references:
    - https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html
author: vitaliy0x1
date: 2020-01-21
modified: 2022-10-09
tags:
    - attack.privilege-escalation
    - attack.initial-access
    - attack.persistence
    - attack.stealth
    - attack.t1078.004
logsource:
    product: aws
    service: cloudtrail
detection:
    selection_usertype:
        userIdentity.type: Root
    selection_eventtype:
        eventType: AwsServiceEvent
    condition: selection_usertype and not selection_eventtype
falsepositives:
    - AWS Tasks That Require AWS Account Root User Credentials https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html
level: medium

The parts of Sigma#

“Sigma” names a format, a rule collection and a toolchain, each in its own repository and under its own license.

Specification

public domain

The rule, correlation and filter formats, with appendices for modifiers, tags and the taxonomy of field names and log sources, plus JSON schemas. Version 2.1.0 was released on August 2, 2025.

Rule repository

DRL 1.1

SigmaHQ/sigma: more than 3,000 rules in folders for generic detections, threat hunting, emerging threats, compliance and placeholder rules, published as rule packages on the releases page.

pySigma

LGPL 2.1

The Python library that parses rules and converts them. Backends for query languages and pipelines for log data models ship as separate packages, to keep the core slim and vendor-agnostic.

sigma-cli

LGPL 2.1

The sigma command on top of pySigma: sigma plugin install splunk, then sigma convert -t splunk -p sysmon rules/. It replaced the legacy sigmac, which reached end of life on August 1, 2024.

Converting rules with sigma-cli#

A backend picks the query language and pipelines map the fields; the same rules can feed several targets.

bash
python -m pip install sigma-cli
sigma plugin install splunk

# process-creation rules into Splunk queries for Sysmon logs
sigma convert -t splunk -p sysmon sigma/rules/windows/process_creation

# the same rules as a Splunk savedsearches.conf file
sigma convert -t splunk -f savedsearches -p sysmon -o savedsearches.conf sigma/rules/windows/process_creation

See it in a real stack

No architecture uses Sigma yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2016–2026

Analysts shared indicators of compromise and YARA rules for malicious files, but had no common way to describe a detection in log events, so searches built for one SIEM stayed there. Florian Roth came to Thomas Patzke with an already concrete idea for a signature format for log events. They refined it by trading voice messages, and the next day Roth wrote the first rules: the commit “First Example Set”, with rules for a cleared event log and for failed logon reasons, is dated December 24, 2016.

Over two to three months they worked through problems such as different field naming conventions, solving them in the rule language and the converter, much of which Patzke wrote. Sigma was released in 2017, and Patzke presented it at Hack.lu that year. Both had built it out of their own pain handling incidents, and large organizations often run several SIEMs: with Sigma, a rule written once could become a Splunk or ArcSight query, an Elasticsearch query or a grep one-liner. MISP added native Sigma support in March 2017, and by 2019 some users listed Sigma support as a requirement when buying security products.

The original converter, sigmac, was replaced by pySigma, a library with backends and pipelines in separate packages, and its command-line front end sigma-cli. Specification 2.0 in August 2024 dropped the old aggregation expressions for correlation rules and added filters, and sigmac reached end of life on August 1, 2024. The project now lives in the SigmaHQ organization, maintained by a group that includes Roth and Patzke along with Nasreddine Bencherchali, Christian Burkard, François Hubaut and others.

Why it’s built this way

YAML for rules
The Sigma FAQ says YAML is easy to read and write, flexible and has all the language elements needed, while admitting it lacks a standardized schema language like XML’s (the specification later added JSON schemas).
Generic log sources instead of product-specific ones
One rule with category: process_creation replaces separate rules for Sysmon, Windows Security auditing and kernel process events; converters map the abstract log source to the right indexes, so the rule isn’t tied to one telemetry source.
Convert to each SIEM rather than ship an engine
Organizations already ran Splunk, ArcSight and Elasticsearch side by side. Converting meant writing a rule once for all of them; Patzke said they would be fine with the converter becoming obsolete through native Sigma support, as YARA and Snort have in many products.
Simple searches and a few common correlations
The design covers basic searches and counts, which the project says meet more than 90% of day-to-day detection needs, in exchange for rules that can be shared across all sorts of security environments.

Timeline

  1. 2016

    Florian Roth commits the first example rules on December 24

  2. 2017

    Sigma is released; MISP 2.4.70 adds native support in March; Thomas Patzke presents it at Hack.lu

  3. 2022

    Specification 1.0.3 published on December 28

  4. 2024

    sigmac reaches end of life on August 1; specification 2.0 adds correlation rules and filters on August 8

  5. 2025

    Specification 2.1 adds sum, average and percentile correlations on August 2

  6. 2026

    Quarterly rule packages continue, the latest released in July

Sources14 · facts checked 12 October 2026

Improve this page on GitHub