What is detection engineering?

Key takeaways

Detection engineering is the practice of building, validating and maintaining the logic that identifies malicious activity in an environment, treated as an engineering discipline with version control, testing and measurable coverage rather than as ad-hoc rule writing. Its output is detection content that runs in a SIEM, EDR or XDR platform and has been shown to work against real data before analysts see the first alert.

• The constraint is capacity, not knowledge. Most teams can name the detections they lack. Writing one properly means reading the log schema, validating against real data and back-testing, which is slow, skilled work.
• A rule referencing a field nobody ships is a silent gap. Schema validation is the check most often skipped, and the one that decides whether a coverage dashboard describes reality.
• Back-testing moves tuning out of production. Running new logic against historical logs establishes what it would have caught and how much noise it would have made, before analysts absorb either.
• Provenance sets a rule's priority and its lifetime. A rule written for a technique in general has no natural end. A rule written for a specific unremediated exposure inherits its priority and can be retired when it closes.
• Coverage and ingestion cost are separable. Identifying which ingested sources no live rule references is what lets retention be decided on evidence rather than on budget pressure.

01 - Why does it matter?

In most organisations detection engineering evolved separately from exposure management, and the separation is expensive. Log sources are onboarded broadly and use cases designed for breadth, so the result is generic content that treats every alert as equally important regardless of whether the underlying weakness is exploitable. Alert volume rises, false positives rise with it, and the usual response is more tuning, which does not address why the alerts were low-value.

Meanwhile the rules a team actually needs sit in a backlog measured in months, because writing one correctly means reading the schema as it is rather than as documented, validating against real data, and back-testing. In the middle sits a gap that usually has no owner: an exposure confirmed exploitable that cannot be fixed for three weeks because of a change window. It is the highest-risk state in the environment and often has no compensating detection.

• The backlog is measured in months. Teams generally know which rules they need. Capacity, not knowledge, is the binding constraint.
• Rules get tuned in production. Written against an assumed schema, deployed, then corrected while analysts absorb the noise the first version generated.
• Coverage is generic. Content designed for breadth produces alerts whose importance cannot be judged from the alert itself.
• Intelligence does not become detection. Reports arrive faster than anyone can map them to installed software, and the relevant window closes first.
• Nothing covers exposures awaiting a fix. The riskiest interval in the remediation cycle is routinely the least monitored part of it.

02 - What the discipline involves

• Coverage mapping. Establishing which adversary techniques the environment can detect and which it cannot, usually expressed against MITRE ATT&CK.
• Rule authoring. Writing the logic, increasingly in a neutral format such as Sigma, then translating it to the platform query language.
• Schema validation. Confirming the fields a rule depends on exist, are populated as expected, and are shipped by the hosts in scope.
• Back-testing. Running new logic against historical data to establish what it would have caught and how much noise it would have produced.
• Log optimisation. Determining which ingested sources support active detections, so retention decisions rest on evidence rather than cost pressure alone.
• Detection as code. Managing the lifecycle in version control with peer review, automated testing and continuous integration, exactly as software is managed.
• Retirement. Removing logic whose reason for existing has gone. Without a retirement path the corpus decays into content nobody will delete.

03 - The kinds of detection logic

The classes are not ranked, and a corpus built entirely from one of them fails predictably. Atomic and signature logic is precise and short-lived; behavioural and statistical logic is durable and expensive to tune.

• Atomic indicator matches. Logic keyed to a specific hash, domain or address. Cheap to write, precise while the indicator is current, inert once the infrastructure behind it rotates.
• Signature and pattern rules. Match a known payload or command-line string. Effective against unmodified tooling, defeated by encoding a parameter, reordering flags or substituting an equivalent expression.
• Behavioural rules. Key on what an action does rather than what it looks like: a service account spawning an interactive shell, a document process writing to a startup location. More durable, harder to author, and dependent on process-lineage telemetry.
• Correlation rules. Join events across sources inside a time window, such as an authentication anomaly followed by a privilege change on the same identity. The class most sensitive to clock skew and ingestion delay.
• Threshold and rate rules. Fire when a count crosses a bound: failed authentications, outbound volume, process creation rate. Simple to reason about and simple to evade by staying beneath it.
• Statistical and baseline rules. Compare activity against a learned normal for a host, identity or service. Surfaces behaviour no one thought to write a rule for, and degrades if the baseline period already contained the activity it should flag.

04 - Provenance: where a rule comes from

Detection content can be triggered by several different things, and the trigger determines most of what makes a rule useful. A framework gap produces content answering how a technique would be spotted in general. Alert history answers what has been noisy or missed. A simulated attack answers what an emulation plan produces. Threat intelligence answers what a reported campaign looks like, if it touches software actually installed.

