The ABCs of ATO: Insights from the 2021 ATARC Federal DevSecOps Survey (Part 3)
The Advanced Technology Academic Research Center (ATARC), in partnership with the U.S. Air Force, conducted a large scale survey on the current status, challenges, successes, and vision for the future in the Federal DevSecOps landscape. In this series of blog posts we’ll be reviewing the results from the 2021 ATARC Federal DevSecOps Survey and highlighting key takeaways from the responses of the nearly 300 technical professionals in the public sector that participated.
By: Traci Robinson-Williams, Technology Business Strategist | Digital & Cultural Transformation Evangelist, GitLab
Our last post delved into the critical nature of instituting modern planning tools and methodologies, the benefits of toolchain integration, and explained how to “shift security left.” In today’s post we’ll be focusing on the challenges of obtaining application Authority to Operate (ATO) within federal agencies and explore some of the practical steps public sector IT teams can take to ease the process.
The Rocky Road to ATO
The challenges and time investment associated with the ATO process was the second most commonly selected barrier cited by survey respondents as inhibiting digital transformation and IT modernization within their organizations. At the same time that IT teams are expected to rapidly roll out new applications to support their organizations’ mission objectives, they are simultaneously expected to meet the rigorous compliance standards enforced by their cybersecurity teams in order for those applications to be granted ATO. IT teams are in a sense “stuck between a rock and a hard place,” sandwiched between the demand from agency leadership for new capabilities and the demand from cybersecurity teams for compliance with extensive security controls.
Overcoming Silos
While overcoming these often conflicting demands is not impossible, matters are frequently made worse by the practices of development teams themselves. To illustrate, nearly every program—even within the same agency—has a tendency to start from scratch, independently receiving approval from the security office and neglecting to share results with other teams. This prevents development teams from establishing best practices across the organization and contributes to a fracturing of institutional knowledge. In the same vein, program offices maytake their version of required security controls and decide which ones they have to comply with on an ad hoc basis. Success is therefore often dependent on the initiative of the security office to get involved early in the software development lifecycle (SDLC), which may not happen due to resource constraints.
Accelerating ATO
Fortunately, many of the steps development teams can take to streamline the achievement of ATO help speed up the SDLC as well. For example, simplifying the DevSecOps toolchain with a solution like GitLab eliminates the “toolchain tax” (the overhead of maintaining multiple stand alone tools) while simultaneously limiting the number of tools that must be accounted for in required security paperwork. Likewise, establishing a standardized method of implementing controls for all application delivery processes across the entire organization means development teams no longer have to “reinvent the wheel” each time they begin a new project. The end result is the achievement of ATO in hours, not weeks or months.
Bringing it All Together
The 2021 ATARC Federal DevSecOps Survey has taught us a lot about the kinds of challenges development teams face in the public sector and what they can do to overcome them. One of the key learnings is that technology is only part of the solution. Just as important, if not more so, is the willingness of internal stakeholders to adopt new processes that will enable their teams to operate more quickly and efficiently. This extends to a commitment to cross-functional excellence, bringing together various stakeholders, including security teams and business decision makers, into the process early and ensuring communication and transparency across departments.
Thank you for reading the last edition of this series. For those of you who may have missed them, please check out parts one and two for additional insights. As always, if you’re a developer working in the public sector we’d love to hear from you! What surprised you most about the survey results? Are there additional challenges you face that we didn’t ask about?