What is Zero Trust Access?

Every organization has their own interpretation of Zero Trust. However, at a high level, it is about granting USERS access to APPLICATIONS and doing so only after the TRUST is established.

Cisco has been supporting Zero Trust design principles for many years with the Cisco Secure Portfolio. More details about the Cisco Zero Trust Framework and how it maps to various Cisco Secure products are available here.

This document covers the Zero Trust Application Access policy feature on Cisco Secure Firewall Threat Defense (FTD). Starting release 7.4, we can configure Zero Trust policies for access to browser-based applications.

Cisco Zero Trust Access for Hybrid Environments

• Consistent and uniform solution across Cloud and On-Prem
• Route applications to enforcement points based on per-application policy
• Unified experience with easy migration support

Remote Access VPN vs ZTNA

There are large differences based on how the access is granted.

Clientless Zero Trust Access for Applications

The Clientless Zero Trust Access for Applications, moves beyond traditional "authorize then trust" ZTNA models by adding complete threat inspection for each application access. It introduces a new Zero Trust Application Policy.

1. New Policy Type
2. Create a per-app Zero Trust Application policy or create application groups which share a Zero Trust Application policy.
3. Object-based to share settings across Application Policies such as:
   1. Certificates
   2. Intrusion and Malware Policies
   3. Security Zones
   4. SAML IdP configuration

How does it work

Prerequisites

Software Requirements - Snort3 only, Multi-Instance, High Availability and Cluster are Supported

Licensing- Essentials (Base) License, Threat License needed only if using Intrusion or Malware Policy

DNS - DNS server configuration is required

The user's DNS server should resolve the Application FQDN to the Firewall's Internet-facing interface IP

The Firewall's DNS server should resolve the Application FQDN to the Internal IP of the protected application

Certificates

There are three types of certificates required

1. Identity Certificate - This is the certificate presented by the Firewall to the user when they enter the FQDN in the browser
2. SAML IdP Certificate - This is used to validate the SAML assertions for each application or a group of applications
3. Application Certificate - The Firewall uses this to decrypt the application traffic for inspection and authorization of the user to access the application.

🚧

Note

This document does not cover the detailed steps for Installing Certificates, Licensing and DNS configuration. They are covered in the configuration guides referenced at the end.

Install Certificates

Step 1: We begin by installing the Identity Certificate which is presented by the Firewall when the users are prompted for authentication, after entering the application URL in the browser. Since this certificate can be presented for authenticating to one application or multiple applications which are part of an Application Group, it must either be a wildcard certificate or include the URLs of the all the applications in SAN (Subject Alternative Name).

Step 2: Navigate to Devices > Certificates and click Add. Select the Firewall from the Device from the dropdown menu.

Step 3: Click + to add the new certificate using the enrollment method of your choice. In this example, we are naming the certificate ZTAA_Policy_Cert and using PKC12 enrollment. Check only the SSL Client and SSL Server options.

Step 4: Click Save and Add when returned to the original Add New Certificate window.

Step 5: Confirm that the certificate is successfully enrolled. The CA and ID certificates should be visibile in the Status column.

Step 6: Now add the SAML IdP certificate. The Firewall will use this certificate to validate the SAML Assertions.

Step 7: From the same certificates page, click Add. Select the same Firewall and click + to add the new certificate enrollment.

Step 8: Name the certificate as Azure_SAML_Cert and choose the enrollment type as Manual and enable CA Only.

Step 9: Now we will add the Application Certificate. The Firewall performs known-key decryption of the application traffic in order to apply the Intrusion, File and Malware inspection. This certificate is added as an Internal Certificate. Navigate to Objects > Object Management > PKI > Internal Certs. Click Add Internal Cert.

Step 10: Enter the name of the certificate, and choose the Certificate and Key files. If the file is encrypted, enter the password.

Step 11: Click Save and confirm that the certificate is successfully installed.

Configure Zero Trust Policy

Step 1: Navigate to Policies > Zero Trust Application Policy. This is the new policy page added to configure Zero Trust access policies for one or more applications.

📘

Note:

If you are configuring your first policy, then you will see a page with the list of requirements you should complete, before you configure the policy. Click Add Policy to create the policy.

Step 2: Now you will define the Zero Trust Application Policy which will have Global settings that will be applied to the Applications that are protected by this policy. This policy is going to protect a group of Engineering Applications. In this example we have configured:

• Name: ZeroTrust_Policy_Engineering_Apps
• Domain Name: tmelab.com
• Identity Certificate: ZTAA_Policy_Cert

• Security Zones: Outside (This is the interface zone which is reachable over the internet for the user)
• Global Port Pool: 20000-22000 (Leave it at default values)

• Intrusion Policy: Demo IPS
• Variable Set: Default-Set
• Malware and File Policy: Demo File Policy

📘

Note

As you can see we are configuring Security controls for the Zero Trust Application Policy. The Firewall doesn't perform authn/authz as the authentication and authorization are handled by the idP. The Firewall performs a full security stack inspection on the authenticated and authorized flow.

