Sigma

What is Sigma?

Sigma is an open, vendor-neutral format for writing detection rules in YAML, designed so a single rule can be compiled into the query language of whichever SIEM an organization runs. It does for detection content roughly what a portable query language does for databases.

Key takeaways

• One rule, many back ends. A Sigma rule is compiled into Splunk SPL, KQL, Elasticsearch DSL or another target dialect rather than rewritten for each.
• It is a format, not a detection engine. Sigma describes what to match. Execution, alerting and response remain the SIEM's job.
• Field mapping is where the work is. The abstraction only holds if the rule's field names map correctly to how the organization's logs are actually normalized.
• Portability protects content from platform change. A SIEM migration becomes a recompile rather than a rewrite of a rule library built over years.
• Community rules are a starting point, not a deployment. Public rulesets are written against generic environments and generally need tuning before they are usable.

Why it matters

Detection content written directly in a SIEM's native query language is locked to that SIEM. Years of accumulated, tuned rules become a migration cost, which in practice means the platform decision is made once and never revisited regardless of what it costs afterwards.

The second benefit is the one that matters day to day: a portable format makes detection content shareable. A rule published for a new technique can be adopted by an organization running a different SIEM without translation, which shortens the interval between a technique being described publicly and being detectable.

What a Sigma rule contains

• Metadata. Title, identifier, status, author, references, and the ATT&CK techniques the rule relates to.
• Log source. The category, product and service the rule expects — which is what determines whether it can run in a given environment at all.
• Detection logic. Named selections of field-value conditions, combined by a condition expression. This is the substance of the rule.
• False positive notes. Known benign causes, which are what make a community rule tunable rather than merely importable.
• Level. A severity indication that the target platform maps onto its own alerting model.

A worked example of a rule and its compilation

Take a well-documented technique: an attacker using a built-in Windows certificate utility to download a file, because a signed operating system binary attracts less attention than an unfamiliar executable. Expressed in Sigma, the rule declares a log source of category process creation on product Windows, then a selection matching two conditions on the same event — the image path ending in the utility's filename, and the command line containing the argument that turns it into a downloader. The condition expression requires both. A false positives block notes that some software distribution scripts legitimately use the same argument, and the level is set to high.

That single rule compiles to a search in Splunk SPL, to a KQL query for Microsoft Sentinel, to an Elasticsearch DSL query, and to other targets, each generated by a converter rather than written by hand. Nothing about the detection idea changes across those targets; only the syntax does.

The failure mode appears in the same example. The rule refers to fields named CommandLine and Image, which is what the Windows event provides natively. An environment whose pipeline normalizes those fields to process.command_line and process.executable, or drops command-line arguments entirely for privacy reasons, will compile the rule successfully and match nothing at all. The compiler reports no error, because the mismatch is in the data, not in the rule.

Where the abstraction breaks down

Sigma assumes a shared vocabulary of field names that real deployments do not have. The same process-creation event is normalized differently by different agents and different pipelines, so a rule referencing a command-line field will silently match nothing if the data calls it something else. Maintaining the field mapping between Sigma's expectations and a local schema is the recurring cost of the format, and it is not small. Common schemas such as the Open Cybersecurity Schema Framework and Elastic Common Schema exist to reduce this cost, and they help to the extent that a pipeline actually conforms to one.

Expressiveness is the second limit. Detection logic that depends on statistical thresholds, sequences over time, joins across data sources or enrichment lookups sits outside what the format expresses cleanly, and those rules end up written natively anyway. Sigma covers the large, valuable middle of a detection library rather than all of it.

How to evaluate a community rule before deploying it

Public rule repositories are the format's main practical benefit and its main source of alert noise. A short review before import prevents most of the latter.

• Check the log source against reality. The first question is not whether the logic is good but whether the required events are being collected, from the hosts in scope, with the fields the rule reads.
• Check the field names against the local schema. Every field in the detection block needs a verified mapping. An unmapped field is a rule that appears deployed and matches nothing.
• Read the false positives block. It is written by the author who tuned the rule somewhere else, and it is the fastest available list of what will fire benignly.
• Backtest before enabling. Running the compiled query across recent historical data shows the alert volume the rule would have produced, which is the only reliable predictor of whether it is deployable.
• Record the local modifications. Tuning diverges a rule from its upstream version. Without a record of what changed and why, the next upstream update overwrites reasoning nobody can reconstruct.

How Sigma relates to detection as code

They are complementary and frequently confused. Sigma is the artifact format — a portable, reviewable, diff-able representation of one rule. Detection as code is the practice around it: the repository, the pull request review, the automated tests, the deployment pipeline and the rollback path.

Sigma makes detection as code considerably easier, because a YAML rule is something version control and code review handle naturally. But an organization can run a rigorous detection-as-code pipeline entirely in a native query language, and it can equally keep a folder of Sigma rules with none of the surrounding discipline.

FAQ

Is Sigma a SIEM? No. It is a rule format. Sigma rules are compiled into the query language of a SIEM, which does the actual matching, alerting and storage.

Can community Sigma rules be deployed as-is? Rarely. They are written against a generic environment and typically need field mapping and threshold tuning before they produce a usable signal in a specific estate.

Does Sigma cover every kind of detection? No. Statistical thresholds, sequence-based logic, cross-source joins and enrichment lookups are awkward or impossible to express, and those rules are usually written natively.

Sources

• SigmaHQ, Sigma Rule Specification, 2025.
• SigmaHQ, Sigma public detection rule repository, ongoing.
• MITRE Corporation, ATT&CK for Enterprise knowledge base, 2025.
• Open Cybersecurity Schema Framework project, OCSF Schema Documentation, 2025.
• Elastic, Elastic Common Schema (ECS) Reference, 2025.