Last week at the Singapore CSA OTCEP event a panel I was on received the question: what do we think about the use of zero trust in OT? I’m not sure why we all hesitated to answer. Being polite? Unsure of how to answer? Tired from jet lag or crazy time zones?

I can’t answer for the other three panelists, but for me it’s hard to talk about a zero trust security principle in OT when there seems to be no appetite for adding basic authentication in PLCs, Controllers and other Purdue Level 1 devices (hereinafter called PLCs).

PLCs and the protocols that communicate with them, turn the meaning of zero trust on its head. These devices, with few exceptions, truly have zero implementation of zero trust. They trust everything without authenticating the source or data integrity of a request packet or command. They suffer from the problem we have labeled, “insecure by design”. There are no security controls to overcome. There is no need to find and exploit a vulnerability. Access = compromise with the compromise limited by the connected actuators/physical system capability and the attackers automation and engineering skill.

The control commands are accepted and acted on without authentication. Want to turn something off? Make it rotate faster? Lower the temperature? Just send the request in the proper format and the PLC will send the command to the actuator without regard to who or what sent the command. It’s not zero trust. It’s total trust or trust all.

In many cases engineering and administrative commands are also accepted without authentication if they are formatted properly. Change the IP address? Change the program logic or recipe? Even upload new firmware? A minority of Level 1 devices require authentication for these functions, and a smaller amount support additional security features such as signed firmware, secure boot and encrypted communication. It is however a smaller minority that require authentication than the documentation would indicate, as it is common that this authentication can be subverted by back doors or an undocumented vendor “maintenance interface”.

This fundamental issue not only still exists, but it is still viewed by most as an issue that is impossible to address. As I pointed out in last week’s article, the US Government has been publishing a steady stream of lists of requirements for securing critical ICS. In all this numerous and conflicting advice, not once have they suggested, let alone required, that the PLCs require authentication. Even though getting the PLC to issue a false command, report false data, or be unavailable to monitor or control the process is often the ultimate goal of the attacker.

Instead the US Government puts out laundry lists of good practice security controls of varying quality, the latest TSA list being particularly bad for pipeline security. When will those that are looked to for authoritative guidance or regulation finally state that asset owners must have a plan to end the trust all posture of PLCs? There are actually some solutions available now, but the uptake has been minimal because it is seemingly more important to implement a good practice security control that has almost no impact on risk but helps one be more cyber hygienic.

Until the insecure by design / trust all issue in PLCs is highlighted and a plan to move past it is recommended (or even better required), I can’t get too excited about the zero trust term or conversation in OT. It is too painful of a reminder that the community, including and especially me, have failed to address this cornerstone security deficiency.

Fighting buzzwords and terminology is most often a waste of time after they reach critical mass as zero trust has. So this question at OTCEP has helped me form an answer. The answer will vary based on the network and question, but the answer will always begin …

Before we talk about zero trust, we have to realize that the most critical part of our ICS, the PLCs and controllers, almost all have a total trust or trust all security principle and adding basic authentication in these devices needs to be prioritized in your systems.


All that being said, I do think that software defined networks (SDN) and other restrictions on East / West communications in the Levels 1 and 2 are potentially valuable technologies, at the right point in an asset owner’s OT security program. It’s why one of the four 301-Level Autobahn training program sessions is on SDN in OT.