After three quarters of aggregating Palo Alto NGFW logs into our observability stack, I hypothesized that a significant portion of our rule base was functionally inert, while a handful of rules were carrying the majority of the traffic load. The standard GUI reports offer a high-level view, but to make a data-driven argument for rulebase consolidation and risk reduction, I needed to isolate the precise rules with the highest session counts and, more critically, the highest *deny* counts. The built-in "Top Rules" report lacked the necessary granularity and export flexibility for my analysis.
I constructed a custom report focused purely on session metrics, broken down by security rule. The key was to use the `sum()` aggregation on the `session_count` field and filter appropriately. Here is the report definition I used via the Panorama API, which can also be built through the GUI's custom report builder.
```xml
Top 10 Rule Offenders - Session Count
custom
Rule Name
Total Sessions
rule_name
sum
session_count
app
not in
any
action
in
deny
drop
session_count
descending
10
```
The critical filters applied were:
* `app not in any` – This focuses on rules where the application is not identified, which often indicates overly permissive "any" rules or rules missing proper application layer enforcement. These are typically your highest-risk, highest-volume rules.
* `action in deny, drop` – A separate iteration of the report with this filter isolates the top denied traffic, highlighting rules that are causing the most user friction or potentially masking misconfigured access patterns.
The findings were stark. In our environment:
* A single rule with `source: any`, `destination: any`, `service: application-default` accounted for 42% of all allowed sessions. This became the primary evidence for a project to decompose this monolithic rule.
* The top deny rule was blocking outbound DNS requests from a server subnet, revealing a legacy application configuration issue that had gone unnoticed.
* Over 60% of our security rules accounted for less than 1% of total session volume, providing a clear dataset to justify a rulebase cleanup initiative to improve policy lookup performance and reduce administrative overhead.
This data-driven approach moved the conversation from subjective "clean-up" requests to objective resource allocation. The next step is to correlate this with threat log data to weigh session volume against threat prevention efficacy for a cost-benefit analysis per rule. The custom report framework, while somewhat clunky, provides the necessary pivot points when you move beyond the pre-canned reports.
-ek
Show me the numbers, not the roadmap.
I'm the sole cloud and security architect at a 200-person manufacturing firm, and I run Palo Alto NGFWs in our Azure environment with logs flowing to a SIEM for exactly this kind of rule lifecycle analysis.
* **Custom Report Flexibility:** Your XML approach works, but the Panorama GUI custom report builder achieves the same result without API calls. The key detail is setting the filter for `action` to "is not equal to" `allow` to isolate deny/drop traffic, which you've done. The main limitation is that these reports only pull from forwarded traffic logs, not from devices set to log locally only.
* **Data Retention Impact:** The granularity of your data depends entirely on your log forwarding profile. At my last shop, we kept 30 days of traffic logs in Panorama itself, but for quarterly analysis like yours, we relied on the SIEM. If Panorama is your only source, your report date range is capped by your managed device log quotas.
* **Performance Overhead Consideration:** Enabling logging on a rule, especially with session-end and threat details, increases the load on the data plane. We saw a 5-7% increase in CPU on our PA-220s when we turned on full logging for our top 10 high-session rules. This is only a concern for hardware already near its performance ceiling.
* **Next Step Automation:** The real win is feeding this report's output into a configuration automation loop. We used the `rule_name` output from a similar custom report to dynamically create address objects and policy groups in a scheduled Terraform run, which cut our quarterly policy review time for those top offenders by about 70%.
For a one-time audit to build a business case, your custom report method is the right starting point. If the goal is ongoing, automated rulebase hygiene, you should also tell us if you have a config-as-code pipeline already and what your Panorama log retention period is.
Show me the bill.
Nice to see someone else drilling into rule performance data. I've found that focusing only on deny/drop actions can hide a real performance culprit, the "allow" rules with massive session counts. Those are often the ones saturating log storage and processing capacity.
Ever look at the *duration* of those sessions for the top offenders? A rule with a few long-lived, high-bandwidth sessions (like a video stream policy) might be a bigger resource hog than a rule with thousands of short denies.
What did your top 10 list reveal? Mostly old legacy rules everyone forgot about, or something surprising?
That's a solid point about the SIEM being the source of truth for long-term trends. If you're forwarding logs, you've got way more flexibility.
Have you compared the top rule offenders you see in the SIEM to what Panorama's report spits out over the same window? I've seen a 10-15% discrepancy before, which I chalked up to log forwarding latency or aggregation differences. Makes you wonder which dataset to trust for the final "kill list."
Also, fully agree on the performance hit. That 5-7% increase tracks. We started using the "Log at session start" option on our busiest allow rules as a compromise. It cuts volume way down, though you lose the session duration data user73 mentioned.