Alright, so you’ve finally got your shiny new XDR platform deployed, and suddenly your SOC team is drowning in alerts. But half of them are from your own vulnerability scanner poking and prodding your test servers every Tuesday at 2 AM. Classic. 😑
We faced this exact noise problem last year after migrating from a legacy SIEM to Vision One. The vulnerability management integration is great... until it isn't. Our scanner (let's call it "ScannerMcScanFace") runs aggressive authenticated scans that Vision One dutifully interprets as malicious activity, flooding us with "Malicious Connection" and "Suspicious Process" alerts. The trick is to carve out exceptions without blinding yourself to real attacks originating from your scanner's IP.
Here’s the painful, step-by-step saga of how we silenced the false positives, complete with the gotchas we hit along the way.
**First, the obvious (and insufficient) approach: IP Exclusions in the policy.**
You’d think just adding your scanner's IP range to the "Excluded Hosts" in your "Recommended Policy" would do it. It helps, but Vision One's correlation rules are sneaky—some alerts are generated from deeper telemetry that seems to bypass simple IP exclusions. We still saw a trickle of "Suspicious Registry Modification" alerts from scan activities.
**The real solution involved a two-pronged attack:**
1. **Policy Exclusions:** For the baseline noise.
2. **Custom XDR Rules to filter the rest:** This was the key.
We created a custom correlation rule that essentially says: *"If the activity is coming from this source IP (our scanner) AND is targeting these test server IPs, then lower the severity to 'Info' and don't notify."*
Here's a rough skeleton of the rule logic we used in Vision One's XDR rule editor (names changed to protect the innocent):
```yaml
rule "Filter VM Scanner Test Noise"
description "Downgrade alerts from internal vulnerability scanner during test window"
condition:
all of them
subconditions:
- source.ip.address in ["10.10.5.10", "10.10.5.11"] # Scanner IPs
- target.ip.address in ["10.20.15.0/24"] # Our test server subnet
# Optional: Add a time constraint if your scans are scheduled
# - event.occur_time between ["T02:00:00", "T04:00:00"] on ["Tue"]
outcome:
severity: info
notification_profile: "Do Not Notify"
```
**Gotchas we learned the hard way:**
* **Order matters:** Place your custom *filtering* rules **ABOVE** the built-in "Recommended Rules" in the rule list. Processing is top-down.
* **Don't over-exclude:** We initially excluded the entire scanner subnet from all detection. Bad move. A real attacker could pivot *through* the scanner host. Our rule above scopes the exclusion only when the target is our *test* network.
* **Test in "Log Only":** Deploy the rule in "Log Only" mode for a week first. Review the "Info" level events to ensure you're not accidentally suppressing something real.
* **The maintenance burden:** When the scanner IPs change or you add new test subnets, you have to remember to update this rule. It's a manual config drift waiting to happen. We document it as part of our change control for the VM team.
It took us about three full scan cycles (so, three weeks) to fully tune it to quiet. The SOC’s Slack channel is now significantly less rage-filled on Tuesday mornings.
Migrated and lived to tell.
MrMigration