How to apply zero trust architecture in robotics

In today’s industry, robots are widely used and weakly secured. Few enterprises deploy their industrial architecture as recommended by an increasing number of safety standards, and only a reduced number rely on security solutions that detect issues (but not prevent!) at the network level. This insecure landscape lead us to create an Endpoint Protection Platform (EPP) that directly acts at the robot level, the Robot Immune System and to adopt a network architecture that assumes no trust, a Zero Trust Architecture.

The original content of this article was made available at the Workshop on Security and Privacy in Robotics during the 2020 International Conference on Robotics and Automation (ICRA). Briefly,we summarize the core concepts of zero trust and argue on why a zero trust architecture is required and how to implement it on an industrial setup with robots.

Zero Trust Architecture in Robotics - Watch Video

Defining a ’typical’ industrial architecture

We’ll take as a reference scenario a typical industrial architecture environment composed by multiple levels and tons of insider and outsider potential attackers and entry points. This architecture has been defined based on a number of different norms, standards and special publications, particularly, for those interested, NIST Special Publication 800-82 is a good read ^[1].

Following NIST's guidelines, we recommend to establish 5 levels of security:

LEVEL 4: IT network: The network that directly interfaces with the cloud or the Internet. Protection and firewall systems stand in this level, where usually security systems or entities, such as a SOC or a SIEM, are included.
LEVEL 3: Operations (ICT/DMZ): The operation level is a boundary, also known as the demilitarized zone, where the IT upper level (level 4) and the OT below level (level 2) are able to access the resources or entities.
LEVEL 2: Process network: In this level remain most of the elements or entities that control the overall industrial process: control stations, HEM, SCADA systems, etc.
LEVEL 1: Control network: Systems that are dedicated to particular control activities, such as collaborative robots (controllers) or PRC for dedicated machinery control.
LEVEL 0: Field network: The machinery or the mechanics of the robots, this is, the manipulator.

Although this is the “ideal” architecture recommended by the norms, reality is quite different. Over the past month, at Alias, we’ve got the chance to inspect and help secure lots of different setups in collaboration with clients and we admit that it’s very rare to find industrial architectures that present these 5 network levels; most of them present 2, some 3, rarely 4.

How industrial architectures are ‘slightly’ secure

The presented industrial architecture is based on perimeters, in particular, segmentation and segregation to secure networks. There are also existing solutions that can make it even more secure, however, they generally act in the network level and without reaching endpoints.

Given the safety hazards that are present in robotics, protecting endpoints from the inside is a must in robotic, staying at the network level for detection is not enough.

Consider a compromised control station where a cyber-criminal could easily take control of the robot without being stopped causing human or environmental damages. Network solution will not stop this. They may detect some unexpected traffic, but because this type of solutions are not specifically designed or connected with robots, we're exposed to risks.

Several manufacturers care very little about cyber security as demonstrated in the past ^[2]. Often, solely about safety, being safety the activity that ensures that a robot doesn’t harm the environment. However, if the environment itself affects the robot, how can we ensure that the robot it’s gonna stay safe? That’s the main difference between safety and security. Fortunately, many of the existing standards for safety such as the ISO-10218 “Safety requirements for industrial robots” is changing towards requesting vendors manufacturers to care about cyber security.

Robots themselves are insecure

Robots need to be protected from cyber threats from the inside to make sure they operate safely.

It’s a big mistake that’s not being directly tackled in the field of robotics, security needs to come first, needs to be ensured at the robot level.

What leads us to understand that the existing cyber security solutions for industrial control systems are not enough to make sure that robots don’t present hazards.
The challenge becomes even more difficult when we are aware that it’s not only a problem in the network architecture, but that also the devices itself have huge unpatched security flaws.

Large part of our work in Alias Robotics’ focuses on this matter and we’ve conducted diverse exercises in which we’ve demonstrated how vulnerable robotic systems can be ^[2:1].

Castle-and-moat security in robotics

Castle-and-moat (used for many years in IT and OT) is an architecture that assumes that as old big castles there’s a wall, with a moat, that protects insiders from outsiders. But once you’re inside, you’re fully trusted. This is translated to perimeters that once crossed, everything within the internal boundary will be trusted and hence, the robotic system could be easily compromised. If any of the internal subsystems within the OT area are compromised, it may directly affect the robots, which are a very sensitive part of the overall industrial process.

Zero trust architecture in robotics

Zero Trust (ZT) is a security model that makes no trust assumptions and demands strict identity verification for every person, device or component trying to access resources on a network, regardless of whether they are sitting inside or outside of the network perimeter. Zero Trust Architecture (ZTA) ^{[3] [4]} is a cyber security plan that utilizes Zero Trust concepts and encompasses component relationships, workflow planning, and access policies.

Building upon previous work ^{[5] [6] [7] [8] [9] [10]}, we highly recommend considering Zero Trust and further describe the 7 principles of ZTA applied to robotics:

