The point of zero-trust is that you don't implicitly trust something, but instead re-evaluate its trustworthiness every time you have to make an access control decision. Trusting a device simply because it's on your VPN is equivalent to trusting a device simply because it's on your LAN, and this is absolutely not a zero-trust architecture.
NIST SP.800-207: "Zero trust (ZT) is the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources... [it] assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location [and it] focuses on protecting resources (assets, services, workflows, network accounts, etc.), not network segments, as the network location is no longer seen as the prime component to the security posture of the resource."
So while I think you 1st sentence is a bit whooly, your 2nd is bang on. Wireguard (and ergo Tailscale) is focused on connecting devices, not services, and being on the mesh gives you access to other devices/endpoints. To achieve zero trust networking you also need micro-segmentation, least-privilege, attribute-based-access control, authenticate/authorise-before-connectivity as part of the overlay.
Yes you are right it's about continuous evaluation. I'm not sure which part of this setup is implementing that continuous evaluation.
Giving benefit of the doubt, perhaps one of the tools mentioned is doing that implicitly, in which case the author hasn't mentioned it. I think it's ZeroTier but I'm not sure how it's being configured to do so.
Without benefit of the doubt, the author may have misunderstood what ZTNA is and the title is misleading.
I would agree with that assessment — it’s applying something of a fuzzy concept to networking. Arguably it is doing it without a great explanation of how, why, and the trade offs, but then the zero trust concept itself is also still in its evolutionary phase.
Zero trust isn’t about doing it in one place, and then leaving all other doors wide open (although that is one possible realisation).
From a security standpoint, it should be about layering, and making it and based on relevant security anchors. For most people, the fact of being on an authenticated local network is a huge positive indicator. (Or more to the point, being outside of it is the indicator.) This is why, generally, home routers don’t leave the admin interface exposed to the WAN. Are we to advocate dropping the “deny WAN for /admin” rule simply because the admin GUI already has password access control?
And every definition of "zero trust networking" I can find still states that the point is that trust is something that's continually evaluated, which isn't the case if you're trusting someone simply because they're on your VPN.
The gist being that you are no longer making unverifiable trust assumptions about the identity of nodes connected to your network, as you have encrypted links between all nodes (not just between external nodes and a VPN gaetway to a non-zero-trust internal LAN) based on their verified identity and allowed access.
A node's identity can be verified by its public key, so you no longer implicitly need to trust that only known and expected nodes are plugged into the switch in the office (for example). I do not have to care about whether the physical network infrastructure can be trusted (zero trust) because I can verify the identity of all nodes.
This of course does not mean your entire architecture is zero trust. There are pretty much always trust decisions and assumptions somewhere, but that is why it's described as zero trust [mesh] networking, not zero trust complete end to end systems.
edit/aside: some people prefer the term "trust minimising" rather than zero trust to emphasise that there's always trust somewhere and you are just pushing it outside of some component or layer, and I agree this is probably a better/more accurate term.
> Tailscale describe zero trust networking more eloquently than I can...
Allow me to rephrase that for you ...
Tailscale, a company whose business model relies on selling Wireguard-based VPN products, tries to convince people/prospective customers that a VPN can be shoehorned into the Zero Trust concept.
If all you have is a hammer, everything looks like a nail as they say....
Agreed, I literally just replied to the comment below, that TS/WG approach of connecting devices is not zero trust as our focus should be on protecting 'services', not 'devices'. This requries micro-segmentation, least-privilege, attribute-based-access control, authenticate/authorise-before-connectivity as part of the overlay.
Tailscale does offer an ACL system[0] that allows protecting individual ports (which I assume is what is meant by services here?) and defaults to least-privilege (when ACLs are enabled, a node in the network cannot access other nodes by default). Though this configuration is centralized in the control plane. Does this not address some of those issues?
I'm not well-versed in zero-trust networking, so I may be missing something fundamental.
Good to know, the reference article does not talk about this and I was not aware of the feature set. My personal belief is that the term 'zero trust' comes in shades of grey. I personally believe that anything internet exposed is the lowest form, implementing a software-defined perimeter is the next, and that the final is to embed overlay networking into the application itself so we do not have to trust the WAN, LAN or even host OS network. I wrote a blog on this last year using Harry Potter analogies - https://netfoundry.io/demystifying-the-magic-of-zero-trust-w...
Exactly. I am awaare of Ockam, I work on the OpenZiti project (https://github.com/openziti). I believe our approaches to embed zero trust, private overlay networking into the app is the best way (with tunnelers for non-embedded where needed) so that we have the least trust in underlay networks (WAN/LAN/host OS network). Ziti is similar to Ockam at a high level (I am sure there are nuiance differences) though while we do not have a Rust SDK, we do have them for Golang, C, Java, Python, C#, Kotlin, ObjectiveC, JavaSript, NodeJS, etc.
Not quite. 802.1x provides an authentication mechanism to devices wishing to attach to a LAN or WLAN. Tailscale is describing to add E2E encryption between device to server so that if a malicious actor is on the underlay, they only see encrypted packets.
I would instead assert that Tailscale's/Wireguard's approach of connecting devices is not zero trust as our focus should be on protecting 'services', not 'devices'. This requries micro-segmentation, least-privilege, attribute-based-access control, authenticate/authorise-before-connectivity as part of the overlay.
It is more zero trust than it would otherwise be though. An RDP server with tailscale can reject by default packets coming from a LAN. And you can get ALC before a connection can be made.