A validated exposure produces something narrower: an attacker could demonstrably do this specific thing on these assets, so what would it look like if they tried. That rule is scoped to real assets, inherits its priority from a demonstrated risk, and has a defined end when the exposure closes. A mature programme uses several of these sources; the difference is that only the last has a built-in expiry.

05 - A worked example: coverage that catches nothing

Consider a rule detecting a suspicious PowerShell invocation. The logic is correct, it converts cleanly to the platform query language, and it shows as a green cell against the relevant ATT&CK technique. It also matches nothing, ever, because script block logging is enabled on the workstation fleet and not on the server estate where the technique would matter. The dashboard reports coverage; the environment has none.

Two checks would have caught it: schema validation, asking whether the fields exist and are populated, and a telemetry check, asking whether the hosts in scope send them. Back-testing catches the opposite failure - logic that is valid but too broad, such as a rule keying on a command-line fragment a deployment tool uses nightly. Running it over ninety days of history surfaces that before an analyst does.

06 - A worked example: detection for an exposure that cannot be patched yet

An internal application server runs a component with a confirmed unauthenticated deserialisation flaw. Exploitation has been demonstrated against the same build in a controlled test, the vendor fix exists, and the change window is nineteen days away. Until then the exposure is known, proven and open.

A compensating detection is scoped to that condition rather than to the technique in general. The population is the twelve hosts running the component, not the estate. The logic keys on behaviour the exploit has to produce rather than the payload it uses: the application service account spawning a child process, which it never does in normal operation, and an outbound connection to a destination outside the recorded set. Both are back-tested against ninety days of history, which establishes that the normal rate is zero.

The rule carries the exposure identifier as its reason for existing, an owner, and an end condition: once the component is patched on all twelve hosts it is retired. Detection is not a substitute for the fix. It removes the case where exploitation during the wait goes unobserved.

07 - How to evaluate a detection engineering practice

• Ask what happens before deployment. Schema validation and back-testing against real history decide whether false-positive rates fall or rise as coverage expands.
• Check that telemetry is verified, not assumed. Coverage claims should be conditional on the affected hosts shipping the fields, verified rather than inferred from a policy document.
• Ask how a rule is retired. Every rule should carry the reason it exists. If nothing can be deleted, the corpus only grows and maintenance cost grows with it.
• Measure technique coverage, not rule counts. A count of enabled rules is not a coverage statement. Mapped technique coverage with a validation status attached is.

08 - Common misconceptions

• More rules means more coverage. Overlapping rules against the same technique add noise and maintenance cost without extending the set of things that can be seen.
• A green coverage matrix means the technique is detected. A matrix records that a rule exists and is mapped. Whether the telemetry is collected on the affected hosts is the separate question that decides.
• Blocking controls close the exposure window. A signature blocks a payload, not a technique. Substituting an equivalent expression, such as 1=1 for true, frequently bypasses it, and blocking rules carry availability risk during exactly the period a change freeze was protecting.
• Tuning is a permanent activity. Most tuning is deferred validation, and work moved before deployment need not be repeated live.
• Detection engineering is a function of the SOC. Authoring and testing logic is engineering work with a release cycle; triage and response are operations work on a shift pattern. Collapsing the two means rules are written by whoever is on duty and tested by whoever gets paged.
• A rule that fires is a rule that works. A rule can fire continuously on benign activity and still count as coverage. What matters is whether it fires on the technique and stays quiet otherwise, and only back-testing establishes both before deployment.

09 - Standards and sources

MITRE ATT&CK is the common reference for expressing which adversary techniques an environment can observe, and ATT&CK Navigator is how coverage is usually visualised. Sigma, maintained by the SigmaHQ project, is the widely used vendor-neutral format for detection logic, with converters that emit the query languages of major platforms. Open schema efforts such as the Open Cybersecurity Schema Framework matter because schema validation is only tractable where field names are predictable.

Frequently Asked Questions

Does detection engineering replace a SIEM? No. It produces the content that runs inside the SIEM, EDR and XDR platforms already deployed, while alerting, triage and response stay with those platforms. Authoring in a neutral format keeps the logic reviewable rather than locked to one syntax.

How is a rule validated before it goes live? Two checks. Schema validation confirms the fields the logic depends on exist, are populated, and are shipped by the hosts in scope. Back-testing runs the logic against historical logs to establish what it would have caught and how much noise it would have produced.

What does exposure-derived detection mean? The trigger for writing the rule was a specific weakness shown to be exploitable on identified assets, rather than a generic template. The rule has a documented reason for existing and a defined end when the exposure closes.

Can detection engineering reduce log ingestion cost? It can make the decision answerable. Log optimisation identifies ingested sources that no active detection references, which is what is needed to right-size retention without opening a gap.

What is the difference between a detection and an alert? A detection is the logic; an alert is one output of it. The distinction matters for measurement: a corpus is judged on mapped technique coverage, validation status and rule provenance, whereas alert counts describe activity volume and rule precision, not how much of the attack surface can be observed.