There’s a good chance that you’ve heard the term Zero Trust (ZT) or Zero Trust Network Architecture (ZTNA) in recent years. Much of the language surrounding Zero Trust makes it sound like an revolutionary leap – a panacea – in terms of security and an obvious good for all organizations and users. Indeed Zero Trust does provide serious benefits in many cases, but we think there is more to the story and that regular people should know more about what Zero Trust actually is and, perhaps more importantly, what it is not.
What is Zero Trust?
In the past, organizations designed their security architecture with a defensible perimeter (e.g., firewalls, remote access via VPN, etc.). Users and devices within the perimeter – e.g., logged in to a device on the LAN or connected through the VPN – are trusted by default, meaning they have access to resources without needing to further verify their identity. Of course, this previous architecture creates a major point of weakness: a malicious internal user, or someone who has had their credentials compromised, would have access to many internal systems once allowed through the perimeter.
As organizational boundaries are increasingly blurred (e.g., use of cloud services, remote work, etc.), creating a defensible perimeter becomes more and more difficult – how can an organization control network devices when its network has essentially been turned inside out? A perimeter defense has significant weaknesses once an attacker has gained access to the network, so that model no longer works.
These factors have led to the industry shift towards Zero Trust, a security architecture based on the idea that no device can be trusted by network services, and therefore always need to be checked on every action taken. You can read more about the NIST standard for Zero Trust, which avoids the marketing-speak that the Zero Trust space is overflowing with. In the end, ZTNA providers require you to authenticate any time you want to access a given system or to perform a certain action, no matter your location in the network or device you’re using. An example of ZTNA would be when you connect to an organizational service such as webmail and you are required to authenticate using a multi-factor authentication app.
Done this way, ZTNA results in a more secure network for the organization, since compromises can be mitigated much more easily. So how could it be problematic?
Zero Trust is a Misnomer: Zero Trust is actually Absolute Trust
In an industry filled with buzzwords, ZTNA might be one of the most misused / least understood simply due to poor choice of words. If we step back and think about it, the term Zero Trust would imply that the system has been designed such that no party needs to trust any other party – sounds great! However, a more accurate term for what we now understand to be ZTNA would be Absolute Trust: ordinary users and organizations must place all of their trust in the ZTNA providers that they use. ZTNA systems don’t trust users, but users and organizations must trust them. Every system access in ZTNA is authorized, real-time, and logged – meaning the ZTNA service knows exactly what every user is doing at any given time. They additionally have access to metadata such as the IP address, client stack, and often much more.
A decade ago most organizations used services that they managed themselves, on premises or in a colocation facility. This was an operational hassle, and the cloud-based world we’re in today makes things much easier. But that comes with a cost: when an organization is turned inside out, exposing every internal conversation and action to a menagerie of third-party providers, those third-party providers are now all part of the threat model the organization needs to consider.
While companies that sell ZTNA solutions are no doubt good at their jobs and securing their networks, nobody is perfect. Breaches happen, and scarcely a week goes by without there being a major breach in the news. So what happens when your ZTNA service provider has a breach? Everyone’s use of the system (along with their metadata), not just everyone in a single organization but everyone in every organization that uses the service provider, could be exposed.
Do ZTNA services actually need all of the information that they are currently privy to in order to accomplish their tasks? If we apply the principle of least privilege / knowledge, it becomes obvious that there’s a problem with the way Zero Trust has been built.
Towards Oblivious Trust
What should we do instead? We believe that systems on the Internet need to be (re)designed to protect everyone (individuals as well as organizations) by default. Privacy is an individual right – each of us can want to control the amount of information about us that’s collected. Security, on the other hand, is an organizational goal for a collection of individuals. We need both privacy and security in all our communications. While current ZTNA designs might seem designed to sacrifice privacy in exchange for better security, ZTNA is actually sacrificing both privacy and security: privacy of individual users and the security of the organizations that are now exposed to dozens of third-party service providers who might get hacked or sell the data and metadata they’ve harvested. ZTNA is trading one form of security for another – fine-grained access control that ZTNA provides vs. organizational and user control over their data and metadata – and we don’t believe that these two goals must be mutually exclusive. If we can create systems that truly require no trust in any participant, we will have succeeded in creating what we call Oblivious Trust.
Fortunately, there are some existing techniques that we can leverage on our journey towards Oblivious Trust. We have previously discussed the Decoupling Principle, which can be applied to design networked systems that inherently provide Oblivious Trust. We’ve found that it’s straightforward to apply the ideas behind Relay to many network services and protocols, which is how we created Booth. In PGPP we applied the Decoupling Principle to implement oblivious authentication, thereby separating a user’s identity from their use of the network while still ensuring that they are authorized. These techniques and more like them are the building blocks we can use to build systems that have both privacy and security built in by design.