Cybersecurity required for safe IIoT robots

For a robot to be safe, it must also be secure from cyberattacks in the age of Industrie 4.0 and the Industrial Internet of Things (IIoT). Everyone in the information technology (IT) and operations technology (OT) departments are responsible for ensuring this happens.

By Tanya M. Anandan January 15, 2019

For a robot to be safe, it must also be secure. Cyber-physical systems are on the rise. Industrie 4.0 and the vision of smart, connected factories continue to drive the robotics boom.

Savvy manufacturers are using networked robots and the insightful data they generate to simplify robot maintenance, maximize production efficiency, and improve product quality. As more robots are connected to each other, the enterprise and the cloud, cybersecurity risks mount.

These threats go beyond data breaches and production delays. Cyberattacks targeting highly nimble, powerful robotic systems come with serious safety concerns. With the increasing popularity of human-robot collaboration and mobile robots, these concerns are heightened. AI-enabled robots are gaining more autonomy. The real power of today’s robots resides in software that is potentially susceptible to cyberattack.

With the convergence of information technology (IT) and operational technology (OT), cybersecurity is no longer “somebody else’s problem.” In this age of the Industrial Internet of Things (IIoT), cybersecurity is everyone’s responsibility. Threats can penetrate all the way to the shop floor. Cybersecurity requires everyone’s vigilance.

“Cybersecurity has only recently entered people’s minds within operational technology and robotics,” said Nigel Stanley, chief technology officer (CTO) for global OT and industrial cybersecurity at TÜV Rheinland. “It was always seen as an information technology problem. Over the past five years, there has been a big uptick in hackers breaking into operational technology systems.”

TÜV Rheinland is a leader in independent testing, inspection and certification services. Stanley’s area of interest is on the operational technology side of security and includes autonomous vehicles, railroad systems, smart manufacturing, robotics, power stations, and as he puts it, everything in between.

Cybersecurity affects manufacturers of all sizes from large multinationals and small to midsized enterprises (SMEs).

“If you take a typical supply chain, you may have a facility that is quite secure, but the supply chain is insecure,” Stanley said. “If hackers were launching an attack against a plant, looking at the supply chain and at smaller manufacturers that provide equipment, such as robots, would be an easier target. This is something that big and small manufacturers need to consider.”

Robot manufacturers, integrators, operators share responsibility

When it comes to responsibility for cybersecurity, the onus rests on many levels. In the robotics space, basically three groups share responsibility. It starts with device manufacturers. These are the designers and makers of robots, robot controllers, and ancillary devices such as machine vision sensors that give robots sight.

“Manufacturers are responsible for making sure their product is as secure as it can possibly be,” Stanley said. “When they are designing a product, they need to make sure they are implementing security measures throughout the design process and writing firmware that is as secure as possible. You then have the implementers, or systems integrators. They take the manufacturer’s product and apply context to it, and that context can impact cybersecurity. Finally you have the operators, the people actually running the production plant. Their job is to make sure the plant remains secure for the lifetime of the equipment and systems in a way that ensures any cyber risks are mitigated as quickly as possible.”

Visions of robot arms thrashing wildly about, or mobile robots running amok through the factory, may be what come to mind when you think of a cyberattack. In reality, the more likely scenario is far more insidious. In fact, it can be downright stealthy. Take, for example, the case of Stuxnet, which might be the world’s first cyber-physical attack.

Repeatability is a robot’s greatest strength, but it can become a liability if control falls into the wrong hands. A malicious attack that alters the rotation of a robot axis by a few degrees could exceed part tolerances, jeopardizing quality and impacting downstream processes.

Robot firmware and software can be attacked in the same way unpatched vulnerabilities in operating systems can be exploited to gain control over a PC.

“Ultimately, no system is entirely safe,” Stanley said. “It’s a tough challenge. A stealthy attack can be very damaging, because a company could produce a large number of components before they realize there is a problem.”

Threats can come from many sources, either unwitting or intentional, and even from within.

Defense-in-depth benefits for robots

IIoT architecture is multilayered and multidimensional. Typically attackers will find the weakest link.

The “defense in depth” concept is a hallmark of cybersecurity best practices. In this strategy, multiple layers of security exist so if a layer fails, subsequent layers can provide the necessary security defenses.

“If you have these multiple layers, then you still have a reasonable chance of protecting your system,” said Mike Medoff, CFSE, CISA, director of cybersecurity certification for exida. “Maybe attackers can compromise one or two layers, but the more steps they have to go through, the harder it is for them to compromise the system. Eventually they will give up if you make it hard enough.”

