Identify Weak Protocols and Cipher Suites (Strata Cloud Manager)

Identify Weak Protocols and Cipher Suites (Strata Cloud Manager)

• Filter decryption logs to check TLSv1.0 activity details.

  Decryption logs show successful TLS activity only if you select the Log Successful TLS Handshakes option in a decryption policy rule. If this option is disabled, you can’t see this information.

  1. Use the query (TLS Version = 'TLS1.0') AND (Error Index = 'None') to show successful TLSv1.0 decryption sessions.

     The decryption logs show us that the name of the decryption policy rule that controls the traffic. Now, we know the site that uses TLSv1.0 and can check the decryption policy rule to find the decryption profile that controls the traffic and learn why the traffic is allowed.
  2. Find the decryption profile that controls the traffic to learn why the traffic is allowed.

     1. Select Manage Configuration NGFW and Prisma Access Security Services Decryption, and search for the decryption policy rule you identified earlier.
     2. Scroll to the Profile column of the decryption policy rule. Alternatively, you can select the rule to open it. Then, under Action and Advanced Inspection, find the Decryption Profile.

     Example: The decryption profile associated with the policy rule is old TLS versions support.
  3. Check the Protocol Versions that the decryption profile allows.

     • Under Decryption Profiles, select the profile identified earlier.
     • Under SSL/TLS Decryption, look at the Protocol Min Version and Protocol Max Version.

     Example: The profile allows TLSv1.0 traffic.
  4. Decide if want to allow or block access to the website.

     Ask questions like "Do you need access for business purposes?"

     Another common scenario that results in the NGFW allowing traffic that uses less secure protocols is when that traffic is not decrypted. When you filter the decryption log for TLSv1.0 traffic, if the Proxy Type column contains the value No Decrypt, then a No Decryption policy controls the traffic, so the NGFW doesn't decrypt or inspect it. If you don’t want to allow the weak protocol, modify the decryption profile so that it blocks TLSv1.0 traffic.

     There are many ways you can filter decryption logs to find applications and sites that use weak protocols. For example:

     • Instead of filtering only for successful TLSv1.0 handshakes, filter for both successful and unsuccessful TLSv1.0 handshakes using the query TLS Version = 'TLS1.0'.
     • Filter only for unsuccessful TLSv1.0 handshakes using the query (TLS Version = 'TLS1.0') AND (Error Index = 'None').
     • Filter for all less secure protocols (TLSv1.1 and earlier) using the query TLS Version <='TLS1.1'.
       If you want to filter the logs for other TLS versions, simply replace TLS1.0 or TLS1.1 with another TLS version.
• Decide what action to take for sites that use weak TLS protocols.

  • If you don’t need to access the site for business purposes, the safest action is to block access to the site by editing the decryption policy rule and decryption profile that control the traffic. The decryption log Policy Name column provides the policy name and the decryption policy shows the attached decryption profile (Action and Advanced Inspection tab).
  • If you need to access the site for business purposes, consider creating a decryption policy rule and decryption profile that apply only to that site (or to that site and other similar sites) and block all other traffic that uses less secure protocols.
• Identify traffic that uses less secure key exchange algorithms, for example, RSA.

  1. Filter decryption logs using the query TLS Key Exchange = RSA:

     Select Incidents and Alerts Log Viewer and select Firewall/Decryption.

     From the Policy Name column in the log, we see that the No Decrypt decryption policy rule controls most of the traffic that uses RSA key exchanges and can infer that the NGFW does not decrypt the traffic and allows it without inspection. Because the traffic isn’t decrypted, the NGFW can’t identify the application and lists it as ssl. If you don’t want to allow traffic that uses RSA key exchanges, modify the decryption profile attached to the decryption policy that controls the traffic.

     You can add to the query to further filter the results for a particular SNI or application that you saw in the first decryption log query.
  2. Decide what action to take for traffic that uses less secure key exchange algorithms.

     Block access to sites that use less secure key exchange protocols unless you need to access them for business purposes. For those sites, consider creating a decryption policy rule and decryption profile that applies only to that site (or to that site and other similar sites), and block all other traffic that uses less secure key exchange algorithms.
• Use the decryption logs to identify sessions that use older, less secure authentication algorithms.

  Filter the decryption log to identify older, less secure authentication algorithms. For example, to identify all sessions that use the SHA1 algorithm, use the query TLS Auth = SHA.

  You can add to the query to further drill down into the results. For example, you can add a particular SNI, a key exchange version (such as filtering for SHA1 sessions that also use RSA key exchanges), a TLS version, or any other metric found in a decryption log column.
• Use the decryption logs to identify sessions that use a particular encryption algorithm.

  For example, to identify all sessions that use the AES-128-CBC encryption algorithm, use the query TLS Encryption Algorithm = AES_128_CBC. You can add to the query to further drill down into the results.

  Examples of queries to find other older encryption algorithms include: TLS Encryption Algorithm = DES_CBC, TLS Encryption Algorithm = 3DES_EDE_CBC, and TLS Encryption Algorithm = DES40_CBC.
• Use this methodology and the log Query Builder to create queries to investigate negotiated ECC curves and any other information you find in the decryption logs.