Click Save to save the settings. Now, we will configure the application specific settings.

Step 3: Since we are protecting multiple applications which share the Global Settings (domain name, Identity Certificate, Security Controls etc.), we will create an Application Group. Click Application Group.

In this example we have configured as shown here

Name: Engineering_Apps_Group

SAML Service Provider (SP) Metadata: This is generated automatically. You can download it and upload it in the SAML IdP to configure the application.

Click Next.

📘

Note

The Entity ID and Assertion Consumer Service URL are automatically generated using the feilds from the Global Settings configured in the previous steps:

• Domain name (configured in global policy settings): tmelab.com
• Application Group name: Engineering_Apps

The doc does not cover the configuration of this application in the SAML IdP providers such as Azure in this example.

SAML Identity Provider (IdP) Metadata: This is the metadata from the SAML IdP used to authenticate the users. You are allowed to configure it later in case this information is current available. You can import this from your SAML provider or configure it manually along with the certificate generated earlier Azure_SAML_Cert.

📘

Note

Here we are not covering the SAML IdP configuration. It is recommended to use the Import IdP Metadata option to prevent any errors due to typos or missing info.

Re-Authentication Interval: 1440 minutes (Leave it at default values)

Security Zones and Security Controls: By default these settings are inherited from the Policy level global settings we configured previously. However, it is allowed to override these. e.g. Individual IPS and Malware policies for each application group.

Step 4: After clicking Next, review the summary to ensure that the configuration is accurate. Click Finish.

Step 5: Now we add the applications to the Zero Trust Application group we just created. Click Add Application and configure as shown below:

• Application Name: Engineering_Wiki
• External URL: https://secureapp1.tmelab.com
• Application URL: https://secureapp1.tmelab.com
• Use External URL as Application URL: Enabled

📘

Note

External URL : The user enters this URL in the browser and it should resolve to the Public Interface of the Firewall.

Application URL: The URL Firewall uses to reach the internal application. This should resolve to the internal IP address of the application.

Use External URL as Application URL: In this example we have kept it enabled. However, depending on the environment, you can uncheck this and provide a different Application URL which is reachable from the Firewall's internal interface.

• Application Certificate: Engineering_Application_1 This is the Internal Cert used by the Firewall to decrypt the communication between the user and the application.
• Application Group:Engineering_Apps_Group

Step 6: Click Next. You will see a summary with the new application added and Enabled. Validate the values provided to ensure accuracy. Click Finish. Repeat Step 5 to add more applications with different details.

Step 7: Now we need to assign the Zero Trust Application Policy to the Firewall safeguarding these applications. Click 0 devices next to Targeted. Choose the correct Firewall and click Apply.

📘

Note

There are bulk actions available as well, if multiple Applications are selected.

Step 8: Click Save to save the changes and Deploy to deploy the policy to the Firewall. Upon successful completion, the deployment status will show up as Completed.

Accessing the Applications

To access the protected applications, from your browser enter the URL https://secureapp1.tmelab.com.

It will prompt you to authenticate the SAML IdP you configured. The SAML IdP will authorize the user successfully only if the user is added to the application configuration on the IdP.

Upon successful authentication, you will be redirected to the Firewall, where the SAML Assertion is validated and you are allowed to access the application. You will notice that one of the ports from the Global Port Pool has been added to the URL in the browser.

Now all communication to this application is decrypted by the Firewall using known-key decryption. The flow can be inspected by the Firewall using the Intrusion, File and Malware policies configured earlier.

Here you can see how the Event Viewer shows the communication to applications protected by the Zero Trust Application Policy. You can see flows matching the Zero Trust Application policy and also an Intrusion Event which was triggered by the user while communicating with the application.

The below Intrusion event example shows that threats detected in ZTAA also display MITRE information associated with it. The tactic shown here is 'Execution', the technique is 'User Execution' and the sub-technique is 'Malicious File'.

🚧

Disclaimer

The names in the screenshot are used for reference only.

Key Benefits/Use Cases

• Provide 3rd Party vendors/Contractors access to internal applications.
• Browser-based access without the need for a client/agent software, using DNS-based traffic routing
• Reduction of attack surface by enforcing per-application access control and enforcing full Security controls like Decryption, IPS and Malware, preventing lateral spread of threats
• The firewall acts as an authentication and authorization proxy preserving original client IP addressing for visibility and monitoring.
• SAML SSO support if the protected application uses a common idP as the Zero Trust Access policy
• Supports the Zero Trust adoption while leveraging existing investments in Secure Firewall
• Allow some ASA WebVPN deployments to move to FTD
• Majority of the Large Enterprises still host applications within on-prem Data Centers, Zero Trust on Firewall protects On-prem Private Applications without backhauling to a SaaS based Zero Trust Access solution

📚Additional Resources

To learn more about the Zero Trust Application Policy on the Cisco Secure Firewall, refer to the following publication:

• Zero Trust Application Policy Configuration Guide