6 ms·

But a simple gateway/ELB can protect your apps from the public internet. (But unless you’re pushing a root CA cert to all client devices then those apps aren’t

But a simple gateway/ELB can protect your apps from the public internet. (But unless you’re pushing a root CA cert to all client devices then those apps aren’t “dark” in any sense due to CT logs). Zscalar’s ZPA docs say: > [ZPA] mitigates lateral threat movement through advanced segmentation https://www.zscaler.com/products/zscaler-private-access https://www.zscaler.com/products/zscaler-private-access So it must be doing some segmentation at the network level, otherwise what does that statement mean?

PLG88 2y ago
The gateway/ELB has inbound ports and 'listens' on the WAN interface for incoming connections. Therefore it can be subject to external network attacks, and be compromised if a CVE etc exists. Zscaler Private Access makes outbound connections so that you can deny all inbound connections and not be subject to external network attacks. It also creates application-specific connections, rather than a full tunnel so that each connection is inherently microsegemented and inaccessible to anything outside of that tunnel. We do the same thing on the open source project I work on, OpenZiti (https://github.com/openziti https://github.com/openziti), though our platform is more like ZPA on steroids.
- nmadden 2y ago
  The Zscaler exchange also listens to incoming connections, as does the OpenZiti edge router. How is this different? I’ve just swapped one vendor’s edge appliance (eg AWS ELB) for another. A CVE in either has the same impact, no? Application specific connections are great and everything. But if a web app has a log4shell-like vulnerability then that app-specific connection means nothing if the app isn’t also isolated at the network level to prevent lateral movement. PS - denying incoming connections doesn’t eliminate all network attacks by any means.
  - PLG88 2y ago
    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-listening-ports-activity-7226908250510606337-RQZe 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.
    - PLG88 2y ago
      p.s., app embedded makes network attacks almost impossible as you no longer have a listening port on the underlay network, well described here - https://blog.openziti.io/go-is-amazing-for-zero-trust https://blog.openziti.io/go-is-amazing-for-zero-trust

PLG88 2y ago

The gateway/ELB has inbound ports and 'listens' on the WAN interface for incoming connections. Therefore it can be subject to external network attacks, and be compromised if a CVE etc exists. Zscaler Private Access makes outbound connections so that you can deny all inbound connections and not be subject to external network attacks. It also creates application-specific connections, rather than a full tunnel so that each connection is inherently microsegemented and inaccessible to anything outside of that tunnel. We do the same thing on the open source project I work on, OpenZiti (https://github.com/openziti https://github.com/openziti), though our platform is more like ZPA on steroids.

nmadden 2y ago
The Zscaler exchange also listens to incoming connections, as does the OpenZiti edge router. How is this different? I’ve just swapped one vendor’s edge appliance (eg AWS ELB) for another. A CVE in either has the same impact, no? Application specific connections are great and everything. But if a web app has a log4shell-like vulnerability then that app-specific connection means nothing if the app isn’t also isolated at the network level to prevent lateral movement. PS - denying incoming connections doesn’t eliminate all network attacks by any means.
- PLG88 2y ago
  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-listening-ports-activity-7226908250510606337-RQZe 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.
  - PLG88 2y ago
    p.s., app embedded makes network attacks almost impossible as you no longer have a listening port on the underlay network, well described here - https://blog.openziti.io/go-is-amazing-for-zero-trust https://blog.openziti.io/go-is-amazing-for-zero-trust