Tuning a Noisy SIEM Without Blinding the SOC
A 4,500-employee manufacturer runs a six-analyst SOC on a SIEM that generates about 1,950 alerts per day. Seventy-one percent come from authenticated vulnerability scans that trip “suspicious PowerShell” and “credential access” rules; 12% are impossible-travel alerts caused by corporate VPN egress in two regions; 8% come from a deprecated EDR integration. The CISO wants fewer than 300 alerts per day within 30 days. The SOC manager proposes disabling the noisy rules. A recent red-team exercise showed those same rules would detect credential dumping and remote PowerShell. There is no detection-as-code pipeline, no ticket automation, and analysts triage mainly by severity label. One analyst manually whitelists scanner IPs each week. A new plant with 600 endpoints is about to onboard. You must reduce volume without losing the red-team coverage, decide what to measure, and advise on the manager’s proposal.
1. Propose a 30-day tuning plan. Which changes would you make first, and what guardrails prevent loss of detection coverage?
Read the worked answer
Sequence by data quality first, then contextual suppression, then workflow.
- Days 1–3: repair the deprecated EDR integration. Duplicate and stale alerts are an ingestion defect, not a detection-tuning problem; fixing it reduces volume without touching rule logic. Confirm time sync and asset enrichment.
- Days 4–7: split the noisy PowerShell and credential-access rules. Keep a high-fidelity rule for LSASS access and remote PowerShell from non-scanner processes. Add a narrow exclusion for the scanner service account and scanner host IPs only when parent process and command line match the authenticated scan baseline. Do not whitelist scanner IPs globally, because an attacker on that subnet would inherit the blind spot.
- Days 8–14: enrich impossible-travel with VPN egress ASNs and device compliance. Suppress only corporate VPN egress with a compliant device; retain alerting for non-VPN and unmanaged devices.
- Days 15–30: add ticket automation and severity mapping, then onboard the new plant with a baseline and canary detections.
Guardrails include change control, rollback, weekly sampling of suppressed events, and red-team replay before closing tuning. The target is lower false-positive volume with preserved true-positive recall, not simply fewer alerts.
2. The SOC manager says disabling the five noisiest rules is the fastest path to the 300-alert target. Evaluate that proposal and state what you would do instead.
Read the worked answer
Disabling the five noisiest rules is fast but unsafe. The red-team exercise showed those rules detect credential dumping and remote PowerShell, so disabling them removes coverage for high-impact techniques. The volume problem is mostly context: scanner traffic, VPN egress, and a broken EDR feed. Disabling treats legitimate telemetry as the enemy and creates a silent gap that no alert will reveal.
A better decision is to retain detection intent and reduce false positives through rule splitting and context. For each rule, ask: what is the malicious behavior, what is the benign cause, and what field distinguishes them? For scanner noise, the distinguishing fields are service account, parent process, and scan window. For impossible travel, they are VPN egress ASN and device compliance. If a rule cannot be tuned without unacceptable risk, keep it in alert-only mode with a named owner and a 30-day review rather than deleting it.
If the CISO insists on a temporary volume cap, make it a measured exception: document affected rules, monitor suppressed events, run weekly atomic or red-team tests, and set an expiry. Do not let a temporary disable become permanent.
3. What metrics and evidence would you present to the CISO at day 30 to show the tuning reduced noise without reducing detection capability?
Read the worked answer
Present a before/after scorecard tied to detection, not just volume.
- Volume: alerts per day, per rule, and per analyst; target under 300 per day.
- Quality: precision by rule from a sample of closed tickets; false-positive rate; duplicate rate.
- Coverage: red-team replay results for credential dumping and remote PowerShell; atomic-test pass rate; rule-to-technique mapping.
- Speed: median time from alert to triage, and percentage triaged within SLA.
- Suppression safety: number of suppressed events, sample-review findings, and any missed true positives.
- Onboarding impact: alert volume from the 600-endpoint plant and whether baselines were updated.
Use a 30-day comparison with the same detection content and test cases. If volume fell but red-team replay failed, tuning failed. If volume fell and replay passed with sampled suppressed events clean, the CISO has evidence that the SOC reduced noise without blinding itself.