ROS is rapidly becoming a standard in robotics, including its growing use in industry. The commonly held assumption that robots are to be deployed in closed and isolated networks does not hold any further and while developments in ROS 2 show promise, the slow adoption cycles in industry will push widespread ROS 2 industrial adoption years from now. ROS will prevail in the meantime so we wonder, can ROS be used securely for industrial use cases even though its origins didn't consider it?

This essay summarizes the work my team and I conducted over the last period tackling this question. For more, refer to the following resources:

Is it secure to use ROS in industry?

The Robot Operating System (ROS) is the de facto framework for robot application development. According to the ROS community metrics that are sampled every year on July, more than 20 million total downloads of ROS packages happened in July 2019. A shocking number given the small size of the robotics community. At the time of writing, the original ROS article has been cited more than 7000 times, which shows its wide acceptance for research and academic purposes. ROS was born in this environment: its primary goal was to provide the software tools that users would need to undertake novel research and development. First with the PR2 robot while being developed at Willow Garage, and then for the overall robotics community with the creation of the Open Source Robotics Foundation in 2012.

ROS' popularity has continued to grow in industry supported by projects like ROS-Industrial (ROS-I for short)[1], an open-source initiative that extends the advanced capabilities of ROS software to industrial relevant hardware and applications. Spearheaded by the ROS-Industrial consortium, its deployment in industry is now a reality. The consortium has more than 80 members and its gatherings in Europe, USA and Asia bring together hundreds of robotics experts every year.

ros_readteaming_scenario

Use case architecture diagram. The synthetic scenario presents a network segmented in 5 levels with segregation implemented following recommendations in NIST SP 800-82 and IEC 62443 family of standards. There are 6 identical robots from Universal Robots presenting a variety of networking setups and security measures, each connected to their controller. $\hat{S_n}$ and $\hat{C_n}$ denote security hardened versions of an $n$ control station or controller respectively.

With dozens of publicly available speeches on how ROS is being used for automation tasks, open source tools available and system integrators picking ROS for real problems under safety constraints, we argue that it is nowadays a relevant piece of software used for industry. Unfortunately, as it's often common in industry, security is not a priority.

ROS was not designed with security in mind, but as it started being adopted and deployed into products or used in government programs, more attention was placed on it. Some of the early work on securing ROS include [2], [3] or [4], all of them appearing in the second half of 2016. At the time of writing, none of these efforts remain actively maintained and the community focus on security efforts has switched to ROS 2, the next generation of ROS. ROS 2 builds on top of DDS and shows promise. However, to the best of our knowledge, there're still no known robots running ROS 2 in production at scale. From our experience analyzing robots used in industry, their operating systems, libraries and dependencies, we argue that ROS 2 is still years from being widely deployed for major automation tasks. Until then, ROS will prevail.

Research question

With the advent of ROS in industry and professional use, one question remains:

Even though ROS was not designed with security in mind, can companies use it securely for industrial use cases?

The work introduced in here tackles this question experimentally by performing a targeted security exercise, namely red teaming, to determine whether ROS and more specifically, ROS and ROS-Industrial packages could be used securely in an industrial setup. We construct a synthetic industrial scenario and choose one of the most common industrial robots with ROS-I support to build it. We then apply available security measures to the setup following official recommendations and program a simple flow of operation.

Using this setup, we perform a red teaming exercise with the following two goals:

  • Goal $G_1$: Control, deny access or disrupt the ROS computational graph.
  • Goal $G_2$: Control, deny access or disrupt the operation of robots (ROS-powered or not)[5].

To achieve these goals, we create four different attacks that target the ROS-Industrial and ROS packages. The results show that ROS Melodic Morenia presents several unpatched security flaws, even when hardened with community recommendations. For details on the attacks, refer to [6].

Red teaming

ros_readteaming_scenario

Attack targeting ROS-Industrial and ROS core packages. The attacker exploits a vulnerability present in a ROS package running on $\hat{S_7}$ (actionlib). Since $\hat{S_7}$ is acting as the ROS Master, segregation does not impose restrictions on it and it is thereby used to access other machines in the OT level to send control commands.

