Cutting Alert Volume 80% While the Red Team Walks Through
Tessera Bank's SOC has 14 analysts, 24x5 coverage, and 38,000 EPS into Splunk. A single rule, 'Suspicious PowerShell,' generates 71% of all alerts, and 96% of those close as benign administrative activity. Median time to triage is 6.2 hours. Last month's red-team exercise was detected once - by a helpdesk ticket from the victim, on day 9. EDR covers 82% of servers and 61% of workstations; the gap is concentrated in OT and a recently acquired subsidiary still on a separate tenant. Leadership's stated KPI is 'alerts closed per analyst per day.' The new SOC manager wants to cut alert volume 80% within a quarter to free up capacity.
1. Critique the KPI and the 80% goal. What would you measure instead, and how would you keep the new measures honest?
Read the worked answer
The KPI is an incentive to close, not to detect. 'Alerts closed per analyst per day' is maximized by bulk-closing and by suppressing anything noisy. Given that 96% of the dominant rule is benign, analysts have been trained by the queue to close fast - the KPI rewards exactly the behaviour that produced a 9-day dwell time.
The 80% goal is achievable and probably desirable, but as written it is a volume target disconnected from detection. You can hit it by deleting the PowerShell rule. You cannot tell from the goal whether you would lose signal.
Measure instead:
- Coverage: techniques detectable per platform, percentage of critical log sources onboarded, EDR coverage by asset class. Coverage is the precondition for everything else.
- Efficacy: detection rate and time-to-detect against a fixed, repeatable purple-team test set; escalation ratio per rule.
- Quality: reopen rate, sampled audit of closures, percentage of alerts with an asset and identity enriched at creation.
- Capacity: analyst hours per validated true positive - this tells you whether tuning worked without rewarding silence.
Keep it honest: freeze the purple-team test set now and re-run it unchanged before and after tuning. A volume reduction that keeps the test-set detection rate flat is real; one that drops it is a suppression programme with a good slide deck.
2. Take the 'Suspicious PowerShell' rule. Rewrite, suppress, or retire it? Show the decision process, and name the risk you are accepting.
Read the worked answer
Rewrite - it is not one detection, it is an undifferentiated bucket. Decompose by context rather than by command name:
- Encoded or obfuscated command lines, and download cradles.
- PowerShell spawned by an Office process, a browser, or a web server worker.
- Execution on servers outside a change window, or by service accounts that have never run it before.
- Unsigned scripts executing from temp or user-writable paths.
- PowerShell touching LSASS, credential stores, or the registry run keys.
The 96% benign rate almost certainly lives in one or two of those buckets - interactive admin sessions on known admin jump hosts. Suppress there, where you have a higher-fidelity compensating control (EDR script-block logging, AMSI telemetry, or a privileged access workstation boundary).
Process: backtest each candidate sub-rule and each suppression against 90 days of data, then run the red team's known technique against the new rule set. If the technique that succeeded on day 9 used PowerShell, and it almost certainly used something in the same neighbourhood, the test tells you whether you kept the signal.
Risk being accepted: suppressing the interactive-admin bucket means a compromised admin account running PowerShell on a jump host becomes quieter. Mitigate by keeping a low-rate sampled alert and routing it to threat hunting rather than the triage queue, and by alerting on the identity anomaly rather than the process. Do not retire the base signal entirely - downgrade it, with an owner and a review date.
3. Leadership asks whether to spend the next quarter on tuning or on closing the EDR gaps. Make the argument, including the OT and subsidiary complications.
Read the worked answer
Coverage first, with a specific exception. Tuning improves the precision of what you can see. The red team won where you could not see: 18% of servers and 39% of workstations had no host telemetry, which is very likely where the initial foothold and the nine days of hands-on-keyboard happened. Detection engineering against data you do not collect is theatre.
Quantify it: moving workstation coverage from 61% to 95% would have put host telemetry on the initial compromise. No amount of PowerShell tuning changes that.
Complications, handled differently:
- The acquired subsidiary on a separate tenant is a pure gap with no technical excuse. Either federate and onboard, or accept in writing that incidents there will be found late. It should also be checked for whether Tessera's data now flows into that tenant.
- OT is a different control set, not a failure. Agent deployment may be genuinely unsafe on operational technology. The right answer is passive network monitoring and segmentation around OT, with detection designed for the protocols in use - not a forced agent rollout.
Sequence: close the subsidiary gap and cover the identity, CI/build, and backup infrastructure first - those are the assets an attacker needs to convert access into impact. Run PowerShell decomposition in parallel as a small, time-boxed effort, because it is cheap and the queue burden is real. Report both as coverage and dwell-time outcomes, not alert counts.