Network Security
Size Next-Generation Firewalls for Decryption Requirements
Table of Contents
Expand All
|
Collapse All
Network Security Docs
-
- Security Policy
-
- Security Profile Groups
- Security Profile: AI Security
- Security Profile: WildFire® Analysis
- Security Profile: Antivirus
- Security Profile: Vulnerability Protection
- Security Profile: Anti-Spyware
- Security Profile: DNS Security
- Security Profile: DoS Protection Profile
- Security Profile: File Blocking
- Security Profile: URL Filtering
- Security Profile: Data Filtering
- Security Profile: Zone Protection
-
- Policy Object: Address Groups
- Policy Object: Regions
- Policy Object: Traffic Objects
- Policy Object: Applications
- Policy Object: Application Groups
- Policy Object: Application Filter
- Policy Object: Services
- Policy Object: Auto-Tag Actions
- Policy Object: Devices
-
- Uses for External Dynamic Lists in Policy
- Formatting Guidelines for an External Dynamic List
- Built-in External Dynamic Lists
- Configure Your Environment to Access an External Dynamic List
- Configure your Environment to Access an External Dynamic List from the EDL Hosting Service
- Retrieve an External Dynamic List from the Web Server
- View External Dynamic List Entries
- Enforce Policy on an External Dynamic List
- Find External Dynamic Lists That Failed Authentication
- Disable Authentication for an External Dynamic List
- Policy Object: HIP Objects
- Policy Object: Schedules
- Policy Object: Quarantine Device Lists
- Policy Object: Dynamic User Groups
- Policy Object: Custom Objects
- Policy Object: Log Forwarding
- Policy Object: Authentication
- Policy Object: Decryption Profile
- Policy Object: Packet Broker Profile
-
-
-
- The Quantum Computing Threat
- How RFC 8784 Resists Quantum Computing Threats
- How RFC 9242 and RFC 9370 Resist Quantum Computing Threats
- Support for Post-Quantum Features
- Post-Quantum Migration Planning and Preparation
- Best Practices for Resisting Post-Quantum Attacks
- Learn More About Post-Quantum Security
-
-
-
- Investigate Reasons for Decryption Failure
- Identify Weak Protocols and Cipher Suites
- Troubleshoot Version Errors
- Troubleshoot Unsupported Cipher Suites
- Identify Untrusted CA Certificates
- Repair Incomplete Certificate Chains
- Troubleshoot Pinned Certificates
- Troubleshoot Expired Certificates
- Troubleshoot Revoked Certificates
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.