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

I feel your pain. We run a fairly open homelab and the constant scan noise is unreal. For risk based filtering, we had to get surgical. Instead of globally dropping scores for "Network Scan Detected," we built a conditional rule. It only lowers the risk score if the scan is targeting a port we intentionally expose to the internet, like 443 or 80. Scans for closed or internal ports on our external IP still get flagged higher.

On whitelisting, I maintain a small local lookup of IPs from projects like Censys and some university research nets we've vetted. It's not perfect though, because sometimes those ranges get repurposed. How often do you update your list?

Conditional rules based on port exposure are a solid start, but they can create blind spots. You're assuming the threat model for a scan on an open service port is uniformly lower, which isn't statistically sound. A scan on port 443 could be benign reconnaissance, or it could be the precursor to a targeted exploit against a specific web application vulnerability. By automatically downgrading that risk, you're introducing a filter bias that assumes all scans against open ports have equivalent intent.

A more rigorous approach is to incorporate scan velocity and destination context into that conditional logic. For instance, a single source IP scanning only ports 80 and 443 across your entire netblock might be downgraded. But that same IP performing a high-frequency scan of *only* port 443 across 50 of your IPs in five minutes should retain, or even increase, its risk score, as it indicates target selection beyond simple discovery.

Your point on the whitelist maintenance is the key flaw in any static list approach. The update frequency question is a trap - it's never frequent enough. We moved to a dynamic lookup that checks IPs against a reputation feed and only applies the whitelist discount if the IP has a high reputation score *and* the activity matches known research patterns, like full IPv4 scans.

This makes a lot of sense. The "scan velocity" idea clicks for me. If someone's hammering just one port across a bunch of our IPs, that really does feel more targeted.

But how do you practically build that velocity logic? Are you just counting events within a time window, or is there a smarter way to flag that pattern without creating another noisy threshold rule?

We ran a controlled benchmark comparing static whitelists to dynamic filtering. The static lists became stale too fast. Now we use a scheduled search that tags source IPs based on behavioral thresholds and updates a lookup table automatically.

For risk modifiers, we didn't just lower the base score for "Network Scan." We split it. Scans with low velocity and targeting only known-open ports get a score of 5. Scans with high velocity, multiple targets, or targeting non-standard ports retain the default score of 30. This required modifying the underlying correlation search to pipe results through a subsearch that checks our dynamic lookup and calculates velocity.

The logic for velocity is simple: events count by src_ip, dest_port over a 1hr sliding window. If the count exceeds 50 distinct destination IPs, it's flagged as high velocity. It's a threshold rule, but it's applied dynamically in the risk rule, not as a separate alert.

You're absolutely right, that generic "refine your rules" advice is useless. It's like telling someone to "just be happy."

We had the same pain. We didn't just lower the risk score for "Network Scan Detected," we created two separate risk rules from it. One for "Low-Velocity Common Port Scan" and another for "Aggressive or Unusual Port Scan." The key was basing the split on a combination of factors that others have mentioned:

* Destination port (is it 443/80 vs. 3389/22?)
* Scan velocity (events per hour from the source)
* The target IP (was it scanned once, or is it part of a sweep?)

The first rule gets a very low score, the second keeps the original high score. This required modifying the correlation search to include a subsearch that calculated the velocity and checked ports, then assigned the correct risk rule. It cut our "Christmas tree" alerts by about 70%.

For whitelists, we automated it. A nightly scheduled search tags IPs that only ever hit our known-open ports at low frequency and adds them to a dynamic lookup. Manual lists for research nets just couldn't keep up.

Splitting the original risk rule into two is such a clean fix, I love that. Your 70% reduction is huge.

One caveat we found: sometimes the nightly lookup for whitelisting would catch a scanner's "quiet" phase, and then its aggressive sweep later would get a lower score because the IP was already tagged. We added a decay factor to our dynamic list, where entries expire after 7 days unless the low-velocity behavior is seen again. That kept our automation from being too trusting.

Decay factor's smart. Our TTL is 24 hours. Found 7 days let too many scanners slip through a "good behavior" window. They'd do a quiet probe, get listed, then unleash the full scan 3 days later while still whitelisted.

