There’s a lot of Zero Trust and Zero Trust Network Access (ZTNA) related marketing buzz circulating at the moment, which can make it seem like every firewall and networking vendor has magically built a Zero Trust product overnight.

Back in 2016, Google was registering almost no interest whatsoever in the term “Zero Trust”, it has experienced a meteoric rise in popularity with at least 90 vendors (at the time of writing) offering some kind of a Zero Trust Network Access solution.

Marketing aside, there has been an undeniable shift in interest towards Zero Trust. We can attribute this shift, in no small part, to President Biden’s Executive Order and the supporting (impartial guidance) published both by the United States National Institute of Standards and Technology (NIST) in 2020 and the British National Cyber Security Centre (NCSC) architecture guidance in 2021.

The resulting, and quite sudden rush to re-brand existing products as Zero Trust has meant many vendors have reached for the nearest and closest technology that approximates the guidance. For the majority of vendors, that technology was the Software Defined Perimeter (SDP).

The vast majority of companies now selling Zero Trust Network Access today, are selling manifestations of a Software Defined Perimeter.

As if Zero Trust wasn’t complicated enough, with new concepts that challenge traditional thinking, lots of acronyms, and nearly 60% of vendors selling SDP solutions, you could be forgiven for thinking that SDP is the only road leading to Zero Trust Network Access.

However, SDP doesn’t represent the leading edge of innovation in the ZTNA market.

Quite the opposite, in fact. SDP was first conceived of 15 years ago, way back in 2007 when the first iPhone was released, MPLS was still the new kid on the block, and Eric Schmidt had just said something about services belonging “in a cloud somewhere”, but nobody really knew what he was talking about.

Which is to say that in the world of technology, networking and security - 15 years is an eternity. Despite the market’s early move towards SDP architectures, the Zero Trust Network Access space is a vibrant and rapidly changing landscape, bursting with new and innovative technologies.

Zero Trust Network Access has a bright, but slightly opaque future. In this article, we’ll share our vision for how ZTNA technologies will continue to evolve over the next three years and why at Enclave, we’re betting on peer-to-peer overlay networks.

What is Zero Trust, and how does it relate to Zero Trust Network Access?

John Kindervag, the mind behind the popularisation of the paradigm-shifting school of thought that is Zero Trust, imagined a set of principles in which no network user, packet, interface, or device — whether internal or external to the network — should be implicitly trusted.

Zero Trust is a large topic. Guidance counsels implementers to consider concepts like asset inventory, session-based access, dynamic policies, real-time monitoring of security posture, and collection of data for continuous measuring and improvement, but at its heart, Zero Trust is a networking concern.

It’s all about connectivity.

At its heart, Zero Trust is an approach to deliver better network access control, but there’s something almost trite about that. After all, not many of us over the last decade would have stood up to campaign for worse access control.

Digital security is a house of cards, stacked and layered. Like onions, we say. Each layer builds upon the previous, but until the advent of Zero Trust, we’d all been building security defences by layering on top of two fundamentally flawed, reactive layers:

1. Private services are publicly visible: It’s still quite normal to place a private system like a VPN server (and SSH, RDP etc.) out onto the public Internet, open a port and let the VPN server reject any connections that can’t present valid credentials. How absolutely crazy is that? What’s our answer to software vulnerabilities in the VPN server? Frequent patching. What’s our answer to Zero Day vulnerabilities where no patch is available? Defence in depth, of course: add more layers!

2. Over-reliance on the perimeter: Often compared to a moat around a castle, the VPN server places external entities onto the local network and allows them (unless deliberately contained with ACLs) unfettered access to move laterally on internal networks. When a red-team simulation (and real-world attack) forces action, what’s the answer? Err. Defence in depth, right? Add more layers!

Yeah, more layers.

The problem is that at the bottom of our house of cards, we’ve got rot in the foundations upon which we build the rest of our security apparatus.

As Henry Ford famously observed, “If you always do what you’ve always done, you’ll always get what you’ve always got”.

This is why Zero Trust and Zero Trust Network Access represent the most important and fundamental shift in assumptions we make about the bottom-most layers of network security since the formation of the Internet.

