Detection Engineering advanced

MTTD Is a Lagging Indicator You Can Game to Zero

MTTD and dwell time only exist after a breach and reward alert volume. Keep them as the board scoreboard; steer your program on leading indicators.

· 15 min read · Gowthamaraj Rajendran

Every detection program metric that starts with “mean time to” shares a property nobody says out loud: it does not exist until you have already been breached.

Mean time to detect, mean time to respond, dwell time: you cannot compute any of them without an incident to measure. They are autopsy numbers. You get one data point per breach, months apart, each confounded by variables you do not control, and you are expected to steer a detection program by them. That is like tuning an engine by reading the crash report.

MTTD is not a bad number. It is a bad steering wheel. This post argues that time-based metrics belong on the board scoreboard and nowhere near your engineering priorities, and lays out the leading indicators that should actually drive the program, tiered by how mature your org is, because the right metric for a two-person detection team is the wrong one for a program running continuous emulation.

A Metric That Only Exists After You Lose

Start with what these numbers actually measure.

IBM’s 2025 Cost of a Data Breach report puts the mean breach lifecycle at 241 days (181 to identify, 60 to contain), the lowest figure in nine years [1]. Mandiant’s M-Trends 2025 reports a global median dwell time of 11 days [2]. Both are genuine, useful, industry-defining measurements. Both are also, structurally, lagging indicators. They describe events that already happened to organizations that already failed to prevent them.

A lagging indicator tells you the outcome of a process after the process is complete. A leading indicator tells you something about the process while you can still change the outcome. Revenue is lagging; pipeline is leading. Breach dwell time is lagging; whether your identity logs are actually reaching the SIEM today is leading.

The problem is not that lagging indicators are useless. They are the truth, eventually. The problem is the feedback loop. If your only real signal about detection quality is dwell time, you learn whether your program worked roughly once per major incident, delayed by the entire length of that incident, and by then the decisions that determined the outcome are a year old. You cannot run an engineering function on a signal that arrives after the thing it is supposed to influence is over.

Detection engineering is a process. You should be measuring the process, not waiting for the body count.

The Confounders You Don’t Control

Here is the part that should end the debate about MTTD as a management metric: even as a lagging measurement, it is confounded so heavily that year-over-year movement often tells you nothing about your program.

Look at the same Mandiant data one level down. Global median dwell was 11 days, but broken out by how the breach was discovered, incidents where the adversary announced themselves (ransomware detonating, an extortion note) had a median dwell of 5 days, while breaches disclosed by an external partner had a median of 26 days [2]. That is a five-fold swing driven entirely by variables that have nothing to do with detection quality.

Think about what actually moves your MTTD:

  • Attacker behavior. A ransomware crew that encrypts on day three hands you a low dwell time. That is not your detection working. That is the adversary choosing to be loud. Your “improvement” is their operational tempo.
  • Incident mix. A quarter heavy on smash-and-grab ransomware posts a better MTTD than a quarter with one quiet, well-run espionage intrusion, even if your detection capability was identical or worse.
  • Disclosure path. Whether the FBI calls you or your own SOC finds it changes the number by weeks. IBM found breaches identified by the organization’s own security team cost an average of USD 4.18 million versus USD 5.08 million when the attacker disclosed them, roughly a USD 900K delta, and internal teams now catch 50% of breaches versus 33% two years ago [1]. That gap is real and worth chasing. But it also means your headline MTTD is partly a function of who happened to notice, not how well you detect.
  • Survivorship. MTTD is only computed on breaches you eventually found. The intrusion still sitting undetected in your environment contributes nothing to the average. Your best-looking quarters may simply be the ones where the thing you missed has not surfaced yet.

A metric where a large fraction of the variance comes from the adversary’s choices and the luck of the disclosure path is not a control surface. You can pour a year of engineering into it and watch it get worse because your incident mix shifted. You can coast and watch it improve because ransomware got noisier. Steering on it is steering on noise.

Goodhart’s Law and the Gaming You Do By Accident

The strongest objection to “just optimize MTTD” is not that teams will cheat. It is that they will succeed, honestly, and make the program worse.

This is Goodhart’s Law, most cleanly stated by Marilyn Strathern: “When a measure becomes a target, it ceases to be a good measure” [3]. The failure mode people picture is fraud: someone fudging the dashboard. The far more common and more dangerous version is sincere optimization. You tell a competent team their job is to drive down time-to-detect, and they will. The question is what lever they reach for, and the cheapest lever is almost always volume.

Detect faster means alert on more things, sooner, at lower confidence. Every low-threshold rule you add lowers your expected time-to-detect for the techniques it touches, because you are now firing on weaker signals earlier. The team is not gaming the metric. They are doing exactly what you asked. The measured MTTD improves. And the queue fills with low-precision alerts.

