Measuring Detection: MTTD and MTTR
A security program that cannot measure itself cannot improve, and the two numbers that matter most are how fast you detect an intrusion and how fast you respond to it — mean time to detect (MTTD) and mean time to respond or recover (MTTR). Every control in this book ultimately serves shrinking those two numbers, because the damage of a breach scales with how long the attacker operates undetected.
This topic covers the metrics that make detection accountable and the traps of measuring security by the wrong numbers — the vanity metrics that reward looking busy.
MTTD and MTTR Defined
MTTD is the time from compromise to detection; MTTR is the time from detection to containment or recovery. Dwell time — compromise to eviction — is the sum, and shrinking it is the core outcome of the whole detection-and-response program. When you read that an industry-average breach dwelled for weeks or months, that is the number the entire book is trying to cut to hours.
Why These Numbers Drive Everything
Attacker damage compounds with time: recon, then spread, then exfiltration, then ransomware. Cutting dwell from months to hours changes a catastrophe into an incident, which reframes detection investment as dwell-time reduction. Every detection, every bit of logging, every hunt is justified by how much it shrinks the window the attacker has to operate.
Leading vs Lagging Metrics
MTTD and MTTR are lagging — measured after incidents happen. Leading indicators predict them and are what you actually tune day to day: detection coverage against ATT&CK, alert fidelity, time-to-triage, patch SLAs. You cannot manage MTTD directly between incidents, but you can manage the coverage and fidelity that determine it.
Metric Traps
Vanity metrics — alert counts, "attacks blocked," logs ingested — measure activity, not effectiveness, and optimizing them can make the real numbers worse (closing alerts fast regardless of quality degrades detection). Measure outcomes and resist gaming: Meridian's scorecard leads with MTTD, MTTR, and dwell time, uses detection coverage and alert fidelity as leading indicators, and validates with exercises rather than trusting any metric that rewards looking busy.
Vanity (alerts generated, attacks blocked, logs ingested) — easy to grow, feel productive, but measure activity not security, and are gameable.
Outcome (MTTD, MTTR, dwell time, detection coverage) — harder to move, but they reflect whether attackers are actually caught fast. Report outcomes; use leading indicators to improve them; distrust any metric that rewards looking busy.
- Measuring the SOC by alert volume or "attacks blocked," which rewards noise and edge-blocking over actually catching intrusions.
- Tracking only lagging metrics (MTTD, MTTR) with no leading indicators, so there is nothing to tune between incidents.
- Gaming metrics — closing alerts fast to improve triage time — which degrades real detection quality.
- Not measuring at all, so the program cannot show improvement or justify investment.
- Treating a low alert count as good when it may mean poor coverage, not a quiet network.
- Make dwell time (MTTD plus MTTR) the headline outcome metric, since attacker damage scales with time undetected.
- Track leading indicators — detection coverage against ATT&CK, alert fidelity, time-to-triage, patch SLAs — to drive daily improvement.
- Guard against vanity and gameable metrics; measure outcomes and validate with exercises and purple-team tests.
- Report the trend and tie each control investment to its effect on detection and response time.
- Use purple-team exercises to test that detections actually fire and to measure real MTTD.
Knowledge Check
Why is dwell time the headline metric for a detection-and-response program?
- Damage compounds, so shrinking the undetected window strictly limits harm
- It is by far the easiest metric to grow quickly
- It simply counts how many total alerts the SOC generates each day
- It measures how much raw log data is stored
Why track leading indicators as well as MTTD and MTTR?
- They lag; coverage and fidelity are tunable between incidents
- Leading indicators entirely replace the need to measure MTTD
- Lagging metrics like MTTD can be tuned directly and in real time
- Leading indicators are the same as vanity metrics
Why can optimizing a vanity metric make real security worse?
- Chasing fast closure pushes analysts to close real alerts unread
- Vanity metrics are inherently impossible to measure or report at all
- Optimizing raw alert counts always reduces dwell time
- Vanity metrics automatically improve MTTD over time
You got correct