What Are Sigma Rules? Generic Detection for Logs & SIEM

Sigma is a generic, open, vendor-neutral signature format for describing detections in log data. A Sigma rule expresses a piece of suspicious or malicious activity — for example, a particular command line, a registry change, or a sequence of events — in a standardized YAML format that is independent of any specific SIEM or logging platform. It is often described as "YARA for log files": just as YARA provides a universal way to describe patterns in files, Sigma provides a universal way to describe patterns in logs. Write a detection once as a Sigma rule, and you can convert it to run on Splunk, Microsoft Sentinel, Elastic, and many other backends.

In short: Sigma solves the "every SIEM speaks a different language" problem. It's a portable, shareable way to write a log detection once and run it anywhere.

The problem Sigma solves

Every SIEM and log platform has its own query language — Splunk uses SPL, Microsoft Sentinel uses KQL, Elastic has its own syntax, and so on. This created a painful situation for the security community: a great detection written for one platform was useless to anyone on a different one, and analysts had to rewrite the same logic over and over. There was no common language for sharing log-based detections the way YARA rules or network signatures could be shared. Sigma was created to fix exactly this — to be the open, common format that any log detection can be written in and then translated to whatever backend a team actually uses.

The structure of a Sigma rule

A Sigma rule is written in YAML and has a few key sections:

• Metadata: a title, description, author, references, and often the related MITRE ATT&CK technique — context that makes the rule understandable and maintainable.
• Logsource: specifies what kind of log the rule applies to (for example, Windows process-creation events), so the converter knows where to look.
• Detection: the actual logic — the fields and values that define the suspicious activity, expressed as one or more named selections.
• Condition: how those selections combine (for example, "selection1 and not selection2") to determine a match.

Optional fields like falsepositives and a severity level help analysts understand and triage what the rule will produce.

How Sigma rules are used

The magic of Sigma is the converter. A Sigma rule on its own doesn't run anywhere — instead, a conversion tool translates the generic rule into the specific query language of your platform. The workflow is:

1. Write or download a Sigma rule describing the behavior to detect.
2. Run it through a converter, telling it your target backend (Splunk, Sentinel, Elastic, etc.).
3. Deploy the resulting platform-specific query in your SIEM as a detection.

This means a detection published by a researcher anywhere in the world can be adopted by any team, regardless of which SIEM they run.

A Sigma rule in plain English

You don't need to read YAML to understand what a Sigma rule does — the logic is straightforward. Imagine a rule designed to catch a common attacker technique: clearing the Windows event logs to cover their tracks. In plain terms, the rule would specify a logsource of Windows event logs, a detection that looks for the specific event indicating the security log was cleared, and a condition stating that the rule matches whenever that event appears. The metadata would title it something like "Security Event Log Cleared," describe why that's suspicious, note that legitimate administrators occasionally do this (a documented false positive), and tag the relevant MITRE ATT&CK technique. That single, human-readable rule could then be converted to run on Splunk, Sentinel, Elastic, or any other supported backend. This illustrates Sigma's whole value proposition: the knowledge of what to detect is captured once, in a clear and portable form, separate from the platform-specific query syntax needed to actually run it. It's the difference between writing down a recipe in plain language that any cook can follow, versus writing it in a way only one specific kitchen could use — the recipe (the detection idea) is the valuable, reusable part, and Sigma keeps it independent of the kitchen.

Sigma vs YARA vs Snort

Sigma is best understood alongside the other two major detection formats, which cover different domains:

• Sigma describes patterns in logs — for SIEM and log-based detection.
• YARA describes patterns in files and memory — for identifying malware.
• Snort/Suricata rules describe patterns in network traffic — for intrusion detection.

Together, the three give defenders portable, shareable detection across logs, files, and the network. Mature detection engineering programs use all three.

Why Sigma matters

• Portability: write once, run on any supported backend — no vendor lock-in for your detection logic.
• Shareability: a large open community publishes and exchanges Sigma rules, so teams benefit from each other's work and from rules tied to fresh threat intelligence.
• Detection-as-code friendly: being text-based YAML, Sigma rules fit naturally into version control and automated testing pipelines.
• ATT&CK alignment: rules commonly map to ATT&CK techniques, supporting coverage tracking.

Where threat intelligence fits

Sigma is a key vehicle for operationalizing threat intelligence. When researchers analyze a new attack, they often publish Sigma rules alongside their findings, letting defenders everywhere deploy detection for that threat in their own SIEM within minutes — regardless of platform. This turns intelligence about an emerging technique into immediate, portable detection, which is exactly the goal of modern, sharing-driven defense.

The bottom line

Sigma rules are a generic, open, YAML-based format for log detections — "YARA for logs" — that solve the problem of every SIEM speaking a different query language. Write a rule once, convert it to your backend, and deploy it anywhere. Portable, shareable, and detection-as-code friendly, Sigma sits alongside YARA (files) and Snort (network) as one of the three pillars of modern, community-driven detection content. Adopting it means your hard-won detection logic is never again trapped in a single vendor's query language, and that you can benefit instantly from rules the global community publishes. To pair Sigma detections with current adversary activity, follow our live threat intelligence feed, aggregated from dozens of authoritative sources.