{"id":33116407,"url":"https://github.com/aliasrobotics/RSF","last_synced_at":"2025-11-15T11:01:34.740Z","repository":{"id":201430838,"uuid":"133223288","full_name":"aliasrobotics/RSF","owner":"aliasrobotics","description":"The Robot Security Framework (RSF), Robot Security Framework (RSF), a standardized methodology to perform security assessments in robotics.","archived":false,"fork":false,"pushed_at":"2018-12-28T08:58:53.000Z","size":867,"stargazers_count":89,"open_issues_count":1,"forks_count":14,"subscribers_count":16,"default_branch":"master","last_synced_at":"2025-09-09T03:57:58.435Z","etag":null,"topics":["assessment","cybersecurity","framework","penetration-testing","pentesting","robotics","robots","security"],"latest_commit_sha":null,"homepage":"https://aliasrobotics.com","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-3.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/aliasrobotics.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null}},"created_at":"2018-05-13T09:34:56.000Z","updated_at":"2025-02-21T19:25:57.000Z","dependencies_parsed_at":null,"dependency_job_id":"82824393-c257-4a6f-88a9-bb37910e2432","html_url":"https://github.com/aliasrobotics/RSF","commit_stats":null,"previous_names":["aliasrobotics/rsf"],"tags_count":1,"template":false,"template_full_name":null,"purl":"pkg:github/aliasrobotics/RSF","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/aliasrobotics%2FRSF","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/aliasrobotics%2FRSF/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/aliasrobotics%2FRSF/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/aliasrobotics%2FRSF/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/aliasrobotics","download_url":"https://codeload.github.com/aliasrobotics/RSF/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/aliasrobotics%2FRSF/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":284545264,"owners_count":27023524,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-11-15T02:00:06.050Z","response_time":57,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["assessment","cybersecurity","framework","penetration-testing","pentesting","robotics","robots","security"],"created_at":"2025-11-15T02:00:40.808Z","updated_at":"2025-11-15T11:01:34.730Z","avatar_url":"https://github.com/aliasrobotics.png","language":null,"funding_links":[],"categories":["Security","System"],"sub_categories":["Sensor and Acuator Interfaces","Security"],"readme":"# The `Robot Security Framework` (RSF)\nRobot Security Framework (RSF) is a standardized methodology to perform security assessments in robotics.\n\n![](imgs/RSF_Diagram_generic.jpg)\n\n**Version**: 1.1\n\n## How to cite our work\n\n[![Article](https://img.shields.io/badge/article-arxiv%3A1812.09490-red.svg)](https://arxiv.org/pdf/1806.04042.pdf)\n```\n@ARTICLE{2018arXiv180604042M,\n   author = {{Mayoral Vilches}, V. and {Alzola Kirschgens}, L. and {Bilbao Calvo}, A. and\n\t{Hern{\\'a}ndez Cordero}, A. and {Izquierdo Pis{\\'o}n}, R. and\n\t{Mayoral Vilches}, D. and {Mu{\\~n}iz Rosas}, A. and {Olalde Mendia}, G. and\n\t{Usategi San Juan}, L. and {Zamalloa Ugarte}, I. and {Gil-Uriarte}, E. and\n\t{Tews}, E. and {Peter}, A.},\n    title = \"{Introducing the Robot Security Framework (RSF), a standardized methodology to perform security assessments in robotics}\",\n  journal = {ArXiv e-prints},\narchivePrefix = \"arXiv\",\n   eprint = {1806.04042},\n primaryClass = \"cs.CR\",\n keywords = {Computer Science - Cryptography and Security, Computer Science - Robotics},\n     year = 2018,\n    month = jun,\n   adsurl = {http://adsabs.harvard.edu/abs/2018arXiv180604042M},\n  adsnote = {Provided by the SAO/NASA Astrophysics Data System}\n}\n```\n\n\u003c!-- Layer 1 --\u003e\n\u003ctable\u003e\n  \u003ctr\u003e\n    \u003cth colspan=\"3\"\u003e\n\n### Physical layer\n   \u003c/th\u003e\n  \u003c/tr\u003e\n\n  \u003c!-- Aspect 1 --\u003e\n  \u003ctr\u003e\n   \u003ctd\u003eAspect: \u003cb\u003ePorts\u003c/b\u003e\u003c/td\u003e\n   \u003ctd\u003e\n\n   \u003c!-- Criteria 1 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003ePresence of external communication ports\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eIdentify presence of unprotected external ports\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eUnprotected external ports can let attackers in physical proximity to perform\n        a variety of attacks and serve as an entry point for them\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Inspect documentation, consult developers and inspect robot’s body and components.\nLook for accessible ports (e.g. Ethernet, USB, CAN, etc.)\n- Open all doors, which are not protected by locks and look for ports inside\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n\n   \u003c!-- Criteria 2 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003ePresence of internal communication ports\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eIdentify presence of unprotected internal ports that typically correspond\nwith sensors, user interfaces, power or other robot-related components\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eUnplugging robot components can potentially lead to the exposure of internal\ncommunication ports. Often, these internal communication ports are typically\nnot protected in robots. This may allow attackers in physical proximity to\nperform a variety of attacks and serve as an entry point\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Open all doors, which are not protected by locks, even those protected, and look\nfor robot components and their buses\n- Investigate ventilation holes and see if they are wide enough to access internal\ncommunication ports\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n\n   \u003c!-- Criteria 3 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eSecurity of external and internal communication ports\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eVerify if attackers can sniff or modify any critical data during communication\nwith a docking station or by connecting to the ports\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eUnprotected external and internal ports can let attackers in physical proximity\nto perform a variety of attacks and serve as an entry point for them\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Try to connect to the identified communication ports:\n  - Determine if authentication is required(e.g. Network access control for Ethernet)?\n  - Assess whether the communication is encripted\n  - Try communicating with them, attempt fizzing to discover if robot’s state can\nbe affected.\n- If a robot connects to a docking station to transfer some data, try to use sniffers\nto see how data exchange is being done (verify if some sensitive, configuration or\ncontrol data is transferred in clear text)\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n\n   \u003c/td\u003e\n  \u003c/tr\u003e\n\n  \u003c!-- Aspect 2 --\u003e\n  \u003ctr\u003e\n   \u003ctd\u003eAspect: \u003cb\u003eComponents\u003c/b\u003e\u003c/td\u003e\n   \u003ctd\u003e\n\n   \u003c!-- Criteria 1 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eAvailability of components from outside\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eIdentify internal hardware that is accessible from outside without a need\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eDirectly accessible components can be physically damaged, stolen, tampered,\nremoved or completely disabled causing the robot to misbehave. The most\nobvious example is the removal of critical sensors for the behavior of the robot\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Inspect robots body and look for accessible components (e.g. sensors, actuators,\ncomputation units, user interfaces, power components, etc.)\n- Open all doors which are not protected by locks and look for accessible components\ninside.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eNotes\u003c/td\u003e\n      \u003ctd\u003eAll cables should also remain inside of the robot. Some components require\nto be partially outside of the body frame (e.g. certain sensors such as range finders, or\nthe antennas of certain wireless communication components) in such a case only the\n        required part should stick out, but not the whole component\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n\n   \u003c!-- Criteria 2 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eMonitoring and alerting capabilities\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eIdentify whether rogue access to the internal hardware of the robot can be\ndetected\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eHaving no verification whether the internals of the robot were accessed or\nnot means that attackers can easily tamper with any components or install a hardware\n*trojan* unnoticed\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Identify all parts of the frame that can be opened or removed to get access to the\ncomponents or modules.\n- Check whether there is an active (tamper switches) or passive (tamper evident\nscrews and seals) monitoring capability present.\n- In case of active monitoring capability, verify that operator receives a real-time\nalert and the incident is being logged and acted upon by reviewing procedures.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eNotes\u003c/td\u003e\n      \u003ctd\u003ePassive monitoring provides information upon inspection whether internals\nwere accessed or not. However, there is still a time window between inspections when\n        exploited robots can be abused\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n\n   \u003c!-- Criteria 3 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eReview logs of physical changes in the robot\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eVerify the logs of the robot and look for tampering actions. Log examples\ninclude powering on/off events, connection/disconnection of physical components,\nsensor values or actuator actions. Detect potential tampering based on this information\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eMost robots register logs of a variety of events going from powering on/off\nthe 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\ntampering of the robot\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Review the logs of powering on and off routines of the robot.\n- Review the logs of physical changes in the robot.\n- Review the logs of each individual component and look for anomalies.\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n\n   \u003c/td\u003e\n  \u003c/tr\u003e\n\u003c/table\u003e\n\n\n\n\n\n\u003c!-- Layer 2 --\u003e\n\u003ctable\u003e\n  \u003ctr\u003e\n    \u003cth colspan=\"3\"\u003e\n\n### Network layer\n   \u003c/th\u003e\n  \u003c/tr\u003e\n\n  \u003c!-- Aspect 1 --\u003e\n  \u003ctr\u003e\n   \u003ctd\u003eAspect: \u003cb\u003eInternal robot network\u003c/b\u003e\u003c/td\u003e\n   \u003ctd\u003e\n\n   \u003c!-- Criteria 1 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eNetwork accessibility\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eDetermine and assess network accessibility and the corresponding protection mechanisms.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eInternal networks could be pass\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Validate authentication mechanisms and verify that no known vulnerabilities are present on such.\n- If internal network is password protected, attempt common password guessing.\n- Verify whether the robot logs both successful and unsuccessful login attempts.\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n\n   \u003c!-- Criteria 2 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eNetwork fingerprinting\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eMitigate the fingerprinting impact on the internal networks.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003e\nNetwork 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.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Perform fingerprinting attacks on the internal networks.\n- Evaluate obtained information with the manufacturer’s available data and assessits impact.\n- 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”.\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n\n   \u003c!-- Criteria 3 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eCommunication protocol security\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eCheck if used communication protocol is up-to-date, secure and has noknown vulnerabilities.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003e\nVulnerabilities in communication protocols can allow attackers to gain unauthorized access to the internal network of the robot and intercept or modify any transmitted data.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Identify all present communication capabilities by inspecting documentation, byconsulting developers or by manual analysis.\n- Analyze if used protocol versions provide encryption and mutual authentication.\n- Verify that used protocol is hardened according to industry standards.\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n\n   \u003c!-- Criteria 4 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eMonitoring, alert and response capabilities\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eIdentify whether internal network activity is monitored, alerts are issuedand corresponding actions are taken based on known signatures or anomalies.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eProper security controls on the internal network might be challenging due\nto hardware limitations or performance requirements, although it is critical for robots\nto introspect, monitor, report and act on issues that could appear on their internal\nnetworks. Security by obscurity is unfortunately a commonly accepted approach in\nrobotics, nevertheless, it has been demonstrated that this approach leads to critically\nunsecured robots. Monitoring and control capabilities should be implemented on the\ninternal network of the robot either through the manufacturer or through additional\nor external solutions. The decision of applying counter-measures to the attack or only\nalerting should be determined by the impact of possible false positives on the operative\nof the robot.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Sweep the internal robot network and enumerate entry points (e.g. open ports, existing component information, network map of components, etc).\n- Try to match the fingerprints identified and to map known vulnerabilities.\n- Connect to the network and attempt to perform network-based attacks (e.g. ARPpoisoning, denial of service on a particular component, etc.)\n- Verify whether the robot detects and registers incidents.\n- Verify whether the robot acts upon such events and either:\n - (The robot) responds to insult proactively.\n - An operator receives a real time alert and acts based on procedures.\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n\n   \u003c!-- Criteria 5 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eFirewall\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eIdentify whether internal network is separated from the external by thefirewall.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eFirewalls can help to further protect components, modules and communications\nfrom the outside and ensure that they cannot accidentally leak data to the\nexternal network.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Inspect documentation, consult developers and inspect components which are responsible\nfor external communications. Identify that such components have firewalls.\n- Inspect firewall settings and verify that no components or modules are allowed to\ncommunicate to the external network unless it is necessary.\n- If a VPN is used, verify that there are rules which allow components or modules\nto communicate with the outside world only via the VPN tunnel.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eNotes\u003c/td\u003e\n      \u003ctd\u003eThere should be a firewall per each interface with external networks. That\nmeans that each communication component interfacing with an external channel\nshould have a firewall behind it or use third party solutions. For example, WiFi\nhotspots in robots or LTE/UMTS transceivers.\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n   \u003c/td\u003e\n  \u003c/tr\u003e\n\n  \u003c!-- Aspect 2 --\u003e\n  \u003ctr\u003e\n   \u003ctd\u003eAspect: \u003cb\u003eExternal network\u003c/b\u003e\u003c/td\u003e\n   \u003ctd\u003e\n\n   \u003c!-- Criteria 1 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eAvailability of components from outside\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eDetermine and assess network accessibility and the corresponding protection mechanisms.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eExternal networks could be password protected. If that is the case, the\ncorresponding mechanisms should be up to date and ensure that only authenticated\nusers are able to access the network.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Validate authentication mechanisms and verify that no known vulnerabilities are\npresent on such.\n- If external network is password protected, attempt common password guessing.\n- Verify whether the robot logs the users connected to the network.\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n\n   \u003c!-- Criteria 2 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eNetwork fingerprinting\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eMitigate the fingerprinting impact on the external networks.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eNetwork fingerprinting is useful to understand the network structure and\nits behavior, as well as to identify devices’ operating system by analyzing packets\nfrom that network. This information could be used for malicious purposes since it\nprovides fine-grained determination of an operating system and its characteristics.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Perform fingerprinting attacks on the external network.\n- Evaluate obtained information with the manufacturer’s available data and assess\nits impact.\n- If necessary, propose a mitigation strategy through the use of ”scrubbers”, which\nwill ”normalize” the packets, and remove the unique identifying traits that the\nattacker is seeking. Refer to [18] for more details about the use of ”scrubbers”.\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n\n   \u003c!-- Criteria 3 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eCommunication protocol security\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eCheck if used communication protocol is up-to-date, secure and has no\nknown vulnerabilities.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eVulnerabilities in communication protocols can allow attackers to gain\nunauthorized access to the external network of the robot and intercept or modify any\ntransmitted data.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Identify all communication capabilities being present by inspecting documentation,\nconsulting developers or by manual analysis.\n- Analyze if used protocol versions provide encryption and mutual authentication.\n- Verify that used protocol is hardened according to industry standards.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eNotes\u003c/td\u003e\n      \u003ctd\u003eIf providing encryption on the protocol level is not possible for some reasons,\nVPN or application level encryption should be used.\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n\n   \u003c!-- Criteria 4 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eNetwork ports exposure\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eIdentify whether only necessary network ports are exposed to the external\nnetwork.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eMore open ports mean a bigger attack surface and therefore their number\nshould be as low as possible. Services that are exposed should have no known\nvulnerabilities due to the ease of their exploitation.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Connect to the network that is being used by the robot for communication and scan\nall robot ports to find the open ones. Verify with manufacturer manuals whether\ntheir presence is required.\n- Identify, if possible, services running behind an open port and its version.\n- Verify whether identified services are still receiving security updates and have no\nknown vulnerabilities.\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n\n   \u003c!-- Criteria 5 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eMonitoring, alert and response capabilities\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eIdentify whether the external network activity is being monitored, alerts\nare issued based on known signatures or anomalies and appropriate actions are taken.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eProperly configured external network monitoring can spot network based\nattacks in their inception even if other security mechanisms are compromised.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Sweep the external robot network and enumerate entry points (e.g. open ports,\nprotocol information, network map of components, robot components etc).\n- Try to match the fingerprints identified and map to known vulnerabilities.\n- Perform network based attacks (e.g. ARP poisoning, denial of service on a particular\ncomponent).\n- Verify whether the robot detects and registers incidents on the external network.\n- Verify whether the robot acts upon such events and either:\n - (The robot) responds to insult proactively.\n - An operator receives a real time alert and acts based on procedures.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eNotes\u003c/td\u003e\n      \u003ctd\u003eIn those cases where it is not possible to implement external robot network\nmonitoring, alerting and response due to limitations on the robot capabilities, manufacturers\nshould extend their capabilities or refer to third party solutions that could\noffer such.\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n\n   \u003c/td\u003e\n  \u003c/tr\u003e\n\u003c/table\u003e\n\n\n\n\n\u003c!-- Layer 3 --\u003e\n\u003ctable\u003e\n  \u003ctr\u003e\n    \u003cth colspan=\"3\"\u003e\n\n### Firmware layer\n   \u003c/th\u003e\n  \u003c/tr\u003e\n\n  \u003c!-- Aspect 1 --\u003e\n  \u003ctr\u003e\n   \u003ctd\u003eAspect: \u003cb\u003eOperating System (OS)\u003c/b\u003e\u003c/td\u003e\n   \u003ctd\u003e\n\n   \u003c!-- Criteria 1 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eUnderlying OS updates\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eVerify that the used Operating System (OS) is still supported by the manufacturer\nand there is a mechanism to perform system updates.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eOutdated operating systems can have security vulnerabilities.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Check if the underlying OS is still maintained and receives security patches.\n- Check whether the latest security updates are applied.\n- Check if there is an update mechanism present and enabled.\n- Check if the updates are encrypted when transferred to the robot.\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n\n   \u003c/td\u003e\n  \u003c/tr\u003e\n\n  \u003c!-- Aspect 2 --\u003e\n  \u003ctr\u003e\n   \u003ctd\u003eAspect: \u003cb\u003eMiddleware\u003c/b\u003e\u003c/td\u003e\n   \u003ctd\u003e\n\n   \u003c!-- Criteria 1 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eVerify code compliance (if accessible)\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eIn those cases where it applies (white box assessment), ensure compliance\nof middleware code against established compliance mechanisms. A common middleware\nsuch as ROS 2 should comply with the Motor Industry Software Reliability\nAssociation (MISRA) guidelines. Other middlewares might use different guidelines.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eAs robotics and autonomy grow, especially in certain fields of robotics,\nusers of middlewares need to be able to determine if the software is able to be used in\na safety-critical environment. With suitable guidance and modification, it is expected\nthat middleware code could be integrated as part of certain compliant system. For this\npurpose, code should be developed and reviewed following certain guidelines. The\nmost common one is the Motor Industry Software Reliability Association (MISRA),\nwidely used in many safety-critical environments and adopted by the ROS 2 middleware.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Determine the exact set of guidelines that are being applied.\n- Validate whether these guidelines have been implemented.\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n\n   \u003c!-- Criteria 2 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eMiddleware updates\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eVerify that the used middleware is still maintained and supported by the\nmanufacturer. Verify to perform system updates in the middlware.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eOutdated middlewares in robotics are subject to have security vulnerabilities.\nThis is specially true with ROS, ROS 2 and other robot-related middlewares\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Check if the underlying middleware is still maintained and receives security\npatches.\n- Check whether the latest security updates are applied.\n- Check if there is an update mechanism present and enabled.\n- Check if the updates are encrypted when transferred to the robot.\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n\n   \u003c!-- Criteria 3 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eMiddleware strict values validation\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eVerify that the used middleware introduce strict value ranges into messages.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003e\n       \u000f 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.\n      \u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n      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.\n    \u003c/tr\u003e\n   \u003c/table\u003e\n\n   \u003c!-- Criteria 4 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eMiddleware provides safe mode for computational nodes\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eWhen nodes fail, it is essential that core functionalities are still available\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003e\n       In a safe  mode, basic functionalities will be pro-vided to recover the robotic system, such as when in tele-operation.\n      \u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n      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.\n    \u003c/tr\u003e\n   \u003c/table\u003e\n\n  \u003c/td\u003e\n  \u003c/tr\u003e\n\n  \u003c!-- Aspect 3 --\u003e\n  \u003ctr\u003e\n   \u003ctd\u003eAspect: \u003cb\u003eFirmware\u003c/b\u003e\u003c/td\u003e\n   \u003ctd\u003e\n   \u003c!-- Criteria 1 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eFirmware updates\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eCheck if manufacturer firmware can be securely updated.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eIf new vulnerabilities are discovered it is important to ensure that there is a\nway to provide updates to all the devices that are already sold to customers. However,\nupdate mechanisms can be circumvented by an attacker to deliver malicious update.\nTherefore, it is important to verify the origin of the update prior to installation.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Identify if there is a mechanism to deliver firmware updates.\n- Verify that updates are cryptographically signed.\n- Verify that the signature is verified prior to installation.\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n   \u003c/td\u003e\n  \u003c/tr\u003e\n\u003c/table\u003e\n\n\n\n\n\u003c!-- Layer 4 --\u003e\n\u003ctable\u003e\n  \u003ctr\u003e\n    \u003cth colspan=\"3\"\u003e\n\n### Application layer\n   \u003c/th\u003e\n  \u003c/tr\u003e\n\n  \u003c!-- Aspect 1 --\u003e\n  \u003ctr\u003e\n   \u003ctd\u003eAspect: \u003cb\u003eAuthorization\u003c/b\u003e\u003c/td\u003e\n   \u003ctd\u003e\n\n   \u003c!-- Criteria 1 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eAccess control\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eVerify that resources are accessible only to authorized users or services.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eAccess to the restricted functions by anonymous users or users with lower\naccess control rights diminishes all the benefits of access control.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Log in with authorized credentials and attempt to perform different actions, record\nthe requests that are being made.\n- Log out and attempt to send the same requests as an unauthenticated user. Verify\nwhether it is successful.\n- Log out and log in again as a user with lower access rights. Attempt to send the\nsame requests again. Verify whether it is successful.\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n   \u003c/td\u003e\n  \u003c/tr\u003e\n\n  \u003c!-- Aspect 2 --\u003e\n  \u003ctr\u003e\n   \u003ctd\u003eAspect: \u003cb\u003ePrivacy\u003c/b\u003e\u003c/td\u003e\n   \u003ctd\u003e\n\n   \u003c!-- Criteria 1 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003ePrivacy assessment\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eIdentify whether the robot is compliant to the privacy policies that apply.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eNot complying with privacy standards could result in a breach of personal\ndata.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Verify that minimum Personally Identifiable Information (PII) is collected and\ntransmitted over the internet.\n- Verify that if PII is collected users are made aware of it (e.g. in case of a video\nrecording people can be warned by stickers or signs on the robot).\n- Verify that all PII is stored and transmitted in a secure manner.\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n\n   \u003c!-- Criteria 2 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eData protection\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eIdentify whether the robot manufacturer emplaces mechanisms to ensure\ncompliance to the data protection regulations and laws that apply. Particularly, General\nData Protection Regulation (GDPR) in the EU.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eNot complying with regulations could result in penalties.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Assess the legitimate interests.\n- Assess the consent.\n- Assess the information provisions.\n- Assess the third party data.\n- Assess the profiling.\n- Assess the legacy data\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003eIt is not relevant to the security of the robot itself. However not complying\nwith data protection regulations can result in financial penalties and should therefore\nbe taken into consideration.\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n  \u003c/td\u003e\n  \u003c/tr\u003e\n\n  \u003c!-- Aspect 3 --\u003e\n  \u003ctr\u003e\n   \u003ctd\u003eAspect: \u003cb\u003eIntegrity\u003c/b\u003e\u003c/td\u003e\n   \u003ctd\u003e\n   \u003c!-- Criteria 1 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eIntegrity check\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eIdentify whether the system performs an integrity check of critical components\nand takes action if they are not present or modified.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eTampering with any of the critical components can make the robot cause\nphysical damage to people and property.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Consult documentation and developers to find whether integrity check for critical\ncomponents is present.\n- Try disabling or modifying critical components (e.g. safety sensors or range finding\nsystems) of the robot and check if the operator receives a real-time alert and\nthe incident is being logged.\n- Check whether the robot continues to function afterwards. Its operation should\nbe stopped as soon as any critical component is disabled or modified, (e.g. if a\nproximity sensor is disabled the robot should not be able to move, because it will\nnot be able to spot obstacles and can easily do some physical damage).\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n     \u003ctd\u003eNote\u003c/td\u003e\n     \u003ctd\u003eCritical components are those that can directly influence the robot’s operation,\n       functionality or safety.\u003c/td\u003e\n    \u003c/td\u003e\n   \u003c/table\u003e\n   \u003c/td\u003e\n  \u003c/tr\u003e\n\n  \u003c!-- Aspect 4 --\u003e\n  \u003ctr\u003e\n   \u003ctd\u003eAspect: \u003cb\u003eAccounts\u003c/b\u003e\u003c/td\u003e\n   \u003ctd\u003e\n   \u003c!-- Criteria 1 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eDefault passwords\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eIdentify presence of default passwords.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eDefault passwords are easily accessible online and remain the most popular\nand effortless way to exploit internet connected devices.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Review documentation and consult developers to identify whether default passwords\nare used.\n- Attempt to log in with commonly used passwords.\n- If default passwords are used, verify whether their change is encouraged on the\nfirst use.\n- If unique passwords are created on a per device basis, ensure that they are random\nand not in a sequential order.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n     \u003ctd\u003eNote\u003c/td\u003e\n     \u003ctd\u003eWhen trying commonly used passwords, beware of account lockouts and verify\n       that there is a recovery mechanism present.\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n\n   \u003c!-- Criteria 2 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003ePassword complexity\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eVerify that password complexity is enforced.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eWeak passwords may take little time to guess.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n     \u003ctd\u003eMethod\u003c/td\u003e\n     \u003ctd\u003eAttempt to change the password to a weak one and verify whether this\nchange succeeded.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eNote\u003c/td\u003e\n      \u003ctd\u003ePassword complexity requirements depend on the sensitivity of the application.\nIn general, the minimum requirements that should be in place are:\n\n- A password length of, at least, 8 characters.\n- Enforce the usage of 3 of this 4 categories:lower-case, upper-case, numbers, special\ncharacters.\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n\n   \u003c!-- Criteria 3 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eLogin Lockout\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eIdentify whether the login lockout is present.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eHaving strong and non-default passwords may not be enough. Brute force\nattempts should be prevented by implementing a login lockout mechanism.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003eAttempt to log in with incorrect credentials multiple times. Verify that the\naccount has got a lockout.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n     \u003ctd\u003eNote\u003c/td\u003e\n     \u003ctd\u003eThe lockout threshold depends on the sensitivity of the service. In general, there\nshould be 5 login attempts or less. Prior to testing, verify that the lockout recovery\nmechanism is being present. Accounts can be either locked out for a specific duration\nof time and/or they can be recovered by physical interaction with the robot.\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n\n   \u003c!-- Criteria 4 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eHardcoded or backdoor accounts\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eIdentify presence of hardcoded or backdoor accounts.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eHardcoded or backdoor credentials pose the same danger as default passwords.\nHowever, their identification is usually harder due to the need for reverse\nengineering or possession of the source code.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Consult documentation and developers to identify whether hardcoded or backdoor\ncredentials are used.\n- Analyze the source code for hardcoded or backdoor credentials.\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n\n   \u003c!-- Criteria 5 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eCleartext passwords\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eIdentify whether passwords are stored in cleartext.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eCleartext passwords can be leveraged by an attacker for privilege escalation\nor lateral movement.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Review the source code and documentation, consult developers and identify\nwhether passwords are stored in a cleartext.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eNote\u003c/td\u003e\n      \u003ctd\u003eLockout threshold depends on the sensitivity of the service. In general, there\nshould be 5 login attempts or less.\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n   \u003c/td\u003e\n  \u003c/tr\u003e\n\n  \u003c!-- Aspect 5 --\u003e\n  \u003ctr\u003e\n   \u003ctd\u003eAspect: \u003cb\u003eCommunication\u003c/b\u003e\u003c/td\u003e\n   \u003ctd\u003e\n   \u003c!-- Criteria 1 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eEncryption\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eEnsure that all sensitive data is transmitted over an encrypted channel.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eIf data is transmitted in a clear text attackers can easily gather sensitive\ninformation (e.g. credentials, audio and video streams, private data).\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Intercept connection between a robot and a control center application or a cloud\nserver.\n- Use protocol analyzer to verify that transmitted data is encrypted.\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n\n   \u003c!-- Criteria 2 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eReplay protection\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eEnsure that transmitted data cannot be replayed.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eIf replay protection is absent, attackers can record legitimate packets and\nthen arbitrary replay them to achieve desired actions.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Intercept the connection between the robot and a control center application or a\ncloud server.\n- Record the control or configuration packets sent to the robot.\n- Attempt to replay the packets and verify whether the desired action is executed.\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n   \u003c/td\u003e\n  \u003c/tr\u003e\n\n  \u003c!-- Aspect 6 --\u003e\n  \u003ctr\u003e\n   \u003ctd\u003eAspect: \u003cb\u003e3rd party libraries and components\u003c/b\u003e\u003c/td\u003e\n   \u003ctd\u003e\n   \u003c!-- Criteria 1 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eVulnerabilities\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003eVerify that 3rd party software components do not have known vulnerabilities.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eIt is quite common to blindly rely on 3rd party components. However they\ncan easily introduce a vulnerability into the product where they are used.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Identify which 3rd party libraries and components are used and what are their\nversions.\n- Look for known vulnerabilities in the current version.\n- Verify whether the identified component is still receiving security updates and has\nno unpatched vulnerabilities.\n- Verify that the latest security updates are installed.\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n   \u003c/td\u003e\n  \u003c/tr\u003e\n\n  \u003c!-- Aspect 7 --\u003e\n  \u003ctr\u003e\n   \u003ctd\u003eAspect: \u003cb\u003eControl center application\u003c/b\u003e\u003c/td\u003e\n   \u003ctd\u003e\n   \u003c!-- Criteria 1 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eWeb application\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003ePerform a security assessment of the web application.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eThe robot can be indirectly compromised if the attacker exploits a web\ncontrol center application.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Identify web interface that is being used (hosted on the robot itself or a cloud\nserver).\n- Use OWASP methodology to test web application against OWASP Top 10 Web\napplication vulnerabilities.\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n\n   \u003c!-- Criteria 2 --\u003e\n   \u003ctable\u003e\n    \u003ctr\u003e\n      \u003cth colspan=\"2\"\u003eCriteria: \u003cb\u003eMobile application\u003c/b\u003e\u003c/th\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eObjective\u003c/td\u003e\n      \u003ctd\u003ePerform a security assessment of the mobile application.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eRationale\u003c/td\u003e\n      \u003ctd\u003eThe robot can be indirectly compromised if the attacker exploits a mobile\nphone control center application.\u003c/td\u003e\n    \u003c/tr\u003e\n    \u003ctr\u003e\n      \u003ctd\u003eMethod\u003c/td\u003e\n      \u003ctd\u003e\n\n- Identify whether the robot has a mobile app that can be used to control or interact\nwith it.\n- Test the application against OWASP Mobile Top 10.\u003c/td\u003e\n    \u003c/tr\u003e\n   \u003c/table\u003e\n   \u003c/td\u003e\n  \u003c/tr\u003e\n\u003c/table\u003e\n\n## License\n[GPLv3](LICENSE).\n\n## Glossary\n- **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*).\n  - *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.\n- **module**: component with special characteristics to facilitate system design, integration, interoperability, re-use.\n- **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.\n- **firmware**: (in the context of robotics) software that is embedded in robots.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Faliasrobotics%2FRSF","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Faliasrobotics%2FRSF","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Faliasrobotics%2FRSF/lists"}