Size Next-Generation Firewalls for Decryption Requirements
Focus
Focus
Network Security

Size Next-Generation Firewalls for Decryption Requirements

Table of Contents

Size Next-Generation Firewalls for Decryption Requirements

Evaluate the amount of SSL decryption your NGFW and Prisma Access deployment can support and decide what to do if you need more CPU resources to support your desired decryption deployment.
Where Can I Use This?What Do I Need?
No separate license required for decryption when using NGFWs or Prisma Access.
Note: The features and capabilities available to you in Strata Cloud Manager depend on your active license(s).
Decrypting encrypted traffic consumes Next-Generation Firewall (NGFW) CPU resources and can affect throughput. In general, the tighter the security (the more SSL traffic you decrypt combined with the more stringent your protocol settings), the more NGFW resources decryption consumes. Work with your Palo Alto Networks SE or CE to size your NGFW deployment and avoid sizing mistakes. Factors that affect decryption resource consumption and therefore how much traffic you can decrypt include:
  • The amount of SSL traffic you want to decrypt. This varies from network to network. For example, some applications must be decrypted to prevent the injection of malware or exploits into the network or unauthorized data transfers, some applications can’t be decrypted due to local laws and regulations or business reasons, and other applications are cleartext (unencrypted) and don’t need to be decrypted. The more traffic you want to decrypt, the more resources you need.
  • The TLS protocol version. Higher versions are more secure but consume more resources. Use the highest TLS protocol version you can to maximize security.
  • The key size. The larger the key size, the better the security, but also the more resources the key processing consumes.
  • The key exchange algorithm. Perfect Forward Secrecy (PFS) ephemeral key exchange algorithms such as Diffie-Hellman Ephemeral (DHE) and Elliptic-Curve Diffie-Hellman Exchange (ECDHE) consume more processing resources than Rivest-Shamir-Adleman (RSA) algorithms. PFS key exchange algorithms provide greater security than RSA key exchange algorithms because the NGFW generates a new cipher key for each session. If an attacker compromises a session key, PFS prevents the attacker from using it to decrypt any other sessions between the same client and server. Generating the new key, however, consumes more NGFW resources.
  • The encryption algorithm. The key exchange algorithm determines whether the encryption algorithm is PFS or RSA.
  • The certificate authentication method. RSA (not the RSA key exchange algorithm) consumes less resources than Elliptic Curve Digital Signature Algorithm (ECDSA), but ECDSA is more secure.
    The combination of the key exchange algorithm and the certificate authentication method affect throughput performance as shown in RSA and ECDSA benchmark tests. The performance cost of PFS trades off against the higher security that PFS achieves, but PFS may not be needed for all types of traffic. You can save NGFW CPU cycles by using RSA for traffic that you want to decrypt and inspect for threats but that isn’t sensitive.
  • Average transaction sizes. For example, small average transaction sizes consume more processing power to decrypt. Measure the average transaction size of all traffic, then measure the average transaction size of traffic on port 443 (the default port for HTTPS encrypted traffic) to understand the proportion of encrypted traffic going to the NGFW in relation to your total traffic and the average transaction sizes. Eliminate anomalous outliers such as unusually large transactions to get a truer measurement of average transaction size.
  • The NGFW model and resources. Newer NGFW models have more processing power than older models.
The combination of these factors determines how decryption consumes NGFW processing resources. To best use the NGFW’s resources, understand the risks of the data you’re protecting. If NGFW resources are an issue, use stronger decryption for higher-priority traffic and use less processor-intensive decryption for lower-priority traffic until you can increase the available resources. For example, you could use RSA instead of ECDHE and ECDSA for traffic that isn’t sensitive or high-priority. This preserves NGFW resources for PFS-based decryption of higher priority, sensitive traffic. (You’re still decrypting and inspecting the lower-priority traffic, but trading off consuming fewer computational resources with using algorithms that aren’t as secure as PFS.) The key is to understand the risks of different traffic types and treat them accordingly.
Measure NGFW performance to understand the currently available resources and determine whether you need more resources to decrypt the traffic you want to decrypt. Measuring NGFW performance also sets a baseline for performance comparisons after deploying decryption. You can also run a proof of concept.
Size your NGFW deployment based on current and future needs. Include headroom for the growth of decryption traffic. Gartner predicts that through 2019, more than 80 percent of enterprise web traffic will be encrypted, and more than 50 percent of new malware campaigns will use various forms of encryption. Work with your Palo Alto Networks representatives to help you size your deployment.