If you are interested in learning more about robot threat modeling and want to reproduce this work with your robot or robot component, reach us out at contact at aliasrobotics.com.

What is a threat model?

Threat modeling is the use of abstractions to aid in thinking about risks. The output of this activity is often named as the threat model. In the context of robotics, a threat model identifies threats that apply to the robot and/or its components (both software and hardware) while providing means to address or mitigate them.

A threat model is key to a focused security defense.

Explaining the relevance of threat modeling in robotics

Reasons to threat model

If you are using robots or producing robotic technology (either software or hardware), here are some of the reasons why you should consider to threat model:

  • Find security bugs early: Threat modeling will help you find design issues even before you’ve written a line of code, and that’s the best time to find those issues.
  • Understand your security requirements accurately: Often, each robotic application requires a specific setup with customizations in both hardware and software. Security measurements often impose strong restrictions on performance and real-time, critical in robotics. Generalizing a set of security mechanisms across different scenarios of application leads to either vulnerable deployments or over-engineered ones. Threat modeling will help you understand better the security requirements for your use case.
  • Engineer and deliver better solutions: By considering your security flaws and requirements early in the process, you can dramatically lower the odds that you’ll be re- designing, re-factoring or facing a constrant stream of security bugs. Threat modeling allows you to optimize resources and focus on whatever your customers want from you.

System description

ROS 2 threat modeling, system description

The application considered is a MARA modular robot operating on an industrial environment while performing a pick & place activity. MARA was launched as the first robot to run ROS 2 natively. It is an industrial-grade collaborative robotic arm which runs ROS 2 on each joint, end-effector, external sensor or even on its industrial controller. Throughout the H-ROS communication bus, MARA is empowered with new possibilities in the professional landscape of robotics. It offers millisecond- level distributed bounded latencies for usual payloads and submicrosecond-level synchronization capabilities across ROS 2 components.

Built out of individual modules that natively run on ROS 2, MARA can be physically extended in a seamless manner. However, this also moves towards more networked robots and production environments which brings new challenges, especially in terms of security and safety. The robot considered is a MARA, a 6 Degrees of Freedom (6DoF) modular and collaborative robotic arm with 3 kg of payload and repeatibility below 0.1 mm.

The robot can reach angular speeds up to 90º/second and has a reach of 656 mm. The robot contains a variety of sensors on each joint and can be controlled from any industrial controller that supports ROS 2 and uses the HRIM information model. Each of the modules contains the H-ROS communication bus for robots enabled by the H-ROS SoM, which delivers real-time, security and safety capabilities for ROS 2 at the module level.

ROS 2 abstractions

ROS 2 threat modeling, ROS 2 abstractions

Architecture Dataflow

The architecture dataflow describes the different components that play a role on the system and the interaction between different mechanims and channels of communication.

ROS 2 threat modeling, architecture dataflow

Relevant assets are also covered as part of the architecture analysis and listed in this section. The following image provices an example:

ROS 2 threat modeling, partial assets

Application components and trust boundaries

As part of a threat modeling process, understanding the different components involved and the boundaries between them is critical.

Application components and trust boundaries in robot threat modeling

The diagram below displayes the resulting trust boundaries of threat modeling a ROS 2 industrial manipulator arm:

Trust Boundaries Diagram for a ROS 2 robot

Analysis and modeling

The objective of this threat analysis is to identify the attack vectors for the robot, MARA. An attack vector is a path that an attacker could follow to perform an attack on the system. Several attack vectors have been identified and classified depending on the risk and services involved. Risks will be detailed using threat modeling methodologies, namely STRIDE and DREAD. Using the information previously gathered, threats are described and possible mitigations are listed.

Threat modeling robots, methodologies and general threat tables

Below we provide one of the generic threat tables applying both methodologies:

Threat modeling robots, generic threats

Attack trees

Attack trees help further analyze and visualize potential attack vectors identified in previos steps. These diagrams often speculate about the possible attacks against the system and allow researchers to reason about them in order to be able to counter potential attacks. In our case, attacks are ordered starting from the physical attack vector, continuing with network based attacks, and finishing with the support infrastructure for the robot.

Threat modeling robots, displaying the attack trees generated for a ROS 2 industrial robot

The following diagram shows one of the attack trees:

Exemplary attack tree for a ROS 2 industrial robot

What's next?

Threat modeling is only the first step towards defending your robotic systems from security threats. Our team can take you to the next level and further support you offering the following robot cybersecurity services:

  • Assessments:

    • Physical robot hacking: On-site (either in your offices or in ours) direct robot hacking. Relevant attacks are performed on the robot in order to detect flaws including weaknesses and vulnerabilities or erratic behaviour. This exercise produces a realistic output and allows Alias Robotics' engineers to provide a direct assessment (including exploits and mitigation proposals) of the robot insecurities.

    • Virtual robot hacking: Remote robot hacking, either via remote VPN access to the robot or through simulation. Alias Robotics builds a virtual setup for your robot and performs security tests to find flaws including weaknesses, vulnerabilities or erratic behaviors while delivering the corresponding exploits with mitigation proposals. Depending on the customer's demands, the assessment is performed either in the robot itself or in simulated versions of it.

    • Robot code testing: We test source code an look for security flaws using a variety of techniques including static and dynamic analysis.

  • Consulting:

    • Security standards compliance: We are experts in robot cybersecurity and have been participating in standardization committees for years. Our team can help you or take complete control of the compliance with security and safety standards for your robots.
    • Robotic Software Development Lifecycle (RSDL): Analysis and improvement of the software development process from a security perspective. We introduce and automate security analysis in the development cycle helping your team avoid unwanted backdoors and vulnerabilities (SecDevOps) in robots while writing code.

Read more about our services at https://aliasrobotics.com/services.html.