Unpacking the Benefits of Zero Trust Architecture as Defined by NIST

https://www.pomerium.com/blog/what-are-the-benefits-zero-trust-brings-to-organizations/

by CKMo • 3 years ago

150 70 3 years ago

barathr2• 3 years ago

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:

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.

waihtis• 3 years ago

is oblivious trust an existing concept or did you cook it up ad hoc for this reply?

barathr2• 3 years ago

It's something we wrote about in the post I linked.

mjg592• 3 years ago

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.

JamesAdir• 3 years ago

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.

michaelt• 3 years ago

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"

gz5• 3 years ago

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).

pclmulqdq5• 3 years ago

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.

zx8080• 3 years ago

Is there a significantly large market for this model? As it:

- 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

unethical_ban• 3 years ago

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.

xbar2• 3 years ago

This is correct.

Hikikomori• 3 years ago

Why would it require you to trust a cloud provider?

HyperSane3• 3 years ago

At a minimum you need to trust that THEY don't get hacked.

OrvalWintermute• 3 years ago

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.

hedgehog• 3 years ago

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.

PLG882• 3 years ago

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/

colinrand• 3 years ago

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.

CKMo3• 3 years ago

It is indeed a continuous process, like devops!

paradice• 3 years ago

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.

EGreg• 3 years ago

Anyone know Ziti?

PLG882• 3 years ago

I know OpenZiti very well (I work on the project)... whats the question?

out-of-ideas• 3 years ago

ive always correlated zero-trust with that which was recently on top of HN: https://dilbert.com/strip/2023-02-11

treat your employees like cattle; see how far that will go

panzagl• 3 years ago

I log into a Citrix client to log into a Azure Virtual Desktop so I can run a vpn to get into Confluence. It's awesome, shoot me now.

HyperSane3• 3 years ago

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.

cscheueuer2• 3 years ago

Has anyone used Pomerium and is it any good compared to Tailscale or Twingate?

Aaronstotle• 3 years ago

I'm testing Twingate out now and I've gotten lot of good back from Engineers. Curious to know as well

CKMo3• 3 years ago

https://www.pomerium.com/comparisons/tailscale-with-pomerium...

The tools do different things. Pomerium plays well with Tailscale.

badrabbit12• 3 years ago

Zerotrust is cancer.

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".

cscheueuer2• 3 years ago

What is the easiest way to implement the original beyondcorp architecture without spending multiple months building a solution in house?

jupp0r• 3 years ago

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.

eikenberry• 3 years ago

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.

tinglymintyfrsh• 3 years ago

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.

pclmulqdq5• 3 years ago

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)"

badrabbit12• 3 years ago

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!

flangola73• 3 years ago

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.

What are the downsides?

NoZebra120vClip• 3 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.

badrabbit12• 3 years ago

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.

HyperSane3• 3 years ago

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.

CKMo3• 3 years ago

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.

badrabbit12• 3 years ago

Did you read my comment? I agree with that part. That isn't what people are doing.

Unpacking the Benefits of Zero Trust Architecture as Defined by NIST

Related Stories