Prisma Access: Implementation & Configuration

This document details the critical phases of implementing and configuring Prisma Access, covering planning, onboarding using both Panorama and Cloud Management, and the configuration of key security features like policies, NAT, decryption, and more.

Part 1: Planning and Design

Thorough planning and design are paramount for a successful Prisma Access deployment. Rushing this phase often leads to configuration challenges, performance issues, or security gaps later.

Network Assessment Prerequisites

• Current Topology Mapping: Document existing network segments, data centers, branch offices, user locations, and major application flows.
• Internet Egress Points: Identify current internet breakouts and associated security controls.
• Bandwidth Utilization: Analyze current bandwidth usage for internet traffic, VPN users, and site-to-site links. Identify peak usage patterns.
• Application Inventory: List critical internal and SaaS applications, their protocols, ports, and sensitivity.
• Existing Security Policies: Review current firewall rules, URL filtering categories, threat prevention profiles, and VPN configurations.
• Authentication Infrastructure: Document existing identity providers (e.g., Active Directory, Azure AD, Okta), user directories, and MFA solutions.
• Device Inventory: Understand the types and operating systems of devices that will connect (corporate managed vs BYOD).

IP Addressing Strategy

• Mobile User IP Pools: Allocate dedicated, non-overlapping private IP ranges (RFC1918 preferred) for mobile users connecting via GlobalProtect. Ensure pools are large enough for peak concurrency. Consider segmenting pools per region if needed. These pools MUST NOT overlap with any internal corporate subnets reachable via Service Connections or Remote Networks.
• Service Connection/Remote Network Subnets: Document all internal subnets that need to be reachable from Prisma Access. These will be advertised (typically via BGP) to Prisma Access.
• Prisma Access Infrastructure IPs: Be aware of the public IP ranges Palo Alto Networks uses for Prisma Access infrastructure (published in documentation). Ensure these are permitted through on-premises firewalls for tunnel establishment.
• Summarization Planning: Plan for route summarization where possible (especially for Service Connections) to minimize routing table size.

Authentication Design

• Primary Method Selection:
  • SAML 2.0: Strongly recommended for Mobile User authentication. Integrates seamlessly with modern IdPs (Azure AD, Okta, Ping, etc.), supports SSO, and simplifies MFA enforcement via the IdP.
  • LDAP/Kerberos: Can be used but often requires direct connectivity from Panorama/Cloud Identity Engine to Domain Controllers, which might need Service Connections established first. Less common for pure MU authentication than SAML.
  • RADIUS: Useful for integrating with specific MFA providers or legacy authentication systems.
• Identity Provider (IdP) Integration: Configure trust relationships between Prisma Access (acting as Service Provider - SP) and your chosen IdP. This involves exchanging metadata, configuring assertion attributes (username, groups), and setting up signing certificates.
• Group Mapping Strategy: Plan how group memberships will be obtained for policy enforcement:
  • Via SAML assertion attributes (sent by IdP).
  • Via Panorama LDAP group mapping (Panorama queries AD/LDAP).
  • Via Cloud Identity Engine (CIE) synchronization (Cloud service queries IdP/AD).
• Multi-Factor Authentication (MFA): Enforce MFA through the SAML IdP's conditional access policies or via RADIUS integration.

Example SAML Authentication Flow (Mobile User)

        sequenceDiagram
            participant User as User (GP Client)
            participant Portal as GP Portal (Prisma Access)
            participant IdP as Identity Provider (e.g., Azure AD)
            participant Gateway as GP Gateway (Prisma Access)

            User->>Portal: Initiate Connection
            Portal->>User: Redirect to IdP for Authentication
            User->>IdP: Request Authentication
            activate IdP
            Note over User, IdP: User enters credentials, performs MFA
            IdP-->>User: SAML Assertion (Signed)
            deactivate IdP
            User->>Portal: POST SAML Assertion
            activate Portal
            Portal->>Portal: Validate Assertion Signature & Attributes
            Portal-->>User: Authentication OK, Send Agent Config & Cookie
            deactivate Portal
            User->>Gateway: Connect using Config & Cookie
            activate Gateway
            Gateway->>Gateway: Validate Cookie/Assertion Info
            Gateway-->>User: Tunnel Established
            deactivate Gateway
    

Bandwidth Sizing Considerations

