How to Expedite Authority to Operate & Secure Development at Scale in the US Government
By Jay Ryan, U.S. Federal Government Program Manager, Security Compass
Connecting secure software development and ATO
U.S. government agencies are undergoing tremendous change in the area of secure software development maturity. A key benefit of the change is the reduction in time to achieve Authority to Operate (ATO) for software applications. Ensuring software is constructed with security in mind from the very beginning of the software development process reduces the risk of a breach and streamlines ATO attainment. Secure software development does not negate the need for risk assessment and management. Instead, it clarifies threats and mitigation options much earlier in the software development process.
There are a few relevant pieces of evidence that support the notion that secure software development is a U.S. federal government priority.
From Waterfall to Agile and DevSecOps
First, we are witnessing a shift toward Agile and DevSecOps methodologies (see Figure 1), which focus on considering security much earlier in the software release process.
We commonly refer to this as a “shift left” (see Figure 2), which implies security and compliance concerns are addressed through the early stages of design and requirements.
From months to weeks or days
Next is the emphasis on scaling ATO, or the push to shorten the approval process (see Figure 3), ideally driving toward continuous ATO where much lower-risk incremental decisions are made rather than infrequent high-risk decisions.
Security inheritance and scalability
The third piece of evidence is the speed of innovation to support continuous improvement. This includes layered compliance for scalability and security inheritance (see Figure 4), microservices architectures for reusability, cross-functional membership for empathy, external resources for diversity, and factories for better consistency.
Current challenges
While much positive change is occurring within the U.S. federal government, it is hardly a smooth transition across the board. Current challenges include:
- Design enforceability: There are lingering questions about design enforceability in a still-maturing DevSecOps culture. In addition, challenges are presented when designers attempt to proactively influence the early stages of development and are not permitted.
- Siloed communication: Existing organizational layers can also impede the need for cross-functional collaboration between development and operations teams and the authorizing official (AO) members.
- Understanding how to operationalize DevSecOps: Often, there are questions about how to systematically operationalize DevSecOps. In the U.S. government agencies, the need for standards and frameworks at scale is critical, so the DevSecOps program follows best practices and remains auditable. In this area alone, there are many standards and frameworks to choose from, including NIST RMF, NIST 800-53, the NIST Cyber Security Framework, FedRAMP, CMMC, CNSSI, and HIPAA, the Department of Defense (DoD) DevSecOps Playbook, the DoD DevSecOps Reference Design, the Air Force Continuous ATO Playbook, the IEEE Standard for DevOps (IEEE 2675-2021), and others. Operationalizing is often achieved through some combination of these documents.
Rising to the challenge
Despite existing challenges, recent innovations in U.S. government agencies continue to catalyze the move toward Continuous ATO. Layered Compliance, for example, is an architectural construct that allows new applications to be built from pre-approved components. This process helps accelerate delivery time for custom applications. Additionally, novel solutions are being built on top of current tools to bring more insight and clarity to decision-makers. These new tools take advantage of existing ATO software in order to offer new capabilities and services.
SD Elements provides a scalable solution in the early, mid, and AO reporting stages of an application.
Context sensitive
SD Elements helps streamline the software development process in the early stages by generating context-sensitive security requirements. The platform does this by using an adaptive and customizable survey that enables automated mapping of the current software application architecture to existing standards and frameworks. This mapping ensures that only applicable security requirements for the project are assigned to developers and non-applicable controls are removed. It also reduces the number of controls that need to be addressed by the engineering team for the application by using the inheritance tracking model for controls that are implemented in a higher layer.
Once context-sensitive security requirements are defined within SD Elements, integrations with issue-tracking tools like Jira ensure consistent, program-level oversight across software development teams.
Consistent, observable, traceable
In the past, it was common for software development teams to create security requirements tasks based on personal experience. This approach, however, lacks the objectivity and consistency required for ongoing system resilience and trust. Measuring against an objective standard provides a baseline of consistent requirements. SD Elements provides the critical traceability of completed tasks against objective standards (developed by NIST, ISO, IEEE, and others) without reliance on subjective experience.
Auditable
As requirements are implemented, reports can be generated to show the status of the security requirements and implemented controls against a standard. These reports can then be used to help demonstrate control compliance to the authorizing official. Compliance information is readily available at any time, with full traceability down to the individual project tasks related to the implementation of specific security controls.
Achieving ATO faster with SD Elements
SD Elements helps enable rapid or continuous ATO in U.S. government agencies by automating the identification, tracking, dissemination, and management of controls that map to U.S. federal government security and privacy controls. The capabilities required to manage a cross-functional security program at scale are built into the product, which allows U.S. government agencies to focus on rapid software development and innovation in support of mission objectives.
Looking ahead, there are two key challenges to consider. First, much of the current workaround DevSecOps is based on cloud adoption and enablement strategies. As we enter into hybrid infrastructures that include IoT devices, the integration of these environments will pose a formidable challenge. Second, the cultural change required will be a significant effort. Moving from an annual routine to a daily routine will require a change in process and tools; reports with timely information need to be produced.
Despite these challenges, we remain optimistic that DevSecOps will continue to help the US Federal Government achieve its goal of reducing ATO timelines while balancing appropriate security earlier in the development lifecycle.