ATO ASAP: Streamlining government security with a Federal Compliance Library

With the perfect brew of open technologies and culture, the federal technology community now has the potential to leapfrog how we manage government security compliance.

To do this, the community — public and private sector alike — must “think different” and work openly, iteratively and collaboratively. This has worked for the technology community at large, enabling it to create continuous, exponential leaps in innovation.

By taking a systems thinking approach to the problem, we can effectively modernize the compliance process, make government more secure and save taxpayer money.

Expediting the authority to operate (ATO) process is fundamental to all of this.

One of the top IT modernization priorities of the federal government technology community should be to build a Federal Compliance Library.

The problem: Component redundancy, duplication of efforts

As we previously wrote, 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

It’s time we 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.

Compliance further, faster

When agencies can seamlessly tap into a communal resource to share and collaborate on commonly used components, they will have more time to focus on security postures that are truly unique and require more attention.

By building a Federal Compliance Library based on open, iterative, collaborative principles, the federal government technology community will go further, faster.

When it comes to truly securing our federal IT systems, we need this now more than ever.