We know where that ends. The SANS 2025 Detection and Response Survey found 73% of organizations naming false positives their single biggest detection challenge, with “very frequent” false positives climbing from 13% to 20% of respondents year over year [4]. Optimizing for speed and volume is a direct incentive toward the exact false-positive load already breaking SOCs. I have argued separately that this volume is not just an accident: alert fatigue is an offensive technique, something an adversary can manufacture on purpose. A program that has been tuned to minimize time-to-detect has done the adversary’s noise-generation for them, and called it an improvement.

This is the same disease I described in the threat intel context, where programs measure the volume of what they produce instead of whether it improved a decision. Count-based targets always drift toward the thing that is easy to count. For intel it is feeds ingested. For detection it is alerts fired and minutes shaved. Neither is the outcome you wanted.

Statistical Guardrails, Not Better Intentions

You do not fix Goodhart with a memo telling people not to game the metric. They are not gaming it. You fix it by measuring the thing in a way that makes the cheap lever visible when someone pulls it. That means statistics, not single numbers.

Track distributions, not means. A mean is exactly the summary that hides the damage. Report the full distribution of time-to-detect and, more importantly, its variance. A team that lowered its mean by adding twenty low-confidence rules will show a fatter tail and higher variance even when the average looks better. If you only publish the mean, you cannot see the tradeoff you just made.

Pair every speed metric with a precision metric. Time-to-detect and precision (share of alerts that are true positives) must move together on the same dashboard. Speed improving while precision falls is not progress; it is the Goodhart failure caught in the act. Neither number is legible without the other.

Break everything out by cohort and by technique. An aggregate MTTD is a blender. Break it out per detection, per technique, per log source, per severity band. The aggregate can improve while your coverage of a critical technique quietly rots, because a flood of fast, easy detections on noisy techniques drowns the slow, hard ones that matter. Cohort-level breakdowns are how you catch a program that is optimizing the average by neglecting the hard cases.

The pattern underneath all three: a single scalar is trivial to optimize in a way you did not intend. A distribution with paired constraints and cohort splits is not. If you are going to hold anyone to a number, make it a number that gets worse when they do the wrong thing to improve it.

The Steering Wheel: Leading Indicators, Tiered by Maturity

Here is the payload. If lagging metrics are the scoreboard, what do you actually steer by? Leading indicators: things you can measure today, before any incident, that predict whether your detection process is healthy.

But the honest version of this advice is not a flat list of “best metrics.” A two-person detection team measuring the same things as a program running continuous automated emulation will either drown or measure nothing. Leading indicators have prerequisites. You earn the right to the sophisticated ones by having the infrastructure they depend on. Tier them.

Tier 1: Early stage (a SIEM, an EDR, one or two people who write rules)

You have no purple team, no emulation pipeline, and no ground truth. Do not pretend otherwise. Measure the plumbing, because at this stage broken plumbing is your actual risk.

  • Priority-scenario coverage. Not ATT&CK percentage. The count of working detections against your top ten threat scenarios: the specific techniques a relevant adversary would use against your stack. Ten of ten beats a sprawling matrix of untested rules. (This is the coverage side of the detection funnel argument; do not re-derive it, just adopt the denominator.)
  • Rule health / validation pass rate. What share of your enabled rules have actually fired, or passed a functional test, in the last N days? A rule that has never fired is either perfect or dead, and it is usually dead.
  • Log source freshness and completeness. What percentage of expected log sources reported on time today? Half of detection failures trace back to log collection, not logic. This is the cheapest, highest-leverage number a small team can watch.
  • Time-to-deploy a detection. Idea to production, in days. If shipping a rule takes three weeks of tickets, nothing else on this list will improve. Speed of change is the master leading indicator, which is why detection-as-code exists to make deployment boring and fast.

You graduate from this tier when the plumbing is reliable enough that you can trust a test result: when a detection not firing means the logic is wrong, not that the log source was down.

Tier 2: Maturing (a dedicated detection function, some adversary emulation, a detection-as-code pipeline)

Now you can generate ground truth on demand. This is where leading indicators stop being proxies for plumbing and start measuring detection quality directly. Tools like Atomic Red Team give you 1,800+ atomic tests mapped to ATT&CK to run against your environment [5], which is what makes the following measurable.

  • Detection rate in testing. Of the techniques you emulated this cycle, what percentage produced an actionable alert? This is recall you can measure without waiting for a breach.
  • MTTD-in-testing. Time from technique execution to alert firing, in a controlled test. This is the leading version of the lagging MTTD: same measurement, taken before the incident, on a technique you chose, with a clean baseline. It is the single best answer to “how do we measure detection speed without being gamed?”: measure it in the lab, where volume tricks do not help you.
  • Coverage velocity. New validated detections shipped per sprint, and net-new techniques covered. Movement, not a static coverage snapshot.
  • Mean time to remediate a detection gap. When emulation finds a miss, how long until a working detection ships? Gap-closure rate is a purer program-health signal than coverage percentage.
  • False-positive rate by rule cohort. Precision, broken out by source and rule family, tracked as a distribution. This is your Goodhart guardrail from the previous section, operationalized.

