6 ms·

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 mor

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

Hikikomori 4y ago
Why would it require you to trust a cloud provider?
- deleted 4y ago
  [deleted]
- HyperSane 4y ago
  At a minimum you need to trust that THEY don't get hacked.
  - xbar 4y ago
    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.
JamesAdir 4y 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 4y 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"
  - mjg59 4y ago
    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.
  - remram 4y ago
    How so? Do you mean because a hardware mod would be physically detectable, maybe?
  - attentive 4y ago
    Ha, MITM SSL... My pet peeve is crowdstrike having root/admin RCE backdoor on every server/client OS. Talk about trust.
    - deleted 4y ago
      [deleted]
  - acdha 4y ago
    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.
gz5 4y 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).
pclmulqdq 4y 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 4y 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
  - pclmulqdq 4y ago
    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.
    - jasonwatkinspdx 4y ago
      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.
      - pclmulqdq 4y ago
        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.
unethical_ban 4y 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.
- xbar 4y ago
  This is correct.
- deleted 4y ago
  [deleted]
OrvalWintermute 4y 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 4y 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.
PLG88 4y 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/ https://docs.openziti.io/
waihtis 4y ago
is oblivious trust an existing concept or did you cook it up ad hoc for this reply?
- barathr 4y ago
  It's something we wrote about in the post I linked.
  - mc32 4y ago
    Zero knowledge as a term seems to lend itself to this concept.
mjg59 4y 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.

Hikikomori 4y ago

Why would it require you to trust a cloud provider?

deleted 4y ago
[deleted]
HyperSane 4y ago
At a minimum you need to trust that THEY don't get hacked.
- xbar 4y ago
  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.

JamesAdir 4y 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 4y 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"
- mjg59 4y ago
  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.
- remram 4y ago
  How so? Do you mean because a hardware mod would be physically detectable, maybe?
- attentive 4y ago
  Ha, MITM SSL... My pet peeve is crowdstrike having root/admin RCE backdoor on every server/client OS. Talk about trust.
  - deleted 4y ago
    [deleted]
- acdha 4y ago
  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.

gz5 4y 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).

pclmulqdq 4y 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 4y 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
- pclmulqdq 4y ago
  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.
  - jasonwatkinspdx 4y ago
    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.
    - pclmulqdq 4y ago
      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.

unethical_ban 4y 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.

xbar 4y ago
This is correct.
deleted 4y ago
[deleted]

OrvalWintermute 4y 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 4y 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.

PLG88 4y 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/ https://docs.openziti.io/

waihtis 4y ago

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

barathr 4y ago
It's something we wrote about in the post I linked.
- mc32 4y ago
  Zero knowledge as a term seems to lend itself to this concept.

mjg59 4y 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.