Using a continuous ATO for better compliance and real-time data

While this may be accurate, we believe there’s a solution that could ease these difficulties, save a significant amount of time for the teams involved, and still maintain system security.

The answer is to enable a continuous ATO, using the National Institute of Standards and Technology’s (NIST) Open Source Control Assessment Language (OSCAL). This format provides machine-readable representations of security controls, processes, and assessment plans, which provide an up-to-date response reflecting the current state of the system.

But before we discuss the benefits of a continuous ATO and how it would work, let’s review why the current process can be such a heavy burden.

Existing challenges of an ATO

Preparing for and manually submitting an ATO for the first time is incredibly intensive. It requires writing multiple lengthy documents and responses to security controls that must meet the governing agency’s specific criteria. This authorization package includes validating software versions, ensuring security controls are in place, designing system security plans, validating contingency plans, and executing them. Then, organizations within the governing agency must review the authorization package to ensure that the documentation addresses any additional key concerns.

If the program is going through an ATO renewal, however, the support team must perform these tasks while also maintaining their current workload. For an authorizing agency to renew an ATO, the project team must update all of the critical control documentation, put a plan in place for addressing any security findings, and submit it to the authorizing agency.

Ensuring compliance for a successful – and timely – review

One of the key components that the ATO process examines is how programs incorporate the 6 steps of the Risk Management Framework. This helps teams ensure they’re addressing all the appropriate steps that enable information systems to maintain a better risk management profile. One of the core reasons for wanting to strive for a more mature risk management profile is that it can help with the ATO process by demonstrating to the Authorizing Official (AO) that your program has a firm foundation in how you approach risk.

However, if the program is out of compliance within one of the key controls, it can slow down the process – potentially by weeks – thereby endangering a timely renewal. The AO will return the authorization package for review, and the team will have to redo the ATO application by addressing the concerns that the AO found in the system.

Additionally, if the team was not proactive in their submission timeline, their ATO package might be returned close to the renewal deadline, raising the risk of their system falling out of compliance. This type of situation can have serious ramifications for a program, even causing an important system to fall out of authorization.

If the team is going through an initial authorization, a manual review can take even more time – potentially 3 to 6 months. This doesn’t include the time required for the package to pass the Technical Review Board. To ensure that programs meet their launch date, sometimes teams have to ensure that the adaptive capabilities testing (ACT) is performed prior to their planned launch. Even then, it can pose a risk to the program’s security posture if the ATO is kicked back.

Using OSCAL to automate the ATO process

With a continuous ATO, it’s easier for program teams to deal with these challenges. This process helps them maintain a high standard of development and operations without having to worry about spending so many hours on the upkeep of security controls and documentation every 1 to 3 years. But how exactly would this work? The answer is simple: automation.

This means having a methodology for analyzing the controls, which is accomplished by establishing an OSCAL control catalog. This machine-readable representation of the controls implemented within a GitHub repository includes contextualized documentation and metadata regarding the use-case of the controls themselves. OSCAL even provides an example of what the process would look like in a basic control catalog.

How does this help? By adopting an OSCAL process, companies and organizations can pull up-to-date information directly from the technical infrastructure as a YAML, JSON, or XML file with real-time data about the system. And that is what Ad Hoc has been doing for the past few years on select programs.

The ease of having these tools on hand allows any auditor or AO to validate the system’s current state without having to request the team put aside current development work and lose sprints of development work to update documentation and security controls to meet the requirements.

Using OSCAL also assists with identification and ownership of system components that have shared ownership. For example, a program using a cloud provider would be able to use OSCAL to check the security posture of the components and relay the security status to system stakeholders.

This ongoing review and reporting of each component’s security status also enables a program to maintain a more vigilant overall security posture. In effect, a continuously updating information system allows us to dismiss the notion of a static security posture, providing instead a more holistic view of compliance in an agile world.

ATOs aren’t fun. But it doesn’t mean they also have to be time consuming for the teams involved. Much of the work that goes into the process is repetitive – exactly the kinds of tasks that computers excel at. By bringing automation to the compliance process the same way we’ve been bringing it to deployment and infrastructure, we can alleviate one of the most tedious requirements for creating a safe and effective digital service.