Robot cybersecurity, a review

Abstract. Robots are often shipped insecure and in some cases fully unprotected. The rationale behind is threefold: first, defensive security mechanisms for robots are still on their early stages, not covering the complete threat landscape. Second, the inherent complexity of robotic systems makes its protection costly, both technically and economically. Third, vendors do not generally take responsibility in a timely manner, extending the zero-days exposure window (time until mitigation of a zero-day) to several years on average. Worse, several manufacturers keep forwarding the problem to the end-users of these machines or discarding it. In this article we review the status of robot cybersecurity considering three sources of data: 1) recent literature, 2) questionnaires performed in top robotics forums and 3) recent research results in robot cybersecurity. Building upon a decade of experiences in robotics, this article reviews the current status of cybersecurity in robotics and argues about the current challenges to secure robotic systems. Ultimately, based on the empirical results collected over a period of three years performing security assessments in robots, the present text advocates for a complementary offensive approach methodology to protect robots in a feasible and timely manner.

Full text transcribed from the original publication source.

1Notes for Practice

• This article reviews the status of robot cybersecurity considering research and empirical data.
• While systematically reviewing sources, the article provides various observations that attempt answering two questions posed initial: what’s the status of cybersecurity in robotics? and, how can we best improve cyber-resillience in robotics?
• Following a red teaming methodology, the article considers the vulnerabilities affecting robots from three different robot manufacturers and provides an intuition on how to use these flaws to generate indicators to evaluate the security readiness of a manufacturer.
• Based on the theoretical and empirical results studied, the text concludes that robot cybersecurity is still on its early stages and neither practitioners nor manufacturers or defensive security solutions meet the current industry demands to remain secure. Given this scenario the text provides a final observation considering red teaming methodologies to approach robot cybersecurity in a time-sensitive manner.

Keywords: robotics, security, review, survey, offensive

21. Introduction

For the last fifty years, we have been witnessing the dawn of the robotics industry, but robots are not being created with security as a concern, often an indicator of a technology that still needs to mature. Security in robotics is often mistaken with safety. From industrial to consumer robots, going through professional ones, most of these machines are not resilient to security attacks. Manufacturers’ concerns, as well as existing standards, focus mainly on safety. Security is not being considered as a primary relevant matter.

The integration between these two areas from a risk assessment perspective was first studied by Stoneburner (2006) and later discussed by Alzola-Kirschgens et al. (2018), which resulted in a unified security and safety risk framework. Commonly, robotics safety is understood as developing protective mechanisms against accidents or malfunctions, whilst security is aimed to protect systems against risks posed by malicious actors (Swinscow-Hall, 2017). A slightly alternative view is the one that considers safety as protecting the environment from a given robot, whereas security is about protecting the robot from a given environment. In this article we adopt the latter and refer the reader to Appendix A for a more detailed literature review that introduces the differences and correlation between safety, security and quality in robotics.

Security is not a product, but a process that needs to be continuously assessed in a periodic manner, as systems evolve and new cyber-threats are discovered. This becomes specially relevant with the increasing complexity of such systems as indicated by Bozic and Wotawa (2017). Current robotic systems are of high complexity, a condition that in most cases leads to wide attack surfaces and a variety of potential attack vectors which makes difficult the use of traditional approaches. Altogether, this leads to the following research questions: what’s the status of cybersecurity in robotics? and, how can we best improve cyber-resilience in robotics?

The present article tackles these questions by performing a systematic review. The approach followed is three-fold: first, we review literature in the robot cybersecurity space depicting the current landscape. Second, we study and review the results obtained while surveying different robotics groups and communities in search for an answer of the current state of robot cybersecurity. Third and lastly, we review the results obtained during three years of proactive security research in robotics, discussing vulnerabilities and the offensive exercises conducted. The article finalizes by sharing some thoughts and conclusions about how to secure robots, how to understand better the attack vectors they are subject to and how to minimize their attack surfaces.

2.1Robotic systems and robots

Both literature and practice are often vague when using the terms robot/s and/or robotic system/s. Sometimes these terms are used to refer to one of the robot components (e.g. the robot is the robot arm mechanics while its human-machine interface (HMI) is the teach pendant). Some other times these terms are used to refer to the complete robot, including all its components, regardless of whether they are distributed or assembled into the same hull. Throughout this article the latter is adopted and unless stated otherwise, the terms robot/s and/or robotic system/s will be used interchangeably to refer to the complete robotic system, including all its components.

