Password-Spray Alarm Storm
Your SOC has an Alarm Rule that fires when a single account has five failed logons in ten minutes. During a password-spray attempt, 1,200 failed logons hit 20 accounts from 300 source IPs in eight minutes. The rule generated 400 alarms because it re-fires as each new failure arrives after the threshold. Analysts closed the alarms in bulk, and the attempted compromise of one account was missed. The SOC lead wants no more than 20 alarms per hour for this behavior, but still wants to catch both classic brute force against one account and low-and-slow spraying across many accounts. You have LogRhythm Alarm Rules, AI Engine rules, Lists, and Watchlists available. The environment has no EDR integration, so containment is manual. The service desk uses the same source IP range as the VPN. You need a design that keeps forensic detail and does not suppress a subsequent successful logon after failures.
1. Would you tune the existing Alarm Rule, add an AI Engine rule, or both? Explain using event cardinality, grouping, and the required alarm ceiling.
Read the worked answer
I would do both, because the two rules answer different questions. The existing Alarm Rule is useful for a single account under repeated attack, but it is firing on every subsequent failure after the threshold. I would first add a duplicate-suppression or consolidation window so one account produces one alarm per window, not hundreds. That alone does not solve spray, because a per-event rule cannot aggregate 300 source IPs and 20 destination accounts. I would add an AI Engine rule that groups by destination account over ten minutes and counts distinct source IPs, with a threshold that catches distributed spray, plus a second grouping by source IP that counts distinct destination accounts. With 1,200 events, the grouped outputs are on the order of tens, not hundreds, which respects the 20-per-hour ceiling. I would use Lists to exclude known scanner ranges only after validation, and keep the raw failed-logon records searchable for drill-down. The alarm should carry the grouping key so an analyst can pivot to all related events.
2. How would you preserve detection of a successful logon after the spray without creating another storm?
Read the worked answer
I would add a separate high-severity AI Engine sequence rule: multiple failed logons from the same source IP followed by a successful logon to any account within 15 minutes. Grouping by source IP keeps the output to one alarm per source, not one per failure. I would also add a variant for a successful logon to a privileged account after failures, using a Watchlist, because that is worth alerting even at lower failure counts. These rules must not be suppressed by the failed-logon alarm consolidation, so I would keep them in a separate rule and route them to case creation. I would validate against historical authentication logs to ensure the sequence window catches the known missed compromise without flooding on service-account behavior. The analyst view should show the failed count, distinct accounts, first and last failure, and the successful logon time so triage does not require a separate search.