The Alert Flood
A 300-endpoint company deploys an endpoint detection tool. Within a week the SOC receives about 4,000 alerts per day. Two analysts triage them manually. Most alerts are from a legitimate administrative script that the IT team runs hourly. A handful of alerts each day involve credential access behaviour on finance workstations, but they are buried. The SOC manager proposes buying more analysts. The IT director proposes turning off the script-related rule. Last month a real intrusion went unnoticed for nine days because the analyst was saturated. The company has no formal severity taxonomy and no documented triage procedure.
1. Diagnose the root cause and propose the first three changes.
Read the worked answer
The root cause is not analyst capacity; it is an uncontrolled detection pipeline with no tuning, no severity model, and no process. Buying analysts scales the noise. Turning off the rule blinds the SOC to script abuse, which is a common attacker technique. The first change is to tune the administrative script detection: allowlist the known script by hash and parent process, but keep a detection for the same script run from unusual parents or on unusual hosts. The second is to build a severity taxonomy tied to asset criticality and behaviour, so credential access on finance hosts outranks routine script noise. The third is a documented triage procedure with defined escalation, ownership, and response times per severity. These three reduce volume and ensure the finance alerts surface before any headcount decision.
2. How do you handle the IT director's request to disable the rule?
Read the worked answer
I treat it as a legitimate problem with a wrong solution. The script is authorised, so the detection should be scoped, not deleted. I would explain that disabling the rule removes visibility into script-based lateral movement and credential theft, which is exactly the behaviour that matters. The compromise is a tuned rule with an exception for the known script hash and approved execution context, plus a lower-severity informational alert for the authorised runs so the pattern is still visible. I would document the exception with an owner and a review date, and require re-approval if the script changes. This preserves detection while removing the flood, and it gives the IT director the outcome they want without the blind spot.
3. Define metrics that would have caught last month's nine-day dwell time.
Read the worked answer
Dwell time alone is a lagging indicator. I would track median and 90th-percentile time from alert generation to first analyst action, stratified by severity, and the count of high-severity alerts that breached their response target. I would track the ratio of alerts closed as benign without investigation, because that is where buried true positives hide. I would also track detection coverage against known techniques and the number of untuned rules generating above a threshold volume. For the finance credential-access scenario specifically, I would define a metric for high-severity alerts on critical assets that remained unacknowledged beyond target. These metrics expose saturation before it becomes a nine-day dwell time.