15.1 MTTA, MTTD, MTTR, SLA, and Lookups

A Security Operations Center (SOC) is judged less by how many alerts it opens than by how quickly and correctly it turns evidence into action. TryHackMe's Security Analyst Level 1 (SAL1) training content names four ideas every junior analyst should be able to compute from timestamps: Mean Time to Acknowledge (MTTA), Mean Time to Detect (MTTD), Mean Time to Respond or Resolve (MTTR), and Service Level Agreement (SLA) thresholds. This independent study material covers those metrics and the lookups that keep them honest.

The four clocks, in order

Incidents do not start when a human opens a ticket. They start when evidence first exists. Until the sequence is automatic, write four times on the case:

MTTD is the mean of (T1 − T0) across incidents, not across every raw alert. If ransomware staging began at 09:12 and the EDR alert was created at 09:18, detection time for that case is 6 minutes. Average that interval across a reporting window and you have MTTD. A short MTTD with terrible accuracy is not a win: a noisy rule that alerts instantly on every powershell.exe start inflates detection speed while the real 09:12 event sits in a pile of twins.

When T0 is unknown — common when logs rolled or the host had no EDR — do not invent a detect time of zero. Mark MTTD as not computable for that case, or use the earliest remaining evidence and say so. Silent gaps are a detection-engineering problem, not a reason to report a heroic 30-second MTTD.

MTTA is the mean of (T2 − T1). It answers one question only: how long do alerts sit unowned? If the 09:18 alert is acknowledged at 09:26, acknowledge time is 8 minutes. MTTA is an analyst-queue metric. It does not prove the attacker was stopped, and it should not include hours when the SOC was staffed but the ticket sat in a secondary queue nobody watched.

MTTR is where SOCs argue. Some teams define it as mean time to respond: first effective containment (isolate, disable, block) minus T1. Others define it as mean time to resolve: true closure minus T1. SAL1 training lists MTTR as a key indicator; on the job you must write down which clock your SOC uses. In this chapter, respond means first containment that changes attacker freedom, and resolve means the incident is actually finished (malware removed or credibly blocked, account recovered, detection tuned if needed). Mixing the two in one widget is how leadership thinks a four-hour ransomware event "took 12 minutes."

An SLA is not an average. It is a promise with a threshold, almost always sliced by severity. Example targets used in many SOCs (your org will publish its own; these are teaching numbers):

You can publish a beautiful MTTR mean and still miss the SLA if one P1 sat for three hours while twenty P4s closed in two minutes. Report percent of cases meeting the threshold, not a blended mean of P1 and P4.

Dwell time is related but not identical to MTTD. Dwell is how long an attacker was active; MTTD is how long until the SOC knew. A 14-day dwell with a 6-minute MTTD on the last beacons means you detected a late chapter, not the intrusion.

Worked example: one shift, three cases

Convert times to minutes past 09:00 so the arithmetic stays visible. Then compute both the naive means and the means after a lookup.

Case 1 — finance laptop, later confirmed staging. First evidence 09:12. Alert 09:18. Ack 09:26. EDR isolate 09:41. Ticket closed after cleanup 11:12.

• Detect: 09:18 − 09:12 = 6 min
• Acknowledge: 09:26 − 09:18 = 8 min
• Respond (contain from detect): 09:41 − 09:18 = 23 min
• Resolve (close from detect): 11:12 − 09:18 = 114 min

Case 2 — credential-phishing click, no malware. Gateway log 10:02. Alert 10:05. Ack 10:19. Password reset and session revoke 10:31. Closed 10:40.

• Detect: 3 min
• Acknowledge: 14 min
• Respond: 10:31 − 10:05 = 26 min
• Resolve: 35 min

Case 3 — "port scan" that is the weekly Qualys scanner. SYN flood 10:44 from 10.8.20.14. Alert 10:44. Ack 10:47. Closed as a "true positive, scan blocked" at 10:49. Nobody opened the known-scanner list.

• Detect: 0 min
• Acknowledge: 3 min
• Respond/resolve: 5 min

Naive shift means if you average all three as incidents:

• MTTD = (6 + 3 + 0) / 3 = 3.0 minutes
• MTTA = (8 + 14 + 3) / 3 = 8.3 minutes
• MTTR-respond = (23 + 26 + 5) / 3 = 18.0 minutes

Those numbers look excellent and are a bad picture of risk. Case 3 is authorized scanning, not an incident. After a known-scanner lookup drops it from the incident set:

• MTTD = (6 + 3) / 2 = 4.5 min
• MTTA = (8 + 14) / 2 = 11 min
• MTTR-respond = (23 + 26) / 2 = 24.5 min

Slower on paper, truer in reality. That is the job of lookups. The bar chart below is Case 1 only, so you can see that resolve time (114 min) is a different species from contain time (23 min). If a dashboard published only 23, managers would think the laptop was clean by 09:41.

Lookups: the data that makes metrics usable

A lookup is a reference table the SIEM, SOAR playbook, or ticketing tool joins onto an alert: asset owner, criticality, business service, subnet purpose, VIP user flag, DHCP reservation, known scanner and vulnerability-management ranges, approved backup servers, threat-intel lists, and "this hash is our own red-team beacon." Lookups do not replace investigation. They stop the SOC from using the wrong stopwatch.

Asset criticality

The same encoded PowerShell parent chain is not the same incident on an intern laptop and on a domain controller. A criticality lookup (for example: 1 = crown jewel, 2 = business-critical, 3 = standard, 4 = lab) should raise severity and tighten SLA automatically. Without it, MTTA on "all mediums" hides that the domain-controller alert waited 40 minutes because it wore the same yellow badge as a lab VM. Criticality also tells you which missed SLAs matter: a P3 lab box breaching a four-hour ack target is not the same failure as a P1 file server missing a 15-minute ack.

User VIP

A VIP lookup (C-suite, finance wire approvers, domain admins, publicly targeted executives) changes who you call, not just a dashboard color. A new mailbox-forwarding rule on the CFO is an escalation candidate; the same rule on a shared facilities inbox may be P3. VIP encodes blast radius and fraud path. It should influence priority and communication list, not a verdict of "malicious."

Known-scanner and other allow lists

Vulnerability scanners, EDR health checks, and backup agents generate traffic that looks like attacks and is authorized. A known-scanner list (IP, scanner user, certificate, or source host) should mark those alerts as expected / benign true positives before they consume MTTA. Best practice is to auto-close only with a distinct reason code such as "authorized scanner," never by pretending they were remediated threats. If the scanner subnet is stale, the lookup itself becomes an MTTD problem: a real adversary who parks on a nearby address will be ignored.

Other high-value lookups: DHCP-to-hostname (so you page the right owner), AD group membership (is this a service account?), and "approved software publishers" for noisy IDS. Enrichment that feeds SOAR can auto-set severity; it still must be auditable.

Trap: closing tickets to game MTTR

The cheapest way to make MTTR fall is to stop the clock without stopping the attacker.

Watch for:

• Closing as resolved when the only action was "emailed the user" with no confirmation
• Relabeling unknowns as false positives at end of shift so the queue is empty
• Auto-close after N hours of silence, which converts neglect into a green mean
• Measuring MTTR from the last reopen so a three-day incident becomes a 20-minute ticket
• Averaging P1 and P4 into one MTTR so the mean is the P4 pile
• Treating scanner and red-team noise as resolved true positives to pad volume and speed

If reopen rate, dwell on critical assets, or missed true positives rise while MTTR falls, the metric is being gamed. Pair every speed KPI with a quality KPI: true-positive rate among incidents, percent of P1s that met SLA, and time-to-contain as a separate series from time-to-close.

Practices that actually improve the numbers

Track acknowledge, detect, contain, and close as separate series. Slice by severity and by asset criticality. Exclude authorized-scanner and known-test alerts using lookups, then audit those lists monthly. Start the SLA clock from a documented T1, not from whenever someone remembered to open a ticket. Junior analysts help metrics most by timestamp hygiene (created, claimed, first action, close reason) and by running lookups before they treat an alert as an incident — not by racing to hit Closed.