Red teaming is a full-scope, holistic and targeted (with specific goals) attack simulation designed to measure how well a system can withstand an attack. Opposed to Penetration Testing (pentesting or PT), a red teaming activity does not seek to find as many vulnerabilities as possible to risk-assess them, but has a specific goal. Red teaming looks for vulnerabilities that will maximize damage and meet the selected goals. Its ultimate objective is to test an organization/system detection and response capabilities in production and with respect a given set of objectives. Past works in robot cybersecurity criticize the current status of cybersecurity in robotics and reckon the need of further research. Previous attempts to review the security of robots via offensive exercises or tools mostly focus on proof-of-concept attacks and basic penetration testing, detecting flaws in ROS. A recent study [7] mentions the identification of several flaws within ROS-Industrial codebase, however it does not explicitly describe ROS-specific flaws. Considerations are made with regard the open and insecure architecture predominant in ROS-Industrial deployments throughout its open source drivers. From interactions with the authors of [7:1], it was confirmed that the reported security issues were made generic on purpose, further highlighting the need for further investment on understanding the security landscape of ROS-Industrial setups.

To the best of our knowledge, no prior public work has performed a red teaming activity on ROS-Industrial packages (or in any other robotics technology for that matter), and challenged its security extensions. The work introduced in here presents a study in which we aim to do so in a realistic industrial scenario.

Discussion

Findings

Attack Description Goals met
$A_{1.1}$: remove arbitrary code execution Subject to some prior interactions, attacker with control of $D_1$ is able to exploit a vulnerability in ROS and launch arbitrary remote code executions from a privileged ROS end-point compromising completely the computational graph $G_1$ and $G_2$ ($R_1$, $R_2$, $R_3$, $R_4$ and $R_5$)
$A_{1.2}$: privilege escalation Subject to local access, attacker is able to exploit a vulnerability in ROS and escalate privileges (to the ROS ones) in such machine $G_1$
$A_{2}$: FIN-ACK flood attack targeting ROS Attacker attempts to deny ROSTCP connection on target destination by forcing a maxed-out number of connections $G_1$ and $G_2$ ($R_1$, $R_2$, $R_3$, $R_4$ and $R_5$)
$A_3$: PitM attack to a ROS control station & Attacker poisons ARP tables and gains access to the network flow of information siting between targeted publishers and subscribers, interfering with communications as desired. $G_1$ and $G_2$ ($R_1$, $R_2$, $R_3$, $R_4$ and $R_5$)
$A_4$: Insider endpoint via unprotected robot controller Attackers exploit known vulnerabilities in a robot endpoint to compromise the controller and pivot into the ROS network. $G_1$ and $G_2$ ($R_1$, $R_2$, $R_3$, $R_4$, $R_5$ and $R_6$)

$G_1$ is achieved in all the presented attacks whereas $G_2$ is mostly achieved yet depends on the hardening of the corresponding control stations and robotic endpoints.
At the time of writing, among the vulnerabilities we exploited most remain active. An exception is RVD#2401 which got resolved by Open Robotics within 30 hours from the moment we submitted a mitigation.

Lessons learned

Through our experiments we showed how control stations running Ubuntu 18.04 do not protect ROS or ROS-Industrial deployments. Moreover, the guidelines offered by Canonical [8] for securing ROS are of little use against targeted attacks, as demonstrated. Certain ongoing hardening efforts for ROS Melodic [9] helped mitigate some issues but regardless, most goals were still achieved with attacks targeting threats like zero days, wide and availability of industrial components, inadequate security practices or non-patched OS and firmware.

control stations running Ubuntu 18.04 do not protect ROS or ROS-Industrial deployments. Moreover, the guidelines offered by Canonical [8:1] for securing ROS are of little use against targeted attacks, as demonstrated.

