Configure Decryption Logging

Table of Contents

Decryption Logs and Other Monitoring Tools

Configure Decryption Logging

Log successful and unsuccessful TLS handshakes and forward logs to appropriate storage and administrators for analysis.

Where Can I Use This?	What Do I Need?
All NGFW deployments, including those funded by software NGFW credits All Prisma Access deployments	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).

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.

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.

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.

Configure Decryption Logging (Strata Cloud Manager)

Incidents and Alerts: Log Viewer is the home of decryption logs and other log types for NGFW and Prisma Access deployments managed by Strata Cloud Manager. Logs are forwarded to Strata Logging Service only with a valid license; otherwise, logs are saved locally.

Log in to Strata Cloud Manager.
Create or modify a to specify the traffic you want to log.
Configure Log Settings for the decryption policy rule.
1. For Logging, select Log Successful TLS handshakes.
  
  By default, Strata Cloud Manager logs unsuccessful 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. (Optional) Forward decryption logs to Dedicated Log Collectors, other storage devices, or specific administrators.
  If you forward decryption logs, be sure that the logs are stored securely because they contain sensitive information.
  
  Create a Log Forwarding profile to specify the decryption Log Type and the method of forwarding the logs.
  For External Log Forwarding, select the profile you created.
Save your rule.
To commit your changes, click Push Config.

Configure Decryption Logging (PAN-OS)

Configure the decryption traffic you want to log in a decryption policy rule (PoliciesDecryption).

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).
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 (ObjectsLog Forwarding) to specify the decryption Log Type and method of forwarding the logs.

Store forwarded decryption logs securely because they contain sensitive information.
If you log successful TLS handshakes in addition to unsuccessful TLS handshakes, configure a larger log storage space quota (DeviceSetupManagementLogging and Reporting SettingsLog 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.