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
choose not 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.
Create separate Decryption
policy rules
and Security policy rules to tightly control guest access so that
guests can only access the areas of your network that they need
to access.
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.
