Hacker News Reader

Comment by barathr | Hacker News Reader

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.

View on HN

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.

This is correct.

Why would it require you to trust a cloud provider?

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

Well, I don't want any of my vendor-provided to be full of malware. But real-time hacks don't instantly put my ZTA at risk.

On premise ZTA is possible.

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

Ha, MITM SSL... My pet peeve is crowdstrike having root/admin RCE backdoor on every server/client OS. Talk about trust.

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.

How so? Do you mean because a hardware mod would be physically detectable, maybe?

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.

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

I don't know yet. There is a... weird... base of interested customers who are very paranoid and don't have good options otherwise.

Also, you don't have to trust us the way you trust a cloud, we don't have access to your running servers.

Look into hedge funds as customers.

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.

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

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

Zero knowledge as a term seems to lend itself to this concept.

Reply on news.ycombinator.com