Your SIEM fires 500 'failed login' alerts a day, almost all noise, and analysts now ignore the rule. What's the right move?
Short answer
Cut false positives through detection engineering, not by blinding yourself. Re-tune so alerts fire only on patterns that matter — many accounts hit with one password (spraying), one account hit many times (stuffing/brute force), impossible travel — while keeping the raw failed-login events searchable on a dashboard. Then measure alert precision over time. Disabling the rule removes a real signal, blanket suppression creates a permanent blind spot, and hiring people to triage pure noise doesn't scale and burns them out.
A rule that fires 500 times a day and gets ignored is worse than no rule — it trains analysts to dismiss the very category of event that matters, and the real attack hides in the noise. This question tests whether you reach for detection engineering instead of the two lazy extremes: kill it, or throw bodies at it.
Why tuning is the answer
Failed logins are not inherently interesting; patterns of failed logins are. Re-engineer the detection so it alerts only on signal:
- Password spraying — one password tried across many accounts in a short window.
- Credential stuffing / brute force — many failures against a single account, or a burst from one source IP.
- Impossible travel or a failed login immediately followed by a success from a new geo/ASN.
Crucially, you keep the raw events flowing to a searchable index or dashboard — just not as alerts. That preserves the data for hunting and post-incident scoping while removing the per-event noise. Then you measure precision (true positives / total alerts) so you can prove the tuning worked and keep refining it.
Why the other options fail
- Disable the rule — you delete the signal entirely. Brute force and spraying are common initial-access techniques; going dark on them is a gift to attackers.
- Suppress all and rely on EDR — EDR watches endpoints, not your identity provider or cloud auth surface. Spraying against a VPN or M365 portal may never touch an EDR-monitored host. That's a blind spot, not a strategy.
- Hire more analysts — paying humans to dismiss noise doesn't fix the broken signal-to-noise ratio; it just spreads the fatigue and doesn't scale with volume.
What the interviewer is probing
They want a candidate who treats the SOC as an engineering problem: false positives are a tunable defect, not a fact of life. The strong answer names the attack patterns to detect, preserves raw data for investigation, and commits to measuring precision over time — the difference between an analyst who endures alerts and one who improves the detection.
Likely follow-ups
- What thresholds distinguish password spraying from credential stuffing in your detection logic?
- How would you measure whether your tuning improved precision without dropping a real attack?
- How do you keep the raw data available for hunting without it generating alerts?