Cyber Threats
Experimental analysis of smart factories Part 3
Part three describes the usage of Industrial IoT (IIoT) devices and overlooked security risks in software supply chains. Let's look at what points users should be aware of based on the experimental results.
Save to Folio
Previous posts
On May 11, 2020, Trend Micro released a paper showing the results of proof-of-concept research on new security risks associated with smart factories. In this series of 5 columns, based on the results of this research, we will look at the security risks to be aware of when promoting smart factories by examining overlooked attack vectors, feasible attack scenarios, and recommended defense strategies. This column describes the usage of Industrial IoT (IIoT) devices and overlooked security risks in software supply chains. Let's look at what points users should be aware of based on the experimental results.
Industrial IoT (IIoT) devices are the new norm
IoT devices are being incorporated more and more into smart factories. IoT devices are endpoints that have a unique IP address and that can connect to the Internet; they are expected to be used for various purposes not only in development but also in production environments, in combination with original programs developed in-house as well as other physical devices. There are various brands of IIoT devices on the market, such as Arduino Industrial 101, Industrial Shields, Industrino, and Iono Arduino. Notably, Arduino now offers a Pro line especially for industry. Also, customizable small single board computers such as the Raspberry Pi are becoming more popular because of their flexibility and cost efficiency.
<Photo 1> Industrial IoT devices：Iono Arduino (left)、Industrial Shields (right)
Software development with libraries
Development flexibility is the greatest strength of IoT devices. IoT devices are customizable, enabling developers to rewrite the devices' firmware to suit their needs. For example, you can easily build your own temperature sensor with off-the-shelf components and incorporate a library that includes a driver for the sensor into the firmware in order to create a smart sensor for monitoring temperatures on a factory line. In this research, we interviewed about 20 developers, many of whom replied that they use IIoT devices with customized firmware in their plants. Customized IoT devices are very common nowadays, and more will be implemented in the future.
Though developers customize their IoT devices, it is rare to write everything from scratch. When customizing IoT devices, developers often use libraries. A library is a collection of programing parts that helps developers greatly reduce their coding efforts. Industrial manufacturers and third-party communities provide numerous libraries via cloud services. Advanced developers frequently use and create free, open source libraries.
Security risks in software supply chains
Meanwhile, there is growing interest in security risks related to IoT devices. The NASA Jet Propulsion Laboratory (JPL) case in 2019 is a prominent example of an IoT device that became an intrusion point (for the details of the case, see this article). Today, many users are aware that policy setting and management are needed to prevent IoT devices from becoming shadow devices when doing IoT device deployments. However, this is not the only potential security risk related to IoT devices in smart factories. Critical security risks also lurk in complex software supply chains. As mentioned above, libraries are used to develop IoT devices, but the problem is where the developers download the libraries from, and who can interfere in that process.
The modern embedded-development ecosystem is very large and complex, providing some legitimate libraries from device manufacturers and some written by the community. Also, there are many resources, tutorials, and libraries that developers use for their own development. In addition, developers tend to decompose libraries, make some changes, and re-share them publicly. Moreover, highly skilled developers do not rely on official IDEs and prefer multi-framework alternatives such as PlatformIO, which is an advanced development environment that offers over 7,000 libraries and allows anyone to upload and download libraries. However, the security measures implemented in this open community are limited to the level that the library must be downloaded via HTTPS; there is no way to verify the integrity of the repository or code. In other words, there is no way to detect whether the source repository that hosts the library is at risk, or if it contains the original code that the developer wrote.
What happens if an unauthorized or trojanized library is used and becomes included in the firmware of an IoT device as shown in Attack Scenario 1? Let's take a look at the attack scenario that we verified in this research.
Attack scenario: Trojanized libraries for Industrial IoT devices
In this experiment, a custom IoT device with a temperature sensor (Photo 2) was operated in the research environment. The role of this IoT device is to monitor the temperature of the production line in real time and send the data to the cloud. If the sensor measures an abnormal value, the controller on the cloud issues an alert, and in the case of extreme conditions, it can stop the line. Photo 3 shows the temperature display when this automation process is working properly.
<Photo 2> Customizable Industrial IoT device used in this research
<Photo 3> Customized firmware for the IIoT device (left), the temperature display (right)
Note the code enclosed in the red frame in Photo 3. The comment indicates that we are using a library function to read sensor data. In this research, in order to show the effects of a trojanized IoT firmware, we emulated an attacker who has altered the library. While the code written by our developer in Photo 4 is exactly the same as that in Photo 3, the trojanized library is being included, but we do not notice any difference unless we have proper checks in place. The tricky part of this attack is that it is merely changing the content inside the library, so the code does not look suspicious at all. As a result, a warning was issued because the IIoT device reported abnormal values, which led to a situation in which the production line stopped. It is difficult for developers to determine whether or not the library is trojanized unless they inspect every single library and the entire dependency tree.
<Photo 4> The firmware with the trojanized library (left), the display showing abnormal values (right)
Countermeasures: Manage software supply chains
The best defensive approach is to visualize and manage the software and its supply chain used in customized IIoT devices. However, there are so many companies and developers in these supply chains, and it is becoming more difficult to get complete visibility into software supply chains as manufacturing processes get smarter (Fig.1). In such an environment, security measures based on the concept of zero trust are effective; therefore, it is necessary to take measures not only for perimeter defense but also to minimize damage when the plant is penetrated. Specifically, it is possible to segment the factory network and install equipment that can detect anomalies on the network. It is also important to share the security policy not only within the company but also with the developers at external partners, and to set restrictions such as using only libraries from legitimate services.
<Fig.1> Complex development and software supply chains
In the next post, we will examine the 3rd attack scenario, "MES database compromises."