In SOC outcome reporting, what events start and stop the MTTD and MTTC clocks?

## What each number measures A security operations function usually publishes three related spans, and the interview value is entirely in knowing where each one starts and stops. - **Dwell time** — the span from the adversary's first malicious action inside your estate to the point you knew you were compromised. It is measured on a *single* intrusion. - **MTTD (mean time to detect)** — the same span aggregated over a set of intrusions. Dwell and MTTD are not different measurements; MTTD is dwell with a statistic on top. - **MTTC (mean time to contain)** — from the detection boundary to the moment containment was executed. ## Choosing the detection start event There are three candidate dates, and only one of them is honest. The **first malicious action** is the start: the metric exists to say how long an intruder operated in your estate before you knew. The **earliest surviving log record** is not the start — retention policy decides what you can still see, not when the adversary began, and anchoring there quietly reports your log-rotation schedule as the intrusion's lifetime. The **first alert** is the most tempting and the most wrong: anchor there and every intrusion, however old, was detected in minutes, because you have redefined the metric as your own triage speed. ## Choosing the boundary between the two clocks MTTD's stop event and MTTC's start event must be the *same written-down event*. Two common choices are defensible: - the timestamp of the alert that was ultimately confirmed as the intrusion, or - the timestamp of the analyst's confirmed verdict on that alert. Pick one and apply it to every case. The choice decides which number absorbs queue latency: anchor on the verdict and the hours an alert sat unworked are inside MTTD; anchor on the alert and they are inside MTTC. Neither is free, and a SOC that defines the two clocks independently will either lose that time entirely or bill it twice. ## Choosing the containment stop event Containment stops when an action has *taken effect*, and the action differs by surface: a host isolated at the endpoint agent, a session plus refresh tokens revoked at the identity provider, a cloud access key disabled at the control plane, a service account's credential rotated, an egress block applied at the proxy. What does not count: a recommendation sent, a change ticket raised, an approval obtained, a maintenance window booked. Under a co-managed arrangement this is where the number quietly changes meaning — a provider whose contract stops its MTTC clock at 'containment recommended to the customer' is measuring advice latency, and the gap between the recommendation and the customer executing it belongs to you and is unmeasured unless you measure it yourself. ## Containment is not eradication Containment removes the adversary's *current* access. Eradication removes the *paths back* — a scheduled task, an added SSH key, a rogue OAuth grant, a malicious build still pinned in a deployment manifest. They are separate phases and separate clocks. This also produces a classic false stop event: resetting a password does not revoke an already-issued refresh token, a Kerberos ticket or an OAuth grant, so 'password reset at 14:02' is only a containment stop if you can show the derived credentials died with it. ## Why the definitions are the entire metric Because every one of these boundaries is a *choice*, two SOCs reporting 'MTTD: 9 days' may be measuring different things, and one SOC can improve its own number 40% quarter over quarter without detecting anything sooner. That is why the useful artefact is not the number but the per-case record behind it: the start date **and the source that anchored it**, the detection event and its source, the containment action with its timestamp and who performed it, and a flag for whether each date is directly evidenced or estimated. An interviewer asking this question is checking whether you know the metric is a definition before it is a measurement.