• Mobile Users: Estimate based on the number of concurrent users and average expected throughput per user (consider application mix - browsing, video, file transfers). Add buffer for peak usage.
• Remote Networks: Analyze current site bandwidth usage. Decide between per-site allocation or an aggregate pool. If aggregate, sum the peak requirements of all sites and add a buffer (e.g., 20-30%). Over-subscription within the pool is possible but requires careful monitoring.
• Service Connections: Estimate peak traffic flow between Prisma Access users/sites and internal resources. This often requires significant bandwidth, especially if large file transfers or many users access internal apps simultaneously.
• Add-on Services Impact: Features like SSL decryption can increase processing load, which might indirectly influence perceived performance, though bandwidth itself is the primary licensed metric.

Regional Deployment Strategy

• User/Site Locations: Identify the geographic distribution of your mobile users and remote sites.
• Compute Location Selection: During onboarding, select Prisma Access compute locations (PoPs) that are geographically closest to your users/sites to minimize latency.
• Redundancy: For critical Remote Networks or Service Connections, consider establishing tunnels to multiple Prisma Access compute locations for geographic redundancy.
• Data Residency: Be aware of data residency requirements; choose regions accordingly for CDL storage and processing if applicable.

Policy Migration Planning

• Analyze Existing Policies: Review current firewall rules on edge firewalls, VPN concentrators, and branch firewalls. Identify rules relevant to traffic that will traverse Prisma Access.
• Identify Necessary Policies: Determine which existing rules need to be replicated or adapted for Prisma Access (e.g., internet access rules, VPN user access rules, site-to-site rules).
• Consolidate and Optimize: Use migration as an opportunity to clean up old/unused rules, consolidate rules using App-ID/User-ID, and align with Zero Trust principles (least privilege).
• Leverage Prisma Access Features: Plan to use App-ID, User-ID, Content-ID, URL Filtering categories, and HIP profiles instead of just L3/L4 rules.
• Staged Rollout Plan: Consider migrating users/sites in phases to minimize disruption and allow for testing.

Part 2: Onboarding Prisma Access (Panorama-Managed)

This section details the steps for onboarding and configuring Prisma Access using a customer-managed Panorama instance.

Installing and Configuring the Cloud Services Plugin

Initial Setup Wizard Walkthrough

The Cloud Services plugin provides a guided workflow for the initial Prisma Access setup.

Configuring Cortex Data Lake Connection

• Automatic Detection: Usually, after authenticating the Cloud Services plugin, Panorama automatically detects the associated Cortex Data Lake instance for your tenant.
• Log Forwarding Configuration:
  • Navigate to Panorama > Managed Devices > Templates (or a specific Template Stack).
  • Select or create a template for Prisma Access logging.
  • Go to the Device > Log Settings section within the template.
  • Configure system, config, user-id, hip-match, and traffic log forwarding settings to use the detected Cortex Data Lake instance. Ensure appropriate log severity levels are captured.
  • Assign this template to the relevant Template Stacks used by Prisma Access components (Service Connections, Remote Networks, Mobile Users).
• Verification: After pushing configuration, verify logs appear in CDL via Panorama's Monitor tab or the CDL UI.

Template Stacks and Device Groups (Detailed)

This is the core of Panorama-managed configuration, providing structure and reusability.

Panorama Configuration Workflow (Conceptual)

flowchart TD
    subgraph Panorama Objects
        A[Define Shared Objects - Addresses, Services, Profiles]
        B[Define Templates - Network/Device Settings]
        C[Define Device Groups - Policies]
    end

    subgraph Prisma Access Configuration
        D{Assign Templates/Stacks to Prisma Access Components}
        E{Assign Device Groups to Prisma Access Components}
    end

    subgraph Commit & Push
        F[Commit to Panorama]
        G[Push to Cloud Services Plugin]
        H[Plugin Deploys Config to Prisma Access Cloud]
    end

    A --> B
    A --> C
    B --> D
    C --> E
    D --> F
    E --> F
    F --> G
    G --> H

    %% Feedback Loop
    H -- Status/Logs --> G
    G -- Status/Logs --> F


    

Pushing Configuration and Verification

Part 3: Onboarding Prisma Access (Cloud-Managed)

This approach uses the dedicated Prisma SASE cloud management UI, often appealing to new customers or those preferring a fully cloud-based experience.

Navigating the Prisma SASE Management UI

