impossible travel" alert tuning to reduce noise

"impossible travel" alert tuning to reduce noise

TL;DR

Impossible travel fires when one account logs in from two places farther apart than a human could travel. The default rules are too twitchy and will bury you in VPN and geo-IP noise. Calibrate the speed threshold to your workforce, exempt known VPN exits, and require a second signal like a new device before anyone gets paged.

"impossible travel" alert tuning to reduce noise

Use this when

• your identity provider's impossible travel alerts fire 50 times a day and everyone ignores them
• you just turned on conditional access or a new SIEM and the noise is unbearable
• remote staff, travelers, and VPN users keep tripping the rule
• you want the alert to mean something again

Not for this skill when

• you need to investigate a specific suspicious login (that is a different skill)
• the logins come from a datacenter IP doing API calls, not a human traveling
• you want to block logins outright instead of alerting (that is conditional access policy)
• you have no geo data at all in your auth logs

Steps

1. Measure the pain. Count how many impossible travel alerts fired in the last 30 days and how many were real incidents:

index=auth sourcetype=impossible_travel
| stats count by user, src_city
| sort - count

Expected: a list dominated by a few users and cities. Those are your tuning targets, not attackers.

1. Set a realistic speed threshold. Defaults often flag anything over 300 miles in an hour. For a remote workforce, start at 500 miles within 2 hours and only alert if the two logins are also from different autonomous system numbers. VPN exits change geography without changing much else, and the ASN check kills most of that noise.

1. Exempt your known VPN and office egress IPs. Get the egress ranges from your VPN provider's published list and add them as a suppression: if either login in the pair comes from a known egress range, drop it or downgrade it to an info event.

1. Handle mobile and satellite internet. Geo-IP databases place mobile users wrong all the time, and satellite internet can exit hundreds of miles away. For users flagged as mobile, widen the window to 4 hours before alerting.

1. Require a second signal before paging. Impossible travel alone becomes a ticket. Impossible travel plus a new device enrollment, a password change, or an MFA method added in the same hour becomes a page. One weak signal stays quiet; two weak signals get loud.

1. Review weekly for a month. Every Friday, re-run the count from step 1. If false positives are still over half, raise the threshold or add suppressions. If you ever get zero alerts for two weeks straight, the rule is probably broken, not perfect. Check that it still fires on a test pair.

Variant: tuning for a fully remote team across time zones

When everyone works from home in different states, travel alerts fire on normal life. Add home-city allowlists per user and only alert on logins from a third city, never seen before, paired with one of the first two.

Variant: using ASN instead of city for the distance check

Some teams drop geography entirely and alert on logins from two different ISPs or ASNs within a short window. It is cruder but immune to bad geo-IP data. Pair it with the new-device signal so it stays quiet.

Variant: mid-flight Wi-Fi and trains

Users on planes and trains bounce between cell towers and exit nodes fast. If your workforce travels a lot, suppress alerts where one endpoint is a known airline or rail Wi-Fi range, and lean on the second-signal rule instead.

Why this happens

Geo-IP data is approximate, VPNs exit wherever they want, and mobile networks hand off constantly. The detection logic is sound, a person cannot be in Chicago and London an hour apart, but the location data it runs on is noisy. Tuning is just teaching the rule which noise is normal for your people.

Edge cases and pitfalls

• Dont exempt your whole VPN range and call it done. Attackers use commercial VPNs too. Exempt only your corporate VPN egress, and keep alerting on logins from consumer VPN providers.
• Shared credentials break this rule completely. If three people share one service account from three cities, every login looks impossible. Service accounts need their own rules.
• Geo-IP databases go stale. If alerts suddenly spike for one region, check whether your geo database updated before you blame users.
• A real attacker who replays a session token may never log in at all, so this rule never fires. It is one signal among several, not a guarantee.
• Test logins from your own red team or pentest will trip it. Add the test source ranges to suppressions during engagements.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7gL7UZXwdTLlkyK9KbaTyw