Nearly two years ago, Federal agencies began 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.
A key challenge however was the fact that security continued to be a far less agile process, particularly when it came 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—took 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.
It seemed like a great idea at the time but we never heard much about Agile ATO after that.
Turns out, agencies found out the hard way that for the new Agile ATO process to meet the build and ship timelines, it meant integrating additional security controls that went far beyond the conventional vulnerability scanning and configuration management requirements they had become accustomed to. In fact, systems are now being deployed to operations before properly completing vulnerability scanning and ensuring secure configurations in a timely manner. We now know that using zero trust principles to be truly secure requires integrating a complex layer of additional security controls encompassing:
- User authentication
- Device validation
- Firewall setup
- Authorization of user devices to access services and apps
- Dynamic authorization and verification of users in real time
- The ability to vet users and devices on the fly so that every connection is secured during operations
These key controls need to be integrated into the design of the application in order for the Agile ATO to take advantage of new technologies and really make the Agile ATO process viable.
And while Agile ATO was effectively implemented for new systems that had been built with some of these key controls in place, it did not apply as well when getting an ATO for an existing or legacy system or one undergoing upgrades. Many of these systems built prior to beginning any ATO work required an iterative approach that was more challenging because these systems typically required retrofitting to meet new security requirements.
So the fact remained that product development could not truly support an Agile ATO process without that security layer, as developers were not able to get their applications into the hands of real users until that security layer was in place.
Fast forward two years and Agile ATO is in the news again. As it turns out all of those key controls are inherent and delivered holistically as part of the deny-all, authenticate-first Software Defined Perimeter (SDP) solution architected by the Cloud Security Alliance. In fact, NIST is currently preparing to demonstrate how SDP can be integrated to support a truly Agile ATO process. NIST goes one step further working with the ATARC cloud working group and using OSCAL to generate system security plans for Agile ATO to be successful.
So while the original Agile ATO showed promise, Agencies need to know that the opportunity now exists to holistically integrate the key controls required to not only speed up the Agile ATO process but also truly secure new AND legacy systems during operations.
The industry is starting to recognize and embrace SDP technologies that address all layers of network stacks in their security solution. Waverley Labs’ approach to modularize its SDP offering to implement ALL the deployment models in the enterprise is first of its kind. Using single packet authorization (SPA) techniques combined with a deny-all gateway to hide the infrastructure within the perimeter, providing a separate control and data channel to secure end-to-end connections and an internet-scale packet-filter to drop all unauthorized connections separates Waverley’s approach from existing SDP and zero-trust implementations. To learn more about engineering digital risk protection using SDP, check out this white paper.