Decryption Rules and Policy Example

This chapter builds on concepts discussed in this guide to provide a specific example of an SSL policy with decryption rules that follow our best practices and recommendations. You should be able to apply this example to your situation, adapting it to the needs of your organization.

In short:

  • For trusted traffic (such as transferring a large compressed server backup), bypass inspection entirely, using prefiltering and flow offload.

  • Put first any decryption rules that can be evaluated quickly, such as those that apply to specific IP addresses.

  • Put last any decryption rules that require processing, Decrypt - Resign, and rules that block unsecure protocol versions and cipher suites.

Decryption Rule Examples

This section provides an example of decryption rule that illustrate our best practices.

See one of the following sections for more information.

The first decryption rule in the example does not decrypt traffic that goes to an internal network (defined as intranet ). Do Not Decrypt rule actions are matched during ClientHello so they are processed very fast.


Note

If you have traffic going from internal DNS servers to internal DNS resolvers (such as Cisco Umbrella Virtual Appliances), you can add Do Not Decrypt rules for them as well. You can even add those to prefiltering policies if the internal DNS servers do their own logging.

However, we strongly recommend you do not use Do Not Decrypt rules or prefiltering for DNS traffic that goes to the internet, such as internet root servers (for example, Microsoft internal DNS resolvers built into Active Directory). In those cases, you should fully inspect the traffic or even consider blocking it.

Rule detail:

: Decrypt Specific Test Traffic

The next rule is optional in the example; use it to decrypt and monitor limited types of traffic before determining whether or not to allow it on your network.

Rule detail:

Decryption Rules: Block or Monitor Certificates and Protocol Versions

The last decryption rules, because they are the most specific and require the most processing, are rules that either monitor or block bad certificates and unsecure protocol versions.

Rule details:

Example: Decryption Rule to Monitor or Block Certificate Status

The last decryption rules, because they are the most specific and require the most processing, are rules that either monitor or block bad certificates and unsecure protocol versions. The example in this section shows how to monitor or block traffic by certificate status.


Important

Use the Cipher Suite and Version rule conditions only in rules with either the Block or Block with reset rule actions. Do not use Cipher Suite and Version with Decrypt - Resign or Decrypt - Known Key rule actions. These conditions in rules with other rule actions can interfere with the system's ClientHello processing, resulting in unpredictable performance.

Procedure

Step 1

Log in to the Secure Firewall Management Center if you haven't already done so.

Step 2

Click Policies > Access Control heading > Decryption.

Step 3

Click Edit (edit icon) next to your decryption policy.

Step 4

Click Edit (edit icon) next to a decryption rule.

Step 5

Click Add Rule.

Step 6

n the Add Rule dialog box, in the Name field, enter a name for the rule.

Step 7

Click Cert Status.

Step 8

For each certificate status, you have the following options:

  • Click Yes to match against the presence of that certificate status.

  • Click No to match against the absence of that certificate status.

  • Click Any to skip the condition when matching the rule. In other words, choosing Any means the rule matches whether the certificate status is present or absent.

Step 9

From the Action list, click either Monitor to only monitor and log traffic that matches the rule or click Block or Block with Reset to block the traffic and optionally reset the connection.

Step 10

To save changes to the rule, at the bottom of the page, click Add.

Step 11

To save changes to the policy, at the top of the page, click Save.

Example

The organization trusts the Verified Authority certificate authority. The organization does not trust the Spammer Authority certificate authority. The system administrator uploads the Verified Authority certificate and an intermediate CA certificate issued by Verified Authority to the system. Because Verified Authority revoked a certificate it previously issued, the system administrator uploads the CRL that Verified Authority provided.

The following figure shows a certificate status rule condition checking for valid certificates, those issued by a Verified Authority, are not on the CRL, and still within the Valid From and Valid To date. Because of the configuration, traffic encrypted with these certificates is not decrypted and inspected with access control.

The following figure shows a certificate status rule condition checking for the absence of a status. In this case, because of the configuration, it matches against traffic encrypted with a certificate that has not expired.

In the following example, traffic would match this rule condition if the incoming traffic is using a certificate that has an invalid issuer, is self-signed, expired, and it is an invalid certificate.

The following graphic illustrates a certificate status rule condition that matches if the SNI of the request matches the server name or if the CRL is not valid.

Example: Decryption Rule to Monitor or Block Protocol Versions

This example shows how to block TLS and SSL protocols on your network that are no longer considered secure, such as TLS 1.0, TLS 1.1, and SSLv3. It's included to give you a little more detail about how protocol version rules work.

You should exclude nonsecure protocols from your network because they are all exploitable. In this example:

  • You can block some protocols using Version page on the decryption rule.

  • Because the system considers SSLv2 as undecryptable, you can block it using the Undecryptable Actions on the decryption policy.

  • Similarly, because compressed TLS/SSL is not supported, you should block it as well.


Important

Use the Cipher Suite and Version rule conditions only in rules with either the Block or Block with reset rule actions. Do not use Cipher Suite and Version with Decrypt - Resign or Decrypt - Known Key rule actions. These conditions in rules with other rule actions can interfere with the system's ClientHello processing, resulting in unpredictable performance.

Procedure

Step 1

Click Policies > Access Control heading > Decryption.

Step 2

Click Edit (edit icon) next to your decryption policy.

Step 3

Click Edit (edit icon) next to a decryption rule.

Step 4

Click Add Rule.

Step 5

In the Add Rule dialog box, in the Name field, enter a name for the rule.

Step 6

From the Action list, click Block or Block with reset.

Step 7

Click Version page.

Step 8

Check the check boxes for protocols that are no longer secure, such as SSL v3.0, TLS 1.0, and TLS 1.1. Clear the check boxes for any protocols that are still considered secure.

The following figure shows an example.

