A Fast Containment Time Is Not a Good Response

“Our MTTD and MTTC both fell after we moved to managed detection, so our response has improved.”

Let me stop you before that goes on the quarterly slide.

A fast containment time is not a good response.

You changed who watches.

You changed where the alerts come from.

You may have changed which event gets logged as “detected.”

You may have changed which event gets logged as “contained.”

The case-management system dutifully subtracted one timestamp from the other.

It did not check that the timestamps still mean what they meant last year.

The usual layer collapse.

Incident-response measurement runs on two clocks whose start and stop events each organization defines for itself.

Security-tool categories describe data sources and delivery models, not response capability.

Put a category change underneath a clock and the clock will move.

That is not the same as the response getting better.

It is like changing the finish line and congratulating the runner on a personal best.

1. “But the Numbers Come Straight From the Case-Management System.”

They do.

That is why everyone cites them.

It is not why they are right.

Mean time to detect (MTTD, sometimes mean time to identify) is the interval from actual compromise to confirmed detection.

Mean time to contain (MTTC, sometimes mean time to respond) is the interval from detection to confirmed containment.

Both are easy to compute.

Both depend on a word that is doing a great deal of unsupervised work: confirmed.

Detection is not one event.

A SIEM alert is a detection.

A human triage confirmation is a detection.

A formally declared incident is a detection.

Any one of them can be the timestamp in the “detected” field.

Which one you count changes the number by days or weeks without changing anything about the actual response.

Ireland’s Health Service Executive shows how wide the gap can be.

The independent PwC review of its 2021 Conti ransomware incident traced the intrusion to a phishing email on 16 March 2021.

Antivirus flagged suspicious activity on 31 March.

If a tool flag counts as detection, that clock stopped 15 days in (31 minus 16).

If a declared incident counts, it kept running until the ransomware activated, about eight weeks after the phishing email.

Same intrusion.

Same organization.

Two MTTDs, depending on a definition.

And a system of record records what it is told to record.

It has no opinion about whether the definition moved when the provider did.

2. “But the Managed Provider Watches Around the Clock.”

Good.

That is coverage a small team often cannot staff.

It is a delivery model, not a response.

The category names are more precise than the marketing that uses them.

EDR is defined by its data source: the endpoint.

XDR is defined by breadth of data source: the endpoint plus network, email and cloud telemetry, in a mix that varies by vendor.

MDR is defined by who runs it.

It wraps EDR or XDR technology in round-the-clock human monitoring, threat hunting and incident response delivered by the vendor’s own staff.

It is not a rival detection technology.

It is a staffing decision layered on top of one.

And the technology underneath is less fixed than the acronym suggests.

Nir Zuk, then at Palo Alto Networks, coined “XDR” in 2018 as product-positioning language, before any analyst firm formalized a definition.

SIEM went the other way: Gartner analysts Mark Nicolett and Amrit Williams named the category in 2005, and vendors built toward it.

So “XDR” covers whatever mix of sources a given vendor integrates.

Rapid7 markets InsightIDR as combining SIEM with XDR, UEBA, EDR and NDR capabilities in one interface.

That is a claim about breadth of ingested telemetry.

It is not a claim about how far anyone will chase an intrusion once the telemetry lights up.

So when your clocks fall after the move, ask the boring questions.

Whose alert is now the start of the detection clock?

Is it the raw telemetry, the provider’s triage, or the provider’s escalation email to you?

Whose action is now the stop of the containment clock?

Is it the provider’s host isolation, or your team’s confirmation that the intrusion is out?

If those answers changed, the number changed with them.

Category labels are not a stable reference point either.

No standards body assigns tools to categories.

The taxonomy comes from analyst-firm research, principally Gartner, and Gartner redraws it.

Skyhigh Networks launched in 2011 as a cloud access security broker.

McAfee acquired it in January 2018 and sold it as MVISION Cloud, a component of a broader suite.

It re-emerged in March 2022 as Skyhigh Security, marketed under Gartner’s 2021 Security Service Edge category.

One continuous technology lineage.

Three category identities.

If a label can move without the software changing, it can certainly move without your response changing.

3. “But SOAR Contains Incidents Automatically.”

It executes containment automatically.

That is not the same sentence.

SOAR detects nothing.

It ingests alerts that a SIEM, EDR or other tool already generated.

It runs a playbook, a documented incident-response procedure, through a runbook, the automated execution of that playbook’s steps.

It cuts the manual work of triage and containment.

Which means it makes MTTC faster for exactly the incidents it was handed, bounded by exactly the steps the playbook names.

Isolate the host that alerted.

Disable the account that alerted.

Close the ticket.

A beautiful number.

The playbook does not know whether the intrusion reached anything that did not alert.

Neither does the clock.

MTTC measures how fast a team stopped the incident it found, not how fast it should have found it.

A fast MTTC on a very late detection is not evidence of a good response.

It can equally be evidence that the intrusion finally became so obvious that containment was trivial.

Automating the trivial part at machine speed is useful.

It is not a scope decision.

4. “But Our Last Tabletop Exercise Found No Major Issues.”

Then you have a list of gaps with nothing on it.

That is a finding about the exercise as much as about the plan.

The US Cybersecurity and Infrastructure Security Agency (CISA) maintains more than 100 Cybersecurity Tabletop Exercise Packages.

Ransomware, insider threats, phishing, sector-specific scenarios.

Each comes with template objectives, discussion questions, planning materials and an after-action report format.

None of them is a scoring rubric.

They are discussion-based exercises.

They do not output a maturity level or a pass-fail result.

