Cybersecurity glossary
What is Detection Engineering?
Learn what detection engineering is, how teams turn attacker behavior into tested alerts, and how to treat detections as products with owners, telemetry, and false-positive control.
Definition
Detection engineering is the practice of designing, implementing, testing, and maintaining security detections as durable products—mapping attacker behavior to telemetry, writing analytics with clear hypotheses, and continuously tuning them so analysts receive actionable alerts.
Why detections need engineers, not just more rules
A SIEM full of vendor defaults is not a detection program. Detection engineering treats each analytic as a product: it has a hypothesis, data dependencies, tests, an owner, and a retirement path when the world changes.
Without that discipline, yesterday’s useful alert becomes today’s page-storm—or silently dies after a log field is renamed.
The detection engineering loop
Frame a hypothesis
Name the behavior you intend to catch, the adversary goal, and what would prove it in your environment.
Inventory telemetry
Confirm the log or sensor actually records the fields, at the right fidelity, with usable retention.
Implement and document
Write the analytic, map it to ATT&CK, and attach investigation steps and expected evidence.
Validate with true and false cases
Replay incidents, purple-team traces, and known-benign admin activity before promoting.
Operate and retire
Watch fidelity, tune, and delete detections that no longer earn their analyst minutes.
What detection engineers actually ship
Analytics and rules
SIEM queries, EDR custom detections, correlation logic, and hunting notebooks that can graduate into alerts.
Telemetry contracts
Field dictionaries, parsers, and source-health checks so detections do not depend on folklore.
Quality gates
Unit tests, historical backtests, and promotion pipelines that stop unreviewed console edits.
Analyst enablement
Runbooks, enrichment, and context so a true positive is actionable in minutes, not hours of archaeology.
Quality signals worth tracking
| Signal | Healthy pattern |
|---|---|
| True-positive rate | Alerts regularly match the stated hypothesis, not adjacent trivia |
| Time-to-investigate | Runbook plus enrichment gets an analyst to a decision quickly |
| Telemetry freshness | Source lag and parser errors are visible before detections go blind |
| Coverage intent | Priority techniques have detect, prevent, or accepted-gap owners |
| Change control | Rule edits are reviewed, tested, and reversible |
- Require a written hypothesis and ATT&CK mapping before a detection is production-paged.
- Store detections in git with code review; ban undocumented SIEM console changes.
- Backtest new analytics against historical incidents and known-benign windows.
- Measure false-positive rate per detection, not as one org-wide vanity number.
- Pair every high-severity alert with a playbook and a named owner.
- Retest detections after log-source upgrades, parser changes, or EDR policy edits.
- Prefer behavioral TTPs over single IOC matches that expire in days.
- Schedule tuning time; adding rules without retiring noise is not progress.
The practical takeaway
Detection engineering is how organizations turn attacker behavior into reliable, owned alerts. Treat detections as code with tests and telemetry contracts—otherwise the SOC inherits a pile of unmaintained noise that neither catches nor teaches.
Related security terms
MITRE ATT&CK
Common language for mapping techniques to detections.
Tactics, Techniques and Procedures (TTP)
Behavioral patterns detections should target instead of brittle IOCs alone.
False Positive
Noise that detection engineers must measure and reduce.
False Negative
Missed activity that purple tests and hunting expose.
Security Information and Event Management (SIEM)
Typical runtime where detections execute against correlated logs.
Frequently asked questions
What is detection engineering in simple terms?
It is the craft of turning “we should notice this attack” into a tested alert with the right data, a clear story, and an owner who keeps it healthy.
How is it different from SOC analysis?
Analysts investigate live alerts. Detection engineers build and maintain the content that creates those alerts, including telemetry gaps, rule quality, and documentation.
What does “detection as code” mean?
Detections live in version control with review, tests, and promotion between environments—the same discipline as application code, not one-off SIEM console edits.
Where do detection ideas come from?
Incidents, threat intelligence, ATT&CK coverage gaps, red and purple exercises, hunting findings, and control failures in production.
What makes a detection “good”?
A stated hypothesis, required telemetry, expected true-positive examples, known benign lookalikes, severity, and a playbook that tells the analyst what to do next.
Should every ATT&CK technique have a rule?
No. Prioritize techniques that match your threat model and where you actually have telemetry. Coverage maps without data are fiction.
How do teams keep detections from rotting?
Track fidelity metrics, expire unowned rules, retest after log-source changes, and schedule tuning sprints instead of only adding new content.
References
Explore authoritative guidance and frameworks related to detection engineering.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.