It moves the whole industry from a reactive to a proactive posture with a single, simple idea: remove implicit trust from network access. Gartner concisely summarises the key principles of Zero Trust Network Access as follows:

1. Applications are hidden from discovery, no public visibility.
2. Access is restricted via a trust broker.
3. The trust broker verifies the identity, context, and policy.
4. Lateral movement in the network is prohibited.
5. There is a reduced surface area available for attack.

Zero Trust is a broad set of concepts. Zero Trust Network Access is focussed, practical and quite easy to implement and a great place to get started with Zero Trust.

As General Robert Neller, the former US Marine Corps Commandant said, “We need to make the adversary work to find us – we can’t make it easy for them to find us”.

“I don’t understand why people don’t understand,” Neller continued. “If I can find you, I can target you; and if I can target you, I can shoot you; and if I can shoot at you, I can kill you. It’s pretty simple.”

This is the key behaviour of a Zero Trust Network Access solution: to reduce discoverability by allowing operators to close ports on the firewall while maintaining access for trusted parties.

The effect of which is to conceal infrastructure and services, darkening the network to prevent discovery, targeting and attack.

Why Zero Trust, and why now?

Let’s not kid ourselves. We’ve been trying to get better access control since the Morris Worm struck in 1988. Defenders have always struggled to outpace attackers, and in the last decade, it’s gotten worse, with a dramatic uptick in organised crime, state-sponsored actors involved in cyber-arms warfare and the global government-backed Zero-day weapons market collectively blasting through VPN servers and perimeter defences (Suggestion: if you’re not familiar with the Zero-day weapons market, consider reading Nicole Perlroth’s book “This Is How They Tell Me the World Ends: The Cyberweapons Arms Race” detailing her decade spent reporting on the subject for The New York Times, published in 2021).

Some of the more notable high profile hacks in the past several years have stemmed from vulnerabilities in traditional VPN servers, including Pulse Secure VPN and Zyxel but the answers to why Zero Trust and why now, are both almost certainly the Colonial Pipeline hack in 2021.

A malware infection which prompted the immediate shutdown of a 5,500-mile pipeline that carried roughly half of the fuel supply for the United States’ East Coast and catalysed a seismic shift in the US Government. After declaring a national emergency to deal with the hack, the Biden administration moved quickly to strengthen US cybersecurity defences and publish a road map for government agencies to adopt Zero Trust architectures by the end of 2024 to help stop the bleed and stem exploitation of digital vulnerabilities in federal systems.

Software-Defined Perimeter

So what do vendors in this industry do when the US Government mandates an urgent move towards Zero Trust? They reach for the nearest, most accessible technology to fit the requirements - Software Defined Perimeters (SDP). The Software Defined Perimeter architecture also happens to be the oldest of the architectures which fit the Zero Trust Network Access principles, but it’s not the only show in town.

Origins and architecture

When SDP was first conceived in the pre-Cloud era of 2007, it was designed as a solution to enable secure access to the perimeter before passing legitimate traffic on towards servers, applications, and workloads inside the internal, trusted network.

An initiating-host outside of the network was configured to use a variant of the Single Packet Authorization (SPA) to gain access to SDP Connectors running at the edge of the customer’s network (usually an appliance, physical or virtual, deployed as a reverse-proxy with a public IP address).

SDP Connectors were managed by a centralised controller (trust broker), which synchronised the interactions between clients (connection initiators) and SDP Connectors.

In effect, the SDP architecture required users to add proxy devices to the network edge, which only responded to certain external systems, based on receipt of special encrypted handshake packets but were otherwise dark and unresponsive – though they must be available on the public Internet.

Strengths

• No ingress traffic, firewalls can be closed. Most (but not all) SDP vendors use SPA to render the SDP Connector invisible to unauthorised parties.

• North-south traffic. Assuming the ability to deploy an appliance and assign it a public IP address, the SDP architecture darkens the perimeter and enables clients to access services hidden behind the SDP Connector appliance.

• Application-aware. As an application aware proxy, the SDP Connector has full access to traffic flows between client and server, so can police data flows for illegitimate access and perform deep packet inspection.

Weaknesses

• Connector deploys as VM or appliance. Another appliance? In front of every network?

