Sigma Rules Explained: A SOC Analyst's Reading Guide

Sigma rules are a generic, YAML-based format for writing SIEM detection logic once and running it almost anywhere. Instead of hand-writing the same brute-force detection separately in Splunk SPL, Microsoft Sentinel KQL, and Elastic Query DSL, an analyst or detection engineer writes one Sigma rule and converts it into each target platform's native query language as needed.

What a Sigma Rule Actually Is

A Sigma rule is a plain-text YAML file that describes a pattern of log events worth flagging, written in a structured, tool-independent way. The SigmaHQ project describes it as "a generic and open signature format that allows you to describe relevant log events in a straightforward manner," and draws a direct comparison in its own documentation: Sigma is meant to do for SIEM log detection what Snort does for network traffic and YARA does for files. The public repository holds thousands of community-contributed rules spanning generic detections, threat hunting, emerging-threat coverage, and compliance checks.

The point of a Sigma rule isn't the YAML itself. It's the idea underneath it: a detection engineer writes the logic for "flag a failed logon against the built-in Administrator account" exactly once, then hands that single file to a converter that produces the equivalent query for whichever backend a given team runs. The rule is the source of truth. The SIEM query is a generated artifact, not something anyone maintains by hand across three different consoles.

Why Sigma Exists: One Rule, Every SIEM

Before a shared format like Sigma existed, sharing a detection with another team meant a few bad options: paste the raw SPL and hope they also run Splunk, rewrite the logic by hand in KQL or EQL, or describe it in prose and let someone re-implement it. None of that scales, since most organizations run more than one security tool at once.

Sigma treats a detection like source code that happens to describe security logic instead of application logic, an approach usually called detection-as-code. The rule lives in version control, gets reviewed like a pull request, and compiles down to different targets the same way source code compiles for different platforms. That's what makes a detection genuinely portable: a rule matching Windows Security 4625 events doesn't need to know or care whether the analyst reading its output is staring at Splunk, Sentinel, Elastic, or QRadar. SIEM platforms differ enormously in query syntax and data model, and Sigma is the layer that lets one detection idea survive a platform migration instead of getting rewritten from scratch.

How a Sigma Rule Is Structured

Every Sigma rule breaks into metadata fields plus two required sections. Per the SigmaHQ rule specification:

• title: a short, specific summary of what the rule catches.
• id: a UUIDv4 that uniquely identifies the rule, so two rules with similar titles never get confused with each other.
• status: stable, test, experimental, deprecated, or unsupported, a signal for how much you should trust the rule not to false-positive.
• description, author, date, references: standard metadata, the same fields you'd want documented on any piece of code you didn't write yourself.
• logsource (required): which logs the rule searches, expressed through fields like product (e.g. windows), service (e.g. security), or category (e.g. process_creation).
• detection (required): the actual match logic. One or more named selections, each a set of field-value conditions, combined by a condition line at the bottom.
• level: informational, low, medium, high, or critical.
• falsepositives: known legitimate activity that can trigger the same pattern, so whoever reads the alert knows what to rule out first.
• tags: framework references, most commonly MITRE ATT&CK technique IDs.

Inside detection, the YAML structure itself carries meaning. A dictionary of fields is an AND: every field in that block has to match. A list of values under one field is an OR: any single value matching is enough. The condition line decides how the named selections combine, something like selection on its own, or selection1 and not filter when a rule needs to exclude known-benign traffic.

A Worked Example: Reading a Sigma Rule Field by Field

Here's an illustrative rule, written in the style you'd find in the SigmaHQ repository, detecting a failed logon against the built-in local Administrator account. It isn't copied from any specific vendor or published source; it's built to show the structure clearly.

title: Failed Logon Against Built-In Administrator Account
id: 8a2e1f6c-9b3d-4c71-8e2a-5f9d3c7b1a44
status: experimental
description: |
    Detects a failed logon attempt (Event ID 4625) targeting the built-in
    local Administrator account, a common target for password guessing
    since the account name is predictable and, on older builds, exempt
    from normal lockout policy.