The remainder of the article is organized as follows: Section 2 provides a literature review of the robot cybersecurity field highlighting some of the current biographical cornerstones. Section 3 elaborates on the results of the questionares and surveys performed in top robotics conferences and forums. Section 4 reviews the vulnerability landscape in robotics using empirical data collected while assessing the security of multiple robots over the past three years. Finally, Section 5 presents some conclusions and thoughts on how to better secure robotic systems.

32. A literature review of cybersecurity in robotics

Arguably, the first installation of a cyber-physical system in a manufacturing plant was back in 1962 (Robinson, 2014). The first human death caused by a robotic system is traced back to 1979 (Young, 2018) and the causes were safety-related according to the reports. From this point on, a series of actions involving agencies and corporations triggered to protect humans and environments from these machines, leading into safety standards.

Security however hasn’t started being addressed in robotics until recently. Following after McClean et al. (2013) early assessment, in one of the first published articles on the topic Lera, Matellán, et al. (2016) already warns about the security dangers of the Robot Operating System (ROS) (Quigley et al., 2009). Following from this publication, the same group in Spain authored a series of articles touching into robot cybersecurity (Lera, Balsa, et al., 2016; Lera, Llamas, Guerrero, & Olivera, 2017; Guerrero-Higueras, DeCastro-García, Rodríguez-Lera, & Matellán, 2017; Balsa-Comerón, Guerrero-Higueras, Rodríguez-Lera, Fernández-Llamas, & Matellán-Olivera, 2017; Rodríguez-Lera, Matellán-Olivera, Balsa-Comerón, Guerrero-Higueras, & Fernández-Llamas, 2018). Around the same time period, Dieber et al. (2016a) led a series of publications that researched cybersecurity in robotics proposing defensive blueprints for robots built around ROS (Dieber, Breiling, et al., 2017; Dieber, Schlotzhauer, & Brandstötter, 2017; Breiling, Dieber, & Schartner, 2017; Taurer, Dieber, & Schartner, 2018; Dieber & Breiling, 2019). Their work introduced additions to the ROS APIs to support modern cryptography and security measures. Contemporary to Dieber et al. (2016a)’s work, White et al. (2016) also started delivering a series of articles (Caiazza, 2017; White, Christensen, Caiazza, & Cortesi, 2018; White, Caiazza, Christensen, & Cortesi, 2019; Caiazza, White, & Cortesi, 2019; White, Caiazza, Jiang, et al., 2019; White, Caiazza, Cortesi, Im Cho, & Christensen, 2019) proposing defensive mechanisms for ROS.

A bit more than a year after that, starting in 2018, it’s possible to observe how more groups start showing interest for the field and contribute. Mayoral-Vilches, Kirschgens, Calvo, et al. (2018) initiated a series of security research efforts attempting to define offensive security blueprints and methodologies in robotics that led to various contributions (Mayoral-Vilches, Kirschgens, Gil-Uriarte, et al., 2018; Alzola-Kirschgens et al., 2018; Mayoral-Vilches, Mendia, et al., 2018; Mayoral-Vilches, Abad-Fernández, et al., 2020; Mayoral-Vilches, Pinzger, et al., 2020; Lacava et al., 2020; Mayoral-Vilches, García-Maestro, et al., 2020; Mayoral-Vilches, Carbajo, & Gil-Uriarte, 2020). Most notably, this group released publicly a framework for conducting security assessments in robotics (Mayoral-Vilches, Kirschgens, Calvo, et al., 2018), a vulnerability scoring mechanism for robots (Mayoral Vilches et al., 2018), a capture the flag (CTF) environment for robotics whereto learn how to train robot cybersecurity engineers (Mendia et al., 2018) or a robot-specific vulnerability database that third parties could use to track their threat landscape (Mayoral-Vilches, Usategui San Juan, et al., 2019), among others. In 2021, Zhu et al. (2021) published a comprehensive introduction of this emerging topic for theoreticians and practitioners working in the field to foster a sub-community in robotics and allow more contributors to become part of the robot cybersecurity effort.