• Connector availability determines uptime. Just like normal. High availability requires multiple appliances. The connector deploys as a VM or appliance, requires patching, and its availability determines system uptime.

• East-west (server-to-server) traffic. Poor support for this traffic pattern

• Lacks universal protocol support. It’s an application aware proxy, so can’t speak all of the things

• Must be reconfigured if network changes. SDP Connector targets services behind it by IP address and port number.

• Zero Trust properties are lost at the perimeter. When the connector connects to your back-end service, the Zero Trust principles are stripped. The SDP Connector must be free to move laterally on the internal network to access the hosts it protects.

Through a modern lens, the SDP architecture looks like a fairly blunt instrument when you consider how physically dispersed and fragmented the networks of modern organisations are.

We have computers, laptops, workstations, servers, applications, peripherals, IoT devices and more spread between home networks, offices, data centres, containers, Kubernetes clusters, virtual machines, running on the cloud, in multiple regions, sharded between multiple vendors, in serverless functions and on edge compute environments.

The world was a very different place in 2007. SDP was built before the diversification of tech into the Cloud, coupled with DevOps and Covid-19 together which altered the rules of the game, so it’s not hard to see how the then-popular “throw an appliance at it” approach to problem solving could have seemed entirely sensible.

The SDP architecture does, to its credit, excel at remote access use-cases, assuming target systems exist in a small number of locations, and the primary traffic pattern required is client initiated, to a server.

So what might it look like if we built a Zero Trust Network Access solution in 2022 with a modern set of design goals?

How to solve for ZTNA in 2022

Starting from scratch today in our Cloud-enabled, massively interconnected, DevOps fuelled, home-working world, we’d abolish the concept of a perimeter. The idea of inside and out is simply no longer relevant and runs counter to Zero Trust guidance.

We’d also want to ensure our solution was decoupled from the internal IP address. An IP address is a network location, yet we constantly conflate it with identity. Access Control Lists I’m looking at you.

Universal protocol support, obviously.

We may also favour incremental deployment. Seismic shifts in technology often take a disproportionally long time to adopt (IPv6) if the perceived complexity is too high, the gains are not clear enough or transitioning means existing investments cannot be leveraged.

Most importantly – the distinction between north/south and east/west traffic patterns should be irrelevant. DevOps and DevSecOps is a promise to go faster. It would make absolutely no sense to ignore the east/west internal traffic that is no longer fenced into a single flat network. We must not allow Zero Trust Network Access to be thought of as a remote access only technology, it’s much too powerful to be pigeon-holed as a simple tool for north-south traffic.

This is the biggest failure of the SDP architecture. It’s tweaking what we already have, not transforming or re-inventing for the modern world. We need the properties of Zero Trust Network Access everywhere, not just at the perimeter.

Let’s capture some design goals.

1. No perimeters. The network is more than remote access. It’s in the datacenter, it’s between datacenters. It’s at home, in the Cloud, in different regions. It’s multi-Cloud, it’s virtual, mobile and ephemeral. Workloads and users exist in different places, on different networks, with different operators, different trust levels and varying degrees of control. The idea of a perimeter is a toxic design relic of networks in the Noughties. It’s how we’ve thought about and built networks for the last twenty years. It will not be how we build networks for the next twenty.

2. No appliances. Not even a virtual appliance please. Nobody wants an extra device to pay for, power, cool, maintain, service, warranty, backup, restore & patch just to act as an extra hop to get somewhere else. Reasons for having an on-site appliance: storage, compute, cache, backups. Reasons for not having an on-site appliance: shunting packets left-to-right, forget it.

3. No IP addresses. Take Zero Trust Networks Access principles all the way to the edge, to the workload itself. If your ZTNA product needs to ask the question – “What’s that server’s IP address?” to get set up, anything behind that product is not Zero Trust Network Access, forget it.

4. No proxies. If these aren’t the bane of the Internet. Proxies are the poor neighbour of a fully functional network interface. Proxies don’t have the option of not being protocol aware, they have to be. If you’re going to move traffic, use a protocol agnostic network interface for universal protocol support. Attack the problem of layer 7 visibility from the bottom up, support everything and examine the protocols you care about like HTTP, RDP, SSH and SQL. If you start top down, you can only transport protocols which you know how to decode. The network has one job – carry traffic, so don’t hamstring it with a proxy that can only carry three protocols. Zero Trust Network Access solutions need to behave like a real network if they’re going to replace VPNs, and that means universal protocol support.

