3.3 Decryption Policy, Decryption Profiles & Decryption Broker

3.3 Decryption Policy, Decryption Profiles & Decryption Broker

Exam Focus: Candidates must demonstrate thorough knowledge of Decryption Policy rule ordering, compliance and privacy exclusions for sensitive URL categories, Decryption Profile security settings (especially revocation check timeout behaviors), Decryption Broker forwarding chains, and hardware cryptographic acceleration engines.

---

1. Decryption Policy Rule Configuration & Matching Order

In PAN-OS, the decision to decrypt network traffic is controlled by Decryption Policy Rules (Policies > Decryption). Decryption Policy rules are evaluated independently of and prior to Security Policy rules.

Decryption Policy Rule Criteria

Each Decryption Policy rule specifies matching criteria across Layer 3 through Layer 7 attributes:

• Name & Description: Administrative label identifying the rule's operational intent.
• Type:
  • ssl-forward-proxy (outbound client inspection)
  • ssl-inbound-inspection (inbound server protection)
  • ssh-proxy (SSH tunnel tunneling and command inspection)
• Source: Source Zone, Source Interface, and Source IP Address/Subnet.
• Source User / Group: User-ID integration (e.g., Active Directory group CN=Finance-Team,DC=corp,DC=com or Cloud Identity Engine user objects).
• Destination: Destination Zone and Destination IP Address/FQDN.
• Service: Destination port (service-https for port 443, or custom service objects for non-standard SSL ports).
• URL Category: Predefined or custom URL categories (e.g., financial-services, health-and-medicine, high-risk).
• Action:
  • Decrypt: Traffic matching this rule is decrypted according to the specified Type and attached Decryption Profile.
  • No-Decrypt: Traffic matching this rule bypasses decryption entirely, continuing through the firewall as an encrypted tunnel.
• Decryption Profile: Security profile attached to the rule governing cryptographic parameters and certificate validation checks.

Top-Down First-Match Evaluation Logic

Like Security Policy rules, Decryption Policy rules are processed sequentially from top to bottom on a first-match basis. Once a packet matches all criteria of a Decryption Policy rule, the firewall executes that rule's action (Decrypt or No-Decrypt) and immediately ceases rulebase evaluation.

[Incoming Packet Flow: Client Hello (SNI / IP / User)]
                      |
                      v
    +-----------------------------------+
    | Rule 1: No-Decrypt-Financial      | ---> MATCH? ---> YES ---> Bypass Decryption (Encrypted)
    | (Category: financial-services)    |
    +-----------------------------------+
                      | NO
                      v
    +-----------------------------------+
    | Rule 2: No-Decrypt-Healthcare     | ---> MATCH? ---> YES ---> Bypass Decryption (Encrypted)
    | (Category: health-and-medicine)   |
    +-----------------------------------+
                      | NO
                      v
    +-----------------------------------+
    | Rule 3: Decrypt-Outbound-General  | ---> MATCH? ---> YES ---> Execute SSL Forward Proxy
    | (Action: Decrypt)                 |                           (In-Memory SP3 Inspection)
    +-----------------------------------+

[!IMPORTANT] Decryption Policy vs. Security Policy Relationship: Decryption Policy determines whether to decrypt the payload. It does NOT determine whether to allow or block the session! Once decrypted, the plaintext traffic is evaluated against the Security Policy Rulebase to enforce allow/deny actions based on post-decryption App-ID and Content-ID profiles.

---

2. Compliance & Privacy Exclusions (Regulatory Governance)

Decryption is not purely a technical challenge; it is heavily constrained by legal, regulatory, and corporate privacy mandates:

• Health Insurance Portability and Accountability Act (HIPAA): Regulates Protected Health Information (PHI). Intercepting and inspecting employee medical records, telehealth sessions, and patient portals can expose the enterprise to federal privacy liabilities.
• Gramm-Leach-Bliley Act (GLBA) & PCI-DSS: Mandate strict privacy protections for personal banking, credit card transactions, and non-public personal financial information.
• General Data Protection Regulation (GDPR): European privacy laws strictly prohibit employers from intercepting personal banking, private communications, or sensitive personal data of employees without explicit consent and legal justification.

