writing-sigma-rules

Writing Sigma Rules

Sigma is the common language for detection logic -- write once, convert to any SIEM. The value is portability and reviewability, but only if the rule is precise: a Sigma rule that matches everything is worse than no rule, because it consumes analyst time and trains the team to ignore alerts. The work is specificity without brittleness.

When to Use

• Translating a TTP, threat intel report, or incident finding into a portable detection rule
• Writing vendor-agnostic detection logic that converts to multiple SIEM backends
• Building or maintaining a detection-as-code pipeline centered on Sigma
• Reviewing or tuning existing Sigma rules for precision and false-positive reduction
• Converting Sigma rules between backends (Splunk, Elastic, Sentinel, CrowdStrike, Chronicle)
• Contributing rules upstream to SigmaHQ or maintaining a private rule repository

When NOT to Use

• Broader detection engineering including YARA, Suricata, and the full detection lifecycle -- use engineering-detections
• The signature belongs on files or memory, not log telemetry -- use writing-yara-rules
• Hypothesis-driven threat hunting, not rule writing -- use hunting-threats
• Active incident response, not rule development -- use responding-to-incidents

Sigma Rule Structure

Every rule is a YAML document with these fields in order:

The specification requires only three fields: title, logsource, and detection (which must contain a condition). Everything else is optional to the spec. Do not confuse that with the SigmaHQ rule repository, which requires far more — id, status, description, author, date, level, and ATT&CK tags — before it will accept a contribution. Write to the stricter SigmaHQ convention by default, because a rule without an id or a level is unmanageable in a real pipeline, but know which constraint you are meeting when a converter accepts a rule your reviewer rejects.

title: Short Descriptive Name              # REQUIRED by spec, max ~100 chars
id: a1b2c3d4-0000-4000-8000-000000000001  # optional to spec; UUIDv4, never reuse
related:                                    # optional, link to predecessor rules
  - id: <uuid>
    type: derived | obsoletes | merged | renamed | similar
status: experimental                        # optional; see lifecycle below
description: >                              # optional to spec, expected by SigmaHQ
  Detects X behaviour consistent with Y technique.
references:                                 # optional, strongly recommended
  - https://attack.mitre.org/techniques/T1059/001/
author: Your Name                           # optional to spec
date: 2026-07-26                            # optional; ISO 8601 YYYY-MM-DD
modified: 2026-07-26                        # optional; same format, on update
tags:                                       # optional to spec, expected by SigmaHQ
  - attack.execution                        #   tactic (lowercase, dotted)
  - attack.t1059.001                        #   technique (lowercase)
logsource:                                  # REQUIRED by spec
  category: process_creation
  product: windows
detection:                                  # REQUIRED by spec
  selection:
    CommandLine|contains: 'some-indicator'
  condition: selection                      # REQUIRED inside detection
falsepositives:                             # optional to spec
  - Legitimate admin scripts using the same flag
level: medium                               # optional; informational|low|medium|high|critical