• Access: Log in via the Palo Alto Networks Hub portal and launch the Prisma SASE application.
• Dashboard: Provides an overview of connectivity status, security events, bandwidth usage (Prisma Access Insights).
• Main Navigation (Typical Areas):
  • Manage > Configuration: Where most setup occurs (Mobile Users, Remote Networks, Service Connections, Policies, Objects).
  • Manage > Monitor: Access logs, reports, and detailed status.
  • Manage > Panorama Insights: Detailed analytics and troubleshooting dashboards.
  • Manage > Settings: Account settings, licensing, Cloud Identity Engine configuration.
• Workflow-Oriented: The UI often uses guided workflows and a more abstract layout compared to Panorama's direct PAN-OS mapping.

Step-by-Step Configuration Workflows

While specific clicks vary, the conceptual workflow mirrors Panorama but within the cloud UI:

Part 4: Security Policy Configuration

Security policies are the core of Prisma Access, defining what traffic is allowed or denied and what security inspections are applied.

Creating Security Policy Rules

• Targeting Traffic: Rules match based on:
  • Source/Destination Zones: Predefined zones exist for Prisma Access (e.g., trust for MU/RN LAN-side, untrust for internet-side, zones related to SCs).
  • Source/Destination Addresses: IP addresses, address objects, regions.
  • Source User: Usernames or Group names (requires User-ID integration).
  • HIP Profiles: Endpoint posture (for GP traffic).
  • Application: App-ID (e.g., ssl, web-browsing, facebook, ms-office365).
  • Service: L4 Port/Protocol (e.g., service-https, service-http, or custom).
  • URL Category: For web traffic.
• Actions: Allow, Deny, Drop, Reset.
• Security Profiles: Attach profiles to 'Allow' rules for inspection: Antivirus, Anti-Spyware, Vulnerability Protection, URL Filtering, File Blocking, WildFire Analysis, DNS Security, DLP.
• Log Settings: Configure logging at session start/end, log forwarding profiles.

Basic Security Policy Evaluation Flow

flowchart TD
    A[Traffic Received by SPN] --> B{Match Security Rule? Top-Down}
    B -- Yes --> C{Action = Allow?}
    B -- No --> Z[Default Rule: Implicit Deny unless overridden]
    C -- Yes --> D{Apply Security Profiles}
    C -- No --> E{Action = Deny/Drop/Reset}
    D --> F[Forward Allowed Traffic]
    E --> G[Block/Reset Traffic]
    Z --> G

    

Leveraging User-ID and HIP Context

• Source User Field: Populate with specific usernames (e.g., domain\admin_user) or group names (e.g., domain\Finance Users, Okta_Contractors_Group) obtained via Group Mapping.
• HIP Profiles Field: Select predefined HIP Profiles (e.g., "Compliant Windows Devices", "Non-Compliant BYOD") as match criteria for GlobalProtect traffic.
• Use Cases:
  • Allow 'Developers Group' access to specific SaaS tools (App-ID) and internal servers (Destination Address).
  • Allow 'Compliant Devices' (HIP Profile) access to sensitive internal resources.
  • Block 'Non-Compliant BYOD' (HIP Profile) from accessing anything except remediation portals.
  • Apply stricter Threat Prevention profiles to rules matching 'Untrusted User Group'.

Best Practices for Policy Structure

• Top-Down Evaluation: Remember rules are matched from top to bottom; the first match determines the outcome. Place specific rules above general rules.
• Explicit Deny Rules: Include explicit 'Deny' rules for known bad traffic or unwanted applications before broader 'Allow' rules.
• Default Rule: Rely on the implicit deny-all rule at the bottom, or create an explicit deny-any-any rule at the end with logging enabled for visibility into dropped traffic.
• Zone Strategy: Use appropriate source/destination zones (trust, untrust, custom zones for SCs) to segment traffic logically.
• Naming and Tagging: Use clear, descriptive rule names and leverage tags for organization and filtering (e.g., tag rules by site, function, compliance requirement).
• Regular Review: Periodically review and audit the policy rulebase to remove unused rules and ensure continued alignment with security posture.
• Use App-ID, Not Just Service: Define rules based on Layer 7 App-ID instead of just L4 service/port whenever possible for greater accuracy and security.
• Shared vs Specific Rules (Panorama): Place truly global rules in the 'Shared' DG. Place rules common to all Prisma Access components in a parent Prisma Access DG. Place specific MU/RN/SC rules in their respective child DGs.

URL Filtering Policy Configuration

