Prisma Access Audit

Palo Alto Prisma Access SASE Audit

Cloud-delivered security posture audit for Palo Alto Prisma Access tenants. Unlike on-premises PAN-OS firewall audits that inspect a single device, this skill evaluates the distributed SASE fabric: security policies governing mobile users and remote network sites, GlobalProtect Cloud Service client configuration, threat prevention profiles applied across compute locations, service connection health to on-premises data centers, and decryption coverage across all traffic flows.

Covers Prisma Access managed through Strata Cloud Manager (SCM) and legacy Panorama Cloud Services plugin deployments. Reference references/api-reference.md for Strata Cloud Manager API endpoints, authentication flows, and response structures used throughout this audit.

When to Use

• Security policy review after SASE migration from on-premises firewalls to Prisma Access
• Mobile user policy gap analysis — verifying GlobalProtect users receive equivalent or stronger protection than on-premises
• Remote network branch security validation — ensuring IKE/IPSec tunnels enforce consistent policy across all sites
• Threat prevention profile coverage audit — confirming antivirus, anti-spyware, vulnerability protection, and WildFire are bound to all allow rules
• Service connection health assessment — validating connectivity and routing between Prisma Access and on-premises data centers
• GlobalProtect client compliance review — checking client versions, HIP enforcement, and always-on VPN configuration
• Strata Cloud Manager configuration drift detection — comparing running state against intended baseline
• Pre-upgrade baseline capture before Prisma Access infrastructure updates or GlobalProtect client rollouts

Prerequisites

• Prisma Access API credentials — either Strata Cloud Manager OAuth 2.0 client credentials (Service Account with TSG ID) or legacy Panorama Cloud Services plugin API key
• Understanding of mobile user region deployment — which compute locations serve which user populations and the expected geographic coverage
• Knowledge of remote network topology — site names, IKE peer addresses, expected tunnel counts, and bandwidth allocations per branch
• Documented security policy intent — which traffic categories to inspect, which applications to allow/deny, and expected Security Profile Group assignments per policy rule
• GlobalProtect client version requirements — minimum acceptable client version and HIP check thresholds for the organization
• Access to Cortex Data Lake for log correlation — verifying that policy enforcement matches expected behavior in traffic and threat logs

Procedure

Follow this audit flow sequentially. Each step builds on prior findings. The procedure moves from tenant-level infrastructure inventory through policy analysis per traffic type to logging and visibility validation.

Step 1: Tenant and Infrastructure Inventory

Authenticate to the Strata Cloud Manager API using OAuth 2.0 client credentials flow. See references/api-reference.md for the token endpoint and required parameters.

Retrieve tenant information and compute location status:

GET https://api.sase.paloaltonetworks.com/sse/config/v1/prisma-access-config
Authorization: Bearer <access_token>

Record the following:

• Tenant ID and TSG ID — confirm you are auditing the correct tenant
• Compute locations — list all active regions for mobile users and remote networks
• License tier — Prisma Access edition (Business, Business Premium, or Enterprise) determines available features
• Bandwidth allocation — total allocated bandwidth and per-region distribution

Enumerate mobile user regions and remote network sites:

GET https://api.sase.paloaltonetworks.com/sse/config/v1/mobile-users/regions
GET https://api.sase.paloaltonetworks.com/sse/config/v1/remote-networks

[Mobile Users] Count active compute locations and verify geographic coverage matches the organization's user distribution.

[Remote Networks] List all configured remote network sites, their IKE gateway addresses, and tunnel status. Flag any site showing tunnel-down state.

Step 2: Security Policy Audit (Mobile Users)

Retrieve security policies applied to GlobalProtect mobile users:

GET https://api.sase.paloaltonetworks.com/sse/config/v1/security-rules
  ?folder=Mobile Users

[Mobile Users] Evaluate each rule against these criteria:

• Overly permissive application: Rules with application: any combined with action: allow bypass App-ID identification entirely. Flag as Critical.
• Missing Security Profile Group: Allow rules without a bound Security Profile Group or individual profiles permit traffic without threat inspection. Check profile_setting on each rule.
• Source/destination scope: Rules using any for both source and destination address — evaluate whether address objects or address groups can narrow the scope.
• Service port usage: Rules using service: any instead of service: application-default — App-ID enforcement is strongest when applications are restricted to their standard ports.
• Rule ordering: Verify that deny/drop rules for known-bad categories precede broad allow rules. Misordered rules may permit traffic before a deny can evaluate.

