Robots are going mainstream. From assistance and entertainment robots used in homes, to those working in assembly lines in industry and all the way to those deployed in medical and professional facilities. For many, robotics is called to be the next technological revolution. Yet, similar to what happened at the dawn of the computer or the mobile phone industries, there is evidence suggesting that security in robotics is being underestimated. Even though the first dead human from a robot happened back in
An open source template of our security framework is available at http://github.com/aliasrobotics/RSF and licensed under GPLv3. We kindly invite security researchers, robotic researchers and analysts to use, review, challenge and complement our work.
Over the last 10 years, the domains of security and cybersecurity have been substantially democratized, attracting individuals to many sub-areas within security assessment. According to recent technical reports summarizing
In an attempt to provide a solution for the second problem, this paper presents the Robot Security Framework (RSF), a systematic methodology for performing security assessments in robotics. We argue that security, privacy and safety in robotic systems should clearly be recognized as a major issue in the field. Our framework proposes a standardized methodology to identify, classify and report vulnerabilities for robots within a formal operational protocol. Throughout the description of the RSF, we present exemplary scenarios where robots are subject to the security issues hereby exposed.
Robot security is becoming a concern that extends rapidly. However, to date, and as already briefed in the Introduction section, there are few honest and laudable efforts that elaborate into methodologies for analyzing robot's security or cybersecurity. The most relevant of those pioneering contributions is
In an attempt of providing real use-case scenarios,
Other contributions to robot security, have primarily focused upon providing only partial contributions, e.g. hardening particular aspects of robots, such as
Recently, some pieces of
Inspired by the current state of the art,
- Reformulation of the categorization terms. In particular, the term component becomes aspect. Component is a rather generic term in robotics and it typically refers to a discrete and identifiable unit that may be combined with other parts to form a larger
entity. Components can be either software or hardware. Even a component that is mainly software or hardware can be referred to as a software or hardware component respectively. In order to avoid any confusions, rather than component, the term aspect will be used to categorize each layer within RSF.
- Overall restructuring of the content. The original structure of the work presented by
Shyvakovhinders its comprehension, specially for those more familiar with robots and their components. Therefore, we propose a layer-aspect-criteria structure where each criteria is analyzed in terms of its objective, the rationale or relevance, and the systematics of assessment or method.
- Formalized firmware layer. We adopt a commonly accepted definition of firmware suitable for the context of robotics: software that is embedded in robots. We apply this definition to the previous 'Firmware and Operating System layer' and generalize it simply as 'Firmware layer'. Besides the operating system, we include robot middleware as a relevant topic of assessment and group them both into Firmware, according to the adopted definition.
- Adoption of generic "component" and "module" terms. As an alternative to the proposed "internal component" and "external component" terminology, we suggest the generic terms "component", as defined above, and "module". Both are commonly accepted as a component with special characteristics that facilitate system design, integration, inter-operability and re-use. This way, we simplify the message when speaking about components
The term "internal components" can lead to misunderstandings. For some, internal components are those physically embedded within the robot exoskeleton. According to others, internal components are those that physically define each discrete and identifiable component and, thereby, should not be exposed nor taken into consideration from a security perspective. Ultimately, there is a third school of thought that classifies internal and external components based on a networking point of view, considering as "internal components" only those that are connected to the internal network (with no external interface access). [↩]. In light of the above, we elaborate on the following notion: robots are composed by components and modules. Some of them are physically exposed and some others are not. Among the modules and components, some are part of the "internal network", thereby hidden from the outside from a network perspective, whereas others are freely accessible from the outside and thereby part of the external network.
- Improved internal networking security model. As pointed out above, according to our vision, modern robotics should converge towards the enforcement of identically strict security levels on both internal and external communication interfaces. Therefore, we propose changes to assess internal network security and justify them by presenting existing study cases.
- Improved model for physical tampering attacks. We include a series of aspects and criteria to detect physical attacks on robots. We highlight the use of logging mechanisms, already present in most robots, in order to monitor suspicious physical changes therein.
- Added exemplary scenarios. Throughout the framework content we add exemplary scenarios to illustrate how our methodology helps to assess the security of existing robots.
- We open source our work and provide a variety of user-friendly representations to simplify its adoption. This work is available and freely accessible at http://github.com/aliasrobotics/RSF under GPLv3 license.
The Robot Security Framework
We hereby propose a framework based on four layers that are relevant to robotic systems. We subsequently divide them into aspects considered relevant to be covered. Likewise, we provide relevant criteria applicable for security assessment. For each of these criteria we identify what needs to be assessed (objective), why to address such (rationale) and how to systematize evaluation (method). The following image pictures our framework:
A complete list of elements, including several examples, is provided within our paper. A template for security analysts is also available in the RSF Github repository. We kindly invite security researchers, robotic researchers and analysts to use, review, challenge and complement our work.