In my previous blog, I explained how firewalls and other perimeter-based network security solutions are incapable of delivering zero trust. Be it firewalls and VPNs, cloud-based perimeter models like virtual firewalls, or cloud-based point solutions – none of them comply with a true zero trust framework (as defined by NIST and other leading agencies). But the question remains: if these models cannot deliver zero trust, what can - and how?
The short answer is the Zscaler Zero Trust Exchange. With its unique architecture, this cloud-native platform can guarantee zero trust – unlike legacy network security technologies. Built on proxy architecture, the Zero Trust Exchange, as depicted in Figure 1, acts like an intelligent switchboard that securely connects users to apps, apps to apps, and machines to machines - for any device, over any network, at any location. It mandates verification based on identity and context before granting any communication request to an application.
The Zero Trust Exchange provides zero trust for users, applications, and workloads by securing access to the internet and SaaS as well as private applications wherever they are hosted – on the internet, in data centers, or in private or public clouds.
Let’s review in detail how the Zero Trust Exchange delivers zero trust at scale with its proven architecture. In figure 2, the Zero Trust Exchange sits as a policy enforcer and decision maker in between the entities like mobile devices, IoT, etc. that are trying to connect (at bottom) and the resources like cloud applications, SaaS applications, internet applications, etc. that the entity is trying to access (at top). The Zero Trust Exchange applies policy and context in a variety of ways to come to an enforcement decision, then brokers authorized connectivity to the requested resource.
Identity Verification - The first step is to establish identity. To do so, the Zero Trust Exchange first terminates any connection. Terminating the connection at the very first step might seem like an odd thing to do, but there is a good reason for it. The Zero Trust Exchange halts the session and checks the connection by comparing identity from Identity and Access Management (IAM) systems to verify who this user/person is and what context is associated with their identity. Depending on the type of application, the Zero Trust Exchange can enforce authentication requirements such as ID Proxy, SAML assertion, and MFA (with IdP option).
If the identity check fails, or the user is not allowed to access that specific resource based on identity context, the connection is terminated right there. This is done through a proxy architecture - in contrast to the pass-through architecture of firewalls, which lets the data pass and then performs out-of-band analysis, allowing unknown threats to pass through undetected. The Zero Trust Exchange has API integration with all major identity providers like Okta, Ping, Active Directory / Azure AD, and others to establish that identity.
Device Verification - The next step is to build context around the posture of the device - is it a corporate device or personal? Managed or unmanaged? Compliant or not? Device context is combined with other forms of context, such as the user’s role, what application they are trying to access, what content they are exchanging, and more. Those conditions determine the level of access that gets granted. The Zero Trust Exchange integrates with major endpoint protection solutions such as Microsoft Defender, VMware Carbon Black, Crowdstrike Falcon, and more for context and endpoint security.
Application Policy - The Zero Trust Exchange identifies whether the requested application is a public application or a private application, and further categorizes SaaS applications as sanctioned (apps that the company has purchased, such as M365) or unsanctioned (employees using on their own). Based on the type of application, it classifies the risk of the application and handles access policy by leveraging application risk index with solutions such as URL filtering, Cloud Access Security Broker (CASB) protections, and more. The Zero Trust Exchange also determines the closest application source available to the user, which is then used to establish the connection.
Security Posture - The ultimate goal of any security technology is to protect sensitive data, including encrypted data. Many attackers are hiding malware in SSL, knowing that firewalls cannot inspect encrypted traffic at scale, so they can go undetected. More than 90% of traffic is encrypted today, and while firewalls are incapable of inspecting all encrypted data inline, the Zero Trust Exchange can decrypt traffic and see what’s inside. It provides data loss prevention (DLP), as well as cyberthreat protection for inline data via sandboxing. The context collected in the previous steps is used to look for anomalous behavior. These verifications help identify the risk levels of the users at each step.
If the user passes all of these gates, the key question is: do we want to broker that connection to the requested resource?
Policy Enforcement - Companies determine their business policy to designate at a high level what their employees can and cannot access. Based on those policies, along with the context of the individual request, the Zero Trust Exchange permits or denies access to the applications. Private applications are not exposed to the internet, and access is brokered via outbound-only connections, whereas public applications have conditional access.
Consider an employee from the finance department using a managed device to access financial data - the exchange would allow this transaction if all context required by policy is fulfilled. However, if the employee uses an unmanaged device, full access will not be given. An alternate policy can instead offer access via a remote browser session that streams data as pixels from an isolated session in a containerized environment, but will not allow the data itself to be accessed, downloaded, cached on the device, etc.
The Zero Trust Exchange establishes a granular connection from the entity to the resource or application for which access is authorized. This is a true zero trust connection. Even if there is a security threat, it is limited to that connection between the specific requesting entity and the application it is accessing, rather than the entire network. This architecture is fully compliant with the tenets defined in NIST architecture - essential for any security solution to deliver trusted access.
The Zero Trust Exchange eliminates the need for complex MPLS networks, complex perimeter-based firewall controls, and VPNs - with fast, secure, direct-to-cloud access and secure cloud-to-cloud connectivity that eliminates backhauling, route distribution, and service chaining. Instead of multiple hardware-based or virtual security solutions that are hard to manage and maintain, an integrated zero trust solution secures all internet, SaaS, and private applications with a single, comprehensive platform. The Zero Trust Exchange delivers cloud-native, transparent zero trust access - offering seamless user experience, minimized cost and complexity, increased visibility and granular control, and enhanced performance for a modern approach to zero trust security.
To learn more about zero trust, watch this webinar: Why Firewalls Cannot do Zero Trust. You'll learn what zero trust is, what it isn’t, and best practices for implementation.
