The Role of DevSecOps in Continuous Authority to Operate

Federal agencies expend considerable resources seeking Authority to Operate (ATO) approval for information systems. The ATO approval process requires gathering a copious amount of information to create an ATO package to submit for approval. Subsequently, the approval process involves a time-consuming, detailed analysis of these artifacts. As a result, federal agencies are seeking ways to make the ATO process faster, more efficient, and more automated. Two catalysts to achieving these improvements in the ATO process are the introduction of continuous ATOs and the adoption of DevSecOps practices. This post describes how DevSecOps can enable obtainment of continuous ATOs, as well as reduce the time and cost for gathering ATO materials. This post discusses DevSecOps and continuous ATOs within the context of the U.S. Department of Defense (DoD) specifically, but the concepts presented here are directly applicable within many other U.S. Government departments and agencies.

Within the DoD, the use of Agile and DevSecOps continues to increase. The DevSecOps approach favors rapid development and deployment. Such rapid development and deployment must be balanced against the need to ensure the software systems are secure with minimal risk, thus enabling them to receive timely ATOs/continuous ATOs. As this post illustrates, the key in achieving this balance is the proper implementation and utilization of tooling and automation.

DevSecOps and the Software Factory

In practice, DevSecOps typically takes the form of building a software factory, where software is continuously coded, checked-in, built, tested, and deployed. The DevSecOps software factory is a combination of people, processes, and tools that enable continuous improvement of software and continuous, incremental delivery of software versions to production.

While DevSecOps technically refers to the software development pipeline (the factory), the term is also often used colloquially to refer to the software development methodology. Specifically, it is often inferred that a DevSecOps software factory is used in combination with some form of Agile development methodology.

While Agile and DevSecOps can be adopted independently, a symbiotic relationship exists between them that allows for significant impact when implemented together. Agile provides a development methodology ideally suited for DevSecOps pipelines, which in turn provide the necessary pillars to turn Agile concepts into development reality. Even if Agile is not being formally adopted with a DevSecOps software factory, the utilization of a DevSecOps pipeline generally implies a desire to build software rapidly with frequent updates and releases.

Throughout the software development lifecycle, a software system’s program manager is constantly making decisions and tradeoffs between cost, schedule, functionality, and quality. Their focus is generally on key performance parameters (KPPs) and their compliance with all regulations, along with cost and schedule parameters. However, with every decision and tradeoff there is a risk that the system will fail to meet its operational mission due to security concerns. Consequently, deploying and operating software systems contains inherent security risks. Some can be mitigated through risk controls, and others may be accepted as residual risk. Within the DoD, it is the job of the authorizing official (AO) to focus principally on risk and security, without being held to other KPPs that can influence program managers’ decisions. A software system’s AO is charged with determining the suitability of risk controls and the acceptability of residual risks. This determination is made through the Risk Management Framework (RMF) process.

An ATO is usually good for up to three years, and it is assumed that no major changes to the system’s cybersecurity posture will be made during that time. In the event of such changes, the AO will usually require a reassessment and reauthorization of the system. This traditional approach is not well suited to Agile software development methods and DevSecOps, which focus on delivering working software frequently. Agile software often produces new software every couple of weeks, but the release schedule can range from every couple of hours to every couple of months.

With an eye towards Agile development and DevSecOps pipelines, the RMF methodology introduces and encourages an alternative approach to the traditional three-year ATO process through ongoing authorization decisions, or continuous reauthorization. This continuous reauthorization is referred to as a continuous ATO, which can be used for systems that have “been evaluated as having sufficiently robust system-level continuous monitoring programs.”

DevSecOps and Continuous ATOs

The DevSecOps approach to software development fosters not only an increase in communication and collaboration between software development and operations personnel, but also with other stakeholders. Specifically, information system security officers (ISSOs) and other security professionals can be more tightly integrated into DevSecOps environments. This integration makes obtaining a continuous ATO feasible. As a DevSecOps team works through the RMF process and develops the system’s security plan (SP), they must identify a continuous monitoring approach for the applicable security controls, with a focus on identifying automated ways of performing security assessments during continuous integration (CI) and continuous delivery (CD).

A complete SP should be integrated into the development platform, where both developers and the ISSO can view all the same artifacts. This integration allows any changes to the system’s security posture to be immediately identified and reported to the ISSO to ensure that all security controls are adequately addressed. Automated continuous monitoring is used to meet the RMF’s independent assessment requirement and can automatically provide the assessment results to AOs or their representatives, allowing them to evaluate the system’s security risks and provide continuous reauthorization. Moreover, DevSecOps automation also enables a complete audit history and traceability of previously approved security changes.

Essentially, the path to a continuous ATO is to develop a DevSecOps software pipeline with automation established for enforcement of policies and controls, execution of testing tools, and generation of authorization artifacts. In an environment with a continuous ATO, the intent is to allow the AO to trust the process that produces the software as much as it trusts a reviewed piece of software in a traditional ATO review. If the AO is comfortable that the DevSecOps pipeline will sufficiently monitor, test, and control the software it produces, a continuous ATO may be granted, which will allow for a more rapid software release cycle.