Calculate the App-ID adoption ratio: count rules using specific App-IDs versus rules with application: any. Mature deployments target >80% named App-ID usage.

Step 3: Security Policy Audit (Remote Networks)

Retrieve security policies applied to remote network sites:

GET https://api.sase.paloaltonetworks.com/sse/config/v1/security-rules
  ?folder=Remote Networks

[Remote Networks] In addition to the rule-level checks in Step 2, evaluate:

• IKE/IPSec tunnel configuration: Verify encryption algorithms meet organizational standards (AES-256-GCM preferred, minimum AES-256-CBC). Check IKE version (IKEv2 required), DH group (minimum Group 14), and SA lifetime settings.

GET https://api.sase.paloaltonetworks.com/sse/config/v1/ike-gateways
GET https://api.sase.paloaltonetworks.com/sse/config/v1/ipsec-tunnels

• Routing validation: Check BGP or static route configuration per site. For BGP, verify peer ASN, advertised prefixes, and route filters. For static routes, confirm next-hop reachability and subnet accuracy.

GET https://api.sase.paloaltonetworks.com/sse/config/v1/bgp-routing

• Split-tunnel vs full-tunnel posture: Determine whether branch traffic is fully tunneled through Prisma Access (recommended for consistent inspection) or split-tunneled with direct internet breakout. Split-tunnel configurations must ensure local breakout traffic still traverses a security policy.

• Bandwidth allocation: Verify per-site bandwidth allocation matches actual usage. Sites consistently exceeding allocation experience packet drops or degraded performance.

Step 4: Threat Prevention Profile Assessment

Retrieve all Security Profile Groups and individual profiles:

GET https://api.sase.paloaltonetworks.com/sse/config/v1/security-profile-groups
GET https://api.sase.paloaltonetworks.com/sse/config/v1/anti-spyware-profiles
GET https://api.sase.paloaltonetworks.com/sse/config/v1/vulnerability-protection-profiles
GET https://api.sase.paloaltonetworks.com/sse/config/v1/wildfire-anti-virus-profiles

Evaluate each profile type:

• Antivirus profile: Verify action is set to reset-both or drop for all decoders (HTTP, SMTP, IMAP, POP3, FTP, SMB). Default profiles using alert only are insufficient — flag as High finding.
• Anti-Spyware profile: Check that DNS sinkhole is enabled, botnet domains are blocked, and spyware severity levels critical/high/medium are set to reset-both or drop.
• Vulnerability Protection profile: Verify that critical and high severity signatures use reset-both action. Default profile uses alert for informational — acceptable. Check for custom exceptions that weaken protection.
• WildFire profile: Confirm all file types (PE, APK, Mac OS X, ELF, PDF, MS Office, JAR, Flash, Linux pkg) are forwarded to WildFire for analysis. Verify WildFire verdict actions block malicious and grayware.
• File Blocking profile: Validate that high-risk file types (EXE, DLL, BAT, SCR, MSI) are blocked on relevant protocols.

[Mobile Users] [Remote Networks] Verify that all allow rules in both folders reference a Security Profile Group containing the above profiles. Rules without profile binding pass traffic uninspected.

Step 5: URL Filtering and DNS Security

Review URL Filtering and DNS Security configurations:

GET https://api.sase.paloaltonetworks.com/sse/config/v1/url-filtering-profiles
GET https://api.sase.paloaltonetworks.com/sse/config/v1/dns-security-profiles

• URL Filtering categories: Verify that high-risk categories (malware, phishing, command-and-control, grayware, newly-registered-domain) are set to block. Check that the Advanced URL Filtering license is active for inline ML-based analysis of unknown URLs.
• Custom URL categories: Review any custom URL categories for appropriateness — overly broad allow-list categories can bypass security.
• DNS Security: Confirm DNS Security policy is applied and that DNS-layer threat categories (DGA, DNS tunneling, newly seen domains) are set to sinkhole or block.
• CASB / SaaS Security: If licensed, verify that SaaS application visibility and inline controls are configured. Check for sanctioned vs unsanctioned SaaS application policies.