43. Surveying the robotics community

During a period of two years (2019–2020) various security surveys were conductued in top robotics conferences and forums. The following subsections discuss each one of them while attempting to draw some observations.

4.13.1 Surveying the ROS community

Figure 1 presents a summarized result of the survey conducted in the ROS community during a period of several months. The survey received a total of 52 responses, which represented the small interest in security at the time. The largest groups of participants are depicted in Figure 1b. The most represented group comes from Universities (30%), followed by Software vendors (18%) and Robot manufacturers (14%). The majority of the respondents have at last 2 years of experience with ROS and half of them at least 5 (1c), most coming from Europe (1d). Figure 1e present data on security considerations. The data indicates that 73% of the participants think that they have not invested enough to protect their robots from cyber-threats. Coincidentally, the same number of participants indicated that their organizations are open to invest however only 26% acknowledge to actually have invested. This data leads to the following observation.

Others comprises various subgroup, all with less representation than the ones mentioned.

When considering the mitigation strategies applied by respondents as depicted in Figure 1f, it’s important to highlight that most efforts concentrate on perimeter actions (i.e. firewalls, segmentation and segregation) whereas robot-specific defensive solutions are only applied in a 36% of the cases. Similarly, network assessments and security audits are conducted only in one fourth of the cases (26%) which conflicts with the de facto security practices in other industries, wherein assessments are critical to evaluate the resilience of technology.

4.23.2 Surveying the PX4 community

PX4 (Meier et al., 2015) is an open source flight control software for drones and other unmanned vehicles. Similar to ROS, its community represents another relevant group in robotics. A security survey was conducted in 2020 and the results are summarized in Figure 2. Though the PX4 community is significantly smaller than ROS’s, the sample size obtained (11 respondents) was extremely small to draw major conclusions. Interestingly though, it was observed that the majority of the respondents have yet to see a security issue impacting the community (2d), only 27% had seen it.

The majority of the respondents (81%, Figure 2e) indicated to be willing to invest and more than 90% confirmed that the amount could be 100 USD or above (Figure 2f). This aligns nicely with Observation 2 and further hints that growth should be expected in this field.

4.33.3 Surveying the ROS-Industrial community

Also in 2020, a series of security-related surveys were launched as part of the European ROS-Industrial Conference, which happens every year in December. Data collected is presented in Figure 3. The majority of the respondents (93%) showed awareness about the threats their robots faced and admitted being aware of their exposure to attackers (Figure 3b). Unsurprisingly, as a subset of the overall ROS community, the security mitigation actions in the ROS-I community also concentrate on the perimeter which lead to another observation.

This fact becomes concerning in industrial environments wherein insider threats are as dangerous, and the disruption of ROS could lead to catastrophic consequences for the automation processes (Mayoral-Vilches, Pinzger, et al., 2020), impacting more than 5 robots in 44% of the cases according to respondents (Figure 3f). The lack of security measures in ROS are particularly concerning since its distributed communication middleware could be easily used to spread malware across connected robots. Such concept was demonstrated by Mayoral-Vilches, San Juan, et al. (2019), which prototyped an instance of ransomware targeting industrial collaborative robots, leaving these machines and its data completely locked until the corresponding ransom is paid.

4.43.4 Surveying the European robotics community at the European Robotics Forum (ERF) (2020)

As one of the leading geographies in robotics and cybersecurity, the opinion of european robotics experts was sampled during the annual European Robotics Forum (ERF). Figure 4 summarizes the most relevant data collected. The most interesting observation relates to the question “Who is the actor to be responsible for cyber-incidents?”

54. Security research results in robotics

Figure 5 depicts summarized vulnerability research results for three vendors: ABB, Mobile Industrial Robots (MiR) and Universal Robots (UR). The data was collected and archived over a multi-year period. Figures 5a, 5b and 5c illustrate the “days until mitigation” for each vulnerability and according to the public data in the Robot Vulnerability Database (RVD) (Mayoral-Vilches, Usategui San Juan, et al., 2019). The flat line represented by a series of data points in Figures 5b and 5c denotes that the vendor hasn’t reacted yet to any of these flaws and they remain unmitigated (they are zero days). For ABB robots, the scattered plot in Figure 5a denotes more security activity. The following observations are drawn from the data.