Best Practice No-Decrypt URL Categories

To maintain regulatory compliance, enterprise security baselines mandate creating explicit No-Decrypt rules placed at the very top of the Decryption Policy rulebase for three critical predefined URL categories:

1. financial-services (online banking, brokerage, investment portals)
2. health-and-medicine (hospitals, health insurance, pharmacy management, medical portals)
3. government-and-military (tax portals, social security services, official government websites)

SSL Decryption Exclusion List

In addition to URL category exclusions, many commercial applications enforce certificate pinning or proprietary TLS protocols that break under SSL Forward Proxy (e.g., Apple iOS App Store, Microsoft Office 365 activation, Dropbox, Google Drive desktop sync).

PAN-OS includes a pre-compiled SSL Decryption Exclusion List maintained by Palo Alto Networks and updated dynamically via Content Updates (Applications and Threats).

• Viewable under Device > Certificate Management > SSL Decryption Exclusion.
• Administrators can toggle predefined exclusions on/off or add custom domains (e.g., *.partner-bank.com) to exempt specific services from decryption globally without modifying the policy rulebase.

---

3. Decryption Profiles: In-Depth Cryptographic Controls

A Decryption Profile (Objects > Decryption > Decryption Profile) attaches directly to a Decryption Policy rule to enforce strict cryptographic standards, validate server certificates, and control protocol versions.

+-----------------------------------------------------------------------------------+
|                         PAN-OS Decryption Profile Settings                         |
+-----------------------------------------------------------------------------------+
| [SSL Protocol Settings]                                                           |
|   - Min Version: TLSv1.2               - Max Version: TLSv1.3                     |
|                                                                                   |
| [Certificate Verification Checks]                                                 |
|   [X] Block sessions with expired certificates                                    |
|   [X] Block sessions with untrusted issuers                                       |
|   [X] Block sessions with unknown certificate status                              |
|   [X] Block sessions on certificate status check timeout                          |
|                                                                                   |
| [Revocation Verification (OCSP & CRL)]                                             |
|   - Mode: OCSP preferred, CRL fallback                                            |
|   - OCSP Stapling: Enabled (Verify stapled response from Server Hello)            |
|                                                                                   |
| [Unsupported Ciphers & Protocol Hardening]                                        |
|   [X] Block sessions with unsupported versions (SSLv3, TLS 1.0, TLS 1.1)          |
|   [X] Block sessions with unsupported cipher suites (3DES, RC4, MD5)              |
+-----------------------------------------------------------------------------------+

Protocol Version & Cipher Suite Hardening

• Protocol Bounds: Administrators configure Min Version (TLSv1.2) and Max Version (TLSv1.3). Any client or server attempting to negotiate legacy SSLv3, TLS 1.0, or TLS 1.1 is dropped.
• Cipher Hardening: Checkboxes allow instant blocking of weak or deprecated ciphers, including 3DES, RC4, MD5 message digests, and non-PFS static RSA key exchange algorithms.

Certificate Revocation Checking: OCSP vs. CRL

When a server presents a certificate, PAN-OS checks whether the certificate has been revoked by its issuing CA before trusting it:

• Online Certificate Status Protocol (OCSP): A real-time, lightweight HTTP query sent to the CA's OCSP responder URL extracted from the certificate's Authority Information Access (AIA) extension. OCSP returns immediate status: Good, Revoked, or Unknown.
• Certificate Revocation List (CRL): A periodic, flat list of revoked certificate serial numbers signed and published by the CA at its CRL Distribution Point (CDP). PAN-OS downloads, parses, and caches CRL files locally. CRLs consume significant memory and bandwidth when lists grow large.
• OCSP Stapling (RFC 6066): To eliminate the latency and overhead of the firewall making external queries to third-party OCSP responders, OCSP Stapling allows the web server to query its own OCSP responder periodically and cache the signed response. The server then "staples" this timestamped OCSP response directly into its TLS Server Hello. PAN-OS verifies the stapled response instantly without initiating an outbound network query.

Revocation Check Timeout: Security vs. Availability Trade-off