Dedicated robotic security protection systems like the Robot Immune System (RIS) used in $\hat{C_2}$, $\hat{C_5}$ or $\hat{C_6}$ managed to secure the corresponding robot avoiding directed attacks however $R_2$ and $R_5$ robots were stillhijacked by compromising the ROS computational graph via their control stations. RIS was not able to stop these attacks because they came from trusted sources whose behavior was learned over a prior training phase. An exception was $R_6$ which we were not able to compromise thanks to the Robot Immune System (RIS) being installed at $\hat{C_6}$ whereas $R_3$ (not protected) was easily compromised and used as a rogue endpoint for attackers to pivot into other malicious endeavors. From this, we conclude that industrial scenarios like the one presented in this use case using ROS must not only follow ICS guidelines but also harden robot endpoints and the ROS computational graph.

Due to constraints on resources and time, the following items remain open and might be tackled in future work:

  • We showed how Ubuntu Bionic 18.04 was not a valid starting point for secure ROS (Melodic Morenia) industrial deployments. In the future we will look into other Linux file systems and Operating Systems as a starting point. Particularly and given Windows' popularity in industry and its recent activity and support of ROS for development, we recommend its security evaluation in future research efforts.

  • The security mechanisms in the Robot Immune System (RIS) do not currently allow it to detect threats on its interconnecting components (other devices) and seems a difficult endeavour since it would require RIS (at the endpoint) to constantly monitor and exchange communications with other segments of the industrial network (which will further compromise some of the segmentation and segregation assumptions). Instead, we believe future work should focus on a) reviewing the interoperability services offered by RIS in the robotic endpoint while ensures Zero Trust principles are applied and b) guarantee ROS computational graphs can be hardened regardless of their packages.

  • We only applied a subset of ISA/IEC 62443 and was included into the use case scenario via the hardening step. Future work should extend our setup and complement it with additional security measures following this norm. Though we strongly believe this is of valuable research interest, our interactions with industrial operators indicate that the level of compliance with ICS standards is still on its early phases. Correspondingly, we reckon that the use case assumed while synthetic, captures an already high degree of security measures when compared to real scenarios.

  • While we failed to find exploitable security flaws within the triaged ROS-Industrial drivers, further work needs to be put into mitigating existing ones archived in RVD. Moreover, we encourage for a periodic review of the drivers using both static and dynamic testing.

  • We consider it would be extremely interesting to analyze the dynamics of having heterogeneous robots, from different vendor in a security case study. Future work might consider to extend the scenario we assumed with robots from mixed vendors, mixing ROS packages and incurring into a much more complex software engineering security scenario.

Conclusions

We presented four targeted attacks over a synthetic industrial scenario constructed by following international ICS cybersecurity standards where the control logic is operated by ROS and ROS-Industrial packages. Our attacks exploited both new and known vulnerabilities of ROS achieving the two goals we set. We managed to execute code remotely ($A_1$) in a ROS end-point, disrupt the ROS computational graph ($A_2$), impersonate a ROS control station through PitM ($A_3$) and finally use an unprotected robot endpoint to pivot into the ROS network ($A_4$).

The original research question posed whether ROS could be used securely on industrial use cases. Based on our experimental results, we found: With the current status of ROS, it is hardly possible to guarantee security without additional measures.

With the current status of ROS, considering open resources and their status, it is hardly possible to guarantee security without additional measures.

Acknowledgements

This research has been partially funded by the European Union‘s Horizon 2020 research and innovation programme under grant agreement No 732287 under ROSin project through the FTP RedROS-I [10]. Thanks also to the Basque Government, throughout the Business Development Agency of the Basque Country (SPRI). Special thanks to BIC Araba and the Basque Cybersecurity Centre (BCSC) for the support provided. This research was also financially supported by the Spanish Government through CDTI Neotec actions (SNEO-20181238).

The following names presented in no particular order helped, advised or supported bringing up this work: Bernhard Dieber, Stefan Rass, Martin Pinzger, Alejandro Hernández Cordero, Alfonso Glera, Odei Olalde, Lander Usategui San Juan, Gorka Olalde, Xabier Perez-Baskaran, Iñigo Ibiriku, Oxel Urzelai and Nuria García.

