I suppose the thesis that it’s a bad name is borne out by the fact that many technical people misunderstand it; it’s a contraction of “zero trust networking” and is a fine description of the technical approach: don’t trust anyone by virtue of their network location. (Trust is negotiated at the application layer.)
#NoVPN or Zero Perimeter could be better slogans.
On the other hand, the only people I have seen confused are technical people that (incorrectly) think they have identified an inconsistency; non-technical folks seem fine to just map name->feature-set.
Agreed - I've seen the same result in my current company. The only real objection raised is from a technical pedant who argues that we're trusting identity and so we shouldn't call in _Zero_ Trust. He's almost deliberately missing the point though.
Our users, on the other hand, are not making any real noise about it because from their point of view it's the natural extension of SSO (from the point of view of that being the only bit that they will interact with in any meaningful way) and that was something that reduced friction for them too.
We've not suffered from the name really, to be honest.
+1 for NoVPN. It's short, sweet, and quickly conveys the benefit. It may also remind people of the frustrations they often face using VPN software, which is often flaky and has a poor UI, so eliminating it could be met with feelings of relief.
Nevertheless, it's always a little unsettling whenever some Internet rando confidently posits that a phrase conveys a certain meaning or emotional reaction to people without any evidence whatsoever. I mean, come on, do a little market research. Do your homework. (The same goes for me!)
I don't agree, but I would like to try to give you the benefit of some doubt--what is it about vpn that you think adds to the overall defennce when zero trust networking is fully implemented?
Zero-trust networking -- with or without a VPN -- requires that every internal service be properly configured. If a sensitive service escapes the lab and becomes accessible without bring properly set up, then at least having it behind a VPN gives you a little air cover. If there's no VPN whatsoever, then this service can potentially be accessed by the public.
IOW, "when zero trust networking is fully implemented" is a precondition that isn't always realistically achievable, especially in large distributed organizations where you don't always have complete control over what your colleagues build and deploy.
Makes no sense to do market research for this. You throw a new naming out there and see if it sticks. If it sticks, done, if not, no market research needed.
The blog author wasn't recommending a new name. He was merely complaining about the name without any data whatsoever to back up his claim.
Mere destructive criticism is cheap and easy, and isn't worth posting here IMO. Creativity and success, OTOH, are frequently difficult and worthy of praise and sharing.
You can have ZTN with a VPN and you can have a perimeter with ZTN. What you can't have is trust based on network position. So I think Zero Trust is fine.
It's a marketing term ultimately and any practitioner should be able to understand what it means. If they don't it's kinda on them.
I’m not familiar with anyone in the ZTN space advocating for a need for VPNs. Do you have any examples you can share?
Google explicitly positions BeyondCorp as a replacement for VPN:
> BeyondCorp is a Zero Trust security framework modeled by Google that shifts access controls from the perimeter to individual devices and users. The end result allows employees to work securely from any location without the need for a traditional VPN.
Advocating for a VPN or not isn't relevant. ZeroTrust isn't "no vpns". You can do ZeroTrust and have a VPN. ZTN is more about what you do than what you don't do, despite the name.
1. Clients authenticate servers
2. Servers authenticate clients
3. Communications are encrypted and auditable
4. Fine grained authorization using available context like device health
You could have employees hold a client cert, connect to a VPN, have the VPN attest the employee's state, and then provide them access to a subnet. From that subnet they can continue talking to other services that also perform authn/authz. The VPN doesn't make it "less" zero trust, it's just that the traditional VPN model is one where it's the single point of auth.
We could take cues from the food world: Better Than VPN, I can't believe it's not VPN!
I'm not really convinced the name is a real problem. We use a lot of terms that aren't obvious and it works just fine. For example, http. First you have to learn that means Hypertext Transfer Protocol, then you have to learn what Hypertext means, and then you have to learn that it's used for a lot more than Hypertext these days.
The problem isn't that it's not obvious, but that it's actively counterintuitive.
If a car company was called 'GJKN', and that stood for some obscure acronym, you'd just memorize that. But you'd probably be a lot more confused by the car company 'NoWheels' when their car still has wheels, just in different places.
It's a bad term in the sense that it's not self-explanatory. Hearing just the term itself is likely to give you the wrong idea about what it means.
Learning a name -> feature mapping isn't a problem in itself, but the fact that you have to do it before you get an approximately correct idea regarding what it's about is an unnecessary inefficiency.
Without going to much into it I thought Zero Trust is some new funky cryptographic way of eliminating the need for trust in some interaction between parties.
Turns out it is just a different phrase for the existing concept of defense in depth.
Certainly one could define defence in depth as a component of zero trust I guess (very vaguely) but they represent different perspectives.
Defence in depth is a technologically focused approach: implementing redundant checks at multiple architectural layers of a stack.
Zero trust is about the high-level approach to perimeters and ACLs, including not only tech & stack architecting, but organisational messaging / policy / culture.
If using Google's BeyondCorp architecture as the definition of "Zero Trust"[1], it does away with traditional "defence in depth" redundancy such as implementing, in series, IPSec/Wireguard/TLS tunneling AND mutually authenticated application layer TLS to mitigate a single technology failing. Instead, network boundaries are removed and anyone can access internal system login pages across the Internet from a web browser[2]. In place of network boundaries, device attestation[3] is relied upon to ensure control over the state of devices that are being used to access the internal system.
I would argue that the "Zero Trust" definition in the BeyondCorp architecture is somewhat an opposite of "defence in depth" because it appears to advocate so many single points of failure. You have to trust the TPM manufacturer's claims. You have to be certain the software running the public facing login portal is free of remotely exploitable vulnerabilities. You have to trust your whole business on the source code of a single vendor providing the software for centralised user authentication. You have to trust the few employees who manage these single points of failure with an entire business rather than a small part of the business.
Defence in depth is either achieved by implementing systems in series, or in parallel.
Systems in series have decreased availability and thus have a downside of an exploitation in any one system in series being a more likely occurrence (larger attack surface), and upon an occurrence, the availability of all systems in series is impacted. For example, let there be two proxies in series from two vendors, each proxy performing deep packet inspection and analysis of files being transferred. To get a file transferred through both proxies, an attacker has to convince both proxies (independently implemented) that the file is not malicious, and thus it is harder to fool two systems rather than one. However an attacker can find a content parsing vulnerability in either proxy (double the attack surface) and use the access gained to more readily deny service, leak information or inject or modify information.
Systems in parallel introduce a larger attack surface and thus exploitation occurrences are more likely, but each occurrence has significantly decreased consequence. An example of such an architecture is different divisions of a business using SFTP, TLS or SMB protocols to transfer files, and different divisions using different implementations of those protocols in different software. An encryption vulnerability in one implementation of one protocol may only expose two divisions of the business, but the other divisions would not be directly impacted. It is likely that incidents occur more frequently as there is a much larger attack surface, but each incident has a less severe outcome.
I have to agree that "zero trust" is terrible marketing (alongside "trustless computing" or variations of that). Generally, we think of "trust" as a positive term, and having zero of it seems bad. That's at least the brain-stem reaction I have to this term, and I think no amount of "but but but you see the problem is we trust the wrong things therefore we should have none of it" will fix the perception.
If I'm not mistaken, the point of the term is that you're not just punting to the firewall to protect your network: eggshells are not sufficient to protect eggs. Thus the proposal isn't "zero shell eggs", it's closer to "all shell no egg".
I don't have a good alternative to it, but maybe something like "Continuous Skepticism", "Always Verify", "Pervasive Vigilance", or "Verify Everything" might be terms that evolve in the right direction. I don't think any of these are winners, but at least none of these take a fairly universally positive term (like trust) and negate it without further explanation.
"Zero trust" really feels more like just an eye-popping bullet point in a consultant's slide deck that gets thrown in to make sure the client hasn't totally nodded off by the 10th slide...
> I have to agree that "zero trust" is terrible marketing
I hate to say it but it's brilliant marketing to the people the vendors selling this are targeting - IT departments and CSO's lumped with compliance to arbitrary security certifications and audits.
For these people the user themselves are as much the enemy as the actual attack vectors: they do not trust the staff in their organisation and their goal is to implement infrastructure to control and surveil and limit the scope of their activities to the greatest extent possible.
So in fact, the double-speak of the "zero trust" phrasing fully aligns with their internal motivations and is now well and truly embedded in as a marketing term in the latest crop of security vendors.
I think that's what's intended by "zero trust". It's not that trust is bad, it's that it's not necessary when you architect the system in a certain way.
One defining trait of 2022 is the breakdown of trust. (The other is that people insist that "this time is different" and that history doesn't have anything to teach us about the current time.)
If you look at /new/ on HN you will see there are people who have nothing better to do than second-guess every decision the government or any other organization made about the coronavirus.
Blockheads think you can't trust banks, central banks, or anybody except the person who wants you to buy the latest shitcoin.
Yes, except that when marketing is involved the first order of emotional response is that you put the words in the blender and treat them as a "bag of words" independent of order or contextual meaning. That's just how people respond in the first 0.2 s, and since people receive one or two orders of magnitude of marketing communications than they can process that first 0.2s is critical as to if they will see any more of it.
Why should the average end user care or know what the internal security model and practices are referred to as? How would they even discover that a given app or brand is trying to enforce zero trust without reading their engineering blog or fine print or something like that? Such motivated person would certainly not be confused by the nomenclature. Many things are named sub-optimally in technology, this seems like a strange one to write a post on.
For end users you have magic of single sign on - they use login to their work laptop and seamlessly navigate to whatever they need for their work without ANY login screens.
'Zero Trust' is for back-end services where you assume you need encryption at transit and you always need some authorization to check if someone or something has access to other stuff.
The zero trust idea is 'just because they are on the right subnet doesn't mean you can trust them'. So you add things like healthyness checks (is this device up to date), anomaly detection, and use those to dynamically determine how much authentication challenge you give a user.
For this to work, the key is really good and easy single sign on with second factor also made easy. That way you can do more trusted authentication (a SSO token backed by Microsoft login is harder to phish than just a password. More importantly, it really lowers the authentication burden on your users.
Zeeo trust, as I understand it, is all about authenticating user devices, rather than fixed appliances. It is much less something that happens between appliances (though appliances authenticating themselves to clients does count).
I think that is incompatible with what parent said.
This. Zero Trust will be a pain for service owners, admins etc., but for the end user, it should be pretty smooth. There may be bugs/errors initially, but there should not be any permanently added friction.
Quite the opposite, Zero Trust can mean that the user can now access services that previously needed a VPN from anywhere, without caring what network they are one.
Honestly one of the hardest things about zero trust is getting end users who aren’t used to it to stop trying to solve problems by turning on the VPN.
(We are almost completely zero trust, but obviously there are still a few legacy systems you need to connect to a VPN to access)
I don’t do deskside support, but I do have to help nontechnical people interact with apps and services occasionally, and often their first troubleshooting step is ‘make sure the VPN is on’, whereas mine tends to be ‘let’s eliminate a potential source of network craziness and make sure the VPN is definitely off’
So do tend to think that the important messaging for end users is that zero trust is about eliminating something - making things simpler.
Reading the original BeyondCorp paper, I think Zero Trust was from the beginning construed as an end-user-facing replacement for VPNs. Sure, you can use it for backend services too, but it definitely doesn’t exclude end-users.
Add to that it will be marketing tool for B2B market - "we support SSO and Zero Trust", your users will seamlessly login to our solution and after they login we check at each step if they have access to the resources they want to access.
Zero Trust is as simple as setting up your network so there are no arbitrary services added to the network that are discoverable or visible that are not known in advance, vetted and trusted. For end users it looks like a wifi hotspot where you cannot see other machines connected to the hotspot, and they cannot see you. Most modern services work fine in this environment, but older less secure, let's host a server on my desktop type software will not work. It also means getting rid of a lot of shared services where Bob in sales can click on an attachment and bitlocker all the contents of shared drives.
Zero Trust unlocks a couple very desirable things: simpler LANs with less stuff to break, it's harder for trojans to spread, and better access control. Zero Trust is also really hard to do in places where you have a huge, managed LAN and a bunch of thick client software that relies on direct network connections, or direct connections to database servers and the like.
To put it more succinctly, in the zero-trust mindset it isn't ever _your_ network.
It's a network you happen to be connected to. Your only trust the network at the physical layer that it won't destroy your hardware. Beyond that you don't trust anything you receive over the network that you can't independently verify.
I work for a really large organization that has received praise for what it is doing with zero trust but to us lowly users the implementation has really meant the total death of single sign on. We sign on constantly to everything now all the time.
Zero Trust is really just defense in depth[0]. All the things it implements are DiD solutions that have existed way before the term Zero Trust emerged.
Defense in depth, combined with abandoning the pretense that certain things that were regarded as security perimeters (like ‘having an IP address on a specific subnet’) we’re not really defenses in the first place.
As someone not working in security -- nobody working in security actually believed in that kind of stuff, right? Even my dumb self knows that the network is fundamentally full of evil nodes.
It's not so much that servers would be left wide open to be hit by anything that plugged into the LAN (although, sure... some of that, too), but more that there was no need seen for things like endpoint firewalls on user desktop machines plugged in to the LAN, because they were 'behind the firewall'.
And honestly even today we still see that thinking in datacenter ops and even virtual cloud ops. I've seen people say 'I don't need to worry about those mongo credential compromises because I'm running mongo on a secure VPC'.
A surprisingly large share of people "working in security" are actually just checking boxes, and are very risk averse so resist all change, especially taking out any boxes.
I think part of the issue with Zero Trust (ZT) is that it's been applied too broadly in too many contexts. For example, a number of cloud services advertise as ZT, but they probably would actually prefer the nomenclature Zero Knowledge. But of course zero knowledge is being namesquatted (ha!) by an actual cryptography concept, so people who know the difference rightly objected to companies co-opting it. Now a bunch non-cloud offering also want to get on the ZT bandwagon, which just further dilutes and muddies the meaning of the term. Since there's no actual standard defining ZT, it becomes just about as meaningful a descriptor as Best Practices and Military-Grade Encryption.
- We treat the internal network the same as external networks, like your home network. Our systems don't care whether you are at home or at work - you'll have to verify and authenticate the same no matter what.
then workers will be asking "Oh, so why don't I just work from home..."
Reading the comments here you'd think this article was complaining about what zero trust is or how it is bad. Instead it is about how we explain Zero Trust to others and the very real interpretation of "zero trust for (you)" by end users hearing about this be policy.
A realistic interpretation given the way machines and etc are locked down. It doesn't seem like a bad idea to me to come up with a better name to avoid friction with those unfamiliar with the concept. Even as it is on HN people seem to jump to conclusions based on the name so imagine non technical users hearing about this.
Biggest problem with current "Zero Trust" implementations is they imply a full surveillance of employees' Internet traffic including man-in-the-middling their encrypted SSL requests. My company just deployed "ZScaler" -- a product marketed as a "zero trust" VPN solution but in actuality is an Orwellian surveillance tool. This will give "zero trust" a nice negative connotation very soon.
Single point of failure devices for decryption of traffic (MitM) is not in line with the original definition of "zero trust", and VPNs certainly aren't either.
Zero trust arose out of this exact sort of scenario following the Snowden leaks and the NSA document showing "SSL added and removed here". End to end encryption and removing MitM middleboxes was the answer to SSL intercepting proxies.
This is a VPN/SSL interception product attempting to remain relevant by advertising as something it isn't.
ZScaler has coopted the term Zero Trust for marketing purposes. Their SSL interception tool is branded as part of their Zero Trust but is antithetical to the principles of zero trust ... in fact, IMHO anybody who deploys it is further away from achieving Zero Trust than before they started - instead of users authenticating using individually secured transactions to every TLS endpoint they connect to, it is all centralized in ZScaler which is ubiquitously trusted across the organisation. This is a centralizing of the trust model that is the opposite of the intent of Zero Trust.
I hope ZScaler gets shamed into modifying or removing some of this branding (or alternatively sued when one of their customers gets attacked or fails an audit after believing it ...)
A lot of the time, SSL MITM proxies are used as a mechanism to detect malicious content within a corporate content. I have seen, deployed across millions of machines, prevent phishing documents from being detonated thousands of times.
i’m not really sure what you mean. most of these products are indeed reverse-proxies, but reverse proxies do not sit in front of the whole internet, just corporate services
I wonder what user speed bumps people have seen around zero trust. When IBM started adopting it, employees rejoiced that they could access email and Slack without the VPN.
I first heard the term a few years ago, but because I work in that space it didn't bother me. When I talk about it to network ops folks I like to say "perimeterless", which is a fair description of what they care most about: no more firewalls, DMZ, or "internal" vs "external".
The device-centric authentication and authorization part, I don't really have a good simple term. When it works well, I call it "better user experience" because to the people accessing, there's a lot less for them to deal with, and fewer passwords to remember or VPN status to worry about.
The lack of a VPN requirement is nice. The experience from my last job where we had a VPN was that everything worked pretty well for employees with company-issued laptops, but when a division hired contractors or brought in a third party, they weren't issued laptops, so they couldn't access anything on the VPN, leading to continuous support issues and work for the netops folks.
For my part I really like it because it addresses one aspect of security often neglected (even more so than security in general): internal malicious actors. Disgruntled employees, workers that expeditious bypass security because their boss has to have it NOW, executives and senior leadership that throw their weight around and get special access to bypass security, or simple human error. Also, all the un-encrypted internal traffic. In this case, "zero trust" applies, because where companies used to trust their employees not to screw around with company assets, hard experience has demonstrated that even absent malice, people do stupid things and it costs real money.
"Zero trust" is fine as a name; it's basically a reminder to be careful of where you place implicit trust in your security model. Self-reflection showed that typical corporate network models had an increasingly unjustified degree of trust in the integrity of their internal networks and endpoints attached to those networks; so that tends to be referent that people identify.
I think zero trust describes the philosophy more than the implementation. Design the network so that we treat every device like it is not to be trusted.
I have experienced first hand the reaction of people who feel "so you don't trust us any more"? What are we not allowed to do now? when first exposed to this term.
Part of the missing puzzle pieces here are ambiguity about the word "trust". People generally think it is a good thing to have trust. So why do we want zero of it? How can that possibly be a good thing?
I think something that emphasises the increase in trustworthiness of the overall system due to this would be ideal. Such as "continuous trust verification (CTV)" might be good.
It does not help that certain companies (looking at you ZScaler) have abused this term for marketing purposes. They are actively harming not just their own customers but the entire security industry through their branding of products completely unrelated to it as zero trust. A lot of people in decision making roles now believe Zero Trust(tm) means in fact, some things that are the complete opposite of what it actually means.
I used to work for Rogue Wave Software, who had a product called "Software Parts Manager" which was shortened to SPM, which was used to build code across a number of flavors of Unix, compilers, etc.
The developers internally didn't seem to like it much. They called it SPAM instead of SPM. One day, I as the person managing the online commerce system, see there is an upgrade of one of the products. I scan the README file, and whoever wrote it internally constantly referenced "SPAM" in terms of how to use it.
Anyway to this day, I am a stickler for making teams use the real name, and not the slang name. And if a team ever creates a derogatory name for a product, I see it as a huge red flag that the product itself has issues. But conversely if the slang name is a good one, it's worth considering making that the official or openly fun/positive unofficial name.
The past few years I've watched several clients rebrand their internal "CyberSecurity Awareness Month" to "Cyber Awareness Month" because of the stuff that had come out around Apple's photo scanning plans and the constant use of CSAM in those contexts.
The first big step that systems people are calling "Zero Trust" have in common is that they don't trust devices based on the (physical or virtual) network they're connecting from.
There are all kinds of other things that are still trusted, so "Zero" isn't terribly helpful.
'Zero trust' as a term was popularized over a decade ago by John Kindervag, and has roots older than that. Kindervag focused on the fact that we shouldn't trust LAN/WAN devices just because they were (apparently) on the LAN/WAN.
We are well beyond that era - devices, users, apps and data are now massively distributed. In this new era, the question is can we avoid 'trusting' all networks.
Of course, you need to trust something, so that paradigm would suggest that the app is the new edge, and only enable identified, authenticated, authorized ('trusted') app sessions to make ephemeral network connections. In that model, all inbound firewall ports are closed (not even dynamic port opening), so that unauthorized sessions can't even scan/probe.
Still have plenty of services with network trust everywhere I've worked, particularly in the oldest and slowest moving parts of an organization, but now I'm on VPN instead of LAN. I can still ping AD and SAP and whatever else one could find if you could run nmap on your work network.
It's not really about trusting more or less outside networks, it's about exposing your network very selectively (e.g. single services behind authenticating proxies), preferably with a corporate login and some form of device attestation.
We are doing this at $work, everyone says "zero trust" but means something different, high level goals set but hard to translate those to implementation.
Someone argued with me that trusting a byod mobile phone for a 2fa app that phones home with checkmarks is zero trust because of the check alone, never mind a user's crappy android that isn't corporate managed/monitored is being used for both first and second factor auth. The fact that they do a lot of auth all over the place yet all that depends on the security of a random user's random personal phone being trusted does not prevent it from being called "the zero-trust way".
Mutually Assured Trust was the first thing that popped into my mind when reading the article. The premise of explaining things to end users and the difficulty of naming things also reminds me of the Kerberos paper [Designing an Authentication System:
a Dialogue in Four Scenes](https://web.mit.edu/kerberos/dialogue.html). Zero Trust reminds me of Kerberos, reborn into a web-first world.
Zero Trust is a fine phrase, but it greatly over claims. (Unless I'm missing something, and it eliminates trust requirements for third party SSO services, software supply chains, infrastructure operators, and other common attack vectors).
It doesn't eliminate the trust requirement for any of those at all.
It's easier to talk about zero trust by identifying the thing it is not. For example, ZT is not "it is sufficient to be inside X" where X is on a host, in a container or not, on a subnet (we are less than ten years way from having to argue with people about "why are we using encryption on our internal connections?"), or some other context, and so on.
The way that Google handles it, at least based on their publications about BeyondCorp is that endpoints are authenticated cryptographically by TLS certificates backed by their TPM chips.
When someone tries to connect to a service, instead of having a firewall verify their device is trusted by checking the IP address is within a trusted range, the device is authenticated by the Access Proxy using mutual TLS.
Authorization decisions incorporate both device and user privileges. A machine that isn't registered as being physically bolted to the floor inside a physical security domain won't be able to access certain highly restricted resources. A machine that isn't registered as being up to date on security patches will also have privileges restricted. A machine which does not present a client certificate or presents a client certificate that is no longer trusted will only be able to access services intended for the public.
Instead of treating the subnet as a de facto database of trusted machines, there's an actual database of trusted machines that is incorporated into authorization decisions at access time.
So, now they trust a widely accessed proxy, a TLS certificate authority, a TPM chip (they aren't really TPM's right? The spec mandates trivial physical exploits...), the database, and whatever network protocols tie all this stuff together.
That's many more machines than a system that relies on old fashioned SSH client certs. Client certs don't really scale, but I guess Google has to give up some security, given their size.
I don't understand why a small business would reproduce all that complexity though, especially since it requires outsourcing a bunch of critical components to untrustworthy third parties.
First of all, I think it'd probably help to link the publication I'm using as my primary source [1].
The certificate is indeed stored in a TPM:
> Desktops and laptops use an X.509 machine certificate and a
corresponding private key stored in the system certificate store.
Key storage, a standard feature of modern operating systems,
ensures that command-line tools (and daemons) that com-
municate with servers via the AP can be consistently matched
against the correct device identifier. Since TLS requires the
client to present a cryptographic proof of private key possession,
this implementation makes the identifier non-spoofable and
non-clonable, assuming it’s stored in secure hardware such as a
Trusted Platform Module (TPM).
I'd be interested to hear more about how they are trivially exploited. I had not heard that was the case, and from the quote above it seems that information had evaded Google's engineers as well since they are considering credentials stored in TPMs to be non-clonable.
The primary trouble with SSH keys is that they can only authenticate one thing: they're either something the user can exfiltrate from the machine, in which case they authenticate the user and trust the user to authenticate the machine, or they are locked to the machine, in which case they authenticate the machine and trust the machine to authenticate the user. This was a common difficulty that Google ran into when implementing Inventory-Based Access Control for their BeyondCorp system: protocols are typically designed to authenticate a single identity, which may be the user or the machine but not both, which leaves the door open for users connecting from unauthorized endpoint devices whose security posture cannot be validated (if only authenticating the user) or adversaries stealing authorized endpoint devices. The point of the Access Proxy is to provide two distinct authentication steps: one to authenticate the device via mutual TLS and one to authenticate the user via their SSO credentials.
> In the cases of gRPC and TLS traffic, we wrapped the bytes
in an HTTP CONNECT request. Wrapping has the obvious
downside of imposing a (negligible) performance penalty on the
transported protocol. However, it has the important advantage of
separating device identification and user identification at differ-
ent layers of the protocol stack. Inventory-based access control
is a relatively new concept, so we frequently find that existing
protocols have native support for user authentication (e.g., both
LOAS and SSH provide this), but extending them with device
credentials is non-trivial.
The value added by private networks is not only the fact that all of the people on them are trusted, but also that (at least in enterprise systems) all of the devices on them are trusted as well. In the absence of network trust, the policy decision point needs a different way to authenticate the device to replace the authentication step that would normally be done at the time when the device attempts to connect to the VPN or the internal network. In an equivalent system that used a VPN, the database utilized to make device access control decisions would already exist, but the policy would be applied when the device attempts to join the network, and then the never again as the device freely interacts with other resources on the network. The access proxy applies that device authorization policy at resource access time instead of network admission time.
That would only be true if the access granted to machines that were in the previously trusted network was now completely eliminated (probably breaking all sorts of critical systems).
Instead, the proponents of zero trust have redefined "untrusted network endpoints" to mean "trusted network endpoints".
I get this, but I don’t get why that means we should do away with VPNs, etc. Isn’t “in my private network” an additional piece of information that can be used to help authenticate a client?
Sure you can still have a VPN. It’s just not used for security because that’s a terrible idea.
We’re talking about situations where you have some control over both sides. If you’re authenticating with some random embedded device, you’d likely use a VPN for security.
The term “Zero Trust” is now a mainstream industry trend, for better or for worse.
The positive aspect of this is that - especially for those of us in the information security industry - there’s a name for this security philosophy, and shift toward approaching security architectures and policy models form a holistic perspective, breaking down traditional silos and barriers.
Really “Zero Trust” is about zero inherent or implicit trust. Zero Trust is about carefully building a foundation of trust (based on sound cryptographic validation), and growing that trust to ultimately permit an appropriate level of access at the right time. It could perhaps have been called “earned trust” or “adaptive trust” or “zero implicit trust,” and these would have suited the movement better, but “Zero Trust” has more sizzle, and it stuck.
The term is now very broadly used - in fact, being the core part of the May 2021 White House executive order issued by President Biden. So we need to embrace it.
However, for non-security people, I agree that the term can be off-putting or potentially insulting. I’ve seen enterprises deliberately term their Zero Trust initiatives as things such as “Modern Workplace Security”, or “Digital Transformation”. That’s fine - security leaders can and should adapt things to best suit the culture and context of their organizations.
#NoVPN or Zero Perimeter could be better slogans.
On the other hand, the only people I have seen confused are technical people that (incorrectly) think they have identified an inconsistency; non-technical folks seem fine to just map name->feature-set.