For years every ATT&CK technique came with one sentence of detection guidance, and that sentence never helped anybody who had to write the query. MITRE retired those fields on 28 October 2025 and put two new objects in their place, Detection Strategies and Analytics, carrying platform-specific guidance, tunable parameters and log sources named without ambiguity: wineventlog:security, auditd:SYSCALL.
The ratio is measurable. ATT&CK v19, the current release, published on 28 April 2026, lists 222 techniques and 475 sub-techniques for Enterprise. Set against those are 697 detection strategies, exactly one per technique and sub-technique, and 1,758 analytics, roughly two and a half each. Where a single sentence used to sit, there are now two and a half analytics with their platform, their parameters and their data source attached.
Detection engineering occupies that gap. It frames the hypothesis, turns it into an analytic that holds up against an adversary who knows it exists, validates it, maintains it and decides when it retires. Security scorecards rarely measure any of that. They measure coverage.
What a coverage percentage actually counts
A SOC reporting 78% coverage of MITRE ATT&CK has counted matrix cells containing at least one rule. The calculation costs nothing and the number presents well to a board. Three flaws hollow it out.
The matrix carries no weighting for prevalence
Every cell counts the same. Adversary activity distributes itself rather differently. Red Canary publishes an annual ranking of the techniques seen most often in confirmed threats, and its methodology is open: over 110,000 threats across 4.5 million identities, endpoints and cloud assets, drawn from 305 petabytes of telemetry across 1,700 organisations, with unwanted programs and authorised testing filtered out.
In the 2026 edition, covering 2025, T1078.004 (Cloud Accounts) leads for a second consecutive year, ahead of PowerShell (T1059.001) and the Windows command shell (T1059.003). Behind them come data from cloud storage (T1530), ingress tool transfer (T1105), email forwarding rules (T1114.003), WMI (T1047), malicious copy and paste (T1204.004), email hiding rules (T1564.008) and obfuscated files (T1027).
Half of that list sits in identity, email and cloud, well away from the endpoint. A SOC with exemplary endpoint coverage and no analytic watching mailbox forwarding rules scores well and leaves technique number six open. It is the shape of the Microsoft 365 account takeovers we have covered. T1204.004 travels under a better-known name: it is the technique behind ClickFix and the fake CAPTCHA lure.
The pyramid of pain does not show up in the matrix
David Bianco set it out in 2013. Hashes, IP addresses and domains sit at the base because an adversary swaps them at no cost, while tactics, techniques and procedures sit at the apex because changing those is expensive. An analytic looking for a hash is precise and brittle at once, blind to the same family altered by a single byte. One built on invariant behaviour survives the edit.
Both score identically in the coverage percentage, and that is where the metric breaks.
Some techniques cannot be covered without context
Summiting the Pyramid calls these ambiguous techniques: those whose invariant behaviours overlap substantially between malicious and benign use. PowerShell is the example that comes up in every conversation about this. Without additional context the analytic drowns in false positives; with too much filtering it turns brittle, and the adversary evades it by operating outside the filter. Marking the cell as covered says nothing about which side of that trade-off the organisation landed on.
Robustness: the measure that replaces coverage
Summiting the Pyramid, from MITRE's Center for Threat-Informed Defense, defines a robust detection through two conditions: accurate, and resistant to adversary evasion over time. Accurate means few false positives and few false negatives. Resistant means it keeps working when the adversary changes implementation. The project splits the work into three domains (telemetry readiness, analytic design and validation) and supplies what was missing: a way to score.
The model rates each observable in an analytic across five levels:
- Level 1, ephemeral values. Hashes, addresses, filenames. Changed at no cost.
- Level 2, core to an adversary-brought tool, or observed from outside the boundary. Whoever controls the tool controls the evasion.
- Level 3, core to pre-existing tools, the legitimate binaries already on the system, or observed from inside the boundary. They were there before the intrusion, which makes them costlier to alter.
- Level 4, core to some implementations of the technique. Low-variance behaviours, unavoidable short of rewriting the implementation.
- Level 5, core to the technique. The unavoidable steps: invariant behaviour no implementation can sidestep.
To those rows the model adds columns for where the signal originates. The host model has three: application, user mode and kernel mode. An adversary calling a lower operating-system function, or issuing a direct syscall, bypasses the event IDs the layer above would have produced. The network model has two: protocol header and protocol payload. Payload content is encrypted or obfuscated far more readily than header content.
Scoring this way changes the board conversation. Instead of "we cover 78%", the sentence becomes "we have fourteen level 4 or 5 analytics across the twelve techniques most prevalent in our sector, and three hundred level 1 analytics awaiting review". The second version can be argued with, budgeted for and audited.
An undocumented detection is not a detection
Palantir open-sourced its Alerting and Detection Strategy Framework, and the diagnosis behind it will be familiar to anyone who has inherited a rule catalogue: engineers wrote detection logic on instinct, with no explicit hypothesis, no record of why an alert should fire and no peer review. The framework has a name for the outcome: alerting apathy.
The framework requires ten sections filled in before anything reaches production: a plain-language goal, ATT&CK categorisation with both parent and child technique, a strategy abstract and the technical context a responder needs. Then blind spots and assumptions, known false positives, validation, priority, response steps and references. Peer review comes last, and only then does the analytic ship.
Two of those sections separate a programme from a drawer of saved queries.
- Blind spots and assumptions. No analytic is perfect. Writing down where it can fail lets another engineer understand how it stops firing and how an adversary who knows it defeats it.
- Validation. The framework asks for the concrete steps that generate a true positive capable of firing the analytic, much like a unit test, and points to Atomic Red Team as one way of producing it. It then sets a rule the framework demands and real catalogues rarely honour: if that true positive cannot be produced, the alert is decomposed, rebuilt or discarded.
An analytic nobody has managed to fire in a controlled test sits in production with no evidence it works. No public survey measures how many are in that position, and the absence of the figure is itself informative.
Detection as code
If analytics are software, they get managed as software: repository, peer review, tests, promotion through environments and a deprecation policy. Sigma makes the logic portable. Its authors describe it as what Snort is to network traffic and YARA is to files, applied to log data, so a detection is written once and converted into each platform's native query.
The pipeline chains the earlier pieces together. An analytic starts as a hypothesis: a hunt that paid off, an intelligence report, a finding from an offensive exercise. It is written up on its own record card, scored for robustness and peer reviewed before being converted and deployed to staging. There it is validated by controlled emulation, checking not merely that the rule fires but that the alert reaches the console and raises a ticket. Only then does it move to production and join the review cadence, which is where retirement gets decided.
Threat hunting feeds that pipeline at its most productive end: a confirmed hypothesis that never becomes an analytic is work you will do again. A threat hunting engagement that leaves capability behind differs from one that leaves a report in precisely that respect.
Emulation-based validation has a further effect that shows up in the accounts. It turns offensive exercises into engineering input: every technique the red team executed without raising an alert is at minimum a pending decision, whether that means a new analytic, missing telemetry or risk accepted in writing. In the exercises we run at Hard2bit, that list of pending decisions ends up drawing more board discussion than the technical report.
What to measure
Jared Atkinson proposed the Funnel of Fidelity at SpecterOps, a model describing detection and response as five phases (collection, detection, triage, investigation and remediation) in which each filter sharply reduces what reaches the next. Its use is to locate the bottleneck before anyone signs a purchase order. A SOC drowning in triage has an analysis capacity problem, and adding rules makes it worse.
Those five phases carry the measures that genuinely describe a detection programme.
- Telemetry coverage per priority technique, ahead of rule coverage. Without the data source the analytic does not exist. Deciding which logs reach the SIEM is therefore a detection decision, not a procurement one.
- Distribution of analytics by robustness level, tracked quarter on quarter.
- Analytics that fired in the past twelve months. Of those, how many produced a decision. Of those, how many produced a confirmed incident.
- Retirement rate. A programme with no deprecations is not alive.
- Analytics in production with no owner, no documented hypothesis or no validation. Zero is the reasonable target, and the starting number tends to surprise people.
- Time from a relevant technique becoming public to a validated analytic existing for it.
One caution about the figures in circulation. Widely quoted cases describe SOCs running thousands of rules of which a handful fired in a year. Those are consulting anecdotes with no published data behind them and should not be treated as industry benchmarks. The number that matters is your own, and it comes out of a SIEM query almost nobody has run.
Where to start without rebuilding the SOC
- Pull the list of analytics in production from the SIEM, with owner and last-fired date attached. That is a query, not a project.
- Compare the techniques genuinely prevalent in your sector against those with a validated analytic. The public ranking is a starting point; your own incident history is a better one.
- Score the robustness of the twenty analytics carrying those techniques. Twenty properly documented analytics are worth more than a half-finished inventory of everything.
- Write down the blind spots of those twenty in specific terms: which implementation slips past, and why.
- Validate through controlled emulation and follow the alert to the end of the funnel, not to the rules engine.
- Set a review cadence and an explicit retirement bar, agreed in writing before it is applied to anything.
None of those steps requires a purchase. All of them require somebody to own the catalogue, which is usually the missing piece. At Hard2bit it is the first thing we examine when we take over a managed SOC we did not build.
What the discipline does not solve
Summiting the Pyramid is candid about its limits, and they deserve repeating because the vendor literature is not. Tampering with data sources falls outside its scope: the model assumes trustworthy telemetry, and an adversary who corrupts the source invalidates the score. Scores also drift, because an operating-system update or a new function in a pre-existing tool can move the level of an analytic that was solid yesterday.
High-level analytics cost more to build, too, since they demand translating a TTP abstraction into low-level observables, and sometimes the necessary telemetry is simply not available in that environment. The project itself acknowledges properties it has not researched in depth: the cost of engineering a detection, of collecting its data, and of running it at scale.
Then there is the obvious constraint, which is also the expensive one. EDR blind spots are not fixed by writing better rules for the places where an agent already runs.
The gap between the framework and the catalogue
The framework moves faster than internal catalogues, and there is recent evidence of it. ATT&CK v19.2, released on 6 August 2026, added ShinyHunters and TeamPCP as groups, and Shai-Hulud and Mini Shai-Hulud as software. Those are, respectively, the actor behind the Salesforce OAuth abuse and the npm worm that plants execution hooks. Months pass between a technique surfacing in an incident and entering the framework; longer still passes before any particular SIEM holds a validated analytic for it.
That lag is the ground detection engineering works on, and it explains why coverage ages badly as a metric: it describes the map from two releases ago. A programme is not organised by counting ticked techniques. It is organised by knowing how many of your analytics you would write again today, and which of them would still fire if the adversary knew exactly how they were written.
This article describes public detection engineering methodologies using information available on 20 August 2026. Framework versions, scoring levels and prevalence rankings change with every publication: always check against the current MITRE ATT&CK and Center for Threat-Informed Defense documentation, and against your own platform, before applying anything in production.