references:
    - https://attack.mitre.org/techniques/T1110/001/
author: SOCSimulator Research
date: 2026-07-27
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4625
        TargetUserName: 'Administrator'
        LogonType:
            - 3
            - 10
    condition: selection
falsepositives:
    - A legitimate administrator mistyping their own password
    - A scheduled task or service configured with an expired Administrator credential
level: medium
tags:
    - attack.credential-access
    - attack.t1110.001

Read it top to bottom the way you would if this landed in a pull request instead of one you wrote yourself.

title and id identify the rule uniquely. The id is what a correlation rule or a rule-management tool references, not the title, since titles can drift over time while the id stays fixed.

description explains in one sentence why TargetUserName: Administrator matters: the built-in local Administrator account has a fixed, guessable name, which makes it a favorite target for T1110.001, password guessing.

logsource says this rule applies only to Windows Security-channel events, the same channel covered in how to read Windows event logs and the Windows event IDs cheat sheet. A converter uses this field to pick the right index or table name for the target platform.

detection.selection lists three fields as a dictionary, so all three must match: EventID: 4625 (failed logon), TargetUserName: Administrator, and LogonType matching 3 or 10, a list, so either value counts. That last field narrows the rule to attempts arriving over the network or via RDP rather than someone standing at the console.

condition: selection is the simplest possible condition: the rule fires whenever selection matches on its own. More elaborate rules combine several named selections and filters on this line.

falsepositives names the two most likely benign explanations before anyone even opens the alert, which is exactly the context an analyst wants sitting next to the trigger.

level: medium reflects that one failed logon against Administrator is suspicious but not proof of compromise by itself. A detection engineer would typically pair a rule like this with a Sigma correlation rule, a separate rule type that counts repeated matches from one source over a time window, before escalating severity on volume.

tags close the loop back to ATT&CK, which is worth its own section.

Sigma rules aren't limited to logon telemetry. A rule matching Sysmon Event ID 1 (process creation) for powershell.exe launched with an encoded command-line flag is just as common in the wild, and it would carry tags like attack.execution and attack.t1059.001, mapping to T1059, Command and Scripting Interpreter. The shape barely changes. Only the logsource and the fields inside detection do.

How Sigma Maps to MITRE ATT&CK

The tags field is where a Sigma rule declares its place in MITRE ATT&CK. The convention, confirmed in SigmaHQ's own rule documentation, is attack.tactic-name for the tactic and attack.tXXXX (lowercase) for the technique, so a credential-access rule targeting brute force carries both attack.credential-access and attack.t1110.001 side by side.

That pairing does real work once a rule fires. An alert tagged attack.t1110.001 tells the analyst reading it, without any extra digging, that the underlying technique is password guessing rather than password spraying or credential stuffing, which changes what to check next: one account under sustained attack versus many accounts each getting a light touch. At the team level, tags rolled up across the whole Sigma rule set become a coverage map, the same way a hand-built ATT&CK heatmap does: which techniques have a rule behind them, and which don't. MITRE's own site is the canonical source for what each technique ID actually means, and cross-referencing a rule's tags against it is a normal part of validating that a rule matches the technique it claims to.

How Analysts Actually Use Sigma Day to Day

Very few analysts hand-convert Sigma rules line by line. The current official tool is sigma-cli, a command-line interface built on the pySigma library, and both live under the SigmaHQ GitHub organization alongside the main rule repository. A real conversion, per SigmaHQ's own getting-started guide, looks like this:

sigma convert --target splunk --pipeline splunk_windows ./rules

That single command reads every Sigma rule in the ./rules folder and prints the equivalent Splunk SPL. Swap --target splunk for --target elasticsearch or another supported backend and the same rule produces a different platform's native query, without touching the YAML at all. Commercial platforms like SOC Prime layer additional tooling on top of this same open ecosystem: hosted conversion, curated rule feeds, and management UIs for teams that want more than the free command-line path.

