Zero Trust isn't just a buzzword; it is easily one of the most transformative paradigms in cybersecurity - ever.
That's not hyperbole. There's a good reason all US Federal agencies are rapidly adopting Zero Trust. But Zero Trust doesn't just apply to governments and state secrets; it can deliver major benefits to organizations of any size, even down to SMBs.
So what is Zero Trust, and what can it do? Read on for more:
In this article
- What is Zero Trust?
- A simple explanation of Zero Trust
- Establishing the 'trust' in Zero Trust - authentication and authorization
- The relationship between Zero Trust and identity
- How does Zero Trust protect resources and data?
- What is ZTNA?
- Zero Trust requires a new perimeter
- What is a Zero Trust Architecture?
- How do I create an application perimeter for Zero Trust?
- What is micro-segmentation?
- What is a software-defined perimeter?
- What's the best way to create an application perimeter for Zero Trust?
- How can I use Zero Trust in the cloud?
- How does Zero Trust apply to OT and Critical Infrastructure?
- Are governments paying attention to Zero Trust?
- Does SASE play a role in Zero Trust?
- Some final thoughts on Zero Trust
What is Zero Trust?
Zero Trust is a strategy for securing critical resources, such as databases, application servers, or devices and machines, by positively and continuously validating the identity of all users and applications that access them.
Before Zero Trust, organizations spent a lot of effort to maintain strong perimeter defenses, investing in network firewalls, intrusion detection, network access control, and other tools to try to keep hackers out of their networks.
After two decades, the verdict on legacy network security is in: it just hasn't delivered the results it promised. There are news reports of organizations falling victim to cyberattacks on a daily basis. The reality is, between phishing, social engineering, drive-by downloads, exposed endpoints, and 0-day vulnerabilities, hackers with motive have no shortage of ways to access a modern enterprise.
This fact was highlighted in the Department of Defense's 2022 Zero Trust Strategy:
"[M]alicious actors often breach the Department’s defensive perimeter and roam freely within our information systems."
If the Department of Defense can't keep its networks free of hackers, what hope do the rest of us have?
Zero Trust provides that hope.
A simple explanation of Zero Trust
If you, like the Department of Defense, "assume breach," then you accept that your own networks are not to be trusted. That's what the term Zero Trust really refers to - never implicitly trusting a user or device just because it's on the network.
Since you can't trust users and devices on the network, you must instead build trust through verification. For example, all devices and users trying to access a protected resource must be authenticated ("are you who you claim to be?") and authorized ("are you allowed to access this resource?").
Hackers in your networks trying to access a protected resource will either fail the authentication or the authorization check.
And that's it. Simple concept, right?
Establishing the 'trust' in Zero Trust - authentication and authorization
For Zero Trust to work, we have to set up appropriate tests to verify authentication and authorization.
For authentication, we can select from a range of attributes about users, devices, and client software that can be used to differentiate authorized from unauthorized access. The attributes are typically checked at sign on, and continuously verified throughout the user's session. A simple example of an attribute which might be checked is the location of the user; an executive logging in with the right password but from an unexpected country should require greater scrutiny.
The next step is to define access policies that use those attributes to define who can access what, from where, and how. The authorization granted may vary based on the attributes - for example, a user might be able to browse the Intranet from a BYOD device, but must log in from a corporate-owned device to access the HR system.
A modern Zero Trust implementation will provide the flexibility to choose the right set of attributes and policy definitions to ensure that authorized users enjoy a streamlined experience, while hackers in the network are blocked from accessing the protected resources.
The relationship between Zero Trust and identity
While identity is at the heart of Zero Trust, it's a common mistake to assume that building multi-factor authentication into the "front door" of an application (often a web portal) is the same as Zero Trust. As described in our blog on Zero Trust and identity in detail, there are many other open services on a typical application server. For example, IT admins need to be able to log in to manage the server; that path can provide another way to get to the resource without going through the front door. In other cases, such as the notorious WannaCry ransomware attack, gaining access to the resource can be as simple as sending a carefully-crafted packet to a vulnerable service.
If you assume you are breached and that hackers are in your network, the logical conclusion is that every single network packet must go through authentication and authorization.
In other words, identity is necessary but insufficient for to achieve Zero Trust.
A resource that is protected by Zero Trust is defended in several ways.
First, as described above, all unauthorized packets are blocked. This effectively hides the protected resource on the internal network; this is sometimes called cloaking the resource. Cloaking has many benefits, including:
- Preventing hackers from discovering and probing the protected resource;
- Making it difficult to uncover corporate practices and technology stacks; and
- Blocking accesses from unauthorized clients - including malware, hacker toolkits, and ransomware
Zero Trust policies aren't limited to access to a resource - they can also work in the opposite direction, preventing software on protected resource from making unauthorized lateral access to other machines in the corporate network or on Internet. This secures the data on the resource by:
- Guarding against privilege abuse by authorized users; and
- Blocking - not just detecting - data leaks
One popular deployment configuration with our customers is to restrict access to a resource to known good VDI, with copy/paste controls turned on to block exfiltration to the user's machine. Zero Trust policies are also used to prevent direct exfiltration to the Internet as well as to lateral staging servers.
Another way Zero Trust can help secure resources is by ensuring all traffic to and from the resource travels in an encrypted tunnel. For example, Zentera's CoIP Platform's AppLink <link> capabilities can encrypt LAN traffic to prevent packet sniffing and spoofing. Although not technically part of Zero Trust specifications such as NIST 800-207, LAN encryption is required for the US Government in OMB M-22-09.
What is ZTNA?
The solutions that enforce access policies are typically called Zero Trust Network Access, or ZTNA for short.
A simple way to think of ZTNA is a replacement for VPN - just with much more granular filters that are based on identity of the user, device, and client software.
ZTNA solutions often deploy as a gateway in front of protected resources, or as an agent installed on the protected resource. Zentera offers both models.
In reality, Zero Trust Network Access may not be the best name for the feature, as the policy may not even grant network access in the first place: a common use case for ZTNA is to provide users with access that's limited to specific resources. But despite the potential confusion, the name is already well-entrenched.
ZTNA solutions are often used to enable remote access ("north-south"), but for Zero Trust, it's critical that ZTNA also be used inside the enterprise ("east-west"). A ZTNA solution that doesn't cover the east-west direction doesn't address the basic Zero Trust motivation - filter the threats that are already inside the network. Zentera's ZTNA solutions work for both north-south and east-west accesses, providing users with a consistent access method regardless of whether they are working from home or in the office.
Zero Trust requires a new perimeter
For all of the importance of ZTNA and policies, one of the easiest mistakes to make when architecting Zero Trust is to focus on policies for "front door" access to the application. The reality is that policies you can't enforce are worthless.
The diagram below shows a ZTNA gateway that enforces access policies to the protected resource. In addition to the web "front door," there may be many other open paths - ssh and PowerShell for IT administrators, application performance monitoring and logging tools, to name a few. If threats in the network can bypass the gateway, either by directly accessing an application server or the databases it depends on, what good is it?
ZTNA secures remote access, but resources that are open in the network are still exposed to threats in the network.
To properly protect the resource, we must creating a new perimeter around the resource and its dependencies, so that all accesses to the resources go through policy checks. Once that is done, we have achieved the goals of Zero Trust.
What is a Zero Trust Architecture?
The combination of access policy control with ZTNA and a new perimeter are exactly what are defined in NIST 800-207.
Zero Trust protects resources or assets; everything behind the PEP is implicitly trusted.
The 800-207 spec calls this new perimeter an "implicit trust zone." Servers and devices inside the implicit trust zone are trusted, and do not need to go through policy checks to access each other. All accesses from outside the implicit trust zone have policy enforced at a policy enforcement point (PEP).
In other words, we need to create a new perimeter to force all accesses to go through the PEP. For convenience, we can call this an application perimeter, as it typically contains an application and its dependencies (databases, etc.).
The NIST spec provides a very helpful lens through which to evaluate what is and what is not Zero Trust. Viewed this way, it becomes clear that the core components of Secure Access Service Edge (SASE), such as Secure Web Gateway (SWG), are actually solving other problems (for example, protecting users against malicious web content).
For more on NIST 800-207, check out our NIST SP800-207 explainer article.
It is certainly possible to create an application perimeter using legacy technology. You could choose to put the protected resource and its dependencies in a separate VLAN. You could also change the network topology and put the resource and its dependencies behind a firewall. As NIST SP 800-207 points out, the management overhead and disruption to existing applications makes this a "very poor choice."
There are two other main approaches to create an application perimeter: micro-segmentation and software-defined perimeter.
Micro-segmentation is a technology designed to minimize the attack surface in a datacenter by filtering unused ports between pairs of machines, leaving behind only "authorized" communications.
Most micro-segmentation solutions typically focus on datacenter-scale challenges - deploy everywhere, then use the visibility to filter unused traffic between devices. The filtering rules can be implemented by devices in the network (switch/router ACLs) or by host firewalls (also called "host-based micro-segmentation"). Programming ACLs is highly dependent on the topology of the datacenter, whereas the host-based model easily applies to north-south and east-west traffic, making it more flexible and portable.
Micro-segmentation tools can be used to create a Zero Trust perimeter, but are typically not optimized for this purpose; as the goal of micro-segmentation is to lock down a datacenter, micro-segmentation vendors may be challenged to scale down to individual resources or applications, both from operational and business perspectives. As a result, the difficulty of creating and maintaining a perimeter can vary widely from vendor to vendor.
A software-defined perimeter is a network perimeter that is defined and and can be reconfigured in software, and is purpose-built to create an application perimeter.
An SDP also provides visibility relevant to defining and maintaining an application perimeter. Compared to micro-segmentation, which is typically deployed across the datacenter, an SDP can be deployed to protect a single application server.
Zentera's CoIP Platform implements an Application Chamber, software-defined perimeter that allows administrators to flexibly create perimeters around groups of servers, partition them into smaller groups, or merge them as needed. Zentera's Application Chamber makes it possible to create a SDP that contains a resource and all of its dependencies, but does not disrupt it - no addressing or application changes.
Even decades-old infrastructure supports the VLAN method of limiting the NIST 800-207 implicit trust zone, while micro-segmentation and SDP approaches can generally run on any IP network. SDN, however, requires a significant investment in standardizing your network across all sites. You should not need to upgrade to SDN for the purpose of deploying Zero Trust.
That said, not all approaches are equal - it is critically important to consider the operational costs of VLAN, micro-segmentation, and SDP.
Enterprises tend to have mixed technology stacks, with different vendors and different operational teams responsible for each site; coordinating VLAN deployment and maintenance across the entire estate can be a challenge. Furthermore, cloud infrastructure introduces new concepts, such as VPCs and VNETs. Essentially, building an application perimeter using the existing underlying infrastructure is possible, but can end up costing far more in planning, execution, and maintenance.
Depending on the implementation, micro-segmentation can also suffer from dependencies on the underlying infrastructure. Some vendors use ACLs to program rules into the infrastructure; these types of tools may introduce dependencies on the network infrastructure stack or even the particular API versions used throughout the environment.
SDPs are immune from infrastructure dependencies; they provide a consistent configuration and deployment model across the entire estate. CoIP Platform achieves this with the zLink software agent, supporting virtualized and bare metal servers anywhere, and with the Micro-Segmentation Gatekeeper, which deploys inline with protected resources to create a type of application perimeter called a Zero Trust DMZ.
The Zero Trust paradigm is even more critical in the age of cloud computing. The flexible nature of the cloud and the fact that end users and DevOps need to access cloud applications from anywhere make it difficult to define a traditional perimeter. And as many cloud infrastructures connect back to on-premises environments in a hybrid deployment, cloud misconfigurations can provide a path for attacks to flow back into the enterprise.
Fundamentally speaking, cloud infrastructure is not that different from legacy network infrastructure. All cloud providers offer VPN services, but users can typically connect to one VPN at a time, forcing administrators to make difficult routing choices.
Virtual private clouds, or VPCs, are fast to deploy and easy configure, but are generally difficult to reconfigure - partitioning a VPC usually requires server migration. Compared to an SDP, which can be continually modified to improve security, a VPC is generally static.
An overlay Zero Trust architecture like CoIP Platform can help solve these challenges. CoIP Platform AppLink creates an Application Network that enables any-to-any cross-domain ZTNA. It allows for a single set of identity-based policies to define connectivity, eliminating the need to change them when a workload is migrated from on-prem to cloud.
While the underlying Zero Trust principles are no different for OT and Critical Infrastructure as compared to cloud and datacenter, the implementation can be significantly different.
Many OT workloads cannot accept the software agent needed to create an SDP. In these cases, we can instead define a Zero Trust DMZ to enforce the access policies.
Manufacturing and critical infrastructure environments are highly sensitive to downtime, so it's important to be able to insert the Zero Trust DMZ while minimizing the impact to existing applications.
Zentera helps customers implement a Zero Trust DMZ with the Micro-Segmentation Gatekeeper (MSG), an appliance that deploys inline to protect resources and enforce Zero Trust access policies.
Are governments paying attention to Zero Trust?
In the US, the Biden Administration's Executive Order 14028 mandated all Federal agencies to lead by example, requiring Zero Trust adoption by the end of FY 2024. It also laid the groundwork for the Government to begin pushing Zero Trust requirements down into private industry, starting with its contractors. EO 14028 was also the catalyst for NIST SP800-207 and OMB M-22-09.
Does SASE play a role in Zero Trust?
SASE, or Secure Access Service Edge, proposes a new, cloud-based deployment model for security services that were previously deployed as on-prem components, or are new for the cloud. It includes a basket of capabilities, including SWG, CASB, and SD-WAN.
SASE often includes ZTNA as well. SASE-delivered ZTNA may play a role in remote access for a Zero Trust project, but it cannot deliver on-prem ZTNA, so on-prem users and remote users will have different experiences. It also does not have a concept of an application perimeter, which would be needed for a NIST SP 800-207 Zero Trust Architecture.
For more information on SASE, check out our explainer article:
Some final thoughts on Zero Trust...
Zero Trust can be daunting, especially if you think of Zero Trust as a switch that has to be thrown. There are just too many variables, too many dependencies, and too many unknowns to make a cutover to Zero Trust.
We find customers succeed when they instead view Zero Trust as a journey, and can progress at their own pace.
Transitioning to Zero Trust one resource/use case at a time yields the best results.
Breaking the organizational transition into small steps gives you the opportunity to pause and reflect after each migration, tuning the process to work for your unique organizational needs, building momentum for the transformation from smaller successes. It also gives you a path to training your team and your users on how to get the most out of Zero Trust.
As you consider how to approach your Zero Trust transformation, you'll also want to consider factors such as:
- What kind of assets will I need to protect (VM, bare metal, cloud, OT) - both now and in the future?
- What kinds of network connections will I need? Web apps only, or full support for TCP/UDP/ICMP?
- What kind of policies will I need to implement?
- Can my needs be met by a single platform, or will I need a suite?
- How can I staff the build and run phases of the transformation?
Best of luck with your Zero Trust projects!
Share this article