At the very least, a defense in depth strategy will delay the attacker and allow time for detection and response measures.

“It’s not like you can put one big fence around everything and that protects it,” Medoff said. “People have found ways around those fences. You essentially want to build security into each layer of your control system architecture.”

Medoff describes some of the components, layer by layer.

“Within the robot itself, there’s usually an embedded operating system. Then there’s the application code that runs on that robot. A big area is all the communications code that will take and process commands to the robot. What that’s connected to can obviously vary, but it’s usually connected to systems that are more PC-based. Those systems might have databases on them, or configurations relevant to the robot, and then their own operating system. Then you have the cloud servers and their software that communicates to the devices, to the robots, and to the users over the web interface.”

exida is a certification and knowledge company specializing in automation system safety, alarm management, and control system cybersecurity standards implementation. While the company works with product developers, integrators, and end users to evaluate systems for functional safety and cybersecurity, Medoff concentrates more on the development side. Recently, he finds himself working more often with mobile robot developers.

“I sometimes work with startups that are concerned about safety and cybersecurity, so they are engaging our services from the beginning,” Medoff said. “Usually you don’t see that. Startups typically just focus on getting a product out the door. But I do see that starting to change.”

Savvy companies are getting proactive and realize cybersecurity requires a team approach.

Offense vs. defense

Within the security field, there are two basic approaches to cybersecurity: offense and defense.

Nathaniel Cole is chief technology officer (CTO) for Cybersecurity Testing and Certification. His team is on offense. They actively test client’s devices during both development and the final implementation state. This testing extends beyond robotics and industrial systems to enterprise IoT for the consumer, medical and energy sectors, among other industries.

“We’re there to find holes, to potentially break the device or break the system, or break the infrastructure, and show how that can happen,” Cole said. “As best we can, we mimic malicious actors, their motives, and act upon the threats that might be identified within the device.”

Testing applies to more than just the device itself. It involves the entire ecosystem an attacker would have access to (as shown in the diagram). This includes the device enclosure and the hardware, user and network interfaces; any data deployed to the device, such as third party libraries and custom source code for the device’s smart application; any mobile applications that connect to the device; and any systems the device communicates with may be housed either in the cloud or on the corporate network.

“On the defensive side,” Cole said, “you might have monitoring or threat analytics. You’re looking at the behavior of individuals, of systems, of devices that reside on the network, in order to detect and respond to potential malicious activity.”

This defensive role can extend into implementing and maintaining controls to help with protecting these devices. Examples include firewalls, air gaps, network configuration, and logs.

Whether offensive or defensive, neither role is better than the other. Both are needed for a comprehensive program.

Risky by default

It’s critical for robot operators, or end users, to change the default user names and passwords at initial setup of a device. Robots installed with their default passwords are easy prey for hackers.

“Having manufacturers force operators to change the default passwords and user names at setup would go a long way to securing these devices,” Cole said. “It’s not just the robotics industry. There have been malware and breaches of cameras, thermostats and routers.

“As robotic devices become interconnected, secure communication is not necessarily implemented,” Cole continued. “As offensive security practitioners, we wouldn’t necessarily be able to break in and gain access, but somebody that is within the network certainly would be able to see this communication. You can start to figure out how to manipulate that traffic and potentially gain a level of access to that robotic machine. We’ve seen that, where we’re potentially able to gain administrative capabilities through the network interface and completely change how that robotic device is working. It’s not being secured, encrypted, or hashed in some way to obfuscate the data going back and forth. It’s no longer providing data integrity, but it’s also no longer providing security for that device. Because now, we know how to interact with it.”

Secure by design

Cybersecurity for robotics is still an immature field. Cole said the robotics industry is starting to understand its importance and how to implement security from the initial design all the way through to robot implementation.

“It’s not just the manufacturer’s responsibility,” he said. “The implementer (robot integrator) is important, but you still have the operator who will be running that device day in and day out, who has a responsibility to build security in depth. That goes beyond the device itself and that implementation, out to their perimeter, their internal networking construct and capability.”

The entire ecosystem must be taken into consideration. This is especially critical in remote monitoring applications.

“If you have remote monitoring capability and you have a web interface that is accessible through your desktop browser as well as your mobile phone, those come into play as well because you’re sending data back and forth,” Cole said. “You would want some level of security assurance that the data you’re seeing within the remote monitoring capability devices is secure.