Step 6: GlobalProtect Client Configuration

[Mobile Users] Review GlobalProtect Cloud Service configuration:

GET https://api.sase.paloaltonetworks.com/sse/config/v1/mobile-agent/global-settings
GET https://api.sase.paloaltonetworks.com/sse/config/v1/hip-profiles
GET https://api.sase.paloaltonetworks.com/sse/config/v1/hip-objects

Evaluate the following:

• Client version currency: Check minimum supported client version against the currently deployed versions across the user population. Clients older than the current major release minus one are a compliance risk. Query Prisma Access Insights for version distribution.
• Split-tunnel configuration: Verify whether the GlobalProtect portal configuration uses full-tunnel (all traffic through Prisma Access) or split-tunnel (specified apps/domains bypass the tunnel). Full-tunnel is recommended for consistent security inspection.
• HIP (Host Information Profile) checks: Verify that HIP objects check for minimum OS patch level, disk encryption status, antivirus presence and currency, host firewall state, and certificate validity. HIP profiles should enforce compliance gates — non-compliant devices receive restricted access.
• Pre-logon tunnel: Check whether a pre-logon tunnel is configured for machine-level authentication before user login. Required for environments needing machine certificate-based access.
• Always-on VPN enforcement: Verify that the GlobalProtect configuration enforces always-on VPN with no user-disable option. Check for disable- override password protection.
• Authentication method: Review SAML, certificate, or LDAP/Kerberos authentication. SAML with MFA is recommended for mobile users.

Step 7: Service Connection Validation

[Service Connections] Verify connectivity between Prisma Access and on-premises data centers:

GET https://api.sase.paloaltonetworks.com/sse/config/v1/service-connections

Evaluate each service connection:

• Tunnel status: Verify IKE/IPSec tunnel is established and has been stable (no recent flaps). Check tunnel uptime and last state change.
• Routing advertisements: Confirm that on-premises routes are correctly advertised to Prisma Access via BGP. Verify that Prisma Access is advertising the expected mobile user and remote network subnets back to on-premises.
• Bandwidth allocation: Check allocated bandwidth versus utilization. Service connections nearing capacity cause traffic drops for mobile users accessing on-premises resources.
• QoS configuration: If QoS is configured, verify traffic classification and bandwidth guarantees align with business application priority.
• Redundancy: Verify that primary and secondary service connections exist for each data center. Single service connections are a single point of failure. Check failover behavior — active/passive or active/active.

Step 8: Decryption Policy Review

Evaluate SSL/TLS decryption coverage across the Prisma Access tenant:

GET https://api.sase.paloaltonetworks.com/sse/config/v1/decryption-rules
  ?folder=Mobile Users
GET https://api.sase.paloaltonetworks.com/sse/config/v1/decryption-rules
  ?folder=Remote Networks

[Mobile Users] [Remote Networks] Check decryption configuration:

• Decryption rule coverage: Identify which traffic flows are decrypted (SSL Forward Proxy) and which bypass decryption. Internet-bound traffic from all user and branch sources should be decrypted for full threat inspection.
• Decryption exclusions: Review technical exclusions (certificate pinning, client certificate mutual TLS) and compliance exclusions (financial, healthcare categories). Verify exclusion lists are minimal and documented with justification.
• Certificate chain: Validate that the forward trust CA certificate is properly distributed to all endpoints. Mobile user devices must trust the decryption CA to avoid certificate errors. Check certificate expiration.
• TLS version enforcement: Verify that TLS 1.0 and 1.1 are blocked or decrypted with alerts. Only TLS 1.2 and 1.3 should be permitted without findings.
• Performance impact: For remote network sites with limited bandwidth, assess whether decryption processing introduces latency. Check Prisma Access Insights for decryption-related performance metrics.

Step 9: Logging and Visibility

Verify log forwarding and monitoring configuration:

GET https://api.sase.paloaltonetworks.com/sse/config/v1/log-forwarding-profiles

