Quality in software is often understood as "execution according to design purpose" whereas security means that "software will not put data or computing systems at risk of unauthorized access." There seems to be a connection between these two aspects but, how do we integrate both of them in the robotics development cycle?

Original article available at https://arxiv.org/pdf/2003.10402.pdf.

We introduce DevSecOps in Robotics,

a set of best practices designed to help roboticists implant security deep in the heart of their development and operations processes.

Where waterfall development once dictated the process of "handing off" from developers to Quality Assurance (QA) to operations, these responsibilities now have blurred borders with most engineers skill sets spanning multiple disciplines. Enter DevOps is commonly known as a set of practices that combine software development (Dev) with Information Technology operations (Ops). They aim to shorten the development life cycle and provide continuous delivery while ensuring the quality of the software (Quality Assurance or QA) ^[1]

In Robotics, as in many other areas closely connected to Computer Science, there is a set of adopted common practices, including DevOps. The figure below pictures the DevOps cycle most roboticists use and split it into 4 phases: Development, Deployment, Production and Post-Production. In the DevOps philosophy, these phases are all connected in a continuous, never-ending, loop.

The waterfall is now a river; development and operations flow together but, where is security in such a landscape? As pointed out by the UK’s National Cyber Security Center, having a secure approach to development has never been so critical, when it comes to cyberphysical systems and, of course, robotics. The way roboticists build software and systems is rapidly evolving, becoming more and more automated and integrated. Many roboticists today define, prototype and develop an entire robotics system architecture in simulation and tie it to tooling which will automate both testing and deployment.

Over the last couple of years we have seen big changes on the arrival of cloud services to robotics and to ’robot infrastructure as a service’ including simulation, fleet management systems, or teleoperation capabilities among others. The promise is that robots of almost any size and complexity can be called into virtual life, changed, or terminated without leaving the desktop. On top of these new capabilities, a process of quick and regular deployments has evolved. Often referred to as Continuous Delivery, this iterative approach is powerful, flexible and efficient, but these strengths bring new sets of risks which your security practices must address. To do so, roboticists will need to consider security as a primary concern throughout your development and deployment processes.

The principles provided below are intended to help secure the entire process of software development in robotics, from establishing a security-friendly culture in your organisation through implementation and ongoing management. It must be noted, however, that using these principles do not guarantee a secure final robot, but should help you gain confidence and insights that the code you deploy is built with a security mindset.

From DevOps to DevSecOps

Security, well identified as a continuous process, needs to be applied individually to both development and operational phases and then holistically to the complete system. When adding security to the DevOps tuple we dive into DevSecOps. Often times called "Rugged DevOps" or security at speed, DevSecOps is a set of best practices designed to help organizations implant security deep in their DevOps development and operations processes ^[2][3]. DevSecOps, also known as SecDevOps and DevOpsSec, seeks to embed security inside the development process as deeply as DevOps does with operations.

Turning again into robotics, security –identified as a process that needs to be continuously assessed both in hardware and software– is a highly time and resource-consuming task. As was proven before in Computer Science, including security –across the development, deployment, production, and postproduction phases– results in a more secure output.

The Figure above depicts our view on how DevSecOps could be implemented in robotics. We list phases, tasks, and activities while providing descriptions to further clarify the effort required.

Development phase

• Plan task
  Threat modeling: use of abstractions to aid in thinking about risks.It identifies security threats that apply to the robot and/or its components (both software and hardware) while providing means to address or mitigate them in the context of a use case and ideally, during development.

  Quality Assurance (QA) requirements: imply capturing the quality metrics and aspects that will be later used to measure a codes compliance. The requirements captured in this activity are later translated into actionable tests.

  Unit, integration and functional tests: unit testing is the practice of testing small pieces of code, typically individual functions, alone and in an isolated manner. Integration testing involves checking whether different modules perform when combined together as a group. Finally, functional testing verifies the functionality of a given software composition, that is to confirm that the corresponding source code provides the expected behavior. In line with Test-Driven Development and other groups’ practices ^[4], it is encouraged to write tests before coding. Particularly, we encourage to a) write the general code skeleton, classes, and public methods and to b) write the test cases for the logic to implement.

