Credential-Stuffing Rule Tuning Versus NAT Suppression
Cortex XSIAM ingests 900 million authentication events per day from 18,000 identities. A correlation rule named Auth-Burst-Success fires when an IP has five failed logins across at least three usernames followed by one success within 10 minutes. It produces about 1,800 alerts per day. Tuning data shows 82% originate from three NAT egress ranges used by a partner call center, and 11% are from a vulnerability scanner. The rule uses a 30-day lookback, and each alert triggers a playbook that enriches the source IP with geolocation and asset criticality; median enrichment time is 4 minutes. Analysts have a 15-minute triage target for high-severity alerts, but the queue is 6 hours deep. You need to reduce noise while keeping detection for credential stuffing against privileged accounts. The CISO asks whether to suppress the NAT ranges outright or tune the rule; a recent red-team test used a call-center laptop to attempt login against a domain admin.
1. Compare outright suppression of the NAT ranges with rule tuning. Which do you recommend and why?
Read the worked answer
Outright suppression is unsafe. The red-team path used a call-center laptop inside one of the NAT ranges, so suppressing all three ranges would remove visibility into exactly the path that was exercised. It also creates a permanent blind spot that attackers can rent. Tuning is better, but scoped: keep the rule for privileged accounts and for any successful authentication from those NAT ranges to high-value applications; lower or aggregate only non-privileged, low-risk patterns. The scanner range is a better suppression candidate, but only with an owner, expiry, and confirmation that it is not used for interactive logins. The goal is not zero alerts from the NAT; it is to collapse commodity noise while preserving a high-severity path for privileged or red-team-like behavior.
2. Rewrite the detection logic to reduce false positives while preserving coverage for privileged accounts and the red-team case.
Read the worked answer
Rewrite as two tiers. Tier A (high): five failures across at least three usernames followed by a success within 10 minutes, where the target is privileged or the source is outside known NAT ranges. Tier B (low): the same pattern from a known NAT range against non-privileged targets; aggregate by source IP and hour into one issue instead of one per user. Add distinct-target count and successful-auth flag so password spraying and stuffing separate from normal mistypes. Exclude confirmed scanner IPs with an expiring exception. Reduce the rule lookback to 24 hours for enrichment, not 30 days, and keep the 10-minute detection window. This should cut volume sharply while still firing on the red-team case: a call-center laptop succeeding against a domain admin is privileged and remains Tier A.
3. How would you validate the tuning before production, and which metrics would prove success?
Read the worked answer
Run the new logic in shadow mode for 7-10 days alongside the existing rule. Backtest against the red-team event and a sample of confirmed credential-stuffing incidents. Compare alerts per day, true-positive rate, privileged-account coverage, and time to detect. Confirm the scanner exception does not remove any privileged login. Require an owner and 90-day expiry for every suppression. After cutover, monitor weekly for missed privileged successes and for a rise in Tier B aggregation hiding a real campaign. Do not declare success from volume alone; the acceptance criterion is fewer alerts with no loss of privileged or red-team coverage.