Work with Stakeholders to Develop a Decryption Deployment Strategy
To understand the traffic you should and should not decrypt, work with other invested groups, including finance, HR, IT, legal, and executives to ensure that you don’t decrypt sensitive traffic but do decrypt everything else.
Work with stakeholders such as legal, finance, HR, executives, security, and IT/support to develop a decryption deployment strategy. Start by getting the required approvals to decrypt traffic to secure the corporation. Decrypting traffic involves understanding how legal regulations and business needs affect what you can and can’t decrypt.
Identify and prioritize the traffic you want to decrypt. The best practice is to decrypt as much traffic as you can to gain visibility into potential threats in encrypted traffic and prevent those threats. If incorrect firewall sizing prevents you from decrypting all of the traffic you want to decrypt, prioritize the most critical servers, the highest-risk traffic categories, and less trusted segments and IP subnets. To help prioritize, ask yourself questions such as, “What happens if this server is compromised?” and “How much risk am I willing to take in relation to the level of performance I want to achieve?”
Next, identify traffic that you can’t decrypt because the traffic breaks decryption for technical reasons such as a pinned certificate, an incomplete certificate chain, unsupported ciphers, or mutual authentication. Decrypting sites that break decryption technically results in blocking that traffic. Evaluate the websites that break decryption technically and ask yourself if you need access to those sites for business reasons. If you don’t need access to those sites, allow decryption to block them. If you need access to any of those sites for business purposes, add them to the SSL Decryption Exclusion list to except them from decryption. The SSL Decryption Exclusion list is exclusively for sites that break decryption technically.
Identify sensitive traffic that you
choosenot to decrypt for legal, regulatory, personal, or other reasons, such as financial, health, or government traffic, or the traffic of certain executives. This is not traffic that breaks decryption technically, so you don’t use the SSL Decryption Exclusion list to except this traffic from decryption. Instead, you Create a Policy-Based Decryption Exclusion to identify and control traffic you choose not to decrypt and apply the No Decryption decryption profile to the policy to prevent servers with certificate issues from accessing the network. Policy-based decryption exclusions are only for traffic you choose not to decrypt.
When you plan decryption policy, consider your company’s security compliance rules, computer usage policy, and your business goals. Extremely strict controls can impact the user experience by preventing access to non-business sites the user used to access, but may be required for government or financial institutions. There is always a tradeoff between usability, management overhead, and security. The tighter the decryption policy, the greater the chance that a website will become unreachable, which may result in user complaints and possibly modifying the rulebase.
Although a tight decryption policy may initially cause a few user complaints, those complaints can draw your attention to unsanctioned or undesirable websites that are blocked because they use weak algorithms or have certificate issues. Use complaints as a tool to better understand the traffic on your network.
Different groups of users and even individual users may require different decryption policies, or you may want to apply the same decryption policy to all users. For example, executives may be exempted from decryption policies that apply to other employees. And you may want to apply different decryption policies to employee groups, contracts, partners, and guests. 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.
How you handle guest users depends on the access they require. Isolate guests from the rest of your network by placing them on a separate VLAN and on a separate SSID for wireless access. If guests don’t need to access your corporate network, don’t let them on it and there will be no need to decrypt their traffic. If guests need to access your corporate network, decrypt their traffic:
- Enterprises don’t control guest devices. Decrypt guest traffic and subject it to your guest Security policy so the firewall can inspect the traffic and prevent threats. To do this, redirect guest users through a captive portal, instruct them how to download and install the CA certificate, and clearly notify guests that their traffic will be decrypted. Include the process in your company’s privacy and computer usage policy.
Similarly to different groups of users, decide which devices to decrypt and which applications to decrypt. Today’s networks support not only corporate devices, but BYOD, mobile, remote-user and other devices, including contractor, partner, and guest devices. Today’s users attempt to access many sites, both sanctioned and unsanctioned, and you should decide how much of that traffic you want to decrypt.
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 so the firewall can inspect the traffic and prevent threats. 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 what traffic you want to log and investigate what traffic you can log. Be aware of local laws regarding what types of data you can log and store, and where you can log and store the data. For example, local laws may prevent logging and storing personal information such as health and financial data.
Decide how to handle bad certificates. For example, will you block or allow sessions for which the certificate status is unknown? Understanding how you want to handle bad certificates determines how you configure the decryption profiles that you attach to decryption policies to control which sessions you allow based on the server certificate verification status.