5. No changes. Deploy non-disruptively. Best case, uplift the existing network as-is and enrich with Zero Trust Network Access principles to leverage existing investments. Worst case, deploy non-disruptively to anything already in-situ. If the solution requires rip-and-replace, forget it. ZTNA solutions need to deliver the network you want over the network you already have.

6. Never obstruct. Too many ops teams turn themselves inside out and get tied up in knots trying to evolve the network to support the changing needs of the business. It took DevOps to remind us that IT is supposed to be a service to the business. The same is true of the network. The ZTNA solution must allow seamless network change and dynamically reconfigure around it. It’s not practical to need to move a workload but be blocked because the ZTNA solution will need to be reconfigured. If the ZTNA solution can act as a blocker to change, forget it.

7. Be easy to use. As Bruce Schneier puts it, “complexity is the worst enemy of security, and our systems are getting more complex all the time”. Ease of use is a feature. Care about the end-user, don’t burden them with firewalls, ACLs, NSGs, VPCs, NAT, certificates and key rotation. Be easy to use or forget it.

8. Be resilient to failure. The availability of the overall system should not be predicated on the availability of a single device. The answer is (still) not “throw an appliance at it”. The entire system should be resilient to temporary trust broker failures.

We don’t need incremental improvements. We want – need – solutions that take a new, holistic approach to Zero Trust Network Access, not just a new approach to the perimeter.

Zero Trust has the potential and promise to help us do more with less and become orders of magnitude more secure in the process. To build a better network and bring seamless connectivity to all parts of the business without needing to do anything remotely complicated to make it all work. But not with small, increment improvements and decades-old design philosophies.

There are a handful of companies today building modern ZTNA solutions from the ground up with requirements like these in mind and who are using peer-to-peer overlay networks to do it.

We’re one of them.

Enter the peer-to-peer overlay network

If you’ve not heard that term before, peer-to-peer overlay networks are like traditional corporate VPNs, but without the VPN server.

Instead of using VPN servers (or concentrators) to allow devices to talk, on a peer-to-peer overlay network, devices are connected directly to one another automatically, and regardless of their location (e.g. at home, in the office, the data centre, Cloud, on edge devices, containers, Kubernetes, IoT or in more exotic places like GitHub Actions or Lambda functions).

It’s a big distinction, because without VPN servers in the middle, the network starts to look more like the business itself. For example, Developers connect directly to their development servers, rather than having traffic routed, sometimes inefficiently, via a corporate VPN.

The peer-to-peer connections carrying data between devices are negotiated using a combination of certificates, UDP & TCP hole punching and NAT traversal techniques, which together create fast, encrypted tunnels between devices from behind closed firewalls.

Implemented completely in software, the whole system is centrally managed by a SaaS (or self-hosted) trust broker, which allows the network to dynamically form and terminate in response to real-time conditions. Additionally, the trust broker feeds user identity, security context and dynamic policy evaluation into the overlay networks’ construction to govern which devices can connect, for whom, when and under what conditions to create precision access.

The entire network can operate on a need-to-know basis. Network members must successfully authenticate using digital certificates and all systems are dark to the public Internet, protected behind closed firewalls with no knowledge of one other and no ability to communicate until policy-based trust conditions are met.

There’s no getting around this system, and the blend of peer-to-peer overlay network architecture with the principles of Zero Trust Network Access creates a powerful combination.

Now every transaction, on any part of the network is automatically micro-segmented, least privilege and authenticated at the device level. Policy decisions are dynamic, enriched with user identity and real-time security posture information and the whole network goes dark, becoming invisible - hidden from discovery, targeting and attack.

At enclave.io we call this alliance a Zero Trust Overlay Network

Zero Trust Overlay Network

A Zero Trust Overlay Network is a highly customisable overlay network that sits on top of your existing network infrastructure, aligned with Zero Trust Network Access principles to create secure, private, and end-to-end encrypted connections, without needing to re-configure or make changes to the underlying network infrastructure.