In the Decryption Profile, the checkbox Block session on certificate status check timeout represents one of the most critical architectural decisions on the firewall:

• Checked (Enabled - Fail Closed): If the firewall sends an OCSP or CRL request and the external CA responder fails to answer within the timeout window (due to network congestion, DDoS on the CA, or DNS failure), the firewall terminates the user session. This prioritizes Security over availability, ensuring that revoked certificates are never accepted.
• Unchecked (Disabled - Fail Open): If the responder times out, the firewall allows the session to proceed. This prioritizes Availability over security, preventing network outages when third-party CA infrastructure experiences transient downtime, but risks permitting access to compromised or revoked certificates.

---

4. Decryption Broker Architecture & Deployment Topologies

In large enterprise datacenters, security operations teams deploy diverse, specialized third-party security appliances—such as dedicated Data Loss Prevention (DLP) appliances, external Network Intrusion Detection/Prevention Systems (NIDS/NIPS), and network packet forensics tools (e.g., Symantec DLP, Cisco Sourcefire, Gigamon, ExtraHop).

The Multi-Tool Decryption Dilemma

Historically, each standalone appliance had to independently decrypt TLS traffic, perform inspection, and re-encrypt the traffic. This created severe operational problems:

• Cryptographic Latency & Performance Degradation: Multiple sequential decrypt/encrypt cycles introduced massive latency and CPU overhead.
• Certificate Management Nightmare: Server private keys and enterprise root certificates had to be synchronized across dozens of disparate vendor appliances.
• Inspection Blind Spots: Tools that lacked native TLS 1.3 decryption capabilities were completely blinded by modern ciphers.

The Decryption Broker Solution

PAN-OS Decryption Broker solves this problem by centralizing decryption on the Palo Alto Networks Next-Generation Firewall. The firewall decrypts the traffic once, forwards the unencrypted plaintext stream across dedicated interfaces to one or more third-party security appliances for analysis, receives the inspected traffic back, and re-encrypts the traffic before transmission to the final destination.

                               +----------------------------+
                               |    Palo Alto Networks      |
               Encrypted In    |           NGFW             |   Encrypted Out
               ===============>| [Decrypt]        [Re-Encrypt]|===============>
                               +----------------------------+
                                    | Plaintext        ^
                        Forward Egress |                | Return Ingress
                                    v                |
                          +--------------------------------+
                          |    Dedicated Security Chain    |
                          |                                |
                          |   +------------------------+   |
                          |   |  Inline Third-Party    |   |
                          |   |  DLP Appliance         |   |
                          |   +------------------------+   |
                          |                |               |
                          |                v               |
                          |   +------------------------+   |
                          |   |  Inline Third-Party    |   |
                          |   |  IPS Appliance         |   |
                          |   +------------------------+   |
                          +--------------------------------+

Decryption Broker Topologies

PAN-OS supports two primary forwarding architectures for Decryption Broker:

1. Two-Way Transparent Bridge (Inline Security Chain):
   • Used for inline active enforcement devices (e.g., third-party IPS or inline DLP) capable of modifying, sanitizing, or dropping malicious packets.
   • The firewall forwards decrypted plaintext out a dedicated Broker Egress Interface.
   • Traffic traverses the third-party security appliance chain.
   • The traffic returns into the firewall via a dedicated Broker Ingress Interface.
   • If the third-party tool detects a violation, it drops the packet inline; if clean, the firewall re-encrypts the stream and forwards it to the true destination.
2. One-Way Monitoring (Passive Tap / Span Chain):
   • Used for passive, out-of-band monitoring appliances (e.g., passive NIDS, forensic loggers, or compliance packet capture recorders).
   • The firewall copies and mirrors the decrypted plaintext stream out a dedicated interface to the monitoring tool.
   • No return path is expected or required; the firewall continues processing and re-encrypting the original traffic flow independently.

---

5. Hardware Cryptographic Acceleration Architecture

Decryption is computationally intensive, requiring billions of complex mathematical operations per second (large prime modular exponentiation and elliptic curve point multiplication). Performing these cryptographic calculations in general-purpose software would overwhelm standard CPUs, degrading App-ID, Content-ID, and overall firewall throughput.

