Palo Alto Decryption Logs Explained & Quiz

Understanding Decryption Logs

Decryption logs are generated for sessions governed by a decryption policy rule, including sessions with a no-decrypt policy rule. Details such as the decryption policy rule that controls the traffic, the cipher suite used, and other TLS handshake information help with monitoring decryption activity and troubleshooting any issues. For example, you can filter decryption logs by a specific decryption log error or error index to pinpoint and address specific issues such as expired certificates.

By default, decryption logs record details of unsuccessful TLS handshakes. You can log successful TLS handshakes in decryption policy rules.

Note: If you log successful TLS handshakes, ensure that you have sufficient system resources (log space).

Configure decryption logging in the decryption policy rules that control the traffic you want to log. To log traffic that you don't decrypt, create a policy-based decryption exclusion and, for rules that govern TLSv1.2 and earlier traffic, apply a No-decryption profile to the decryption policy rule.

Important: If you forward decryption logs for storage, ensure that you properly secure log transport and storage because these logs contain sensitive information.

For reasons such as version support, encrypted portions of TLS handshakes, or information availability, some parameters are not available for every proxy type or TLS version. Unsupported Parameters by Proxy Type and TLS Version lists these parameters.

Next-Generation Firewalls (NGFWs) don't generate decryption log entries for web traffic blocked during SSL/TLS handshakes. These sessions don’t appear in decryption logs because the NGFW prevents decryption when it resets the SSL/TLS connection, ending the handshake. You can view details of the blocked sessions in the URL filtering logs.

SSH Proxy traffic isn't captured in decryption logs. In addition, certificate information isn't available for session resumption logs.

Supported Platforms

• Strata Cloud Manager
• PAN-OS & Panorama

Configuration Steps

1. Configure Logging in Decryption Policy:

   Configure the decryption traffic you want to log in a decryption policy rule ( Policies > Decryption ). By default, the NGFW logs only unsuccessful TLS handshakes:

   

   Log successful handshakes as well as unsuccessful handshakes to gain visibility into as much decrypted traffic as your device's available resources permit (don't decrypt private or sensitive traffic; follow decryption best practices and decrypt as much traffic as you can).

2. Configure Log Forwarding:

   Create a Log Forwarding profile to forward decryption logs to log collectors, other storage devices, or specific administrators, and then specify the profile in the Log Forwarding field of the decryption policy rule Options tab.

   To forward decryption logs, you must configure a Log Forwarding profile ( Objects > Log Forwarding ) to specify the decryption Log Type and method of forwarding the logs.

   

   Store forwarded decryption logs securely because they contain sensitive information.

3. Configure Log Storage Quota:

   If you log successful TLS handshakes in addition to unsuccessful TLS handshakes, configure a larger log storage space quota ( Device > Setup > Management > Logging and Reporting Settings > Log Storage ) for decryption logs.

   The default quota (allocation) is one percent of the device's log storage capacity for decryption logs and one percent for the general decryption summary. There is no default allocation for hourly, daily, or weekly decryption summaries.

   

   Many factors determine the amount of storage you might need for decryption logs and they depend on your deployment. For example, take these factors into account:

   • The amount of TLS traffic that passes through the NGFW.
   • The amount of TLS traffic that you decrypt.
   • Your usage of other logs (evaluate from which logs you should take capacity to allocate to decryption logs).
   • If you log both successful and unsuccessful TLS handshakes, you probably need more capacity than you need to only log unsuccessful TLS handshakes. Depending on the amount of traffic you decrypt, decryption logs could consume as much capacity as Traffic logs or Threat logs and may require a tradeoff among them if the device's capacity is fully subscribed.

   The total combined allocation of log quotas cannot exceed 100% of the available NGFW log resources.

   You may need to experiment to find the right quota for each log category in your particular deployment. If you only log unsuccessful handshakes, you could start with the default or increase the allocation to two or three percent. If you log both successful and unsuccessful handshakes, you could start by allocating about half of the space to decryption logs that you allocate to Traffic logs. The logs from which you take the space to allocate to decryption logs depends on your traffic, your business, and your monitoring requirements.