VPN Alert Cluster Before the Executive Call
At 02:10 on a Tuesday, the SIEM generates 60 alerts in 90 minutes for the rule 'VPN failed logins then success.' Twelve alerts share an unfamiliar ASN; three involve disabled service accounts; one is for a privileged finance administrator from an IP geolocated 900 km from her usual city. The service desk has just launched a company-wide password reset after a phishing wave, and the CISO wants a decision before the 08:00 executive call. You have two analysts: one has six months' experience and is scheduled to leave at 06:00; the other is engaged on a suspected malware outbreak in the warehouse. The ticketing SLA for a P1 is 15 minutes, and the SOC has no authority to disable accounts without service-desk approval. Last quarter, a similar alert cluster was a false positive caused by a misconfigured VPN concentrator.
1. How should you classify and prioritize this cluster, and what would you do in the first 15 minutes?
Read the worked answer
Classify the cluster as a suspicious event, not yet a confirmed incident. The key separator is not the volume of failures; it is whether any success produced an anomalous authenticated session. The privileged finance administrator alert is the highest priority because that account can access financial systems and because the source is 900 km from her normal location. In the first 15 minutes: (1) preserve VPN, IdP, and EDR logs for the 60 alerts; (2) open a P1 ticket only for the privileged success, with the rest linked as related events; (3) contact the finance admin out of band, not via email, to confirm whether she is traveling; (4) ask the service desk to check MFA results for that session; (5) request a temporary block of the unfamiliar ASN through the network team, while documenting business impact. Do not mass-disable accounts or reset all 60 users yet: the phishing reset campaign could explain many failures, and mass action would destroy evidence and disrupt operations. Escalate to the service-desk manager for account-disable approval if MFA was bypassed or the user denies the session.
2. What evidence would move this from a suspicious event to a confirmed incident, and what would keep it an event?
Read the worked answer
Move to confirmed incident if any of these are true: a successful privileged login without a valid MFA challenge; an authenticated session from the unfamiliar ASN with commands, mailbox rule creation, or file access; the finance admin denies the login; or the source IP appears in threat intelligence as a credential-stuffing node. Also check whether the disabled service accounts are truly disabled in the IdP and AD; a success there is a control failure, even if benign. Keep it an event if every success is tied to the password-reset campaign, MFA was satisfied, the user confirms the session, and the ASN belongs to the corporate VPN provider. The distinction matters because incident declaration triggers legal, communications, and evidence-preservation duties. Document the decision and the exact log lines used. If evidence is ambiguous at 06:00, declare a low-confidence incident with a conservative scope rather than closing it; you can downgrade later.
3. The CISO asks whether to disable all 60 accounts. Evaluate that request.
Read the worked answer
Disabling all 60 accounts is disproportionate and likely harmful. Most failures probably come from the phishing reset, and disabling everyone would lock out staff, generate a new wave of help-desk tickets, and obscure the real attack path. Instead, apply risk-based containment: disable the privileged finance account and any account with a confirmed successful anomalous session; force reauthentication and reset for accounts that succeeded from the unfamiliar ASN; leave failed-only accounts in the reset campaign. Require service-desk approval for each disable, as policy states, but escalate the privileged case immediately because delay is itself a risk. Record who approved each action and why. Reassess in two hours using MFA logs and user confirmations. This preserves business continuity while containing the accounts that could cause real damage.