Introduction 

The authorization to operate (ATO) process is easily one of the most burdensome and time-consuming security processes in government. The acronym evokes the same emotions at every federal agency: fatigue, frustration, and the inescapable feeling that there must be a better way.  

 

Everyone involved in the process understands the need to reduce the number of hours worked and hoops jumped to deliver an ATO. Much of the time it takes to put together an ATO is spent combing through reams of documentation, often revisiting the same compliance records over and over for different systems simply because of a common component—cybersecurity déjà vu. 

 

At CMS, this lengthy process is much the same. As soon as a team begins configuring a project for security, they must develop an understanding of compliance requirements. Each project team must compile extensive documentation on how safeguards will be applied to achieve compliance for the technologies they plan to implement. This usually involves researching existing compliance requirements, policy, and documentation.

  

The ATO process is highly prone to becoming a silo since every new system requires its own new authorization and teams are unable to access authorization information from other teams without explicit permission. Anyone can see that this is a recipe for effort duplication. 

 

The silo effect can become so severe that valuable time is spent on authorizing a technology which was already granted ATO elsewhere within CMS, with shared services being the most common culprit. Teams often lack awareness of work already done, but it isn’t the team’s fault—it's the process.

 

Seeking ATO is not just lengthy, but opaque by design. In fact, the only person who can have full visibility over all ATO compliance documentation is the Cyber Risk Adviser (CRA). 

 

Walls into Windows: A Case Study 

It couldn’t wait. They knew their project was vitally important to the enterprise, and there was no way they could afford to wait three to nine months before going live.

 

Everyone knew that each system needed an initial ATO before receiving clearance for launch, but the very prospect of waiting an entire quarter or more was fast becoming a risk to the business. They weighed their options and their Information System Security Officer (ISSO), Jimil Perkins, agreed to go for the longshot: approach their Cyber Risk Advisor (CRA) for a special arrangement to expedite their ATO.

 

As their CRA, Gus Borjas understood the urgency. But there is no fast track, shortcut, or workaround with a traditional ATO. Rather than treating the authorization like a brand-new system, Gus sought similarities with components of other systems across CMS which already had ATO.

 

Once the team listed their project’s technical stack, Gus had his search parameters. He used his access as a CRA to manually search for compliance similarities within the CMS Federal Information Security Management Act Controls Tracking System (CFACTS).  

 

Through CFACTS, Gus went through over 100,000 pages of documentation manually to identify various compliance examples. He extracted information from approximately 250 different system security plans and worked with the team to compile their new system’s security plan to get their ATO—a herculean slog. 

 

Having knowledge of exactly which component technologies required authorization certainly accelerated the work, but it was still an overwhelmingly manual process requiring significant labor hours. Yet Gus and the team successfully reduced the time to ATO from over three months to just one.  

 

With a dramatic two-thirds time-to-authorization reduction under their belts, Gus and the team realized their project might very well be a CMS use case for speeding up the infamously lengthy ATO system. That inescapable feeling that there must be a better way was finally becoming tangible. 

 

Despite their success, increasing visibility into compliance documentation was an extremely time-consuming effort. Though the team only spent one month on their ATO, the manual work of hunting down similar documentation, even with clear parameters identified, demanded a great deal of searching, verifying, and editing.  

 

There was simply no way CRAs could sustainably repeat such a process for the over 250 systems they guide each year. By design, the system security structure only allows CRAs to have total visibility. The process was only sped up because Gus had the ability to select a list in CFACTS and look at all compliance examples, not just those of one team.  

 

In order to rapidly deliver ATO again, the process could not rely solely on CRAs. With no way to onboard more human resources, there needed to be a secure, systematic way to turn those walls into windows. 

 

Enter RapidATO 

The success of the one-month ATO gave rise to a desire for identifying opportunities to achieve more rapid ATOs. This new process provided the foundation for a new way of understanding security documentation for authorization: reusable open compliance.

  

While a straightforward solution may have been to simply knock down the walls and give everyone visibility across all CMS compliance records, the security risk of such a change could outweigh the benefits. In the worst case, it could allow a bad actor to access the entire CMS compliance record for every system from a single compromised non-CRA entry point. The best solution was to create a faster way to reuse compliance data by providing blueprints for a new system’s ATO based on similarities with active compliant systems. 

 

The initiative designed to create these blueprints, RapidATO, operates by identifying data elements from authorized systems that are similar to elements of the system seeking ATO to form a compliance patchwork based on past successes. These foundational elements, called vetted components, allow users to work toward their ATO based on precedence. Although using modular ATO templates would be a surefire way of reducing documentation burden and effort duplication, identifying and vetting these components was still a highly manual process. 

 

A Better Way with AI 

The repetitive, labor-intensive work of scanning and interpreting existing data was an excellent candidate for applying an artificial intelligence solution. Tying up CRAs to manually identify components represented an immense opportunity cost given their broader suite of responsibilities.

  

“Many systems at CMS have common technology stacks, but developer teams are unaware of each other and end up having to figure out security compliance in the dark,” explains Andrés Colón, the Senior Technical Advisor for RapidATO, “The manual work of identifying reusable compliance descriptions across all systems would have been far too cumbersome for a team of humans to complete and maintain, especially as new documentation is created. This is where Artificial Intelligence and Data Science comes in.”

  

AI would automate the identification of reusable compliance so CRAs and other SMEs wouldn’t have to spend valuable time doing it themselves. It would provide SMEs candidate components so they can craft them into their final form and contribute a component library that RapidATO provides to ISSOs and developers so they can accelerate their security planning and implementation. Overall, AI reduces burden and helps CMS perform compliance tasks with high speed and accuracy that was hitherto unheard of.

 

The AI pipeline was created to automate the processing of raw data containing the security documentation of all systems in the agency to identify common technology and compliance statements to be shared across over 250 systems. The machine learning (ML) algorithms leverage natural language processing (NLP) to analyze security documentation as a human would, identifying topics, similarities and standardized component candidates based on prior successes.

 

The algorithms accurately perform documentation analysis based on two key elements of the program which interact with one another: an exploratory engine and a confirmatory engine. 

 

The exploratory engine is designed to work unsupervised, identifying topics, similarities and common control compliance descriptions based on processing data including all System Security Plans. Running the similarity query teaches the AI the qualities of a good candidate component. The AI then applies this information to its future decision-making and provides SMEs important information so that they can perform the final step of crafting a candidate component into a reusable component. 

 

The confirmatory engine leverages supervised learning models to recognize familiar sets of controls and identify candidate components. Unlike the exploratory engine, which only requires validation from SMEs, the supervised learning model is trained directly by an SME who reads and annotates security plans for the machine and provides it examples.

  

This model learns to process text based on continuous human input, iteratively learning how to find potential vetted components based on qualities identified by the SME. In doing so, it automates the type of work Gus had to do for the first one-month ATO, where the brunt of the labor was poring through the security documentation of multiple systems to find similarities. 

 

 

Data scientists and SMEs use the output of these engines to learn which components are good candidates and if they should be further refined. Enabling the confirmatory engine to identify commonalities automatically reduces human labor hours and lays the foundation for the creation of an agency-wide reusable compliance library that is accessible to all development teams across the agency.