How DevSecOps Helps the Federal Government Achieve Continuous ATO

This article originally appeared on The New Stack.

Information security is at the heart of every software system launched in the federal government. In accordance with the Federal Information Security Management Act (FISMA), an information technology system is granted an Authority to Operate (ATO) after passing a risk-based cybersecurity assessment. While necessary, the ATO process can pose challenges to the software development process as it requires an authorizing official (AO) to pre-approve systems against a set of risk controls before putting the systems into operation. An ATO is typically valid for three years, based on the assumption that the system’s cybersecurity posture won’t change significantly during that period. This assumption of relative stasis is often unrealistic because of modern development practices, which facilitate and embrace change. As changes are (inevitably) made, the “set it and forget it” ATO becomes inadequate. As a result, the need to reassess and reauthorize the system negatively impacts the overall cost and schedule of delivering it to the end users.

The federal government’s guidelines for system assessment and authorization, laid out in the Risk Management Framework (RMF), suggests an alternative approach to the traditional once-every-three-years ATO process through continuous reauthorization. Created by the National Institute of Standards and Technology (NIST), the RMF offers a structured process to integrate information security and risk management activities into the system development lifecycle. The RMF continuous reauthorization concept seamlessly aligns with core tenets of DevOps and subsequently paves the way for DevSecOps.

DevSecOps incorporates security activities into the SDLC. The approach helps develop teams seamlessly integrate security and compliance functions into their regular workflows by inserting the necessary steps into the continuous integration/continuous delivery (CI/CD) pipeline. Let’s explore what this reality looks like for federal agencies.

Communication is an extremely effective catalyst for creating a dynamic development process and facilitating cross-functional collaboration between the development, security and operations teams. It is critical to involve security and operations teams in the initial, as well as routine, pipeline-related discussions to ensure that the right security steps are built into the pipeline(s). Consistent conversations between the teams help to build and reinforce trust in the pipeline(s) used in the software factory. Laying out the security requirements early in the software development process helps developers weave the necessary security protections into their workflows and establish delivery pipelines security teams trust.

DevSecOps enables organizations to automate processes, which in turn minimizes defects due to human error. Government agencies deliver higher performing and better quality applications by embedding automated security controls and tests into their pipelines. They also avoid bottlenecks and deliver capabilities faster by automating the tasks and approval gates that really don’t need a human in the loop.

In many circles, security is still seen as an impediment to software delivery, a blocker that is both maddening and inevitable. However, the truth is that security can actually promote speed.

DevSecOps, when properly executed, accelerates software delivery because security checks are completed and defects are corrected continuously throughout the SDLC, as opposed to in one hulking lump after the system has been developed. This is good news for developers (their creations make it into operations sooner), for security teams (they can more easily authorize the system because they know it has been developed in compliance with organizational policy) and for operations teams (they inherit a system that is worthy of running on their network).

Security teams gain transparency and useful insights at every step of the SDLC through an audit trail, governance measures and real-time compliance reporting without waiting for developers to generate and share reports post-development. Those continuous insights, coupled with the confidence of trustworthy pipelines, eliminate wasteful back-and-forth between the security office and development teams and result in much quicker ATO sign-off.

The ATO decision is crucial for federal government agencies, as it signals that an IT system is safe to deploy “in the wild.” Implementing DevSecOps is a simple yet elegant way to push continuous security to the left and reduce the vulnerabilities being released into the production environment. Federal agencies benefit greatly by reducing defects and gaining the trust that the relevant security checks have been executed and the code is always worthy of release.

For more information on how CloudBees helps the federal government deliver secure software more quickly, visit https://www.cloudbees.com/industries/government.