I cannot speak for Zscaler in this scenario, but I can explain why its different and reduced risk for OpenZiti/NetFoundry (I literally posted on this topic yesterday on LN, blog post coming soon -
https://www.linkedin.com/posts/philipleonardgriffiths_no-lis...)
First things first. Yes. If a vulnerability exists in the overlay network that would allow an attacker to bypass the security of the zero trust network, but what does that mean in practice? Well, to do this they would need to:
- (1) need to bypass the mTLS requirement necessary to connect to the data plane (note, each hope is uses its own mTLS with its own, separate key).
- (2) have a strong identity that authorizes them to connect to the remote service in question (or bypass the authentication layer the controller provides through exploits; note again, each app uses separate and distinct E2EE, routing, and keys)
- (3) know what the remote service name is, allowing the data to target the correct service (not easy as OpenZiti has its own private DNS that does not need to comply to TLDs)
- (4) bypass whatever "application layer" security is also applied at the service (ssh, https, oauth, whatever)
- (5) know how to negotiate the end to end encrypted tunnel to the 'far' identity
So yes, if they can do all that, then they'd definitely be able to attack that remote service.
But wait, I said "remote service", not "remote services". Thats right, all that work and compromises and they only have access to 1 single service among hundreds, thousands, or potentially millions of services. Lateral movement is almost mpossible. So the attacker would have to repeat each of the 5 steps for every service.
Finally, how would they know which company sits behind which OpenZiti fabric. Thats right, they don't. So its pot luck if its even against the target they want to try and exploit.