You graduate when emulation is continuous rather than a quarterly event, and when your metrics have enough history to show trends and regressions rather than snapshots.

Tier 3: Mature (continuous validation, threat-informed prioritization, multiple teams)

At this tier the leading indicators become second-order: not “do we detect it” but “is our detection capability decaying, and where.”

  • Continuous validation coverage. Share of your prioritized ATT&CK techniques exercised on a rolling cadence, with a pass/fail trend line rather than a point-in-time number.
  • Detection decay / drift rate. Percentage of previously-passing detections that regress between test cycles. This is the metric almost nobody tracks and the one that predicts silent failure best. A rule that passed last quarter and fails this quarter is invisible to every coverage report.
  • Threat-weighted coverage. Coverage weighted by the TTPs of the actors actually relevant to you, so a gap in a top-actor technique counts for more than a gap in one no one targeting you uses.
  • Time-to-detect trend on previously-tested TTPs. For techniques you have covered before, is MTTD-in-testing trending down? This is the only legitimate way to use a time-to-detect number as a steering metric: against a stable, self-chosen baseline, in testing, as a trend.
  • Recall and precision from emulation ground truth. Both, together, from the same exercises: the only place you get real recall without a breach to supply it.

A useful anchor for building this ladder is a published detection-engineering maturity model, which maps capabilities to levels so you can see which indicators you have actually earned the right to measure [6]. The mistake to avoid is reaching up the ladder: adopting Tier 3 decay metrics when your Tier 1 log sources are still flapping produces a beautiful dashboard measuring nothing.

The Strongest Objection

Here is the best case against everything above, and it is a good one.

MTTD, MTTR, and dwell time are universally understood. Every CISO, every board member, every cyber-insurance underwriter knows what dwell time means and can benchmark yours against IBM and Mandiant. They are boardroom-ready in a way that “MTTD-in-testing against a rolling emulation baseline” will never be. Ripping out the metrics executives actually recognize, in favor of leading indicators no one outside detection engineering has heard of, is self-indulgent. It optimizes for the engineer’s sense of rigor over the organization’s ability to have a conversation about risk.

That objection is correct about reporting. It is wrong about steering. And the fix is to stop conflating the two.

Do not rip MTTD out. Report it upward, unchanged, benchmarked against the industry, exactly as the board expects. It is a fine scoreboard: a shared, external, legible number for “how are we doing overall.” Keep it there.

Just do not turn the steering wheel with it. The moment MTTD becomes the target your team is measured and rewarded against, Goodhart takes over and the cheapest path to a better number is more alerts, lower thresholds, and the false-positive load that is already the number-one problem in the field [4]. A scoreboard you optimize directly stops being a scoreboard and becomes a liability. The board sees the score. The engineers steer by the leading indicators that actually predict it. Those are two different instruments for two different jobs, and the entire mistake most programs make is using one for both.

Closing

Time-based detection metrics are lagging by construction, confounded by variables you do not control, and, when you optimize them directly, an incentive to manufacture exactly the alert volume that is breaking SOCs. None of that makes them worthless. It makes them a scoreboard.

Report dwell time and MTTD to the board next quarter, benchmarked, unchanged. Then close the deck and go run your program on the numbers that move before the incident does: is the log source reporting, did the emulated technique fire, how fast can you ship a fix, and is last quarter’s detection still passing this quarter’s test. Those are the numbers you can act on while acting still matters.

The scoreboard tells you the score. It was never supposed to tell you how to play.

Resources

  1. 2025 Cost of a Data Breach Report. IBM (mean breach lifecycle 241 days: 181 to identify, 60 to contain, lowest in nine years; internally identified breaches averaged USD 4.18M vs USD 5.08M attacker-disclosed; 50% now detected internally).
  2. M-Trends 2025. Mandiant / Google Cloud (global median dwell 11 days; adversary-notified median 5 days vs external-partner-notified 26 days).
  3. Goodhart’s Law. After economist Charles Goodhart (1975); the “when a measure becomes a target, it ceases to be a good measure” phrasing is Marilyn Strathern (1997).
  4. 2025 SANS Detection and Response Survey. SANS Institute (73% name false positives their top challenge; “very frequent” false positives rose from 13% to 20% year over year).
  5. Atomic Red Team. Red Canary (library of 1,800+ atomic tests mapped to MITRE ATT&CK for detection validation).
  6. Detection Engineering Maturity Matrix. Kyle Bailey (community maturity model mapping detection capabilities to levels).