You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
What is the significance of code.gov to start? The code.gov aggregator visualized agency compliance with a dashboard, but then redirect users to associated Github.com organizations associated with that agency on said site.
Re the previous question: would it not be best to initialize here or elsewhere to work towards a MVP here and now?
Re the code.gov metadata standard, I am not sure how "the code.gov metadata standard could be used to indicate repositories that contain SSP components" can be done given the agency sites Code JSON and that points to these repositories. Am I mistaken?
To the above question, we could really use a RFC/RFP system to flesh out the technical details. I doubt people will think the FCL is a bad idea, but determining the winning approach is a devil in the details concern. :-)
I am proud to be the first commenter. Tell me and others in the community how we can move this forward!
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:
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
Add your comments below or contact us at [email protected].
Press
The text was updated successfully, but these errors were encountered: