Plan Your SSL Decryption Best Practice Deployment
Table of Contents
Expand all | Collapse all
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.
- Set goals.
- Plan to decrypt as much traffic that is not private or sensitive as your firewall resources permit. This reduces 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 traffic from using non-standard ports. Migrating to App-ID based rules before deploying decryption ensures that when you test your decryption deployment, you’ll discover Security policy misconfigurations and fix them before rolling decryption out to the general user population.
- Work with and educate stakeholders such as legal, finance, HR, executives, security, and IT/support to develop a decryption deployment strategy.
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.
- Get the required approvals to decrypt traffic to secure the enterprise.
- 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 an Authentication 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 traffic you can’t decrypt:
- Fully understand the traffic you except from decryption. 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.
- 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 an Authentication 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.
- GenerateseparateCA 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 a 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.
- Take a baseline measurement of firewall performance to understand resource consumption and available firewall resources so that you can 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.
The combination of these factors determines how decryption consumes firewall processing resources. If firewall resources are an issue, use stronger decryption for higher-priority and higher-risk traffic and use less processor-intensive decryption to decrypt and inspect lower-priority traffic until you can increase the available resources.Size the firewall to include headroom for growth in the amount of traffic to decrypt because more traffic is encrypted every day.
- Work with your Palo Alto Networks SE/CE to size the firewall deployment and avoid sizing mistakes.
- Note the currently available firewall resources. In general, the tighter your 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, but provide greater security because the firewall generates a new cipher key for each session. 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.
- 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.
- Identify early adopters to champion decryption and get department managers on-board with the plan.
- Set up POCs 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. 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 and check Decryption logs to ensure that decryption is working as expected, and then gradually decrypt a few more URL Categories, etc. 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 deployment practices.
- Educate the user population before the general rollout. POCs help 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. Ensure that everyone understands 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.