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.

Zero Trust in the Operational Technology Environment

The other day I tweeted out a link to an article I saw come through Twitter that extolled the virtues of Zero Trust in the Operational Technology environment. In short, Zero Trust Architecture is a security approach that relies on mutual authentication and fine granularity of permission to protect data and services. Essentially, transactions are proceed when the end points are 100% sure they know who they are communicating with and those entities are explicitly permitted to complete that transaction. Contrast this to perimeter-based security which allows transactions to take place simply because a communication was established. e.g., “If my firewall didn’t stop you, it must be OK for you to view this web page” or “I trust you because you have the right IP address.”

Now without getting into the weeds of a comparison between the two security architectures, let’s assume many of the points Don O’Neil (the author) makes in the article are valid. End-to-end security is arguably the most desirable security model and ZTA is probably one of the better ways to achieve it. However, I think we have a long way to go to get to ZTA in the OT world.

The issues abound, from ancient protocols with no notion of trust, to many operators’ desire to keep OT as simple as possible to minimize the risk of failure. Not to mention regulatory approaches (and resulting mindsets) with perimeter-based security baked in. NERC CIP Electronic Security Perimeters, anyone?

To be fair, O’Neil writes about evolving OT to ZTA and acknowledges many of these issues in the article. I’m a little worried, however, that the only folks who really pick up on those details are the ones who already understand how tall those hurdles really are. We need more articles like O’Neil’s to get us beyond perimeters and build security directly into OT systems . This would greatly reduce the impact of a perimeter getting breached -something that keeps many of us in the OT world awake any night…

Does moving to ZTA mean all of those perimeters will go away? Perhaps with some of the use cases that carry less risk, but in many situations defense-in-depth rules the day, so the ZTA and perimeters will need to co-exist.