• Cortex Data Lake forwarding: Confirm that all log types (traffic, threat, URL, data, WildFire, authentication, HIP match, decryption) are forwarded to Cortex Data Lake. Missing log types create visibility gaps.
• Log retention: Verify Cortex Data Lake storage allocation and retention periods meet compliance requirements. Check for capacity warnings.
• Autonomous DEM (Digital Experience Monitoring): If licensed, verify that Autonomous DEM is enabled for mobile users. Check that application performance monitoring targets are configured for critical SaaS applications (Microsoft 365, Salesforce, ServiceNow, etc.).
• External SIEM forwarding: If logs are forwarded to an external SIEM, verify syslog or HTTPS forwarding is functional and that log ingestion rates match expected volume.
• Alert configuration: Check for configured alerts on critical events — tunnel down, license expiration, compute location capacity, high threat volume.

Threshold Tables

Security Policy Coverage

Threat Prevention Profile Strength

GlobalProtect Client Compliance

Service Connection Health

Decryption Coverage

Decision Trees

Mobile User Policy Gap Prioritization

Mobile User allow rule identified
├── Has Security Profile Group?
│   ├── No → HIGH: Add SPG immediately
│   │   └── Traffic type?
│   │       ├── Internet-bound → Bind full SPG (AV+AS+VP+URL+WF+FB)
│   │       ├── Access to on-prem via service connection → Standard SPG (AV+AS+VP)
│   │       └── SaaS direct access → Full SPG + URL Filtering + CASB
│   └── Yes → Check SPG completeness
│       ├── Missing WildFire → Medium: Add WF profile for zero-day coverage
│       ├── Missing URL Filtering → Medium: Add URL for web threat protection
│       └── All profiles present → OK
│
├── Application = any?
│   ├── Yes + Service = any → CRITICAL: Fully open rule
│   │   └── Review Prisma Access Insights traffic logs for actual app usage
│   │       → Replace with specific App-IDs
│   ├── Yes + Service = specific port → HIGH: App-ID bypass on port
│   │   └── Identify applications on that port from traffic logs
│   │       → Replace with named App-IDs + application-default
│   └── Named App-IDs → OK
│
├── Decrypted?
│   ├── No → SPG inspection limited to metadata
│   │   └── Add decryption rule for this traffic flow
│   └── Yes → Full inspection effective
│
└── HIP-enforced?
    ├── No → Evaluate adding HIP profile for device compliance
    └── Yes → Verify HIP checks match organizational policy

Remote Network Security Posture Remediation

Remote network site identified
├── Tunnel status?
│   ├── Down → CRITICAL: Restore connectivity
│   │   ├── Check IKE Phase 1 (peer IP, pre-shared key, proposals)
│   │   ├── Check IKE Phase 2 (proxy IDs, encryption mismatch)
│   │   └── Verify on-prem firewall allows IKE/NAT-T (UDP 500/4500)
│   ├── Flapping → HIGH: Investigate stability
│   │   ├── Check DPD (Dead Peer Detection) settings
│   │   ├── Review ISP stability at branch site
│   │   └── Verify SA lifetime alignment between peers
│   └── Stable → Continue to policy audit
│
├── Encryption strength?
│   ├── Below minimum (3DES, DH Group 2/5) → HIGH: Upgrade proposals
│   │   └── Target: AES-256-GCM, IKEv2, DH Group 19/20
│   └── Meets standard → OK
│
├── Routing correct?
│   ├── BGP: Missing expected prefixes → Verify route filters and advertisements
│   ├── Static: Incorrect next-hop → Correct route configuration
│   └── Routes present and accurate → OK
│
├── Split-tunnel or full-tunnel?
│   ├── Split-tunnel without local security → HIGH: Risk of uninspected traffic
│   │   └── Migrate to full-tunnel or add local security stack
│   └── Full-tunnel or split with local inspection → OK
│
└── Bandwidth adequate?
    ├── >90% utilization → WARNING: Upgrade allocation
    ├── 70-90% utilization → Monitor trend
    └── <70% → OK

Threat Prevention Profile Strengthening Path

