Federal Compliance Library
A conceptual approach to helping to streamline the authority to operate process.
Overview
The Federal Compliance Library is a conceptual approach to helping to streamline the authority to operate process. We welcome your feedback.
The problem: Component redundancy, duplication of efforts
The bureaucratic process to obtain the ATO needed to launch a government IT system is slow, labor-intensive and expensive.
Agency product owners need an ATO to demonstrate compliance with common security standards and controls. The end paperwork product of ATOs — systems security plans (SSPs)— are cumbersome documents that become obsolete before they’re even completed.
To compound all of this, we have hundreds of federal agencies generating unique compliance statements for the same or similar products.
The solution: A centralized, integrated components catalog
We suggest the U.S. Government build and maintain a Federal Compliance Library of reusable components that agencies can share and iterate on in a public-private partnership.
This library would support cross-agency compliance efforts by offering vetted pre-sets, templates, and baselines for various IT systems.
Reusable compliance components will enhance the creation, maintenance and understanding of SSPs. They’ll also support gap analysis, automated verification and ongoing assessments and authorization. Security and compliance checks will still need to be verified at the system level, but a Federal Compliance Library would prevent us from reinventing the components wheel.
Our end goal should be to:
- Shift compliance to developers and build it into the development process (versus treating it as the last item on a bureaucratic checklist).
- Create the initial SSP with vetted, managed, component-based control implementation statements.
- Ease system audits with continuous monitoring/authorization.
How the Federal Compliance Library could work
The Federal Compliance Library could be both public and private Git repositories that contain reusable SSP components, paired with the code or configuration representing that component. Leveraging tools that developers already use can inform that shift.
Everything that can be released publicly and without requiring a login should be. Aspects of SSPs that contain personally identifiable information or system-sensitive information can be excluded or shared privately.
To accomplish this the code.gov metadata standard could be used to indicate repositories that contain SSP components. That way, the same inventory tools developed for code.gov could be used for building public and private compliance libraries — as well as assembling components from these libraries into systems.
Add your comments
We’ve created an open issue in GitHub to discuss this.
Add your comments and feedback or contact us at ato-asap@civicactions.com.