City VPN concentrators suddenly show bursts of failed logons across many accounts. Which monitoring activities best help the SOC notice and act on that pattern?
Select an answer to reveal the explanation.
Short Explanation
When failed VPN attempts spike, you want all those logs in one bucket and an alert that wakes the SOC—like smoke detectors tied to a central panel. Turning logging off or waiting a year just hides the fire.
Full Explanation
Central aggregation of VPN concentrator logs plus actionable alerts on failed-logon bursts is how the municipal SOC detects credential attacks or misconfigurations in time to respond. Burst patterns across many accounts are classic monitoring signals for password spraying or botnet probing against remote access. Shipping those logs to a SIEM or equivalent, then paging on thresholds, converts raw telemetry into security operations action.
Disabling VPN logging during a spike destroys the evidence and blinds detection to save storage—the opposite of monitoring. Waiting for the next annual audit reviews history too late for an active burst. Deleting failed-logon records to keep dashboards green is intentional concealment and removes forensic value.
Exam caveat: monitoring includes both collection and alerting; logs without detections still delay response. Tune thresholds to account for shift-change noise without suppressing true multi-account sprays against city VPN.
Operational check: forward VPN auth logs in near real time, alert on failed-logon rate and distinct-account spikes, correlate with geo/ASN anomalies, and have a playbook to lock accounts, block sources, and force resets when criteria hit.