To deliver wire-speed inspection, Palo Alto Networks hardware firewalls (including the PA-3400, PA-5400, and PA-7000 series) integrate dedicated hardware cryptographic acceleration engines:

• Dedicated Crypto Offload Processors (Octeon Cores & Custom DPUs): Dedicated high-performance cryptographic coprocessors handle intensive asymmetric public-key operations (RSA/ECDSA handshake signatures, Diffie-Hellman key derivation, and ephemeral certificate minting). This offloads the firewall's general CPUs, reserving them entirely for deep packet inspection.
• Hardware Symmetric Crypto Accelerators (AES-NI & Inline ASICs): High-speed hardware pipelines perform bulk symmetric encryption and decryption (AES-GCM, ChaCha20) inline at line rates.
• Cryptographic Memory Pools: Dedicated high-speed memory buffers store SSL session states, pre-computed DH parameters, and cached certificates, preventing memory contention with standard networking tables.

---

6. Operational Diagnostics & CLI Verification

Inspecting Active Decryption Policy Rules

admin@PA-5450> show running decryption-policy

Rule: No-Decrypt-Finance {
        from: Trust-L3;
        to: Untrust-L3;
        category: [ financial-services health-and-medicine ];
        action: No-Decrypt;
}
Rule: Decrypt-Corporate-Users {
        from: Trust-L3;
        to: Untrust-L3;
        source-user: [ corp\finance-team corp\engineering ];
        action: Decrypt;
        type: ssl-forward-proxy;
        profile: Corporate-Decryption-Profile;
}

Verifying Decryption Broker Status

Check the operational state and packet forwarding statistics of Decryption Broker security chains:

admin@PA-5450> show decryption-broker status

Security Chain: Corp-DLP-Chain
  Type:                 Transparent Bridge (Two-Way)
  Egress Interface:     ethernet1/15
  Ingress Interface:    ethernet1/16
  Status:               UP (Active Forwarding)
  Packets Forwarded:    48201948
  Packets Returned:     48201940
  Dropped / Timed Out:  8

Checking Dataplane Cryptographic Memory

Monitor crypto memory pool utilization to ensure the firewall is not approaching decryption session limits:

admin@PA-5450> debug dataplane show ssl-decrypt memory-usage

SSL Decryption Memory Summary:
  Total Memory Allocated:      4096 MB
  Memory In Use:               1124 MB (27%)
  Active SSL Sessions:         18450
  Session Allocation Failures: 0
  Cached Dynamic Certificates: 1240

---

7. Comparative Architecture: Decryption Broker Topologies

---

8. Exam Traps & Real-World Pitfalls

[!WARNING] EXAM TRAP 1: Rule Ordering Inversion (The Compliance Leak) Because Decryption Policy rules evaluate top-down on a first-match basis, placing a broad outbound Decrypt rule above specific No-Decrypt compliance rules creates a major compliance violation. If Rule 1: Decrypt-All (Category: Any) sits above Rule 2: No-Decrypt-Banking (Category: financial-services), all banking and healthcare sessions will match Rule 1 and be decrypted! Always place specific No-Decrypt rules at the very top of the rulebase.

[!WARNING] EXAM TRAP 2: The OCSP Timeout Blackout Enabling Block session on certificate status check timeout enforces maximum security, but introduces a major availability dependency. If an upstream ISP fiber cut impairs connectivity to a major public CA's OCSP responder, legitimate enterprise users will suddenly be blocked from accessing essential business websites, generating widespread helpdesk outages. Candidates must understand that checking this box chooses a fail-closed posture, whereas unchecking it chooses a fail-open posture.

[!WARNING] EXAM TRAP 3: Decryption Broker Interface Prerequisites Decryption Broker interfaces cannot be standard Layer 3 routed interfaces shared with general network traffic. They must be configured as dedicated Decryption Broker interfaces or dedicated virtual wire (Vwire) pairs assigned specifically to a Decryption Broker forwarding chain. Attempting to assign an active routed interface to a broker security chain will fail commit validation.