The Security Dilemma of Smart Factories | June 2021
The Security Dilemma of Smart Factories
Specificity of the programming languages used to move industrial robots
The Security Dilemma of Smart Factories | June 2021
Introduction
Industrial robots are the core of the automation of manufacturing processes in smart factories, and are the most important components as they support the manufacture of all kinds of products such as automobiles, aircraft, processed foods, and pharmaceuticals. In addition, as equipment that realizes unmanned manufacturing in the post-COVID-19 world where minimal or no contact is a necessity, the importance of industrial robots that can repeatedly execute specified movements with high accuracy is regaining attention. However, it is not commonly known that industrial robots are programmed using languages designed decades ago. Trend Micro has been conducting cybersecurity research on smart factories since 2017, and discovered vulnerabilities in "automation programs" that define the behavior of industrial robots and also design flaws in "programming languages". These languages are legacy languages that were designed decades ago, but they continue to be used for purposes such as maintaining compatibility with successor models and reducing the burden of re-learning, and are a technology that is still being used in modern smart factories. In this paper, based on the results of our third joint research project with the Polytechnic University of Milan, from a short to long-term perspective, we analyze the design security risks involved in legacy languages and risk mitigation measures that all users of industrial robots should take.
Industrial robots support factory automation
An industrial robot is a mechanical device that performs assembly work, transportation, processing, etc. inside a factory instead of humans (Photo.1). In today's world, where production that caters for business on a global scale is commonplace, it would be unthinkable to build a factory manufacturing process that does not involve industrial robots. Industrial robots, which can repeatedly perform precise work and reproduce flexible movements, are the basis of the automation of the manufacturing process. The demand for industrial robots is increasing significantly, even with the COVID-19 pandemic. According to a report by Fortune Business Insight, the global market size for industrial robots was about 21.83 Billion USD in 2019, and is expected to expand to 66.48 Billion USD by 2027. This increase in demand is believed to be due to soaring labor costs in Asian countries, which are the main production base regions, and continuous investment in automation for the purpose of improving productivity. In addition, the social demand for the realization of minimal or no physical contact and unmanned services brought about by the COVID-19 pandemic is presumed to be a major driver of the growing demand for industrial robots. Industrial robots, which play a central role in automation of the manufacturing process, will become even more important in the post-COVID-19 world.
Page 2 of 18| The Security Dilemma of Smart Factories
The Security Dilemma of Smart Factories | June 2021 Movements of industrial robots are defined programmatically
Now let's analyze industrial robots from the perspective of digital technology. Industrial robots are complex cyber- physical systems used in manufacturing and are key components of smart manufacturing systems. When you hear the word robot, usually the actuator part like an arm comes to mind first, but the actuator part does not move independently, its movements are defined by a program and controlled by a controller (Figure.1). Therefore, industrial robots do not move as desired immediately after being placed, but work the required movements are programmed. An industrial robot is, so to speak, a large computer with a section that operates physically.
Automation programs are written in proprietary languages
Trend Micro decided that it was worth conducting security research on the "automation programs" of industrial robots when it discovered a vulnerability in an application of heavy industry giant ABB in previous joint research with the Polytechnic University of Milan. The application was written in ABB's own programming language and researchers were unfamiliar with it. Automation programs that drive industrial robots are written in completely different languages than the mainstream programming languages that are used to create websites and mobile apps. "Task programs" that define the automation behavior of industrial robots are typically written by field experts using a programming language specific to each robot manufacturer. In addition, each robot manufacturer creates a manufacturer-specific ecosystem that only uses its own programming language, programming environment, and even tools. Let's look at examples of individual manufacturer's languages. Photo.2 is an example of a simple code written in the original language "KRL" of Kuka, a major heavy industry company. In this case, an industrial robot arm is instructed to move between two points (pos1 and pos2). Photo.3 also shows a pick-and-place program written for the ABB platform. You can see that each of them has a different language structure.
Page 3 of 18| The Security Dilemma of Smart Factories
The Security Dilemma of Smart Factories | June 2021
This means that in order to operate an industrial robot, it is necessary to learn the proprietary language developed by its manufacturer, and when introducing an industrial robot from a different manufacturer, it is necessary to learn that manufacturer’s proprietary language as well. Therefore, it can be said that the operation of industrial robots is an environment in which strong vendor lock-in must occur due to its technical structure. Furthermore, given the long product life of industrial robots and the fact that the languages were developed decades ago, the vulnerabilities in automated programs discovered in the previous study may have resulted from defects in the programming languages themselves. Based on this hypothesis, Trend Micro started this research with the aim of "understanding the root causes of vulnerabilities in automation programs and presenting risk mitigation methods."
This survey targeted eight major robot manufacturers
This survey targeted the platforms of eight companies that are leaders in the field of industrial robots. The target manufacturers were ABB, Comau, Denso Wave, FANUC, Kawasaki Heavy Industries, Kuka, Mitsubishi Electric, and Universal Robots. All of these manufacturers have long histories and have established trusted positions in the industry. Although Universal Robots is a recent entrant, it is worth noting that in addition to its own programming language, its control process engineers are leveraging mainstream languages such as Java and Python. In this study, we not only used empirical verification methods such as analysis of task programs including automation logic, but also considered technical documents of 8 major industrial robot platforms, analyzed information from 11 online forums, from a non-technical perspective, held interviews with 20 experts in the field of industrial robots. With this method, we aimed to force consideration of non-technical issues such as industry characteristics and development culture, which goes beyond the vulnerability analysis of specific programs. As a result, as well as raising the security awareness of control process engineers, it became clear that some vulnerabilities could be fixed more easily and effectively by redesigning the platform and performing major upgrades. This matter will be described later in this series. The fact that a technology itself is "legacy" does not mean that it immediately has security vulnerabilities. However, the security requirements and development process of each technology must change as threats evolve due to changes in the environment. What happens when technology developed according to the common sense of decades ago is incorporated into today's smart factories? This research clarifies the current positioning of cyber security in the industrial field through structural analysis of existing programming languages.
Page 4 of 18| The Security Dilemma of Smart Factories
The Security Dilemma of Smart Factories | June 2021
3 attack scenarios
Trend Micro verified around 100 task programs available from public code repositories (GitHub and online communities), and we could confirm the presence of vulnerabilities such as "defective input value verification," "lack of authentication functions," and "remote code execution" in most of the code. We have demonstrated three attack scenarios that exploit these vulnerabilities. These scenarios are:
1. Changing of robot operation via the network: By exploiting defective input value verification of the motion server and transmitting invalid coordinate value data via the network, robots are made to perform unintended operations. 2. Information theft via robots: Confidential information is stolen by launching a path traversal attack that exploits a vulnerability in a task program. 3. Targeted, self-spreading malware: These exploit the network communication functions and code dynamic loading functions inherent in programming languages to make task programs function as droppers that take in malicious programs from external sources. In addition, defective input value verification in task programs is exploited to cause industrial robots to execute functions corresponding to invalid external input. By combining these, self-spreading malware written in a programming language for industrial robots is generated and executed.
Cyber attackers with advanced technology are assumed
The attack scenarios presented in this paper are assumed to be feasible by highly skilled and budgeted cyber attackers targeting well-defined targets. The reason for this is the placement characteristics of the industrial robots that are the target of attacks over a network. Industrial robots are usually not directly connected to the Internet, instead they are located on a field network in a factory environment. As a result, external attackers inevitably go through many other IT and OT assets before they actually reach an industrial robot, and it takes a considerable amount of time and effort to complete such attacks, and obviously, the clear intention to attack. Therefore, it is reasonable to assume that the people who perform the attack scenarios presented in this paper are advanced attackers who are familiar with the specific facilities being targeted, including industrial robots. For reference, looking at recent security case studies targeting industrial control systems (ICS), it can be seen that highly-skilled attackers (or state-sponsored attackers) are prepared to spend a long time attacking specific targets. In addition, state-level attackers and other attackers have budgets of 2.2 to
Page 5 of 18| The Security Dilemma of Smart Factories
The Security Dilemma of Smart Factories | June 2021 27 million JPY (20,000 to 250,000 USD, equivalent to the price of a small lab facility) for experiments such as those used in this survey, and it is assumed that they have the used industrial robot systems installed.
Damage caused by attacks
Figure.3 shows the attack scenarios demonstrated in this study and the impacts of the attacks.
By exploiting the vulnerabilities in the task program identified in this study, cyber attackers could physically damage production lines, steal confidential information, or even steal money. For example, exploiting "Attack Scenario 1: Changing of robot operation via the network" could trigger incidents that can lead to reduced productivity, such as causing physical damage to manufacturing equipment. In addition, if you were an attacker aiming to steal information, you could use "Attack scenario 2: Information theft via robots" and "Attack scenario 3: Targeted and self-spreading malware" in combination to obtain confidential information from a factory environment, and use it as a hostage to extract or demand money from the factory. As mentioned above, the vulnerabilities used in these tests were found in code found on GitHub and online communities. It cannot be said that such code is definitely used as-is on the manufacturing floor, but it can be said that some of these codes are taken from technical materials such as manuals and programming references used by novice programmers. Therefore, it cannot be said that it is completely harmless to workplaces. In addition, previous research has shown that vulnerabilities in open-source code can spread and ultimately affect products. Therefore, we assume that the attack scenarios presented in this paper are reproducible on the manufacturing floor.
Now let's take a closer look at three attack scenarios that can directly lead to damage of a factory environment.
Attack scenario 1: Changing of robot operation via the network
The movement of an industrial robot is defined programmatically and the values input to the controller. Photo.4 is an open-source task program created for the industrial robot "Kuka," which is a motion server task program that defines the movement of the robot. This allows the robot to receive coordinate information over the network, regulating the robot's movements. Therefore, the input to the robot must always be complete in order to ensure physical safety. Normally, an area for safety protection is set for an industrial robot (hereinafter referred to as a safety area), and the maximum operation of an industrial robot is limited to within this area. Therefore, if the safety area is set properly, inputs with coordinates outside the area will be invalidated. On the other hand, in cases where invalid coordinates are specified for the "inside" of the safety area, the integrity of the input must be ensured by the input value verification and access control functions for the robot.
Page 6 of 18| The Security Dilemma of Smart Factories
The Security Dilemma of Smart Factories | June 2021
However, "defective access authentication" and "defective input value verification" were found in the program investigated this time. In other words, this task program is not configured to receive commands only from a specific partner, does not judge the validity of the input coordinate information, and determines the movement of the robot based only on the received data. By exploiting these vulnerabilities, an attacker can spoof network packets and move the targeted robot at will. This attack can affect manufacturing quality and create delays in the manufacturing process due to unintended robot movements. If the safety area is not configured correctly, the damage will be more serious. Photo.5 is the result of running this attack scenario without correctly configuring the safety area.
Programs that define behavior over networks in this way are common as motion server task programs used to drive connected industrial robots. Large-scale projects, such as ROS-Industrial software, make extensive use of motion servers to provide a vendor-neutral interface common to various OEM industrial robots. In general, there is appropriate network level protection (such as IP address or MAC address filtering), and industrial robots are guaranteed to receive coordinate values from only designated controllers. However, if the task program does not have a mechanism other than the network level protection described above to authenticate the source, or if it is affected by an input value verification vulnerability, as long as the received coordinate value is from a valid IP address or MAC address, it will be automatically trusted even if the source is spoofed. In either case, this makes it easy for an attacker residing on the local network to perform this attack scenario. As a result, an attacker can simply send arbitrary coordinates and the industrial robot will be driven accordingly, resulting in poor product quality and delays or stoppages in the manufacturing process. In addition, improperly configured safety areas can result in more serious physical damage as shown in Photo.5.
Page 7 of 18| The Security Dilemma of Smart Factories
The Security Dilemma of Smart Factories | June 2021 Attack scenario 2: Information theft via robots
This attack scenario exploits a path traversal vulnerability in a task program on a Web server that is executed to display coordinate information on an industrial robot controller provided by a manufacturer. The program discovered in this research was an app that can be used via "ABB-Robot Apps Robot Studio" and operates as a web server on an industrial robot. And it was implemented using Rapid, ABB's own language. Exploitation of this vulnerability could enable an attacker on a network to create a file containing potentially sensitive data (such as a log file containing coordinate information from when an industrial robot operates) on an industrial robot, and leak it using the controller of an industrial robot. Confidential industrial information is traded at very high prices in the underground market and is one of the main targets for cybercriminals. In response to our report, ABB has removed the relevant app from their app store. Path traversal is an attack method and vulnerability in which attempts are made to access a directory that should not be accessible by exploiting a vulnerability. This attack exploits a server specification that adheres to instructions in a tree structure, but in most cases, there is code that allows unintended access by the developer. Photo.6 is the ABB program mentioned earlier, with line 493 being the code that most clearly shows the path traversal vulnerability. Line 493 calls the sendFile function to send the requested file to the client. Of note here is the concatenation with the page string, which includes the higher-level directories, which also allows access to other files across the file system.
Also, photo.7 shows the results of an experiment in which the vulnerability was exploited to steal confidential sample information. It has been shown that a path traversal attack can access "secret.txt." The code also provides an excerpt of the vulnerable web server code, along with comments left by the developer. In this case, it shows that all requests come from a benign browser and are reliable, but in reality, this is by no means secure coding.
Page 8 of 18| The Security Dilemma of Smart Factories
The Security Dilemma of Smart Factories | June 2021
In security-conscious software development, it is always assumed that "external input is unreliable." Therefore, it is necessary to verify the input values on the server side in advance so that unauthorized access is not performed by input that the developer did not expect.
Attack scenario 3: Generation of targeted and self-spreading malware
By preparing a Trojan horse malicious program in a task program and having it act as a dropper, an attacker can create self-spreading malware on an industrial robot and spread the threat throughout the entire factory. Once the malware is created according to the steps shown in Figure.4, the worm-capable malware begins scanning the network for other potential targets, exploiting network vulnerabilities, and spreading itself.
Page 9 of 18| The Security Dilemma of Smart Factories
The Security Dilemma of Smart Factories | June 2021
Photo.8 is a screenshot showing the network scanning operation of the worm-type malware presented as a proof of concept in this survey. The basic operation is simple. In this case, the network is scanned (intentionally limiting the scope to three IP addresses in order to make the proof of concept as specific as possible) and whether the target port is open or not is checked. The Command and Control (C&C) server can then communicate with the infected industrial robot and execute commands such as network scans and spread infection to other industrial robots.
Thus, while industrial robots and their automation technologies are totally different from traditional web applications running on Windows servers, there are well-known types of vulnerabilities such as path traversal and code injection, meaning you could be infected with a virus and you could be targeted by malware.
Page 10 of 18| The Security Dilemma of Smart Factories
The Security Dilemma of Smart Factories | June 2021
In addition, most of the issues analyzed in this survey are so-called "normal programming problems," so if we focus only on individual vulnerabilities, it may seem that we are only presenting the risk of "any attack is possible if the attacker can change the task program." However, these risks are not the only ones that give the full picture of the issues covered in this survey. The essence of the problem is that the programming languages we investigated in this survey continue to be used despite being designed in an era when none of them would have been assumed to be actively used for attacks.
Fundamental security risk: "Flat access" to "basic functions"
As explained above, it is possible to steal information and cause physical damage by exploiting the vulnerabilities of task programs of industrial robots. At first glance, the vulnerabilities discovered in this research appear to be "vulnerabilities resulting from poor coding" that tend to occur in web application development. If so, thorough secure coding is an effective countermeasure, but the problems hidden in the task programs of industrial robots are a little more complicated. The task programs of industrial robots are written in "proprietary languages designed decades ago." From a security perspective, closed factory environments of 20 years ago and modern smart environments of technological innovation are totally different. Therefore, it is very possible that the security standards at the time of language development did not match those of today. Based on this hypothesis, for this survey Trend Micro analyzed a total of 100 task programs written in the programming languages of eight major vendors in the industrial robot industry in an attempt to determine the "security risks of language design itself." As a result, it was found that the programming languages of industrial robots have a technical security risk that "basic functions of systems (lower system resources) can be used unconditionally without any confirmation of permissions." The essence of the problem is that the functions required to drive the robot are implemented, but there are no mechanisms to prevent those functions from being used by malicious people. The specifications of programming languagesare highly platform-dependent. As mentioned earlier (insert a link to the first installment), an industrial robot is a complex cyber-physical system in which a program, a controller, and a driving part work in close coordination. Therefore, the problem is not only the programming language, but also a problem on the platform robot controller side. The language problem confirmed this time is caused by the fact that there is no mechanism for confirming permissions on the controller, which is the platform. It is thought that there is no mechanism for executing the permissions confirmation function on the programming language side either.
Now let's take a closer look at the problem.
Platform for which "flat access” is possible
Decades ago, when the programming languages for industrial robots were designed, the concept of smart factories did not exist, and closed factory environments were the norm. So it is not surprising that the design was not performed with active attackers from external locations in mind. In comparison, modernly designed systems such as smartphones reflect security designs that assume malicious attacks. For example, when developing an app for Android and programming it in Java, as described in the developer documentation, an explicit permission request is required to access resources outside the sandbox of the app itself. Therefore, even if a malicious developer sneaks an app containing malware onto the mobile app store, they must request permission to use the microphone, network, and other low-level system resources required by the malware to operate the app (Example: When the app is launched for the first time, the message "The app XX is requesting access to the microphone. Do you want to allow it?" is displayed). Such permission settings are also necessary for industrial robots. However, at present, there is no such requirement for industrial automation platforms, and all resources have "flat" access. In other words, the task program can use lower- level resources beyond the scope of permissions that it should have.
What happens when "basic functions" are abused
Page 11 of 18| The Security Dilemma of Smart Factories
The Security Dilemma of Smart Factories | June 2021 The combination of the flat access mentioned above and the basic software functions of programming languages dramatically increase the security risks of industrial robots. Below, let's take a look at the basic functions of programming languages for industrial robots. Industrial robot programming languages are used to define robot movements, but the software itself has more features. The proprietary programming languages of manufacturers investigated this time not only supported the concept of the file system found in ordinary computing systems, but also had functions such as function pointers and dynamic code reading. As shown in Figure.5, we can see that the software of industrial robot vendors provides sufficient functionality to act as a web server.
As mentioned above, system resources can be used without any restrictions, allowing an attacker to exploit these basic functions. By taking full advantage of these basic features, it is even possible to write malware on a robot platform. Below, let's look at the true role of each feature and what happens if they are abused.
[File and directory access] Programming languages for which the "File system" and "Directory listing" items are checked have basic functions for opening, reading, and writing to files and directories (access configuration parameters, write log information, and save program statuses). Although these features are legitimate in nature, they can be exploited to leak information or load attack code.
[Reading and executing code] Programming languages for which the "Load module from file" and "Call by name" items are checked have functions similar to function pointers in general programming languages. These features allow control process engineers to create modular programs by leveraging dynamic calling procedures. In addition, these features can change the flow of task programs at runtime, making them one of the most powerful and dangerous features. These features are inherently very useful when implementing complex task processes which combine modular programs. On the other hand, these can be vulnerabilities which can be exploited to deploy dropper-type malware and execute remote code.
[Transmission and reception of data to and from external systems] "Communication" is a function that has been confirmed to exist in all languages. This function facilitates cooperation between industrial robots and external systems. Examples of application include receiving real-time position coordinates
Page 12 of 18| The Security Dilemma of Smart Factories
The Security Dilemma of Smart Factories | June 2021 from an external program, interlocking with a vision system, and sending feedback to an external system to be recorded as logs. The problem here is that while the platforms have network communication capabilities, they lack any ability to authenticate and control access at the programming language level altogether. Developers and integrators can use authentication functions to set access restrictions when a robot controller is operated from an external location, but they cannot restrict access to network communication of task programs executed on the controller. Therefore, if a task program containing malicious code is written to a robot controller, the task program can perform external communication without any restrictions. Under this type of specifications, it is extremely difficult to create a task program that can perform external communication safely, so it can be said that there is a limit to how far security risks can be reduced based on the efforts of task program developers alone.
Security risks specific to proprietary languages
In addition to the above technical features, there are also risks due to the "uniqueness" of each robot language. For common programming languages (C, C++, C #, Java, PHP, Python, etc.), there are code checkers (e.g., static program analysis tools) that detect insecure patterns. On the other hand, one of the concerns is that it will be difficult to automate security checks because there are no such tools for each company's robot programming language. Industrial robot programming languages are not based on a common runtime or architecture like mainstream operating systems, but on the platform (robot controller) of each manufacturer. For this reason, each robot vendor will also have to prepare their own proprietary programming language and the environment on which the program execution runtime will be based. There are programming languages and environments based on real-time operating systems (RTOS), but generally they are not standardized. In addition, each language has its own semantics (criteria for judging whether variables and statements used in the source code work correctly), and these may be very different from general-purpose programming languages. In fact, some of the languages we surveyed do not have features like string manipulation or cryptographic manipulation. Also, these types of characteristics tend to limit the choices available to users. Since the programming environment of industrial robots cannot be easily replaced, it is not easy or practical for users to correct these design flaws. In addition, the languages of each company are not only central to current industrial automation, but also have strong technical lock- ins, which inevitably increases the cost of transferring to other platforms. Therefore, it is very likely that users will have to choose to accept the security risks of the robot platform they use.
There are cyber security risks that continue to lie in the core technologies that support manufacturing. This is the modern dilemma of smart factories.
A modern smart factory environment where the assumptions of 20 years ago do not apply
Factory environments have traditionally been "closed" network spaces. In other words, it was an environment in which network communication with the outside and its effects were not considered (or did not need to be) on the premise that only the people who work there would touch the factory equipment. The industrial robots that were the subjects of this empirical study were designed on the same premise. However, in today's world where network connectivity is advancing even in factory environments, that premise is a thing of the past. In order to improve productivity and reduce the ratio of defects, which are critical issues for factories, and to maintain employee safety and business continuity even during the COVID-19 pandemic, smart manufacturing processes using digital technology will become the industry standard. When that happens, factories are also exposed to the risk of cyberattacks. Software runs everywhere in smart factories and is connected to the network. In addition, not only user companies but also system integrators, consultants, manufacturers of industrial robots, etc., who are the subjects of this study, are involved in the development and supply of such software in a complicated manner. Therefore, the efforts of the entire ecosystem are required to realize safe smart factories. In other words, it is important for each user, integrator, and manufacturer to "make safe software" and thus "keep software safe".
Implementing risk mitigation measures from a short- to long-term perspective
Page 13 of 18| The Security Dilemma of Smart Factories
The Security Dilemma of Smart Factories | June 2021 The security concerns presented in this series are deeply rooted in the basic technology of industrial robots, making it difficult for manufacturers to immediately replace it with another technology or make corrections. Therefore, in addition to protecting the existing environment as a short-term measure, it is recommended that the stakeholders involved in industrial robots should gradually and systematically implement risk mitigation measures in anticipation of future smartness as a medium- to long-term measure. Figure.6 shows Trend Micro's recommended stakeholder-specific step-by-step risk mitigation measures. In order to make smart factories more secure, it is important for field engineers, system integrators, and industrial robot manufacturers to implement their respective security measures. Below, let's take a closer look at short- to long-term countermeasures.
Short-term measures As explained above, it would be extremely difficult to solve the security risks of industrial robots from the ground up in a short period of time. Therefore, in the short term, it is a realistic solution to minimize the risk at the field level on the premise of retaining the security flaws that are explained in this series. The key players in implementing short-term measures are the control process engineers in the field and the system integrators who actually write, implement, and operate task programs. Field engineers on the user side must ensure that network segmentation is performed to minimize the damage if a task program of an industrial robot is abused. This action significantly reduces network-related security risks. In addition to these essential security measures, protection of networks and endpoints is recommended to minimize the risk of being vulnerable to or being infected with malicious code. In addition, although details will be described later, secure coding practices are also indispensable for users. If you perform development with a system integrator, try to share a similar security policy with them. Source code reviews, bug fixes, and creation of appropriate source code control processes are both basic and effective measures.
Medium-term measures (Security measures in new environments) In addition to the above short-term measures, a security library for industrial robot programming languages can be given as a medium-term measure with a view to protecting new environments. Security libraries include, for example, encryption libraries. At this stage, the key players are system integrators and industrial robot manufacturers. By implementing such security measures in higher development, on-site developers can easily implement input value verification and authentication functions without spending time adding new processes.
Page 14 of 18| The Security Dilemma of Smart Factories
The Security Dilemma of Smart Factories | June 2021 In addition, system integrators and industrial robot manufacturers should implement motion server references. By implementing such references, developers do not have to check each piece of motion data processing code for defects one by one. Typical examples of such reference implementations are Mitsubishi Electric's native motion server and Kuka's EKI. In addition, as a countermeasure against defects found in source code reviews, system integrators should consider providing proactive patches for task programs that may contain vulnerabilities.
Long-term measures (Security measures for the entire future market) In the future, the efforts of manufacturers will be essential to ensure that the designs of programmable industrial robots are safe. For example, in an industrial robot platform (controller), it will be essential that security functions (such as authentication, access control, encryption, etc.) are incorporated into programming languages. The runtime in an industrial robot controller must implement fine-grained privilege separation that leverages an authorization system. An effective way to reduce the effects of vulnerabilities and malicious code is to limit the execution of functions to privileged directives only. On top of that, developers also need to make others aware of these usage limits in advance, similar to the process we saw in the Android app development example. Last, but not least, code signing is the only way to ensure that code for industrial machines has not been tampered with. Code signing is not easy to do, but using this measure makes it possible to ensure that the code is exactly what the original developer wrote. Implementing code signing in factory equipment has a long way to go, but if market needs continue to drive innovation that favors integration and flexibility, it should be possible to achieve more dynamic automation code implementation in shorter cycles. This should speed up development and reduce the amount of time spent manually checking programs. Task programs that are written securely also reduce the chances of vulnerabilities being created. This, in turn, reduces the risk of programmable industrial machines being exposed to external attacks. In fact, there are already a number of safety-conscious coding guidelines for general-purpose programming languages. As the integration of IT and OT progresses, over the coming decade, the industrial engineering industry may face the same challenges that the IT software industry faces today. Now is the time to start implementing and establishing secure coding processes at the same level.
Responsibility as a security expert Factory security is a medium- to long-term strategy that cannot be handled completely by one company. It can be said that users, integrators, manufacturers, and security vendors should work together to implement solutions with the aim of improving the security level of the entire ecosystem. And Trend Micro is one of the security vendors aiming for the same goal. Trend Micro has been focusing on research and development for the integration of IT and OT (Operation Technology) for many years. Security solutions for factory environments, which have been expanded since 2020 and are being deployed around the world, have been devised to realize network segmentation, which is the core short-term measure, without changing the settings of existing environments. In addition to this, we provide a group of solutions that protect entire factory environments, such as IPS that prevents intrusion from IT/OT connection points, detection tools that enable internal monitoring in factory networks, and industrial endpoint protection products. In addition, the effectiveness of these security solutions is supported by the accumulation of advanced threat research such as that introduced here. In addition, Trend Micro was able to participate in the "ROS-Industrial (ROS-I) Consortium" as a result of this study, and will be involved in the promotion of safe development of industrial robot applications in Industry 4.0 over the medium to long term. In this study, Trend Micro discovered a security problem affecting the ROS-I driver that controls industrial robots, and in response, proceeded to investigate it in collaboration with the ROS-I Consortium. This joint investigation found that an attacker could compromise the communication interface of a motion server program running on the ROS-I driver and the controller of an industrial robot. In this case, the recommended remedy is to configure the network appropriately. In this regard, the ROS-I Consortium has published a report to help users improve their security. In addition, the Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) of the US Cybersecurity and Infrastructure Security Agency (CISA) emphasized the significance of the results of this investigation and issued a report approving recommended mitigation measures. Trend Micro not only provides security solutions, but also contributes to improving the security level of the entire ecosystem by sharing the results of research that utilizes its expertise.
Aiming for "security by design" for the entire ecosystem Through the four parts of this series, we have analyzed the task programs and programming languages of industrial robots from the perspective of cybersecurity, and clarified the issues facing modern industrial robots. At this point,
Page 15 of 18| The Security Dilemma of Smart Factories
The Security Dilemma of Smart Factories | June 2021 although it may be difficult to take all possible measures needed to address the security issues identified in this survey, it is possible for manufacturers, integrators, and users to work together to reduce these risks to an acceptable level. Cybersecurity measures in factory environments are in the process of being transformed. Within 10 years at the latest, smart factories that assume network connectivity with the outside world will become commonplace. At that time, the industrial automation industry is likely to face the same challenges that the modern IT software industry faces. But there is still time. There are many things each player can do from this point on in preparation for that time.
We hope that this study will serve as a reference for everyone who will be creating the future of smart factories.
Read a whole paper
Page 16 of 18| The Security Dilemma of Smart Factories
The Security Dilemma of Smart Factories | June 2021
Appendix: Checklist for secure programming
Adhering to a safe development process based on a programming guide is one basic measure, but it has not yet become established as a common measure in the industrial robot market. Industrial robots are computers that execute programs, and control process engineers are programmers. And as long as the programmer is human, the chances that the written code will be insecure cannot be eliminated. Therefore, task programs, like any computer systems, should be checked to ensure that they are secure. This section provides security checklists to help control process engineers and system integrators develop and evaluate task programs. The following is a list of check items for control process engineers and system integrators to use when they are writing task programs. Please use it when developing a task program.
----- Checklist for when writing a task program -----
Recognize that industrial machines are computers and task programs are exploitable code. All communication is subject to authentication. Access control policies are implemented. Input is validated as needed. Output information is always scrutinized. Appropriate error handling is performed without disclosing unnecessary details. Appropriate configuration and placement procedures are implemented. There is a change control process in place for industrial task programs.
------
In addition, the factory security officer of the user company must clarify the items to be evaluated regarding the expected control level of the task program to be outsourced before actually outsourcing the creation of a task program to an integrator. To encourage the implementation of appropriate security functions, users should clearly inform the integrator of the following:
----- Checklist for when outsourcing task program development -----
If the task program will receive data from outside the controller of the industrial robot. If the task program will generate data that is processed outside the controller of the industrial robot. If the task program is static over time. If there an upgrade procedure to change whether the task program is static. If the module will be loaded while the main program is running. Who implemented the task program. Who has access to the task program before it is transferred to the controller of the industrial robot. Who is the system user authorized to run, load, and modify task programs during normal operation.
------
Page 17 of 18| The Security Dilemma of Smart Factories
The Security Dilemma of Smart Factories | June 2021
YOHEI ISHIHARA
Security Evangelist, Trend Micro Incorporated.
Graduated from the Department of Criminology, California State University, Fresno. Joined Trend Micro after experience with sales and marketing at a hardware manufacturer in Taiwan, and SIer in Japan. Now provides information on IoT-related threats and vulnerabilities, and enlightens users about security problems in cooperation with researchers world-wide.
Trend Micro, a global leader in cybersecurity, helps make the world safe for exchanging digital information. Leveraging over 30 years of security expertise, global threat research, and continuous innovation, Trend Micro enables resilience for businesses, governments, and consumers with connected solutions across cloud workloads, endpoints, email, IIoT, and networks. With over 6,700 employees in 65 countries, and the world’s most advanced global threat research and intelligence, Trend Micro enables organizations to secure their connected world www.trendmicro.com.
© 2021 by Trend Micro Incorporated. All rights reserved. Trend Micro, and the Trend Micro t-ball logo, and Smart Protection Network are trademarks or registered trademarks of Trend Micro Incorporated. All other company and/or product names may be trademarks or registered trademarks of their owners. Information contained in this document is subject to change without notice. [WP00_Security_Dilemma_Smart_Factories_Article_210607]
Page 18 of 18| The Security Dilemma of Smart Factories