If I asked you to name technologies that enable Zero Trust security, Zero Trust Network Access (ZTNA) would probably be right at the top of your list. That wouldn’t be a surprise - Gartner projects that ZTNA will make up 70% of remote access deployments by 2025. And “Zero Trust” is right in the name! But names can be misleading, and ZTNA has a dirty little secret that most vendors won’t admit.
The truth is, ZTNA doesn’t give you Zero Trust.
As surprising as it may be, most ZTNA solutions on the market play at best a minor role in delivering Zero Trust. To understand why, we need to look carefully at what Zero Trust is about, look at what ZTNA is, and then look critically at the major gaps ZTNA leaves behind.
What is Zero Trust?
There’s enough written about Zero Trust already, so we won’t dive into the details here, but Forrester has a nice writeup, and we’ve written up a detailed explainer in case you’d like to go deep. Summed up, Zero Trust is about applying “never trust, always verify” to protect resources such as applications and data; if you can do that, you can achieve a whole host of benefits including defense against ransomware and 0-day attacks, insider threats, and data leaks, even if your network is crawling with hackers.
And that’s all there is to it.
This actually makes it very simple to evaluate how much a particular technology or solution helps with Zero Trust: once I’ve adopted the technology, how well are my applications and data protected against these kinds of threats?
The answer for most ZTNA is “not very.”
What is ZTNA?
ZTNA typically refers to technologies intended to replace user VPN access. Users are authenticated against the corporate identity provider with multi-factor authentication. Once authenticated, the user is granted access only to specific corporate assets - web access to a corporate web server or shell access to a specific host, for example. ZTNA’s main security benefit is to provide organizations with an alternative to giving out unrestricted network access.
That’s important, to be sure. It’s also much easier to configure ZTNA than it is to set up a firewall to filter VPN connections. But is it Zero Trust?
What gaps does ZTNA leave?
Let’s think about a couple of simple cases to see the problems with ZTNA and Zero Trust.
On-Prem Users
Remote users use the VPN to connect when they’re out of the office. They normally don’t need a VPN when they’re on the office WiFi or plugged into wired Ethernet. The same is true of most ZTNA solutions. They don’t provide any protection for resources when the user already has access to the network.
Houston, we have a problem. There’s no way to get the benefits of Zero Trust if there’s no enforcement point for users, is there?
The truth is, many ZTNA solutions are designed to replace VPN for remote access. They just aren’t intended to act as the sole gate for access to a resource. That means you've made at best a small improvement in the security posture for the applications and data you care about.
Other Open Network Ports on the Application Server
When people think about ZTNA, they think of the benefits of adding identity and MFA to an application server. But that's not the only way in.
Do your administrators need to log in to the server or run Powershell on them to maintain them? How about automation tools like Ansible? Does the server need to communicate to backend resources, like application performance monitors, or log collectors? Can those ports become avenues for insider attacks, ransomware, or data leaks?
A "Zero Trust" solution should prevent these attacks - so what's ZTNA's role here? Short answer: ZTNA doesn't help at all.
Paths for ZTNA Access Abuse
Part of the allure of ZTNA is that it can allow remote least-privilege access to specific resources. But ZTNA can be used for many types of access - including allowing remote users to log in to a server using ssh.
Let’s say you use ZTNA to grant RDP access for a technician to a specific server in your network that controls your HVAC. What stops that 3rd party user from then pivoting to other machines in your network?
ZTNA might reduce the number of ways malicious users can get in, but as this example shows, once they’re in you need other controls to protect assets in your network.
ZTNA and VPN Co-Existence
Most ZTNA customers are probably using ZTNA to replace VPN access for certain users who don’t need access to everything, like contractors. Unless you’ve gone through the exercise of completely migrating all resources to ZTNA, you’re going to still need a traditional VPN in parallel for remote employees.
As discussed earlier, if you have access to the network, ZTNA by itself can’t provide any security benefit. That means that employee VPN credentials are still valuable – and are still a target for phishing.
I think you get the point. ZTNA can help reduce the attack surface that a VPN exposes and does have a security benefit. It might be part of the solution for Zero Trust. But by itself, it’s not Zero Trust.
So what can you do to implement real Zero Trust?
Secure your access today! Learn more about our solutions to meet your security needs
NIST to the Rescue
NIST Special Publication 800-207 outlines what it takes to achieve Zero Trust. Shown conceptually below, it means you need to insert some kind of security enforcement (the Policy Decision Point, or PDP) in front of the resources you are trying to protect. Accesses to the resource are authenticated and authorized by policy, while everything behind the PDP is in an Implicit Trust Zone, where no security checks are performed.
NIST SP800-207 doesn’t prescribe a particular implementation of this model, so it’s important to think through the tradeoffs of various approaches. A poorly-conceived Zero Trust Architecture can lead to higher costs, operational challenges, or even failure of the Zero Trust project.
Just from the ZTNA perspective, here are a couple of key points to consider. Paying attention to these can help you avoid architectural problems that can complicate your ultimate Zero Trust goals.
Make sure your ZTNA is the standard access method for the resource, whether users are on-premises or remote
After spending time and effort to set up a ZTNA, the last thing you want for Zero Trust is for the on-prem users to be able to bypass the MFA and identity checks that you configured. Leaving multiple ways to access a resource can also be confusing for users.
Understand how SaaS-based ZTNA solutions route traffic
Pay close attention to how your ZTNA vendor handles user data traffic. Some SaaS ZTNA solutions route all traffic through a cloud for scanning. This can lead to performance and usability problems for on-prem users accessing on-prem resources.
Avoid ZTNA solutions that rely on a public gateway
Putting the ZTNA gateway in your DMZ means that the security boundary is in your DMZ. The bigger your implicit trust zone, the larger your attack surface and the more difficult it will be to achieve Zero Trust. If you do select a gateway approach, make sure you can put the gateway as close to your protected resource as possible.
The Zentera approach to ZTNA
From our beginning, we designed CoIP Platform to secure the most security-sensitive resources, like those found in advanced semiconductor design, and in fact, wrote about the needs years ago. As a result, our ZTNA implementation doesn’t suffer from the challenges above.
- CoIP Platform ZTNA tightly integrates with our micro-segmentation (Application Chambers), enabling you to ensure that ZTNA is the only way to reach a protected resource;
- CoIP Platform ZTNA provides the same easy-to-use experience whether users are on-premises or remote; and
- CoIP Platform’s Application Network enables "ZTNA 2.0", terminate on an agent running on the resource or at a private gateway deep inside your network, dramatically reducing the size of the implicit trust zone.
For more information on how CoIP Platform can help you deploy a NIST SP800-207 Zero Trust Architecture in record time, check out our white paper or contact a solutions expert for a consultation.
Share this article
