Zero Trust, Explained
What is Zero Trust?
Based on ideas first captured by the Jericho Forum in 2004, “Zero Trust” as a term was coined in 2010 by Forrester to describe a movement to replace implicit trust relationships with explicit authentication and policy-defined access control.
The core tenet of Zero Trust is “never trust, always verify.”
For example, in existing enterprise networks, the network topology creates an implicit trust relationship. Just being connected to a particular subnet automatically grants an endpoint a certain set of access rights within the corporate network. Access from point A to point B is defined by the programming of IP addresses and all of the routers and firewalls along the path. It's difficult enough to visualize what's connected to what, let alone try to manage the risk based on the interaction of these separately-managed components.
Replacing implicit trust with explicit trust surfaces any hidden security assumptions, making it easier to manage security and risk.
Why do we need Zero Trust? What's wrong with today's security?
The traditional enterprise security model is based on a “hardened” perimeter. There were fewer applications, running in a few centralized datacenters, completely under the control of enterprise IT; in those days, securing the enterprise at the perimeter was good enough for the average company.
However, modern enterprise applications run in an increasingly complex environment. Applications and data have increasingly moved beyond the traditional corporate perimeter into the public cloud, already stressing the perimeter model. Add to that an increasingly mobile workforce, increasing requirements for ecosystem collaboration, and multi-cloud initiatives – the increased complexity is clear. At the same time, more of the business operations are digitized than before – companies are more susceptible to cyber threats than they used to be.
The tried-and-true tools in IT’s arsenal – namely, firewalls, VPNs and VLANs – are now over twenty years old. With these tools, policy is defined by topology. They were defined to support static networks, and change management to support complex and dynamic requirements is a struggle.
Consider the connection shown below, between a cloud and resources in a factory environment.
Path connectivity is defined by as many as 6-12 different routers, switches, and firewalls along the path, each potentially managed by a different team. It’s a difficult enough problem to analyze that the best way to validate connectivity is to try it – with a ping. It’s even more difficult to prove that that’s the only connectivity allowed.
Zero Trust dramatically simplifies this problem, by reframing the distributed policy into a single statement of who can access what. For the example above, ZTNA allows you to dramatically simplify the cross-border connectivity, with just one place to check to configure policies and verify access.
Zero Trust Network Access
Zero Trust Network Access (ZTNA) is a secure method of delivering applications to users or other machines. Unlike traditional VPN + firewall solutions, which connect networks at Layer 3 and then attempt to filter, a ZTNA does not rely on the network topology at all, instead using trust factors such as certificates, geolocation, and application fingerprinting to establish the identity of applications.
By default, no connectivity exists. When an application sends a packet, the ZTNA automatically performs a policy check against a centralized database, to authenticate (“are you who you claim to be?”) and authorize (“are you allowed to take this action?”) the combination of user, endpoint, and application on both ends of the connection. Only when policy checks pass are packets allowed to be sent/received.
Aren't all Zero Trust solutions the same?
Unfortunately, there's really no RFC or standard that defines what a Zero Trust "compliant" solution should be. As a result, some vendors have used the term to put a spin on a legacy product.
When evaluating Zero Trust solutions, customers are advised to evaluate the type and strength of the trust factors, the ease of end-to-end policy definition, and whether the solution will require an infrastructure upgrade to be effective in both on-premises and cloud environments..
The Properties of Ideal Zero Trust for Modern Networks
Simple Policy Definition
Enterprises need tools to define and enforce simplicity. Security policies should be human- readable; they should be easily mapped to business requirements to streamline implementation and increase auditability for compliance, and should support automation for repeatability.
Access That Follows Least Privilege
Hybrid environments are complex, yet most corporate resources (VMs, containers, etc) are service-oriented and single-purpose – the in- house git server is not also hosting the Active Directory service. As a result, the ideal solution should have strong mechanisms to define whitelist policies to minimize the attack surface.
Portable to Any Environment
Streamlining cloud adoption and enabling user mobility means companies need to be able to secure their applications and data wherever they happen to be. The ideal Zero Trust solution must shift the focus from network-level architecture to the application-level, operating in every environment and across traditional security boundaries. It should not be dependent on firewalls.
Co-Exists with Existing Networks and Applications
Enterprises cannot switch to this new paradigm overnight. It is important that a Zero Trust solution be deployable to protect critical applications without requiring a forklift upgrade, not only for cost reasons, but also to avoid disrupting the enterprise’s infrastructure and operations.
|Zentera Secure Access and Zentera Cloud Access satisfy all of the properties of an ideal Zero Trust solution.|
Zero Trust vs Micro-Segmentation
Zero Trust and Micro-segmentation are aligned topics, but don't refer to the same thing. Zero Trust has to do with security and the factors that drive security policies; micro-segmentation has more to do with how and where security functions are inserted to protect workloads. For more detail, check out the explanation on our resource page, Micro-Segmentation, Explained.