18F Thinks Security Authorizations Should Be Agile Too

It’s said business eats cybersecurity for breakfast. But when it comes to agile development, security is integral to the process, and that means security has to be agile, as well.

Federal agencies have been embracing a shift to agile development methodologies—releasing projects in stages to get user feedback and rectify bugs early in the process and continuing to iterate and improve over time. But security is often a far less agile process, particularly when it comes to getting an authority to operate, or ATO—an arduous process that can stall deployment of even small-scale systems.

The developers at 18F—an internal digital advisory group based out of the General Services Administration—are taking this challenge head-on, developing an agile ATO process for agencies that puts the security work up front, rather than at the tail end of a project.

“Something that has been very, very difficult for us is to work with the security teams at agencies to work in an iterative way,” said Michael Torres, director of product at 18F. “What we’re used to seeing is the ATO—authority to operate—not being granted until the very end of the project. What we try to do is at the very beginning of the project, the first few weeks, we get an ATO. And then every piece after that, we increment that ATO so it covers more and more of the system.”

That initial ATO can be a small mountain to climb—it includes the initial product plus the underlying infrastructure and third-party support systems—but still much easier to summit than the full process. This is especially true if the security team is not included in the conversation until the very end.

“It’s been a huge cultural shift for a lot of the security offices at agencies but it is possible,” Torres told Nextgov after speaking at the Forrester CXDC event on May 31. “I think that there’s a tendency because security has always been left to the end and because security people have been burned so many times, I think they, rightly so, are pretty shell-shocked when dealing with a new technology. So, they want to cover all of their bases initially so that they don’t have to worry about it.”

As with the rest of the development process, 18F is trying to change that mentality.

“What we’re advocating is to help them and help the program team just focus on this small piece that we’re releasing so that we can make sure that that’s secure and also put in processes and maybe some infrastructure to make sure the next time we release there’s a process for an iterative ATO that doesn’t take as much time and is not as daunting,” Torres said.

The ATO process is notoriously slow, as it requires reams of documentation and an authorized third-party assessment organization, or 3PAO, to validate the security posture of a system. The Federal Risk and Authorization Management Program, or FedRAMP—the program that oversees the process, grants provisional ATOs for cloud services and validates agency-issued ATOs —has been working to streamline the process, which can take many months and millions of dollars.

“As soon as you have an MVP, or minimum viable product, that has some real value for users that you want to test, that’s when you should get your ATO,” Torres said.

Product development cannot truly be agile without that security component, he said, as developers aren’t able to get the product into the hands of real users until a security layer is in place. Without that real-world feedback, developers can’t truly apply the user-centered design tactics that make the agile process so valuable.

“You can be agile all the way up to beta” without including security, he said. “And then when you’re finally releasing at beta, you’ve basically done a waterfall release because you haven’t shown it to users until the very end and you haven’t actually been using production data.”

“The ATO process can work in a variety of ways, and can effectively be implemented in an agile manner during the development of a system,” FedRAMP Director Matt Goodrich told Nextgov. However, that approach is only viable during the development of a new system. The agile process doesn’t apply as well when getting an ATO for an existing system or one undergoing upgrades.

“Since many systems were built prior to beginning any ATO work, an iterative approach may be more challenging because the system is already functional and sometimes requires retrofitting the system to meet new security requirements,” Goodrich said. “While an iterative approach to existing systems can be effective, it is often not as easy or straightforward as implementing the ATO process during the development phase of a system.”

But for new systems, 18F’s approach is a good one, he said, adding that FedRAMP’s Joint Authorization Board, or JAB, is using agile methods for its review process.

“As FedRAMP continues to evolve and improve the ATO process, we will continue to identify new ways to implement agile methodologies,” Goodrich said.

“This is where we’re going,” Torres said. “We have not had a lot of opportunity to do this because we’ve just started talking about this. But this is where we’re hoping things move.”

Torres said the 18F team initially developed this agile ATO process while working on one agency’s project and are currently trying it again with a second.

“We’re very optimistic that this is a great way to ensure that agile can work in government,” he said.