Chances are, this isn’t the first article you’re reading about Zero Trust. Chances are also that articles you have seen vary greatly in what Zero Trust means and does. Zero Trust isn’t a clearly defined IEEE standard, nor was there ever an RFC written about it. Each vendor seems to take artistic liberties to match their focus, which makes it a very fluid conversation.
What should it do? What problems should it solve? Most people agree, per the name, that Zero Trust somehow switches the mentality of the network from allowing access by default, to blocking access by default unless explicitly required. A lofty goal, but what does it really imply, and how does this apply to industrial control systems and critical infrastructure?
Context is Important for Zero Trust Policies
In essence, Zero Trust is a framework that disallows connectivity by assuming there is risk unless proven otherwise. Rather than simply defining a minimalist access policy, security posture and context can play a role in improving Zero Trust security. This helps significantly reduce risk by making more informed decisions about connectivity.
A Zero Trust architecture, prior to allowing a machine or user to connect to the network, should always verify whether that connection can be made safely. Furthermore, that connection should be established to the minimum number of resources that it needs. These checks should be done on a per-session basis instead of once-off at the start.
Incorporating context into Zero Trust policy decisions stands in stark contrast to the usual allowlist approach of Zero Trust implementations. The initial user verification process shouldn’t just be credentials, even if more advanced controls like 2FA are in place. Obviously, identity is an important verification step, but it doesn’t help assess whether the connection can be made safely and should be allowed, especially if the device has been compromised. We should be asking specific questions based on metrics that allow better-quality decision to be made in real-time, such as:
- Where is the connection coming from?
- Is there an indication that the machine used to connect is compromised?
- Are there any vulnerabilities that introduce risk to the rest of the network?
- What is the history of communication between these systems or is it a new connection?
Particularly in IT infrastructure, there is substantial movement toward adopting a Zero Trust framework. Networks are being “micro-segmented.” VPN remote access is evolving to something more advanced and more granular. User Agents are deployed on workstations to obtain more information about its security posture and so forth.
These are all developments with tons of value for IT infrastructure, but how do you do this in OT/IoT infrastructure? What can you do to adopt the same benefits for industrial control systems, cyber-physical devices, and critical infrastructure?
Zero Trust for OT/IoT and Industrial Control Systems
Does micro-segmentation make sense for OT? Aside from the technical challenges of implementation, what if traffic is blocked? What impact will that have on the process? In IT, it’s normal and even highly desirable to block traffic when it’s suspected of being malicious, but in OT this is risky. Simply blocking it might just impact production as much or more than allowing that traffic.
What about User Agents? Many OT or IoT devices like controllers, sensors, robots, and so forth are headless. There’s no option to put software on them, especially if they are streamlined, single-purpose processors that don’t run a full-featured operating system. Very often, security wasn’t a consideration when these products were developed. Now pair all of this with digital transformation in OT and we have a perfect storm on our hands.
So, what can you do for OT and where do you start? To make better-quality decisions about connectivity, you need to understand what you’re trying to protect. This is identical to IT, but the methods of getting there differ.
“Understanding” isn’t just about MAC addresses, IP addresses or ports. This is about knowing the type of devices, what their expected behavior is, and what hardware and software is used. This is about knowing how the entire OT environment behaves. Which machine speaks to which other machine(s)? With what protocol? What payload is exchanged? At what frequency?
If you understand this in real-time, you’re well on your way toward an optimal Zero Trust for OT/IoT environments.
Decision Time to Maximize Security
Gathering information must lead somewhere. Without it, the effort is pointless so it should be converted into actionable intelligence and ultimately actions. Knowing hardware and software versions will lead to knowing what vulnerabilities apply to those monitored devices, whether those devices are even still supported by their vendors, and how they should act on the network. Now that is relevant.
Knowing the behavior of entire OT/IoT networks also includes the ability to detect and alert upon anomalies. If devices that never communicated with one another suddenly start doing so, or if they have previously communicated but are now displaying different behavior, it justifies investigation into their legitimacy. It’s very possible that this is the start of a breach.
Elaborating a bit on actionable intelligence, the data gathered toward Zero Trust shouldn’t just be a few lines stating what the issue likely is. It should help determine what impact it has to the OT network when addressed. For example, fixing vulnerabilities can be quite an undertaking—how does that improve security posture compared to the effort required? This is quantifiable information to make an informed decision about moving forward with patching.
There IS OT in ZerO Trust!
With regards to Zero Trust policy enforcement, even in OT and IoT, sometimes it’s justified to automate interventions by blocking traffic. The suite of tools that form the cyber defense mechanism should all play nice and exchange information to act as fast as possible so each can fulfill its function effectively.
