Manage Client-Based Zero Trust Access in Secure Access

Zero Trust Access means that no one is trusted by default, whether inside or outside the network, and verification is required from everyone trying to gain access to resources on the network. Enrolling in Zero Trust Access implies an enhanced level of security that reduces the attack surface by ensuring that only authenticated and authorized users and devices can access specific resources. This method aligns well with cloud adoption, remote work, and mobile device usage by securing access regardless of location.

Cisco Secure Client supports Zero Trust Access to private resources and internet resources from user devices. To use the Secure Client with Zero Trust Access on a supported device, a user must enroll in Zero Trust Access on the Secure Client. Secure Client is Cisco's endpoint security client application that enables secure connections to private resources, SaaS apps, and internet resources protected by Secure Access. Secure Client is configured with various software modules. A Secure Client module may require the deployment of a certain profile to run module successfully. A system configuration manager or remote monitoring and management (RMM) system can download, install, and deploy the Secure Client on an organization's user devices. For more information about the Secure Client, see Cisco Secure Client (including AnyConnect) Administrator Guide, Release 5.1.

Zero Trust Access (ZTA) and VPN share some similarities despite have independent purposes. Both allow for remote access and encryption that allow for enhanced security. See the following benefits that come with enabling ZTA:

• Zero Trust Access is enabled for each private resource.
• Remote users connect to specific private resources rather than to an entire network, minimizing risk surface area.
• An attacker who breaches a device or zero-trust connection cannot glean information about your internal network.
• You can allow authorized users of unmanaged devices to connect to specific resources without granting them access to your network. You will enable browser-based zero trust access for those resources, then distribute a dummy URL to those users, so the real address is not exposed. This solution lets you securely provide browser-based access to end users such as:
  • Contractors, vendors, trainers, outside legal counsel, and others.
  • Employees on leave.
• End-users' endpoint/device posture is evaluated continuously to verify that the end-user device meets requirements. Posture can be assessed each time they access a resource, rather than just once when they join the network.
• When access to a resource is blocked, client-based users see a block page rather than a browser time-out error.
• Simpler setup and faster performance than VPN.
• Remote users can connect to internal resources in situations where they cannot use VPN. For example, an employee who is visiting a customer or vendor site can connect.
• Users do not need to log in separately to the network before they can access resources configured for zero trust access. 
• After a user with a managed device has completed initial setup of Cisco Secure Client, the user has the same experience accessing a resource whether in the office or working remotely.

So why are they different and what would you need them for?

Zero Trust Network Access (ZTNA) provides access only to specific authorized applications, not the entire network, reducing the attack surface whereas VPN grants users access to the entire network or a network segment once connected, which can expose broad resources.

Furthermore, ZTA is mostly a clientless function that is accessible with just a web browser. It also hides applications from the internet, enforces least privilege access, and continuously assesses device posture and user context, enhancing security with direct connection to applications across the web and cloud or data centers; VPN primarily creates client-to-tunnels that can expose the network unnecessarily.

We strongly recommend utilizing VPN for environments with broad network access and network segmentation is limited. See the following scenarios where enabling VPN might be more beneficial:

• To allow end users to connect to all resources on the network that are not configured to disallow VPN access.
• To enable connections to private destinations that are not configured as private resources.
• To enforce some endpoint requirements that are not currently available in client-based zero-trust posture profiles.
• While transitioning your organization to Zero Trust Access.

To allow these users to access the resource, use the solutions described on this page to ensure that the egress IP address associated with their devices is within your organization's IP address space. Read through the following use cases and required licenses for a full explanation of functionality.

You can block specific URLs and websites with either a rule or security profile configured to block within your access policy but ZTA does not enforce block actions at the DNS level. This generates a blank web page instead of the expected block page.

To block HTTPS pages with a ZTA security profile, you must Configure End-User Notifications so the Decryption setting is set to End-User Notification Only.

For users implementing client-based ZTA on an Edge v2 infrastructure, a fixed public IP address tied to a specific geographic cloud region might be required. Predictable IPs like this can improve operational efficiency and reliability for distributed operations. This applies the two following use cases:

• Organizations without a default route per region.

• Organizations with a default route and a restrictive firewall that does not support FQDN-based rules. Any IP range must be added to the Access Control List (ACL).

Refer to the following table for available IP addresses per region.

ZTA rules configured for Internet Access execute traffic interception that can hinder captive portal detection performed by the OS and remediation by the user. For rules configured to Use ZTA to secure all internet destinations intercept all traffic by default. To allow for OS remediation to happen, the ZTA agent must detect captive portals itself and disable interception while the endpoint is in that condition.

The ZTA agent's Captive Portal Detection Service is responsible for detecting changes in endpoint captive portal conditions and starts when there is a network change. It detects by probing the following HTTP urls per platform:

• Windows: http://www.msftconnecttest.com/connecttest.txt

  Response: "Microsoft Connect Test" with Status Code 200

• macOS and iOS: http://captive.apple.com

  Response: "<HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML>" with Status Code 200

• Android: http://connectivitycheck.gstatic.com/generate_204 Empty

  Response with Status Code 204

If the expected response is received, then it's deemed that the endpoint is not behind a captive portal. Otherwise if the initial probe times out (two seconds for DNS, two seconds for the remainder) or is otherwise inconclusive, probes will be retried at lower frequency until a response is received. If the initial probe returns any HTTP response that does not match the expected response, then it's deemed that the endpoint is behind a captive portal. The service then continues to probe frequently until it detects that the OS has remediated and the endpoint is no longer behind a captive portal.

Note

Captive portal detection service requires a network change debounce timeout that is shorter than the current 5 second default.

When endpoint is etected behind a captive portal, the ZTA agent disables interception for all ProxyConfigs to avoid intercepting captive portal remediation traffic. Interception resumes when it's detected that the endpoint is no longer behind a captive portal.

When a Zero Trust Access request passes through the different services in Secure Access, various scenarios or configurations generate a variety of logs. See the following explanations on how to investigate and process the logs created:

ZTA With Secure Private Access (SPA) Using Private Resources

• Zero Trust Access client-based logs for policy enforcement, verdicts and block reasons, as well as any handling issues that prevented enforcing at all.
• Firewall logs in case a security feature (IPS, Security profiles, DLP) is enabled for your Zero Trust Access traffic and is so passed through the firewall service for enforcement.

ZTA With Secure Internet Access (SIA) Using Internet Destinations

• Zero Trust Access client-based logs for request handling and any issues that come up for it, as well as global posture enforcement details in case of a posture block.
• Firewall or Secure Web Gateway (SWG) logs for the outcome of the Secure Access SIA stack policy evaluation, after Zero Trust Access as the headend has handed off the traffic for enforcement.
• DNS logs for the internet DNS resolution that happens at the Zero Trust Access proxy (which is done against the Secure Access resolvers).

These logs can be viewed in either the Activity Search Logs or the S3 Logs.

Zero Trust Access has the following requirements that you must establish or confirm prior to enabling and configuring your environment.

After you’ve enrolled in ZTA, we strongly recommend the following action items to ensure total security and performance:

• Cisco Secure Client Overview

• Configure Timeout Intervals for ZTA Sessions

• Network Authentication for ZTA

• Create and Add a Private Resource

• Configure Client-Based Zero Trust Access for Private Destinations

• Manage Zero Trust Access profiles

• Get Started With Private Access Rules

• Manage User Authentication Profiles

• Manage Threat Defense Devices for Universal Zero Trust Network Access