Threat prevention profile audit
├── Using default (best-practice) profiles?
│   ├── Yes → Acceptable baseline
│   │   └── Review for organizational customization needs
│   └── No → Custom profiles exist
│       ├── Weaker than defaults? → FINDING: Strengthen to match or exceed
│       └── Stronger than defaults? → OK, document customizations
│
├── Antivirus profile
│   ├── Any decoder set to alert-only? → HIGH: Change to reset-both
│   └── All decoders reset-both/drop → OK
│
├── Anti-Spyware profile
│   ├── DNS sinkhole disabled? → HIGH: Enable immediately
│   ├── Critical/high severity = alert? → HIGH: Change to reset-both
│   └── Properly configured → OK
│
├── Vulnerability Protection profile
│   ├── Custom exceptions reducing coverage? → Review each exception
│   │   └── Exception still required? → Document justification
│   │       └── No longer needed → Remove exception
│   └── Standard severity actions → OK
│
└── WildFire profile
    ├── File types not forwarded? → Medium: Add missing file types
    ├── Verdict action = alert for malicious? → HIGH: Change to drop
    └── Full coverage, block malicious → OK

Report Template

PRISMA ACCESS SASE AUDIT REPORT
=================================
Tenant: [tenant name]
Tenant ID: [tenant ID]
TSG ID: [TSG ID]
Prisma Access Edition: [Business / Business Premium / Enterprise]
Audit Date: [timestamp]
Performed By: [operator/agent]

INFRASTRUCTURE OVERVIEW:
- Compute locations (Mobile Users): [count] — [region list]
- Remote network sites: [count] — [site list]
- Service connections: [count] — [data center list]
- Total bandwidth allocation: [Mbps]
- Strata Cloud Manager version: [version]

