Impossible Travel Rule with Service Accounts and NAT
An AI Engine rule named Impossible Travel fires when the same user authenticates from two countries within two hours. It produces about 60 alarms per day. Investigation shows roughly 80% involve service accounts running scheduled jobs across data centers, and another 10% come from a corporate VPN egress that geolocates to two cities because of carrier routing. The remaining 10% include real user travel and a small number of compromised accounts. The CIO wants the rule disabled because analysts ignore it, but the security team has evidence that one of the true positives led to a credential compromise last quarter. You have Lists, Watchlists, entity enrichment, and the AI Engine rule test capability. You need to reduce noise without losing the compromised-account signal, and you must be able to justify the change to auditors.
1. What rule logic and reference-data changes would you make, and why is disabling the rule the wrong control?
Read the worked answer
Disabling the rule removes the only control that caught the prior credential compromise, so the problem is precision, not the concept. I would first exclude non-interactive and service-account authentication using a List of service accounts and a logon-type condition, rather than excluding all authentication from data centers. I would add a List of known VPN egress and NAT ranges, but only after confirming those ranges cannot be used by an attacker without corresponding VPN logs; the rule should then correlate with VPN authentication or be downgraded, not blindly trusted. I would require successful interactive logon and group by user plus entity so a user working through a remote entity is evaluated against the right location baseline. I would keep a high-severity variant for privileged accounts on a Watchlist. The revised rule should retain the original event fields and the geolocation evidence so analysts can distinguish real travel from carrier geolocation errors.
2. How would you test the revised rule and measure whether it is better, not just quieter?
Read the worked answer
I would backtest the revised logic against at least 90 days of historical authentication data using the AI Engine rule test capability or equivalent searches, and compare the alert set with the known true positive and known service-account false positives. I would define metrics before the change: alarm count per day, true-positive count, false-positive count, precision, analyst triage time, and missed known incidents. A quieter rule that drops the prior compromise is a failure even if volume falls. I would run the revised rule in parallel with the old rule for a limited period, route both to a test queue or annotate alarms, and review a sample daily. After production, I would keep a monthly review of excluded service accounts and NAT ranges because infrastructure changes can silently create blind spots.