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.

This approach allows an organization to quickly develop and deploy new features into production while maintaining an Agile cadence, without sacrificing the organization’s need to conduct security assessments and evaluate risks prior to the deployment of every release. It should be noted that not all security controls can be evaluated using automated methods. Some controls, such as those associated with creating and disseminating policies, must still be manually evaluated for updates at least annually or in accordance with the system’s SP. Generally, such manual controls should not have an immediate impact on system updates or new releases of the system since they are not directly connected to the codebase. Alternatively, in some cases, such as changes to access controls or audit logging, the system changes may have immediate impact on the system’s security posture and require further evaluation that is not automated. In these events, changes can be automatically detected within the development process and automatically trigger a security assessment. This trigger would also put the release on hold until the security assessment has been completed.

The DoD Software Factory and Continuous ATOs

Until this point, we have focused on how DevSecOps pipelines can be used to support RMF activities and obtainment of continuous ATOs. However, actually obtaining continuous ATOs for specific systems is an endeavor that has unique requirements and challenges based on the context in which the system operates. The remainder of this post look more closely at how obtainment of continuous ATOs can be feasibly achieved by a DoD program’s software factory (DevSecOps pipeline).

RMF Steps to an ATO

The RMF process has well-prescribed steps that must be completed to earn and keep valid an ATO: categorize system, select security controls, implement security controls, assess security controls, authorize system, and monitor security controls. Whether a system is pursuing a traditional ATO or a continuous ATO, all these steps must be completed, and must be completed with the same level of rigor and thoroughness.

These steps in the RMF process are completed collaboratively between the system’s AO, system technical staff, and system program leadership, with the AO serving as the final arbiter of what is applicable and acceptable. For the first two RMF steps, system categorization and selection of security control, manual processes are utilized for both traditional ATOs and continuous ATOs—these steps are not easily automated. However, for steps 3 to 6 in the RMF process, automation toward a continuous ATO is achievable, especially in DevSecOps environments.

Similar to how the initial steps in the RMF process require manual bootstrapping to begin the process before automation can be leveraged in subsequent steps, the granting of an ATO will be based on a manual assessment initially, and then automation can be used to retain the ATO. This means that for the initial authorization only, steps 4 and 5 will still require manual intervention, then for continuing authorization and reauthorization those steps will be automated, along with steps 3 and 6.

Security Authorization

RMF step 5, “Authorize System” is the step where the actual ATO is granted. In this step the AO receives a security authorization package containing implementation and evaluation details for all security controls and then makes an assessment whether the mission and business risk of operating the system is acceptable. There are three types of security authorization that must be addressed:

• Initial Authorization—This is the initial risk determination for the system, sometimes called the zero-base review, where all security controls for the system are considered and an ATO is granted if the AO is satisfied that all security controls are addressed in a manner that reduces risk to an acceptable level. Granting this ATO indicates the AO and program leadership are accepting this residual risk. The initial authorization is where manual processes are needed for RMF step 5.
• Ongoing Authorization—This is time-driven or event-driven security authorization that determines that a system still meets the security risk posture established in the initial authorization. Each release of new software code from a DevSecOps pipeline would constitute a need for an event-driven ongoing authorization assessment. This type of ongoing authorization assessment can be automated in a DevSecOps pipeline, resulting in a continuous ATO. This is the automated portion of RMF step 5.
• Reauthorization—This is a static, single point-in-time risk determination and risk acceptance decision that occurs after initial authorization. The need for reauthorization can result from time-driven or event-driven activities. Typically, reauthorization occurs when there is concern the risk level for the system may have risen above the acceptable level. The AO may determine that reauthorization requires a full assessment similar to the initial authorization, but generally a targeted review focusing on the area of risk is performed instead. Reauthorization can be automated or it can be manual. For manual reauthorization, the DevSecOps pipeline can still speed the process by automatically generating the artifacts needed for the AO to make a risk determination.

4 Considerations for Continuous ATO

To grant a continuous ATO, the AO will consider the entire software development ecosystem that leads to system deployment. Principally, there are four areas the AO will be concerned with:

• software development practices
• the platform the DevSecOps pipeline operates on
• tooling implemented in the DevSecOps pipeline and how the tools are used
• how production deployment is performed

Some DoD programs build their own DevSecOps pipelines, while others leverage DoD DevSecOps platform providers, such as Platform One, Kessel Run, Black Pearl, or the Army Software Factory. Utilizing a DevSecOps platform (and associated tooling) that already has an ATO can reduce the ATO timeline for a software system developed on top of that pipeline because adherence to some RMF controls can be inherited from the platform’s ATO. However, keep in mind that the local AO for a software system to be deployed may choose to accept the DevSecOps platform’s ATO or not. Typically, the DevSecOps platform’s ATO would be accepted, and the AO would focus attention on the software development practices and deployment procedures for the software system under their direct purview.

A Continuous ATO Roadmap for the DoD

With the end goal of obtaining a continuous ATO for each production deployment from the given DoD program’s software factory, a series of activities must be completed. Most DevSecOps pipelines are continuously evolving, so a necessary precursor to obtaining a continuous ATO is to ensure the pipeline is built with all the capabilities needed to support a continuous ATO. Beyond that, the following courses of action must be planned and executed to obtain a continuous ATO:

• In preparation of pursuit of continuous ATO, interview all known stakeholders to understand their desires and concerns.
• In preparation of pursuit of continuous ATO, review lessons learned from other programs that have pursued continuous ATOs.
• Develop an execution roadmap for internal and external software factory capabilities.
• Develop a clean summary of product backlog items, so that they can be mapped to RMF security controls they may address in the future.
• For each production deployment target, identify the AO who is responsible for authorizing the system.
• For each AO, communicate the desire to obtain a continuous ATO and ascertain what the AO’s requirements are to support such a plan.
• For each system, work with the AO to determine the correct system categorization.
• For each system, work with the AO to select the relevant and appropriate security controls.
• For each system, implement the necessary security controls and automate generation of ATO/continuous ATO artifacts. Much of this will be provided automatically by the DevSecOps pipeline; the initial work will be in mapping tool features to security controls and configuring the tools to meet security control requirements.
• For each system, determine how controls without automated solutions can be addressed. For example, a requirement that audits logs are reviewed manually each quarter could be essentially automated by having the system trigger an alert when the action needs to be performed and then having someone check a box in the system to indicate the review is complete.
• For each system, work with the AO to assess that implemented measures are satisfying security control requirements.
• For each system, work with the AO to ensure proper system continuous monitoring is in place.
• For each system, receive system initial authorization (ATO) from the AO.
• For each system, receive approval that necessary measures are in place for ongoing authorization and reauthorization and obtain a continuous ATO.

For each continuous ATO being sought, the software systems’ technical leadership must complete the activities listed above. However, there is opportunity to gain efficiencies because much of the same information will be requested for each ATO, and there will be many overlapping security controls among the ATOs. A key element to success will be to design the DevSecOps pipeline to produce the unique authorization package (collection of artifacts) for each ATO from the corpus of data and information available from the DevSecOps tooling.

The Right Tooling Environment to Speed Up Continuous Authority to Operate

DevSecOps development environments are rife with the tooling and automation needed to speed up the ATO process and make continuous ATOs a reality. However, it is imperative that software systems’ technical leadership staff proactively plan how to leverage these capabilities for ATO/continuous ATO purposes. When the capabilities of DevSecOps environments are tuned to monitor areas of concern for RMF controls and automatically produce related artifacts, the promise of continuous ATOs is within grasp.