How do I filter out benign network scans from the Enterprise Security dashboard?

That's a sharp observation about the short TTL catching tactical shifts. We had a similar experience with scanners testing a whitelist's patience.

The trade-off, in our setup, is that a 24-hour decay can be too aggressive for certain infrastructure. It started flagging routine vulnerability assessments from our own security team. We had to create a separate "approved internal scanner" list to avoid that noise, which is its own maintenance headache.

You've perfectly described the vendor documentation problem. It's theoretical, not operational.

On your specific point about dropping the base risk score for scans: I'd advise against it. That action is global and irreversible within the scoring chain, and it degrades the fidelity of your entire risk index. A more surgical method is to apply a conditional risk reduction, but only when specific, safe criteria are met. For example, we append a substantial negative risk modifier to the "Network Scan" rule, but it triggers only if the scan exclusively targets ports 80 or 443 *and* the source IP's total event count in the last hour is below a high threshold, say 500. This carves out the high-volume, low-skill background noise while leaving the score intact for a slower, more targeted multi-port sweep.

For whitelists, maintaining a static lookup of "benign" IPs is a fool's errand due to IP rotation and reputation decay. We found more success using a scheduled search to dynamically populate a lookup with IPs exhibiting demonstrably harmless behavior over a rolling 48-hour window, like only scanning a single service port across many of our IPs. This list automatically ages out entries after 72 hours, which balances the need for persistence with the reality of shifting infrastructure.

You're not wrong about trading one manual process for another. That's the core trap. But the alternative isn't "no moving parts," it's "which moving parts have the highest yield?"

I treat the decay parameter not as a daily knob to turn, but as a quarterly infrastructure review item. When we onboard a new PCI segment or an internet-facing service, we set its baseline. The maintenance is in the change ticket, not a separate process.

> "is it even a whitelist anymore"
Exactly. That's the point. Once you layer on conditions, you've built a classifier. Calling it a whitelist is what creates the maintenance burden. We stopped using the word entirely and manage it as a low-priority detection rule with a weekly automated health check.

You've hit the nail on the head about the vendor docs. That generic "refine your rules" advice drove me nuts during our last beta.

We tackled it by building a dynamic filter for the `Network_Traffic` model. Instead of a static whitelist, a scheduled search tags IPs as `likely_benign_scanner` based on a pattern. For us, the key criteria are:
* Targeting only ports 80, 443, or 8080
* Scanning more than 3 distinct external IPs
* Having a request rate under 150 attempts per 5-minute window

Events from tagged IPs get a *massive* negative risk modifier applied to the original "Network Scan" rule, effectively sinking them off the dashboard. The real trick is the tag's short TTL, just 8 hours. It catches persistent background bots without accidentally protecting a source that shifts to more aggressive tactics later.

It's not a whitelist. It's a temporary, context-aware suppressor. This cut our scan noise by about 70% without touching the base risk rule score. Have you tested any pattern-based tagging?

The 8-hour TTL for your `likely_benign_scanner` tag is a smart touch. That's a nice balance between keeping persistent noise down and not letting the classification become stale if the source changes behavior.

One thing we had to watch out for with a similar pattern-based approach was our own CDN edges and certain SaaS monitoring services. They sometimes hit the port and IP diversity criteria during normal operations, so we added an extra filter to exclude our known trusted ASNs from the tagging search. It added maybe two lines to the logic and saved us from sinking legitimate traffic.