Reproduction and results availability

Our setup can be reproduced using the following:

alurity.yaml file to reproduce our setup 
############
# Networks
############
networks:

  # Level 1: Control Networks, connect controllers and control stations
  #  for each controller, we expect a dedicated control-network  w
  - network:
    - name: control-network_c1_s1
    - driver: overlay
    - internal: true
    - encryption: false
    - subnet: 12.0.0.0/24
  - network:
    - name: control-network_c2_s2
    - driver: overlay
    - internal: true
    - encryption: false
    - subnet: 12.0.2.0/24
  - network:
    - name: control-network_c4_s4
    - driver: overlay
    - internal: true
    - encryption: false
    - subnet: 12.0.4.0/24
  - network:
    - name: control-network_c5_s5
    - driver: overlay
    - internal: true
    - encryption: false
    - subnet: 12.0.5.0/24

  # Level 2: Process Network
  - network:
    - name: process-network
    - driver: overlay
    - internal: true
    - encryption: false
    - subnet: 13.0.0.0/24

  # Level 3: DMZ 2 sub-network
  # NOTE: used to interface Process Network with machines in DMZ 2
  #  (e.g. a historian, additional servers and related)
  - network:
    - name: dmz2
    - driver: overlay
    - internal: true
    - encryption: false
    - subnet: 14.0.0.0/24

  # Level 4: IT Network
  - network:
    - name: it-network
    - driver: overlay
    - encryption: false
    - internal: true
    - subnet: 15.0.0.0/24

  # Level 3: DMZ 1 sub-network
  # NOTE: used used to interface IT Network with central control station
  - network:
    - name: dmz1
    - driver: overlay
    - encryption: false
    - internal: true
    - subnet: 16.0.0.0/24

  # Beyond lvl4: Cloud
  - network:
    - name: cloud-network
    - driver: overlay
    - encryption: false
    - internal: false
    - subnet: 17.0.0.0/24

#################################
# Firewalls and network elements
#################################
firewalls:
     - container:
       - name: firewall-it-dmz1
       - ingress: it-network
       - egress: dmz1
       - rules:
         - iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
         - iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
         - iptables -A FORWARD -i eth1 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
         - iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
         - iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE
         - iptables -A FORWARD -i eth2 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
         - iptables -A FORWARD -i eth0 -o eth2 -j ACCEPT
         - route add 13.0.0.20 gw 16.0.0.254 eth2
     - container:
       - name: firewall-process-dmz2
       - ingress: process-network
       - egress: dmz2
       - rules:
         - iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
         - iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
         - iptables -A FORWARD -i eth1 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
         - iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT

