Size Next-Generation Firewalls for Decryption Requirements
Evaluate the amount of SSL decryption your NGFW deployments 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.
