zawada

Zero Trust Redux

Leave a Comment / Cybersecurity / By / January 14, 2022

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

Leave a Comment / Cybersecurity / By / December 2, 2021

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.

Containers in the OT Equipment Space

Leave a Comment / Platforms / By / November 30, 2021

The other day some utility industry colleagues and I discussed IT/OT convergence. The discussion included an exchange on the future of containers in the Operational Technology (OT) environment. I thought the topic would make for a good blog post. 

First, let’s define what we mean by the term “container.” In the information technology (IT) world, a container is the combination of a piece of software and all the executables, libraries, configuration files, and other dependencies that an application or server needs to function.   This “bundle of code” runs in a protected environment such that the software running in one container cannot directly impact software running in a different container. 

By bundling all application components together and not relying on similar functions and code provided by an operating system, the software becomes relatively portable.  I can move it from one container platform to the next, and I don’t need to worry about the operating system version or what library (often called a DLL in the Microsoft Windows world) on the system might have been modified by installing another application.  I can run two different pieces of software that might require two different versions of the same library.  Since each container gets its own copy of the library, there’s no reason they both need to run the same version.

This concept is very close to virtualization, where multiple copies of an operating system may be running on a system, each as an independent “virtual machine” running its own set of applications or services.  The main distinction is that a machine supporting containers only has one copy of the operating system running.  Thus, it does not require the overhead of multiple virtual machines.  The most common implementations of containers are Docker and Kubernetes.

While containers are common in the IT world, what benefit would they bring to the OT world?  In a nutshell, they would allow more modularity of function in OT devices.  Many OT devices today run on what one might call “monolithic” software.  That is, from the operator’s point of view, the device runs a single firmware image.   If I want to upgrade a device to take advantage of a new feature or address a cyber vulnerability, I need to replace a single firmware image with a new one.  This means I now need to be concerned about what functions that previously worked fine may have had new bugs introduced in the latest version.  Most OT operators would probably prefer to have the option to upgrade only the software for that one function that needs to be added or upgraded.  However, with many OT devices today, that is not possible – the options are to either replace all of the software or none of it.

In recent years (decades?), we’ve seen a trend of many functions being combined into a single box.  For example, in the electric utility protection world, a relaying scheme made up of electromechanical relays that may have taken up the better part of an 8-ft panel now fits into a single microprocessor-based box that’s less than 6 inches tall.   And now, that 6-inch-tall box serves not only as a protection system, but also as a SCADA interface, Phasor Measurement Unit (PMU), digital fault recorder, and human-machine interface (HMI).  

As OT devices become more powerful, the consolidation trend will continue and (continuing our protection example) drive the combination of many panels, perhaps all of a single substation’s automation functions, into a single box.  (Or maybe two or three boxes for redundancy purposes.) However, many who might design that sort of configuration are wary of combining so many functions into a monolithic piece of software.   There are too many hidden interdependencies, and the risk of a single code modification affecting so many critical functions is too significant.  Containers offer a way to allow for consolidation (and resulting economies of scale) to continue at the hardware layer while increasing the separation of functions to reduce the risks at the software layer.  In the long run, this means OT operators will be able to implement greater functionality at a lower cost and the same or greater level of reliability.

Once functions are containerized, I can manage OT device functions individually and move to an operations model where choosing device functions becomes more like choosing apps on a smart phone.  Furthermore, hardware platforms may become less specialized and the cost to implement OT functions may drop lower. 

I expect containers will be a continuing theme on this blog.  Stay tuned…

What is Operational Technology? – An Opening Post

Leave a Comment / OT Boundaries / By / November 27, 2021

Since this is the very first post of this blog, I thought I would address the question of what Operational Technology (OT) is, since OT is at the core of what Syntonous is about.  Gartner defines OT as: 

“…hardware and software that detects or causes a change, through the direct monitoring and/or control of industrial equipment, assets, processes and events.” 

That’s a pretty good definition. Most folks think of OT as being related to critical infrastructure or manufacturing.  The actuators, sensors, and other interfaces between computing and physical infrastructure can be recognized as OT in most cases.

What varies are the extents to which the observer applies the OT label.  Some would say the OT label applies only the hardware closest to the process.  This would include, for example, the protective relaying device in a substation or the Programable Logic Controller (PLC) on the manufacturing floor.  In this view of OT, any use of traditional servers and databases is merely tight integration with IT and an example of IT/OT convergence.  Here, the Technology component is not necessarily “high tech” or digitized, it’s simply an advanced automated process.

In other circles, OT is not limited to the immediate vicinity of the industrial environment.  In this case, OT encompasses centralized back-office systems that coordinate the process(es) in the field.  Even though large portions of this form of OT may be running on IT infrastructure, that IT equipment is transformed into OT simply by virtue of being connected to the industrial process.  In an extreme case, back office OT might not even have connectivity to the devices in the field.  That information may be manually entered into an operator workstation.  In the example below, is OT limited to the magenta boxes, or is it the whole picture?  That depends on the organization and the experiences of the people involved. Neither answer is wrong – to a certain degree, OT is in the eye of the beholder.

Simple OT System

At the end of the day it doesn’t matter what portions of the system my department or your company considers to be OT as long as we both recognize that organizations may have different definitions.  Those differences need to be hashed out before incorrect assumptions are made about where the boundaries lie.