Unpacking the Benefits of Zero Trust Architecture as Defined by NIST
pomerium.com
pomerium.com
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.
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).
- involves a completely different approach to devops/sre
- adds lots of pressure on reliability as relues on a some non-widespread hardware device
- vendor lock, obviously, so not any better comparing to the cloud providers
Also, you don't have to trust us the way you trust a cloud, we don't have access to your running servers.
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.
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.
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.
On premise ZTA is possible.
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.
The tools do different things. Pomerium plays well with Tailscale.
treat your employees like cattle; see how far that will go
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".
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.
"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.
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)"
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
Authentication and authorization for internal services is kind of basic.
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".
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!
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.
What are the downsides?
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.
> 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.
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.
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").
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.
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".
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.
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.
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.
I mean, at least have users define a multi word passphrase with no complexity condition or expiry.
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.