Articles about detection engineering from security operations practitioners.
I carried a mostly-green ATT&CK heatmap into a detection review. Three weeks later an attacker walked straight through the exact technique the map called covered. After that miss, the first thing my team threw out was the coverage percentage.
The detection engineer job description says: write detection rules, map to ATT&CK, tune false positives. Most of what the role actually requires (debugging broken log pipelines, maintaining exclusion lists nobody documented, writing the investigation context that keeps a detection actionable months after it ships) never makes it into the posting.
A green ATT&CK heatmap measures how many rules you've written, not whether any of them work. Start with the 20 detections that show up most often in real breach chains, validate each one, and only then expand.
We shipped a hundred detections and the ATT&CK heatmap stayed green through fourteen broken rules, week-stale IOCs, and a log pipeline that had stopped exporting months earlier. Every failure traced to the same root: we treated detection engineering as rule writing and skipped the maintenance.
Sigma solved detection portability but not tuning, conversion fidelity, or cloud coverage. Where the format still delivers value and where teams over-rely on it.
Learn where Snort still earns its rack space in 2026, where it's gone blind, and the keep/replace/de-scope call.
Year one of our purple program produced slide decks, not detections. Here's the structural diagnosis and the pipeline model that fixed it.
Detection engineering stalls when it's treated as a person, not a function. Here's what the function actually owns, and how to build it from Level 0.
Practitioner takes on SOC modernization, detection engineering, threat hunting, and more. No fluff. No product pitches.