Detection engineering is the discipline of building, testing and maintaining the logic that turns raw security telemetry into reliable alerts. It treats a detection as a software artefact: written to a stated requirement, version-controlled, tested against real attack behaviour, deployed through a pipeline, tuned on measured performance, and retired when it stops earning its place.
That is the short answer. The rest of this article sets out the lifecycle stage by stage, what detection-as-code changes in practice, how to map MITRE ATT&CK coverage honestly, which metrics tell you whether any of it works, and where AI drafting fits under human approval.
Why detection engineering became a discipline
Most SOCs did not choose detection engineering. They arrived because the alternative stopped working.
The alternative was a pile of rules. Some came with the SIEM, some were written during an incident and never revisited, some were copied from a blog post and mapped to a technique nobody validated. Nobody owned them, nobody tested them, and nobody could say which had ever caught anything. The result is an alert queue analysts learn to distrust, the failure described in reducing alert fatigue: the problem is rarely too few detections, it is too many that were never proven.
Detection engineering borrows the parts of software engineering that solve that problem. A requirement, a test, a review, a deployment record, and a measurement of whether the thing works in production.
The detection engineering lifecycle
Seven stages, run as a loop rather than a project. Each stage has an output the next consumes, which stops the process collapsing back into ad-hoc rule writing.
1. Requirements. Start with the threat and the decision, not the query. Name the behaviour you want to catch, the part of the estate it applies to, and what an analyst should do when the alert fires. A detection with no stated decision cannot be judged later, because there is no standard to judge it against. This is also where priority is set: a technique your threat model says is likely and damaging outranks one that is merely interesting.
2. Research. Confirm the behaviour leaves a trace you can see. Check the log source exists, that it is collected from the hosts that matter, that the field you need is present, and that retention covers the window you would investigate over. Many failed detections fail here and are misdiagnosed as bad logic. If the data is missing, the output of this stage is a telemetry request, not a rule.
3. Develop. Write the logic against the behaviour rather than the tool. Attackers change binaries constantly; the underlying actions change slowly. A detection for an unusual process reading credential material from memory survives a change of tooling, where a hash or a filename does not. Put the triage guidance, the known benign patterns and the owner in the same file as the logic.
4. Test. Two tests, not one. Prove the detection fires on the malicious behaviour, using recorded telemetry from an emulation run or a purple-team exercise. Then prove it stays quiet against a benign baseline drawn from your own estate, not a generic sample. A detection validated only on the attack half of that pair is how a SOC acquires a rule that fires two hundred times a day.
5. Deploy. Ship it through the same route as code: a change request, a reviewer who is not the author, an automated test run, and a record of what went live and when. The point of the review is that a second engineer catches the assumption the first did not know they had made.
6. Tune. Detections decay. Estates change, applications get deployed, and a detection that was precise in March is noisy by September. Review precision and analyst feedback on a fixed cadence, change the logic on evidence from closed cases, and record the reason with the change.
7. Retire. The stage most teams skip. Retire a detection when the behaviour is now blocked at source, when its telemetry has gone, or when its precision has stayed poor through several rounds of tuning. A detection nobody owns and nobody trusts still costs analyst attention every time it fires.
Detection engineering framework: detection-as-code
Detection-as-code is what makes the lifecycle enforceable rather than aspirational. Detection logic, its tests, its metadata and its response guidance live in version control. Changes arrive as pull requests. Tests run automatically. Deployment is a pipeline, not a person editing a rule in a console at four in the afternoon.
The benefits are the ordinary benefits of source control, which is precisely why they are worth having:
- Answerable history. Who changed this detection, when, and what did the tests say at the time. During an incident review, that question gets asked and usually cannot be answered.
- Review before production. A second engineer reads the logic before it can generate alerts for anyone else.
- Repeatable testing. The same test suite runs on every change, so a fix to one detection cannot quietly break another.
- Portability. Logic held as structured content, in a format such as Sigma, can be translated to more than one backend.
- Rollback. A change that misfires is reverted, not reconstructed from memory.
The cost is real: it needs a pipeline, a test corpus and engineers comfortable with git. Adopt the vocabulary without the pipeline and you get the ceremony, not the guarantees.
Mapping MITRE ATT&CK coverage without fooling yourself
MITRE ATT&CK is the common language for describing what an attacker did, which makes it the natural axis for measuring what you can see. It is also the easiest place to generate a comforting number that means nothing.
The trap is counting rules. A technique with one untested rule and one with five validated, high-precision detections render as the same green square. So does a technique whose detection depends on a log source that stopped being collected two quarters ago.
Score each technique on three separate axes instead:
- Telemetry. Do you collect the data that would reveal this technique, from the systems where it would happen, for long enough to investigate?
- Detection. Is there logic that fires on it, and has that logic been tested against a real execution of the technique?
- Reliability. In production, does it fire with acceptable precision, or has it been muted in practice by an analyst who stopped reading it?
A technique counts as covered when all three hold. Anything else is partial, and saying so is the value of the exercise. The output is a prioritised gap list: missing data goes to the platform team, missing logic goes to the detection backlog.
Coverage is not uniform in value either. Weight it by your own threat model. Strong endpoint coverage with thin identity or cloud API coverage is a specific, actionable finding, and one many teams discover only after an incident crosses that boundary.
Testing and validation
Testing is what separates detection engineering from rule writing, so it is worth being concrete about what a good test looks like.
Unit-level validation. Replay a known malicious sample through the detection and assert it fires. Replay a benign sample and assert it does not. Both halves run on every change.
Adversary emulation. Execute the technique for real in a controlled environment and check the whole chain: the telemetry arrived, the detection fired, the alert reached the queue, and the guidance told the analyst what to do. Testing the logic alone hides pipeline failures, and pipeline failures are silent by nature.
Regression testing. Detections interact. Widening an exclusion to quieten one rule can blind another relying on the same field. Running the full suite on every change catches that.
Negative testing against your own noise. Generic benign corpora do not contain your backup agent or your deployment tooling. The false positives that destroy analyst trust are almost always local.
The discipline is the same one independent testing applies to products. In AV-Comparatives Real-World Protection testing, SenseOn recorded a 99% protection rate with zero false positives (full results). The pairing is the point: detection rate alone is easy to buy with aggressive logic a SOC then has to live with.
Detection engineering metrics that matter
Four metrics carry the weight. Two more are commonly reported and are activity, not outcome.
| Metric | What it tells you | How to measure it | How it gets gamed |
|---|---|---|---|
| Precision | Whether analysts can trust the detection | Confirmed true positives divided by all alerts from that detection, over a fixed window | Suppressing noisy detections instead of fixing them |
| Validated coverage | Which attacker behaviours you could actually catch | Techniques where telemetry, tested logic and production reliability all hold | Counting rules mapped to techniques |
| Time to detect | Whether you find the behaviour before it matters | Time from the first observable attacker action to the alert, measured from closed cases | Measuring from alert creation rather than from the attacker action |
| Time to triage | Whether the queue is survivable | Alert creation to analyst verdict, per detection | A mean dominated by fast auto-closures |
| Alert volume | Nothing on its own | Count per detection per day | Treated as a proxy for effort |
| Rule count | Nothing on its own | Count of deployed detections | Treated as a proxy for coverage |
Two habits keep these numbers honest. Measure precision per detection, not across the estate, because an estate-wide figure hides the handful of rules doing the damage. And derive time to detect from closed cases with a known attacker start point, not from alert timestamps, which measure your pipeline rather than the adversary.
For context on what these figures look like once triage is largely automated, SenseOn publishes a 0.68% true-positive density across investigated cases and resolves 92.5% of incidents under human governance. The point is not the numbers but that both are stated per case and can be checked, which is the standard to hold any platform to.
Detection engineering best practices for SOC teams
The practices below are the ones that separate teams whose detection programme compounds from teams whose programme accumulates.
Give every detection an owner. A named person, recorded in the file. Unowned detections go stale, and nobody dares delete them.
Write the response with the detection. If an engineer cannot say what an analyst should do when it fires, it is not finished.
Prioritise from your own threat model. Public technique popularity is a starting point, not a plan. A financial services firm under FCA scrutiny and a manufacturer inside NIS2 scope have different first ten detections.
Treat missing telemetry as a first-class output. The detection backlog and the data backlog are different queues with different owners. Mixing them means the data gaps never get fixed.
Run purple-team exercises on a schedule, not as an annual event. An annual feedback loop into the backlog is too slow to change behaviour.
Correlate before you alert. Individually weak signals across endpoint, network, identity, cloud and email become a case when joined. Alerting on each one separately is how a queue reaches a volume nobody can read. This is the architecture argument set out in AI in threat detection and in the platform comparison in best EDR solutions.
Review retirement quarterly. Put it in the calendar; it never happens otherwise.
Where AI fits, and where a human still signs
AI is useful in detection engineering, in a narrower place than the marketing suggests.
What it does well is drafting and testing. Given a technique and a telemetry schema, a model can produce candidate logic, generate test cases, suggest the benign patterns likely to trigger it, and translate a detection between query languages. That removes most of the typing and much of the research, the parts of the lifecycle that scale badly with headcount.
What it should not do is approve its own work. A detection is a standing decision about what will interrupt a human being, and that needs an accountable owner. On the SenseOn platform, the Forge agent drafts and tests detections for a detection engineer to approve. The engineer reviews the logic, the test evidence and the expected alert volume, then approves or rejects, and the reasoning behind the draft is recorded in the Decision Trace.
The same boundary applies to tuning. A model can propose an exclusion from a pattern in closed cases. Whether that exclusion is acceptable is a risk decision, because every exclusion is a small deliberate blind spot. That belongs to a person. Will AI reduce SOC work? sets out which parts of the job this removes, and the SenseOn platform page describes how the agents and the human approval points fit together.
The practical test for any vendor claim here is simple. Ask what the AI produced, what evidence came with it, and who signed. If the answer to the last is nobody, the tool is making risk decisions on your behalf without a record.
Frequently asked questions
What is detection engineering?
Detection engineering is the practice of building and maintaining the logic that turns security telemetry into alerts a human can act on. It covers writing the detection, testing it against real attacker behaviour, deploying it through a controlled pipeline, measuring how it performs in production, tuning it, and retiring it when the behaviour it watches for no longer matters.
What are the stages of the detection engineering lifecycle?
Seven: requirements, research, develop, test, deploy, tune and retire. Requirements name the threat and the decision the alert supports. Research confirms the telemetry exists. Develop writes the logic. Test proves it fires on the behaviour and stays quiet otherwise. Deploy ships it through review. Tune acts on production evidence. Retire removes detections that no longer earn their place.
What is detection-as-code?
Detection-as-code means holding detection logic, its tests and its response guidance in version control and shipping changes through the same pipeline as application code. Every change gets a reviewer, an automated test run and an audit trail. The practical gain is not elegance. It is that you can answer who changed a detection, when, why, and what evidence said the change was safe.
How do you measure MITRE ATT&CK coverage honestly?
Score each technique on whether the telemetry exists, whether a tested detection fires on it, and how reliable that detection is in production. A technique only counts as covered when all three hold. Counting rules mapped to techniques inflates the picture, because one untested rule and five validated ones both read as a green square on the matrix.
Which detection engineering metrics matter most?
Four carry the weight. Precision tells you the share of alerts from a detection that were genuine, and it decides whether analysts trust it. Validated coverage tells you which attacker behaviours you could actually catch. Time to detect tells you whether you find the behaviour before it matters. Time to triage tells you whether the queue is survivable. Alert volume and rule count measure activity, not defence.
Can AI write detections for you?
AI can draft and test detection logic quickly, which removes most of the typing and much of the research. It should not be the thing that approves the result. On the SenseOn platform the Forge agent drafts and tests detections for a detection engineer to approve, so the accountable decision stays with a named person and the reasoning stays on the record.