Your approach assumes scanner patterns are slow-moving. In our logs, the aggressive ones switch tactics within hours, not days. Short TTL catches that.

Thanks for asking that. The velocity logic can feel a bit clunky at first. We basically used a scheduled search that groups by source IP and destination port, then counts events over a sliding one hour window. It's just counting events within that time window, but the key was comparing it to a baseline of normal background noise for our own network.

A threshold rule on its own will get noisy, you're right. To make it smarter, we added a second check: does this pattern target multiple destination IPs? If a source is hitting that event count but only against one of our IPs, we treat it differently than if it's sweeping across dozens. That helped separate the targeted poking from the full-on carpet scans. How are you thinking of handling the destination context?

The port-based conditional rule you built is a great starting point. It mirrors how we first filtered our own dashboard.

Regarding your whitelist update question, I found a weekly cadence to be a bare minimum. Even then, we saw issues with ranges being repurposed for malicious activity, which is why we eventually moved to a dynamic system. Static lists require constant vigilance.

One caveat with your approach: lowering the score only for scans on open ports assumes your security posture on those ports is perfect. A scan on port 443 could be the prelude to a targeted attack on a specific web app vulnerability. We paired our port check with a velocity filter to catch that.

You've hit on a key operational variable. The optimal TTL is entirely dependent on your environment's typical attack tempo, which isn't universal. A 24-hour decay aligns with what we observed for internet-facing VPCs, but for our internal segmented networks, a 72-hour window proved more effective because internal recon is often slower and more sporadic.

This is why we parameterized the decay period in our automation, allowing it to be tuned per network zone. A fixed global TTL, whether 7 days or 24 hours, will inevitably be wrong for some segment of your infrastructure.

Have you considered tying the decay not just to time, but to the volume of *other* suspicious activity from the same IP? An IP that triggers a separate, high-fidelity alert could have its "benign" tag purged immediately.

Parameterizing the decay period sounds like another moving part that needs babysitting. You're just trading one manual process for another.

Tying it to other activity is the right instinct, but now you're layering conditions on a whitelist. At that point, is it even a whitelist anymore, or just another correlation rule?

That's exactly why we stopped whitelisting by IP at all. It's a maintenance trap. Instead we focused on making the detection itself smarter.

We lowered the base score for scans targeting only port 80 and 443, but only if the source IP had no other alerts attached to it in the last 48 hours. It cut our dashboard noise in half without a list to update.

Does your correlation search for the scan rule look at the broader alert history for the source, or just the isolated event?

Dropping the risk score for "Network Scan Detected from External Source" into the basement is tempting, but it just moves the problem from the dashboard to the risk index. You'll miss the real threat when it's buried under a mountain of suppressed false positives.

What worked for us was keeping the base risk rule but adding conditional modifiers that require zero-sum logic. The scan event gets its base score, but then we subtract points based on context. A scan hitting only ports 80/443? That's minus 15. Source IP hasn't triggered any other alert in the last 48 hours? Minus another 10. The score plummets for the obvious background noise, but an aggressive multi-port scan or a source with other suspicious activity still surfaces.

As for whitelists, we gave up on maintaining a static lookup of "benign" scanners. It's a full-time job and you'll always be 48 hours behind the next research project's new IP block. We treat low-score events as implicit whitelisting for a sliding 24-hour window. If the same source doesn't do anything more interesting in that time, the entry decays.

Completely agree that the generic advice to "refine risk rules" is useless. We moved the needle by building a context engine that sits upstream of the risk framework, filtering before events are scored.

The specific filter that cut our dashboard noise by 60% works on the `Network_Traffic` model. It's not a simple whitelist. It's a scheduled search that tags source IPs with an attribute like `benign_scanner_pattern` if they meet all of these criteria in a 2-hour window: target only ports 80/443, have a request velocity below a threshold (we use 200 events), and target more than five of our external IPs. Events from tagged IPs are then routed to a separate, low-priority risk rule with a negligible score.

Maintaining a static lookup for known benign scanners became unsustainable. We replaced it with the above automation, but we seed it with a very small, static list of research ranges (like Project Sonar) that we review quarterly. The key was accepting that any IP can turn malicious, so the `benign_scanner_pattern` tag has a hard expiration of 8 hours and is revoked immediately if the source triggers any other alert.