A few weeks ago, I wrote a post called “What is trust?”, about how we need to be more precise about what we mean when we talk about trust in IT security. I’m sure it’s case of confirmation bias*, but since then I’ve been noticing more and more references to “zero-trust networks”. This both gladdens and annoys me, a set of conflicting emotions almost guaranteed to produce a new blog post.
Let’s start with the good things about the term. “Zero-trust networks” are an attempt to describe an architectural approach which address the disappearance of macro-perimeters within the network. In other words, people have realised that putting up a firewall or two between one network and another doesn’t have a huge amount of effect when traffic flows across an organisation – or between different organisations – are very complex and don’t just follow one or two easily defined – and easily defended – routes. This problem is exacerbated when the routes are not only multiple – but also virtual. I’m aware that all network traffic is virtual, of course, but in the old days**, even if you had multiple routing rules, ingress and egress of traffic all took place through a single physical box, which meant that this was a good place to put controls***.
These days (mythical as they were) have gone. Not only do we have SDN (Software-Defined Networking) moving packets around via different routes willy-nilly, but networks are overwhelmingly porous. Think about your “internal network”, and tell me that you don’t have desktops, laptops and mobile phones connected to it which have multiple links to other networks which don’t go through your corporate firewall. Even if they don’t******, when they leave your network and go home for the night, those laptops and mobile phones – and those USB drives that were connected to the desktop machines – are free to roam the hinterlands of the Internet******* and connect to pretty much any system they want.
And it’s not just end-point devices, but components of the infrastructure which are much more likely to have – and need – multiple connections to different other components, some of which may be on your network, and some of which may not. To confuse matters yet further, consider the “Rise of the Cloud”, which means that some of these components may start on “your” network, but may migrate – possibly in real time – to a completely different network. The rise of micro-services (see my recent post describing the basics of containers) further exacerbates the problem, as placement of components seems to become irrelevant, so you have an ever-growing (and, if you’re not careful, exponentially-growing) number of flows around the various components which comprise your application infrastructure.
What the idea of “zero-trust networks” says about this – and rightly – is that a classical, perimeter-based firewall approach becomes pretty much irrelevant in this context. There are so many flows, in so many directions, between so many components, which are so fluid, that there’s no way that you can place firewalls between all of them. Instead, it says, each component should be responsible for controlling the data that flows in and out of itself, and should that it has no trust for any other component with which it may be communicating.
I have no problem with the starting point for this – which is as far as some vendors and architects take it: all users should always be authenticated to any system, and authorised before they access any service provided by that system. In fact, I’m even more in favour of extending this principle to components on the network: it absolutely makes sense that a component should control access its services with API controls. This way, we can build distributed systems made of micro-services or similar components which can be managed in ways which protect the data and services that they provide.
And there’s where the problem arises. Two words: “be managed”.
In order to make this work, there needs to be one or more policy-dictating components (let’s call them policy engines) from which other components can derive their policy for enforcing controls. The client components must have a level of trust in these policy engines so that they can decide what level of trust they should have in the other components with which they communicate.
This exposes a concomitant issue: these components are not, in fact, in charge of making the decisions about who they trust – which is how “zero-trust networks” are often defined. They may be in charge of enforcing these decisions, but not the policy with regards to the enforcement. It’s like a series of military camps: sentries may control who enters and exits (enforcement), but those sentries apply orders that they’ve been given (policies) in order to make those decisions.
Here, then, is what I don’t like about “zero-trust networks” in a few nutshells:
- although components may start from a position of little trust in other components, that moves to a position of known trust rather than maintaining a level of “zero-trust”
- components do not decide what other components to trust – they enforce policies that they have been given
- components absolutely do have to trust some other components – the policy engines – or there’s no way to bootstrap the system, nor to enforce policies.
I know it’s not so snappy, but “explicit-trust networks” really is a much better way of describing what’s going on here. What I do prefer about this description is it’s a great starting point to think about trust domains. I love trust domains, because they allow you to talk about how to describe shared policy between various components, and that’s what you really want to do in the sort of architecture that’s I’ve talked about above. Trust domains allow you to talk about issues such as how placement of components is often not irrelevant, about how you bootstrap your distributed systems, about how components are not, in the end, responsible for making decisions about how much they trust other components, or what they trust those other components to do.
So, it looks like I’m going to have to sit down soon and actually write about trust domains. I’ll keep you posted.
*one of my favourite cognitive failures
**the mythical days that my children believe in, where people have bouffant hairdos, the Internet could fit on a single Winchester disk, and Linux Torvalds still lived in Finland.
***of course, there was no such perfect time – all I should need to say to convince you is one word: “Joshua”****
****yes, this is another filmic***** reference.
*****why, oh why doesn’t my spell-checker recognise this word?
******or you think they don’t – they do.
*******and the “Dark Web”: ooooOOOOoooo.
Alice, Eve and Bob - a security blog 
5 thoughts on ““Zero-trust”: my love/hate relationship”