The DOD risk management framework clearly maps out the steps required to achieve an authorization to operate (ATO), but an ATO isn’t enough. If you want to realize the full potential of a DevOps pipeline, you need a continuous ATO. Without it, you face a new risk check for every new software release. Recognizing this, the secretary of defense issued a memorandum highlighting the key factors required for an organization to achieve continuous ATO in February of 2022.
In A Systems Approach to Continuous ATO, Mark Hurter, a global solutions architect specializing in compliance at CloudBees, explains how you can leverage the CloudBees platform to meet those new standards and experience the full benefit of a CI/CD pipeline.
Let's cover some of the highlights of the talk and see how they might apply to you.
Why Is the Continuous ATO So Important?
Mark makes the reasons why you need a continuous ATO very clear. It's what allows you to release your software at the speed of DevOps. Without it, you face not having a current or updated ATO for a new feature and will still have to go through the risk management process to deliver it to the front lines where it is needed.
In the commercial world, the ability to implement DevOps ideas and methods have decided who wins and loses for many years. Now it's become a deciding factor on the battlefield, and you need to adapt. An agile software pipeline that produces quality products can affect changes in short order, and delivering those changes is necessary to maintain a battlefield advantage. The continuous ATO makes it happen safely and effectively.
Of course, you still have to achieve the initial ATO, but once you’ve reached it, the next step is to build a DevOps feedback loop that not only allows ideas to reach production faster, but also makes it possible for feedback from the front lines to impact the next release.
So, how do you get there?
What Does It Take to Achieve and Keep a Continuous ATO?
While the benefits of achieving a continuous ATO are clear, the path to get there isn't. The new policy clearly indicates that the DOD sees the need for a continuous ATO, but it doesn't map out a unified or even a reusable approach for getting there.
The AO Dilemma
Mark starts by mapping out what the authorizing officer (AO) needs to know before they're ready for continuous ATO.
First, they need the ability to assess, in real time, that their application is secure and compliant. The goal here is to be able to continuously release new code, but that means that the code is always changing. AOs need continuous evidence that the code is still secure and compliant.
Second, they must be able to assert that compliance based on the current risk posture. Again, the goal is for the code to change. Regulatory requirements are periodically updated, too. So are modern development tools and methodologies. All these factors contribute to the risk posture, and have to be integrated into the decision-making process.
Finally, the AO has to have the evidence to back up their assertions. Auditors and regulators need to see the data. Simply making the assertion that you're ready isn't enough. You must be able to back it up with hard data in an accessible format.
With those capabilities in mind, we can reason about what a DevOps platform must be capable of in order to run in a continuous ATO environment.
First, the ability to support continuous operation is table stakes. This goes beyond the basic requirement of supporting continuous integration and delivery; the system must also provide the continuous feedback required to verify ongoing compliance.
The system must also support automation. With a high level of automation, you achieve higher throughput, decrease human error, and gain confidence in your pipelines.
A holistic approach spans your enterprise and provides you with visibility across all your systems. You need this to properly assess how changes impact everything and prioritize your issues.
Which takes us to the last two requirements. The platform has to help you make the right decisions about prioritization: what to fix now, and what to defer. It also needs to provide you with controls that compensate for issues that you decide to set aside for later.
Three Key Capabilities
Mark boiled these features down to three key capabilities:
You need to adopt and use an approved DevSecOps reference design. This is the foundation for ensuring that you have a secure and repeatable process to secure your pipeline and to achieve and keep the compliance needed for a continuous ATO.
Ongoing visibility is the only way that you maintain awareness of the state of your pipeline and its continued compliance.
An active cyber defense makes it possible for you to respond to threats in real time. Without the ability to quickly respond to attacks, they'll spread.
How CloudBees Helps With Continuous ATO
Let's see how CloudBees addresses these requirements.
Model Reference Design
This slide above demonstrates how CloudBees CDRO maps into your model reference design.
CDRO's model includes the checks, control, and approvals you need to implement a cATO-compliant model. This model must go beyond a CI/CD pipeline because it needs entrance and exit gates that ensure that your product stays secure and within compliance.
With CDRO you can create gates around unit test cases, static code scans, and other software quality checks, and the system will collect evidence if they passed or failed. The gates can also be automated or configured with a manual approval.
In order to successfully implement cATO, you need visibility into all your digital assets:
Code - the underpinning of your software
Binaries - what your code produces, combined with third-party libraries that must be secured from supply chain attacks and zero-day defects
Environments - where the code runs. Today's environments are dynamic and often ephemeral.
Identities - who deploys and uses the software
Data - a first-class asset that is both ingested and produced by the software
Mark concisely describes this slide:
Here you've got a comprehensive and a contextual view of your digital estate. The authorizing officer has all the evidence necessary to assert their compliance posture and provide evidence of compliance for that continuous ATO. The product owner can see what aspects are compliant or problematic, and developers are sent contextualized and prioritized lists of what they need to focus their efforts on.
Finally, we have compensating controls. What happens when a new feature fails, or a new attack arises? How do you react without completely disabling the application?
If you establish a standard where every new feature is created with a corresponding feature flag, you have a built-in compensating control. You have the ability to respond to threats in real time, not by withdrawing a release or killing an application, but by toggling the features that are threatened. This leaves the rest of the service intact.
This doesn't mean you don't need to prepare for rollbacks for more serious issues, but it does give you a robust mechanism for addressing deficiencies and active threats.
CloudBees and the Continuous ATO
It’s clear that a continuous ATO is what you need to successfully support your mission.
The CloudBees platform has the tools and capabilities you need to deliver software at DevOps speed combined with the model, visibility, and controls you need to achieve and maintain compliance.