The software development and IT organizations within U.S. federal government agencies face conflicting challenges. They must defend systems against constant attacks by criminals, hacktivists, and hostile nation states; however, they are also under pressure to modernize their systems and consistently deliver better services at lower costs.
To help ensure more secure software and systems, the Federal Information Security Modernization Act requires federal agencies to have systems in place to assess and monitor security and privacy risks. Becoming certified to provide software – either through internal government development teams or third parties – requires an Authority to Operate (ATO).
As a prerequisite to achieving ATO, teams must demonstrate compliance with the NIST Risk Management Framework and thousands of security controls depending on the deployment environment. Recent research by Security Compass found more than a third of U.S. federal government agencies reported that it took four or more months to achieve ATO, and 72 percent reported the process lasted greater than two months. This process must be repeated when significant changes are made to systems and at least every three years.
Process and Technical Challenges to Achieving ATO
Although the ATO process is designed to improve the security of government systems and software, it also presents challenges for teams attempting to deliver new, secure systems that can improve missions and reduce costs for government agencies.
- With potentially thousands of requirements, ensuring that all are covered consistently is challenging. Translating those into security policies and specific mitigation controls is even more difficult, requiring effort from scarce security resources.
- Once controls are identified, they must be communicated to development and operations teams for implementation, then tracked for completion. This process is still largely manual. Our research found more than six in 10 organizations use spreadsheets to track security requirements (and almost a third didn’t know how the controls were tracked).
- Manual processes also slow down reporting. ATO achievement requires teams to provide evidence of processes and control implementation. Using shared spreadsheets can be unreliable and make it difficult for program managers and assessors to identify gaps.
Achieving ATO at Scale and Speed
Delivering secure software is a requirement for ATO. Delivering it faster is a requirement of all agencies. Doing both is possible by implementing some best practices into the Secure Software Development Life Cycle (SDLC).
Waiting for security scanning tools to identify weaknesses late in the development lifecycle and the required remediation process slows down releases. "Shifting left" – or moving security into the earliest phases of the SDLC – accelerates development and reduces developer/security friction.
Shifting left requires organizations to anticipate weaknesses in their systems during the Requirements phase of the SDLC — prior to writing code. This allows mitigation controls to be identified and assigned to development and operations as part of the normal development process. The result is faster release cycles with fewer vulnerabilities (and less rework).
ATO certification requires additional steps in the development and deployment process. Manual practices delay progress. Automation of requirements gathering, assigning remediation controls, and validating completion of tasks reduces manpower requirements and the resulting delays. It also enables organizations to scale their processes across more applications.
Automation of requirements should include the specific obligations of regulatory frameworks in scope for the system or application. For ATO, this includes the NIST Risk Management Framework and supporting standards like NIST 800-53 (Security and Privacy Controls for Information Systems and Organizations) and NIST 800-218 (Secure Software Development Framework).
Enabling secure and rapid development requires integration with the tools developers use every day. Rather than maintaining requirements and mitigation controls in spreadsheets, they should be assigned as deliverables in popular issue tracking tools like Jira, Archer, and ServiceNow. Required mitigations can be mapped to results from scanning tools like Veracode, Synopsys, Checkmarx, and Nessus to understand quickly which controls are validated and which remain open.
Authority to Operate requires documentation that appropriate processes are in place and followed. Discrete spreadsheets for each project are difficult to manage, easy to ignore, and subject to untraceable changes. A centralized, controlled, and auditable environment for recording all activity regarding a project’s weaknesses, controls, and mitigation efforts simplifies certification.
Improving software security and reducing ATO effort is possible when you adopt proactive security activities. By anticipating weaknesses in software and systems based on the programming language, frameworks, and deployment environment, and assigning mitigation controls as part of the normal development process, teams can reduce rework later in the SDLC. Providing all users with a centralized and audited platform simplifies tracking open issues and provides the evidence required to satisfy ATO requirements.
To learn more about accelerating your ATO program, read The 2021 State of Secure Development & ATO in U.S. Government Agencies and contact us today.