Sixty Brute-Force Alerts a Day: Tuning SEC-114 Without Creating a Blind Spot
The SIEM ingests roughly 4.2 billion events per month and the detection engineering team owns 380 rules. Rule SEC-114, "Brute Force - Multiple Failed Logons," fires about 60 times per day. Its logic: five failed authentications from one source IP to one destination within 60 seconds. Triage shows 52 of the daily alerts originate from 10.20.4.0/24, an internal vulnerability-scanning subnet, using the service account svc_scan; those scans are authorized and run nightly between 01:00 and 04:00. The remaining eight alerts come from a single workstation, 10.60.11.87, which at 03:12 attempts one logon each against 12 different servers in under 90 seconds, always failing with "bad password" for accounts following a firstname.lastname pattern. The analyst on shift wants to disable SEC-114 and add the scanner subnet to a global whitelist so the queue clears before the morning handover.
1. Classify both alert clusters and explain the reasoning behind each classification.
Read the worked answer
The 52 scanner alerts are false positives in the detection sense but true events: the failed logons genuinely occurred. They are benign because the source subnet, the service account, and the time window all match an authorized, documented nightly scan - the reasoning rests on authorization plus context, not on the rule's logic. The eight alerts from 10.60.11.87 are the real finding. A five-failures-to-one-host rule never triggers because the actor spreads attempts, one failure per destination across 12 servers in 90 seconds. That pattern is password spraying, and the uniform "bad password" response for firstname.lastname accounts confirms usernames are being enumerated as valid. It is a high-severity true positive because a single success yields a foothold on a server. Disabling SEC-114 would therefore suppress the only signal that caught the actual attack.
2. Redesign the detection strategy so the analyst's queue clears without losing coverage.
Read the worked answer
Split the rule. Keep SEC-114 but add a scoped suppression that requires all three conditions - source in 10.20.4.0/24, user equal to svc_scan, and the 01:00-04:00 window - on an exception list with a named owner and a 90-day expiry, reviewed rather than permanently whitelisted. Build a second rule keyed on breadth: more than eight distinct destination hosts with failed logons from one source within ten minutes, excluding known scanners, severity high. Add a third correlation: any successful logon from that same source within 30 minutes escalates to critical and auto-opens a ticket, because spray that succeeds is the actual breach. Add a low-and-slow variant using a 24-hour window and a threshold of 20 distinct destinations, since an attacker who learns the ten-minute rule will simply slow down. Every suppression needs an expiry date and a compensating detection on successful authentications from the suppressed source, so the blind spot stays covered.
3. Which additional data sources or enrichments would most improve fidelity, and why those?
Read the worked answer
Add domain controller security logs (4625, 4624, and 4771 Kerberos pre-authentication failures) so authentication failures that never touch the endpoint become visible; the current rule may only be reading Windows agent telemetry from member servers. Add asset inventory so that destination breadth can be weighted by criticality - spraying 12 domain controllers is not the same as spraying 12 kiosks. Add DHCP and NAC logs to map IP to MAC to switch port, converting an IP-based alert into a device and a physical location, which also enables port-level containment. Add a behavioral baseline for first-seen source-destination pairs and out-of-hours logons. Add ticketing and change-management data so authorized scans are consumed as context automatically instead of relying on analyst memory - that memory gap is the root cause of the 52 daily false positives.