The overlay network can be created out of—and on top of—systems that are connected in a peer-to-peer mesh to remove network complexity and eliminate the need for gateways, proxies, and middleware devices.

Strengths

• No gateway devices or proxy servers. Entirely software based, ZTON solutions only require agent installation and have no requirement for additional hardware (unless the customer has opted to self-host).

• Universal protocol support. Overlay networks operate at OSI layers 2 or 3, depending on the implementation, encapsulating either Ethernet frames or IP packets, which allows ZTON architecture to carry almost any kind of network traffic the organisation might need, including UDP and multicast traffic.

• Incremental deployment. As ZTON solutions are often SaaS-based with agent installation on endpoints, it’s often possible to deploy Zero Trust Network Access to just two systems in a few minutes without disrupting the underlying network, adjacent systems, or endpoint operation where the agent is installed. Expanding later to include more devices and servers incrementally.

• Does not distinguish between north-south or east-west traffic patterns. ZTON architecture is agnostic to endpoint location, heterogeneous provider networks and logical boundaries. So it works in exactly the same way, anywhere. Regardless of the underlying bearer or what traffic it’s carrying.

• Removes complexity from the network. Building private connectivity using ZTON means simpler configurations for firewalls, ACLs, NSGs, VPCs, NAT, certificates & secret keys, which directly translates into less time spent managing network complexity.

• Resilient to temporary trust broker failures. Policy is cached by endpoints. Should the trust broker become temporarily unavailable, network traffic continues to flow between connected devices.

• No network changes to deploy. Software-based installation on edge-devices and endpoints, so completely non-disruptive to core network and existing systems.

• Aggressive automation. Without any up-front deployment costs beyond agent installation, ZTON solutions lend themselves towards automation and self-service, enabling API calls to dynamically create, reform, grow or shrink task and purpose-built networks at a moment’s notice.

Weaknesses

• Primarily agent-based deployment. Some organisations negatively regard agent-based solutions, often because they suffer from agent bloat on end-user systems.

• Agent software requires patching. Like any software, ZTON agent installations require patching. Ensuring agents are patched and up to date can be more challenging for the IT or ops teams if the vendor does not provide an auto-update mechanism.

• Zero Trust not applied to peripherals. If the agent software cannot be installed, Zero Trust Network Access principles cannot be extended to it, so as traffic leaves the overlay network to reach peripherals devices, for example, ZTNA principles are lost at the gateway.

Zero Trust in 2025 and beyond

The genie is out of the bottle. As more companies embrace Zero Trust Network Access solutions, huge swaths of the Internet will go dark, rendering previously exposed systems undiscoverable.

As Zero Trust Network Access displaces VPN servers as the defacto remote access mechanism, businesses will begin to transact on entirely invisible, transient private networks. At the same time, the risks of lateral movement (along with VPNs) are consigned to the pages of history, much to the dismay of red-team security testers.

The historical precedent for forward looking, fast-moving and highly innovative organisations to reap the rewards of being early adopters is long established.

Competitive advantage comes from technology scarcity, but once a technology reaches mainstream adoption, it switches from being a competitive advantage, to becoming critical to remain competitive.

Today, Zero Trust Network Access and ZTON are early-adopter technologies. Early adopters gain competitive advantage and an ability to execute more rapidly and for lower cost than their peers - but like Cloud computing, the tipping point will come when deploying a ZTON architecture is required simply to keep pace.

There will be technology winners and losers as the world transitions away from VPNs.

Early adopters have the opportunity to unify their entire network stack under the principles of Zero Trust Network Access and leave behind the days of siloed technologies for remote access and machine-to-machine connectivity, fragmented access controls between different vendors and Clouds and the fragile glue that bound them all together.

Much like the evolution from virtual machines to containers, we believe that the Zero Trust Overlay Network architecture will eclipse Software Defined Perimeters as a more accessible, flexible, simpler means to embrace Zero Trust Network Access.

We’d love to show you what we’re building.

If you’d like to talk about the future of Zero Trust or try out a Zero Trust Overlay Network for yourself, the enclave.io team are exhibiting at InfoSec Europe on stand F30 in ExCeL London, 21-23 June 2022.

You can also reach us by emailing team@enclave.io