3 ms·

Sure, zero trust implies those things, but I was asking specifically about these kinds of all-in-one “zero trust appliances”. For me, as an AppSec specialist, I

Sure, zero trust implies those things, but I was asking specifically about these kinds of all-in-one “zero trust appliances”. For me, as an AppSec specialist, I’d say ZT is primarily about making sure all your apps enforce authN/Z regardless of whether the users are on an internal network or not. One way to do that is to stick a simple reverse proxy in front of every app that does OIDC to your central IdP, and then arrange your network so that you cannot bypass that (eg using (micro)segmentation or something like IAP’s signed headers). My impression from reading Zscaler’s docs was that it was really just an over-complicated version of this without even doing the segmentation for you, but it sounds like it does do that bit too.

PLG88 2y ago
The idea of “zero trust appliances” is that you can reduce the attack surface from the external network, that is how Zscaler positions it, to make you apps 'dark'. IMHO though, the logical conclusion is to give every application, as part of the software development lifecycle its own private network, which implements zero trust principles - least privilege, microsegmentation, default deny, strong identity, device authentication, and more. The beauty of this approach is that you eliminate a whole class of vulnerabilities (see 'secure by default from CISA), that is, network/IP attacks, without changing the users experience (they just access the app). Another key aspect is that this approach should be applied to every use case, not just client to server. All of this is possible on the open source project I work on, OpenZiti - https://openziti.io/ https://openziti.io/.
- nmadden 2y ago
  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

The idea of “zero trust appliances” is that you can reduce the attack surface from the external network, that is how Zscaler positions it, to make you apps 'dark'. IMHO though, the logical conclusion is to give every application, as part of the software development lifecycle its own private network, which implements zero trust principles - least privilege, microsegmentation, default deny, strong identity, device authentication, and more. The beauty of this approach is that you eliminate a whole class of vulnerabilities (see 'secure by default from CISA), that is, network/IP attacks, without changing the users experience (they just access the app). Another key aspect is that this approach should be applied to every use case, not just client to server. All of this is possible on the open source project I work on, OpenZiti - https://openziti.io/ https://openziti.io/.

nmadden 2y ago
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.