Plan Your SSL Decryption Best Practice Deployment

Before you deploy decryption in your network, set goals, work with stakeholders to define what to decrypt, and plan a staged, prioritized deployment.
Prepare to deploy decryption by developing a decryption strategy and roll-out plan. Turning on decryption may change the way users interact with some applications and websites, so planning, testing, and user education are critical to a successful deployment.
  1. Set goals.
    • Plan to decrypt as much traffic that is not private or sensitive as your firewall resources allow to reduce the attack surface by exposing and preventing encrypted threats. Understand local laws and regulations about the traffic you can legally decrypt and user notification requirements.
    • Migrate from port-based to application-based Security policy rules before you create and deploy Decryption policy rules. If you create Decryption rules based on port-based Security policy and then migrate to application-based Security policy, the change could cause the Decryption rules to block traffic that you intend to allow because Security policy rules are likely to use application default ports to prevent application traffic from using non-standard ports. For example, traffic identified as web-browsing application traffic (default port 80) may have underlying applications that have different default ports, such as HTTPS traffic (default port 443). The application-default rule blocks the HTTPS traffic because it sees the decrypted traffic using a “non-standard” port (443 instead of 80). Migrating to App-ID based rules before deploying decryption ensures that when you test your decryption deployment in POCs, you’ll discover Security policy misconfigurations and fix them before rolling decryption out to the general user population.
  2. Work with and educate stakeholders such as legal, finance, HR, executives, security, and IT/support to develop a decryption deployment strategy.
    • Get the required approvals to decrypt traffic to secure the corporation.
    • Identify and prioritize the traffic to decrypt:
      • Decide which applications to decrypt (sanctioned, unsanctioned). Don’t allow encrypted unsanctioned applications.
      • Decide which devices to decrypt (corporate, BYOD, mobile, etc.).
        Enterprises don’t control BYOD devices. If you allow BYOD devices on your network, decrypt their traffic and subject it to the same Security policy that you apply to other network traffic. To do this, redirect BYOD users through a captive portal, instruct them how to download and install the CA certificate, and clearly notify users that their traffic will be decrypted. Educate BYOD users about the process and include it in your company’s privacy and computer usage policy.
      • Decide if you want to use the same decryption policy for different groups, such as different employee groups, contractors, partners, and guests.
    • Identify the traffic you can’t decrypt:
      • Traffic that breaks decryption for
        technical
        reasons such as certificate pinning, unsupported ciphers, or mutual authentication.
      • Traffic that you
        choose
        not to decrypt such as financial, health, government, military, and other sensitive categories, including users and groups such as executives.
      • Fully understand the traffic you except from decryption (whitelist). You don’t have visibility into encrypted traffic and the firewall can’t apply threat prevention profiles to encrypted traffic.
    • Prepare updated legal and HR computer usage policies to distribute to all employees, contractors, partners, guests, and any other network users so that when you roll out decryption, users understand their data can be decrypted and scanned for threats.
    • Decide how to handle certificate verification. Your business model may require tradeoffs between security and the user experience. Understanding how you want to handle certificate verification helps determine how you configure SSL Forward Proxy Decryption profiles.
    • Identify the traffic you want to log. Be aware of local legal and regulatory differences, and how they affect which traffic you can log and where you can store logs.
    Place firewalls where they can see all of the network traffic so that no encrypted traffic inadvertently gains access to your network because it bypasses the firewall.
  3. Develop a plan for rolling out your public key infrastructure (PKI).
    • If you have an existing PKI, generate the SSL Forward Trust CA certificate from your Enterprise Root CA as a subordinate certificate. This makes deployment easier because network devices already trust the Enterprise Root CA, so you won’t run into certificate issues. If you don’t have an Enterprise Root CA, consider getting one.
      Alternatively, generate a self-signed Root CA certificate on the firewall and create a subordinate Forward Trust CA certificate on that firewall to install on network devices. Self-signed certificates are best for small companies that don’t have an Enterprise Root CA and for proof-of-concept (POC) trials.
      Similarly to BYOD devices, enterprises don’t control guest devices. If you allow guest devices on your network, decrypt their traffic and subject it to the same Security policy that you apply to other network traffic. To do this, redirect guest users through a captive portal, instruct them how to download and install the CA certificate, and clearly notify users that their traffic will be decrypted. Include the process in your company’s privacy and computer usage policy.
    • Generate
      separate
      CA certificates for Forward Trust and Forward Untrust. Do not use the same PKI subordinate CA for both certificates and do not sign the Forward Untrust certificate with the Trusted Root CA! The Forward Untrust certificate warns users that the certificate signing the server is not legitimate and that they should not proceed to the site. If the Trusted Root CA signs the Untrust certificate, then clients trust certificates that should be untrusted because clients trust the Root CA.
    • Generate a separate subordinate Forward Trust CA certificate for each firewall. Using separate subordinate CAs enables you to revoke one certificate when you decommission a device (or device pair) without affecting the rest of the deployment and reduces the impact if you need to revoke a certificate. Separate CA certificates help technical support troubleshoot user issues because the certificate error message includes information about the firewall the traffic traversed. Although using one Forward Trust subordinate CA on all firewalls is easier to deploy, using a separate certificate on each firewall provides the best security.
    • If you need additional security for your private keys, consider storing them on an HSM.
  4. Measure firewall performance so that you understand the available firewall resources and have a baseline to compare performance after you deploy decryption, and estimate the size of the firewall deployment required to support the amount of traffic you want to decrypt.
    • Work with your Palo Alto Networks SE/CE to size the firewall deployment and avoid sizing mistakes.
    • Understand the currently available firewall resources to help estimate firewall sizing for the SSL Decryption deployment. In general, the tighter the security, the more resources decryption consumes. Factors that affect how much traffic you can decrypt include:
      • The amount of SSL traffic you want to decrypt.
      • TLS protocol version.
      • Key size.
      • Key exchange algorithm. Perfect forward secrecy (PFS) ephemeral algorithms such as DHE and ECDHE consume more resources than RSA. PFS provides greater security because the firewall generates a new cipher key for each session, but generating the new key uses more firewall resources. However, if an attacker compromises a session key, PFS prevents the attacker from using it to decrypt other sessions between the same client and server, while RSA does not.
      • Certificate authentication. RSA certificate authentication (this is not the same as the RSA key exchange algorithm) consumes fewer CPU cycles than ECDSA certificate authentication but ECDSA provides the highest level of security.
      • Encryption algorithm. The key exchange algorithm determines whether the encryption algorithm is PFS or RSA.
      • The firewall model and resources. Newer firewall models have more resources than older models.
    • Transaction sizes affect performance. Measure the average transaction size of all traffic, then measure the average transaction size of traffic on port 443 (default port for HTTPS encrypted traffic) to understand the proportion of encrypted traffic on the firewall in relation to your total traffic and the average transaction sizes.
    The combination of these factors determines how decryption consumes firewall processing resources. To best utilize the firewall’s resources, understand the risks of the data you’re protecting. If firewall resources are an issue, use stronger decryption for higher-priority traffic and use less processor-intensive decryption to decrypt and inspect lower-priority traffic until you can increase the available resources.
    Don’t size the firewall deployment based only on today’s needs. Include headroom for growth in the amount of traffic to decrypt because every day, more traffic is encrypted.
    • Identify early adopters to champion decryption and get department managers on-board with the plan.
    • Set up POCs in each department to test the deployment strategy before you roll it out to the general user population. Measure the way the decryption POC deployment affects firewall CPU and memory utilization to help understand if firewall sizing is correct or if you need to upgrade. POCs can also reveal applications that break decryption technically.
      • Educate POC participants on the changes and how to contact technical support.
      • Set up a technical support POC for the decryption POCs so that support has the opportunity to develop the best ways to support the rollout.
      • Phase in decryption. Plan to decrypt the riskiest traffic first (URL Categories most likely to harbor malicious traffic, such as gaming or high-risk) and then decrypt more as you gain experience. Alternatively, decrypt the URL Categories that don’t affect your business first (if something goes wrong, it won’t affect business), for example, news feeds. In both cases, decrypt a few URL Categories, listen to user feedback, run reports to ensure that decryption is working as expected, and then gradually decrypt a few more URL Categories, and so on. Plan to make decryption exclusions to exclude sites from decryption if you can’t decrypt them for technical reasons or because you choose not to decrypt them.
      • Gauge the success of the POCs and fine-tune the deployment practices.
    • Educate the user population before the general rollout. The POC experience helps identify the most important points to communicate.
    • Distribute updated legal and HR computer usage policies to all employees, contractors, partners, guests, and any other network users and ensure that they understand their data can be decrypted and scanned for threats as you roll out decryption to each department or group.
    • Create realistic schedules that allow time to evaluate each stage of the rollout.

Related Documentation