On top of these, Figures 5d to 5i enhance previous data with additional private sources of information and consider vulnerabilities that have yet to reach the public domain. It should be noted that the distribution of vulnerabilities signals the security awareness of the manufacturer. Coherently, Figure 5g shows how for ABB robots, four out of five vulnerabilities considered have been publicly disclosed, triaged and scored. In contrast, for MiR and UR robots the oppositive is observed. Four out of five vulnerabilities have yet to be disclosed publicly.

65. Conclusions

This article reviews the current status of cybersecurity in robotics and argues about the current challenges to secure robotic systems. Three sources of data were considered and treated in three different sections: Section 2 considered recent literature, Section 3 discussed the results of four questionnaires conducted in top robotics forums over a period of two years and finally, Section 4 summarized the security research results in robotics obtained while conducting security assessments.

Various observations were made while evaluating different sources of data which hint that the field is still immature (Observations 1, 2, 3) and the practitioners are mostly yet to observe cyber-attacks (Observation 4). An interesting take is that most mitigations in industry seem to be focused in the perimeter (Observation 5) as this is typically the most feasible approach, however past work (Mayoral-Vilches, García-Maestro, et al., 2020) indicates that the castle-and-moat method won’t work in robotics and instead, new approaches based on zero-trust should be pursued.

The lack of investment and concern that some manufacturers are showing for cybersecurity was confirmed reviewing the publicly available data on robot vulnerabilities. While some manufacturers are increasingly showing progress shortening reaction times (Observation 8), others remain uncaring and persuade their users with marketing messages and strategies centered around openness and community. This appears to be a common trend (Observation 7) in the collaborative robots manufactured by the danish MiR and UR, both owned by Teradyne. In light of this, additional data coming from private (non-publicly available) sources was used to evaluate the threat landscape. Based on the data, Observation 9 concludes that the cooperation with security researchers and the posterior responsible disclosure leads to a reduced threat landscape (and coherently a smaller percentage of non-disclosed vulnerabilities).

The empirical results collected over a period of three years (2018–2020) performing security assessments in robots across industries indicates that most robots currently are vulnerable. The complexity of such systems is indeed one of the causes why defensive approaches are struggling to keep up with the need. Given the current maturity landscape of specialized defensive mechanisms for robots and inspired by the popular adage “the best defense is a good offense”, the present work recommends considering offensive practices to increase the resilience of current robotic systems. Offensive assessments can provide an external evaluation of the security readiness of a particular robot and should be integrated early within the development cycle (Mayoral-Vilches, García-Maestro, et al., 2020). Altogether, this motivates the following final observation.

7Appendix

7.1A. Robotics software quality, safety and security

Quality (Quality Assurance or QA for short) and Security are often misunderstood when it comes to software. Ivers argues (Ivers, 2017) that quality “essentially means that the software will execute according to its design and purpose” while “security means that the software will not put data or computing systems at risk of unauthorized access”. Within Ivers (2017) one relevant question that arises is whether the quality problems are also security issues or vice versa. Ivers indicates that quality bugs can turn into security ones provided they’re exploitable, and addresses the question by remarking that quality and security are critical components to a broader notion: software integrity as depicted in Figure 6.

Coming from the same group, Vamosi (Vamosi, 2017) argues that “quality code may not always be secure, but secure code must always be quality code”. This somehow conflicts with the previous view and leads one to think that secure software is a subset of quality. The author of this proposal rejects this view and argues instead that Quality and Security remain two separate properties of software that may intersect on certain aspects (e.g. testing) as depicted in Figure 7.

While the target of this research proposal is Security, Quality will also be studied given its intersection. Often, both secure and quality code share several requirements and mechanisms to assess them. This includes testing approaches such as static code testing, dynamic testing, fuzz testing or software component analysis (SCA) among others.

In robotics there is a clear separation between Security and Quality that is best understood with scenarios involving robotic software components. For example, if one was building an industrial Autonomous Guided Vehicle (AGV) or a self-driving car, often, she/he would need to comply with coding standards (e.g. MISRA (Ward, 2006) for developing safety-critical systems). The same system’s communications, however, regardless of its compliance with the coding standards, might rely on a channel that does not provide encryption or authentication and is thereby subject to eavesdropping and man-in-the-middle attacks. Security would be a strong driver in here and as remarked by Vamosi (Ivers, 2017), “neither security nor quality would be mutually exclusive, there will be elements of both”.