• URL Filtering Profiles: Create profiles defining actions (allow, alert, block, continue, override) for predefined URL categories (e.g., Malware, Phishing, Social Networking, Streaming Media) and custom categories.
• Applying Profiles: Attach URL Filtering profiles to Security Policy rules (typically rules allowing web-browsing, ssl).
• Best Practices:
  • Block known malicious categories (Malware, Phishing, Command-and-Control).
  • Alert or block high-risk categories (Questionable, Parked Domains).
  • Carefully consider blocking/allowing productivity-impacting categories (Social Media, Streaming). Use 'Continue' pages for user awareness if allowing potentially risky categories.
  • Implement Credential Phishing Prevention features (blocking corporate credential submission to untrusted sites).
  • Leverage Advanced URL Filtering features (real-time detection via ML) if licensed.
  • Create custom URL categories for specific internal sites or exceptions.

Threat Prevention Profile Configuration

• Profile Types: Antivirus, Anti-Spyware, Vulnerability Protection, File Blocking.
• Configuration: Define actions (default, alert, block, sinkhole for AS) for various threat signatures/types. Select appropriate decoders and application/file type settings.
• WildFire Analysis: Configure WildFire profiles to send unknown files/email links for cloud-based sandboxing and analysis. Set actions based on WildFire verdicts (malicious, grayware, benign).
• Applying Profiles: Attach profiles to Security Policy rules allowing traffic where threats might exist (e.g., internet access, inter-zone traffic).
• Best Practices:
  • Use Palo Alto Networks recommended default actions as a starting point.
  • Ensure profiles are attached to relevant 'Allow' rules. A profile does nothing if not applied.
  • Keep content packs (signatures) updated regularly (usually automatic).
  • Consider stricter profiles for traffic from less trusted sources (e.g., untrust zone, non-compliant devices).
  • Enable packet captures for threat logs to aid analysis.

Part 5: NAT Policy Configuration

Network Address Translation (NAT) is used to modify source or destination IP addresses, primarily for enabling outbound internet access from private IP spaces.

Source NAT (SNAT)

• Purpose: Translates private source IP addresses (from Mobile Users, Remote Networks) to a public IP address usable on the internet. Prisma Access handles the allocation of these public IPs.
• Configuration:
  • Create NAT Policy rules matching traffic from internal/trust zones destined for the untrust/internet zone.
  • Source Address: Specify the internal IP pools/subnets to be translated (e.g., MU IP pools, RN subnets).
  • Destination Zone: Typically 'untrust'.
  • Translated Packet (Source): Usually set to 'Dynamic IP and Port' (DIPP). Prisma Access manages the pool of available public IPs for translation. Specify the Egress IP address (provided by Prisma Access during setup) or leave as default if applicable.
• Common Use Case: Allow mobile users and remote network sites using private IPs to browse the internet via Prisma Access.

Destination NAT (DNAT)

• Purpose: Translates a public destination IP address (often on the 'untrust' side) to a private internal IP address.
• Use Cases (Less Common in Prisma Access):
  • Exposing an internal service *through* Prisma Access to the internet (rare, usually handled by on-prem firewalls or cloud load balancers).
  • Specific routing scenarios involving IP overlap resolution (advanced).
• Configuration: Create NAT Policy rules matching traffic destined for the public IP. Set the 'Translated Packet (Destination)' to the internal private IP address. Requires careful planning of routing and security policies.

Part 6: Decryption Policy

Much of today's traffic is encrypted (SSL/TLS). Decryption allows Prisma Access to inspect the content of this traffic for threats, URL categories, sensitive data (DLP), and accurate App-ID identification.

Configuring SSL Forward Proxy Decryption

This is the most common decryption method used for outbound traffic from users/sites to the internet/SaaS.

