Zero Trust Redux
In my last post I talked about the emergence of the Zero Trust Architecture (ZTA) in the Operational Technology world. Coincidentally, the topic has come up in a couple of discussions I’ve been involved in lately… Perhaps it’s not so coincidental – maybe ZTA, or at least the buzzword, is rapidly entering into the OT space. In any event, what has become very apparent to me is that many folks mistake zero trust with what they have been using for many years now: implied (implicit) trust.
Implied trust is what you have when you permit or deny some action to occur based solely on what network a device is connected to, what IP addresses are in use, or, perhaps in some cases, whether or not it presents the correct password. There’s no independently verifiable mechanism to corm that device is what it says it is, like a signed Public Key Infrastructure (PKI) certificate. It’s using the right addresses and its traffic passes through the right firewalls, so this must be a transaction we want to take place, right? So to make sure the bad guys stay out, we erect all sorts of firewalls and develop complex Access Control Lists (ACLs) to make sure all of the their communication is kept far away from our critical processes.
I think the problem is that people who aren’t in the know (especially those OT folks who don’t follow all of the latest IT trends) hear the term “zero trust” and they think “Hey, we’ve got no trust mechanisms built into our technology, they must be talking about our stuff.” OK, maybe that’s a bit harsh, but I do think the misconception is more along the lines of building all sorts of protection around your system because you trust no one to stay out.
In reality, ZTA is the opposite. ZTA relies heavily on building sophisticated trust mechanisms into processes and protocols precisely because you can put no trust in attributes like what network a device is connected to. The idea is that you put zero trust in anyone who doesn’t have the right certificate or is using a communication channel that can be highjacked by a malicious actor, for example. A nice description with a little more detail can be found in this article: What is Zero Trust? A model for more effective security.
In some contexts, ZTA is seen as the opposite of using a Virtual Private Network (VPN), since the VPN allows to extend the trusted network to those outside of an enterprise. I think that’s a bit of misleading simplification since ZTA technology can be useful in many contexts outside of the remote access VPN use case. On the other hand, an extreme advocate of ZTA might claim that you could do away with all firewalls and network security mechanisms because with ZTA technology, it doesn’t matter what network a device is on or what it has access to. Without the correct, verifiable credentials, they aren’t getting in. However, making that leap means you put a *lot* of trust in the system developer to not make any mistakes or leave an exploitable vulnerability in the system. I won’t say I put zero trust in developers, but the history of cybersecurity shows that mistakes do happen and quite often they get rooted out by folks looking for them to do bad things. With that in mind, it’s still prudent to use firewalls and protect systems from unnecessary access, especially in OT environments where the consequences of a security breach are high.
So as you have discussions around zero trust, it would be wise to start off with a discussion about the definition so everyone is on the same page. This is especially true when people from different environments or organizations are involved because with a rapidly spreading buzzword like ZTA, it’s possible someone participating in your conversation has picked up an incorrect notion along the way. Having an opening conversation around definitions for level-setting purposes is actually not a bad idea whenever a complex technical discussion occurs among folks who normally don’t work together. It’s good to work organizational and experience differences out of the mix before misunderstandings occur.