I am not sure I agree with “You can implement a ZTNA strategy with the right VPN/remote access solution”… it depends. Many solutions purport to deliver zero trust, but if they use network identifiers, inbound ports, connect and then authenticate, you are placing a lot of trust in the network which we are meant to treat as compromised and hostile. Table stakes IMHO is using a ZTNA solution which implement strong identity, authenticate-before-connect, outbound only connections, microsegemtation and least privilege (without ACLs which do not scale well).
Tell them to do better. They are all willing to play ball.
What about software and apps that connect directly via IP Address, instead of host name? Do those just not work on this ZTNA product? For example if you just open putty and plug in an IP and hit connect, will that traffic escape the tunnel since no FQDN lookup is performed?
FYI - Prisma Access also has the ‘ZTNA connector’ which can be used in place of traditional IPSEC tunnels for on prem apps, if you want to use the reverse proxy style of access for the reasons you mention.
What exactly does that mean in a practical sense?
Their platform is cloud-native. Architecture is inline proxy-based. They are SDP, but inline proxy based. They are full mesh overlay, but this applies to both the endpoint agent and the edge SDWAN services. They are fully identity aware with a single shared identity context for all services.
They are a full cloud network security and app security solution that delivers a converged cloud network onramp in the form of SDWAN for the branch and data center (physical or cloud) as well as an agent for the mobile endpoint.
You guys/gals really should take a closer look. It’s seriously like having one “Eureka!” moment after another.
My “with the right solution” = your “depends”. Again, ZTNA is a framework to follow when implementing products or solutions. If you’re VPN/Remote Access solution allows you to adhere to the ZTNA framework…then you have the “right solution”. Also, you can have “network identifiers” and still completely control access. Not sure why companies like Netskope and Zscaler put so much stock into IP obfuscation. The outcome isn’t any different if you’re remote users are on a dedicated IP pool and have to pass through inspection and control layers before access is granted to a resource. Note, with ZTNA from Netskope and Zscaler they actually trust the traffic once endpoint, user and app are permitted. That’s not ZeroTrust to me. I still want that permitted user, endpoint, application traffic inspected by ATP engines. That’s a miss on their part and security risk to the customer. All their work to remove network identifiers from the equation is immediately devalued by them not actually inspecting the traffic.
Depending on the vendor, there are ways to manually configure IP addresses to be sent back on-prem. But correct, by default that traffic will just follow the default route to the vendor cloud and going nowhere from there in case of private IPs. So the result is that network scans or malware won’t find anything at all. It’s a compelling argument. However there are drawbacks… for example these virtual connector appliances do very limited NGFW stuff if any at all. So you basically fall back to L4 policies for private traffic.
Right, we looked at that but it has some limitations. When we kept pressing for roadmap or features, the answer was always “but why wouldn’t you just use a VPN (service connection)”. Also the pricing/licensing is not in favor of the ZTNA connector.
You can have one without the other. The reason I don’t like network identifiers is that they are weaker and spoofable. Cryptographic identity is much stronger. Personally, I don’t like how Zscaler/Netskope implement with external IdP and needing to trust them (TLS only from device to their DC to do identity check). I prefer the ZTNA solution to have its own PKI so that you can do mTLS and E2EE everywhere, with strong identity on an authenticate before connectivity basis.
This has an added advantage of routing traffic across the overlay according to the systems embedded identity, rather than IP. IP is only used for ingress/egress to non-ZTNA endpoints. This gives the system a private DNS which does not need to comply to top level domains. This all together means we can use the ZTNA solution to support any use case (incl. M2M, E-W etc) while removing IP constraints, NAT issues etc.
If you stop external network attacks then the need for inspection is many times lower - not to mention how IPS/IDS is becoming harder with app E2EE, HTTP3 etc. You can still do packet filtering, just put the IPS/IDS inline at point of egress from the ZTNA overlay and before the application.
This does not even tough on doing app-embedded ZTNA. If you can get to that level, then the application no longer has any ports on the underlay WAN, LAN, or host OS network and thus its unattackable via conventional IP-based tooling & all conventional network threats are immediately useless.
What were the limitations that held you back, out of curiosity? We have Prisma Access but are yet to venture to using their ZTNA connector.
“If you stop external network attacks then the need for inspection is many times lower”
But we’re not supposed to be thinking in terms of “if”. It’s a matter of “when” and there is no complete solution that will stop ALL external network attacks, which means the enterprise would have lateral exposure still. To your point, defense in depth is critical. The challenge is keeping it all simple and manageable. If you have to buy one solution to roll out part of your ZTNA strategy, another solution to managed legacy IP-based use cases and another solution to provide advanced threat inspection…that starts to sound a lot like more of the same. More point solutions. More complexity and increased risk.
You run into issues with any application that requires the actual client IP. Admitted this is mostly for legacy stuff (on-prem AD, Kerberos, …). Zscaler seemed to have possible workarounds to make these things work.
They have a basic overview of the exceptions that don’t work on ZTNA connector in this doc: ZTNA Connector Requirements and Guidelines (paloaltonetworks.com)
For private apps you can pretty much stop all external network attacks if you do application embedded ZTNA. Sure, you could try to attack the overlay network BUT that would require:
- bypassing the mTLS requirement necessary to connect to the data plane (all parts of the overlay are exclusively mTLS)
- having an strong identity that authorizes them to connect to the remote service in question (or bypass the authentication layer the controller provides through exploits)
- knowing what the remote service name is, allowing the data to target the correct service (not easy considering you have a private DNS which does not need to comply to Top Level Domains)
- bypass whatever “application layer” security is also applied at the service (ssh, https, oauth, whatever)
- know how to negotiate the end to end encrypted tunnel to the ‘far’ identity
That doesn’t even include that a hacker would not necessarily know which overlay they are trying to attack and thus whether its ‘worth it’ or what they can pivot from afterwards.
Also, the better ZTNA solutions support legacy IP-based use cases - as was discussed in the other reddit thread I referenced above. The only thing the ZTNA solution I have in mind is it doesn’t do advanced threat protection, it does everything else though.
ATP is kind of important though, right?
IMO, a pretty complete solution will allow the enterprise to implement a ZTNA strategy, support all sorts of predicates (IP, Endpoint Context, User Identity, Application, etc.) and also provide inline ATP. Bonus points if the solution is simple to use and fully maintained by the supplier.
I admit I don’t know a ton about “app embedded ZTNA”, so can’t really commit on that part.
But, if you’re looking for the coverage I just outlined, I can think of at least one supplier that checks all the boxes.
Then its probably not the one I am thinking of, curious which yours is. Mine is OpenZiti (OpenZiti · GitHub; or its commercial derivative, NetFoundry) which is open source, supports any use case (N-S, E-W, broad macro intercepts, microsgemented, static or dynamic ports, IP, DNS, etc), has embedded system of identity (PKI/CA) with ability to work with any external IdP as primary or secondary AuthN/AuthZ, provides endpoints context through posture checks, deploys as virtual appliance, app on host, app embedded, clientless, and more. The only thing it doesn’t do it inline ATP. Bonus points, it can run as SaaS, hybrid, or completely airgapped, and has a smart routing mesh network which brings in SDWAN concepts and works great for DDIL network scenarios (which is why military contractors and gov like it so much). TBH though, if you haven’t heard of it, that probably because more users are companies themselves who embed it into their tech stack and deliver it as their own branded ZTNA offering (e.g., a cyber security unicorn, 1 of the 4 hyperscalers, a large ICS/OT vendor, etc).
Cato Networks, add in a global backbone, fully converged EPP and XDR…and a bunch of other ancillary supplier managed service capabilities if an enterprise needs them and a partner MSP can’t deliver them ditectly.