Hello! I’m back with another installment in a series of posts around zero-trust network access. I’ll explain some more of the architectural components (in general) and touch on the difference between the ZT, ZTN, and ZTNA nomenclatures.
So – What is the difference between ZT, ZTN, and ZTNA? Well, Zero Trust is a set of principles such as least privilege, (micro) segmentation, and machine/user identity that ZTN (Zero Trust Networks) and ZTNA (Zero Trust Network Access) build on. Depending on who you are Gartner and NIST go into great detail on ZT and ZTNA. In addition, a variety of vendors have several posts on their position or take on zero-trust and what it means to them.
As far as ZTNA goes – Zero Trust has been coupled with Zero Trust Network Access to make traditional VPN redundant in terms of remote access for the private access to your applications, where ever they are. Thinking of it another way ZTNA includes ZT and has some varying degrees of features with it that are more or less enabled by the fact that you no longer need to define a perimeter for your VPN solution. At this time I think ZTN and ZTNA are used interchangeably, though you can apply zero trust principles on networks in general for ZTN and I think that ZTNA is mostly focused on remote access to applications.
Perimeter-less remote-access solution
The idea of ZTNA is the absence of traditional VPN connectivity without sacrificing the security of the entire enterprise. In fact, one could say it’s saving the enterprise from further exploitation. Notice I didn’t say the absence of tunneling technology. The user experience is the same whether inside or outside of the corporate network. Furthermore, Depending on the architecture users connect more directly to the application you’re hosting instead of a branch and/or HQ/Data Center which may be sub-optimal. This is especially true in cases where there are global enterprises. I know I am not the only one who’s seen infrastructure built such that end-users somewhere in Asia have to connect to a hub or spoke somewhere in the US or EU (or the reverse). Not only that, remote access configurations which are typically ‘full tunnel’ VPN. The five most often referenced cons for full-tunnel VPN are:
- Snare the SaaS-based traffic
- Direct regular internet traffic to the HQ/branch/DC
- Prevent local access to needed resources
- Increased costs and usage for all that traffic traversing the network
- Having to deal with/think about the client in any way
Moving further, ZTNA it is the complete lack of network-definition in tunnel connectivity that is at the heart of zero-trust network access infrastructure. Technically, split-tunnel happens, but it is at the application level. This generally means packet filtering or host-routes on the end-point. Each application is defined and assigned to users. They are either permitted or excluded from the use of these applications through authentication of the device already so why would you then create an underlay of a network-defined tunnel at all? Doing so is redundant. Even if a service offers a subnet-level definition of the network tunnel customers can easily (and do) define all of the RFC 1918 space in such a configuration to quickly and easily define private space where none is missed. In the end, this is just de-facto full tunnel configuration which negates all of the benefits of a ZTNA service that allows a more direct, but secure access to public and private applications without changing the experience.
But wait, there’s more!
There is one thing I haven’t touched on yet. I bet you’re thinking about your existing investment in all those firewalls all over your enterprise and in your cloud providers right? How do you connect those? What if you want to use them and this service? Well, you can! Migration paths are easy, but here is the nice part. Your firewalls go back to being…firewalls! not Firewalls and VPN concentrators and on and on. Poking holes in your firewalls to allow some of these applications outside of VPN also, potentially, is no longer needed as well.
Look Ma no policy engine
I’m just kidding, of course, there is a policy engine. But when you take a look at a ZTNA service there is little in the way of a policy engine that’s trying to win a drag race. Policy is very simple and relies heavily on your identify provider (IdP) of choice and the MFA/SSO mechanisms you configure. For instance, in a very simplified ZTNA architecture, once you have defined the application and who can access it, under some conditions access can be granted by simply using your Google account as the IdP and you’re in provided you pass.
We can no doubt talk about tunneling protocols and the religion of such all day or several days. However, I do like the simplicity in TLS/DTLS vs IPSec tunnels. I won’t go into why, but I can tell you that almost any ZTNA architecture today is TLS/DTLS based. They are arguably easier to work with and manage than IPsec. Integration into web browsers is easier as well in terms of ZTNA architecture. There are a couple of exceptions to this were some vendors are using wireguard tunnels quite successfully in their service.
The main ZTNA parts that make up the whole
We have a few choices! Each of those choices takes the zero-trust principles and adds their flavor to it to fit a variety of target use cases that are more comfortable to enterprise customers. Below I am showing you the general architectures that you’ll run into. If you’re wondering what an SDP is below it’s called a Software Defined Perimeter. Think of it another way this is where the TLS/DTLS tunnel generally terminates and it is where enforcement happens. These are usually multi-tenant systems that are closest to the end-point, and if there is a connector, closest to the connector.
In general, there are three main parts to the architecture:
- You have a client, hopefully, lightweight and non-intrusive. In fact, you shouldn’t have to think about this client at all.
- You have the SDP/Enforcement node(s)/proxy
- You have a connector that is also a reverse proxy of some kind. The connectivity for this is ‘inside-out’ meaning that it calls home. The effect is that your applications are invisible from the public internet. Why is this important? Attack surface. You don’t have to make any ACL exceptions to host this.
Some variations of this model are as follows:
ZTNA Architecture 1 – Client + Connector + SDP
- End-point client – a lightweight, probably centrally managed
- Connector – Usually a reverse proxy VM that is deployed inside the data center or IaaS
- SDP – Software Defined Perimeter – and enforcement node that handles authentication, proxying of traffic, stitching of tunnels
ZTNA Architecture 2 – Clientless + Connector + SDP
- No client on the end-point. Traffic acquisition handled in a variety of ways such as DNS/CNAME
- SDP – Software Defined Perimeter – Honestly, the SDP/proxy/enforcement node is a pillar of any ZTNA service so I expect to always see this (and so far do)
- Connector VM or connector process. There are two flavors here which are either a full VM or a service/process, that is installed on the application server to run proxy for it. Either way, these connectors call home to the service. So again no ACL changes are needed for this.
- Could be a great ’third-party access’ use case
ZTNA Architecture 3 – No connector and no client, yes has an SDP
- No client or at most some integration into a browser
- No connector – Access to private applications can be handled by very limited exposure. When the SDP proxies the private access traffic the source IP is generally the service provider’s IP. ACL changes only within a specified IP range of the provider. Still invisible to everyone else on the public internet.
- SDP still exists, handles traffic acquisition enforcement, authentication
- Could be a great ’third party access’ use case
There are so many great use cases for ZTNA, but probably the most exciting one is the third-party or B2B use case. I’m going to save this part for another post, but imagine giving a third-party or a B2B process where you didn’t have to worry about setting up lots of vpn config, ensuring that you’re secure, or since most people I have worked with don’t want to or can’t risk offering it all, are able to do so in a secure way that doesn’t put them on your corporate network. You know what I just realized that I haven’t even gotten into how RBI (Remote Browser Isolation) can be combined with these services for enhanced third party access. So I’ll talk a little bit about how that looks as well.
If you have questions reach out! I love talking about the transformation of remote access. Effortless use, better security.
3 thoughts on “ZT, ZTN, ZTNA, Oh my! (and some other things)”
Looking forward to a blog on the Dynamic Duo of RBI and ZTNA.
maybe i am to inexperienced, i just cant get my head around it fully.
Users have to use Applications, maybe installed somewhere, maybe web/app-based, those Applications work with data from databases. This is most of the times, why we need VPN, because those databases are mostly hosted, at the heart of the company.
So as i understand, with ZT,ZTN,ZTNA – we still have tunnels, but not into the heart of the company, but to somewhere else, where the applications are (in your blog, it sounds very cloud centric, but as i understand, it could also be the companys data center).
And we do more with authentification and via measering how “secure” the user, as an “edge” is.
So at all, we are moving “Security” simply around, in the software stack.
What we saw in the last decade, is more and more security bugs in software, because software is build and delivered much faster. Yes with fuzzing and more automatic analysis while building, we get better.
But before we can get any benefit from that, our businesses, engineers, have to adapt to this new “worlds”.
If i have an application, written by my internal developers, that works with a database in the backend, which contains customerdata, i need to have trust, into this application, into the “containment”/micro segmentation around it, into the user…
I can´t see where it gets any simpler. But maybe i am missing a part.
But to deliver a bit more “info” to my point, i also put a link with a press release, by a known vendor (and i could choose every other vendor)
When i look for every new feature, they build into their “plattforms”, a year back, will i find at minimum one advisery with a security bug, for those features? And when i look in a year, from now on, will there not be advisories for every new feature they introduced now? I can not even have trust, to the systems/applications, that should measure how trustable my user or my edge systems are. Because the all fall apart, when we stare long enough at them.
Sorry for the long comment and i am not a native english speaker, so sorry for the “bad” english 🙂
Would be great to here back.
So long, have a nice weekend and stay safe !
LikeLiked by 1 person
I’m sorry for taking so long to get back to this reply. Let me try to answer these questions and hopefully help your understanding better. To be Frank though these architectures are full of nuance. The most important part is the push to simplicity and low effort, low friction access. So it’s honestly difficult because it seems so hard and simple. Apps that have DB back-ends are clearly part of this evolution. The apps can be anywhere. The service however is cloud-centric and centrally managed.
So the first part is the cloud-centric piece. The architecture is cloud centric but honestly the apps can live anywhere. The usual use-case today is apps located in IaaS such as AWS, Azure, GCP, some others so I tend to think of those things. At the same time these services are generally cloud-managed with centralized policy and posture. There’s an enforcement node or ‘widget’ in there and there may or may not be a connector either as a process or a VM closest to the app. For some platforms, like PAN and Fortinet I believe they’re largely vNGFW deployments into the cloud. So if you want full featured firewall in the cloud I guess that could be a route, but I consider them a departure from the SDP based ZTNA model.
Next up is tunnels. A tunnel can be any technology, ipsec, tls, gre and some others. If you open a browser and go to some site the traffic is put into tls which could be considered a tunnel for the flow for the one website. But I understand that tunnels also invoke the large tunnels which have lots of network flows inside them. Acting as ‘circuits’ in a way for traffic flows.
It’s certainly going to be a huge educational effort to get engineers to figure out if these new architectures can work for them or not. Though what I hear most is “what do you want in a VPN” and not really anyone being consultative. If you ask someone with traditional VPN what they want in VPN you’re probably going to get an answer thats aligned with what they know.
The difference between, lets say PAN or Fortinet is that most if not all of the other architectures are cloud-native. I know that’s hand-wavy a bit, but consider that in Umbrella our infrastructure is purposefully built to be upgraded pretty much live and things aren’t long lived. They’re literally not meant for up time. Even though the DCs a whole stay up and available for customers who don’t/shouldn’t notice a difference when things are taken out of service for upgrade and other changes.
In the areas of trust I I rather like the work that is going around that centers on post-authentication. So you’re entitled to access an application, but what happens after that? Maybe certain parts of the security stack can be in the service chain. Some good people are also working on signals between applications in a new-ish standard called CAEP. Something to look into if you’re interested. I think making things more risk-based and dynamic as far as trust will make things even better.
I hope you are doing well and being safe out there!