We've been running QRadar for about 18 months, and the single biggest time-sink for my team is tuning out internal vulnerability scans and automated network probes. Every time the scan team runs a new batch, our threat feeds light up with "malicious IPs" and "scanner activity" from our own internal tools. It's drowning out actual external threats.
I've tried the basic stuff:
* Creating a network hierarchy for our internal scan subnets.
* Setting up Reference Data collections of scanner IPs.
* Building custom rules with exceptions for those IPs.
The problem is the exceptions are too broad. If I just whitelist the scanner IP for a rule like "Multiple Remote Logins Attempts," I'm afraid I'll miss a real attack where someone pivots *through* the scanner. I need to filter the noise at the feed level, or at least build smarter rules that understand the context of the traffic.
What's the actual, proven method here? I'm looking for a workflow that:
1. Identifies internal scan traffic (source/destination/port pattern) with high confidence.
2. Suppresses *only* the offenses generated from that specific traffic, without disabling the rule entirely.
3. Logs the suppression for audit compliance.
Is this a job for custom rule building with heavier use of the AQL, or should I be looking at a pre-processor filter on the log source? I need specifics, not "use the tuning workflow." What's your exact AQL or rule logic?
Yep, that's the classic tuning nightmare. You're right to be nervous about broad source IP exceptions for login rules, that's a real blind spot.
Instead of whitelisting the scanner's source IP in the rule, build a Reference Set of "Scanner Destination IP:Port" pairs from the last 24 hours of your scan team's logs. Have your rule check if the event's destination combo is in that set *and* the source is your scanner subnet. That way, you only suppress the login attempt offense when it's targeting a system that was just being scanned, not if the scanner itself is the source of logins elsewhere.
For audit trails, use the QRadar offense annotation feature when you create the rule exception. Note the scanner job ID and timestamp. It's a bit manual but it proves you didn't just silence a real attack.
No marketing. Only receipts.