Quality in robotics, still on its early stages (Pichler, Dieber, & Pinzger, 2019), is often viewed as a pre-condition for Safety-critical systems. Similarly, as argued by several, safety can’t be guaranteed without security (Goertzel & Feldman, 2009; Bagnara, 2017). Coding standards such as MISRA C have been extended (MISRA, 2016b, 2016a) to become the C coding standard of choice for the automotive industry and for all industries developing embedded systems that are safety-critical and/or security-critical (Bagnara, 2017). As introduced by ISO/IEC TS 17961:2013 “in practice, security-critical and safety-critical code have the same requirements”. This statement is somehow supported by Goertzel (Goertzel & Feldman, 2009) but emphasized the importance of software remaining dependable under extraordinary conditions and the interconnection between safety and security in software. This same argument was later extended by Bagnara (Bagnara, 2017) who acknowledges that having embedded systems non-isolated anymore plays a key role in the relationship between safety and security. According to Bagnara, “while safety and security are distinct concepts, when it comes to connected software (non-isolated) not having one implies not having the other”, referring to integrity.

In the opinion of the author of this thesis proposal, coding standards such as MISRA or ISO/IEC TS 17961:2013 for safety-critical and security-critical software components do not guarantee that the final robotic system will be secure and thereby, safe. As illustrated in the example above, robotics involves a relevant degree of system integration and inter-connectivity (non-isolated embedded systems connected together internally and potentially, externally as well). As such, both secure and ultimately safe robotics systems do not only need to ensure quality by complying against coding standards but also guarantee that they aren’t exploitable by malicious attackers.

In the traditional view of system security, safety is often understood as “nothing bad happens naturally” while security intuitively indicates that “nothing bad happens intentionally”. Acknowledging the acceptance of this view in the security community, this thesis will put special focus in the context of robotics and use a different definitions. To further understand terminology and prior art in a robotics context, Table 1 presents a summary of the concepts discussed with their interpretation applied to robotics and the corresponding sources used.

Security, as understood in Table 1 shares Integrity with Safety. As discussed in Bagnara (2017) and Goertzel and Feldman (2009), “the only thing that distinguishes the role of integrity in safety and security is the notion of exceptional condition. This reflects the fact that exception conditions are perceived as accidental (safety hazards) or intentional (security threats)”. The later, security threats, are always connected to vulnerabilities. A vulnerability is a mistake in software or hardware that can be directly used by an arbitrary malicious actor or actress to gain access to a system or network, operating it into an undesirable manner (Pfleeger & Pfleeger, 2002). In robotics, security flaws such as vulnerabilities are of special relevance given the physical connection to the world that these systems imply. As discussed in Alzola-Kirschgens et al. (2018), “Safety cares about the possible damage a robot may cause in its environment, whilst security aims at ensuring that the environment does not disturb the robot operation. Safety and security are connected matters. A security-first approach is now considered as a prerequisite to ensure safe operations”. Figure 8 depicts the concepts of Safety, Quality and Security representing their relationships. The target of this research proposal remains security, however, its relationship with quality and safety must be noted.

Robot security vulnerabilities are potential attack points in robotic systems that can lead not only to considerable losses of data but also to safety incidents involving humans. Some claim (Zheng, Zhang, Sun, & Liu, 2011) that unresolved vulnerabilities are the main cause of loss in cyber incidents. The mitigation and patching of vulnerabilities has been an active area of research (Ma, Mandujano, Song, & Meunier, 2001; Alhazmi, Malaiya, & Ray, 2007; Shin, Meneely, Williams, & Osborne, 2011; Finifter, Akhawe, & Wagner, 2013; McQueen, McQueen, Boyer, & Chaffin, 2009; Bilge & Dumitraș, 2012) in computer science and other technological domains. Unfortunately, even with robotics being an interdisciplinary field composed from a set of heterogeneous disciplines (including computer science), to the best of the knowledge of this proposal’s author and his literature review, not much vulnerability mitigation research related to robotics has been presented so far.

Read the original paper ↗