What Sigma Is & Rule Anatomy
What is it?
Sigma is a YAML format for describing a log detection independently of any SIEM. A rule has a title, a logsource (which data), a detection (selections + a condition), and metadata — then a converter translates it to Splunk, Elastic, etc.
Why it matters
Detections written in one SIEM's query language die with that tool. Sigma is portable: write the logic once, run it anywhere, and share it with the community.
Where you see it
A .yml file: `logsource: {category: process_creation, product: windows}` then `detection: {selection: {...}, condition: selection}`.
What normal looks like
A well-formed rule with a clear logsource, a focused selection, and a condition that names the selection(s) — readable and convertible.
What suspicious looks like
A rule with no logsource (it matches the wrong data), or a detection whose condition does not reference its selections — it will not convert or will match nothing.
How analysts investigate
Read a rule top-down: what data (logsource), what to match (selection), how to combine (condition). If any of the three is missing or mismatched, the rule is broken.
Common beginner mistakes
- Omitting or mismatching logsource, so the rule runs against the wrong events.
- Writing a condition that does not reference the selection.
Portable detection in YAML
title: Encoded PowerShell from Office
logsource: { category: process_creation, product: windows }
detection:
selection:
ParentImage|endswith: '\WINWORD.EXE'
CommandLine|contains: '-enc'
condition: selection
→ converts to Splunk/Elastic; logic outlives the toolQuick check
What makes Sigma valuable over a SIEM-specific query?
A quick self-check — it doesn't affect your XP or progress.
Sign in to save your progress on the server.