• Code task
  IDE checks: many vulnerabilities in products and systems could be avoided if better, more secure coding practices were in place. A number of Integrated Development Environment (IDE) plugins exist, which help developers check for security flaws while they code ^[5].

  Peer Code Review: the act of consciously and systematically analyzing fellow programmers code to check each others mistakes, an effective improvement practice for reducing security vulnerabilities.

• Build task
  Software Component Analysis (SCA): the process of identifying potential areas of risk from the use of third-party and open-source software components. In robotics, this could be very easily extended to hardware as well.
  

  Static Application Security Testing (SAST): the study of software without executing it and by simply looking at its structure and content. SAST is a testing methodology that analyzes source code to find security vulnerabilities.

  Alert on high-risk code changes: when the delta of code changes is above a certain pre-defined boundary, alerts should be generated.

  Build (compilation) checks: CI systems generally involve one or more building process. Compilation output can deliver valuable input and should be accounted for. It is good practice to monitor a compilers output and file tickets for review in the warnings that remain. This can be easily automated and tickets can be filed to a centralized flaw management system like the Robot Vulnerability Database (RVD) ^[6]. An open prototype of such a flaw management system, integrated with Github, is available at https://github.com/aliasrobotics/RVD including the necessary tooling to manage it.

• Test and simulate task
  Dynamic Application Security Testing (DAST): a practice to detect conditions indicative of a security vulnerability in an application or software in its running state. The software is tested from the outside, that is, no access to the source code
  is assumed to be provided and thereby falls into the black-box security testing methodologies. (white-box)

  Deep Static Application Security Testing (Deep SAST): leverages on the the effectiveness of using machine learning-based static analysis to predict security flaws.

  Fuzz testing: a semi-automated testing technique for software that consists of injecting data in search for errors. It involves providing invalid, unexpected, or random data as input. (black-box)

  Penetration Testing (PT or pentesting):the practice of simulating a cyber attack against a given system (with a well defined scope) to check for exploitable vulnerabilities and determining its severity. (white-box, black-box or gray-box)

• Flaw management task
  Flaw management activity: is the cyclical practice of identifying, classifying, re-mediating, and mitigating flaws. It is at the center of security activity and refers to the process of how security researchers, suppliers, and end user organizations
  manage bugs and vulnerabilities, making systems more secure.

Deployment phase

Configuration and system integration task: deals with system integration and configuration of all parts previously developed and conforming the robotic system. It is one of the most sensitive tasks from a security perspective. It is critical to define secure deployment mechanisms and employ strong systematic configuration practices to ensure no flaws are presented during this task.

Production phase

Monitor: deals with the continuous monitoring of the system and should oversee the systems’ performance, errors, and other relevant information. A common good practice is to employ elements that record all activity, securely, for potential future forensics research.

Post-production phase

• Analyze task
  Vulnerability Scans: provide results on new vulnerabilities affecting your
  system and provides solid data on their levels of severity. This data should be fed into the Flaw Management system and prioritized based on common scoring mechanisms.

  Red Teaming: a full-scope, holistic, multi-layered, and targeted (specific goals)
  attack simulation designed to measure how well a companys systems, people, networks, and physical security controls can withstand an attack. It aims to look for vulnerabilities that will maximize damage and meet the goal,in order to test organization/system detection and response capabilities in production.

Bug Bounties program: a coordinated and well scoped effort to encourage security research in a particular system rewarding (with bounties) those researchers who help find bugs. Bug Bounty programs utilize a pay for results model, favour competition and often leverage the crowd sourced model.

Conclusion

With DevOps, engineering efforts now serving multiple masters, where the focus used to be purely on precision, now longevity, scalability and security (with DevSecOps) hold equal footing in product requirement discussions. Where Quality Assurance (QA) had traditionally held the line on risk definition and maintainability, Security now has an equal, if not dominant, role.