Zero Trust certainly has its benefits over the old perimeter-based model, but it also requires new, and massive, trust in third-party cloud providers. A bit more on that:
Describing "Zero Trust" as a misnomer when it's a reference to placing no inherent trust in the client seems misleading. Yes, you have to place trust in whatever makes the trust decision, whether that's you or a third party. And you also have to place trust in whoever is providing device or user identity in the first place. There are certainly techniques you can apply that mean that accessing a service only provides that service with "this user legitimately has access to this resource" rather than any information about the specific user, but someone has still had to make the determination that that user is trustworthy, and they need to have held information about that user to make that determination.
Well that's a lot to read and I should queue it up. But I think you're overselling the risk.
Zero-trust means moving the authn and authz from a perimeter around the whole ecosystem of tools for your org, down to the individual apps. Every app, every tool you were using in an old system, could still log your IP/username/login/logout times. Now, we're saying "hold up, use 2FA and better RBAC at all times" per application, instead of assuming an entity is partially trusted because of where they are on the network.
I think ZT can be implemented in or out of the cloud. It just happens that people are coupling a move toward ZT with cloud identity managers like Okta, and cloud services like AWS.
> but it also requires new, and massive, trust in third-party cloud providers
Nothing in zero trust inherently requires a 3rd party cloud provider. That is actually an implementation decision, and ZTA can be completely implemented on prem with no outsourced providers.
If your needs can be summed as 'only trust entities which you explicitly trust, while doing continuous verification and least privilege', then use something like OpenZiti or WireGuard.
To be fair, most orgs don't have those needs. Most zero trust implementations were in fact not motivated by zero trust. It was more like the VPNs were backhauling user->big_cloud_provider_hosted_app connections through bandwidth-constrained private data centers. Acceptable (or not a top priority to fix) when remote work was a fraction (for most orgs). Not acceptable for all orgs once C-19 hit. "Zero trust" from the big vendors took the connections direct (via their clouds).
You will always need to trust someone. How did you trust your hardware such as laptops and network equipment so far? So either you trust the vendor, or you're trusting a 3rd party that checks the hardware for you and give you some form of approval.
IMHO there's a huge gap between "trust this dell hardware not to contain hardware implants" vs "trust cloudflare warp to MITM every SSL connection I make"
The conflation between "Zero Trust" and "Zero Trust implemented with third-party infrastructure" is unfortunate - I think it's reasonable to feel uncomfortable with a third party being in a hyper-privileged position to effectively assert access to your infrastructure, but that's not inherent to Zero Trust and we shouldn't frame the conversation in such a way that assumes that it is.
That’s orthogonal to zero trust, however, and either way it’s still relative: if you have a policy requiring traffic inspection it’s not unreasonable to think that Cloudflare is going to be safer than some random box in the basement run by the average enterprise network team.
I actually have been working on a startup that is trying to work on reducing your reliance on trust in your infrastructure providers: we basically let you put your "perimiter" checks inside a piece of hardware that you control completely within a cloud service, and that takes the cloud provider out of the equation - and it should take us out of the equation too, since you host the instances.
My brother worked for a fund, and at some point ended up in a conversation with BoA's CTO at some industry event. CTO was shocked my brother's fund was all on prem vs using AWS. The party line from my brother's fund? "We compete with Jeff Bezos for deals so we don't trust him."
I don't really want to argue the merits of that perspective, I'm just reporting an anecdote that there's definitely customers with it.
Thank you! I hadn't been thinking about that, but it makes sense.
I certainly think that the set of people who don't trust clouds is probably bigger than it should be, but there are some cases where the "natural bug bounty" (available money to steal) is over 100x higher than the earnings of a software engineer and it's easy to cash out. I think it may be reasonable to be paranoid about your cloud provider's (and their employees') access to your systems if that is the case.
Yeah, even if you don't think cloud providers are doing scummy stuff as policy, there's always the risk of rogue employees. One of the startups I worked for had that happen with a remote office. They decided to wind down the office, gave generous severance and plenty of warning, but one of the devs felt they had nothing to lose so they snuck a trojan onto the servers that would siphon away some of the ad revenue. It wasn't very sophisticated so we found it the first morning the metrics took a dive.
Not if you use open source and self-host it yourself. For example, I work on the OpenZiti project which makes it easy to embed zero trust networking principles into (almost) anything - https://docs.openziti.io/
There's no product doing this yet but it seems likely we'll end up with cryptographic mechanisms to enforce the integrity of the security-critical processes offloaded to third parties.
With many new ideas, the early folks love the benefits and aren't put off by the challenges. With ZTNA, after doing quite a few deployments myself, I can say that the biggest challenges are operational. Nothing will piss off developers more than having had access to a resource one day, lose it unexpectedly, and then not know who to track down to get it back. Or, users hating on their VPN, want something else, and then that something else (often just another VPN provider) works differently and causes them disruptions. ZTNA is a long journey, not a quick fix.
I work in infra engineering in such a company and it indeed is so mentally draining when something that should be a few clicks on Azure take me 2 days of chasing shadows to figure out what access I need and who to ask for it and then having to prove that I really need that access level and not a weaker one.
I once worked at a company where I had to logon to the corporate VPN with an MFA token, then logon to the datacenter VPN with a second token, then logon to a VMWare Horizon virtual desktop and then RDP to a VM inside a tenant network. I needed a different AD cred for every tenant.
I dismissed it a few years ago as a harmless hype but I am now seeing real harm being caused by this hype.
To avoid writing an essay here let me keep it short and explain why: I am seeing orgs spending valuable time, money and resources on box checking and implementing false security all over. It is being used in place of improving security posture that is aware of threat context facing the organization. It has scope-creeped beyond the original intended purpose of ensuring all actions are explicitly authorized and eliminating implicit trust to mean a buch of ridiculous goals and hype words no one can explain consistently.
I caution everyone to avoid using the term but to still implement the original beyondcorp architecture.
Another cancer that is begining to spread:"passwordless".
Zerotrust makes perfect sense. It takes the default deny firewall policy and applies it to every host. Entities can only communicate after proving their identities to each other and every single packet is authenticated. When done correctly every host could be completely open to the internet without any security issues.
That's one of the ways I like to think about it. When you have zero trust, you can comfortably expose any app to the internet.
If you can't comfortably expose your app to the internet, you probably don't have zero trust.
The problem is, "exposed to the internet" is pretty much how most things are today, in a world where everything is trying to be "smart." There is a pathway to most assets and resources and that's what causes breaches. So all services and resources should be assumed as "exposed" until proven otherwise, therefore all infrastructure (and development) should apply zero trust principles.
If you already have authentication and authorization in front of every service in your internal network (unlikely), it's as easy as making everything routable from the internet.
If not (more likely) you need to start there, which will improve your security posture incrementally, even if the beyondcorp project gets cancelled along the way.
I will add that in the case of authentication before each service, it is important that it does not happen in the application itself, but before reaching it, which usually means either network centralization (e.g. Teleport) or authentication proxy (Traefik + forward auth + proxy, GCP identity-proxy, AWS Verified Access). It is also important to centralize the identity provider, of course, which in the times of SAML / OAuth is easily achievable even for small organizations.
I don't know what "zerotrust" is supposed to mean. Maybe they're stretching the meaning of zero knowledge constructions. "Zero knowledge" should mean "the service provider never keeps logs, data, metadata, or secrets in the clear that can be retrieved without user intervention, preferably not knowing anything about any particular user." MEGA is partially this.
"Passwordless" isn't terrible if it means "use a physical device or TPM-stored secret instead of a password". It shouldn't replace 2FA by having 2 actual factors.
> It shouldn't replace 2FA by having 2 actual factors.
So long as you have two factors of auth, I am fine with it.
> I don't know what "zerotrust" is supposed to mean
My point exactly. What happens in most orgs is they pick out a few apps that are really important, implement MFA, collect some logs and put an edr on the servers and voila you have zero-trust. However, the authentication and security behind the trust you are establishing itself has implicit trust and lacks many layers of defenses so you're just polishing turd and calling it zero-trust.
Now, if every freaking device and user in your trusted compute base is authenticated before traversing a security boundary then all is well -- but wait, what does that really mean? Authenticated? So if I am a member of "domain users" and "authenticated users" in AD and I can just RDP to your fancy zero-trust labeled apps, is that really zero trust? If indirect and non-explicit permission grants such as with nested or broad group/role memberships grant people permissions then is that zero trust?
You see what I mean by this? Execs want to see zero-trust so all this b.s. gets pushed down and zerotrust ends up causing an increase in risk and exposure!
From a more cynical point of view, "zero-trust" tends to mean something along the lines of: "trust a TPM on the user side... and all of my server logic and my cloud provider."
From a less cynical point of view it means "hold all the client's keys in their TPM and only authenticate on the server side, but don't decrypt (or otherwise pass keys around)"
zero trust at its core means authentication and authorization at each service, for each request. at a high level it means not trusting a connection from another service in the same network just because it’s on the same network. rooting trust to tpms is orthogonal but certainly the right way to root trust.
The space where I think zero trust is the most interesting are vpns like tailscale/wireguard/microsegmentation that flip the status quo around and say the network is the identity/authoritzed group
Wait, but I thought everyone was doing that anyway prior to the "zero trust" thing. The difference was who you trusted to hold user (and concern-specific) keys - before zero trust, it was your server, and afterward, it's the user.
Authentication and authorization for internal services is kind of basic.
> I thought everyone was doing that anyway prior to the "zero trust" thing.
Nope, lots and lots of organizations who have a zillion of internal services which they know to be insecure but are kept that way because they "are accessible only on the protected network".
> Another cancer that is begining to spread:"passwordless".
I have got to hear your problems with it! As I see it passwordless will eliminate whole families of attack methods. Lookalike credential phishing pages made obsolete. I wish we had started using it years ago.
For one thing, a password is a string of characters that you and I carry around in our heads. At least they were, until complexity requirements, forced expiration, and proliferation of accounts caused us to rely more on password managers than our memories.
However, the platonic ideal of a password is one that you remember: "Something You Know". Therefore, it is usable at the library, it is usable in the hospital after your ambulance transport, it is usable when you're stranded in Portugal and borrowing someone's phone at the U.S. Embassy in Lisbon. Passwords are not something that can just drop out of your pocket, or be "stolen" from you, in the sense of depriving you of that knowledge.
"Passwordless auth" comes to rely on devices. MFA did this to us first, of course, where SMS codes come through our phone, which is now mandatory, or come off our Yubikeys or Google Authenticator, which in turn depend on a computing device. "Passwordless auth" is always tied to a device of some kind.
Therefore, passwordless auth is something that can easily fail or be taken away from us. How easy is it to lose your phone? What are the chances you'll need to sign in to, say, Apple, to retrieve a contact's phone number, and all you have is your brain connected to your fingers? Your passwordless auth is now useless.
So yeah, it's great from a technerd perspective, where we have lots of devices, always a backup, plenty of cash to replace them, disaster plans in place, etc. Passwordless auth (and MFA along with it) isn't so attractive when you're addicted to heroin, mentally ill, homeless and living on the streets, and you're trying to sign in at a library computer so that you can apply for SNAP benefits, Medicaid, and Section 8 housing assistance.
It is inferior to multi-factor authentication. It sounds fancy but you are removing a layer of security for no reason other than it's trendy and hyped up! Good security is application of layers of defenses in a disciplined and consistent way. I should not be able to steal a yubikey or find one flaw in your passwordless credential reset method or abuse the next and greatest phishing method like in-browser vnc with webusb and that's all I need to take over an account. Let me clarify: the problem is removal of "what you know" as a layer of defense and a factor of authentication. I don't care if it is a password, passphrase, pin, puzzle, picture or whatever, without it having only one factor of authentication is remarkably inferior to MFA. And this is detrimental to 10-15+ years of security culture improvements all because vendors and clueless c-suite execs prefer to follow trends instead of listening to actual security professionals.
Passwordless authentication means removing the most critical failure factor from authentication: the human.
> I should not be able to steal a yubikey
This type of attack is not based in reality; most attacks are done remotely from a location with limited jurisdiction and practically no repercussions. When there is no credential to phish because it's a hardware-backed cryptographic assertion, security is drastically improved. WebAuthN literally provides credential phishing immunity, which is by far the most prevalent source of account compromise today (see: annual Verizon threat report). It is so superior, I would even go so far as to share my password to, say, my Google account provided it is protected exclusively with a hardware authentication factor.
> Passwordless authentication means removing the most critical failure factor from authentication: the human.
Yes it is but you are removing a layer of defense not a link in a chain. You think this is better based on a fundamentally flawed understanding of defensive security.
> This type of attack is not based in reality; most attacks are done remotely from a location with limited jurisdiction and practically no repercussions
Of course the threat landscape never changes right? And the process you have to issue new yubikeys is flawless too right? And threat actors never adapt right? WebUSB and in browser vnc can't possibly be abused? So many things can go wrong.
Look, here is the fundamental thing you people that jump on these hype trains don't understand about security: it is that after half a century, what we've learned is that it is a cat and mouse game and there are no long lasting silver bullets and even if there were, you still do security in layers because mistakes happen and you could screw up something that makes your silver bullet ineffective. So you add multiple layers of preventive and detection focused security.
You don't remove an entire layer of security and somehow twist that to sound like you improved something. It's legitimately fraudulent and harmful.
Passwords are bearer credentials and as such, they are not a meaningful layer of defense when in the custody of even a modestly competent system administrator.
As I'd said, you need to look no further than annual threat reports to see that credential theft is the most common avenue of abuse - by a lot. Hardware assertions, on the other hand, which in WebAuthN standards are also bound to domain origins, simply remove this risk entirely. Let me repeat: you cannot phish a WebAuthN assertion. Yes, you can pull off a physical attack, but at this point of the game, it is over because the adversary could just implant a bootkit, keylogger or backdoor on your valuable system.
The threat landscape certainly changes but the economics of computer fraud and abuse remains largely the same: attack the most vulnerable link in the chain for maximum profit for the least amount of cost - the human and her portable password (and other forms of exportable factors, roughly in order of security: SMS-based, HOTP/TOTP apps, email magic links, Duo-style "confirmations").
> Passwords are bearer credentials and as such, they are not a meaningful layer of defense when in the custody of even a modestly competent system administrator.
Again, you are avoiding my argument. Passwords, even pin codes have been a meaningful layer of defense for half a century. You can argue that they are weaker and propose stronger methods such as paddhphrases but you arr arguing against passwords when your real argument is against "what you know" as a factor of authentication.
> As I'd said, you need to look no further than annual threat reports to see that credential theft is the most common avenue of abuse - by a lot.
Are you a middle manager or executive by chance? Because I respond to incidents as a matter of routine and I very much know how much passwords get phished or cracked. You know what solved the problem: adding even the weakest layer of authentication like SMS. Now, there are many better altetnatives for a second factor of auth other than SMS as there are for passwords as what you know being a factor and I am open to that discussion. But what you are saying is you don't get why a weak layer of defense is needed so you want to get rid of it.
> The threat landscape certainly changes but the economics of computer fraud and abuse remains largely the same: attack the most vulnerable link in the chain for maximum profit for the least amount of cost
Again, it's not a chain. Your mindset is a flawed way of thinking carried over from physical security (think "cyber killchain), which is perimeter focused, that's where the chain analogy comes from.
Modern security, having learned from the past few decades is such that you have many layers of chains. The user's knowledge, as weak as it is, is one such layer. Removing it plain and simple is a reduction in your security posture. See, the critical thing you need to get is the relationship between layers od chains as opposed to links in a chain is complementary not symbiotic.
Persistent threat actors will get past any layer of defense. If ransoming your company gets me a few million dollars, as a criminal there is not a whole lot I wouldn't do including physical attacks (there are even untargeted campaigns where threat actors drop or mail USB drives en masse).
> the human and her portable password (and other forms of exportable factors, roughly in order of security: SMS-based, HOTP/TOTP apps, email magic links, Duo-style "confirmations").
Great, guess what that means? They spent all that time and effort to get past a password and now they face a yubikey. The difference in cost to threat actors is at least geometric. They can't just steal a yubikey or compromise your phone, now they also have to steal or guess your password.
By removing user knowledge as a factor, you are making it orders of magnitude cheaper for a threat actor. And you think that is fine because the latest and shiniest methods of authentication, unlike past solutions will never ever be defeated and you will never face insider threats or threat actors willing to spend more to profit off of you.
Stealing or guessing a password is infinitely easier than compromising a Yubikey or otherwise hardware-based authentication factor. This is a demonstrable fact and any argument to the contrary is simply pearl clutching. I challenge you to find even a single incident resulting from a compromise of this 2nd factor, until you do there's nothing to discuss. And because you don't find it, it will ultimately demonstrate passwords are not even necessary when accounts are protected in this way.
> This is a demonstrable fact and any argument to the contrary is simply pearl clutching
I agree. Lookup what a strawman argument is. No one made that claim.
> I challenge you to find even a single incident resulting from a compromise of this 2nd factor,...
Friend, do you read comments before replying to them? That is exactly my challenge to you. Passwordless usually means getting rid of 2fa and using one or more "next generation credential providers".
I'm thoroughly convinced you don't understand the U2F/WebAuthN standard, which makes intelligent discourse about the topic impossible. Good luck with your studies.
We weren't talking about those two standards alone and you haven't brought them up as examples either. All i have learned from you is you use strawman arguments.
Ok, what part of U2F requires users to remember a secret? I have seen passwordless accounts you can take over simply by controlling a yubikey. I hate it when people seem to argue with me but argue against strawmans they're inventing. I agree, discourse here can't happen.
Thanks. I learned something. Even if passwords are a weak form of security, they add an extra Ayer that would make it much more difficult for an attacker. They don’t have to be the only layer of security, and would still be good as an extra layer on top of hardware keys and/or OS keychains. Very interesting.
Yes. Also keep in mind that layers are not just preventive. There are also detection layers. You can frustrate threat actors by reacting to their attempts to get past the password or some other layer by collecting logs and alerts. A simple example would be setting up ssh on your vps with password AND public key auth and the setup fail2ban. Of course it is very hard to bypass public key auth but even if you accidentally post your private key to github or have your personal device hacked, that is still one layer of defense to slow them down.
If threat actors spend sufficient resources they will get past any security layer. There is no such thing as absolute security, good security creates the most hostile environment for threat actors by requiring them to committ the most resources without interfering with normal usability of the system.
Using a password on a WebAuthN protected account is the equivalent of putting a bathroom privacy lock on your steel front door. It's psychological coddling, nothing more.
No it is not, comparing passwords or passphrases really (what people should be using) to a bathroom privacy lock is silly. For threat actors, difficulty is not relative like that.
It's more like you have an actual normal door with alarms at a bank. Then a door to the vault area with similar alarms. Then the actual vault.
In your ideal world, everyone should be able to just walk up to the vault because it is so amazing on it's own.
Most passwordless setups require at least 2FA. Using it to login demonstrates both something you have (the authentication key on device) and something you know/something you are (PIN or biometrics used to unlock the authentication key).
Not from what I have seen. For example phone-app based auth has your phone as both what you have and the code you enter or button you press as another factor but in reality that is just one phone. I have seen a place where you can take over the org if you steal one guy's yubikey. Windows hello has a pin for what you know but then it authenticates the device with TPM instead of you separately as a user. But at least windows hello requires you to remember a pin other methods have secrets generated on the fly which I am certain are phishable or just use what you have alone as a factor of auth.
I mean, at least have users define a multi word passphrase with no complexity condition or expiry.
Isn't this basically true of every tech idea once it hits the enterprise? Agile is the usual whipping boy paraded when discussions of enterprise ruining something but it seems just true in general. As a problem I think this mostly boils down to technical decisions being made by non-technical people. Like many articles about Zero-Trust (some easy examples here in the comments) come out of the gate talking about AuthN, which is inherently about trust, they just don't seem to get it.
https://invisv.com/articles/zerotrust.html
What we need to move towards is something more like Oblivious Trust -- you rely upon third parties but they have nothing sensitive in the first place.