Just wrapped up a fresh Palo Alto deployment audit for a client. Found a few common gaps that are easy to miss in the initial setup rush.
I now run through this quick checklist every time. It's saved me (and clients) from headaches later. Focuses on the practical stuff beyond basic connectivity.
**My Post-Deploy Audit Points:**
* **Security Rules:**
* Clean up placeholder/`any` rules. Tag them for review.
* Verify app-id is used over port-based rules where possible.
* Check for rules with no logs enabled (why?!).
* **Profiles & Policies:**
* Confirm Vulnerability and Anti-Virus profiles are attached to allow rules.
* Verify URL Filtering is applied to outbound traffic, even if just in 'alert' mode for now.
* Spot-check that Decryption policies are applied correctly for internalcloud traffic.
* **Management & Logging:**
* Test HA failover *and* failback. Don't just assume.
* Confirm critical logs (threat, traffic, URL) are forwarding to your SIEM/collector.
* Check admin/service accounts – MFA enabled, least privilege applied?
* **Best Practices:**
* Validate DNS settings on the box itself (for URL cat. & updates).
* Review scheduled config backups – are they working, and where?
* Quick spot-check of Panorama push groups (if used) for consistency.
What would you add? I'm always tweaking this list. The goal is a secure, observable foundation before layering on complexity.
—jc
Test everything
Your point about verifying App-ID over port-based rules is crucial. I'd extend that to the reporting side - a common oversight I see is teams not building their operational dashboards around App-ID categories from the start. They get the policy right but then measure traffic volume by IP or port, which completely misses the value of the visibility they just configured.
On management accounts, I'd stress checking not just for MFA but for the integration points with your corporate directory. An often missed step is ensuring the admin role mappings from Active Directory or IdP groups are correctly scoped. A broad "admins" group getting superuser access because it was the quickest path during deployment is a typical find.
Finally, on HA, testing failback is an excellent call. I'd add that you should validate the config sync status and drift *after* the failback sequence completes. I've seen scenarios where devices rejoin the cluster but critical policy or object changes made on the active unit during the failure window don't fully synchronize, creating a subtle split-brain condition.
measure what matters
Your point about checking for rules with no logs enabled is a good catch. It's often an oversight from using a rulebase template where logging is disabled by default for "cleaner" reports, but it eliminates the ability to track initial connections or troubleshoot.
On DNS settings, I'd expand that to specifically validating the *order* of the DNS servers listed for the device services. If the primary is unreachable, the firewall will hang on resolution for PAN-DB, threat updates, and WildFire submissions until the timeout is reached, creating a silent performance lag. It's a simple thing but often configured with two internal resolvers without considering what happens if the first one is under load.
CPU cycles matter