The process sensor ecosystem is not cyber secure and can cause catastrophic damage

I have written extensively about the lack of cyber security and authentication in Purdue Reference Model Level 0,1 devices (process sensors, actuators, drives, etc.) This is more than just a process sensor problem but a sensor ecosystem problem that can unintentionally affect operation as well as make processes susceptible to cyber attacks. The sensor ecosystem consists of sensors, sensor networks, alarm management, device management, etc. Sensors are the input to every process and the raw sensor data is instinctively trusted. IOT, Industry4.0, and digital transformation all assume the sensor ecosystem is uncompromised, authenticated, and correct which generally is not true. The worst thing a measurement device can do is provide misinformation. Misinformation can cause minor problems like operating at a sub optimum state or major catastrophic failures. Even operating at a sub optimum state can have significant consequences such as loss of income and/or accelerated wear or degradation. Unfortunately, many of these problems are not noticed or tied to a specific cause. Problems with device management based on cyber security deficiencies are a common cause of operating issues.

Many people think of cyber security as a threat from an external source such as a foreign government with destructive motives. This is certainly a valid threat, but the most common source of cyber security problems are internal threats with no bad motives. Unintentional process sensor issues are simply unmanaged risks that go wrong by random chance or lack of attention. Examples of unintentional sensor issues that caused catastrophic events include the Texas City refinery explosion, the Buncefield tank farm explosion, the Three Mile Island nuclear plant core melt, and the wrong (i.e., "frozen") power measurements that almost caused a major blackout in Europe in January 2019. In fact, a study at a refinery in Japan found that field-related issues, which were typically instrument failure or improper ranging of scale, resulted in almost 50% of the nuisance alarms. Intentional cyber attacks that targeted sensor systems included Stuxent and Triton with the intent to mislead operators. Consequently, both unintentional and malicious cyber attacks must be managed to be able to claim that risks are being managed. Risk management is both a moral and legal obligation.

In preparation for a ISA84 (Safety Integrated Systems) task on cyber securing control system field devices, Herman Storey, Simon Clarke, and myself came up an initial list of field device and networking issues that need to be addressed to provide for management of cyber-related risk. It is not short or simple. The problem is complex and poorly understood, but can be manageable. Some technical developments would greatly simplify the management problem, and these are also identified. Some technical developments must await the next generation of network technology and some can be applied to the existing installed base of devices. However, blindly applying IT/OT cyber security policies, procedures, and technologies can prevent a control system device from functioning or even shut it down – the intent of the hackers. As these are device as well as network issues, OT AND engineering need to be involved. It should also be evident that many of these issues are not what would be considered “OT”. Moreover, the issues identified affect alarm management (ISA18), process reliability and safety (ISA84), cyber security (ISA99), wireless (ISA100), and device management (ISA108).

Device/network level issues:

As a general rule, devices and device networks have no authentication and authorization. In wireless networks, devices are authenticated for some host communications, but not users. Since users are not authenticated, access control is incomplete at best. In safety networks only the application on a device is authenticated, but not the device itself.
In all field networks, backdoors are open for unlimited access. The backdoor is necessary for many functions that are not possible without the backdoor. That is, the backdoor is a design feature like the hardcoded default passwords in many PLCs. The backdoor is needed for provisioning, commissioning, calibration, troubleshooting, factory and shop work, etc.
The networks do not support 3-way conversations between a device, a portable tool such as a handheld calibrator using the backdoor, and a host system that could monitor and archive changes. A portable tool cannot log in to a host system and use host resources.
The back doors are necessary for many host subsystems (like safety logic solvers) as well as field devices. Some of these subsystems can provide some protection for the backdoor, but the protection is easy to bypass if improper work processes are used in the field. Moreover safety logic solvers can use non-SIS transmitters and non-SIS HMIs, especially with integrated control and safety systems.
Good field work processes involve people not trained in cyber security. Good work processes are remarkably rare as is good understanding of issues.
Many of the issues with device and network level security cannot be solved at the device level and would require enhancements to network protocols to address. These types of revisions are not in progress for existing tools, devices and networks.
The problems with network and device level security exist in all device level protocols including safety protocols.
New network protocols are under development that will address at least some of these issues. It is not clear that the back-door issues are being solved.
The new protocol developments currently under way will not be useful for solving problems with the current installed base of instrumentation.
Smart transmitters require two-way communication

Perimeter security issues:

The means to establish a secure perimeter is not supported by common tools and work processes. Perimeter security is technically feasible for the current installed base of field devices. But some tool enhancements and improved work processes are necessary.
The perimeter includes all systems and portable tools that are connected to a device at any time in the life of the device. The device itself and any software or tools used with the device must come from a trusted and authenticated source.
Many portable tools in common use do not have provision for security enforcement. Some systems have security support.
All systems and tools that communicate with devices need metadata files from the Internet to be able to communicate with a device. Secure means for obtaining these files and installing them in portable tools and host systems have traditionally been poor or nonexistent. The security perimeter does include Internet access for tools and systems. The need to communicate directly via the Internet goes against most cyber security guidelines but is necessary for the device to work – a conundrum.
Since there is no device or network security, physical security is necessary. Physical security is not practical in some environments where these devices are used. Even in physically secured environments, it is common to have contract personnel with uncertain skills and motives with easy physical access to devices and even to have these people assigned to perform work on devices using unsecured tools and poor work processes. Perimeter security depends on physical access restrictions through good work processes and procedures, and on good supervision by personnel that are aware of cyber security issues.
Architecture matters. It is common to have no network connection from a device to a host. Under this condition it is impossible to know if a device has been tampered with or what was done. It is difficult (impractical) to maintain current backups of device configuration, and it is also difficult to (or impossible) to manage configuration changes. Lack of a permanent network connection to a host makes perimeter security worse rather than better – assuming that the host itself is secured. An unsecured device with no permanent host connection is not secure. A permanent host connection can assist with perimeter security.

People/policy issues

Instrument engineers/technicians are general not part of any cyber security team and that has to change.
Cyber security guidelines generally do not include Purdue reference Model Level 0,1 devices and networks as they focus on the IP networks and that has to change.
Network Operation Centers (NOCs)/Security Operations Center (SOCs) generally cannot detect instrumentation issues. Conversely, control room displays generally cannot identify cyber security issues. These functions and personnel need to be integrated.
Sensor forensics may exist but are generally not used to maintain sensor isolation. Out-of-band sensor monitoring is needed to maintain process safety.
As identified in https://www.controlglobal.com/blogs/unfettered/the-ultimate-control-system-cyber-security-nightmare-using-process-transmitters-as-trojan-horses/, counterfeit transmitters have been identified and need to be addressed.

Ironically, cs2ai.org is having a webinar Thursday June 27^th on Triton. Triton is a problem, but not the only problem. In fact, the only way for Triton to be successful is to compromise the operator displays and suppress alarms. The field devices are in EVERY safety system from EVERY vendor and you don’t need to know the detailed software and networking to compromise a safety system. With Internet connectivity, no real cyber security, and no forensics, the field devices can be a much bigger problem than Triton.

Joe Weiss