Sigma Rule Structure

The Sigma Rule — Field by Field

In Lesson 8.1, you saw a complete Sigma rule and understood its purpose. Now you need to understand every field, what it controls, and how to write each one correctly. By the end of this lesson, you will be able to read any rule in the 3,000+ SigmaHQ repository fluently.

A Sigma rule is a YAML document with a defined schema. Here is a complete rule with every field annotated:

title: Suspicious PowerShell Encoded Command
id: f4b89c3a-7e2d-4d91-8f1a-3c5e9b0a2d4f
status: test
description: |
    Detects PowerShell execution with encoded command parameter,
    commonly used by attackers to obfuscate malicious scripts.
references:
    - https://attack.mitre.org/techniques/T1059/001/
    - https://docs.microsoft.com/en-us/powershell/
author: CyberBlue Academy
date: 2026/02/23
modified: 2026/02/23
logsource:
    category: process_creation
    product: windows
detection:
    selection_process:
        Image|endswith: '\\powershell.exe'
    selection_args:
        CommandLine|contains:
            - '-EncodedCommand'
            - '-enc'
            - '-e '
            - '-ec '
    condition: selection_process and selection_args
fields:
    - Image
    - CommandLine
    - ParentImage
    - User
falsepositives:
    - Legitimate administrative scripts using encoded commands
    - Software deployment tools
level: high
tags:
    - attack.execution
    - attack.t1059.001

Let's break down every section.

Metadata Fields

The top block of every Sigma rule provides context about the rule itself — who wrote it, when, and why.

Click to enlarge

title (required)

A short, descriptive name for the detection. This appears in alert dashboards, so make it immediately understandable:

id (required)

A UUID that uniquely identifies this rule globally. Use uuidgen on the command line or any UUID generator. The ID never changes once published — even if the rule is modified.

status (required)

Indicates the maturity of the rule:

description

A longer explanation of what the rule detects and why it matters. Use the pipe (|) in YAML for multi-line descriptions.

references

URLs to threat reports, ATT&CK technique pages, blog posts, or documentation that explain the attack technique this rule detects. Critical for analysts who need to understand the context behind an alert.

author and date/modified

Who wrote the rule and when. The modified field tracks the last update. In SigmaHQ, this helps you identify stale rules that may need review.

The logsource Section

The logsource section tells Sigma which type of log this rule should evaluate. This is what makes Sigma vendor-neutral — instead of specifying a Wazuh index or a Splunk source type, you describe the log category abstractly.

logsource:
    category: process_creation
    product: windows
    service: sysmon

Three fields define the log source:

The detection Section

This is the heart of every Sigma rule — the logic that determines when the rule fires. The detection section uses three concepts: selections, filters, and a condition that combines them.

Selections

A selection is a set of field-value matches. When all fields in a selection match a log event, the selection is true.

detection:
    selection:
        Image|endswith: '\\schtasks.exe'
        CommandLine|contains: '/create'

This selection matches any log event where the Image field ends with \schtasks.exe AND the CommandLine field contains /create.

Field Modifiers

Sigma provides modifiers that control how field values are matched:

Multiple Selections

You can define multiple named selections and combine them in the condition:

detection:
    selection_process:
        Image|endswith: '\\powershell.exe'
    selection_args:
        CommandLine|contains:
            - '-EncodedCommand'
            - '-enc'
    filter_admin:
        User: 'SYSTEM'
        ParentImage|endswith: '\\sccm.exe'
    condition: (selection_process and selection_args) and not filter_admin

The condition Field

The condition is a Boolean expression that combines selections and filters:

Severity, Tags, and Output Fields

level

The severity level determines how urgently analysts should respond:

tags

ATT&CK technique and tactic mappings. Format: attack.<tactic> and attack.t<technique_id>:

tags:
    - attack.persistence        # Tactic
    - attack.t1053.005          # Technique: Scheduled Task
    - attack.defense_evasion    # Tactic
    - attack.t1070.004          # Technique: File Deletion

These tags let your SIEM dashboard correlate alerts by ATT&CK technique and tactic — the same mapping you practiced in Lab 1.2.

fields

A list of log fields that should be included in the alert output. These help analysts triage faster by showing relevant context without opening the raw log:

fields:
    - Image
    - CommandLine
    - ParentImage
    - User
    - Computer

falsepositives

Known scenarios where this rule might fire on legitimate activity. This field serves as documentation for analysts — when they see the alert, they can check these scenarios before escalating.

Click to enlarge

Key Takeaways

• Every Sigma rule is a YAML document with metadata (title, id, status, author), logsource (what logs to evaluate), detection (the matching logic), and context (level, tags, falsepositives)
• The logsource section is the key to Sigma's portability — it abstracts log sources so the same rule works across SIEMs
• Selections define what to look for using field-value pairs with modifiers like |contains, |endswith, and |startswith
• The condition combines selections and filters using Boolean logic: selection and not filter is the most common pattern
• Field modifiers (|contains, |endswith, |all, |re, |base64) control how values are matched against log fields
• Severity levels (informational through critical) determine alert priority and analyst response time
• ATT&CK tags link every detection to the MITRE framework for coverage mapping and correlation

What's Next

You now know the structure of every Sigma rule field by field. In Lesson 8.3, you will put this knowledge into practice by writing your first detections — rules for brute force attacks, suspicious process creation, and unusual service installations. Lab 8.2 has you write your first Sigma rule from scratch.