Zero Trust, Explained
If you've read any cybersecurity article in the last few years, chances are it referenced the concept of "Zero Trust". What is Zero Trust, and why has it captured the attention of cybersecurity practitioners across industry and the government? These questions are addressed in this article, which covers the following topics:
- What is Zero Trust?
- Why do we need Zero Trust? What's wrong with today's security?
- What is the difference between Zero Trust and SASE?
- What is Zero Trust Network Access (ZTNA)?
- Aren't all Zero Trust solutions the same?
- What are the properties of an ideal Zero Trust architecture?
- What's the difference between Zero Trust and Micro-Segmentation?
- What is Secure Access 2.0, and why does it include both ZTNA and Micro-Segmentation?
What is Zero Trust?
Today's network security today is oriented around controlling access to a network. Once you are "on the network," you can access any of the resources (applications and data) on that same network. In other words, gaining access to the network means you are trusted to access any of those resources – access policies can only be implemented by moving resources around in networks, making it hard to implement granular policies and make changes to policies.
The Zero Trust methodology shifts the attention away from the network, instead putting the focus on controlling access to resources.
The principles of Zero Trust aren't new - they are based on ideas first captured by the Jericho Forum starting in 2004, but since Forrester coined the term "Zero Trust" in 2010, interest in Zero Trust has taken off as companies have adopted mobility and cloud computing. The Biden administration's recent executive order directing federal agencies to adopt Zero Trust have only increased the importance and urgency around this important trend.
The core tenet of Zero Trust is “never trust, always verify.” At a high level, it's pretty clear - no access should be allowed to a resource without first verifying the requestor's identity and authorization.
Here's a simple example: to use a departmental printer, Alice needs to be "on the same network" as the printer. The printer trusts traffic from Alice – not because it knows who Alice is, but because anyone on the network is to be trusted... right? But what if an attacker finds a way onto that network, malicious traffic would be trusted just as much as Alice's print jobs. At that point, there's not much preventing the printer from becoming part of a massive botnet.
Worse, if there are other sensitive resources on the same network – for example, a database containing customer credit card information – the attacker will be able to access that as well.
The typical way of handling this risk is to keep the credit card database on a completely separate network segment (e.g. VLAN), to increase the degree of difficulty for the attacker. In practice, this is very hard to do for more than just a few highly sensitive assets... which is why ransomware and cybersecurity attacks still constantly make headlines.
In the Zero Trust model, we don't trust traffic implicitly because it comes from a "secure" network; instead, we can follow a 4-step process to validate and secure that traffic:
- Authenticate users, endpoints, and applications, to validate they are who they claim to be
- Authorize every access to ensure it is allowed by policy
- Secure communications with least-privilege
- Encrypt data-in-transit on the network, to guard against snooping
It's much easier to manage security and risk, when it doesn't matter if your network is breached. That's the power and the promise of a proper Zero Trust framework.
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.
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.
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, a Zero Trust architecture can allow you to dramatically simplify the cross-border connectivity, with just one place to check to configure policies and verify access.
What is the difference between Zero Trust and SASE?
Zero Trust is more of a security philosophy that defines how authentication should be performed (granular and identity-based), and how authorization is performed (always). It does not define a specific implementation.
SASE, or Secure Access Service Edge, proposes a new deployment model for security services. SASE incorporates Zero Trust, insofar as it recommends that its security services access layer follow Zero Trust principles, but it is inherently less focused on the details of the security than on the deployment model.
For more information on SASE, check out our explainer article:
What is Zero Trust Network Access (ZTNA)?
Zero Trust Network Access (ZTNA) is the most secure method to allow remote users to access applications or endpoints, and is rapidly replacing traditional legacy VPNs as the remote access solution of choice.
The primary purpose of a VPN is for connectivity - not security. With a VPN, a user's device is virtually added to the corporate network The user can access everything in the corporate network. The rush of corporations to increase capacity to support work from home explains the recent emphasis hackers have put on new VPN exploits and phishing attacks – lots of corporate data is accessible with the right set of credentials.
ZTNA solutions, on the other hand, are built from the ground up with Zero Trust security. They typically use multiple trust factors, such as geolocation and other metadata in combination with standard user authentication and MFA, to authenticate both the user and the device at the same time. This reduces the risk that phished credentials could be used to access corporate data.
ZTNA solutions provide granular policy controls that define which services or endpoints the user is allowed to access, and with which clients the user may use to access them. For example, a typical ZTNA policy might specify something like:
"Alice, from her identified Mac, can use ssh to connect to the build server, using TCP port 22."
"Bob, from his Windows laptop, can use a proprietary client software to connect to the building management system, using either TCP port 80 or 9987-9989."
A good ZTNA should never build "always on connectivity" - following the Zero Trust principles, identity and authorization should be continuously verified. As a result, successful compromise of ZTNA credentials dramatically limits the scope of actions an attacker can take.
Aren't all Zero Trust solutions the same?
In short - no. As interest in Zero Trust has grown, many vendors of network security have slapped a "Zero Trust" nameplate on existing solutions, while others may have partial solutions that provide pieces of Zero Trust.
Still other solutions, like Software-Defined Perimeters (SDP), function as a perimeter "door." They may connect users to a resource, but without segmentation capabilities – once inside, they provide little to no control over how that access may be abused.
While there isn't yet an industry standard for a Zero Trust architecture, NIST is rapidly working to change that through architecture guidelines such as SP 800-207.
Because there are a wide variety of implementations, customers defining their Zero Trust strategy are advised to evaluate factors such as:
- The completeness of the Zero Trust vision
- Whether the solution supports standard TCP/IP applications, or only web apps
- Whether the solution is natively integrated with segmentation controls
- The ease of implementation and end-to-end policy management; and
- Whether the solution will require an infrastructure upgrade to be effective in both on-premises and cloud environments.
What are the properties of an ideal Zero Trust architecture?
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.
Supports Policy Discovery and Evolution
It's difficult for admins to be able to guarantee that policies are properly defined when the service is first turned on. Applications can have undocumented behavior, and even "well understood" applications might have surprise dependencies somewhere in the network. It's important to look your Zero Trust tools to help you discover these dependencies and suggest actions that help increase security over time..
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.
|CoIP Access Platform satisfies all of the properties of an ideal Zero Trust solution.|
What's the difference between Zero Trust and 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.
What is Secure Access 2.0, and why does it include both ZTNA and Micro-Segmentation?
Secure Access 2.0 is a new paradigm that enables specific resources (cloud servers, VMs in a datacenter, or manufacturing devices on a shop floor) as targets for secure access, and couples that access with micro-segmentation controls to protect the resource. The result is policy-driven, fine-grained access to specific resources that can be implemented quickly, completely decoupled from the existing network infrastructure.
For our view on Secure Access 2.0, check out our blog post on this topic.