Securing ROS robotics platforms

/

How can we apply security principles and best practices to robotics development?

 
 

Let’s start with this well-known and relatively old quote, still very relevant today. It reminds us that security is a dynamic process that accompanies any system’s lifecycle. This is because new vulnerabilities are constantly being discovered for all kinds of components. The ways software is used, its platform and libraries change too. Software that was considered as secure in the past may not be the case today.

In the past few years, the number of published vulnerabilities discovered in open source has been steadily increasing. Open source is neither more nor less secure than proprietary code. However, few companies understand the breadth of open source that is being used in their applications. This lack of knowledge translates into a lack of awareness about vulnerable components, and this is a source of risk. ROS is certainly no exception, and collective efforts are needed to keep this great community secure.

As you can imagine, through vulnerable robots, organisations may leak sensitive information about their environment, or even cause physical harm if they are accessed by an unauthorised party.

So, what can you do to keep your robots and the data they handle secure? Let’s dive right into some tips.

Securing your robot’s software

What could go wrong?

You may already be aware of what “CVE” and “CWE” stand for. If not, I strongly encourage you to familiarise yourself with these great sources of information on security issues, published by the MITRE organisation. Common Vulnerabilities and Exposures (CVEs) are a catalogue of publicly disclosed security vulnerabilities in all kinds of software and systems. Common Weakness Enumeration (CWE) is a community-developed list of software and hardware weakness types. The Top 25 most common and dangerous security weaknesses are released every year. You can think of this as a “ranking” of the most prevalent and impactful weaknesses experienced over the past 2 years, organised and ranked for you. An interesting fact: many of the top vulnerabilities in the CWE Top 25 have been the same common kinds of vulnerabilities for decades. This means that while things do change, learning about the most common vulnerabilities will be useful for years to come.

Set your robots up for security

In practice, a good place for your team to start is to embrace a secure software development lifecycle process. It ensures that security is an intrinsic part of every stage in your software development. This approach requires that engineers are trained in secure coding best-practices. This may obviously represent an initial investment, but one that will always pay in the long term. A great place to start is by checking out the CISA life cycle processes guidelines.

 
 

Image source: OpenSense Labs

Your projects will likely have many reused software components, and they will need to be updated occasionally. Eventually, a vulnerability may be found in one, so keep an eye out and be ready to quickly update. To stay on top of things, it is a good idea to use Software Composition Analysis (SCA) tools to identify the open source software components in your code, and evaluate elements, such as security, licence compliance, and code quality (for example, they will let you know of known vulnerabilities in your components, and warn you if they are out of date, or have patches available). This will help you keep any libraries being used as up-to-date as possible, to reduce the likelihood of using components with known vulnerabilities (OWASP Top 10-2017 A9). You can check for any vulnerable components by using free tools, such as OWASP Dependency Check or Github’s Dependency Scanning.

It is crucial to keep your OS and software up to date with security updates and CVE fixes. This is a simple and essential practice to avoid becoming an avenue of exploitation. So, apply any security updates as soon as they’re available and it’s feasible for your robots. And remember, you can take further steps to harden your robots. For instance, make sure to close all their unused ports and enable only necessary services. Give the local user the least privileges they need, to prevent privilege escalation should an intruder ever gain access. If you want peace of mind that you are using a hardened OS with built-in security features, check out Ubuntu Core.

Deep dive into your code

There are different types of code-level analysis to implement as a basic measure. Some analyses can be automated and included in a CI/CD pipeline, so you don’t have to rely on manual scans, and luckily there are a number of open source tools to help you in this task. Each one has pros and cons, so combining them will lead to the most comprehensive results. Below are some suggestions for your ROS applications.

Static Analysis tools (SAST) and Fuzzers

The first good practice is to analyse your code statically – that is, without executing even a line of code. As you’ll see, there are plenty of such options, many free and open source. The gcc and clang compilers support using sanitizers that will detect errors in C/C++ code at build time. In particular, if your team is working with code in memory-unsafe languages like C and C++, this is a crucial step. Take a special look at Google Sanitizers’s Address, Leak, Memory, and Undefined Behaviour sanitizers. Other such free tools include LGTM (by GitHub), Coverity, and Reshift.

Fuzz testing or fuzzing is a well-known technique for uncovering programming errors in software, which consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion. Many of these detectable errors can have serious security implications. It’s a great idea to use this practice to validate your SAST findings. Check out Google’s OSS-Fuzz for your fuzzing needs, and when you’re done, save this list of security tools that are free for open source projects.

 
 

Image source: Synopsys

And, just as crucial to the ROS ecosystem, please do report CVEs if you discover any! This will help strengthen the security of ROS code across the whole community. Have a look at the ROS 2 Vulnerability Disclosure Policy when you’re ready to report.

Hey, ROS 2 user

Of course we cannot discuss security in ROS-based robotics without mentioning the ROS 2 security features. The default middleware in ROS 2 is DDS, and there are security features that are baked into its very standard, such as: Cryptography, which implements encryption, decryption, hashing, digital signatures, and so on; Authentication, for checking the identity of all participants in the network; Access Control, which specifies which resources a given participant can access; and Security logging, to record all security-relevant events.

The SROS2 utilities provide a set of tools that make it easier to configure and use these security features. If you’re using or planning to use ROS 2, I encourage you to check out this tutorial, and to then try it out.

Given this clear security benefit of ROS 2 over ROS 1, an obvious step, whenever possible, is to migrate your code to ROS 2. But if you cannot, or simply are not ready to migrate just yet, consider exploring Canonical’s Extended Security Maintenance service for deployed robots. One of the benefits of ROS ESM is that it provides you up to 10 years of security maintenance for ROS and Ubuntu base OS distribution. This can be especially critical to get if you’re still running an unsupported version of ROS.

Join efforts with the larger ROS community

Last but not the least, the reason we’re all here: we’re a community interested in sharing, finding, and offering support to others working with ROS.

In case you’re not familiar with it, the ROS 2 Security Working Group focuses on raising awareness of and improving the security around ROS 2. How can you get involved? Track the wg-security tag on the ROS Discourse, and always get the upcoming meeting announcements. Join the monthly meetings, come and share your use cases, any obstacles you’re facing, and pool efforts with the rest of the ROS community to work through them. We hope to see you there.

Learn more:

You may also consider reading the following materials:

This is a guest post by ROS-Industrial Consortium Americas Member Canonical by Florencia Cabral Berenfus - Canonical, Robotics Security Engineer. This is a follow up to Florencia’s presentation given to the ROS-I membership at the 2021 4th Quarter Members Meeting. https://rosindustrial.org/events/2021/12/ros-industrial-consortium-americas-community-meeting-dec-2021. You can learn more about Robotics at Canonical at https://ubuntu.com/robotics.