2

I am currently evaluating Next-Generation Firewall concepts and features and remembered about the Zero Trust networking model. I do find the notion of "trust nothing" in the context of networking security very enticing. So I researched on providers of zero trust solutions and also read the appropriate NIST architecture specification.

So generally speaking, in a zero trust network, clients register via an installed application at a gateway and send all of their data to that gateway. The gateway then checks if the user's request is legitimate and forwards it to the appropriate server. The server's return data is again checked for anomalies and, provided nothing was found, forwarded to the user. Failing the existence of a client, users may be able to use a web-gateway (similar to a Captive Portal in a 802.1X setup).

What strikes me as odd is that this explanation sounds awfully a lot like a network architecture where users are accessing resources through a VPN, ideally provided by a firewall, and the VPN gateway then acts as a Man-in-the-Middle to decrypt the TLS connections between user and server so as to perform ARM, DPI and AV functions (and re-encrypt if no anomalies have been found).

This may become problematic if you have hard restrictions by way of data protection regulations or other hurdles that prevent you from inspecting basically all (user) data in your network. In fact, one of the major criticisms of NGFW solutions is that to produce the advertised security, the firewall needs to decrypt the encrypted packets so as to be able to prevent malicious data from entering the corporate network. But if Zero Trust architectures functionally are doing the same thing by actively being a Man-in-the-Middle, then this criticism is not alleviated.

Is there another aspect to current zero trust architecture solutions that I am currently missing?

5
  • A VPN is a tunnel that encapsulates packets inside outer VPN packets. That is unlike Zero Trust that does not encapsulate packets. They are two very different things.
    – Ron Maupin
    Jan 17, 2023 at 16:07
  • @ron-maupin If I send all of my user data across an encrypted TCP application stream (like HTTPS) to a gateway so that the gateway will do the server connection for me, then what I am doing is functionally equivalent to encapsulating my concrete TCP packets. Just because it is technically different, does not necessarily prevent that it is functionally the same. The functional aspect is what I am interested in.
    – alex
    Jan 17, 2023 at 16:12
  • Zero Trust is a broad architectural concept, and there's no one solution/product. If you squint a bit, a VPN and TLS connection are very similar. It's true that some vendors have recast their VPN solutions as "zero trust" in order to capitalize on the marketing value. Vendors have tried to put the zero trust label on anything they have.
    – Ron Trunk
    Jan 17, 2023 at 16:29
  • "If I send all of my user data across an encrypted TCP application stream (like HTTPS) to a gateway so that the gateway will do the server connection for me, then what I am doing is functionally equivalent to encapsulating my concrete TCP packets." No, TLS encrypts the TCP segment (not packet) data. It does not encapsulate the IP packet inside another packet as a VPN tunnel would do. Those are two different things.
    – Ron Maupin
    Jan 17, 2023 at 16:46
  • This may become problematic if you have hard restrictions by way of data protection regulations or other hurdles that prevent you from inspecting basically all (user) data in your network. ZT isn't for everybody. It was developed for systems where security is more important than privacy. Like many vague concepts such as "cloud computing," marketing departments have taken the term and applied it to everything possible, whether it belongs or not.
    – Ron Trunk
    Jan 18, 2023 at 13:13

4 Answers 4

5

The comparison as given makes the two solutions seem very similar. Most Zero Trust Network Access implementations do implement the mentioned features but tend to add additional features and components to make a whole package.

Simply providing a VPN tunnel for remote clients (or local clients with no trust, doesn't matter in ZTNA) is not enough to accomplish Zero Trust, even if the VPN client software provides features for verifying 'client posture' to make sure it has functional anti-virus etc. Securing the client only makes part of the network 'zero trust'. Resources on the local network also need to be secured. ZTNA requires those internal platforms and cloud platforms the organization uses also have software to help control their connections and data transfer, including between devices on the internal network.

For example: Employees may bring in devices or data that is infected or suspect and infect an internal system that is 'trusted'. Without controls on the internal devices, a beachhead infection on a trusted device could easily spread to other trusted devices.

Also it helps limit and mitigate trusted people doing things they should not by interfacing between devices that would not otherwise pass traffic through a gateway where the traffic might be inspected.

To make it effective, you need a mostly centralized or fully centralized management platform for this kind of approach, otherwise it becomes too complex for administration to keep an effective handle on it all.

Simply controlling data access from remote users is not enough.

1
  • This is correct and my example was knowingly reductive. Of course in my alternative VPN-based ZTNA, all of the "trusted" internal clients/servers/hw would need to establish a VPN connection to the gateway. Upon reflection, I guess my greater concern is the MitM/DPI aspect that ZTNA seems to rely upon functionally (i.e. inspect every user data). Depending on your situation, this might be troublesome in lieu of data privacy protection regulations. I'll amend my question accordingly.
    – alex
    Jan 18, 2023 at 8:55
1

Conceptually speaking, TLS and VPN are very similar. Vendors can, and often do, recast their VPN products as Zero Trust in order to capitalize on the marketing value.

1

Zero Trust (ZT) is a security concept that assumes all users and devices are untrusted until proven otherwise.

Your question is about Zero Trust Network Access (ZTNA) which is an implementation of the ZT concept that applies to network access.

Where ZTNA conceptually diverges from the previous user-based network access concepts (802.1x, VPN, WPA-Enterprise, ...) is in the fact that the old model put a user into a network segment assigned to their role (accounting, IT, ...) - macro-segmentation. What this network segment can access afterwards is implemented somewhere else and on a per-group basis. With ZTNA, on the other hand, users are not segmented per-group, rather per-user. Once authenticated, a user can access specific services separately from the other users (micro-segmentation w/ overlay tunnels).

That being said, ZTNA is concept which is well over a decade old but which only recently got popular with major vendors, each fitting their solutions under the ZTNA umbrella (no pun intended). The ZTNA concept does not require DPI firewall or TLS decrypting (MitM) proxy. You can and you should ask your favorite vendors whether their ZTNA service allows you to run w/o DPI and TLS decryption.

1

Don't forget about all your IOT/OT devices that cannot accept a vendor ZTNA client when working on this framework. There are ways to create micro-segmentation of the LAN in a campus environment to limit device-to-device communication and protect against the L2 adjacency issue. Airgap Networks turns L2 networks into L3 networks by using /32 concept.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.