The output is qualitative by design: an escalation contact that is out of date, a playbook that assumes access to a system that would itself be down, a notification step nobody could execute inside the deadline.

If you want a trend line, you build it yourself.

Count the gaps each exercise surfaces, and how many from the last one remain open.

That is a homemade proxy.

Useful, and not a standard.

A tabletop also tests the plan only as well as the scenario was designed.

A scenario where the attacker has one foothold will never discover that you assume attackers have one foothold.

The strongest signal is the post-incident review, judged by what it changes.

The PwC review of the HSE incident is what a complete one looks like.

It reconstructed the timeline back to the phishing email.

It named the specific control gap: antivirus that flagged activity on 31 March, configured in monitor mode rather than blocking.

It mapped recommendations to findings: 24-hour monitoring, multi-factor authentication, new Chief Technology Officer and Chief Information Security Officer roles.

Not “improve monitoring.”

Not “increase training.”

A tool that saw the thing and was configured not to stop it.

That gap is not exotic.

Most of the tool population observes rather than blocks.

EDR functions primarily as an alerting tool rather than a protection layer.

SIEM correlates logs other things already wrote.

Of the usual seven categories, the web application firewall is the one that sits in-line in the request path and can refuse a request before the application processes it.

Everything else produces a signal that somebody, or some playbook, has to act on.

A signal that nobody acts on still stops the detection clock, if you let it.

5. “But We Isolated Every Host That Alerted.”

Then you contained every host that alerted.

You contained the alert, not necessarily the intrusion.

Incomplete containment does not look like a skipped step.

The team detects, contains, eradicates, recovers and reviews.

Every box is ticked.

The attacker is still there, because the confirmed systems were never the only foothold.

SolarWinds’ Orion compromise is the large-scale version.

The US CISA’s Emergency Directive 21-01, issued 13 December 2020, told federal agencies to disable the compromised Orion software and rebuild affected devices from trusted sources.

That addressed the confirmed foothold.

Investigators then found the attackers had used the initial access to obtain additional footholds through credential theft and authentication-token manipulation.

Disabling Orion alone was no longer sufficient to sever their access.

Remediation had to extend to full credential resets across environments.

Now shrink that to your size.

One host shows indicators.

It is isolated in minutes.

Nobody checks whether the same credential or the same access path was used anywhere else.

The MTTC for that incident is excellent.

It is excellent because the boundary was drawn around the alert.

A team optimizing the clock can hit its target by drawing containment narrower than the intrusion reached, or by declaring incidents later.

Neither clock, on its own, would show that anything went wrong.

The next incident will.

6. “But the Board Wants a Single Number.”

Give it one.

Then make the number honest.

Both clocks are population averages dominated by the slowest cases.

A single long-dwelling, quietly persistent intrusion can pull an annual average up by months even if every other incident that year was handled in hours.

The average alone cannot tell the board which situation it is looking at.

So report the median beside it.

Report the slowest cases by name.

For scale, IBM’s Cost of a Data Breach research found that in 2024 breaches took an average of 194 days to identify and a further 64 days to contain.

That is 258 days (194 plus 64), more than eight months, from initial compromise to containment.

It is a dated industry average.

It is not a benchmark to beat, because every organization inside it defined “identified” and “contained” for itself.

The clocks are useful as trend indicators inside one organization tracking itself over time.

They are much less useful across organizations.

They are least useful across a tool or provider change, unless the definitions were written down and held fixed.

7. No, This Does Not Mean MTTD and MTTC Are Useless.

They are not.

Tracked consistently inside one organization, the clocks show real trends.

A managed service can add coverage a small team lacks.

Round-the-clock monitoring was one of the HSE review’s own recommendations.

An automated playbook can remove manual work from every alert.

The claim is narrower.

A better number is not evidence of a better response unless the definitions and the containment boundary were held fixed and checked.

Each of the three measurement types has a blind spot.

The clocks tell you how incidents are trending, not why.

A tabletop tests a plan against a scenario nobody has lived through.

A post-incident review is grounded in what actually happened, and only fires after something has.

Judging maturity from one of them alone is measuring with an instrument whose blind spot is already known.

8. What You Should Actually Do

Write down which event starts and stops each clock. Compromise, first tool alert, triage confirmation, declared incident, provider isolation, confirmed containment.

Pick one for each boundary.

Keep the definitions stable across any tool or provider change.

If a change forces a new definition, restart the series rather than splicing it.

Report medians and the slowest cases alongside averages. Name the long-dwelling incidents rather than letting them hide inside a mean.

Before closing an incident, check where else the same credentials and access paths were used. The boundary is the intrusion’s reach, not the set of hosts that alerted.

Record for every detection tool whether it runs in blocking or monitor-only mode. A tool that flags and does not stop is a detective control with a response dependency.

Know which of yours are.

Judge each post-incident review by whether it names a specific control gap and maps each recommendation to a finding.

Boilerplate recommendations are a sign the review did not find anything, not a sign there was nothing to find.

Under a managed service, state contractually who investigates and who contains. Which actions the provider takes on its own authority.

Which it only recommends.

What it reports as detection.

What it reports as containment.

9. The Model Is Not Complicated.

A clock measures the interval between two events you chose to count.

A category label describes a data source or a staffing model.

A containment boundary is a decision about how far the intrusion reached.

Only the last of those is the response.

Change the provider if it gives you coverage you lacked.

Automate the playbook if it saves real work.

Keep the clocks.

Breach-duration averages, exercise-package counts and category names are dated evidence.

The definitions behind your own numbers are not dated at all.

They are just unwritten.

Write them down, hold them still, and then the number that falls will mean something.