'Zero trust’ security is a poor choice of words(code.mendhak.com)
code.mendhak.com
'Zero trust’ security is a poor choice of words
https://code.mendhak.com/zero-trust-poor-choice-of-words/
100 comments
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.
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!)
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 disagree with novpn because having a vpn or private network is a useful layer in the overall defence.
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.
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.
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.
I don’t really have an opinion on this but isn’t “seeing if it sticks” just other words for market research?
The "fuck it, do it in prod" of market research.
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.
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.
https://beyondcorp.com/
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.
https://beyondcorp.com/
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.
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.
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.
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.
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.
Turns out it is just a different phrase for the existing concept of defense in depth.
Zero trust isn't the same as defence 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.
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.
[1] https://storage.googleapis.com/pub-tools-public-publication-...
[2] Example: https://login.corp.google.com/
[3] Example of how device attestation could work: https://www.w3.org/TR/webauthn/
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.
[1] https://storage.googleapis.com/pub-tools-public-publication-...
[2] Example: https://login.corp.google.com/
[3] Example of how device attestation could work: https://www.w3.org/TR/webauthn/
>don’t trust anyone by virtue of their network location.
Sounds like an impoverished way of saying "ambient authority is bad" ;)
(I do concede the article's point that marketing actually matters.)
Sounds like an impoverished way of saying "ambient authority is bad" ;)
(I do concede the article's point that marketing actually matters.)
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...
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 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.
"No trust required"
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.
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.
Absolutely correct, and I think everyone/most here including GP know that, it's just that 'zero trust' doesn't obviously sound like that.
Paraphrasing you slightly, it's missing a word: 'zero trust [required]'.
Paraphrasing you slightly, it's missing a word: 'zero trust [required]'.
I agree. “Zero trust” is bad English. The issue is that “trust” in tech speak means something else than trust in plain language.
In plain English, to trust means you accept the person implying they had already been vetted or had been vetted by alternative means.
In tech, to trust is double speak for not doing any vetting as you punted that responsibility to a firewall or something else.
In the spirit of double speak, “zero trust” really means “nullify no vetting”.
In plain English, to trust means you accept the person implying they had already been vetted or had been vetted by alternative means.
In tech, to trust is double speak for not doing any vetting as you punted that responsibility to a firewall or something else.
In the spirit of double speak, “zero trust” really means “nullify no vetting”.
> I don't have a good alternative to it, but maybe something like
I thought "trust" was working out just fine...
What happened? When did we lose the ability to trust?
Maybe it would be easier to try to find new way to build trust? Rather than replacing it altogether?
I thought "trust" was working out just fine...
What happened? When did we lose the ability to trust?
Maybe it would be easier to try to find new way to build trust? Rather than replacing it altogether?
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.
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.
This really isn't the right story for diving into this line of discussion.
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.
Because the terms will inevitably communicate to the users one way of the other.
It confuses even engineers who don't focus on security.
It confuses even engineers who don't focus on security.
'Zero Trust' is not for end users.
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.
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.
That is not the idea currently being pushed.
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.
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.
Data point: Parents definition of zero-trust largely matched mine and doesn’t seem particularly incompatible with yours.
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.
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.
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.
Maybe ‘networkless’ would be a better word…
(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.
Maybe ‘networkless’ would be a better word…
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.
Right. From an end user perspective, zero trust manifests as ‘single sign-on’. Which is easy enough to grasp.
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.
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.
This is a really odd description of zero trust.
For end users, zero trust looks like ‘not needing to check the VPN icon is green before you launch the payroll app’.
The concept of ‘being on the network’ goes away. Which is good, because that was a major source of confusion for end users.
For end users, zero trust looks like ‘not needing to check the VPN icon is green before you launch the payroll app’.
The concept of ‘being on the network’ goes away. Which is good, because that was a major source of confusion for end users.
I love how the industry takes a word like "devops" and redefines it until meaningless. I think that has happened to Zero Trust as well.
But.. your description doesn’t match up with what I think the original definition of zero trust means?
You said it was about preventing unknown services turning up on a network, which almost feels like the opposite of zero trust to me.
Zero trust is about not caring if unknown services are on your network, because merely ‘being on the network’ doesn’t grant you access or trust.
You said it was about preventing unknown services turning up on a network, which almost feels like the opposite of zero trust to me.
Zero trust is about not caring if unknown services are on your network, because merely ‘being on the network’ doesn’t grant you access or trust.
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.
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.
[0] https://www.forcepoint.com/cyber-edu/defense-depth
[0] https://www.forcepoint.com/cyber-edu/defense-depth
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.
.... wish I could tell you 'no'.
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'.
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 also like the term "Onion Approach to Security"
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.
Well if you say what zero trust really is ...
- 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..."
- 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..."
This is probably one of the best descriptions.
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.
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.
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 ...)
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.
more like - 'zero trust' in the sense you cannot trust it
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.
"Serverless Computing", "Agentless", and "Immutable Infrastructure" are all badly named.
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.
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.
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.
Bad product name anecdote...
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.
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 author give implementation details names which are also not good naming as not reflecting the global idea.
I think "Boundaryless Security" is decent.
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.
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.
This. Zero is for device/network but still there are other trusts.
'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.
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.
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".
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.
But it's not mTLS? ;)
Trust and you'll be trusted said the liar to the fool.
The buzz around it is a bit annoying but the concept certainly is great.
Never trust by default, always verify.
Never trust by default, always verify.
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.
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.
So, (precisely speaking) it is increasing the set of network endpoints that are trusted from a LAN to the entire internet.
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.
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.
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.
[1]: https://research.google/pubs/pub45728/
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.
[1]: https://research.google/pubs/pub45728/
The opposite: increasing the set of network endpoints that are untrusted from the internet to both the internet and the LAN.
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".
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.
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.
VPNs aren't necessarily "done away with" in the ZT model, in fact in many circumstances they would still be encouraged.
I’d rather be told that it is zero trust security than another fancy name that everyone knows it is bullshit
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.
(If you’re interested in more, see my book and website on this subject at https://zerotrustsecurity.guide/ )
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.
(If you’re interested in more, see my book and website on this subject at https://zerotrustsecurity.guide/ )
If I didn’t have Zero Trust, I wouldn’t have no trust at all.
“Always Active Security”
AI(Artificial Intelligence) is real poor choice of words, because of there is no intelligence at all, just math..
Which is why it's called artificial
[deleted]
#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.