The Robot Security Framework (RSF)

Robot Security Framework (RSF) is a standardized methodology to perform security assessments in robotics.

Version: 1.1

How to cite our work

@ARTICLE{2018arXiv180604042M,
   author = {{Mayoral Vilches}, V. and {Alzola Kirschgens}, L. and {Bilbao Calvo}, A. and
	{Hern{\'a}ndez Cordero}, A. and {Izquierdo Pis{\'o}n}, R. and
	{Mayoral Vilches}, D. and {Mu{\~n}iz Rosas}, A. and {Olalde Mendia}, G. and
	{Usategi San Juan}, L. and {Zamalloa Ugarte}, I. and {Gil-Uriarte}, E. and
	{Tews}, E. and {Peter}, A.},
    title = "{Introducing the Robot Security Framework (RSF), a standardized methodology to perform security assessments in robotics}",
  journal = {ArXiv e-prints},
archivePrefix = "arXiv",
   eprint = {1806.04042},
 primaryClass = "cs.CR",
 keywords = {Computer Science - Cryptography and Security, Computer Science - Robotics},
     year = 2018,
    month = jun,
   adsurl = {http://adsabs.harvard.edu/abs/2018arXiv180604042M},
  adsnote = {Provided by the SAO/NASA Astrophysics Data System}
}

Physical layer
Aspect: Ports	Criteria: Presence of external communication ports Objective Identify presence of unprotected external ports Rationale Unprotected external ports can let attackers in physical proximity to perform a variety of attacks and serve as an entry point for them Method Inspect documentation, consult developers and inspect robot’s body and components. Look for accessible ports (e.g. Ethernet, USB, CAN, etc.) Open all doors, which are not protected by locks and look for ports inside Criteria: Presence of internal communication ports Objective Identify presence of unprotected internal ports that typically correspond with sensors, user interfaces, power or other robot-related components Rationale Unplugging robot components can potentially lead to the exposure of internal communication ports. Often, these internal communication ports are typically not protected in robots. This may allow attackers in physical proximity to perform a variety of attacks and serve as an entry point Method Open all doors, which are not protected by locks, even those protected, and look for robot components and their buses Investigate ventilation holes and see if they are wide enough to access internal communication ports Criteria: Security of external and internal communication ports Objective Verify if attackers can sniff or modify any critical data during communication with a docking station or by connecting to the ports Rationale Unprotected external and internal ports can let attackers in physical proximity to perform a variety of attacks and serve as an entry point for them Method Try to connect to the identified communication ports: Determine if authentication is required(e.g. Network access control for Ethernet)? Assess whether the communication is encripted Try communicating with them, attempt fizzing to discover if robot’s state can be affected. If a robot connects to a docking station to transfer some data, try to use sniffers to see how data exchange is being done (verify if some sensitive, configuration or control data is transferred in clear text)
Aspect: Components	Criteria: Availability of components from outside Objective Identify internal hardware that is accessible from outside without a need Rationale Directly accessible components can be physically damaged, stolen, tampered, removed or completely disabled causing the robot to misbehave. The most obvious example is the removal of critical sensors for the behavior of the robot Method Inspect robots body and look for accessible components (e.g. sensors, actuators, computation units, user interfaces, power components, etc.) Open all doors which are not protected by locks and look for accessible components inside. Notes All cables should also remain inside of the robot. Some components require to be partially outside of the body frame (e.g. certain sensors such as range finders, or the antennas of certain wireless communication components) in such a case only the required part should stick out, but not the whole component Criteria: Monitoring and alerting capabilities Objective Identify whether rogue access to the internal hardware of the robot can be detected Rationale Having no verification whether the internals of the robot were accessed or not means that attackers can easily tamper with any components or install a hardware *trojan* unnoticed Method Identify all parts of the frame that can be opened or removed to get access to the components or modules. Check whether there is an active (tamper switches) or passive (tamper evident screws and seals) monitoring capability present. In case of active monitoring capability, verify that operator receives a real-time alert and the incident is being logged and acted upon by reviewing procedures. Notes Passive monitoring provides information upon inspection whether internals were accessed or not. However, there is still a time window between inspections when exploited robots can be abused Criteria: Review logs of physical changes in the robot Objective Verify the logs of the robot and look for tampering actions. Log examples include powering on/off events, connection/disconnection of physical components, sensor values or actuator actions. Detect potential tampering based on this information Rationale Most robots register logs of a variety of events going from powering on/off the robot to each individual component data. Specially, some robots detect physical changes on their components and register it. Such changes could lead to an undetected tampering of the system. Reviewing the logs could lead to discovering physical tampering of the robot Method Review the logs of powering on and off routines of the robot. Review the logs of physical changes in the robot. Review the logs of each individual component and look for anomalies.

Network layer
Aspect: Internal robot network	Criteria: Network accessibility Objective Determine and assess network accessibility and the corresponding protection mechanisms. Rationale Internal networks could be pass Method Validate authentication mechanisms and verify that no known vulnerabilities are present on such. If internal network is password protected, attempt common password guessing. Verify whether the robot logs both successful and unsuccessful login attempts. Criteria: Network fingerprinting Objective Mitigate the fingerprinting impact on the internal networks. Rationale Network fingerprinting is useful to understand the internal network structure and its behavior, and to identify components’ operating system by analyzing packets from that component. This information could be used for malicious purposes, since it provides fine-grained determination of an operating system and its characteristics. Method Perform fingerprinting attacks on the internal networks. Evaluate obtained information with the manufacturer’s available data and assessits impact. If necessary, propose a mitigation strategy through the use of ”scrubbers”, whichwill ”normalize” the packets, and remove the unique identifying traits that the attacker is seeking. Refer to [18] for more details about the use of ”scrubbers”. Criteria: Communication protocol security Objective Check if used communication protocol is up-to-date, secure and has noknown vulnerabilities. Rationale Vulnerabilities in communication protocols can allow attackers to gain unauthorized access to the internal network of the robot and intercept or modify any transmitted data. Method Identify all present communication capabilities by inspecting documentation, byconsulting developers or by manual analysis. Analyze if used protocol versions provide encryption and mutual authentication. Verify that used protocol is hardened according to industry standards. Criteria: Monitoring, alert and response capabilities Objective Identify whether internal network activity is monitored, alerts are issuedand corresponding actions are taken based on known signatures or anomalies. Rationale Proper security controls on the internal network might be challenging due to hardware limitations or performance requirements, although it is critical for robots to introspect, monitor, report and act on issues that could appear on their internal networks. Security by obscurity is unfortunately a commonly accepted approach in robotics, nevertheless, it has been demonstrated that this approach leads to critically unsecured robots. Monitoring and control capabilities should be implemented on the internal network of the robot either through the manufacturer or through additional or external solutions. The decision of applying counter-measures to the attack or only alerting should be determined by the impact of possible false positives on the operative of the robot. Method Sweep the internal robot network and enumerate entry points (e.g. open ports, existing component information, network map of components, etc). Try to match the fingerprints identified and to map known vulnerabilities. Connect to the network and attempt to perform network-based attacks (e.g. ARPpoisoning, denial of service on a particular component, etc.) Verify whether the robot detects and registers incidents. Verify whether the robot acts upon such events and either: (The robot) responds to insult proactively. An operator receives a real time alert and acts based on procedures. Criteria: Firewall Objective Identify whether internal network is separated from the external by thefirewall. Rationale Firewalls can help to further protect components, modules and communications from the outside and ensure that they cannot accidentally leak data to the external network. Method Inspect documentation, consult developers and inspect components which are responsible for external communications. Identify that such components have firewalls. Inspect firewall settings and verify that no components or modules are allowed to communicate to the external network unless it is necessary. If a VPN is used, verify that there are rules which allow components or modules to communicate with the outside world only via the VPN tunnel. Notes There should be a firewall per each interface with external networks. That means that each communication component interfacing with an external channel should have a firewall behind it or use third party solutions. For example, WiFi hotspots in robots or LTE/UMTS transceivers.
Aspect: External network	Criteria: Availability of components from outside Objective Determine and assess network accessibility and the corresponding protection mechanisms. Rationale External networks could be password protected. If that is the case, the corresponding mechanisms should be up to date and ensure that only authenticated users are able to access the network. Method Validate authentication mechanisms and verify that no known vulnerabilities are present on such. If external network is password protected, attempt common password guessing. Verify whether the robot logs the users connected to the network. Criteria: Network fingerprinting Objective Mitigate the fingerprinting impact on the external networks. Rationale Network fingerprinting is useful to understand the network structure and its behavior, as well as to identify devices’ operating system by analyzing packets from that network. This information could be used for malicious purposes since it provides fine-grained determination of an operating system and its characteristics. Method Perform fingerprinting attacks on the external network. Evaluate obtained information with the manufacturer’s available data and assess its impact. If necessary, propose a mitigation strategy through the use of ”scrubbers”, which will ”normalize” the packets, and remove the unique identifying traits that the attacker is seeking. Refer to [18] for more details about the use of ”scrubbers”. Criteria: Communication protocol security Objective Check if used communication protocol is up-to-date, secure and has no known vulnerabilities. Rationale Vulnerabilities in communication protocols can allow attackers to gain unauthorized access to the external network of the robot and intercept or modify any transmitted data. Method Identify all communication capabilities being present by inspecting documentation, consulting developers or by manual analysis. Analyze if used protocol versions provide encryption and mutual authentication. Verify that used protocol is hardened according to industry standards. Notes If providing encryption on the protocol level is not possible for some reasons, VPN or application level encryption should be used. Criteria: Network ports exposure Objective Identify whether only necessary network ports are exposed to the external network. Rationale More open ports mean a bigger attack surface and therefore their number should be as low as possible. Services that are exposed should have no known vulnerabilities due to the ease of their exploitation. Method Connect to the network that is being used by the robot for communication and scan all robot ports to find the open ones. Verify with manufacturer manuals whether their presence is required. Identify, if possible, services running behind an open port and its version. Verify whether identified services are still receiving security updates and have no known vulnerabilities. Criteria: Monitoring, alert and response capabilities Objective Identify whether the external network activity is being monitored, alerts are issued based on known signatures or anomalies and appropriate actions are taken. Rationale Properly configured external network monitoring can spot network based attacks in their inception even if other security mechanisms are compromised. Method Sweep the external robot network and enumerate entry points (e.g. open ports, protocol information, network map of components, robot components etc). Try to match the fingerprints identified and map to known vulnerabilities. Perform network based attacks (e.g. ARP poisoning, denial of service on a particular component). Verify whether the robot detects and registers incidents on the external network. Verify whether the robot acts upon such events and either: (The robot) responds to insult proactively. An operator receives a real time alert and acts based on procedures. Notes In those cases where it is not possible to implement external robot network monitoring, alerting and response due to limitations on the robot capabilities, manufacturers should extend their capabilities or refer to third party solutions that could offer such.

Firmware layer
Aspect: Operating System (OS)	Criteria: Underlying OS updates Objective Verify that the used Operating System (OS) is still supported by the manufacturer and there is a mechanism to perform system updates. Rationale Outdated operating systems can have security vulnerabilities. Method Check if the underlying OS is still maintained and receives security patches. Check whether the latest security updates are applied. Check if there is an update mechanism present and enabled. Check if the updates are encrypted when transferred to the robot.
Aspect: Middleware	Criteria: Verify code compliance (if accessible) Objective In those cases where it applies (white box assessment), ensure compliance of middleware code against established compliance mechanisms. A common middleware such as ROS 2 should comply with the Motor Industry Software Reliability Association (MISRA) guidelines. Other middlewares might use different guidelines. Rationale As robotics and autonomy grow, especially in certain fields of robotics, users of middlewares need to be able to determine if the software is able to be used in a safety-critical environment. With suitable guidance and modification, it is expected that middleware code could be integrated as part of certain compliant system. For this purpose, code should be developed and reviewed following certain guidelines. The most common one is the Motor Industry Software Reliability Association (MISRA), widely used in many safety-critical environments and adopted by the ROS 2 middleware. Method Determine the exact set of guidelines that are being applied. Validate whether these guidelines have been implemented. Criteria: Middleware updates Objective Verify that the used middleware is still maintained and supported by the manufacturer. Verify to perform system updates in the middlware. Rationale Outdated middlewares in robotics are subject to have security vulnerabilities. This is specially true with ROS, ROS 2 and other robot-related middlewares Method Check if the underlying middleware is still maintained and receives security patches. Check whether the latest security updates are applied. Check if there is an update mechanism present and enabled. Check if the updates are encrypted when transferred to the robot. Criteria: Middleware strict values validation Objective Verify that the used middleware introduce strict value ranges into messages. Rationale � Messages define what data a listener can accept, but to avoid bugs and/or errors, the listener should only consider a set range of values valid for any given field. When values out of this range are received, the listener should error out in a controlled manner. Method a) Middleware should provide primitives for range-checking ( a message type with built-in range checks can be denied on the publisher’s side before the listener ever has to interact with it) or b) listeners must implement their own range-checking. Criteria: Middleware provides safe mode for computational nodes Objective When nodes fail, it is essential that core functionalities are still available Rationale In a safe mode, basic functionalities will be pro-vided to recover the robotic system, such as when in tele-operation. Method Middleware should provide primitives for implementing a safe mode within the software lifecycle. Ideally, such lifecyle should connect to the hardware (lifecyle) one and coherently provides means of recovery.
Aspect: Firmware	Criteria: Firmware updates Objective Check if manufacturer firmware can be securely updated. Rationale If new vulnerabilities are discovered it is important to ensure that there is a way to provide updates to all the devices that are already sold to customers. However, update mechanisms can be circumvented by an attacker to deliver malicious update. Therefore, it is important to verify the origin of the update prior to installation. Method Identify if there is a mechanism to deliver firmware updates. Verify that updates are cryptographically signed. Verify that the signature is verified prior to installation.

Application layer
Aspect: Authorization	Criteria: Access control Objective Verify that resources are accessible only to authorized users or services. Rationale Access to the restricted functions by anonymous users or users with lower access control rights diminishes all the benefits of access control. Method Log in with authorized credentials and attempt to perform different actions, record the requests that are being made. Log out and attempt to send the same requests as an unauthenticated user. Verify whether it is successful. Log out and log in again as a user with lower access rights. Attempt to send the same requests again. Verify whether it is successful.
Aspect: Privacy	Criteria: Privacy assessment Objective Identify whether the robot is compliant to the privacy policies that apply. Rationale Not complying with privacy standards could result in a breach of personal data. Method Verify that minimum Personally Identifiable Information (PII) is collected and transmitted over the internet. Verify that if PII is collected users are made aware of it (e.g. in case of a video recording people can be warned by stickers or signs on the robot). Verify that all PII is stored and transmitted in a secure manner. Criteria: Data protection Objective Identify whether the robot manufacturer emplaces mechanisms to ensure compliance to the data protection regulations and laws that apply. Particularly, General Data Protection Regulation (GDPR) in the EU. Rationale Not complying with regulations could result in penalties. Method Assess the legitimate interests. Assess the consent. Assess the information provisions. Assess the third party data. Assess the profiling. Assess the legacy data Method It is not relevant to the security of the robot itself. However not complying with data protection regulations can result in financial penalties and should therefore be taken into consideration.
Aspect: Integrity	Criteria: Integrity check Objective Identify whether the system performs an integrity check of critical components and takes action if they are not present or modified. Rationale Tampering with any of the critical components can make the robot cause physical damage to people and property. Method Consult documentation and developers to find whether integrity check for critical components is present. Try disabling or modifying critical components (e.g. safety sensors or range finding systems) of the robot and check if the operator receives a real-time alert and the incident is being logged. Check whether the robot continues to function afterwards. Its operation should be stopped as soon as any critical component is disabled or modified, (e.g. if a proximity sensor is disabled the robot should not be able to move, because it will not be able to spot obstacles and can easily do some physical damage). Note Critical components are those that can directly influence the robot’s operation, functionality or safety.
Aspect: Accounts	Criteria: Default passwords Objective Identify presence of default passwords. Rationale Default passwords are easily accessible online and remain the most popular and effortless way to exploit internet connected devices. Method Review documentation and consult developers to identify whether default passwords are used. Attempt to log in with commonly used passwords. If default passwords are used, verify whether their change is encouraged on the first use. If unique passwords are created on a per device basis, ensure that they are random and not in a sequential order. Note When trying commonly used passwords, beware of account lockouts and verify that there is a recovery mechanism present. Criteria: Password complexity Objective Verify that password complexity is enforced. Rationale Weak passwords may take little time to guess. Method Attempt to change the password to a weak one and verify whether this change succeeded. Note Password complexity requirements depend on the sensitivity of the application. In general, the minimum requirements that should be in place are: A password length of, at least, 8 characters. Enforce the usage of 3 of this 4 categories:lower-case, upper-case, numbers, special characters. Criteria: Login Lockout Objective Identify whether the login lockout is present. Rationale Having strong and non-default passwords may not be enough. Brute force attempts should be prevented by implementing a login lockout mechanism. Method Attempt to log in with incorrect credentials multiple times. Verify that the account has got a lockout. Note The lockout threshold depends on the sensitivity of the service. In general, there should be 5 login attempts or less. Prior to testing, verify that the lockout recovery mechanism is being present. Accounts can be either locked out for a specific duration of time and/or they can be recovered by physical interaction with the robot. Criteria: Hardcoded or backdoor accounts Objective Identify presence of hardcoded or backdoor accounts. Rationale Hardcoded or backdoor credentials pose the same danger as default passwords. However, their identification is usually harder due to the need for reverse engineering or possession of the source code. Method Consult documentation and developers to identify whether hardcoded or backdoor credentials are used. Analyze the source code for hardcoded or backdoor credentials. Criteria: Cleartext passwords Objective Identify whether passwords are stored in cleartext. Rationale Cleartext passwords can be leveraged by an attacker for privilege escalation or lateral movement. Method Review the source code and documentation, consult developers and identify whether passwords are stored in a cleartext. Note Lockout threshold depends on the sensitivity of the service. In general, there should be 5 login attempts or less.
Aspect: Communication	Criteria: Encryption Objective Ensure that all sensitive data is transmitted over an encrypted channel. Rationale If data is transmitted in a clear text attackers can easily gather sensitive information (e.g. credentials, audio and video streams, private data). Method Intercept connection between a robot and a control center application or a cloud server. Use protocol analyzer to verify that transmitted data is encrypted. Criteria: Replay protection Objective Ensure that transmitted data cannot be replayed. Rationale If replay protection is absent, attackers can record legitimate packets and then arbitrary replay them to achieve desired actions. Method Intercept the connection between the robot and a control center application or a cloud server. Record the control or configuration packets sent to the robot. Attempt to replay the packets and verify whether the desired action is executed.
Aspect: 3rd party libraries and components	Criteria: Vulnerabilities Objective Verify that 3rd party software components do not have known vulnerabilities. Rationale It is quite common to blindly rely on 3rd party components. However they can easily introduce a vulnerability into the product where they are used. Method Identify which 3rd party libraries and components are used and what are their versions. Look for known vulnerabilities in the current version. Verify whether the identified component is still receiving security updates and has no unpatched vulnerabilities. Verify that the latest security updates are installed.
Aspect: Control center application	Criteria: Web application Objective Perform a security assessment of the web application. Rationale The robot can be indirectly compromised if the attacker exploits a web control center application. Method Identify web interface that is being used (hosted on the robot itself or a cloud server). Use OWASP methodology to test web application against OWASP Top 10 Web application vulnerabilities. Criteria: Mobile application Objective Perform a security assessment of the mobile application. Rationale The robot can be indirectly compromised if the attacker exploits a mobile phone control center application. Method Identify whether the robot has a mobile app that can be used to control or interact with it. Test the application against OWASP Mobile Top 10.

License

GPLv3.

Glossary

• component: a part of something that is discrete and identifiable with respect to combining with other parts to produce something larger (source: ISO/IEC 24765).
  • Note 1 to entry: Component can be either software or hardware. Even a component that is mainly software or hardware can be referred to as a software or hardware component respectively.
• module: component with special characteristics to facilitate system design, integration, interoperability, re-use.
• interoperability: the capability to communicate and transfer data among modules and combine modules physically in a manner that requires the user to have little or no knowledge of the unique characteristics of those modules.
• firmware: (in the context of robotics) software that is embedded in robots.