SIEM dashboards show repeated failed logons and impossible-travel alerts for municipal SSO, but the identity team never tunes or responds to them. What practice is missing?
Select an answer to reveal the explanation.
Short Explanation
Alarms that nobody answers might as well be wallpaper. Watch failed logons and impossible travel, tune them, and chase the weird stuff—that is authentication monitoring, not just collecting pretty charts.
Full Explanation
Authentication anomaly monitoring is an active detection and response practice: triage repeated failed logons, impossible-travel alerts, credential stuffing patterns, and similar SIEM signals with playbooks that contain account takeover. Municipal SSO dashboards that never get tuned or answered waste visibility and allow attackers to iterate against city identities unchallenged. The missing practice is operational monitoring and response, not merely log collection.
Disabling SSO so failed logons cannot occur removes the city’s primary authentication plane and creates worse outage and shadow-IT risk. Lowering password complexity to reduce lockouts weakens authenticators in response to attack noise—an inverted control decision. Deleting audit logs after 24 hours to save storage destroys forensic and compliance evidence precisely when investigation of those anomalies would need history.
Exam caveat: Domain 6/7 style distractors often disable the service or the logs; the professional answer preserves telemetry and acts on it. Operational check: define severity and escalation for impossible travel and brute-force bursts, tune baselines for VPN egress and traveling officials, measure mean time to respond, and periodically tabletop an SSO takeover scenario with identity and SOC staff.