This sample rule blocks traffic that uses SSL 3.0, TLS 1.0, or TLS 1.1 traffic because such traffic is easily hacked and not secure.

Step 9

Choose other rule conditions as needed.

Step 10

Click Add.

Optional Example: Manual Decryption Rule to Monitor or Block Certificate Distinguished Name

This rule is included to give you an idea about how to monitor or block traffic based on the server certificate's distinguishedname. It's included to give you a little more detail.

The distinguished name can consist of country code, common name, organization, and organizational unit, but typically consists of a common name only. For example, the common name in the certificate for https://www.cisco.com is cisco.com. (However, it's not always this simple; Distinguished Name (DN) Rule Conditions shows how to find common names.)

The host name portion of the URL in the client request is the Server Name Indication (SNI). The client specifies which hostname they want to connect to (for example, auth.amp.cisco.com) using the SNI extension in the TLS handshake. The server then selects the corresponding private key and certificate chain that are required to establish the connection while hosting all certificates on a single IP address.

Procedure

Step 1

Click Policies > Access Control heading > Decryption.

Step 2

Click Edit (edit icon) next to your decryption policy.

Step 3

Click Edit (edit icon) next to a decryption rule.

Step 4

Click Add Rule.

Step 5

In the Add Rule dialog box, in the Name field, enter a name for the rule.

Step 6

From the Action list, click Block or Block with reset.

Step 7

Click DN.

Step 8

Find the distinguished names you want to add from the Available DNs, as follows:

  • To add a distinguished name object on the fly, which you can then add to the condition, click Add (add icon) above the Available DNs list.

  • To search for distinguished name objects and groups to add, click the Search by name or value prompt above the Available DNs list, then type either the name of the object, or a value in the object. The list updates as you type to display matching objects.

Step 9

To select an object, click it. To select all objects, right-click and then Select All.

Step 10

Click Add to Subject or Add to Issuer.

Tip

 

You can also drag and drop selected objects.

Step 11

Add any literal common names or distinguished names that you want to specify manually. Click the Enter DN or CN prompt below the Subject DNs or Issuer DNs list; then type a common name or distinguished name and click Add.

Although you can add a CN or DN to either list, it's more common to add them to the Subject DNs list.

Step 12

Add or continue editing the rule.

Step 13

When you're done, to save changes to the rule, click Add at the bottom of the page.

Step 14

To save changes to the policy, click Save at the top of the page.

Example

The following figure shows a distinguished name rule condition searching for certificates issued to goodbakery.example.com or issued by goodca.example.com. Traffic encrypted with these certificates is allowed, subject to access control.

This sample rule condition adds the GoodBakery Distinguished Name to the Subject DNs list and its corresponding Common Name to the Issue DNs list. This has the effect of matching traffic on either the subject or the issuer, although it's more common to match on the subject only.

Associate the Decryption Policy with an Access Control Policy and Advanced Settings

This task discusses how to associate the decryption policy with an access control policy and setting recommended advanced settings for the access control policy.

For your decryption policy to be used by the system, you must associate it with an access control policy.

Before you begin

Create the sample decryption policy as discussed in this guide.

For more information about decryption policy advanced options, see Decryption Policy Advanced Options.

Procedure

Step 1

Log in to the Secure Firewall Management Center if you haven't already done so.

Step 2

Click Policies > Access Control heading > Access Control.

Step 3

Either create a new access control policy or click Edit (edit icon) to edit an existing one.

Step 4

Click the word Decryption as the following figure shows.

In the firewall management center, for the access control policy, click the word Decryption to select a decryption policy to associate

Step 5

From the list, click the name of your decryption policy and also check Early application detection and URL categorization as the following figure shows.

For the selected decryption policy, select the Early application detection and URL categorization check box

Step 6

Click Apply.

Step 7

Click More > Advanced Settings as the following figure shows.

Select the access control policy's Advanced Settings

Step 8

Click Edit (edit icon) next to TLS Server Identity Discovery.

Step 9

Select the check box as the following figure shows.

In the access control policy's Advanced Settings, select the Server Identity Discovery check box

Step 10

Click OK.

Step 11

At the top of the page, click Save.

Step 12

At the top of the page, click Return to Access Control Policy Management, as the following figure shows

At the top of the page, click Return to Access Control Policy Management

Step 13

Click Edit (edit icon) to edit the access control rule.

Step 14

At the bottom of the page, next to the default action, click (Default Logging and Inspection).

Step 15

Check Log at beginning of connection and any other options you choose.

For more information, see Logging Settings for Access Control PoliciesLogging Settings for Access Control Policies in the Cisco Secure Firewall Management Center Device Configuration Guide.

Step 16

Click Apply.

Step 17

At the top of the page, click Save.

What to do next

Traffic to Prefilter

Prefiltering is the first phase of access control, before the system performs more resource-intensive evaluation. Prefiltering is simple, fast, and early compared to subsequent evaluation, which uses inner headers and has more robust inspection capabilities.

Based on your security needs and traffic profile, you should consider prefiltering and therefore excluding from any policy and inspection the following:

  • Common intraoffice applications such as Microsoft Outlook 365

  • Elephant flows, such as server backups

Decryption Rule Settings

How to configure recommended best practice settings for your decryption rules.

Decryption rules: Enable logging for every rule except those with a Do Not Decrypt rule action. (It's up to you; if you want to see information about traffic that isn't decrypted, enable logging for those rules also.)

Procedure

Step 1

Click Policies > Access Control heading > Decryption.

Step 2

Click Edit (edit icon) next to your decryption policy.

Step 3

Click Edit (edit icon) next to a decryption rule.

Step 4

Click the Logging tab.

Step 5

Click Log at End of Connection.

Step 6

Click Save.

Step 7

Click Save at the top of the page.