You also have to consider all the software at play, including software for ancillary devices such as machine vision cameras, functional safety devices like laser scanners, other sensors, and robot end-of-arm tooling. Cole said the user needs to secure the integrity of the input from such devices so it’s not being manipulated to make the robotic arm or controller do something it’s not supposed to do.

“It’s important to keep in mind that for the manufacturers, it’s not that they need to build 100% secure robotics,” Cole said. “They are trying to build something that is used for more than one use case. They want to allow for creativity on the part of the implementers and operators to use that robotic controller and arm with its different attachments however they may want to use it. That makes it very difficult to build in security, because the manufacturer doesn’t know all the implementation cases. But they can build components that allow the implementers and operators to take it over the finish line to secure it. Defense in depth and collaboration are needed to secure these functions.”

Debug software is critical

Buggy software is a primary entry point for cyberattackers, according to Medoff. Bug-free software is critical to the IIoT robotics system.

“People don’t understand that the source of vulnerabilities are typically bugs in the software,” Medoff said. “You need to prevent them at the source, which is when you’re developing the product, and not afterwards, which tends to happen more often today.”

Medoff said a common misconception is people assume software bugs come with the territory and will always exist.

“They don’t have to always exist if we can get companies to change the way they develop their products. That might be a huge hurdle, but I think it’s something that has to be done. As long as you have all those bugs and vulnerabilities, you’re fighting a losing battle. The weakest link in the system is the one that can be attacked, so all these different layers have to be protected,” Medoff said. “It’s really hard to do that unless everyone is following the same playbook.”

That’s where industry standards come into play.

Cybersecurity automation standards

The International Electrotechnical Commission (IEC) in agreement with the International Society of Automation (ISA) published a series of standards and technical reports that define procedures for implementing secure Industrial Automation and Control Systems (IACS). The standard provides guidance to those that create products, integrate systems, and operate industrial automation and control systems.

The ISA/IEC 62443 standard contains seven foundational requirements (FR). Stanley recommends robot manufacturers make sure their products meet as many of these requirements as possible.

  • FR 1 Identification and authentication control (IAC). Protect the device by verifying the identity of and authenticating any user requesting access;
  • FR 2 Use control. Protect against unauthorized actions on the device resources by verifying the necessary privileges have been granted before allowing a user to perform the actions;
  • FR 3 System integrity. Ensure the integrity of the application to prevent unauthorized manipulation;
  • FR 4 Data confidentiality. Ensure the confidentiality of information on communication channels and in data repositories to prevent unauthorized disclosure;
  • FR 5 Restricted data flow. Segment the control system via zones and conduits to limit the unnecessary flow of data;
  • FR 6 Timely response to events. Respond to security violations by notifying the proper authority, reporting needed evidence of the violation, and taking timely corrective action when incidents are discovered;
  • FR 7 Resource availability. Ensure the availability of the application or device against the degradation or denial of essential services. If properly addressed, these requirements will reduce many cybersecurity risks across an industrial robot system.

Standards provide an easier way for companies to assess their suppliers and determine if they have the proper security protocols in place.

“If I was a robot manufacturer and I wanted some sort of endorsement for my cybersecurity, then I would want my robot to be assessed against IEC 62443,” Stanley said. “The beauty of that is you can actually assign a security level after you’ve done the assessment to determine how secure the robot is.”

When robotics suppliers and users are looking for partners to help them tackle the multilayered complexities of cybersecurity, it’s important to consider the service supplier’s track record and experience. A team that understands the manufacturing space, particularly the automation realm, and has a working knowledge of industry standards, is a good bet.

There are vulnerabilities at every level of the IIoT robotics system. It’s everyone’s responsibility to assess and mitigate potential cybersecurity risks. For a robot to be safe, it must also be cyber safe.

Tanya M. Anandan is contributing editor for the Robotic Industries Association (RIA) and Robotics Online. RIA is a not-for-profit trade association dedicated to improving the regional, national, and global competitiveness of the North American manufacturing and service sectors through robotics and related automation. This article originally appeared on the RIA website. The RIA is a part of the Association for Advancing Automation (A3), a CFE Media content partner. Edited by Chris Vavra, production editor, Control Engineering, CFE Media, cvavra@cfemedia.com.

Original content can be found at www.robotics.org.


Author Bio: Contributing editor, Association for Advancing Automation (A3).