By Roman Arutyunov, Xage Cofounder and Head of Product

A recently disclosed vulnerability (CVE-2022-38773) in Siemens Programmable Logic Controllers (PLCs) highlights the increasing attack surface for operational technology (OT) and the need for Zero Trust approaches to securing access to these critical assets.

The vulnerability affects Siemens Simatic and Siplus S7-1500 CPUs, and has caused a stir partly due to the fact that it has some traits in common with the vulnerability that was exploited in the famous Stuxnet attack on Iranian nuclear facilities. The key concern is that the vulnerability is in the Root of Trust implementation, and is baked into the hardware of affected devices. Thus, it cannot be fixed with a software patch. An attacker with access to a vulnerable device could load it with maliciously modified firmware that would be bootable, and would allow the adversary to get around security features supposed to be built into the operating system.

PLCs are intended to last a long time, so a hardware bug with this level of risk introduces an unfortunate challenge: critical infrastructure operators must either replace hardware that could otherwise continue to operate well for years to come, or they must find some way of securing it that does not rely on a software or hardware update.

Siemens has responded to the disclosure by noting that exploiting the vulnerability would require physical access to the PLC in question. This is a flawed claim that we’ll address in a moment. Their recommended solution is to shore up physical security measures at sites with affected devices. Siemens also noted that they have produced new versions of the hardware that does not include this vulnerability, and encouraged operators to replace the existing hardware with more secure versions. 

Neither replacing the hardware nor boosting physical security measures is a viable or adequate option for addressing this vulnerability. Hardware replacements are a costly and difficult process, often requiring production shutdowns. Replacing PLCs more often than necessary violates a core tenet of the OT mindset, which is to design for high availability and to avoid unnecessary shutdowns. Furthermore, replacing hardware offers no guarantees against future vulnerabilities in the new hardware.

Boosting physical security at affected sites may be a good idea, but it also won’t stop attackers from finding a way to exploit the vulnerability. Let’s explore why this is the case.

Why Shoring Up Physical Security Won’t Protect You From Siemens PLC Vulnerabilities

The requirement of physical access to exploit a vulnerability was present in the Stuxnet scenario as well. As always, threat actors found a way. In that case, they were able to sneak malware loaded onto USB sticks into the environment. 

That was over a decade ago, and a lot has changed. 

Today, more than ever, critical infrastructure organizations have a dire need for access control. Gone are the days of the true airgap, but the tools for true secure access control to OT are not widely adopted yet. This often results in the proliferation of overprivileged, undermanaged administrative accounts, overly permissive firewall rules and open ports, and limited to no control over which users are executing which actions, especially in the deepest layers of the Purdue model. Furthermore, many organizations lack the ability to monitor or control the transmission of data into or within their environment, either from users to machines, or laterally between devices in the OT network. This leaves wide open the possibility of locally or remotely compromising a single PLC and then laterally transmitting tampered firmware to many other devices within the environment.

Once an adversary has loaded malware into a PLC, their next goal is to move laterally into other vulnerable devices in the same environment. This puts a spotlight on a key question for anyone responsible for OT security:

• How are we controlling and monitoring user-to-machine and machine-to-machine interactions within our OT environment?

The answer to this question can make the difference in whether or not your organization experiences a data breach or down time as a result of an attack. Stopping an attacker from expanding their footprint beyond a single device can save your organization millions.  

Critical Infrastructure Operators Need Zero Trust Access Control Built for Operational Technology To Protect Critical Assets

This Siemens PLC vulnerability is not the first of its kind, nor will it be the last. Neither replacing the hardware every few years, nor increasing physical security are good enough solutions. To secure critical assets against exploitation of this and other vulnerabilities, access control for OT needs a few key characteristics:

• Overlay, not rip and replace: Access control for OT must be able to be installed and be fully effective without requiring you to replace gear that is built to last for decades.
• No agents or clients: OT involves many embedded devices running custom firmware, so installing agents isn’t an option.
• Highly available mesh architecture: OT needs to be able to trust that their access control solution will continue to enforce access policies locally even if network connectivity is intermittent. This is difficult or impossible to achieve with IT-centric tools.
• Control Machine-to-Machine interactions, not just user-to-machine: Even if attackers compromise a single device, it is critically important to stop them from moving laterally and propagating malware from the first machine into the rest of the environment. This is achieved with zero trust access control for all machine-to-machine interactions.
• Granular per user and asset control of data transfer into and within OT: To stop adversaries from delivering or propagating tampered firmware in your environment, you need zero trust-based control of who can transmit data into not just your environment, but the actual asset (such as the PLC), with granular control for when they can do so, what they can transmit, and which assets they can transmit data to.
• On-demand access revocation: If an individual device is compromised, you need to immediately isolate it and prevent further communications between it and other devices to prevent lateral movement and halt the attacker’s progress.

If you are responsible for OT security at a critical infrastructure organization, and are investigating how to secure your environment against exploitation of CVE-2022-38773, check out our white paper on Zero Trust Access Management for Industrial Enterprises and Operations.