An alert shows a user logging in from Paris and, five minutes later, from Singapore. Before declaring an incident, what do you check FIRST?
Short answer
Validate before escalating. Corporate VPNs, cloud proxies (like CASB or M365 service IPs) and mobile carriers routinely produce false 'impossible travel,' so check the egress IPs, the MFA result, and the device/user-agent before pulling the trigger. Auto-locking on every hit causes alert fatigue and erodes user trust in the SOC. Assuming it's always a false positive misses real account takeover. Emailing the manager is slow and isn't a security control — the logs answer the question faster and more reliably.
Impossible-travel alerts are high-volume and high-false-positive, which is exactly why a junior analyst is tested on them: do you react, or do you investigate? The correct first move is to validate the signal with the data you already have before disrupting a user or declaring an incident.
Why validation comes first
Geolocation is inferred from IP, and IPs lie constantly in an enterprise. The "Singapore" login might be a corporate VPN concentrator, a cloud egress (M365 backend service IPs, a CASB proxy), or a mobile carrier routing through a distant gateway. So you check:
- The egress IP / ASN for each login — is one a known corporate or cloud range?
- The MFA result — did a phishing-resistant factor succeed, or was MFA skipped/failed?
- The device and user-agent — same managed device, or a new unknown client?
These fields usually resolve the alert in under a minute and tell you whether it's benign or a genuine account takeover worth escalating.
Why the other options are wrong
- Auto-lock and open a P1 — locking on every impossible-travel hit drowns the SOC in P1s, disrupts legitimate users, and teaches the business that security cries wolf. Reserve the lock for validated compromise.
- Always a false positive — the lazy mirror image. Impossible travel is a real ATO indicator; dismissing it by default means you'll wave through the genuine attack when it comes.
- Email the manager — slow, indirect, and not a control. The manager's reply doesn't tell you what the auth logs do, and you've burned dwell time waiting for it.
What the interviewer is probing
They want to see disciplined triage from a junior: enrich and validate with logs before acting, distinguish a benign egress quirk from a real takeover, and escalate only on evidence. Naming the VPN/cloud-egress explanation and the MFA/device check shows you understand why these alerts are noisy and how to separate signal from noise without either ignoring them or over-reacting.
Likely follow-ups
- What specific log fields would confirm or rule out a genuine takeover here?
- If MFA succeeded from both locations, does that make it safe or more suspicious?
- How would you tune this detection to allowlist known corporate egress without going blind to real attacks?