Agency and industry experts want to bring the concepts of software development to the arduous authority to operate (ATO) approach.

A new white paper from ACT-IAC details an operational maturity model, that breaks down how an agency can automate their ATO process and turn it into code.

Dan Jacobs, the cloud portfolio manager at the Office of Personnel Management and member of the ACT-IAC Cybersecurity Community of Interest ATO as code project team, said automating an organization’s ATO process is a complex issue.

“This is something that we look at and say there’s an enormous amount of value because we’re spending huge amounts of time and capital trying to work through what risk management really is. So going into it, we said to ourselves, ‘ideally, I’d love to have some type of open standard leveraging Open Security Controls Assessment Language (OSCAL) that creates data models, system security plans (SSPs) and all the things that we need. Then, we can just go forward and magically things will work,” Jacobs said on Ask the CIO. “That hit a brick wall real quick, so we had to pivot. We spent an awful lot of time talking amongst each other, really just trying to lay out what the dependencies were. What we found out that if you were to move forward with an ATO as code, there are so many dependencies that you’re going to spend the majority of your time just getting mature to the point where you can implement it. In the course of that, we pivoted and said, ‘all right, this sounds like an operational maturity model, where we are breaking out at a function by function level, what an organization has to do in order to get to the point where they can fully automate their ATO, and at that point, they can begin to automate the rest of the risk management process as well.”

The government-industry team created the maturity model around five levels that incorporates data, technology and missions.

Gaurav “GP” Pal, the CEO and founder of stackArmor and another leader on the ACT-IAC COI team, said getting away from the static ATO process has been something agencies and industry have been trying to do for almost a decade.

He said the maturity model gives agencies a roadmap to find their way.

“This ATO maturity model sets out five stages that basically lets you ask where do I begin and how do I start thinking about this problem? A lot of people ask, ‘well, what’s the bang? Why do this? Is it just about a faster ATO or is it about money?’” Pal said. “I think one of the things at least we came up with was, hey, we want to very rapidly go from authority to operate to ability to respond. The whole idea behind the end result is, how do we go in and deliver a more secure cyber posture with the increasing threats that we see?”

And before anyone says, “Oh great, another maturity model,” which is something Jacobs and Pal say they heard from government and industry alike, the ACT-IAC team didn’t want to develop something that was unfamiliar to the cyber community.

Big commitment to move to ATO as code

Jacobs said the approach recognized the commitment an organization would have to make from the technology to the procurement to the workforce to the business areas.

“If you say you want to make a commitment to adopting OSCAL, there’s myriad requirements that are going to come into play, not the least of which is, how do I train my people to do it? There’s a workforce transformation piece. How do I actually build it into my acquisition cycle so that every vendor that I’m looking at supports it? How do I drive the market? Because the linchpin for this thing is a governance, risk and compliance (GRC) tool that is OSCAL ready. Not all GRCs are there. So therefore it’s a limiting so if you want in, I need to make a public declaration everything going forward is it going to have to be based on these open standards, and it just keeps on going and going and going and the interface between the various pieces,” he said. “One of the main things about ATO as code is shifting left, just like everything else that we do, but we are beginning to build compliance, and the expression of compliance directly out of the DevSecOps group.”

That is where this operational maturity model to help organizations understand at each level what the target is based on where they currently are at now.

Over the last few years, several agencies have made progress in speeding up their ATO process and moved toward a continuous ATO. The Air Force, the National Geospatial Intelligence Agency and the Department of Education have tested and implemented continuous ATO processes.

But Pal said ATO as code isn’t the same as a continuous ATO, but they are related.

“How I see it is continuous ATO and ATOs as code have the same overall objective, which is to go in and deliver a better cybersecurity posture and reduce some of the cost through manual efforts,” he said. “That being said, we felt that as an industry and government group through ACT-IAC, there were still some that continuous ATO deals with a part of the life cycle of an ATO, but not necessarily all of it. And so we just felt that we didn’t want to necessarily fall into the same debate on what exactly it is. We felt that taking a fresh look at the entire ATO life cycle, so therefore ATO as code. The simplest way, in my mind, is ATO as code enables continuous ATO. So if continuous ATO is your goal and objective, then ATO as code gets you there.”

OPM drinking the ACT-IAC champagne

Jacobs said OPM is beginning to implement the ATO as code strategy. He said their focus is on how to share data programmatically and external to the agency.

“If we have open standards, we can begin to declare to the world, this is how we plan on doing things. OPM is an organization that has obviously tie ins throughout the entire federal government, and our federal government customers have to have confidence that we are treating their data and our own respectfully, and in accordance with all due diligence,” he said. “I think [OPM CISO] James [Saunders] and I both agree that leveraging OSCAL is a great way to do that, so we’re focusing on that internally. We’re focusing on how to leverage the data collected from logging, the continuous integration, continuous delivery (CI/CD) pipeline, cloud based application programming interfaces (APIs) and other tools that feeding that information into a future state GRC platform.”

Jacobs added OPM is trying to create a risk management and enterprise risk management function that is wholly integrated.

“We recognize we cannot do that using manual means. It must be automated and that automation is not going to happen through proprietary systems because our customers are the entire federal government and any proprietary solution simply is not going to work,” he said.

StackArmor’s Pal said the goal of creating the ATO as code approach is not to force agencies or organizations to buy yet another product or tool.

“We wanted to really build a capability or a tool that would be valid for all of government,” Pal said. “ What we consistently have found over at least the last three or four or five years is the response to the ATO problem is to go buy a tool. But anybody who’s done this for real can tell you, it’s a people, it’s a culture and yes there is a tool that’s definitely a part of it, but it’s not the sole part of it. We just wanted to get away from this tool-centric approach of trying to solve the ATO problem because it’s much bigger. Therefore, whether we call it a maturity model or as I like to call it, actionable steps, the white paper very clearly lays out steps.  If you have the right people that understand this problem and have the skill set and know, OSCAL, that is so critical to go in and make this real. Then you will pick the right tools.”

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.