Detection engineering

Sigma detection library: 103 platform-agnostic rules across 10 MITRE ATT&CK tactics

Sigma is the detection rule format that compiles to anything — Splunk SPL, Elasticsearch queries, Wazuh rules, QRadar. Write once, deploy anywhere. These 103 rules were authored to Sigma spec with explicit logsource schemas, false positive filters, and MITRE technique tags, so they are deployable without modification in any SIEM that supports Sigma compilation.

Verify count: (Get-ChildItem -Recurse .\detection-rules\sigma -Filter *.yml).Count

Context

Platform-specific detection rules are technical debt. Write a Splunk query, and it runs only in Splunk. Write a Wazuh XML rule, and it runs only in Wazuh. Sigma decouples the detection logic from the implementation. The rules in this library were authored to the Sigma specification so they can be compiled to any supported backend — which means the coverage survives a SIEM migration. It also means every rule documents its own logsource, technique mapping, and false-positive considerations as part of the format, not as a separate document.

Problem

ATT&CK Tactic	Rules	Example detections
Collection	10	Screen capture, keylogging, data staging
Credential Access	10	LSASS access, DCSync, Kerberoasting, browser credential theft
Defense Evasion	10	Log clearing, masquerading, obfuscation, security tool tampering
Discovery	10	User/domain enumeration, network scanning, share discovery
Execution	9	PowerShell encoded execution, LOLBin abuse, script host anomalies
Exfiltration	10	Unusual outbound transfer, DNS tunneling, staging indicators
Impact	13	Ransomware indicators, shadow copy deletion, service disruption
Lateral Movement	10	Pass-the-hash, RDP anomalies, admin share abuse, WMI remote exec
Persistence	11	Scheduled tasks, registry run keys, service installation
Privilege Escalation	10	Token manipulation, abnormal group changes, UAC bypass
Total	103

Approach

Every Sigma rule in this library ships with all required fields. Example structure from the LSASS detection:

title: Suspicious LSASS Process Access
id: a3f72d8e-1b94-4c3f-b6e0-7d8a9e2f1c05
status: stable
description: Detects suspicious access to lsass.exe
  that may indicate credential dumping
tags:
    - attack.credential_access
    - attack.t1003.001
logsource:
    product: windows
    category: process_access
    service: sysmon
detection:
    selection:
        EventID: 10
        TargetImage|endswith: '\lsass.exe'
        GrantedAccess|contains:
            - '0x1410'
            - '0x1010'
            - '0x1438'
    filter_known_good:
        SourceImage|endswith:
            - '\wmiprvse.exe'
            - '\taskmgr.exe'
            - '\MsMpEng.exe'
    condition: selection and not filter_known_good
falsepositives:
    - Legitimate security software (EDR agents)
    - Authorized memory forensics tools
level: high

Required fields in every rule

title — human-readable, unambiguous name.
id — stable UUID for deduplication across environments.
status — stable / experimental / test. No rule ships as "test" without a comment.
description — what this detects and why it matters.
tags — MITRE ATT&CK tactic + technique IDs. Required. No untagged rules.
logsource — explicit product, category, service. Required for compilation.
detection — selection + condition. Filter blocks for known-good processes.
falsepositives — at least one entry. Empty false positives is a red flag.
level — informational / low / medium / high / critical. Not defaulted.

Lessons + next hardening step

A detection rule without false positive handling is a noisy alert factory. Every rule in this library includes explicit filter conditions for known-good behavior. The LSASS rule filters wmiprvse.exe, taskmgr.exe, MsMpEng.exe, and common EDR agents before firing — because those processes legitimately access LSASS memory.

This matters for hiring teams: a rule that fires on everything is not a detection. It's a visibility tax that burns analyst time.

Next hardening step: add tactic-level replay tests so each false-positive filter is validated against real telemetry before promotion.

Outcome

Sigma rules compile to any supported backend. These rules were authored against Windows Sysmon and Windows Security event sources, making them compatible with:

Splunk (via sigmac or pySigma)
Elastic / OpenSearch (Wazuh's indexer backend)
Microsoft Sentinel KQL
QRadar AQL

The same credential-access detection set exists in both Sigma YAML (platform-agnostic) and Splunk SPL (direct implementation) in this repo — illustrating the same logic expressed in both formats.

Evidence

PowerShell (from repo root):

(Get-ChildItem -Recurse .\detection-rules\sigma -Filter *.yml).Count
# Expected: 103

Count per tactic:

Get-ChildItem .\detection-rules\sigma -Directory |
  ForEach-Object {
    $c = (Get-ChildItem $_.FullName -Filter *.yml).Count
    "$($_.Name): $c"
  }

Source of truth: PROOF_PACK/VERIFIED_COUNTS.md — generated by CI on every commit via scripts/verify/generate-verified-counts.ps1.

Browse Sigma rules (GitHub) Verified counts Security page