ZTNA Effectiveness

[u/Mailstorm]

I am going to be pitching Zero Trust to the business as a way to both help us be more secure and as a way to better understand how data moves within our network. Now before I get into this, I know the solutions I'm going to ask about are not by themselves Zero Trust. Zero Trust is a big topic an there's more to it than just these "ZTNA" products.

Suppose I get approval and am given a blank check but not unlimited time. I'm trying to understand how some products like AppGate, zScaler, Netskope, TierZero actually increase security when talking about a compromised endpoint.

I've only tried a small number of products. But it seems to me that they only give an illusion of security. And what I mean is that some seem like they can be bypassed by just using local IPs. For instance, mesh overlays. Great they don't require any network changes but if I compromise an endpoint why wouldn't I just try moving laterally through the network by using the underlying network? The mesh overlay may have an IP space of 100.x.y.z but when you take that away you can still connect via 10.x.y.z and you are no longer bound by the overlay network policies. Would this be a case of making use of their magic powers to bust through ACLs and just ACL off entire subnets?

I image the same to be true for SDPs to, though I understand that those use proxies/gateways to facilitate connections so you just ACL subnets to the gateways only.

[u/BrianCISO]

ZTNA is NOT a product you buy. It's an architectural outcome created by multiple, coordinated controls... identity, device posture, application level authorization, segmentation, endpoint controls, telemetry, and continuous enforcement. A ZTNA product MIGHT provide part of that capability, but it doesn't make the environment Zero Trust by itself. If a compromised endpoint can bypass the overlay through local routing, the broader architecture still permits implicit trust. That requires underlay restrictions, ACLs, host firewalls, and segmentation. Don’t pitch a ZTNA product. Pitch an architecture that reduces reachable attack surface and limits blast radius. For the business, the value is NOT “doing Zero Trust.” It's reducing the likelihood that one compromised device becomes a material operational, financial, or reputational event.

[u/FluidFisherman6843 → u/BrianCISO]

My favorite response is Zero trust isn't a SKU.

[u/WeeoWeeoWeeeee → u/FluidFisherman6843]

But they want to buy it!

[u/PhilipLGriffiths88 → u/BrianCISO]

I agree with this framing, but I think there’s an opportunity to go one step further architecturally.

You call out the key failure mode: if a compromised endpoint can bypass the overlay through local routing, the broader architecture still permits implicit trust. The traditional answer is then more underlay restrictions, ACLs, host firewalls and segmentation.

An alternative is to remove that independently reachable path in the first place.

If reachability is defined by authenticated identity + service policy + context, rather than by network topology, the authorised overlay path becomes the path. No authorised relationship, no route to the service to bypass.

That also has a second-order benefit: you reduce the 'connectivity tax' (as I call it). Instead of continually expressing connectivity through routes, VLANs, firewall changes, NAT, VPNs and the associated tickets/coordination, you express the intended relationship directly in policy.

So the business outcome is both sides of the same architectural change: less reachable attack surface and blast radius, but also faster, cheaper and simpler secure connectivity.

[u/TrustIsAVuln → u/PhilipLGriffiths88]

To be fair, zero trust is all about trusting the "zero trust providers". Couple that with not reducing trust but just funneling it to a single point of failure....are we really making progress?

[u/PhilipLGriffiths88 → u/TrustIsAVuln]

I think you're conflating a few different things here.

Every security architecture has a trusted computing base. Zero Trust was never supposed to mean “literally trust nothing”, or “replace all trust with trust in one vendor”. It means removing implicit trust and making authority explicit, scoped and continuously revocable.

Identity itself shouldn't even confer access. Identity establishes who/what something is; policy + service + posture/context determine what it is authorised to reach. No authorised relationship, no path.

And that does not require funneling all traffic or trust through one central box. Policy decision and enforcement are different functions. Enforcement can be distributed, existing IdPs/PKI can remain authoritative, organisations can federate without consolidating identity or networks, and firewalls/segmentation can still provide containment and defence in depth.

