Offense storm from a building block after a scanner change
An MSSP has a rule Offense-Failed-Login that fires when building block BB-Failed matches 10 Windows 4625 events in 5 minutes, grouped per source IP. BB-Failed excludes usernames svc_backup and svc_sql but nothing else. A new internal vulnerability scanner scans 300 servers every 4 hours, rotating across 20 source IPs and using 40 test accounts. The rule now creates about 400 offenses per day; analysts close them as false positives. Real brute-force attempts come from two external IPs and are lost in the noise. The MSSP wants to keep detecting external brute force, keep service-account exclusions, and retain evidence for audit. They can change rules and building blocks but cannot disable the scanner this quarter.
1. Why does the current rule produce so many offenses, and what rule-design changes reduce noise without hiding external brute force?
Read the worked answer
Reasoning: BB-Failed only removes two service accounts. The scanner uses 40 test accounts and 20 source IPs, so 10 failures in 5 minutes is easily met per IP; grouping per source IP multiplies the offenses. External brute force from two IPs is buried. Decision: keep BB-Failed for the shared exclusion, then add a second building block BB-External-Failed that matches only sources outside the internal network hierarchy. Use BB-External-Failed in a low-threshold external rule and keep the internal rule with a much higher threshold or suppress it for scanner assets. Better: exclude the scanner subnet from the internal rule and create a separate authorized-scan rule with no offense, only a report. Use offense naming with username and destination, not just source IP. Do not simply raise the global threshold to 100; that would hide the external case. Validate with Rule Test against a week of events and compare offense counts.
2. How would you use QRadar rule test and offense data to validate before enabling?
Read the worked answer
Before enabling, use Rule Wizard Test on one week of historical events, run the building block test, and record matches by source. Create a disabled copy of the new rule, deploy, then enable it in a maintenance window. Compare daily offense counts and inspect the first 20 offenses for contributing rules and raw events. Keep the old rule saved for rollback. After 48 hours, if the scanner still dominates, add a scanner asset exclusion rather than loosening the external rule. This tests both the logic and the offense volume before analysts see it.
3. What do you do with the existing 400 open offenses?
Read the worked answer
Handle the existing 400 offenses as evidence, not noise: bulk close with a documented reason such as authorized vulnerability scanner, do not delete them, and add a note linking the scanner change. Then create a suppression or rule exception for the scanner, not a global offense deletion. Keep the external brute-force offenses open and assign them. Review offense retention and audit requirements before any purge. This preserves the audit trail and prevents analysts from re-triaging the same scanner noise.