Every time a government agency deploys a new piece of software, someone has to issue an Authority To Operate. It’s a sort of Good Housekeeping seal of approval for secure, reliable software. It can also be a hurdle too high to enable frequent software updates.
It doesn’t have to be.
In May, the Pentagon blessed a new methodology for supporting rapid software updates: The continuous ATO (cATO) requires a cultural and process change, but is ultimately a more secure and reliable alternative, according to the Continuous Authorization to Operate (cATO) Evaluation Criteria.
Bryon Kroger, Founder and CEO of Rise8 who coined the term and pioneered the first cATO at the Air Force software factory Kessel Run, said the concept is built on the Risk Management Framework developed by the National Institute of Standards and Technology and embodied in NIST 800-53.
A cATO ensures that “when we’re ready to release software, it’s already authorized,” Kroger said.
As Chief Operating Officer at Kessel Run, Kroger led acquisitions, development, and operations for the enterprise-scale software factory. His team proved that cATO speeds software deployments and enhances security. But translating that pioneering success more broadly is anything but instant.
Obstacles to cATO Success
Adopting the agile processes and cultural mentality of DevSecOps, the software processes that combine development, operations, and security, are a tall order for any organization.
cATO “involves a lot of continuous monitoring,” Kroger said, and that scares people off. Automation can ease that burden, with machines tackling much of the routine compliance work, but that too can be scary—requiring a level of trust, confidence, and commitment from all parties.
“People hem and haw about how bad RMF is,” Kroger said. But having a framework is the first step to developing better processes. Rather than wringing one’s hands over one more set of requirements, he said, project managers should just “Go understand the system, go read the RMF—it’s a surprisingly good set of documentation.”
Once a development team fully understands the Risk Management Framework, the door is opened to a more collaborative relationship with authorizing officials because now everyone is speaking the same language. That, in turn, can fuel the shift to cATO.
Secrets to Success
All of Rise8’s processes are geared to the cATO model. After years of work there and at Kessel Run, Bryon lays out the key factors to adopting a cATO culture.
Topping the list is “controls inheritance.” With potentially hundreds of different controls at play within the development pipelines, app builders need a way to move forward consistently and efficiently as they strive for continuous authorization.
By inheriting the underlying controls, developers can streamline their processes, freeing them to focus on development and on their specific areas of concern. By adopting controls inheritance, “they’re only truly responsible for their portion” of a program, reducing the number of controls they have to worry about from as many as 400 or 500 to a fraction, Kroger said.
Next comes the assessors’ experience. Across the DoD, “we practice user-centered design with warfighters,” Kroger said. That means building products and processes that meet a specific user’s needs. If the user is pleased, the project is successful.
Likewise, the continuous assessment and monitoring process should take the assessors into account, since “they’re the ones using [and reviewing] this process.”
The assessors “are doing one of the most important jobs in the military, which is making sure our software is secure,” he said. So the processes that define a cATO ought to be built to meet their needs.
Ultimately, the Defense Department must change the conversation around authorizations. Rather than making exceptions for cATOs, the default option should be cATO and the conventional processes should become the exception.
In consideration of early presumptions that speedier software development would mean a higher-risk software, the truth is that when implemented with the RMF in mind, cATOs reduce risk by more rapidly fixing known problems. A vulnerability can be identified and mitigated in hours, rather than months or years, reducing risk.
“We need to do a better job of showing how what we’re doing today is very risky,” he said of conventional updating and ATO processes. “Going slow is a risk in and of itself.”
Speed should be seen for what it is—a benefit rather than a liability.
“When we go fast, we actually are able to reduce some risks,” he said. Security flaws get fixed faster, and the risk of under-provisioning warfighters is mitigated by more rapid software delivery.
Highlighting those benefits and the risks of sticking with a conventional go-slow approach can change the nature of the conversation. Agile software, delivered and improved incrementally, and authorized continuously, is better for everyone.