Industrial IoT (IIoT) is at the heart of Industry 4.0, facilitating easy connectivity for harnessing and interpreting data, which in turn helps manufacturers tailor their predictive maintenance programmes for greater efficiency.
However, with so many systems and devices in different networks, security is becoming a growing concern. There are various motivations for cyberattacks, some focus on data theft (to acquire industrially-sensitive information), and others causing damage by disabling equipment and halting industrial processes.
But, how?
Any device connected to the Internet is in effect open to cyberattacks. If it still uses its factory-fitted usernames and passwords, it may as well have no security at all. For example, Mirai, a self-propagating botnet (a.k.a. Zombie), attacks poorly-protected systems using telnet, to find devices with their default settings. If these devices are across multiple locations, the botnet instructs them to perform a distributed denial of service (DDoS) attack against their server.
In many cases, however, there’s no need to use these settings, since there’s another entry point – through data transmitted to the device. One common attack is through a forced memory buffer overflow. The malicious programme writes data to the device’s memory reserved for runtime activities. It sends data larger than what the device expects to receive (figure 1), so the excess overflows into other memory space, to overwrite the machine code that governs the system’s behaviour. If the overflow data is something like a new return address, a different part of the program will execute next. This might be a legitimate function, such as the restoration of factory settings (including default passwords), or the hacker can simply set a new password. Either way, the hacker gains access to the system yet the legitimate user has been denied.
Figure 1
A more severe attack involves a shellcode that alters the device’s behaviour. This might be to reveal the password set by the system’s legitimate user, or to reveal the device’s password to get on to the local network and communicate with other devices. Most of the time, the legitimate users have no idea the device has been compromised.
Hackers may know where to send the overflow data for off-the-shelf devices, since they can easily reverse-engineer them to establish their memory map.
Adding protection
Typically, for IoT devices, programs are written in a low-level language like C. So, an obvious way to start protecting them against memory buffer overflow attacks is to program them using C# or Java, for example. In addition, use an operating system for memory management, or a dedicated memory management unit (MMU), which will protect certain areas of the device’s memory (declared as Read Only, for example) during runtime.
An IIoT device can also be attacked through its application program interface (API). Many devices use a representational state transfer (REST) based API, called RESTful. Such APIs are popular since they do not require much bandwidth, can be crafted in Python or JavaScript, and use HTTP to communicate with the cloud. This means data can be created, updated, read or deleted.
The use of any REST-based API presents certain cyber challenges. These can be addressed through better authentication for access control, blocking certain payloads (size and/or type that is not expected) and access from unknown IP addresses and domains. If the IIoT-based device is just one of few that is part of a well-conceived OT system, none of these solutions should prove too difficult to implement.
Starting early
Traditionally, security considerations have always come late during product development, sometimes as late as at the prototyping phase. That must change. Security must be considered when specifying a device’s requirements. Its intended length of service in the field, the importance of what it does and the data it provides/receives will govern the measures to take.
Let’s assume high security is required and, say, end-to-end communications. An important element is the device’s identity: How trustworthy is it? Is static data encrypted on the device? Should/can data in transit be encrypted to thwart ‘man-in-middle’ interceptions?
Thankfully, microcontroller OEMs are producing some great ICs geared for high-security IoT life. Microchip Technology’s CryptoAuthentication family of devices, for example, work alongside the microcontroller or microprocessor within an IoT-enabled devices. Security features include a unique and non-changeable 72-bit serial number (set by Microchip), a 512-bit one-time programmable (OTP) zone, a random number generator and a SHA-256 hash algorithm for data encryption. The ICs also include APIs for storing, retrieving and manipulating X.509 certificates for transport layer security (TLS) integration. Hence, for a server communicating with multiple IIoT-enabled devices, the end-to-end communications link can be made far more secure through unique IDs and encrypting transferred data.
IIoT in Industry 4.0
In IIoT settings, there’s something called the Purdue Model (Figure 2), which reflects the hierarchy of IT and OT system elements, and comprises six layers:
Level 5 = corporate network systems;
Level 4 = IT systems for business logistics (includes databases and servers);
Level 3 = systems for site-wide monitoring and control;
Level 2 = control systems such as HMIs and SCADA software;
Level 1 = basic control devices such a programmable logic controllers;
Level 0 = sensors, actuators, motors and pumps etc.
Figure 2
The purpose of the Purdue architecture is to assure safe control, where safety and security go hand-in-hand. Within the enterprise zone, historically it was only the enterprise network that had access to the Internet and, thus, the outside world. Malware hitting IT equipment at levels 5 or 4 should not be able to affect anything at level 3 or below because of the firewalled zone.
Today, many OT devices in the manufacturing zone are IoT-enabled. Smart sensors and controllers, along with edge-processing systems, are connected to the Internet. Data no longer flows between the Purdue Model levels.
There are mixed views in the industry whether the Purdue Model needs to be replaced or enhanced in light of the increased use of IIoT within the manufacturing zone. Hence, it is important to perform a risk analysis on any IIoT device relative to its level in the Purdue model, and whether it is playing a role in monitoring and controlling, or both.
This article appeared in the December 2021/ January 2022 issue of Electronics World magazine. It appeared in print, is online and is reproduced on our site with the editor’s kind permission here.