TENET	Principle	Interpretation in robotics
ZTA1	All data sources and computing services are considered re-sources.	All sources of data and devices performing some computation and interacting over a network are considered resources. This includes from general purpose personal computers to tiny application specific microcontrollers going through external software as a service (SaaS).
ZTA2	All communication is secure regardless of network location.	Network location does not imply trust. Access requests from internal networks must meet the same security requirements as access requests from external networks. All communication should be done in the most secure manner available, protect confidentiality (encryption), integrity (digital signatures), and provide source authentication.
ZTA3	Access to individual resources is granted on a per connection basis.	Trust in the requester (assuming it is first authenticated) needs to be authorized before the access is granted. Authorization to one resource will not automatically grant access to a different resource.
ZTA4	Access to resources is determined by policy, including the observable state of user identity and the requesting system, and may include other behavioral attributes.	An organization protects resources by defining what resources it has, who are its members, and what access to resources those members need via policies. A policy is the set of access rules based on attributes that an organization assigns to a user, data asset, or application. Least privilege principles are applied to policies in order to restrict both visibility and accessibility. Observable state of user identity includes the network credentials any associated attributes. Observable state of requesting system includes device characteristics such as software versions installed, network location, previously observed behavior or installed credentials, among others. Behavioral attributes include automated user analytics, device analytics, and measured deviations from observed usage patterns.
ZTA5	The company ensures all owned and associated systems are in the most secure state possible and monitors systems to ensure that they remain in the most secure state possible.	A Continuing Diagnostics and Mitigation (CDM) program should be in place to monitor the state of systems and apply patches/fixes as needed.
ZTA6	All resource authentication and authorization are dynamic and strictly enforced before access is allowed.	There is a constant cycle of access requests, scans, threat assessment, adaptation, and continuous re-evaluation of trust. A network implementing a ZTA strategy would be expected to have Identity, Credential, and Access Management (ICAM) and asset management systems in place.
ZTA7	The company collects as much information as possible about the current state of network infrastructure and communications and uses it to improve its security posture.	A company or a system adopting ZTA should collect data about network traffic and access requests, which is then used to improve policy creation and enforcement. This data can also be used to provide context for access requests from subjects.

These principles are translated to the industrial architecture case study, by introducing two new entities (and discarding the traditionally centralized CAs). The new entities are:

• The PEP, Policy Enforcement Point: the gatekeeper between any interaction with any two resources. PEP enforces the policy. The authorization and authentication is done in a non-trusted manner, via directly the PEP, which needs to be accessible to all the resources.
• The PDP, Policy Decision Point: it communicates with the PDP to apply the selected policy. Only the PDP evaluates the policy, using a number of different data sources. PDP and PEP can be architecturally separated for security reasons, but the PEP needs to be exposed.

Altogether allows us to establish a secure architecture for robots in an industrial setup that when having one particular robot compromised doesn’t compromise the rest of the infrastructure (other robots). This, as advised, turns to be really critical on current robotic systems, which are vulnerable and weakly secured.

---

1. Stouffer, K., Falco, J., & Scarfone, K. (2011). Guide to industrial control systems (ICS) security. NIST special publication, 800(82), 16-16. ↩︎

2. Alias Robotics. Week of Universal Robots' bugs https:// news.aliasrobotics.com/week-of-universal-robots-bugs-exposing- insecurity/ ↩︎ ↩︎

3. S. Rose, O. Borchert, S. Mitchell, and S. Connelly, “Zero trust architecture draft (2nd), nist specialpublication 800-207,” National Institute of Standards and Technology, Tech. Rep. 207, 2020 ↩︎

4. S. Rose, O. Borchert, S. Mitchell, and S. Connelly, “Zero trust architecture draft, nist specialpublication 800-207,” National Institute of Standards and Technology, Tech. Rep. 207, 2019 ↩︎

5. S. Rose, O. Borchert, S. Mitchell, and S. Connelly, “Zero trust architecture draft, nist specialpublication 800-207,” National Institute of Standards and Technology, Tech. Rep. 207, 2019 ↩︎

6. R. Ward and B. Beyer, “Beyondcorp: A new approach to enterprise security,”;login:, vol. Vol. 39,No. 6, pp. 6–11, 2014. ↩︎

7. P. Wolfert, J. Deschuyteneer, D. Oetringer, N. Robinson, and T. Belpaeme, “Security risks of socialrobots used to persuade and manipulate: A proof of concept study.” ↩︎

8. J. Jackson, “Beyondcorp:How google ditched vpns for remote employee access,”https://thenewstack.io/beyondcorp-google-ditched-virtual-private- networking-internal-applications/, 2018, accessed: 2020-02-21. ↩︎

9. A. C. for Technology, “Zero trust cybersecurity current trends,” American Council for Technology-Industry Advisory Council (ACT-IAC), Tech. Rep., 2018. ↩︎

10. J. G. Grimes, “Information grid architectural vision. vision for a net-centric, service oriented dodenterprise,” DEPARTMENT OF DEFENSE WASHINGTON DC CHIEF INFORMATION OFFICER,Tech. Rep., 2007.* ↩︎