MOBILE USER FINDINGS:
- Total security rules (Mobile Users folder): [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
- GlobalProtect client compliance: [n]% on current version
- HIP compliance rate: [n]%

  Findings:
  1. [Severity] [Category] — [Description]
     Rule: [rule name]
     Folder: Mobile Users
     Issue: [specific problem]
     Recommendation: [specific remediation]

REMOTE NETWORK FINDINGS:
- Total remote network sites: [count]
- Sites with tunnel up: [n] / [total]
- Sites with full-tunnel posture: [n] / [total]
- Security rules (Remote Networks folder): [count]
- Rules with Security Profile Groups: [n] / [allow count] ([%])

  Findings:
  1. [Severity] [Category] — [Description]
     Site: [site name]
     Issue: [specific problem — tunnel, routing, policy, or encryption]
     Recommendation: [specific remediation]

THREAT PREVENTION ASSESSMENT:
- Security Profile Groups configured: [count]
- Antivirus profiles: [count] — [strength assessment]
- Anti-Spyware profiles: [count] — DNS sinkhole: [enabled/disabled]
- Vulnerability Protection profiles: [count] — [custom exceptions count]
- WildFire profiles: [count] — file types forwarded: [list]
- URL Filtering: Advanced URL Filtering license: [active/inactive]
- DNS Security: [configured/not configured]

  Findings:
  1. [Severity] [Profile Type] — [Description]
     Profile: [profile name]
     Issue: [specific weakness]
     Recommendation: [specific remediation]

DECRYPTION COVERAGE:
- Mobile User decryption rules: [count]
- Remote Network decryption rules: [count]
- Estimated sessions decrypted: [%]
- Decryption exclusions: [count categories/domains]
- Forward trust CA expiry: [date]
- TLS 1.0/1.1 handling: [blocked/allowed/decrypted]

  Findings:
  1. [Severity] — [Description]
     Scope: [Mobile Users / Remote Networks / Both]
     Issue: [specific gap]
     Recommendation: [specific remediation]

SERVICE CONNECTION STATUS:
- Service connections: [count]
- All tunnels up: [yes/no]
- Redundancy: [all redundant / gaps identified]
- Bandwidth utilization: [average %]

  Findings:
  1. [Severity] — [Description]
     Connection: [service connection name]
     Issue: [tunnel, routing, bandwidth, or redundancy]
     Recommendation: [specific remediation]

SEVERITY SUMMARY:
- Critical: [count]
- High: [count]
- Medium: [count]
- Low / Informational: [count]

REMEDIATION ROADMAP:
Phase 1 (Immediate — 0-7 days):
  - [Critical findings requiring immediate action]

Phase 2 (Short-term — 7-30 days):
  - [High findings and quick wins]

Phase 3 (Medium-term — 30-90 days):
  - [Medium findings, profile hardening, App-ID migration]

Phase 4 (Ongoing):
  - [Continuous monitoring, quarterly re-audit, policy lifecycle]

NEXT AUDIT: [based on findings — CRITICAL: 30d, HIGH: 90d, clean: 180d]

Troubleshooting

API Authentication — Strata Cloud Manager vs Legacy

Strata Cloud Manager uses OAuth 2.0 client credentials flow. Authenticate with a Service Account bound to a Tenant Service Group (TSG) ID. The token endpoint is https://auth.apps.paloaltonetworks.com/oauth2/access_token. Common authentication failures:

• Invalid TSG ID: The scope parameter must include tsg_id:<your_tsg_id>. Omitting this or using an incorrect TSG ID returns a 401 error.
• Expired client secret: Service Account secrets have configurable expiration. Regenerate via Strata Cloud Manager > Identity & Access.
• Insufficient role: The Service Account must have at minimum the Auditor or View-Only Administrator role to read configuration.

Legacy Panorama Cloud Services plugin API uses an API key generated from Panorama. If the organization has migrated to Strata Cloud Manager, the legacy API may return stale configuration. Always confirm which management plane is authoritative.

Compute Location Capacity

Prisma Access compute locations can reach capacity during peak usage. If mobile user connections are refused or performance degrades:

• Check compute location utilization via Prisma Access Insights or the Autonomous DEM dashboard.
• Verify that mobile user regions are distributed geographically to balance load — avoid funneling all users through a single region.
• Review bandwidth allocation per compute location. Insufficient allocation triggers throttling before true capacity is reached.

GlobalProtect Client Compatibility

GlobalProtect client compatibility issues commonly arise from:

• Version mismatch: Cloud-delivered GlobalProtect infrastructure updates independently from client software. Clients more than two major versions behind may fail to connect or lose feature support. Check the Prisma Access compatibility matrix.
• OS-specific issues: macOS system extension requirements (Network Extension vs Kernel Extension) change across OS versions. Windows clients may conflict with third-party VPN or endpoint security software.
• MDM-deployed configuration: Mobile Device Management-pushed profiles may override portal-delivered settings. Verify MDM configuration aligns with portal/gateway settings.

Service Connection BGP Flapping

BGP session instability on service connections typically results from:

• Hold timer mismatch: Prisma Access uses a default BGP hold time of 90 seconds. If the on-premises peer uses a shorter hold time and keepalives are lost due to congestion, the session drops. Align timers.
• Route oscillation: If the on-premises router advertises and withdraws routes rapidly, Prisma Access BGP will follow. Check on-premises routing stability first.
• MTU issues: Path MTU mismatches cause TCP session failures that can affect BGP. Verify MTU along the service connection path — typical IPSec overhead requires reducing MTU to 1400 or lower.
• IKE DPD sensitivity: Aggressive Dead Peer Detection settings combined with transient packet loss cause unnecessary tunnel rebuilds. Use a DPD interval of 10 seconds with a retry of 3 as a baseline.

Decryption Certificate Distribution

SSL Forward Proxy decryption requires endpoints to trust the Prisma Access forward trust CA certificate. Distribution challenges include:

• Mobile users: Push the CA certificate via MDM, GPO, or GlobalProtect client configuration. Verify distribution by checking certificate store on sample devices.
• Remote network endpoints: Branch devices behind remote network tunnels must also trust the CA. If branch users access the internet via Prisma Access, their devices need the certificate.
• Certificate expiration: Monitor forward trust CA certificate expiration. Prisma Access generates certificates with configurable lifetimes — set calendar reminders for renewal. An expired CA causes all decrypted sessions to fail with certificate errors.
• Certificate pinning applications: Applications that pin their server certificates (banking apps, certain healthcare portals) will fail through SSL Forward Proxy. Add these to the decryption exclusion list with documented justification.