############
# Containers
############
containers:

  #
  # Controllers
  #
  # C1
  - container:
    - name: "c1"
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/robo_ur_cb3_1:3.13.0
         # - base: registry.gitlab.com/aliasrobotics/offensive/alurity/robo_ur_cb3_1:3.12.1
         # - base: registry.gitlab.com/aliasrobotics/offensive/projects/rosin-redros-i:3.12.1-controller
         - network:
           - control-network_c1_s1
           # - field-network_r1_c1
    - ip: 12.0.0.20  # assign manually an ip address
    - cpus: 4
    - memory: 2048
    - mount: Controller:/root/.urcaps/

  # C^2
  - container:
    - name: "c2"
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/robo_ur_cb3_1:3.13.0
         # - base: registry.gitlab.com/aliasrobotics/offensive/projects/rosin-redros-i:3.12.1-controller
         - network:
           - control-network_c2_s2
           # - field-network_r2_c2
    - cpus: 4
    - memory: 2048
    - mount: /tmp/ris_install:/tmp/ris_install
    - extra-options: SYS_PTRACE
  # C3
  - container:
    - name: "c3"
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/robo_ur_cb3_1:3.13.0
         - network:
           - process-network
           # - field-network_r3_c3
    - ip: 13.0.0.30  # manually assign an ip address
    - cpus: 4
    - memory: 2048
    - extra-options: SYS_PTRACE
  # C4
  - container:
    - name: "c4"
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/robo_ur_cb3_1:3.13.0
         - network:
           - control-network_c4_s4
           # - field-network_r4_c4
    - cpus: 4
    - memory: 2048
  # C^5
  - container:
    - name: "c5"
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/robo_ur_cb3_1:3.13.0
         - network:
           - control-network_c5_s5
           # - field-network_r5_c5
    - cpus: 4
    - memory: 2048
    - mount: /tmp/ris_install:/tmp/ris_install
    - extra-options: SYS_PTRACE
  # C^6
  - container:
    - name: "c6"
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/robo_ur_cb3_1:3.13.0
         - network:
           - process-network
           # - field-network_r6_c6
    - cpus: 4
    - memory: 2048
    - mount: /tmp/ris_install:/tmp/ris_install    
    - extra-options: SYS_PTRACE

  #
  # Control stations
  #
  # S1
  - container:
    - name: "s1"
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/comp_ros:melodic-scenario
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/comp_ros_ur:melodic-official-scenario
         - network:
           - control-network_c1_s1
           - process-network

    - ip:
      - 12.0.0.50  # ip for control-network_c1_s1
      - 13.0.0.5  # ip in process-network
    - cpus: 4
    - memory: 4096
    - extra-options: NET_ADMIN
  # S^2
  - container:
    - name: "s2"
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/comp_ros:melodic-scenario-hardened
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/comp_ros_ur:melodic-official-scenario
         - network:
           - control-network_c2_s2
           - process-network
    - ip:
        - 12.0.2.50  # ip for control-network_c2_s2
        # - 13.0.0.6  # ip for process-network
    - cpus: 4
    - memory: 4096
    - extra-options: NET_ADMIN
  # S^4
  - container:
    - name: "s4"
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/comp_ros:melodic-scenario-hardened
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/comp_ros_ur:melodic-official-scenario
         - network:
           - control-network_c4_s4
           - process-network
    - ip: 12.0.4.50  # ip for control-network_c4_s4
    - cpus: 4
    - memory: 4096
    - extra-options: NET_ADMIN
  # S5
  - container:
    - name: "s5"
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/comp_ros:melodic-scenario
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/comp_ros_ur:melodic-official-scenario
         - network:
           - control-network_c5_s5
           - process-network
    - ip: 12.0.5.50  # ip for control-network_c5_s5
    - cpus: 4
    - memory: 4096
    
  # S7
  - container:
    - name: "s7"
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/comp_ros:melodic-scenario
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/comp_ros_ur:melodic-official-scenario
         - network:
           - dmz1
           - process-network
    - ip:
      - 16.0.0.20  # ip in dmz1
      - 13.0.0.20  # ip in process-network
    - cpus: 4
    - memory: 4096
    - extra-options: NET_ADMIN

  #
  # Development stations
  #
  # D1
  - container:
    - name: "d1"
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/comp_ros:melodic-scenario
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/comp_ros_ur:melodic-official-scenario
         - network:
           - it-network
           - dmz1
           - cloud-network
           # - process-network  # bypass firewall restrictions by connecting directly
    - ip:
      - 15.0.0.30  # ip in IT
      - 16.0.0.30  # ip in dmz1
      - 17.0.0.30  # ip in cloud
      # - 13.0.0.9
    - cpus: 4
    - memory: 4096
    - extra-options: NET_ADMIN

  #
  # Attackers
  #
  - container:
    - name: attacker_cloud
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/alurity:latest
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/expl_robosploit/expl_robosploit:latest
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/reco_nmap:latest
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/reco_binwalk:latest
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/expl_icssploit:latest
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/expl_rospento:latest
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/expl_rosploit:latest
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/expl_metasploit:latest
         - network:
           # - it-network
           - cloud-network
    - extra-options: ALL

  - container:
    - name: attacker_dmz1
    - modules:
         # - base: registry.gitlab.com/aliasrobotics/offensive/alurity/alurity:latest
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/comp_ros:melodic-scenario
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/reco_nmap:latest
         - network:
           - dmz1
           - process-network
    - extra-options: ALL

  #
  # extra elements
  #

  # connector of
  #  - it-network
  #  - dmz2
  #  - dmz1
  - container:
    - name: firewall-it-dmz1
    - modules:
      - base: registry.gitlab.com/aliasrobotics/offensive/projects/rosin-redros-i:firewall-three-net
      - network:
        - it-network
        - dmz2
        - dmz1
    - extra-options: NET_ADMIN
    - ip:
      - 15.0.0.254
      - 14.0.0.254
      - 16.0.0.254
  # DMZ machine
  - container:
    - name: dmz-server
    - modules:
      - base: registry.gitlab.com/aliasrobotics/offensive/projects/rosin-redros-i:dmz
      - network: dmz2
    - extra-options: NET_ADMIN
    - ip: 14.0.0.20
  # Connector of process-network and dmz2
  - container:
    - name: firewall-process-dmz2
    - modules:
      - base: registry.gitlab.com/aliasrobotics/offensive/projects/rosin-redros-i:firewall-two
      - network:
        - dmz2
        - process-network
    - extra-options: NET_ADMIN
    - ip:
      - 14.0.0.253
      - 13.0.0.254

