MSSP Queue Collapse During a Ransomware Precursor
Sentinel Ridge is a 45-client MSSP with six analysts covering 24x7 in three shifts. The queue receives about 1,200 alerts per day, of which 38% are closed as false positives, and the median time to acknowledge is 47 minutes. EDR and NGFW integrations create duplicate tickets for the same endpoint, while a new detections pack has produced 90 low-fidelity 'suspicious PowerShell' alerts per day. On Friday at 21:10, one client's file server shows a ransomware canary file and 14 encrypt operations in 3 minutes; the same host also has an EDR alert that is still unassigned. The account manager wants immediate client notification, but the shift lead wants to confirm before calling. The MSSP contract requires initial notification within 60 minutes for confirmed incidents. The client has no after-hours contact list beyond a shared inbox.
1. How should the shift lead sequence triage and notification for the 21:10 event, and what evidence changes the decision?
Read the worked answer
Reasoning: a canary file plus 14 encrypt operations is a high-fidelity ransomware precursor, not a low-fidelity PowerShell alert. Waiting for perfect confirmation risks missing the 60-minute notification requirement and losing backup or file-server data. The unassigned EDR alert may be a duplicate, but it does not reduce the file-server evidence.
Decision: treat it as a likely true positive. Immediately assign the EDR alert to the on-call analyst, isolate the file server from the network if the client authorizes emergency containment, preserve logs, and identify the process and user. Call the client's shared inbox and escalate through the account manager and any known on-call number; send written notification within the contractual window. Reclassify only if the canary is a scheduled test with a known test process, no encryption occurred, and the file path and hash match the test baseline. Document the decision and the evidence used.
2. Which SOAR automations are safe for the 1,200-alert queue, and which should remain human?
Read the worked answer
Reasoning: automation should remove repetitive work and enrich decisions, not take destructive action on ambiguous evidence. The queue problem is duplication and low context, not a lack of automatic containment.
Safe automations: deduplicate EDR and NGFW tickets by host and time window; enrich with asset owner, criticality, user, and threat intelligence; auto-close only allowlisted, previously adjudicated benign patterns with an audit trail; route alerts by client and severity; create incident channels and page on-call for high-fidelity detections. Keep human: ransomware containment, identity or cloud-admin actions, disabling accounts, isolating domain controllers or clinical systems, client notification, and any action that could cause an outage. For low-fidelity PowerShell, auto-enrich and batch-review rather than auto-close, because the detection pack may be noisy but a real encoded command could hide there.
3. What metrics should the MSSP report to prove improvement beyond alert volume?
Read the worked answer
Reasoning: lower alert volume can simply mean missed telemetry. The MSSP should measure speed, quality, and blast-radius reduction.
Report median and 90th-percentile time to acknowledge and contain by severity; duplicate-ticket rate; true-positive rate by detection source; percentage of high-severity alerts auto-enriched within 5 minutes; number of SLA breaches, especially the 60-minute notification; containment actions taken before client impact; and reopened incidents. Add client-specific metrics such as canary detections tested and backup isolation verified. Review a sample of auto-closed tickets monthly to catch bad suppressions. Tie the metrics to the contract, but do not use mean time to resolve alone because a fast close can hide an unresolved intrusion.