Zero Trust Architecture (ZTA) is a security point of view that has gathered enough momentum in 2020 and 2021 to frequently appear in marketing literature. The big idea of zero trust in network computing is roughly, “I confidently know who you are and have applied an appropriate security policy, but I still don’t trust you.”
My understanding of ZTA continues to evolve. This post represents my understanding today, with an emphasis on what ZTA means for network engineers.
How Is ZTA Different From Firewall Rules?
At first glance, zero trust sounds mostly like a firewall policy. Of course I don’t trust you. That’s why we apply all these filtering rules to the VPN tunnel, network interface, etc. Yes, but simple filtering implies a level of trust. The trust comes in the assumption that if you get through the filter, what you’re saying is trustworthy.
Zero trust does away with that assumption. For example…
- ZTA could mean that just because a VPN user passed a complex authentication scheme, their transactions are not assumed to be wholesome. Well done–your username and password check out, and we’ve applied a filtering policy to your tunnel. With that completed, we’re now going to monitor every single thing you say to make sure you don’t try anything funny.
- ZTA could also mean that despite effective microsegmentation, communications across allowed ports are not trusted. You modeled the east-west data center traffic really well. The resulting microsegmentation policy is thorough. That’s nice. Now we’re going to scrutinize what each host is talking about inside of these allowed conversations.
Presumption Of Breach
Zero trust assumes that every endpoint has been compromised and represents a threat. Therefore, even though an endpoint is connected to the network legitimately and allowed secure access to resources, the access requests themselves are suspect.
Let’s try a couple of metaphors…
- A registered vehicle might be allowed on public roads, but could be carrying contraband. A security control might be to check every vehicle for contraband before allowing the vehicle to continue.
- A human might appear healthy, but could be an asymptomatic virus carrier. A security control might be to test every human for the presence of a virus before they can mingle with other humans.
I Don’t Feel Edgy Anymore
Another complicating factor driving ZTA is that a modern network doesn’t have natural checkpoints where deep packet inspection should clearly be done. Historically, we’ve interwoven physical campuses, colocation facilities, and data centers with carefully constructed WAN links. We’d plumb in our circuits and stick a firewall between the public bit and the private bit. Or we’d erect a barrier between zones where it just made sense, such as between QA and production environments. Of course, remote workers had to come in via a specific VPN concentrator to access company computing resources, and that concentrator was probably a DPI firewall, too.
Nowadays, the perimeter simply doesn’t exist in any meaningful way. We scatter compute resources folks need to access across physical premises, data centers, colocation, and a wide variety of public cloud services. And the humans themselves requiring secure access could be and, in the pandemic age, are anywhere. Where is the perimeter with the obvious junctions at which to place traffic checkpoints?
In this edgeless context, I’ve noticed that ZTA tends to be endpoint-oriented, because that’s where enforcement often needs to happen. Think agents manipulating local host firewalls, for instance. Endpoints are not the only places where security enforcement can happen, however. For example, some zero trust products are proxies, which play architecturally well into the edgeless network concept. You can put a proxy anywhere and point a client at it. Performance when using said proxy is another question, but we don’t need to discuss the speed of light today.
Using NIST’s SP 800-207 As A Zero Trust Architecture Reference
While despairing that zero trust had become a meaningless marketing term, I discovered NIST’s SP 800-207, Zero Trust Architecture document. NIST 800-207 is now my standard to interpret vendor marketing claims about the zero trust capabilities of their products.
NIST SP 800-207 is aimed at enterprises developing a zero trust architecture. The document includes ZTA principles (the seven tenets), logical components comprising a ZTA, deployment scenarios most enterprise network architects would recognize, implementation strategies, and associated risks. The document isn’t overly long at 59 PDF pages, but most of these pages are dense.
ZTA vs. ZTNA
Vendor security literature might mention both ZTA and zero trust network access (ZTNA). Based on the reading I’ve done thus far in NIST SP 800-207 and elsewhere, I believe that ZTA is opinionated about the entire computing stack, while ZTNA is focused on the network layer. Assuming I’m correct about that, technologies such as 802.1x and NAC fall under the ZTNA umbrella, while ZTNA itself falls under the larger ZTA umbrella.
The idea of “What do words mean?” comes into play here, because depending on which vendor you talk to, ZTA or perhaps just “zero trust” and ZTNA seem interchangeable. Pair that with the opinion some network engineers hold that ZTNA is just NAC, and zero trust suddenly feels like a nothingburger.
However, ZTA implies something more significant than merely ZTNA. Therefore, when evaluating products for your organization’s ZTA strategy, it’s important to find out if what the vendor means is also what you mean. Do not assume the shiny new zero trust solution is just a rebranded version of their NAC solution. That might be all there is to it, or there might be something more complex and capable going on.
In summary, my current thinking is that the terms zero trust or ZTA signal a strategy while the term ZTNA signals a product or solution that’s a tactical component of that strategy.
If you have an opinion about ZTA vs. ZTNA and whether ZTNA is just a buzzword to describe NAC, let me know on Twitter @ecbanks or DM on the Packet Pushers Slack channel. I appreciate all feedback, corrections, and alternate viewpoints from anyone in the networking community, including you nice vendor folks.