SSL encryption is intended to make communication over the Internet between two systems private from third-party "eavesdropping." Many websites use SSL to maintain compliance with certain privacy and security regulations, like the Health Insurance Portability and Accountability Act (HIPAA) and Payment Card Industry Data Security Standard (PCI DSS), or as a proactive precautionary service for their users. A large percentage of all network traffic is encrypted with SSL.
Because it's often used and meant to be private between the sender and recipient, encrypted traffic represents an opportunity for attackers to deliver threats into target organizations without being inspected. For example, an attacker may use a Web application like Gmail, which uses SSL encryption, to email an exploit or malware to employees accessing that application via the corporate network or via a company-issued device. Likewise, an attacker may compromise a website that uses SSL encryption to silently download an exploit or malware to the site's visitors.
If you're not decrypting traffic like the kind described in the examples above, you're leaving a large hole in your network where your next-generation firewall cannot protect against threats coming in or sensitive data going out. In addition to ensuring users comply with corporate policy, visibility into encrypted traffic is crucial to confirming that it's clear of cyberthreats.
It's understandable, however, that you may not be able to decrypt all traffic because of the private nature of transactions to and from banking institutions, healthcare providers, government and military organizations, and the payment card industry, for example. However, you can use your next-generation firewall to selectively decrypt incoming and outgoing traffic that falls outside of personal or confidential traffic parameters set by company policies or government regulations.
Palo Alto Networks® Next-Generation Firewall (NGFW) allows SSL decryption on selected incoming and outgoing traffic, providing full visibility, threat inspection and policy compliance before re-encrypting and allowing it to proceed to its destination.
Whether you've recently started implementing Palo Alto Networks products or have been administering them for years, make sure you're maximizing their full value by reviewing our best practices for inspecting encrypted traffic.
As with any technology, there is usually a gradual approach to a complete implementation, consisting of carefully planned deployment phases meant to make the transition as smooth as possible with minimal impact to your end users. With this approach in mind, we've recommended our decryption best practices in three phases, each building on the recommendations before it. The ultimate goal for your NGFW implementation should be to end up with granular visibility and full inspection into as much traffic as possible to prevent threats. Robust decryption processes and policies based on your organization's security and privacy needs are required to achieve this so that you end up with a very small amount of uninspected traffic or, ideally, none at all.
When deciding whether or not you want to decrypt traffic, consider your risk tolerance versus user impact tolerance. For example, how many support calls are you willing to accept from frustrated employees that a decryption profile may potentially cause versus how likely that traffic category is to contain threats and how much risk you're willing to accept.
Before traffic decryption through Palo Alto Networks next-generation firewalls can happen, you must first consider your ability to provide a certificate authority (CA) with which the firewall can establish trust. A CA makes sure that certificates used to enable encrypted communication aren't fake, outdated, or malicious and provides your NGFW with the keys to decrypt it.
If you've got a PKI (Public Key Infrastructure), or internal certificate authority, then the difficult part is already done. If you don't have a PKI, then there's some additional setup work that needs to be done.
Use this environment to generate subordinate certificate authorities, or sub-CAs, and deploy them on your firewall. If your PKI is already established, you can manage, distribute, and control trust certificates through it.
Figure 1: Validate against OCSP or CRL servers to check for revoked certificates
PKIs typically include certificate revocation lists (CRLs), which list certificates that have been revoked for reasons that include improper issuance by the certificate authority (CA) and private keys that have been compromised. PAN-OS® can check for certificate status through CRL servers, as well as through Online Certificate Status Protocol (OCSP). Enable certificate checking within the decryption settings on the firewall to check for revoked certificates and block access to applications that use them.
Figure 2: Two modes of decryption within the NGFW
You'll need to use a self-signed certificate and deploy the trust side of this certificate across all laptops and servers. This method of establishing trust can be difficult to manage, especially if you have a large number of employees in remote locations, because the certificates on those endpoints must also be maintained.
As mentioned previously, there are several reasons why you may not want to decrypt all traffic. So how do you begin determining what traffic you do want to decrypt?
Because many threats utilize file sharing and social media applications, you may want to start with decryption in these categories. The following is a list of URL categories with which we recommend starting:
Choose a category you want to start with and apply a decryption profile to it. Once you've worked through any associated issues, choose the next category you want to decrypt. Remember to try new decryption policies through a test group first before extending them to the rest of your organization, considering both specific users and destinations (URLs or IPs) that will need to bypass the decryption rule.
The following is a list of sensitive categories that should be bypassed for decryption:
Eventually, an ideal decryption rule set should have a decrypt-all policy with specific exceptions for sensitive categories and websites with decryption breakages.
Figure 3: Decryption exceptions may include specific source users or groups, destination IPs and URLs, and sensitive URL categories
Though privacy regulations may prohibit you from decrypting certain kinds of traffic, thus forcing you to accept any risk of threats associated with that traffic at a network level, this doesn't mean you cannot still protect your organization. For traffic that you cannot decrypt, apply a rule that alerts you to SSL traffic on non-standard ports so you can investigate and identify legitimate and illegitimate usage.
Before you start decrypting traffic, review proposed decryption policies with your legal team to make sure you comply with any applicable regulations within the regions where your users are located.
Once you've gotten legal and executive approval to move forward, set up a small group of users on whom to test new decryption policies. This will allow you to understand the impact of your decryption policies and test processes you create for sites that will not decrypt. Implementing Palo Alto Networks User-ID™ technology will help you more easily carve out groups of users to whom you will deploy decryption policies and whom you may need to bypass (legal teams, for example), especially if you already have groups set up within Active Directory.
It's important to keep this test group active even after you've implemented decryption policies across your organization. There may be new forms of encryption for which Palo Alto Networks releases support, and maintaining your test group ensures that you're always prepared to analyze the effect of newly supported decryption with minimal impact to your organization.
Not all encrypted traffic can be decrypted by your firewall, such as traffic using unsupported ciphers or client-side certificates, or applications where the certificate is embedded in the source code, so it's important to figure out how you're going to handle these applications. After you've set up your test group, come up with a process for traffic that you currently cannot decrypt. Make it a habit to review this process on a regular basis.