Zscaler Digital Transformation Administrator Study Guide PDF

STUDY GUIDE: Zscaler Digital Transformation Administrator (ZDTA) Certification Zscaler Digital Transformation................................................................................................... 3 How to Use This Study Guide.............................................................

STUDY GUIDE: Zscaler Digital Transformation Administrator (ZDTA) Certification Zscaler Digital Transformation................................................................................................... 3 How to Use This Study Guide..................................................................................................3 About the ZDTA Exam............................................................................................................. 3 Exam Format..................................................................................................................... 3 Audience & Qualifications........................................................................................................4 Skills Required................................................................................................................... 4 Recommended Training.....................................................................................................4 Core Skills................................................................................................................................5 Identity Services.................................................................................................................5 Authentication and Authorization to the Zero Trust Exchange.....................................6 SAML Authentication................................................................................................... 7 SCIM Authorization.................................................................................................... 10 Basic Connectivity............................................................................................................13 Connecting to the Zero Trust Exchange (ZTE).......................................................... 14 Zscaler Client Connector........................................................................................... 15 App Connectors......................................................................................................... 39 Browser Access & Privileged Remote Access...........................................................43 Platform Services.............................................................................................................46 Zscaler's Platform Services Suite.............................................................................. 47 Device Posture...........................................................................................................48 TLS Inspection........................................................................................................... 49 Policy Framework...................................................................................................... 62 Analytics & Reporting.................................................................................................67 Zscaler Digital Experience............................................................................................... 70 Introduction to Zscaler Digital Experience................................................................. 71 Monitoring Digital Experience.................................................................................... 82 Access Control.................................................................................................................86 Access Control Overview...........................................................................................87 Zscaler's Access Control Services Suite....................................................................88 Cybersecurity Services.................................................................................................... 96 Cybersecurity Overview............................................................................................. 97 Zscaler's Cybersecurity Services Suite....................................................................104 1 Basic Data Protection Services......................................................................................117 Data Protection Overview.........................................................................................119 Protecting Data in Motion.........................................................................................123 Protecting Data at Rest............................................................................................131 Incident Management.............................................................................................. 133 Basic Troubleshooting Tools & Support......................................................................... 135 Zscaler Self Help Services.......................................................................................136 Zscaler Troubleshooting Process & Tools................................................................138 Zscaler Customer Support Services........................................................................ 146 2 Zscaler Digital Transformation Administrator How to Use This Study Guide Welcome to the Zscaler ZDTA Study Guide, which will serve as your go-to resource in preparing for the ZDTA exam and receiving your ZDTA certification. About the ZDTA Exam The Zscaler Digital Transformation Administrator (ZDTA) is a formal, third‐party proctored certification that indicates that those who have achieved it possess the in‐depth knowledge to design, install, configure, maintain, and troubleshoot most Zero Trust Exchange implementations. Exam Format Certification name: Zscaler Digital Transformation Administrator (ZDTA) Delivered through: Certiverse, our online testing platform Exam series: Zscaler Digital Transformation Seat time: 90 minutes Number of items: 50 Format: Multiple Choice, Scenarios with Graphics, and Matching Languages: English Exam Domain Weight (%) Identity Services 4 Basic Connectivity 20 Platform Services 15 Zscaler Digital Experience 10 Access Control 15 Cybersecurity Services 20 Basic Data Protection 16 3 Audience & Qualifications The ZDTA exam is for Zscaler customers as well as all who sell and support the Zscaler platform. By taking the exam, you are demonstrating your deep understanding and knowledge needed to sufficiently drive operational success. Candidates should have a: Minimum of 5 years working in both IT networks and cybersecurity Minimum of 1 year experience with the Zscaler platform Skills Required Ability to professionally design, implement, operate, and troubleshoot the Zscaler platform Ability to adapt legacy on-premises technologies and legacy hub-and-spoke network designs to modern cloud architectures Recommended Training Zscaler recommends that you have first attended the Zscaler for Users (EDU-200) course and hands-on lab, or have solid hands-on experience with ZIA, ZPA and ZDX. 4 Core Skills Identity Services Identity Integration will teach you how to authenticate users to the Zero Trust Exchange. This chapter will enable you to understand how to authenticate users to the Zero Trust Exchange, and how user attributes are consumed for policy. —– By the end of this chapter, you will be able to 1. Recognize how authentication mechanisms work and how they are integrated with Zscaler. 2. Discover how to configure Zscaler Identity Integration services and capabilities. 5 Authentication and Authorization to the Zero Trust Exchange The first thing we do when we connect to the Zero Trust Exchange is verify identity and context, while also consuming attributes for policy. Usually that means connecting to a SAML identity provider (IdP), but in the case of Zscaler Internet Access, it could be other methods such as LDAP or a hosted database. Once we understand the user context, we can control risk through inspection and data protection, and then we can enforce policies such as Allow, Block, Isolate, and Prioritize. Based on attributes of the user and the device, Zscaler Internet Access covers SaaS applications and internet applications. Zscaler Private Access configures connectivity to private applications and resources hosted at Infrastructure as a Service, Platform as a Service, or your private data center. The identity integration enables us to do SAML or LDAP authentication with customer directories. Once we consume identity, we can apply policy based on that identity and device posture, and then log and report on access activity. Once we consume that information, we're able to apply per-user and per-device-based URL filtering, application segmentation, tenant restrictions, and provide adaptive access to private applications. Zscaler integrates with multiple partners and we're specifically going to talk about our Identity Management framework and how we integrate with Active Directory, Azure Active Directory, ADFS, Okta, Ping, or really any SAML 2.0-compliant identity provider. In the immediate sections that follow, we will talk about configuring SAML and SCIM for Zscaler Internet Access, and Zscaler Private Access in the power of the Zscaler platform to ensure that users get access to the right resources under the right conditions. 6 SAML Authentication SAML is a mechanism for federating identities between an identity store and applications. It provides a Single Sign-On (SSO) of users into services so that if a user is signed into the Identity Provider, they can access applications transparently without reauthentication. It also enables the exchange of credentials across a few key components. Components Service Provider (SP) Identity Provider (IdP) Security Assertions The “Application” Authenticates Users/Devices Also known as Tokens Also known as the Relying Party Provides Identifiers and Identity Issued to users by the IdP (RP) to the Identity Provider (IdP) Assertions for users that wish to access a service. Presented to SPs / RPs to Employs the services of an IdP confirm authentication for the Authentication and IdP examples include: Okta, Authorization of users Ping, AD FS, Azure AD Trust based on PKI Zscaler acts as a SAML SP Assertions may contain: Authentication, Attribute, or Authorization statements 7 How SAML authentication works. We've got the identity provider (IdP) on the left, the users in the middle, and the service provider (SP) on the right is Zscaler. The applications the users will attempt to access on the right-hand side could be public applications like salesforce.com or internal applications that are made available through Zscaler Private Access. The first thing that happens is a request is made for an application. Since the user is not authenticated, at steps 2 and 3, they are redirected to authenticate at either Zscaler Internet Access or Zscaler Private Access. Depending on whether the application is public or private, this request to authenticate will, in turn, lead to a SAML authentication request being sent to the SAML identity provider, which is steps 4 and 5. A SAML authentication request is a message that indicates to the identity provider that a user must authenticate and that a SAML assertion should be returned to the SAML service provider. The identity provider must be configured to trust this particular service provider in order to honor the request and ultimately return a SAML assertion. At this point, the user would be challenged by the identity provider to authenticate. The authentication policy is controlled by the configuration at the IdP, so this could be a simple username and password. Maybe it's Kerberos, or it could be multifactor authentication. 8 Beyond just authenticating users, identity providers can perform additional actions, such as retrieving additional user attributes and group memberships. This data can be included in the SAML assertion. The final thing the identity provider does is assemble the SAML assertion and cryptographically secure it using a digital signature. The SAML assertion will be delivered to the service provider via the user's browser. This is delivered using a form POST that is automatically submitted via JavaScript, so the experience to the end user is the same as an HTTP redirect. This is shown here in steps 6 and 7. When Zscaler receives the SAML assertion, it validates the digital signature to ensure it came from a trusted source and that the data wasn't tampered with in transit. Assuming it's cryptographically verified, Zscaler issues an authentication token here at step 8 to the Zscaler Client Connector or a cookie to the user's browser, depending on what client type is being used. At this point, the user is authenticated at Zscaler, and the request for the application can resume via the Zscaler Zero Trust Exchange in step 9. 9 SCIM Authorization Now that you have an understanding of SAML authentication and its workflow, let’s take a look at the next identity integration, SCIM, which works to provide authorization and revoke access for disabled users. What is SCIM? The system for cross-domain identity management (SCIM) is the standard for automating the exchange of user identity information between identity domains and provides automatically-driven updates to user attributes on changes in the home directory. It supports the addition, deletion, and updating of users as well as the ability to apply policy based on SCIM user or group attributes. Resource Model REST API - Operations A standard schema is in place for defining The following operations can be conducted: resources (e.g. users, groups) Create: Add a resource (e.g. user, group) Complex resource types are supported (e.g. with attributes, sub-attributes, Read: Get information about a resource multivalued attributes) Update: Update the attributes of a Resources are encoded as SCIM objects in resource JSON Delete: Remove a resource SSO: Trigger create/update to a third party It is Zscaler’s best practice to utilize SCIM Replace: Change a resource provisioning whenever possible. Search: Find a resource Bulk: Operations on multiple resources With a group-based policy, it is likely more reliable to leverage SCIM criteria, whereas if you want to apply policy based on the user's accessing device, is it trusted or untrusted, then that would require using a SAML attribute as criteria. Given the SAML assertion is generated as users are authenticating, it's possible to include additional contextual information related to the authentication transaction. 10 Advantages and disadvantages of SCIM Advantages Disadvantages Updates information automatically: SCIM Information Not supported by all IdPs: (such as group changes) is updated via the API in real The only drawback of SCIM is time, whereas SAML Auto-Provisioning is static and that it is NOT supported by all requires the users to first log out and then log back in for IdPs with Zscaler. On the other Zscaler to detect changes. hand, Auto-Provisioning is supported by all IdPs. Allows users to be deleted: While Auto-Provisioning can add user information, it cannot delete users from the database, but SCIM can. For example, if revoking access or a user gets deleted or disabled in your directory, you can use SCIM to push that request to Zscaler where we will: 1. Consume that information 2. Automatically disable that user 3. Revoke access through the platform SAML Attributes SAML attributes are static Only applied on authentication Only changed on reauthentication Can include device and authentication attributes SCIM Attributes SCIM attributes are dynamic User- and group-specific They will be updated after a change in the source directory Frequency is IdP controlled Both SAML and SCIM Attributes The best of both worlds Whether you base policy on SAML or SCIM attributes is dependent on your use cases. 11 ZPA Support for SCIM 2.0 Operations Supported Add Users: As they are assigned to the ZPA SP in the source IDP Delete Users: Remove ZPA access for users that are either removed from the ZPA SP in the source IdP, or are removed from the directory completely. Update Users: Update SCIM attributes dynamically (e.g. group memberships) Apply Policy: Based on SCIM user or group attributes. SCIM Data Management SCIM Synchronization With SCIM enabled, read-only lists are Synchronization happens periodically using created in ZPA for: the API - SCIM users - Update interval of ~40 minutes - SCIM groups - Manually triggered at any time - SCIM attributes Updates are queued for sync from the IdP Users can only be managed in the source when: directory/IdP - Users are added/removed to/from a group mapped to the ZPA SP Users, groups, and attributes are updated - Users are individually assigned to from the source directory as changes are or removed from the ZPA SP made. - Users are removed from the source directory entirely. - User attributes are changed in the source directory. 12 Basic Connectivity This chapter will explain the different mechanisms to connect to the Zero Trust Exchange, depending on use cases and locations, emphasizing on best practices. —– By the end of this chapter, you will be able to: 1. Identify how zero trust components are established in the cloud. 2. Recognize the connectivity services Zscaler has in place to securely connect users and applications to the Zero Trust Exchange. 3. Discover how to configure Zscaler connectivity control services and capabilities. 13 Connecting to the Zero Trust Exchange (ZTE) Zero trust components are established in the cloud, and users/devices, IoT / OT devices, or workloads must establish a connection to this cloud so security controls can be enforced. Zero trust connections are, by definition, independent of any network for control or trust. Zero trust ensures access is granted by never sharing the network between the originator (user/device, IoT / OT device, or workload) and the destination application. By keeping these separate, zero trust can be properly implemented and enforced over any network. The network can be located anywhere, or it could be built on IPv6, as the network is simply the means of connecting initiators to destination apps. Throughout this chapter, we will dive deeper into the connectivity services outlined in the image above including: Browser Access & Zscaler Client Connector App Connectors Privileged Remote Access Included as part of Zscaler App connectors provide the Browser-based access Internet Access (ZIA), secure authenticated provides connectivity Zscaler Private Access interface between a through a web browser (ZPA), and Zscaler Digital customer’s servers and the without the Zscaler Client Experience (ZDX), Zscaler ZPA cloud. Connector being installed Client Connector is a to HTTP and HTTPS lightweight app that sits They establish connections applications. on users' endpoints and through the Firewall to the enforces security Zscaler cloud and the This core connectivity policies and access Zscaler cloud facilitates capability also provides controls regardless of that connection as a access to privileged remote device, location, or reverse connection in order access applications such application. to enable users to access as SSH or RDP. applications. 14 Zscaler Client Connector Zscaler Client Connector Included as part of Zscaler Internet Access (ZIA), Zscaler Private Access (ZPA), and Zscaler Digital Experience (ZDX), Zscaler Client Connector is a lightweight app that sits on users' endpoints and enforces security policies and access controls regardless of device, location, or application. The Zscaler Client Connector is Features include: installed on the endpoint to create a tunnel to the Zero Trust Exchange for Consistent Experience on all Platforms the protection of SaaS and internet-bound traffic. Strict Enforcement Options (Tamper Proof) This same Client Connector also Simple Enrollment provides a persistent control plane and dynamic, micro-segmented data Trusted Network Detection plane tunnels to the ZTE for the purpose of internal app protection, User Attribution and Asset Identification and traffic is delivered to the application via a corresponding Transparent Authentication for Users outbound-only data plane tunnel from the Zscaler App Connector. Install Zscaler or Custom SSL Inspection Certificate 15 Authenticated Tunnels There are a number of different modes for Zscaler Client Connector to function when it's forwarding traffic to Zscaler Internet Access. The recommended mechanism is to use the Zscaler tunnel. The tunnel-based approach intercepts traffic at the network level and forwards that traffic through an encapsulated tunnel to the Zscaler platform. There are three authenticated tunnel options (meaning that once the user is enrolled in Zscaler Client Connector, the tunnel is established toward the Zscaler cloud and all traffic that goes into the tunnel is identified as that user and that user-based policy is applied): ZTunnel - Packet Filter ZTunnel - Route-Based ZTunnel with Local Proxy Based Creates Packet Filters Creates Route Table Deploys System Proxy to (Windows Only) Entries Localhost The packet filter based on Route-based mode also Tunnel with local proxy Windows instruments, works in instruments and creates a loopback packet filters that grab additional network adapter, address that appears as a traffic, steer the traffic which becomes the route HTTP, HTTPS proxy, and toward the Zscaler Client for traffic, route-based then instructs the operating Connector process that mode instruments, and system’s proxy setting to can then make a decision additional network adapter, point the browser at that to forward it to the Zscaler which becomes the route local proxy. It’s then cloud. for traffic generated from tunneling the traffic toward client applications. the Zscaler cloud. Additional options that support legacy implementations are: Enforced PAC mode, which basically instruments the PAC file in the browser, similar to what you'd get from a group policy object. That means that the browser itself is forced to go to Zscaler Internet Access via a specified proxy. None, meaning that the policy is not going to do any configuration of proxy or tunneling mode, and relies on the group policy object or the default configuration within the browser. 16 ZTunnel 1.0 vs. 2.0 Tunnel modes come in two formats, the Legacy Z-Tunnel 1.0 and the modern ZTunnel 2.0: ZTunnel 1.0 ZTunnel 2.0 The Legacy Z-Tunnel 1.0 is an HTTP The more advanced Z-Tunnel 2.0 is a CONNECT tunnel. So as traffic is DTLS (Datagram Transport Layer Security) forwarded into the tunnel, it creates a tunnel with fallback to TLS (Transport Layer CONNECT method toward the cloud. It Security) supporting all client traffic, which doesn't really encapsulate the traffic. It means the Zscaler Firewall, as part of the simply adds some header information, Zero Trust Exchange, could inspect and which enables the Zero Trust Exchange to apply policy on all traffic. understand the user information and the data that's being passed to it. With Z-Tunnel 2.0, which is the best practice option, the tunnel is the control With ZTunnel 1.0, there are essentially two channel and a single tunnel from the client tunnels: a tunnel towards the Zero Trust to the Zero Trust Exchange. Any Exchange for the authentication, enrollment notifications from the Client Connector and passing traffic, and another for the admin portal (aka. "Mobile Admin") are policy updates that would occur every 60 passed through the Zero Trust Exchange minutes against the Zscaler Client directly to the client, and those happen in Connector Portal where all those real time. configuration changes are made. Any TCP, UDP, and ICMP Traffic 80 / 443 Proxy Aware Traffic Only DTLS runs on UDP = Faster Transport No Real Encapsulation of Traffic If the client detects that the DTLS tunnel wasn't successful, such as a firewall No Control Channel blocking UDP traffic, we want to fall back to a TLS-TCP connection. Limited Log Visibility DTLS uses a TLS tunnel = Integrity No Visibility Into Non-Web Traffic Tunnel Provides Control Channel = Configurable drop of Non-Web Traffic updates to client (policy changes), available updates, connectivity information, and logging/alerting towards the client. Logging of Client Connector Version, ZTunnel version… Tunnel Failure: There are also connection timeout options and additional options for redirecting traffic to a local listener ( tunnel with local proxy, providing safe fallback within the client if the tunnel mode connection is not successful. 17 Forwarding Profile: Trusted Network Detection Within the client, there is trusted network detection, which can make a decision if a user is in the office, branch, data center, or similar locations based on certain criteria. Hostname and IP DNS Search Domains DNS Server Does a specific FQDN The DNS search domain, The DNS server looks at resolve to an IP address? If provided by DHCP, where the primary network those two match, then the the client will receive a adapter on the client and condition is true. DNS search domain. If understands what DNS those things match the server is being provided to configuration of the trusted it through DHCP. If those network criteria, the user is things are equal, then the on the matching network. DNS server condition is true. Combining these we can say whether they've all got to be true to identify the user or the device as being on a trusted network, and that trusted network (any number of different locations) can then be a condition to make a decision on how the different forwarding mechanisms are going to be used at that location. 18 Forwarding Profile: Multiple Trusted Networks Now we just need to define each of our multiple Trusted Networks so that we can then make the decision as to which forwarding profile matches our desired outcome. Note: Forwarding profiles can reference multiple trusted networks. 19 Forwarding Profile: Profile Action for ZIA Finally, within the forwarding profile, we can select a trusted network criteria and then select from your predefined list of multiple trusted networks, confirming which ones are going to apply to the forwarding profile. This means that for a device on a trusted network, we can make a decision whether to tunnel the traffic, use a tunnel with a local proxy, enforce the proxy, or do ‘none’. While we are here, let’s look at and revisit some of the best practices. The best practice is to use tunnel mode and specifically to use the ZTunnel 2.0, which captures all traffic within the client and tunnels it to Zscaler within a DTLS tunnel. With the ZTunnel 2.0 configuration, default to DTLS, with the ability to fall back to TLS as necessary. 20 Forwarding Profile: System Proxy Settings Within the system proxy settings, you can control how the browser, or more specifically the operating system, receives proxy settings. If you're migrating from an on-premises proxy, you will already have a proxy setting set within the browser or within the system. With a tunnel mode, there is no need to have these proxy settings. So the recommendation is to enforce a no-proxy configuration. Enforcing Proxy Action Type: Automatically Use Automatic Use Proxy Server Execute Detect Settings Configuration for Your LAN GPO Update Script The client sends a Explicitly configure This is a The Windows WPAD (Web Proxy where the Zscaler hard-coded proxy machine will Auto-Discovery) Client Connector import (IP address provide a GPO lookup looking for sets your custom and a port or an (Group Policy a proxy. system PAC file to FQDN and a port) Object) download and run with the ability to update/force from through that PAC bypass local Active Directory to file configuration addresses. A local set the proxy for traffic to be address is settings on the explicitly proxied to something that is machine. a proxy server. non-fully qualified. Also referred to as a forwarding PAC file. It’s important to understand the behavior of GPO updates, forcing Zscaler Client Connector to set a proxy setting, or forcing Zscaler Client Connector to set a WPAD script, making sure that there is no conflict between these. You can then make decisions on whether to use exactly the same settings for the untrusted network, for the VPN Trusted Network, and off-trusted network criteria. 21 Summary: It's really important to understand the distinction between a forwarding PAC and how the forwarding PAC is implemented within Zscaler Client Connector. With a tunnel mode configuration, we do not want to set any forwarding PAC file and have the client intercept the traffic natively as the browser or the client configuration resolves an internet address and intercepts the traffic as it routes toward the internet and tunnels it toward the Zero Trust Exchange through the DTLS tunnels. 22 Application Profile An application profile exists to map the forwarding profiles to different users and different devices based on certain criteria. You need to configure a specific application profile for your Windows, Mac, iOS, Android, and Linux devices. We'll specifically focus on Windows and Mac devices. The app profile selects the forwarding profile, which therefore defines the method of tunneling. So, the forwarding profile defines it as Z-Tunnel 2.0, and so we map that to the application profile to forward traffic through the tunnel. This defines the on- and off-trusted network configuration and defines the system proxy is not configured. The app profile PAC URL defines the Zero Trust Exchange node to be used based on the client's geographic IP information. The most common configuration items here include: Custom PAC URL References the PAC file configured in the ZIA Admin Portal, making decisions on traffic that should be forwarded or bypassed from the Zero Trust Exchange. Override WPAD Ensures that the system GPO WPAD configuration is prevented, and makes sure that the WPAD configuration in the forwarding profile is used as a precedence. Restart WinHTTP Ensures that the system refreshes all of the proxy specific to Windows devices configuration once Zscaler Client Connector is established. Install Zscaler SSL Covered more in the next section. If you aren’t pushing out Certificate your own certificates from your own Certificate Authority, then simply enabling this option will use the one provided by Zscaler. 23  Tunnel Internal Client Ensures that the health updates and policy traffic passes Connector Traffic through the Zscaler tunnels towards the Zero Trust Exchange. Or more specifically, it doesn't go direct to the Zero Trust Exchange – it stays within the zero trust tunnels. Cache System Proxy Ensures that Zscaler Client Connector stores the system proxy state from before it was installed or enabled, and makes sure that when Zscaler Client Connector is uninstalled or disabled, a system proxy configuration is reverted and the user can continue to function as before. And that the Zscaler Client Connector reverts to previous versions of the Zscaler Client Connector software in the event of an upgrade issue. These last two are about supportability in the case where the client needs to uninstall or revert a previous version, and making sure that they have business continuity in the case of any issue with the updates. 24 Deploying Zscaler SSL Inspection Certificates A critical part of the Zero Trust Exchange is the ability to inspect SSL, and it's important that the client trusts the SSL certificates that are being used for SSL inspection. Zscaler Client Connector has the ability to deploy the Zscaler root CA as well as custom root CAs that might be being used within an organization. The configuration options to upload the root CA from a custom CA to make sure that's deployed is controlled here, as well as the ability within the app profile, as previously mentioned, to control ensuring that the SSL certificate is installed. 25 Tunnel 2.0 Configuration When we look at the Z-Tunnel 2.0 configuration, there are a number of options that we need to consider. There are some specific application bypasses for things like UCaaS. If we want to bypass Microsoft Teams or Zoom traffic from going into the tunnel, we can do that by selecting them under the application bypass. It's important that we make exclusions and inclusions for traffic that we want to grab at the adapter level and pass into the Z-Tunnel 2.0. The default excludes the RFC 1918 address space and includes the default 0.0.0.0/0 address range and all ports 1 to 65,535 TCP and UDP. You could configure bypasses and change this if you specifically want to bypass a port from going into the tunnel, an IP address going into the tunnel, or you can ensure that everything goes into the tunnel. Zscaler also provides the ability for inclusions and exclusions of DNS requests. Zscaler is a DNS resolver, but it's important to understand that the client is going to get a DNS server from its DHCP. If the client gets a DNS server from DHCP that is within the RFC 1918 address range, the client may query that directly, and it's only once the connection comes through Zscaler that we'll be able to see the traffic and make a DNS re-resolution request. DNS requests are tunneled to the Zscaler cloud, and the Zscaler cloud performs the DNS resolution. It's not necessary to configure Zscaler as the DNS server since this configuration intercepts any DNS request to any DNS server and redirects it or tunnels it to the Zscaler cloud for the Zero Trust Exchange to perform the DNS resolution. 26 Forwarding Profile PAC vs App Profile PAC Let's explain the difference between a Forwarding PAC and an App PAC in more detail. Forwarding Profile PAC App Profile PAC Steers traffic toward or away from the Steers traffic toward or away from the Client Connector Zscaler Cloud Controls System PAC file - which HTTP Routes traffic AFTER the Client Proxy to be used for a URL, tunnel with Connector has received it. local proxy or other explicit proxy. Used to determine the geographically Has no bearing where Client Connector will closest Zscaler Enforcement Node (ZEN). route traffic, only where the user’s apps will send traffic. A Forwarding Profile PAC gets defined The Application Profile PAC steers traffic within the forwarding profile and it steers towards or away from the Zscaler cloud – traffic toward or away from Zscaler Client after traffic has been intercepted by the Connector. It's essentially the system PAC tunnel mode or after traffic has been file, stating which HTTP proxy is going to directed to it with the local proxy. be used for a specific URL. The Application Profile PAC then If it's the PAC file for a Tunnel with Local processes the traffic and makes a decision Proxy, it's going to point traffic at the which Zscaler node (ZIA Public or Private loopback address or another explicit proxy. Service Edge, or ZPA Public or Private It has no bearing on where Zscaler Client Service Edge) is going to process the Connector will route traffic, only where the request afterwards. user's applications will send traffic. So a user's application could be the Internet Finally, that App Profile PAC is then used to Explorer browser, Edge browser, Chrome determine the geographically closest browser, Firefox. They would receive the Zscaler enforcement node to process it. Forwarding Profile PAC that makes the decision how that browser will treat the HTTP traffic and what proxy server it will send it to. And that proxy server could be Zscaler, or that proxy server could be the local proxy that's enabled in Zscaler Client Connector. 27 ZIA: PAC Files Within the Zscaler Internet Access (ZIA) Admin Portal, we can define the PAC files that are hosted on the cloud. PAC files are essentially JavaScript functions that take two inputs that are dynamically provided to it by the browser, or in the case of the App Profile PAC, through the inspection process. It takes the input of a URL and a host, and it returns back an answer of sending the traffic “DIRECT” or “PROXY”. As previously discussed, The Forwarding PAC is processed by the web browser or the system proxy, while the Application Profile PAC is for Zscaler Client Connector to make its traffic routing decisions. Migration: If you're migrating from an on-premises proxy to the Zscaler Internet Access platform, existing PAC files may be migrated to Zscaler. Here you would migrate to Zscaler using Tunnel with Local Proxy, and you might bring in that browser configuration. It remains the same. The PAC file simply returns to Zscaler Client Connector as a proxy, and Zscaler Client Connector tunnels that traffic to the Zero Trust Exchange. And because it's an authenticated tunnel, the Zscaler Zero Trust Exchange understands who the user is. As a migration step, it's a very simple process to take your existing PAC file and move it into the Zscaler Client Connector. However, the recommendation is to use the Z-Tunnel 2.0 forwarding mechanism, and you need to take into consideration how to move from an existing explicit proxy configuration to moving to Zscaler tunnel mode. 28 ZIA: Browser Behavior - PAC to Tunnel Mode As you move from PAC mode to a tunnel mode, or explicit proxy mode to a tunnel mode, there are implications on the way your browser will behave. Site Authentication The browser will automatically understand how it authenticates to intranet sites, so it'll do Kerberos, NTLM (New Technology LAN Manager), and Integrated Windows Authentication (IWA) to websites, which are automatically defined as being in the intranet zone. And the intranet zone is defined as sites which bypass the proxy, so a site which has a direct statement in the PAC file is automatically identified as being an intranet site. Therefore if it challenges for authentication, the user will automatically authenticate, or the browser will automatically authenticate, and the user will be signed in. So if you remove the PAC file configuration and move to tunnel mode, the definition within the browser of what is an intranet site is lost. This means the user may be prompted to authenticate to intranet sites, and it is often seen as a side effect of migrating from PAC file to tunnel mode. As there is no PAC file in the browser with Tunnel Mode, you need to specifically define the intranet sites in the browser to ensure there's a congruent authentication behavior (single sign-on to intranet applications – because they're defined as intranet sites). In Internet Explorer, you would need to click the Advanced button and add those sites as intranet sites. You are taking that decision away from the browser saying there are sites that bypass the proxy, and you are explicitly defining them within (1) the intranet zone and saying these sites are my intranet sites that I should then automatically authenticate to within Google, Chrome, Edge browsers, etc… via the (2) AuthServerAllowList. And within Firefox you would add things to the (3) auth.trusted-uris configuration option. All of these can be pushed out through group policy objects and identified from your existing PAC file, migrated into the browser configuration, and pushed out before the migration to Zscaler occurs. 29 Tunnel Mode - Packet Filter Based - ZTunnel 2.0 Now we need to look deeper into the tunnels. The application is going to generate some traffic, and it may understand what a Forwarding PAC file is. It might look at Internet Explorer and bring in the PAC file. And so that PAC file decision says, should I send it to Zscaler Client Connector? It's also going to understand something that's a ZPA (Zscaler Private Access) segment, based on how it resolves. The bottom line is that there are going to be exclusions and inclusions. Anything that's included will be sent through to Zscaler Client Connector, or Zscaler Client Connector will physically intercept traffic. Anything that is bypassed or bypassed through the packet filters will go directly out to the internet. 30 Tunnel Mode - Packet Filter Based - ZTunnel 1.0 With Z-Tunnel 1.0, it's important to understand that traffic at a network layer will only intercept traffic that's 80 or 443. So if you've got, again, the application generating packets, if it's port 80 or 443, it'll be intercepted and passed to Zscaler Client Connector. If it's explicitly proxy, do you have a proxy configuration tunnel with local proxy? It'll be passed to that local adapter that's listening, and again, into Zscaler Client Connector. Or again, if it's a Zscaler Private Access segment, we'll intercept that and send the traffic to Zscaler Client Connector. Anything that is none of those, anything that is not a ZPA segment, or 80 and 443, will inherently bypass Zscaler Client Connector and then route directly out through the interface to the internet. 31 Tunnel with Local Proxy Flow With the Tunnel with Local proxy as the only configuration on there, you explicitly need the Forwarding Profile PAC to target traffic directly to the local listener on Zscaler Client Connector. This means the application needs to be proxy-aware. It needs to understand the configuration of what my Zscaler Client Connector proxy listener is, and it will then forward the traffic to that Zscaler Client Connector. Zscaler Client Connector then passes traffic to Zscaler Internet Access. Any other traffic that's not ZPA will pass out directly to the internet. 32 Tunnel Mode - Route-Based Flow In the route-based mode, again, there is a routed adapter. There's an additional network adapter that's configured on the machine. And in a scenario where the Tunnel with Local Proxy is not configured, the application generates traffic, it follows the routing table, and that traffic routes into the Zscaler Client Connector IP address. The Application PAC processes the traffic, and again, traffic routes either to the Zscaler cloud or it bypasses and routes directly to the internet. 33 ZIA Enrollment Process When Zscaler Client Connector is launched, it needs to enroll, also needing to authenticate to be able to understand who the user is, what policy to apply, what tunnels to create, and how to identify the user through those tunnels. As the Zscaler Client Connector launches, it's going to talk to the mobile admin portal (Zscaler Client Connector Portal) and understand what domain the user is in and what SAML identity provider the user should authenticate against. The user receives that IdP redirect and they are redirected to their SAML IdP, such as Okta, ADFS (Active Directory Federation Service), Azure AD (Active Directory). The user will sign into the SAML IdP and receive a SAML response within the Zscaler Client Connector process. That SAML response is provided to Zscaler Internet Access, which consumes the response, validates it, and if the response is valid, then the user receives an authentication token back to Zscaler Client Connector. Zscaler Client Connector provides that token to the Zscaler Client Connector Portal, which validates the token and registers the device. At this point, the Zscaler Client Connector Portal understands who the user is, fingerprints the device, consumes that device information, and passes that device registration through to Zscaler Internet Access. Zscaler Internet Access then provides the client credentials so that when the user makes a request through the Zscaler service, it can authenticate the user and it uses the Zscaler identity token to authenticate the client through the platform. 34 ZPA Enrollment Process With Zscaler Private Access, again, the client is launched as part of the authentication process. It already understands the domain that the user is in from the Zscaler Internet Access enrollment, so there's an immediate registration attempt, followed by a second IdP redirect as Zscaler Internet Access and Zscaler Private Access are controlled as two separate SAML-reliant party trusts. During this second authentication round where the Zscaler Client Connector talks to the SAML IdP, it will sign in transparently because they're already signed in from the Zscaler Internet Access enrollment. There may be a multifactor authentication at this point, but the IdP authenticates the user and returns the SAML response back to Zscaler Client Connector. Zscaler Client Connector provides that response token and registers the device into Zscaler Client Connector Portal, which passes that registration through to Zscaler Private Access, and Zscaler Private Access enrollment then enables the Zscaler Client Connector certificates to be generated and Zscaler Client Connector is enrolled in Zscaler Private Access. Zscaler Client Connector then generates the secure tunnels to the Zero Trust Exchange, through which the profile and settings are downloaded so the client receives the information about the Zscaler Private Access applications that they're able to access. 35 Client Connector Intervals There are multiple intervals where Zscaler Client Connector will refresh the information it has about the applications, the app profiles, the forwarding profiles, the PAC files, and the policy. On Network Change (connect/disconnect) Any time there is a network change, such as when the device comes out of hibernation and reconnects to Wi-Fi, I turn Wi-Fi on and off, or I restart the processes. There'll be a full refresh of all of those objects. Every Two Hours Every two hours Zscaler Client Connector will check for software updates. Every Hour Every hour Zscaler Client Connector will connect and download any policy updates for the app profiles and forwarding profiles. If the PAC files or URLs are changed, it will automatically update every hour as this counts as a profile change. Every 15 Minutes However every 15 minutes, Zscaler Client Connector will download the PAC file of the app profiles and the forwarding profiles in case they have changed. Manually The end user can obviously also initiate an update through the administration of Zscaler Client Connector and force a check for software updates or force a check for policy change. 36 Rotating Passwords with App Profiles Zscaler Client Connector is locked down to prevent users from logging out, disabling, or uninstalling the application. This is password-protected and the password is generated on a per-configuration basis and available to support personnel through the administration interface that could then be provided to users if there's a need to uninstall, disable, or log out for some service-affecting reason. One-Time Passwords Unique, per-device password that is generated on enrollment Password changes when used Password always available in device information Administrators and support teams are encouraged to only use the one-time, per-device password and NOT the global passwords within the App Profile, which can be reused. 37 Device Posture and Posture Checks Within the Zscaler Client Connector, there is Device Posture. Device Posture enables a level of trust of the device as part of the Zero Trust Network Access policy. There are a number of these posture checks available to choose from. While Windows and Mac have the ability to check for all of them, iOS and Android have limited capabilities based on their ability to understand if disk encryption is enrolled or they don't have the functionality for domain-joined devices. These pieces of information then enable us to identify the device. Common Examples Include: BYOD vs. Corporate Devices Does the device trust a root CA, which is only internal to an organization? This enables us to consider if it's a BYOD (bring your own device) device versus a corporate device. A corporate device will be domain-joined. It will have a certain registry entry, certain files on the device, the certificate trust. We can also check for client certificates and ensure that the client certificate has a non-exportable private key. Device Security Anti-Virus, OS Version, Disk Encryption, Firewall Endpoint Protection So we can understand the security of the endpoint and use this in policy to provide access to applications. And then we can interface with third-party endpoint protection, such as CarbonBlack, CrowdStrike, SentinelOne, Defender, and the CrowdStrike ZTA score to make policy decisions. For example, if Defender tells us the device is compromised, then we can prevent access to an application. 38 Installing Client Connector To install and maintain the Client Connector, follow this basic process: Download the install file The files are available through the Zscaler Client Connector Portal. The install files are hosted on AWS, so it is possible to copy the link in order to distribute it to users. Install on devices Command Line options exist for Windows, Mac, and Linux clients, Always refer to the online allowing for silent installations. help for each of the command line installation The strictEnforcement option requires cloudName and options. policyToken options to ensure that the user is automatically triggered to the right cloud and authentication token, and make sure that the user can not access the Internet until they are enrolled. Tools such as Intune (Windows) or Jamf (MacOS) are popular ways of distributing to managed devices. Update the client Group-based updates can be readily applied for automatic rollout, such that specific versions can be applied to specific groups of users – useful for testing and staggered rollouts. Troubleshooting Should you encounter any issues with the installation, logs can be exported from within the client or the built-in packet capture can be used. As well, they can be manually retrieved from the file system at c:\ProgramData\zscaler (Windows) or at either ~/Library/Application Support/com.zscaler.Zscaler/ or /var/log/zscaler (MacOS). 39 App Connectors App Connectors provide a secure authenticated interface between a customer’s servers and the ZPA cloud. They do so by establishing connections out through the firewall to the Zscaler Cloud, and the Zero Trust Exchange facilitates a reverse connection. At no point are the internal/private servers exposed by public/external DNS or through inbound DMZ firewall holes. Fundamentals Always deploy App Connectors as a pair (minimum) and as a different Connector Group in separate data centers. Ensure app connectors: Can route to the internet and internal applications. Meet the minimum VM requirements. Can connect to applications (TCP/UDP) for health checking. Source IPs are registered in Active Directory Sites & Services, as the requests will be seen as coming from the App Connectors. Deploy Create a provisioning key for each Connector Group Provisioning keys are signed by an intermediate certificate authority and the intermediate trusted by the root CA. Clients are enrolled against a client intermediate certificate authority. Revoking/deleting the intermediates breaks the trust, invalidating the provisioning keys. Treat provisioning keys as credentials (don’t share in cleartext = download from the UI and upload via SCP or copy/paste over SSH or use the API to retrieve or generate dynamically). Deploy Connector Groups – Always refer to the online help and use it as a checklist when deploying app connectors. Server Group Associate the Connector Group(s) with a Server Group. Dynamic Server Discovery on that server group means that either the 40  group or the connectors will automatically perform DNS resolution and create synthetic server associations that advertise those applications. This is the default (recommended) configuration and, it is not recommended to move away from Dynamic Server Discovery unless for a very specific reason. Define Application Applications must be defined within an Application Segment. Segments An application segment is a grouping of those applications, those defined FQDNs that make that application function. A segment group is a grouping of similar applications that you want to apply policy to. Let’s say, for example, that I wanted Sales to be able to access all of these applications. In such a case, there would be different applications in different segments, possibly in different locations, but they're grouped together because they should provide the same service, and a similar set of users should be able to access that segment. Begin the first application segment as a wildcard (example: if your internal domain is company.com, then we would use *.company.com). This way, any time a user wants to access an application that matches that wildcard, ZPA will ask any connector within the server group to DNS resolve and perform a health check of that application. Then, ZPA will steer the client traffic through the App Connector that was able to establish the connection and pass the traffic through to the application. All of this is further based on policy. Looking at this graphically, an application in the application segment is an FQDN, a wildcard domain, or an IP address on a standard set of ports or range of ports. IP addresses should be used sparingly and only where an application is accessible by an IP address, or where the payload indicates that it needs to be connected by IP address. Once that application segment is defined, it’s associated by definition with those server groups, and the server group is associated with the app connector group. 41 Pulling it Together - Where Each Component Fits Use case: User accessing Jira in DC1 Traffic is identified on the client system to determine if it’s an application needing to be served by ZPA After traffic reaches the Zero Trust Exchange (ZTE), policy evaluation takes place to determine if the user is allowed to access the requested application If access is allowed as per the configured policy, then the App Connector group that is closest to the user’s location is identified by the ZTE Connection is then brokered, and the user is able to access the application 42 Browser Access & Privileged Remote Access Browser Access (BA) Browser Based Access provides connectivity through a web browser without the Zscaler Client Connector being installed to HTTP and HTTPS applications. This core connectivity capability also provides access to Privileged Remote Access applications such as SSH or RDP. Why use Browser Access? It provides authenticated private website access to third parties without managing a DMZ or internet edge It provides access without using a VPN, browser extension, or any client software It delivers the same experience a user would go when connecting directly to an intranet website It allows websites to reside anywhere—in an on-premises data center or in a public cloud It can inspect requests/response with App Protection to protect your intranet website from OWASP Top 10 & custom signatures ZTNA policy provides least-privileged access Zscaler Browser Access enables users to authenticate to internal websites from anywhere, without needing to manage a DMZ, Internet Edge, or a VPN—all with the same user experience as a direct website connection. A User Portal provides a graphical view within the browser of those browser-based access applications that the user has access to. With added protection from the OWASP (Open Web Application Security Project) Top 10 and Custom Signatures to inspect the web content, as well as ZTNA policy for least privileged access, security gets a huge boost over legacy website access methods. Now, we can immediately provide day-one access for subsidiaries or acquisitions or partners to access applications. We can further provide limited access to suppliers, contractors, customers, and other third parties through this mechanism, without the need for them to install a Zscaler Client Connector software (BYOD included—which comes down to the trust of the users and the risk associated with accessing those applications without a client-based endpoint solution). 43 How Browser Access Works User types in the URL of internal web application or the User Portal and is redirected to appropriate IDP for user authentication. The closest connector to requested app creates inside out TLS 1.2 encrypted tunnel over port 443. The Zscaler broker stitches together apps to user connection in the broker location closest to the user, presenting them with either the direct application or the User Portal, depending on which option the user selected. Real-time, global visibility into all user and app activity Configuration Overview Fundamentals SSL is always used for the outside connection, whereas HTTP or HTTPS may be used internally. It’s important that the client trusts that server certificate. This might be publicly signed by a public certificate authority (the private key never leaves the Zscaler cloud), or it could be an internal certificate authority where only your internal clients trust that root certificate authority. Once the user has the connection to the Zero Trust Exchange and the policy permits them access, an inside-out tunnel is created between the App Connector and the Zero Trust Exchange. There are three tunnels: The client to the Zero Trust Exchange, the App Connector to the Zero Trust Exchange, and Zero Trust Exchange to the application through the App Connector. ZPA Admin As with any other application, the website application must be in an Configuration application segment. But in this case, as DNS is utilized, FQDNs are Always refer to the required. online help, using it as a checklist. If desired, also create a User Portal for added user convenience, especially if there are multiple Browser Access enabled applications, linking those applications to the portal. DNS Configuration The Zscaler CNAME (alias) provided by ZPA will be put in the public DNS. 44 Privileged Remote Access (PRA) PRA is an authenticated remote desktop gateway/SSH gateway that relies on Zscaler’s Service Edge and the App Connector to allow a user to access IT and OT servers, desktops, and workstations using their browser, typically through an authenticated web portal. Privileged Remote Access: Provides authenticated access to your jumphosts, workstations, servers, and IT/OT equipment from a browser Allows console sessions to be streamed, meaning no data resides on the user’s device Requires no VPN client, browser extension, or other client software Eliminates firewalls and DMZs—jumphosts, workstations, and servers can be limited to the App Connector IPs Allows a user to access only the consoles you specify Similar to the user portal, the users can connect to the Zero Trust Exchange, and the Zero Trust Exchange provides authenticated access to jumphosts, workstation servers, IT, and OT equipment, all within the browser. The console session is streamed, meaning that no data is stored on the user's device. The user's device has no direct access to that application. It eliminates the need for firewalls, DMZs, and the jumphosts and workstations and servers can be limited to the Zscaler App Connectors’ IP addresses. And, based on policy, users can only access the consoles they're permitted access to. The key driver is the common use case of supporting BYOD devices so the user never needs a corporate device to be able to access privileged resources. Because it's an unmanaged device, you can provide secure access for contractors, suppliers, and other third parties to perform privileged access, such as administration and maintenance tasks. Configuring Privileged Remote Access As with Browser Access, specific configuration steps are contained within the online help and should be referenced during the process. 45 Platform Services Platform Services will allow you to explore fundamental capabilities that Zscaler offers including Private Service Edges, Device Posture, TLS Inspection, Policy Framework, and Analytics & Reporting. Gain an overview of Zscaler’s fundamental Platform capabilities. Dive deeper into how these functionalities interact with other services within Zero Trust Exchange and gain knowledge on how to configure Zscaler’s Platform Services as they relate to Zscaler best practices. —– By the end of this chapter, you will be able to 1. Identify the fundamental set of Platform Services Zscaler provides and how they apply to the Zero Trust Exchange. 2. Recognize how policy is consumed, constructed, and passed to other functions of the Zero Trust Exchange (i.e. Connectivity, Access Control, Security, and Digital Experience Services). 3. Discover how to configure Zscaler Platform services and capabilities. 46 Zscaler's Platform Services Suite Included in Zscaler’s holistic Zero Trust Exchange is Zscaler’s Platform Services suite. This important suite contains a set of fundamental functionalities that are common across Zscaler’s other services suites such as Connectivity, Access Control, Security, and Digital Experience. 47 Device Posture Device Posture is provided as part of Zscaler’s Platform Services suite. It does, however, consume posture from other functionalities in the Zero Trust Exchange such as Browser Access, Zscaler Client Connector in the Connectivity Services suite, and Identity Integration. As such, we don’t need to cover it again here, except highlight what a SAML response looks like when it returns Device Attributes. Device Attributes As the client initiates a SAML authentication request, both for Zscaler Internet Access or Zscaler Private Access, a SAML response is returned. Once consumed, Zscaler can apply policy based on those attributes. Below we can see Azure AD has affirmed the device is managed because it's enrolled in Azure AD and managed by Intune. It's compliant because it's gone through a compliance policy that says the device is running specific software and is compliant with the corporate policy. And ”is known” tells us is the device managed by Intune versus corporately managed by something like SCCM (now known as MECM, Microsoft Endpoint Configuration Manager). 48 TLS Inspection As part of the Platform Services suite of capabilities, TLS Decryption or Inspection works to inspect content and enable various Access Control, Cyber Protection, and Data Protection functionalities to apply policy based on the content of those encrypted communications. Zscaler decrypts Zscaler provides Zscaler ensures Zscaler mitigates Zscaler allows you and inspects 100% controlled and rapid optimal cipher any access risk. to measure of TLS traffic without deployment and selection and key coverage, value, constraints. operations safeguards. and troubleshoot so you gain instant awareness Within the Zero Trust Exchange, there are several facets of how TLS inspection works. The first is Access Control—URL Filtering and Cloud Firewall functionality apply policy based on the request and the response. The second part is based around compromise—the actual payload that's coming from or going toward the web server such as malware inspection, antivirus, the Advanced Threat Protection, the IPS signature, and cloud sandbox functionality. Finally there’s the Data Loss or the data protection side. Inline DLP means scanning the payload that's coming from the client to make sure that nefarious users or accidental users are leaking data out to the internet. Being able to provide Granular Application Controls, not just on the FQDN, the URL that's being accessed, but across the entire URI that's being connected to. All of this is built as a scalable platform, assuming 100% of the transactions will be SSL and 100% of those could be decrypted. Generating intermediate certificates at line speed for all users and all locations enables the best security and data protection outcomes. 49 As noted, without TLS inspection, security controls are effectively blind to any malicious payloads, data leakage, and emerging threats. Without TLS inspection everywhere, a user might access the internet via their corporate device(s), leaving them vulnerable to major security breaches. Encrypted HTTPS Transaction Decrypted HTTPS Transaction When you look at an encrypted HTTPS When you decrypt an HTTPS transaction transaction, there is nothing visible to a or TLS, the following becomes visible: viewer. The only item that one can see from a TLS Handshake without inspection - HTTP Headers is the Server or Domain Name as seen in - Request and Response Headers the image below. - Full Request URL - Request Method - All of the Payload 50 How Does SSL Inspection Work? ZIA ZPA Here, ZIA is a forward proxy doing SSL With ZPA it is in essence a reverse proxy, man-in-the-middle inspection. The client becoming the web server that the user is makes a request to the website and the ZIA connecting to. There's a Client Hello Service Edge sits in between that. On the towards ZPA and then there's a connection other side is a connection from the Service from the App Connector to the application, Edge to the originating web server, where the real service certificate is receiving the server certificate back, provided to the App Connector. validating (signed by a trusted issuer, date is valid, issuer is valid, and the content The App Connector or the ZPA Service within that certificate is valid). ZIA will then Edge provides a real service certificate generate a certificate on the fly, signed by a back to the client. The real service trusted issuer, and provide that certificate certificate may be the same one from the back to the client. As far as the client is application, or it may be a certificate that concerned, they're getting a certificate for was specifically uploaded to the ZPA the web server, but we're generating that platform for those websites that we are on the fly as a man-in-the-middle proxying through it. certificate. Short version: Zscaler Internet Access (ZIA) is a forward proxy interception and Zscaler Private Access (ZPA) is essentially a reverse proxy SSL termination interception. 51 From a client (end user) perspective, they could look at the certificate chain within their browser session to see which certificate is actually being used. In this case we can see that while they are going to a Wikipedia site, in reality the certificate being used is the one from Zscaler, providing a clear indication that the traffic is now being intercepted and inspected. 52 Safe to say, Zscaler knows perhaps more than any company on Earth how to roll out SSL inspection at scale. Let’s break it down into manageable steps. Pre-Work Ensure that you have agreement within an organization that SSL inspection is going to be deployed. It's being deployed to support the business. It's not to spy on what users are doing, but to ensure that the business can continue to function making sure that they're not infected with malware and to ensure that data doesn't leak out that affects the customer perception or the reputation of a business, defining the acceptable usage policy and any notifications that are going to be provided to users. It's important to get buy-in from the legal teams, privacy leaders, the security teams, to understand why this is being done. 53  This is often a misunderstood step with lofty goals of deploying SSL inspection. You can get wrapped up in lots of red tape as to workers' councils, for example, being concerned about spying on users and what they're doing. But it's really important to get a level set within the organization of why TLS inspection is being done - for the security of the business and the business’s reputation, understanding what that encrypted data is, and how Zscaler handles it. Obfuscating the user and device data, never storing any of the content of the payload onto the disk. Scanning for data protection, for infection, and making sure malware doesn't come into the organization or leak out. And of course to best identify and block command and control services. Finally, develop a communication plan for the users. Why are we doing this? Updating the acceptable usage policy, sending out notifications so users understand how to check whether or not SSL is being inspected or not, and what decisions those users can make as to whether or not they're going to continue using their work device to connect to these websites whilst SSL inspection is taking place. Root CA Once we have buy-in, we're going to look at rolling out the root Enrollment certificate authorities to these devices and make sure that all client devices trust the intermediate certificate or trust the certificates that have been inspected. There are multiple kinds of SSL inspection. The default that comes with Zscaler is the Zscaler root certificate authority which has a Chain of Trust through the intermediate certificate, the short-lived temporary certificate, and the web server domain certificate that's going to be issued on the fly. 54 Customers also have the ability to bring their own certificate authority and you might take two different routes for this. The first one is a dedicated root where you create an offline certificate authority specific for SSL inspection on the proxy and you load that up to Zscaler, and therefore every certificate that is issued is then trusted through that Chain of Trust from the specific proxy certificate, the intermediate certificate, the short-lived certificate, and then that spoofed web server certificate. It means that you're in full control of swapping out the roots and full control of the Chain of Trust all the way down to that domain certificate. The alternative is using your existing enterprise root certificate authority. For example, if you have Active Directory, there is a root certificate authority that comes with it and every device that's enrolled within Active Directory the certificate is already inherently trusted. You can generate an intermediate certificate authority from that and upload that to Zscaler and any client should inherently trust that and it simplifies some of the rollout. Rolling out certificates is relatively simple. You can use the Zscaler Client Connector. Zscaler Client Connector can automatically install the Zscaler SSL certificate. You can upload your root certificate to Zscaler Client Connector Portal and then when the install Zscaler SSL certificate is checked, both the Zscaler root certificate and your custom 55  certificate will be installed automatically on devices that run the Zscaler Client Connector. Initial Roll-Out And then we'll roll out and do some inspection for a select group of users, for specific categories, collecting feedback from the users on their experience of that. This all starts with configuring the base set of rules before and continuing throughout the pilot phase. Granular Policy Framework The granular policy enables you to make decisions based on the user, group, department, the category, the cloud application, anything around the FQDN, the IP address, and even device types. We can make sure we don't break applications that may have certificate pinning involved. Client operating system-specific user agents – we might be able to see certain device types. With this policy, we can enforce that only websites with specific TLS versions or the client minimum TLS version is supported, as well as how we control the certificate trust. Is it passed through? Do we block untrusted certificates? Do we block undecryptable traffic and will we perform an OCSP check for that certificate, which is the Online Certificate Status Protocol, to check whether or not a certificate is valid or has been revoked? With the Zscaler One-Click configuration, we can automatically exclude services like M365 OneDrive, SharePoint from inspection which may have challenges with inspection being implemented. 56 Granular rule-based engine User/group/department URL Category/Cloud App Destination IP/FQDN group Device: Name, OS, Trust Level Avoid breaking cert pinned apps Client OS, User Agent, Device Enforce secure TLS usage Minimum TLS versions Certificate validation/revocation for inspected and uninspected traffic Exclude from M365 One Click Inspect OneDrive, Sharepoint 57  For a pilot rule set, we're going to specifically say for a group of users that are in a group called pilot SSL, we're going to inspect some very specific categories. We're going to block untrusted certificates. We're going to do that OCSP revocation check. We're going to block undecryptable traffic, and ensure that the minimum client and server versions are TLS 1.0, and then the default rule is ‘do not inspect’. The higher level rules, rules number 1 and 2, specifically bypass inspection for M365 and other Zscaler-recommended SSL exemptions where we know that applications might break if SSL is employed. It’s also important to understand other traffic that might be generated by your browser. For example, the QUIC (Quick UDP Internet Connection) protocol developed by Google is an experimental protocol that uses UDP port 443 to deliver content to the client. Now it's important to them to block this (and similarly Apple Private Relay) within the firewall, which forces the client to turn back to normal HTTP, HTTPS, over TCP 443 so that the SSL inspection can be done for that protocol. We continue to roll out and we're going to take a look at applications and client environments that may have challenges with inspection. Extended Roll-Out Now we'll figure out deeper problems that might have existed, such as certificate pinning, how to handle developer environments, IoT environments, and the policy around services like Office 365. 58 Certificate pinning or hard-coded certificates – what is that? It means that the client is going to check for the certificate and expects a specific certificate to be returned. The man-in-the-middle certificate that we deliver will not be trusted. It's not the certificate that's been expected, so the application will fail. A good example of this would be something like Dropbox. The Dropbox client expects a specific certificate to be delivered with a specific serial number, signed by a specific issuer, therefore the man-in-the-middle certificate we deliver isn't trusted, so the Dropbox client will fail. However, Dropbox within the browser will continue to work. We need to be able to identify these certificates. Either configure those clients to treat them as valid or make a decision to bypass SSL for inspection for those applications. It's very common, with iOS and Android, for certificate pinning or hard-coded certificates to be used. DigiCert recommends not to use certificate pinning for some of these reasons. 59 Troubleshooting A packet capture will help you understand what's going on. You could look at the certificate when the client makes the request and understand that the certificate was delivered to the client, but the client closed the connection very quickly once the certificate was delivered. That indicates that the client, although connected, decided it didn't trust the certificate and closed down. We can then also understand by looking in the SSL logs for those transactions within the Zscaler administration interface (now known as ZIA Admin Portal) that the client failed the handshake. The client closed the connection, and therefore we need to do something about this. So what can you do? You can make decisions based on either the specific operating system, the operating system combined with an application to bypass inspection, and you could also do this based on the user agent as well. We know that it's Android or iOS, they're connecting to this signal application, and there is no user agent provided as part of that CONNECT request. Or there is a user agent but it's not one that we know about, and therefore make a combined policy decision to bypass that inspection. 60 Measure & Report Really throughout the rollout it makes sense to measure and report on the capabilities. How much SSL inspection has been done? Quantify the value of SSL inspection towards the business. How much decryption has been done as well as how much malware and how much DLP has been triggered that supported the business decision? And then we can also see these TLS versions and ciphers as we go through to see how this is changing over time and the value that Zscaler brings for the SSL inspection journey. The Protocol Report, Security Audit Report (Cyber Risk Report) and SSL Policy Reason field are all go-to resources to measure the success. 61 Policy Framework Authentication Policy How does the Zero Trust Exchange decide how to authenticate a user? When connecting to the ZTE through Browser Based Access or Client Connector, the user should be automatically redirected to the SAML IDP. However, what criteria are used to determine which IDP to redirect to? Answer: Client Connector - Was the user prompted to enter a Username? The Domain (after the @) maps to the Identity Provider, and user is redirected to the Identity Provider to authenticate Client Connector - Was the client installed with a –userDomain option The Domain maps to the Identity Provider Browser-Based Access - Multiple Identity Providers configured? The user is prompted for a username/email. The Domain (after the @) maps to the Identity Provider, and user is redirected to the Identity Provider to authenticate Browser-Based Access - Single Identity Provider configured? The user will automatically be redirected to the Identity Provider Looking at the different policy framework and components, think about how the Zero Trust Exchange identifies the user. Can we give anything as part of install parameters or configuration 62 to understand which identity providers should be used to authenticate the user? Based on that, should the user be allowed to connect to the Zero Trust Exchange? We go through an authentication round. The SAML IdP will control whether or not it grants SAML assertions to the user based on its policy. Zscaler consumes that assertion and then makes a decision as to which parts of the Zero Trust Exchange the user is entitled to connect to. Once the user is connected, we can assess information about how the user is connected, whether they're using browser-based access, privileged remote access, whether we're going to drive them into isolation, or use the Zscaler Client Connector and the Zscaler Client Connector can give us that trusted network policy to understand which network the user is on and what services should be enabled. Based on that network policy, we can make decisions on how the user connects. Should they connect to public Service Edges or private Service Edges? Based on the Zscaler Client Connector information, we can understand should we update the user's version of Zscaler Client Connector. What profile should be installed, both the application configuration and the forwarding configuration on the client? Then based on that information and the SAML information that we've provided and device posture, we can make decisions on whether or not Zscaler Internet Access is enabled, Zscaler Private Access, or Zscaler Digital Experience. There are multiple use cases where we might only want to enable Zscaler Internet Access for a user and not Zscaler Private Access or Zscaler Digital Experience, or vice versa. And then based on those SAML authentications, SCIM provisioning, the SOAR solution, SIM solution, analyzing user access, we can build risk posture and we can pass that through and make decisions about whether the user is allowed to access applications through the Zero Trust Exchange, both public and private. We can understand if the device is managed or unmanaged and make policy decisions to allow access to applications. And then also making decisions about how we inspect SSL traffic. What should we do about inspection? Should traffic be inspected or not? How do we handle errors with the original web server certificate? If it's unsigned, if it's invalid because of date or SNI (Server Name