Day to day, a working analyst is more likely to read Sigma than write it. Vendor writeups and GitHub advisories increasingly ship a Sigma rule alongside the prose explanation of an attack, and reading logsource and detection tells you exactly what evidence the author expects to see, often more precisely than the paragraph above it. Detection engineers write and tune rules in Sigma before converting them into whatever the team's actual SIEM runs, and a solid Sigma rule set becomes the backbone for a lot of the SIEM use cases a team maintains, since the logic stays reviewable in one shared format instead of scattered across per-platform syntax nobody else on the team can read.

Sigma vs. YARA: Two Formats, Different Jobs

The two get mentioned in the same breath often enough that it's worth being precise about the difference. YARA matches patterns inside files and running processes: byte sequences, strings, PE header traits, anything that identifies a piece of malware or a malicious document. It answers "does this file look like something bad?" Sigma matches patterns inside log events flowing through a SIEM: an authentication log, a process-creation event, a firewall log line. It answers "does this sequence of activity look like something bad?"

Both are open, YAML- or text-based, community-maintained formats built around the same underlying philosophy: describe a detection once, in a way that isn't locked to one vendor's product. A mature detection program typically runs both side by side, YARA scanning files at the endpoint and file-analysis layer, Sigma watching the log stream for behavioral patterns neither one alone would catch. Knowing which format is used where, and why, is a fair thing to bring up in a SOC analyst interview.

Common Mistakes Beginners Make Reading Sigma Rules

Treating the title as the detection logic. A title like "Suspicious PowerShell Execution" tells you nothing about what actually triggers the rule. The fields inside detection are the detection. Read those before assuming you know what the rule catches.

Missing that YAML structure encodes AND/OR. A newcomer will read a list of values under one field and assume it means all of them have to match, when a list is an OR. Misreading this inverts what the rule actually looks for.

Ignoring falsepositives. That field exists because someone already thought through the benign explanations. Skipping it means re-deriving, under pressure during a live triage, context the rule author already handed you for free.

Assuming level reflects confirmed severity. A rule's level field is a static estimate set when the rule was written. It's a starting point for triage priority, not a verdict on the specific alert sitting in front of you right now.

Confusing the Sigma rule with the converted query. The YAML is the source. The SPL, KQL, or EQL your SIEM actually runs is generated from it. If a converted query looks wrong, the fix belongs in the Sigma rule, not as a hand-edit to the generated query that the next conversion run will silently overwrite.

How to Start Learning Sigma

1. Read before you write. Browse the SigmaHQ repository and open five or six rules for techniques you already recognize, like T1110 or T1059. Reading real, published rules teaches the structure faster than any explainer, this one included.
2. Install sigma-cli and convert something. pip install sigma-cli plus a backend plugin gets you running real conversions against real rules within minutes, which makes the abstract YAML fields concrete.
3. Map a rule's tags back to ATT&CK. Take a rule's attack.tXXXX tag, look up the technique on MITRE's site, and confirm the detection logic actually matches what the technique describes. This is also good practice for spotting a mistagged rule.
4. Practice reading, not memorizing. The goal isn't reciting field names. It's being able to open an unfamiliar rule during a live shift and know within thirty seconds what evidence it's watching for and why.
5. Cross-reference against raw telemetry. The technique library and playbooks give you the other half: what the evidence a Sigma rule matches on actually looks like in a real console, not just in the YAML describing it.

Where This Fits Into Your Triage Workflow

Sigma rules aren't a separate skill from alert triage. They're the readable version of the exact logic your SIEM's black-box alerts already run, and once you can read one, a vague alert title stops being a mystery, since the detection block underneath it (when a vendor exposes it) tells you precisely what fired and why. That's the same instinct behind reading raw IOCs instead of trusting a pre-built dashboard, and the same instinct behind threat hunting: going to the source of a detection instead of stopping at the label it was given.

If you want to practice pivoting from a raw alert to the detection logic behind it, on consoles that behave like the real thing instead of a clean textbook example, SOCSimulator's SIEM, XDR, and firewall environments are built around exactly that gap, free to start.