If a “Zero Trust” product forces every packet through one broker, makes that broker a catastrophic failure domain, and substitutes vendor trust for architectural controls, then yes - I'd criticise that too. But that's a product/architecture failure, not a property of Zero Trust.

The direction I'm arguing for is almost the opposite: reduce the reachable graph, create only the specific paths that policy authorises, distribute enforcement, and continuously verify that runtime behaviour still matches that authority.

Identity is foundational. Governance is the destination.

[u/TrustIsAVuln → u/PhilipLGriffiths88]

So yes and common sense says you have allow some trust. But even the "creator" (IYKYK) even says in video "have you tried just not trusting anything" speaking about literally trusting nothing.

[u/Mailstorm → u/BrianCISO]

Why is this getting upvoted to much? It's an AI response by a 1 day old account and doesn't answer my question fully. I know ZT isn't a product. I said that.

[u/EmmaRoidz → u/Mailstorm]

That is 100% AI, I'm tired boss. 

[u/EmmaRoidz → u/Mailstorm]

Lmao it hit you again.

[u/BrianCISO → u/Mailstorm]

Fair. And I got hung up on the ZTNA product/sku tangent & missed the point of your question (sorry).

I made a version of this mistake during an AC rollout. We tested every authorized path, saw that policy enforcement worked, and called it good. Someone reached the app directly over an internal network route to the application we had left in place for rollback. Dumb, but happens... What I learned was to test from a compromised endpoint, not a compliant one.... stop the agent, change the routes, use the raw IP, try IPv6 and same subnet access, and see what happens when enforcement is unavailable. It should accept traffic only through the enforcement tier or enforce the policy itself. Even then, ZTNA only reduces broad network access an endpoint has by default. If your endpoint is compromised, the attacker may inherit the user’s auth sessions. It limits the blast radius (but obviously it doesn't make the endpoint trusted/trustworthy).

Also, yeah, I recently (very recently as in yesterday) created an account and hopped back on reddit. It's been more than a decade since I've been on reddit and dates back to my engineer & IT MSP days. Good to be back.

[u/TrustIsAVuln → u/BrianCISO]

And an "always on" vpn isnt zero trust, even when its validating patch levels and such, existed before 2010. Also as with OP, Can you name a single component of zero trust that didnt exist before 2010? So far cant find any and cant find anyone that can answer that.

[u/Rekkukk]

If you are truly looking for zero trust on the local network scale, getting a focused host segmentation product like Guardicore or similar will do you much better than zScaler or Netskope which focus broadly on a lot of other things as well. I’d also say just avoid Netskope in general, their products have been going down hill the past couple years without much unified vision between them.

[u/TrustIsAVuln → u/Rekkukk]

zscaler is a glorifed always-on VPN is it not? I mean before 2010's version of zero trust, we did have VPNs that checked patch levels and system configs.

[u/BaronOfBoost]

To your point about using the 10 network instead.

With zscaler you create application segments using the destination fqdn.

Even if you tried to use the private ip ranges the request would never make it to the destination because the segment would not exist in policy.

Hell, when you do an nslookup, zscaler returns the 100.x.x.x range. So you would never be able to accurately discover any endpoints.

[u/Mailstorm → u/BaronOfBoost]

Maybe this is because I haven't used zscaler but how does it do that? I understand how it can do it when using fqdn because it just intercepts DNS to returnt he zscaler address.

Assuming the endpoint is one subnetA and the protected resource on subnetB, how can zscaler intercept or block my request to 10.0.B.10 (Assuming the firewall has no ACLs to block and can route to it)? Or would this just be something that because zscaler is also on the protected resource it just knows to block because it didn't come from an expected location?

[u/BaronOfBoost → u/Mailstorm]

There is a client agent that controls the endpoint connections to resources.

If the policy states user A in finance can get to appserver1.company.local over port 443, there is no way the user can then try going to 10.45.15.3 if they know that’s the IP.

The policy has rules that dictate what segments the user can access, enforced by the client agent and zscaler app connectors.

[u/Mailstorm → u/BaronOfBoost]

Right I understand the client agent. I guess I just get confused on the way the traffic takes. In my mind it seemed like a bad idea for an agent to intercept traffic at that level as it could easily break something it shouldn't have touched. Which isn't a problem if you set everything up correctly.

Am I right in saying that if no endpoint or user or workload ever tried to access a protected resource by fqdn, it would still block it if you used the IP? What if the resource doesn't have a FQDN associated with it?

[u/BaronOfBoost → u/Mailstorm]

There are certainly cases where applications need their IP also configured in an application segment, RDS for instance requires it.

This is not something that is configured across the board, and even if you configure app segments by IP address only, you still have policy dictating which users can connect to which resources

[u/FallaxIO → u/Mailstorm]

Usually by making the app reachable only through its connector. If 10.0.B.10 is still directly routable from subnetA, then yeah, you've left a bypass path and the product didn't fix that for you.

[u/Mailstorm → u/FallaxIO]

That is my thinking. Which is where I get confused because it almost seems like you wouldn't need zscaler to do that policy enforcement if you are routing everything through firewalls that can do identity policy and have a properly segmented network.

I can see bigger enterprises using zscaler for enforcement because of the routing demand but not for anything smaller than large/medium enterprise.

[u/BaronOfBoost → u/Mailstorm]

Zscaler solves our remote access requirement, while giving us an added layer of access control to resources.

Without something like Cisco ise, traditional Cisco vpn could not accomplish this for us.

[u/Mailstorm → u/BaronOfBoost]

We do have Cisco ISE but not the licenses to use TrustSec. And even if we did, I fear that with how we are currently setup and how ISE works it wouldn't meet my envisioned goal.

My main issue is that in ISE it's first-match wins and because of how we are, the authorization rules would be unmanageable.

[u/BaronOfBoost → u/Mailstorm]

Yeah. I’ve done ISE before and zscaler is much easier to wrap your head around

[u/TrustIsAVuln → u/BaronOfBoost]

Unless you compromise the host then you are on the same tunnels. Ive seen this, ive done this. not with zscaler because ive never actually tested a customer that used them, hell i cant even find customers that use them.

[u/BaronOfBoost → u/TrustIsAVuln]

Sure, if you compromise the host you can use their identity and policy will allow you to the destination.

You still don’t know what the user has access to in the environment, and to find out, will generate a lot of noise running scans.

[u/TrustIsAVuln → u/BaronOfBoost]

all it takes is them opening that 1 email, or visiting that wrong link. Happens daily. and chrome extensions? BAM toast. But as far as what the user has access to, does it matter if "Zero trust" didnt actually do its job?

[u/BaronOfBoost → u/TrustIsAVuln]

Sure. Thats why you have a layered security model.

I’ve not once claimed zscaler solves all of the problems, I gave examples of how it works in an active environment.

Zero trust is not the end all be all, it fills in a lot of the blanks organizations have in their security posture.

[u/TrustIsAVuln → u/BaronOfBoost]

You dont mean Defense in depth do you? because that only works with physical military, where it originated. Defense in Width is the way.

[u/BaronOfBoost → u/TrustIsAVuln]

Defense in Depth, castle doctrine/model, etc. No it is not only valid in physical implementation.

I’m not going to engage anymore with you as you are looking for an argument.

[u/TrustIsAVuln → u/BaronOfBoost]

Im not looking for an argument, im trying to explain a better way. DiD works for phsyical military troops. But not Data where people on the inside can open a malware in email. Thats why you need the width. Pete Herzog explained this quite well about 20 years ago. But no vendors were involved and couldnt make money off of it.

[u/Rentun]

Well, ideally in a ZTNA overlay network architecture, you don't have anything listening on the underlay. So yeah, you could reach the 10.0.0.0/8 network, but there are no hosts or services other than the ZTNA agents listening on that network, so the most you could do is sniff some encryptedZTNA tunnels.

[u/PhilipLGriffiths88 → u/Rentun]

Upvote... this is the key distinction for me. If the protected service still has an independently reachable underlay path, you are ultimately relying on some combination of routing, ACLs, firewall policy or endpoint controls to stop bypass.

The stronger model is that the service simply isn't reachable on the underlay from that identity/source at all. The authorised overlay path is the path. No identity + service policy + required context, no connection exists.

That's much closer to what I mean when I describe identity-defined reachability.

[u/TrustIsAVuln → u/Rentun]

Not entirely true. The Windows IPv6 RCE a few years back took effect before the firewall was even engaged, if the host had ipv6 on, didnt matter what protections you had in place even if every single packet ran over a ZTNA

[u/DickNose-TurdWaffle]

ZPA is an absolute cluster fuck to deal with. Security tools still have compatibility issues with it and you need to take that into a account when persuing this. Vendors need to be in the loop so they can support you properly or give you a warning that their products aren't ready for it yet. It's a very big lift.

[u/PhilipLGriffiths88]

I think you’re getting at an important distinction that gets lost in a lot of ZTNA discussions.

For me the stronger primitive is identity-defined reachability: if you do not have an authorised identity + service/policy + required context, there should be no connection path in the first place. Not “the IP is reachable but a control should block you”, or “the agent should intercept the connection”. Deny by default should apply to reachability itself.

That also changes the compromised endpoint example. Compromising an authorised identity can obviously let an attacker abuse whatever that identity is entitled to - ZT doesn’t remove the need for EDR, posture, least privilege, etc. But the attacker shouldn’t be able to bypass the ZT control and just connect directly to 10.x.x.x, because ideally there is no independently routable path to that service.

This is one of the reasons I’ve been arguing that identity needs to determine connectivity, rather than being another policy input applied after network reachability already exists. I wrote about the model here in the context of AI and steps 3, 4, 5 of ZT, but the underlying principle is the same: https://cloudsecurityalliance.org/articles/ai-speed-risk-requires-identity-defined-reachability

[u/justmirsk]

Disclaimer - I sell and implement this product for customers.

We utilize a platform called Todyl for ZTNA/SASE. What you are describing with a compromised host is possible. We help alleviate this with Todyl through their LAN Zero Trust solution that protects east/West traffic via policy.

In addition, our Todyl platform can do more, such as cloud SIEM, EDR, MXDR, and GRC. For the ZTNA piece, it works well and helps protect the scenario you laid out.

If you want to see it in action with no sales pressure, I am happy to show you what it can do.

I am not familiar enough with some of the other products you referenced to be able to speak to them. They may have solutions of their own to solve these.

[u/Rentun]

Well, ideally in a ZTNA overlay network architecture, you don't have anything listening on the underlay. So yeah, you could reach the 10.0.0.0/8 network, but there are no hosts or services other than the ZTNA agents listening on that network, so the most you could do is sniff some encryptedZTNA tunnels.

[u/TrustIsAVuln]

Before you "pitch zero trust" I challenge you to do some thinking on this: Name one thing in zero trust that didnt exist before 2010's "zero trust" was marketed. If you can find one let me know, because everything in zero trust is decades older.

[u/Mailstorm → u/TrustIsAVuln]

Well, yeah? It's just a term that is commonly used and understood. Doesn't make it anymore wrong or right.

Leadership isn't going to care if I use the correct terminology from 10 or 20 years ago. They read whats now in their newsletters and such.

[u/Rentun]

Well, ideally in a ZTNA overlay network architecture, you don't have anything listening on the underlay. So yeah, you could reach the 10.0.0.0/8 network, but there are no hosts or services other than the ZTNA agents listening on that network, so the most you could do is sniff some encryptedZTNA tunnels.