ADDRESSING RISKS IN INDUSTRIAL CONTROL SYSTEMS AT THE FIELD LEVEL

When we look at the field level in more depth, the two primary points that present risk to the ICS are remote field sensors and IO modules. At stake are uptime, predictable maintenance, and overall industry efficiency: the cornerstones of IIoT.

 The Risks with Remote Field Sensors

Physical security of all sensors may not always be possible, especially when the sensor is very remote like those used to monitor oil and natural gas fields. Inaccessibility further makes sensors vulnerable to physical attacks, so it is essential to authenticate all sensors before their data is accepted. However, in most cases, our field sensors, even those used in critical infrastructure systems, are both open and trusted. This vulnerability of our field sensors has not gone unnoticed.

In 2014, the well-known Black Hat conference featured a paper by Russian researchers who conclude that attacking an enterprise system directly is too much trouble. Instead, they concocted and describe a “Man in the Middle” attack by spoofing and replacing an open and trusted HART modem-based field sensor.3 They describe the process in detail and even make the software libraries available for download.

Our focus on secure systems for IIoT must begin with a trusted sensor that is sending the data to the cloud or the PLC. The implications of a security breach on these remote devices can be profound.

 The Risks with IO Modules

Another way to get access to an open trusted system is using cloned IO modules to deliver malware. Factory owners are used to replacing IO modules within their PLCs. There have been cases in Asia where cloned IO modules (with a fake corporate logo of some of the top automation vendors) are available in the market. Again, since this is a trusted system with traditionally little to no embedded security, it can be an effective vehicle for delivering malware to the main PLC CPU. Physical security (making sure that PLC system updates are limited to a select set of people) can deter this, but keep in mind this does not need to be a malicious act. You might not even know whether this is a cloned or fake IO module.

 Implementing Hardware Authentication with a Field Sensor

A systems solution for the potential risks described can be simple: if you are going to trust the data from a slave subsystem, the data must be authenticated. There is a simple embedded hardware approach to keeping these kinds of trusted systems secure. An authentication scheme was instituted years ago for medical and consumer products such as printer cartridges. These systems traditionally employ a standards-based authentication process, using a custom secure device.

This authentication scheme is based on the challenge-response exchange between the host and the slave device (Fig. 4). The host system sends a challenge used by the slave system to compute a response. This response is validated by the host system to make sure the slave system is not cloned or counterfeit. Only after validation will the host communicate with the slave system.

A simple conceptual block diagram of a hardware-based authentication scheme similar to the symmetric SHA-256 algorithm is shown in Fig. 5.

The SHA-256 protocol, based on a challenge-and-response exchange between authorized devices, will authenticate the sensor before its data is accepted and read. SHA-256 authentication makes it almost impossible for an attacker to connect to a network, to pretend to be a sensor, or even to replace the senor system with a compromised system, unless they have an identical authentication device with the same programmed-in private key.

Vendors such as Maxim Integrated will provide the key programming service at a U.S. stateside facility, then ship a programmed authentication device to you. This device will have a unique key that is known only to you. The devices that store the key are tamper-proof with a range of active and passive tamper protections built-in.

Fig. 4. Authenticating the Slave Module: Can be used with both a field sensor and an IO module
Fig. 4. Authenticating the Slave Module: Can be used with both a field sensor and an IO module
Fig. 5. Sensor authentication with SHA-256 (private key)
Fig. 5. Sensor authentication with SHA-256 (private key)

THE RISKS WITH PLC CPU AND SOLUTIONS

What controls your plant or process is the PLC and the main CPU that is running all the control algorithms. But these systems were never designed to withstand security attacks and breaches. Hence, once these systems are connected online, there are many ways to compromise the main CPU of the PLC. Some of the attack surfaces can be applications software, OS, or hardware, but the most vulnerable surface is the firmware. If the firmware can be modified or infected, any change due to malware is not only hard to detect, but also if it is found, it is very difficult to ascertain the intention or purpose behind it.

SHARE YOUR THOUGHTS & COMMENTS

Please enter your comment!
Please enter your name here