Detection Engineering & SecOps
Turning knowledge of attacks into durable, tested detections.
Detection engineering is what happens when you stop treating detection content as configuration and start treating it as software: versioned, peer-reviewed, tested against known inputs, monitored in production, and deprecated when it stops earning its keep.
Where Threat Intelligence is the analysis and communication of adversary knowledge, this pillar is the operationalization of it — plus the SOC functions that consume the output: hunting, incident response, and response automation.
Why it matters
Section titled “Why it matters”Two failure modes dominate. First, rules that were never tested and silently stopped firing when a log source changed — the detection exists on paper and nowhere else. Second, alert volume treated as a success metric, which guarantees the base rates make the queue useless. Both are engineering problems with engineering fixes.
How this connects
Section titled “How this connects”- → Threat Intel: intel feeds the detection backlog; detection output feeds intel. The base-rate math (§1.2) is what makes alert-fatigue arguments quantitative rather than anecdotal.
- → Penetration Testing & Red Teaming: the purple team loop. Emulate a technique, verify the detection fires, fix whichever end was wrong. ATT&CK is the shared vocabulary.
- → IAM: identity telemetry is the richest detection surface, and identity-centric containment is the fastest lever in cloud IR.
- → GRC: continuous control monitoring is this pipeline with an auditor as the consumer. Log coverage analysis is shared evidence.
- → AI & Automation: agent-assisted triage and SOAR enrichment, with human approval gates on destructive actions.
- → AppSec: application logs are the least-instrumented tier and the one AppSec can actually fix.
- → Cloud & Infrastructure Security: architecture decides what is observable. Whether east-west traffic is loggable at all is a network design decision, upstream of any coverage gap analysis.
- → Incident Response & Digital Forensics: the closest sibling. This pillar builds and tests the rules; §9 responds and investigates. Every incident produces detection gaps, which is the highest-quality input the backlog gets.
- → Data Security & Privacy Engineering: egress and insider-risk detection is where DLP either earns its keep or generates the noise that discredits it.
What’s here
Section titled “What’s here”| Subsection | Focus |
|---|---|
| Detection as Code | Versioned reviewed tested rules, repo structure and peer review, CI/CD for detection content, Sigma and backend conversion, KQL/SPL/EQL, metadata standards |
| Detection Lifecycle | Idea intake from intel/pentest/incidents/hunts, hypothesis → data check → rule → tune → deploy → monitor → retire, backlog prioritization, rule health, deprecation discipline |
| Data Pipeline & Log Engineering | Log tiers, cloud telemetry, normalization (OCSF, ECS, ASIM), enrichment joins, Cribl/Vector/Fluent Bit and cost control, coverage gap analysis |
| Detection Quality & Testing | Precision and recall, unit testing against synthetic and replayed events, Atomic Red Team validation, ATT&CK Navigator coverage, tuning without gutting, the alert fatigue math |
| Threat Hunting | Hypothesis-driven vs. baseline-driven, structured methodology and documentation, converting hunts to detections, cloud and identity hunting, measuring value |
| SOAR & Automation | Automation candidates, playbook guardrails, agent-assisted triage, human approval gates |
| Program Metrics | MTTD/MTTR and their limits, coverage vs. capability reporting, team models |