VPN Log Gap and the Impossible Travel Rule
Northwind Advisory is a 4,200-person professional services firm that relies on VPN access for 1,800 remote staff. Its Exabeam deployment receives VPN authentication and session logs from three concentrators through a syslog relay. After a firmware upgrade on the APAC concentrator, the SOC notices that VPN event volume falls by 18% between 01:00 and 03:00 UTC, and the impossible-travel correlation rule stops firing for APAC users. The source concentrator dashboard still shows successful and failed logins, and the syslog relay reports no disk or CPU pressure. Exabeam shows the last parsed VPN event at 02:47, but there are no parser error messages in the ingestion health view. A change freeze blocks another firmware change until the weekend, and an external audit requiring evidence of remote-access monitoring starts in five days. Analysts disagree whether the problem is collection, parsing, or rule logic, and one suggests disabling the noisy impossible-travel rule until the upgrade is reversed.
1. What sequence would you use to localize the fault, and what evidence at each layer would confirm or eliminate collection, parsing, or rule logic?
Read the worked answer
Localize in three layers, in order, and avoid assuming the rule is wrong because it stopped firing. First compare event counts at the source concentrator, the syslog relay, and the Exabeam normalized VPN table for the same 15-minute window, such as 01:00-01:15 UTC. If the source shows 400 logins and the relay shows 400 but Exabeam shows 260, the loss is after transport: parser, normalization, or indexing. If the relay shows 260, it is transport or source export. If all three show 400 but the rule does not fire, inspect rule logic and enrichment. Second, check raw messages for malformed fields, a changed field name, or a new timezone format after firmware; a parser can succeed syntactically while mapping the timestamp or user field to null. Third, run a known impossible-travel test with two synthetic logins from distant locations and confirm the rule fires. The absence of parser errors is not proof: parsers often drop unneeded fields silently. The 02:47 last-event timestamp suggests a boundary issue, so compare the last event per concentrator and per log type. Document each layer's counts so the audit trail shows how the conclusion was reached.
2. What compensating monitoring would you put in place during the change freeze, and how would you prove it to the auditor without hiding risk?
Read the worked answer
Use an independent identity source, not a duplicate VPN feed. Pull authentication and MFA events from the IdP, which covers the same remote users, and create a temporary correlation rule for successful VPN plus MFA from a new country or impossible travel based on IdP geolocation. Add a daily reconciliation report: source concentrator successful logins versus Exabeam VPN sessions by hour; if variance exceeds 2%, open an incident. For the auditor, present the failed control, the temporary control, the reconciliation evidence, and the time-bound risk acceptance. Do not disable the impossible-travel rule; instead, suppress only known false positives with a watchlist and an expiry date. Keep the rule in test mode with alerting to a review queue so coverage remains visible. If the rule is noisy because of the log gap, rename the alert to reflect partial coverage and route it to a human reviewer. The key is to show detection is still operating, not to claim the original control is healthy. Record who accepted the temporary risk and when the compensating control ends.
3. What permanent fix and validation would you require before closing the incident?
Read the worked answer
Correct the source or relay buffer and time sync, update the parser for the new firmware field mapping, and add a canary event every 15 minutes from each concentrator. Require the vendor to document syslog message format changes before upgrades, and add a pre-upgrade parser test to the change process. Validation should replay one hour of known production logs through the parser in a test namespace, compare normalized user, source IP, timestamp, and result fields to expected values, and confirm the impossible-travel rule fires on a synthetic pair. Monitor ingestion health with a threshold: if VPN event count deviates more than 10% from the 7-day same-hour baseline, alert. After the weekend change, run 24 hours of parallel monitoring before closing. Add a data-quality dashboard for each log source showing last event, parse rate, and field completeness. Update the audit evidence with the root cause and the new control, not just the restored volume, and verify that the compensating IdP rule is retired only after the primary rule passes the synthetic test.