Filtering out entire geolocations for SaaS noise is clever, I hadn't thought of that. Do you ever run into issues with legitimate traffic from an employee traveling, though? Like, if someone on a trip connects to Office 365 from outside your usual countries, does that get filtered out and missed?
Absolutely agree, and that's the perfect way to put it - a "comforting mirage" is exactly right. My team got a real wake-up call when we were only checking blocked threats.
We found our first real incident by doing exactly what you said: focusing on allowed outbound connections. A marketing laptop was beaconing out to a new IP every 90 minutes, but because the traffic volume was tiny and it wasn't blocked, it never hit a single pre-built dashboard. The only reason we caught it was a weekly manual scan of connections sorted by unique destination count.
It really does shift your whole mindset from "what did we stop?" to "what did we allow, and why?"
test everything twice
The built-in "Top Threats" dashboard is indeed insufficient, as several people have noted. For a daily review, I'd actually recommend skipping it entirely at first and focusing on a single log view: the raw connection logs filtered for "allowed" traffic, sorted by destination port. Look for internal hosts initiating connections to unusual high ports (> 1024) on external IPs. This often catches C2 traffic that uses non-standard ports for egress before the threat engine even gets a chance to flag it.
For weekly reporting, don't just schedule the canned compliance PDFs. Build a custom report that tracks two things: the total number of unique external IPs contacted per internal subnet, and the 95th percentile latency for DNS queries from each subnet. A sudden increase in the former or a jump in the latter can indicate malware establishing new connections or performing DNS tunneling, respectively. These are operational metrics that compliance templates never include, but they provide a far more actionable early warning signal.
You can pull the DNS latency data from the firewall's application logs if you're logging DNS traffic, or correlate it with your internal DNS resolver. The key is to establish a baseline for what "normal" looks like so deviations stand out.
Your daily review process is sound, and I particularly agree on the necessity of correlating the "Top Attacks" list with raw logs for those IPs. We've found that step critical for identifying low-and-slow reconnaissance that occurs just below the threshold of an automatic block.
One caveat on tracking "unique external destinations" from a workstation. In environments with modern web applications, a single user session can trigger connections to dozens of CDN endpoints. We had to refine that metric by excluding destinations from major cloud provider ASNs, otherwise we were drowning in false positives from normal SaaS use.
The real challenge is maintaining that manual verification step against aggregated logs long-term. Teams get compliance fatigue and start rubber-stamping those auto-generated PDFs. The most effective setup I've seen builds this verification into a weekly operational checklist, making it a non-negotiable process rather than an ad-hoc review.
Agreed on the baseline for allowed outbound. Most teams baseline the bad stuff and miss the quiet exfil. The SonicWall cloud analyzer data retention is, frankly, a joke for any real trend analysis. You'll lose the historical context you need. That forces you into a SIEM, which then creates the new problem of managing yet another log sink with its own cost and complexity.
Your last point about manual verification is the real bottleneck. You can build all the dashboards you want, but if your team is stuck maintaining IP allowlists or chasing cloud IP ranges, they'll stop looking. The most effective monitoring setup is the one people actually use.