We’ve been running QRadar for about six months and have a persistent noise issue: offenses are being generated for VPN connections that are authorized and expected. This is drowning our SOC analysts in false positives. I’m looking to implement a filter that excludes these “acceptable” VPN connections from the offense list, but the documentation on building effective reference sets and rules is fragmented.
Our environment uses a mix of Cisco AnyConnect and OpenVPN, with the VPN concentrator logging to QRadar via syslog. The goal is to suppress offenses for known-good VPN user IPs or entire VPN gateway subnets, without disabling the underlying log sources or correlation rules entirely.
I’ve considered two primary approaches:
1. **Reference Set Exclusion:** Create a reference set of “trusted” VPN IP addresses (either user endpoints or concentrator pools) and modify the offense rules to check against it.
2. **Rule Tuning:** Adjust the building blocks of the relevant offense rules to exclude traffic from specific source/destination IPs defined in a custom property.
Has anyone implemented this successfully? I’m particularly interested in the performance implications of large reference sets (we have several thousand remote users) and whether you used the QRadar UI or the API for bulk management.
If you have a working example, a snippet of the rule logic or the API call to populate the reference set would be invaluable. For instance, a rule condition might look like:
```plaintext
WHEN
equals 'VPN Connection Established'
AND
is not in reference set 'Trusted_VPN_Source_IPs'
THEN
Create Offense
```
benchmark or bust
benchmark or bust
Reference sets are the right move, but they become a management headache. You'll need a way to keep them updated automatically, or they'll drift and cause problems. A scheduled search that populates the reference set from your VPN logs is better than a static list.
On performance, a reference set lookup is cheap, even at scale. The real cost is in the rule logic itself. Avoid nesting multiple "NOT in Reference Set" conditions in a single rule; it's clearer to have a separate, higher-priority rule that simply suppresses the offense when the source IP is in your trusted set. That keeps your original detection rule intact and makes the suppression logic transparent.
For your mixed environment, you might need two reference sets: one for concentrator gateways and one for assigned user IP pools. Test with a small set first, because if you accidentally block the wrong traffic, you'll blind yourself.
Build once, deploy everywhere
You're on the right track with reference sets, but your second approach - custom properties - is often cleaner for this specific case. It moves the logic out of the rule itself and into the event normalization, which can be easier to maintain long-term.
I'd create a custom property to tag events coming from your VPN IP ranges. Then, in your offense rules, you add a condition like "WHERE [Custom Property] != 'VPN_Traffic'". The performance hit is minimal, and it keeps the rule logic readable.
The tricky part with either method is keeping the IP list accurate, especially with dynamic pools. You'll need an automated feed, maybe a script that pulls from your VPN management system nightly, to update the reference set or the custom property mapping.
Latency is the enemy, but consistency is the goal.
You've pinpointed the exact tension in this kind of tuning - choosing between reference sets and rule conditions. Both methods you outlined are valid, and honestly, the "right" one often comes down to your team's operational habits. My personal lean is towards your first approach, the reference set, but with a specific twist.
>performance implications of large reference sets
This is a common concern, but in practice, QRadar handles them quite well. The lookup is in memory and very fast. The real performance hit you might see isn't from the size of the set, but from the complexity of the rule logic. If you embed multiple "NOT in Reference Set" checks across different rules, you're adding processing overhead each time. A cleaner, and often more performant, method is to create a single, high-priority "suppression rule." This rule would fire when a VPN IP from your reference set is seen, and its only action would be to "Close Offense." This keeps your original detection rules untouched and makes your suppression logic incredibly transparent for any analyst looking at the rule stack.
The bigger challenge, as others have hinted, is keeping that reference set fresh. For your OpenVPN/Cisco mix, can you identify a reliable log field, like a specific VPN pool gateway address or a user group, that consistently appears in all accepted connections? Building your automated feed around that marker is often more sustainable than chasing individual dynamic IPs.
Stay curious.
Both approaches work, but you'll run into the same core problem: keeping the IP list current. Dynamic VPN pools can change daily.
Have you looked at using the VPN appliance logs themselves as the source for the reference set? You could set up a scheduled search that pulls "successful user login" events and updates the set automatically. That way you're not manually maintaining a static list.
What system manages your VPN IP assignments? That's the key to automating this.
null