Securing Robots is Everyone’s Job

In the Star Wars universe, there is a light side and a dark side (also, just like duct tape). This duality can be represented in almost any area of technology – things designed to be good for humanity can also be turned bad by different people. Time and again, we’ve seen cyberattacks, security breaches and shutdowns caused by people exploiting systems that were designed initially to help people.

The Internet was built with a promise of unlimited information available at everyone’s fingertips, a truly egalitarian and noble concept. But along with the good it continues to provide, the Internet spawned dangers such as the dark web, spam, phishing, fake news and disinformation that spreads via social media and other sites.

The Internet was built with a promise of unlimited information available at everyone’s fingertips, a truly egalitarian and noble concept. But along with the good it continues to provide, the Internet spawned dangers such as the dark web, spam, phishing, fake news and disinformation that spreads via social media and other sites.

Robotics is not immune to this moral ambiguity. In several cases, we’ve seen this technology used to disrupt air travel, such as the use of drones at Gatwick Airport a few years ago and other more sinister threats. Reports of automotive hacking aside, a high-profile incident is likely a matter of when, not if.

Traditionally, many robot deployments in factories have been disconnected from the Internet. But this often provides a false sense of security. The outdated thinking is that isolation is sufficient to keep threats away, but this discounts evidence that many cyberattacks work through someone on the inside – either a disgruntled employee or someone inadvertently enabling outside access through social engineering. We have seen organizations with the highest security needs embrace the cloud, and also use it to improve security through best practices. This is known as DevSecOps.

Many of the mobile robots being deployed in warehouses and other locations today rely on Wi-Fi or LTE networking in order to operate and report data back to a centralized service. Making sure these networks are secure usually requires collaboration between the robotics maker and an enterprise IT team. Security practices of today’s cloud vendors in many ways offer superior protection of critical data than even pure on-premise solutions.

Security and safety threats in robotics are dual concerns that are often intertwined. While safety is concerned with limiting potential physical or economic harm to others, security is primarily concerned with protecting the robot from unauthorized use, it is easy to see how unauthorized use could lead to personal or property damage.

This was a recent discussion topic at a meeting of the Robot Operations Group, where security expert (and white hat hacker) Aaron Turner spoke to the members about how technologies that are aimed to help people can be turned into weapons under the right circumstances.

“There’s a whole wide range of things that can go wrong in the computing world that you need to think about,” said Turner. “You need to find someone who has been raked through the coals … who can do threat modeling for you. Thinking about the worst case scenario for your robot can help you make a plan to secure that scenario from ever occurring.”

Some key takeaways:

• Consider the politics – Turner recalled a story where labor disputes in Mexico led a disgruntled process control engineer to sabotage a cement factory. Overloading the weight sensor on a conveyor belt so the belt thought it had a constant load of limestone, when in fact it was shut down. This led the kiln to overheat, creating a “bomb” waiting to explode. Understanding the context a robotic system is placed in is vital to how security concerns are approached.
• Consider the environment – in the investigations of two crashes of the Boeing 737 MAX airplane, it was discovered that an automated system that was designed to keep the nose up had malfunctioned. The control mechanism was hidden, and the pilot didn’t know what was happening. All it took was a single sensor that froze due to condensation. The sensor thought it was going too far up, and the automated system pushed the nose down. Understanding the environmental context of mechanical and robotic deployments is just as critical as insight into the psychology of the people who work day to day with that technology.
• Single-sensor inputs – when one input fails, you often end up with tragic events. Turner explained that robotics developers need to have redundant sensors for automated systems. “It’s not a matter of if, but when your robotic system will be put on a wall of shame if you are going with a single-sensor environment.”
• Failsafes - Turner recounted working with an insulin pump manufacturer that had programmed its machine to default to pump mode instead of shutting down, which could create a very capable “murder machine”. Turner said companies need to build “fail to safe mode” when designing equipment so that a simple error doesn’t create a dangerous situation.
• Security testing is vital - Turner explained how “red teams” are assembled to perform threat analysis of systems. Depending on the context, this exercise can and does save lives. As they say, an ounce of prevention is worth a pound of cure.

As operations experts, we at InOrbit understand the security and safety concerns that customers have about cloud-based software and robotics. Strong security considerations are an integral part of effective RobOps, and as part of that we help bring DevSecOps best practices to robotics. That's why we designed the InOrbit architecture from the ground up with security as a top priority. Some security measures include, but are not limited to:*

• Robust authentication, including multi-factor authentication and Single Sign-On
• Role-based access control
• Secure channels between streaming APIs and the client SDK
• AES-256 data encryption throughout the pipeline, including real-time and at-rest
• Revocable API keys and a secure channel between servers and the REST API
• Encrypted authorized commands only between the APIs and robots
• Non-revocable audit logging
  

We believe that the job of securing a robotics deployment is everyone’s responsibility, which is why we are happy to discuss our security position with robot developers and people interested in deploying robots within their enterprise. 

At InOrbit we’re committed to continue providing reliably secure RobOps tools and services and driving awareness around best practices for the rapidly growing robotics market. 

*More details are available in our Technical Brief on InOrbit End-to-End Security.