Impossible Travel, Late VPN Logs, and an Auto-Disable Playbook
Vertex Financial's New-Scale tenant runs a custom impossible-travel rule that fires about 60 alerts per day. Investigation shows 70% come from corporate VPN egress in three countries, 20% from mobile carrier NAT, and 10% are genuine. An AI agent workflow auto-creates a case, emails the user, and after three failed confirmations invokes a SOAR playbook that disables the account. Last week it disabled 14 users, including the CFO during an earnings call. The IdP logs are ingested, but VPN logs arrive 25 minutes late due to a batch collector. Endpoint logs are available but not used in the rule. The SOC wants to keep automation but add guardrails. The audit committee asks how the team reconstructs an identity timeline and preserves evidence.
1. Redesign the detection logic and enrichment. What data and conditions would you require before the rule fires?
Read the worked answer
Rebuild the rule around successful authentication and trusted-network context. Enrich with VPN inventory, egress IP ranges, ASN, carrier NAT ranges, device ID, MFA result, and IdP risk. Exclude corporate VPN egress and known carrier NAT from impossible-travel geography, but keep the event for other anomalies. Require two successful authentications from geographically distant locations within a window that physical travel cannot cover, and require that at least one is not from a known egress. Use endpoint and resource-access events to raise severity when the second session touches sensitive data. Fix the VPN batch delay; a 25-minute lag means the rule is comparing incomplete data. Either stream VPN logs or add a delay watermark so the rule does not fire before context arrives. Test against 30 days of historical data and measure precision before enabling.
2. What guardrails would you put on the AI agent and SOAR playbook while keeping automation useful?
Read the worked answer
Automation can create a case and enrich, but account disablement is destructive and needs a human approval gate unless confidence is very high and the action is reversible. Add a confidence score based on source trust, MFA, device compliance, and VPN context; route high-confidence cases to a responder with an approve or deny step. The AI agent should not email the user as the only verification, because phishing or a compromised mailbox can answer. Use out-of-band verification through the service desk or manager. Add a rollback runbook and a maximum auto-disable duration. Log every agent decision, prompt, data used, and approver in the case. Test with a tabletop that includes the CFO scenario. Measure auto-disable precision and false-lockout rate; if precision is below an agreed threshold, downgrade to recommend-only.
3. How would you reconstruct an identity timeline and preserve evidence for the audit committee?
Read the worked answer
Build a Smart Timeline keyed to the identity, not the alert. Include IdP authentication, MFA, VPN, endpoint process and logon events, email, and resource access, with source timestamps normalized to UTC. Mark late-arriving VPN events and show ingest time separately so the timeline does not imply false ordering. Preserve raw events, case notes, agent decisions, and playbook actions with immutable audit logs. For audit, export the timeline and a chain-of-custody note showing source, query, time range, and collector. Reconstruct the 14 lockouts and identify which decisions were based on incomplete VPN data. That review should feed the rule and playbook changes, not just an apology.