SIEM Rule Tuning Against a Noisy Detection
A SIEM detection for "impossible travel" fires 300 times a day across 4,000 users. The rule compares consecutive successful logins by geolocation and flags any pair under 60 minutes apart in different countries. Investigation of a 50-alert sample finds: 41 are corporate VPN egress in a datacenter country that differs from the user's home country; 6 are mobile carrier IP geolocation errors; 3 are genuine - one is a user whose credentials were used from a foreign IP while they were on leave. The SOC has two analysts and currently spends about 4 hours a day triaging this rule. Leadership wants the alert volume cut without losing the genuine detections.
1. Propose a tuning strategy that addresses the 41 VPN false positives without suppressing the 3 genuine cases.
Read the worked answer
The dominant false positive is structural: the rule treats VPN egress geography as the user's location. The fix is not a threshold bump but a data-model change.
- Enrich with VPN/ZTNA session data so a login whose source IP matches an active corporate VPN egress is tagged and excluded from the geo comparison, or compared against the VPN exit rather than the user's home country.
- Maintain a known-egress allowlist of corporate datacenter ranges and mark them as "corporate egress" in enrichment, not "foreign country."
- Suppress mobile carrier geolocation where the IP maps to a carrier NAT range with known poor accuracy.
Critically, none of these suppress a login from a non-corporate foreign IP, which is what the genuine case looked like. The rule should still fire when the source is neither a known egress nor a carrier range and the travel is physically implausible. Tuning the enrichment preserves the detection signal while removing the structural noise.
2. How should the team validate the tuned rule before and after deployment?
Read the worked answer
Backtest against historical data first: replay 30–90 days of authentication logs through the tuned logic and confirm the 3 known genuine cases still alert and the 41 VPN cases drop. This is the only way to show the change did not create a blind spot. Define success metrics up front - alert volume per day, analyst minutes per alert, and true-positive count on the replay set - and compare before and after. After deployment, keep the rule in a monitored state for a defined period (e.g., two weeks) with a sample review of suppressed events to catch a missed class of true positive. A tuning change that is not backtested is just a guess with a lower alert count.
3. One of the three genuine detections involved a user on leave. What does that imply about the rule's scope?
Read the worked answer
It shows the rule is catching credential misuse, not just travel - the account was used from a foreign IP while the legitimate user was absent. That is a valuable detection class the team should not lose. It argues for keeping the rule sensitive to non-corporate foreign logins even when the user's own location is unknown, and for pairing it with an out-of-office or leave-calendar enrichment so that a login during approved leave raises priority rather than being suppressed. The lesson: tune the noise source (VPN egress), not the behavior (credential use from an unexpected foreign source).