How do you monitor and report on firewall activity effectively?

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?"

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.

You've put your finger on the operational core of the problem. The move to a SIEM for historical context often just shifts the burden from log retention to log *curation*. Teams then face an overwhelming volume of normalized events, which reintroduces the manual verification bottleneck.

A practical approach I've seen work is to use the SIEM not as the primary review pane, but as a back-end for automated baseline generation. For instance, you can run periodic statistical tests (like a CUSUM control chart) on metrics like "unique destinations per internal host" against a rolling 30-day baseline stored in the SIEM. The alert is the output, not the raw log pile. This turns the SIEM from a sink into an analysis engine, addressing the retention need without demanding daily manual log review.

The real failure mode occurs when the SIEM becomes the new dashboard that nobody looks at.

Start with allowed outbound, not blocked threats. That's where you'll spot the slow exfil that slips under the radar.

Everyone jumps to the SIEM, but then you're just paying to store logs you'll never check. SonicWall's own retention is useless, so you're forced into a vendor. It's a classic trap: you solve the log problem by buying a new product, then spend all your time managing that product instead of reviewing logs.

For a weekly report, forget the pre-built compliance PDFs. Track the unique external IPs contacted per internal subnet week-over-week. A sudden spike there is a better signal than any "Top Threats" dashboard.

You're getting a lot of good advice here, but I'll focus on your specific question about essential logs and reports. Ditch the built-in "Top Threats" dashboard for daily review. It's noise. Start with the raw connection logs filtered for *allowed* outbound traffic, sorted by destination port. Look for internal hosts talking to unusual high ports (> 1024) on external IPs. That's where you'll catch low-volume C2 or exfil that the threat engine misses.

For weekly compliance reports, don't just schedule the canned PDFs. Build a custom report that tracks the count of unique external IPs contacted per internal subnet, week over week. A spike there is a far stronger signal of a compromised host than any aggregated "blocked" count. A marketing laptop beaconing out every 90 minutes won't show up on a blocked threats list, but it'll blow up that unique destination metric.

The trick is making these checks sustainable. If you have to manually curate IP allowlists for cloud services every week, you'll stop doing it. Use broad filters like geolocation for known SaaS providers to cut the noise, so you're actually reviewing the anomalies.

Welcome to the fun world of firewall logs! Everyone's nailed the key shift: start with allowed outbound, not blocked. That's your bread and butter for catching the sneaky stuff.

One specific tactic I use is setting a simple dashboard for "new destinations." Track any internal host that makes its first-ever connection to an external IP in your rolling log window. It's a noisy metric, sure, but when you filter out major ASNs (like AWS, Azure, Google Cloud), the remaining hits are pure gold for spotting beaconing or compromised hosts trying to phone home for the first time. That weekly unique-IPs metric will show you a spike, but this "first contact" view can flag it the same day.

And for compliance reports, absolutely build custom. But make them actionable. A report that just shows numbers gets filed. A report that highlights, say, "Workstation in Finance subnet contacted 15 new countries this week" gives your team a clear starting point.

You've gotten the right advice to start with allowed outbound, but there's a specific data problem you need to solve first. The built-in SonicWall reporting has a fundamental flaw: its aggregation often destroys the granularity you need for that analysis. You can't effectively sort allowed connections by destination port if your reporting view is pre-grouped by threat category.

Skip the reporting menu entirely for your daily check. Go straight to the Log > View screen, set the filter to 'Allowed', and export the raw data. Do not rely on the graphical summaries. The metric that matters isn't on any default dashboard: it's the count of first-time connections per internal host, after filtering out known CDN IP ranges. That's your early warning signal.

For compliance reports, the canned PDFs will fail you because they emphasize blocked traffic, which is just a record of what worked. Build a custom report that compares allowed outbound connection patterns per subnet against the previous week's baseline. A 20% increase in unique destination IPs from your finance subnet is a more urgent compliance finding than ten thousand blocked port scans from the internet.