Detection engineering
Detection Engineering Lab
Windows behavior detections with executable Sigma rules, evidence-linked investigations, and a fixture-tested tuning lifecycle.
Inspect the system
Inspect reproducible rules, correlation, and analyst reasoning. Telemetry is synthetic, dispositions are simulated, and the optional Wazuh path has no live captures.
- Stack
- Python, Sigma, Windows event fixtures, and GitHub Actions.
- Workflow
- Rule → fixture alert → triage → disposition → tuning.
- Evidence scope
- Deterministic fixtures and simulated investigations; no live SIEM evidence.
Overview
I built a detection-as-code lab that connects a rule match to its source records, analyst questions, and tuning history. Its five Windows behaviors cover encoded PowerShell, privileged group membership, authentication sequences, scheduled-task content, and Office-parent PowerShell execution.
Problem
A matching rule establishes a signal, not an incident. Detection engineering also needs negative cases, timing boundaries, missing context, and a way to check whether a noise-reduction change suppresses useful observations.
From rule to regression
- Detection contract
- Sigma and fixtures
- Matching and correlation
- Alert evidence
- Analyst disposition
- Scoped tuning
- Regression validation
The offline CLI validates contracts, evaluates fixtures, verifies source hashes, and generates an alert queue with JSON and Markdown investigations. Six worked cases separate observations from simulated approval, proposed actions, and unresolved questions. The authentication investigation deliberately retains uncertainty about the cause of repeated failures.
Architecture
Six Sigma rules supply predicates to a deliberately bounded Python evaluator. Python separately correlates at least five failures strictly before success within 300 seconds for the same host, account, domain, and source IP. Tests cover identity isolation, duplicates, success resets, exact window boundaries, and tied timestamps. This is batch evaluation of normalized fixtures.
Engineering decisions
- Reject unsupported Sigma conditions and modifiers instead of silently approximating their meaning.
- Preserve the original PowerShell rule and compare it with an exception scoped to the exact command, parent, and user. Changed context remains visible in regression cases.
- Keep fixture integrity checks separate from analyst interpretation. Matching source hashes does not authenticate telemetry or prove a disposition.
Validation
September 7, 2026 CI at 222bc7a passed 28 tests and all 51 fixture assertions in four Ubuntu/Windows jobs. The cases include 23 expected matches and 28 expected nonmatches, including malformed records. Generated reports matched the reviewed outputs.
Sixteen before/after tuning comparisons changed PowerShell matches from ten to nine, removing one authored noise case while retaining all nine intended positives. These counts measure the listed fixtures, not production precision or false-positive reduction.
Lessons / constraints
The completed deliverable is the reproducible offline lab. Hand-authored telemetry and simulated decisions establish no real attack or response. The optional pinned Wazuh setup has static configuration checks but no demonstrated deployment, enrollment, decoder parity, or captured alert. Live adapters, representative telemetry, streaming semantics, and operational quality measurements remain future work.