In an attempt to bring awareness, transparency and fight against the current trend of security-by-obscurity, as a partially funded EU-work, most of our tools have been open sourced at https://github.com/aliasrobotics. Results have also been cataloged at the Robot Vulnerability Database. We encourage roboticists and security researchers to dive into the material generated and help triage remaining flaws.

For more, refer to the Red teaming ROS-Industrial extended report (white paper) (56 pages).

  1. https://rosindustrial.org/ ↩︎

  2. F. J. R. Lera, V. Matell ́an, J. Balsa, and F. Casado, “Ciberseguridad enrobots aut ́onomos: An ́alisis y evaluaci ́on multiplataforma del bastionadoros,”Actas Jornadas Sarteco, pp. 571–578, 2016 ↩︎

  3. B. Dieber, S. Kacianka, S. Rass, and P. Schartner, “Application-levelsecurity for ros-based applications,” in2016 IEEE/RSJ InternationalConference on Intelligent Robots and Systems (IROS), Oct 2016, pp. 4477–4482 ↩︎

  4. R. White, D. Christensen, I. Henrik, D. Quigley,et al., “Sros: Securingros over the wire, in the graph, and through the kernel,”arXiv preprintarXiv:1611.07060, 2016. ↩︎

  5. Note that if appropriate security mechanisms are implemented, control of the ROS network might not necessarily imply control of the robots. ↩︎

  6. Alias Robotics. Red teaming ROS-Industrial extended report (white paper). Retrieved from https://aliasrobotics.com/files/red_teaming_rosindustrial.pdf (56 pages) ↩︎

  7. F. Maggi and M. Pogliani, “Rogue automation: Vulnerabile and maliciouscode in industrial programming,”Trend Micro, Politecnico di Milano, Tech.Rep, 2020 ↩︎ ↩︎

  8. Canonical, “Securing ros robotics platforms,” Canonical, Tech. Rep., 2020. Retrieved from https://pages.ubuntu.com/rs/066-EOV-335/images/Securing ROS_WhitePapaer_10.03.20.pdf ↩︎ ↩︎

  9. R. Daruszka, J. L. Christopherson,et al., “CIS ROS Melodic Morenia benchmark v1.0.0,”. Retrieved from https://workbench.cisecurity.org/benchmarks/5207. Accessed: 2020-08-17. ↩︎

  10. RedROS-I FTP https://www.rosin-project.eu/ftp/redros-i ↩︎

Red Teaming - ROS-Industrial
A red teaming report using the ROS-Industrial platform
ROS-Industrial
Robot red teaming services
Robot red teaming provides an accurate measure of a given robotic technology’s preparedness for remaining resilient against cyber-attacks.