In 2014, the well-known Black Hat conference featured a paper by Russian researchers who concluded that attacking an enterprise system directly is too much trouble. Instead, they concocted and described a ‘Man in the Middle’ attack by spoofing and replacing an open and trusted HART modem based field sensor. They have described the process in detail and even made the software libraries available for download.
Focus on secure systems for the IIoT must begin with a trusted sensor that is sending data to the Cloud or the PLC. Implications of a security breach on these remote devices can be profound.
Risks with I/O modules.
Another way to get access to an open trusted system is by using cloned I/O modules to deliver malware. Factory owners are used to replacing I/O modules within their PLCs. There have been cases in Asia where cloned I/O 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 that this does not need to be a malicious act. You might not even know whether this is a cloned or a fake I/O 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 sub-system, 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 many 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 counterfeited. Only after validation does 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 authorised devices, authenticates 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 to replace the sensor system with a compromised system, unless the hacker has an identical authentication device with the same programmed-in private key.
Vendors provide the key programming service at an American facility and then ship a programmed authentication device to you. This device has a unique key that is known only to you. Devices that store the key are tamper-proof with a range of active and passive tamper protections built-in.
Risks with PLCs, CPUs and solutions
What controls your plant or process is the PLC and the main CPU that is running all control algorithms. But these systems are 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, operating systems or hardware, but the most vulnerable surface is firmware. If the firmware can be modified or infected, any change due to malware is not only hard to detect but also, if found, is very difficult to ascertain the intention or purpose behind it.
Most PLCs lack source and data authentication on firmware uploads. Some PLCs even lack checksums for validating the correct transfer of the firmware. If the attacker can modify the PLC firmware, he or she can:
• Take complete control over the infected system
• Learn about the production process
• Selectively sabotage the manufacturing operation (aka Stuxnet)
• Propagate to the enterprise from a trusted manufacturing system
Not everyone wants to take control of your system to destroy your plant. The risks can be more subtle. There is a lot of intellectual property embedded in a manufacturing setup, and sometimes the intent is merely to get this intellectual property. This kind of malware will not manifest itself by creating problems in your manufacturing setup.
