Palo Alto Firewall Audit

PAN-OS Firewall Security Policy Audit

Policy-audit-driven analysis of Palo Alto Networks PAN-OS security policies. Unlike generic firewall checklists that check for open ports and default-deny, this skill evaluates the PAN-OS-specific security architecture: zone-based segmentation, the App-ID identification chain, Security Profile Group binding coverage, and policy evaluation order.

Covers PAN-OS 10.x+ on PA-series hardware and VM-series virtual firewalls. For Panorama-managed deployments, the audit addresses device group hierarchy and pre/post-rule evaluation. Reference references/policy-model.md for the full packet evaluation chain and references/cli-reference.md for read-only CLI and API commands.

When to Use

Prerequisites

Procedure

Follow this audit flow sequentially. Each step builds on prior findings. The procedure moves from architecture inventory through rule-level analysis to profile and protection validation.

Step 1: Zone Architecture Inventory

Collect all security zones and their assignments.

show running zone

Record each zone: name, type (L3/L2/V-Wire/Tap/Tunnel), assigned interfaces, and zone protection profile. Count inter-zone security policy rules per zone pair. Identify zones with no protection profile assigned — these lack flood, reconnaissance, and packet-based attack protection.

Check the zone protection profile configuration for each active zone:

show running zone-protection-profile

Flag any L3 zone without a zone protection profile as a finding.

Step 2: Security Policy Rule-by-Rule Analysis

Retrieve the full security rulebase:

show running security-policy

For Panorama-managed devices, rules evaluate in this order: pre-rules → local rules → post-rules. Evaluate each rule against these criteria:

Use test security-policy-match to validate specific traffic scenarios:

test security-policy-match source  destination  protocol  application  destination-port  from  to 

Step 3: App-ID Coverage Assessment

Quantify App-ID adoption across the rulebase.

Count rules using application any versus rules with specific App-IDs. Calculate the ratio — mature deployments target >80% of allow rules using named App-IDs rather than application any.

Verify App-ID signature currency:

show system info

Check app-version and app-release-date. Signatures older than 7 days indicate update failures. App-ID accuracy depends on current signatures.

For rules still using application any, check if they also restrict by service (port/protocol). Rules with application any + service any are the highest-risk combination — they permit all applications on all ports.

Step 4: Security Profile Group Validation

Verify threat inspection coverage on traffic-allowing rules.

show running profile-group

A complete Security Profile Group includes: Antivirus, Anti-Spyware, Vulnerability Protection, URL Filtering, File Blocking, and WildFire Analysis. Optionally, Data Filtering for DLP.

For each allow rule, check profile-setting:

Validate that the profile group used on internet-facing rules includes WildFire Analysis for zero-day protection. Internal-only rules may use a lighter profile group, but should still include Anti-Spyware at minimum.

Step 5: Zone Protection Profile Audit

Evaluate zone-level protections independently from security policy.

Zone Protection Profiles defend against volumetric and packet-based attacks at the zone ingress point, before security policy evaluation.

Check each zone's protection profile for:

Step 6: Decryption Policy Review

Evaluate SSL/TLS decryption coverage.

show running ssl-decryption-policy

Without decryption, Security Profiles cannot inspect encrypted traffic — threat inspection is limited to connection metadata. Check:

Threshold Tables

Policy Rule Severity Classification

| Finding | Severity | Rationale | |---------|----------|-----------| | application any + action allow + service any | Critical | Permits all applications on all ports — no App-ID or port restriction | | application any + action allow (specific service) | High | Bypasses App-ID on specified ports — permits any application on those ports | | Allow rule without Security Profile Group | High | Traffic passes without AV, anti-spyware, or vulnerability inspection | | Allow rule with incomplete profile group (missing WF/URL) | Medium | Partial inspection — zero-day and URL threats uninspected | | Disabled rule in production rulebase | Medium | Audit confusion; cleanup recommended | | Shadowed rule (never matches) | Medium | Dead configuration; remove or reorder | | Zone without zone protection profile | High | No flood, recon, or packet-based attack defense at zone boundary | | Decryption not enabled on internet-bound traffic | High | Encrypted traffic bypasses content inspection | | App-ID signatures >7 days old | Medium | Application identification accuracy degraded | | Rule with any source and any destination | Medium | Overly broad scope — evaluate address narrowing |

App-ID Adoption Maturity

| App-ID Rule Ratio | Maturity | Guidance | |-------------------|----------|----------| | >80% named App-IDs | Mature | Maintain; review remaining any rules quarterly | | 50–80% named App-IDs | Developing | Prioritize high-traffic any rules for App-ID migration | | <50% named App-IDs | Immature | Systematic App-ID migration needed — begin with known applications |

Decision Trees

Overly Permissive Rule Remediation

Rule has application = any
├── Also service = any?
│   ├── Yes → CRITICAL: Fully open rule
│   │   ├── Is this a temporary migration rule?
│   │   │   ├── Yes → Set expiration date, add to migration tracker
│   │   │   └── No → Immediate remediation required
│   │   └── Identify actual applications via Traffic Log:
│   │       show log traffic rule equal 
│   │       → Replace with specific App-IDs + service
│   └── No (specific service)
│       └── HIGH: Port-restricted but App-ID bypassed
│           └── Identify applications on that port via ACC
│               → Replace application any with observed App-IDs
│
├── Security Profile Group bound?
│   ├── No → Add profile group BEFORE narrowing App-ID
│   │   └── Ensures threat visibility during migration
│   └── Yes → Proceed with App-ID migration
│
└── Rule disabled?
    ├── Yes → Schedule removal after change window
    └── No → Active rule, proceed with analysis above

