Writing Sigma Rules That Actually Fire (Not Just Compile)

A Sigma rule that compiles is not a detection. It is a hypothesis. Plenty of rule libraries are full of YAML that converts cleanly to SPL or KQL and never fires once — because the logsource is not collected, the field names do not match the pipeline, or the logic is so broad it gets tuned to death on day one. This is a detection engineer’s checklist for writing Sigma that survives contact with production.

1. Pin the logsource to data you actually collect

The most common failure is a perfectly valid rule sitting on top of telemetry that nobody ships to the SIEM. Before writing detection logic, confirm the logsource is collected, parsed, and field-mapped in your environment.

2. Detect behavior, not a single string

Brittle rules key on one literal — an exact path, a specific tool name — and break the moment an attacker renames a binary. Durable rules describe the behavior: the parent/child process relationship, the command-line shape, the combination of fields that is unusual together.

title: Encoded PowerShell Command Execution
id: 9f3c1a7e-darkpwn-illustrative
status: experimental
logsource:
  category: process_creation
  product: windows
detection:
  selection_img:
    Image|endswith: '\powershell.exe'
  selection_flags:
    CommandLine|contains:
      - ' -enc '
      - ' -EncodedCommand '
      - ' -e '
  condition: selection_img and selection_flags
falsepositives:
  - Some legitimate management and deployment scripts
level: medium
tags:
  - attack.execution
  - attack.t1059.001

This keys on the technique (T1059.001, PowerShell) rather than a hash, so it survives renamed scripts — while still naming realistic false positives.

3. Write the false positives down before you ship

Every real detection has false positives. The rules that survive are the ones whose authors enumerated them up front, in the falsepositives field, and provided a tuning path. A rule with an empty falsepositives block has usually not met production yet.

4. Test every rule against attack telemetry

A detection you have never seen fire is not validated. Generate the behavior safely in a lab — Atomic Red Team and purple-team exercises are built for exactly this — and confirm the rule fires on the true positive and stays quiet on a normal baseline.

5. Map to ATT&CK and track coverage honestly

Tag rules with ATT&CK technique IDs and render the result on a coverage map — but count only validated rules. A technique covered by a rule that has never fired is not covered. Honest coverage beats an impressive-looking matrix.

Where to build the skill (authorized labs)

Detection engineering is a hands-on craft, and the safest way to practice is in authorized labs that let you generate real attack telemetry on demand:

The takeaway

The gap between a rule that compiles and a rule that fires is the entire job. Pin the logsource, detect behavior over strings, write down the false positives, test against real attack telemetry, and gate it all behind CI. Coverage you have not validated is a story you are telling yourself — fire the rule before the adversary does.

Put it into practice on real techniques: the behavioral Kerberoasting detection and the SQL injection detection guide both live or die by the rules-that-fire discipline above. More in the Detection Engineering pillar.