Writing Sigma Rules That Don't Drown You in False Positives

The False Positive Problem

A detection rule that fires a thousand times a day is worse than no rule — it trains analysts to ignore alerts. Sigma rules need to be specific enough to be actionable while broad enough to catch real attacker behaviour.

Sigma Rule Anatomy

title: Suspicious PowerShell Download Cradle
id: a2f4e8b1-3c7d-4f9a-b1e2-5d6c8f0a2b4e
status: experimental
description: Detects PowerShell using Net.WebClient or Invoke-Expression with URLs
logsource:
  category: process_creation
  product: windows
detection:
  selection_pwsh:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
  selection_download:
    CommandLine|contains:
      - 'Net.WebClient'
      - 'DownloadString'
      - 'IEX'
      - 'Invoke-Expression'
  filter_legitimate:
    CommandLine|contains:
      - 'WindowsUpdate'
      - 'MicrosoftEdge'
  condition: selection_pwsh and selection_download and not filter_legitimate
level: high
tags:
  - attack.execution
  - attack.t1059.001

Tuning Strategy

1. Start broad, measure FP rate — deploy in audit mode first
2. Identify FP patterns — collect 2 weeks of data before tuning
3. Add filters conservatively — each filter should have a documented justification
4. Version control your rules — treat rule changes like code changes

Testing Rules Against Logs

sigma convert -t splunk rule.yml | tee splunk_query.txt
sigma check rule.yml

Defensive Takeaways

• Never deploy a new Sigma rule to prod without testing against 2 weeks of historical data
• Document the FP rate for every rule
• Prioritise high-severity, low-FP rules over comprehensive coverage with noise
• Community Sigma rules are starting points, not finished products