Missing Security Profile Group Remediation

Allow rule without profile-setting
├── Traffic type?
│   ├── Internet-bound → Bind full SPG (AV+AS+VP+URL+FB+WF)
│   ├── Inter-zone internal → Bind standard SPG (AV+AS+VP minimum)
│   ├── Intrazone → Evaluate risk; bind AS+VP minimum
│   └── Management traffic → Bind AS+VP; URL/WF optional
│
├── Decrypted traffic?
│   ├── Yes → Full SPG effective; bind complete group
│   └── No → SPG limited to metadata inspection
│       └── Evaluate adding decryption first
│
└── Performance concern?
    ├── Session rate >100K/s → Use hardware-accelerated profiles
    └── Below threshold → Full SPG with default settings

Report Template

PAN-OS SECURITY POLICY AUDIT REPORT
=====================================
Device: [hostname]
PAN-OS Version: [version]
Platform: [PA-xxxx / VM-series]
Management: [standalone / Panorama device-group name]
Audit Date: [timestamp]
Performed By: [operator/agent]
ZONE ARCHITECTURE:
Zones configured: [count]
Zones with protection profiles: [n] / [total]
Zone pairs with security policy: [count]
POLICY SUMMARY:
Total security rules: [count]
Allow rules: [n] | Deny rules: [n] | Drop rules: [n]
Rules with Security Profile Groups: [n] / [allow count]
App-ID adoption: [n]% of allow rules use named App-IDs
FINDINGS:
1. [Severity] [Category] — [Description]
   Rule: [rule name]
   Zone Pair: [from-zone] → [to-zone]
   Issue: [specific problem]
   Current Config: [what the rule does now]
   Recommendation: [specific remediation]
DECRYPTION COVERAGE:
Zone pairs with SSL Forward Proxy: [list]
Estimated encrypted traffic inspected: [%]
Exclusion categories: [count]
APP-ID MATURITY:
Named App-ID rules: [n] / [total allow] ([%])
Top application-any rules by hit count: [list top 5]
RECOMMENDATIONS:
[Prioritized action list by severity]
NEXT AUDIT: [based on findings — CRITICAL findings: 30d, HIGH: 90d, clean: 180d]

Troubleshooting

Large Rulebases (>500 Rules)

Auditing large rulebases manually is impractical. Use the XML API to export the full policy as structured data for programmatic analysis: /api/?type=config&action=get&xpath=/config/devices/entry/vsys/entry/rulebase/security Parse the XML to automate shadow detection, profile coverage gaps, and App-ID ratio calculations. Prioritize by hit count — rules with zero hits in 90 days are cleanup candidates.

Panorama Shared vs Device-Group Policies

In Panorama-managed environments, rules exist at multiple levels: shared pre-rules → device-group pre-rules → local rules → device-group post-rules → shared post-rules. An audit must evaluate the effective rulebase on each managed firewall, not just the Panorama device group in isolation. Use show running security-policy on individual firewalls to see the merged effective policy.

Dynamic Address Groups

Rules referencing dynamic address groups (DAGs) with tag-based membership complicate audit — the effective scope changes as tagged objects are added/removed. Check current membership with show object dynamic-address-group all and note that findings may shift as membership changes. Document the DAG evaluation at audit time.

GlobalProtect and Captive Portal Zones

Traffic from GlobalProtect VPN users and Captive Portal-authenticated sessions may enter zones differently than standard interface traffic. Verify that security policies cover GP tunnel zones and that User-ID integration is functioning for identity-based rules.

Content Update Failures

If App-ID or Threat Prevention signatures are outdated, audit findings may not reflect current threat landscape. Verify update schedules: show system info | match content and show jobs processed. Resolve update failures before finalizing the audit report.

Large Rulebases (>500 Rules)

Auditing large rulebases manually is impractical. Use the XML API to export the full policy as structured data for programmatic analysis: /api/?type=config&action=get&xpath=/config/devices/entry/vsys/entry/rulebase/security Parse the XML to automate shadow detection, profile coverage gaps, and App-ID ratio calculations. Prioritize by hit count — rules with zero hits in 90 days are cleanup candidates.

Panorama Shared vs Device-Group Policies

In Panorama-managed environments, rules exist at multiple levels: shared pre-rules → device-group pre-rules → local rules → device-group post-rules → shared post-rules. An audit must evaluate the effective rulebase on each managed firewall, not just the Panorama device group in isolation. Use show running security-policy on individual firewalls to see the merged effective policy.

Dynamic Address Groups

Rules referencing dynamic address groups (DAGs) with tag-based membership complicate audit — the effective scope changes as tagged objects are added/removed. Check current membership with show object dynamic-address-group all and note that findings may shift as membership changes. Document the DAG evaluation at audit time.

GlobalProtect and Captive Portal Zones

Traffic from GlobalProtect VPN users and Captive Portal-authenticated sessions may enter zones differently than standard interface traffic. Verify that security policies cover GP tunnel zones and that User-ID integration is functioning for identity-based rules.

Content Update Failures

If App-ID or Threat Prevention signatures are outdated, audit findings may not reflect current threat landscape. Verify update schedules: show system info | match content and show jobs processed. Resolve update failures before finalizing the audit report.