MTTD vs MTTR vs MTTC

Key: A

1. ACorrect: Mean time to detect is the average time between an incident starting and the team discovering it, so it directly measures detection speed.
2. BHeadcount is a resource measure and says nothing about how fast incidents are found.
3. COwning more tools does not mean incidents are detected faster.
4. DIncidents per month measures volume, not how quickly each one is detected.

Key: B

1. AMTTD does not measure analyst workload, and the manager's error is about containment speed anyway.
2. BCorrect: MTTD measures only how quickly threats are spotted; containment and eradication speed are tracked separately by mean time to contain and mean time to respond or remediate.
3. CFaster detection does not affect the false-positive rate, but that is not the manager's claim either.
4. DTotal alert volume is useful context, but the real flaw is treating a detection metric as a response metric.

Key: B

1. AAutomatic process termination changes the response itself; it does not fix the inconsistent definitions that distort the metric.
2. BCorrect: The metric is inconsistent because shifts define 'contained' differently, so the manager should set and publish one standard definition for containment and remediation timestamps.
3. CUsing only day-shift data hides part of the operation and does not fix the definition problem.
4. DWaiting for full recovery merges containment with recovery, which makes the containment metric meaningless.

Key: C

1. AAlerts already arrive about 10.5 minutes after compromise on average, so faster detection rules would gain little.
2. BBetter detection signatures also address detection, which is not the bottleneck.
3. CCorrect: Triage is done within minutes, but resolution takes about 3.7 to 5.7 hours (about 4.5 hours on average), so automating containment and eradication targets the real bottleneck.
4. DAnalysts acknowledge and triage alerts within about 5 to 8 minutes, so acknowledgment speed is not the problem.

Key: B

1. A72 hours 45 minutes adds MTTC to MTTR but forgets the 12 minutes of MTTD at the start.
2. BCorrect: under these definitions the phases run back to back, so the total is 12 minutes + 45 minutes + 72 hours = 72 hours 57 minutes.
3. C71 hours 03 minutes subtracts the 57 minutes instead of adding them.
4. D73 hours 09 minutes adds too much; the phases sum to 57 minutes plus 72 hours.

Key: D

1. A100 minutes does not match the data; the three durations add up to 285 minutes, which averages 95.
2. B115 minutes would require a larger total than the 285 minutes in the table.
3. C135 minutes is only INC-82's duration, the longest single incident, so it cannot be the average.
4. DCorrect: The durations are 70, 135, and 80 minutes, for a total of 285; divided by 3 incidents, that is 95 minutes.

Key: B

1. ATotal alert volume and open ticket counts measure workload and say nothing about how long the slowest incidents take.
2. BCorrect: The median and 90th percentile, plus distribution charts, show the long-tail incidents that an average hides.
3. CThe percentage closed on time is useful, but it does not show how far the outliers stretch.
4. DMonthly averages alone are the problem described, because averages hide long-tail incidents.