SSL Forward Proxy Decryption Flow

        sequenceDiagram
            participant User as User's Browser
            participant PA as Prisma Access (SPN)
            participant Server as Web Server (e.g., google.com)

            User->>PA: 1. TCP Handshake (SYN to Server IP)
            PA->>Server: 2. TCP Handshake (SYN with PA IP)
            Server-->>PA: 3. SYN/ACK
            PA-->>User: 4. SYN/ACK
            User->>PA: 5. ACK (TCP Established)
            PA->>Server: 6. ACK (TCP Established)

            User->>PA: 7. Client Hello (TLS Handshake)
            activate PA
            PA->>PA: 8. Decryption Policy Match? (Action=Decrypt)
            PA->>Server: 9. Client Hello (from PA)
            activate Server
            Server-->>PA: 10. Server Hello, Certificate, Server Key Exchange
            PA->>PA: 11. Verify Server Cert. Generate **Impersonation Cert** (signed by Forward Trust CA)
            PA-->>User: 12. Server Hello (from PA), **Impersonation Cert**, Server Key Exchange
            deactivate Server
            activate User
            User->>User: 13. Verify Impersonation Cert (Trusts Root CA?)
            User->>PA: 14. Client Key Exchange, Change Cipher Spec, Finished (Encrypted with Impersonation Cert Session Key)
            deactivate User
            PA->>PA: 15. Decrypt Finished message using its key
            PA->>Server: 16. Client Key Exchange, Change Cipher Spec, Finished (Encrypted with Original Server Session Key)
            activate Server
            Server-->>PA: 17. Change Cipher Spec, Finished (Encrypted)
            deactivate Server
            PA->>PA: 18. Decrypt Finished message
            Note over PA, Server: Secure session PA <-> Server established
            PA-->>User: 19. Change Cipher Spec, Finished (Encrypted)
            deactivate PA
            Note over User, PA: Secure session User <-> PA established
            Note over User, PA: PA now decrypts app data User->PA, inspects, re-encrypts PA->Server (and vice-versa)
    

Certificate Management and Deployment

• Forward Trust CA: As described above, requires signing by a trusted root (internal or self-signed) and deployment of that root to clients.
• Forward Untrust Certificate: Used for websites with invalid/untrusted certificates. Prisma Access presents this cert to the user, typically resulting in a browser warning page configurable in the Decryption Profile. Does not require client deployment.
• Deployment Methods for Root CA: Group Policy Objects (GPO) for Windows, MDM profiles (Intune, Jamf, Workspace ONE) for macOS/iOS/Android, manual installation.

Decryption Exclusions and Best Practices

• Reasons for Exclusion ('No Decrypt' Rules):
  • Privacy Concerns: Categories like Financial Services, Health and Medicine often contain sensitive personal data that organizations choose not to decrypt.
  • Technical Issues: Applications using certificate pinning (where the app expects a specific server certificate, not the impersonation cert), mutual authentication, or non-standard TLS implementations may break if decrypted.
  • Unsupported Ciphers/Protocols: While rare, some legacy protocols might not be decryptable.
• Creating Exclusions: Create specific 'No Decrypt' Decryption Policy rules placed *before* the main 'Decrypt' rule. Match based on:
  • URL Category (most common: Financial, Health).
  • Destination IP/Address Object.
  • Source User/Group.
  • Application (App-ID).
• Logging: Ensure TLS Handshake errors and other decryption failures are logged for troubleshooting.
• Performance: Decryption consumes additional processing resources on the SPNs. Monitor resource utilization in Prisma Access Insights, although Prisma Access infrastructure is generally sized to handle significant decryption loads.

Part 7: QoS Policy Configuration

Quality of Service (QoS) allows you to prioritize critical applications and manage bandwidth allocation within Prisma Access, ensuring important traffic gets preferential treatment during congestion.

• Purpose: Guarantee performance for latency-sensitive or business-critical applications (e.g., VoIP, video conferencing, SAP) over less important traffic (e.g., large file transfers, recreational browsing).
• Mechanism: Prisma Access supports policy-based QoS, classifying traffic into different priority classes (typically 8 classes, 1 being highest priority, 4 being default).
• Configuration:
  • Define QoS Profile:** Under `Objects > QoS Profile`, define guaranteed bandwidth and maximum bandwidth limits for each QoS class.
  • Define QoS Policy Rule:** Under `Policies > QoS`, create rules to classify traffic into specific QoS classes. Match criteria include: App-ID, User/Group, Source/Destination IP, Service, URL Category. Assign a QoS Class (1-8) to matching traffic.
  • Apply QoS Profile to Interface:** QoS is typically applied egress on the virtual interfaces handling outbound traffic within the Prisma Access templates (e.g., the tunnel interface for RN/SC, or the external interface for MU internet traffic). This is configured within the Template settings (`Network > Network Profiles > QoS Profile`).
• Bandwidth Management: QoS helps manage the bandwidth allocated to Mobile Users or Remote Networks, ensuring fair usage and prioritization within those licensed limits.
• Best Practices:
  • Identify truly critical applications needing prioritization.
  • Assign highest priority (Class 1-3) sparingly to essential, real-time apps (VoIP, Video Conferencing).
  • Assign lower priority (Class 5-8) to bulk traffic or non-critical apps.
  • Leave most standard business traffic in the default class (Class 4).
  • Monitor QoS statistics to ensure policies are having the desired effect.