Foundations for moving to Continuous Authority to Operate (C-ATO)

Any information system built or deployed to support the federal government must comply with established Federal Information Security Modernization Act (FISMA) standards, including National Institute for Standards and Technology (NIST) Risk Management Framework (RMF) specifications. Organizations traditionally accomplish this through agency-specific Authority to Operate (ATO) processes, which require heavy scrutiny from authorizing officials (AOs).

While ingrained in every agency, the ATO process is often maligned as cumbersome, time-consuming, costly, compliance-focused, and incomplete—stopping short of pinpointing threats. With the increased adoption of DevSecOps and Agile across the federal landscape, organizations are now considering how a Continuous ATO (C-ATO) process could improve their security posture.

Moving to a C-ATO strategy requires a cultural shift as well as a technical one. To adopt C-ATO, agencies will need to change from a mindset of documentation to one of automation and increased visibility. For many, the desire to move beyond today’s manual, paper-based, point-in-time approach is tempered by concerns—what is the most effective path to get there?

Laying the foundation

We offer the following as foundation elements for organizations to consider in terms of C-ATO readiness.

1. Prepare for the cultural change. The move to a C-ATO paradigm shifts the way that your security compliance program fundamentally operates. The traditional model is well entrenched, and a move to a C-ATO model introduces new levels of visibility to the compliance program. As the organization shifts from periodic review and Plan of Action and Milestones (POA&M) remediation to proactive continuous assessment and swift action to protect the enterprise, it enhances its security posture.

With the move to C-ATO, roles and responsibilities related to the process also change, including system owners, control assessors, control owners, developers, security engineers and contractors.

This level of organizational change does not happen overnight or without careful consideration of impact on personnel and their day-to-day functions. Engage with experts in organizational change management early to avoid pitfalls and set your organizational change up for success.

2. Clean up policies, eliminate exceptions. Across the organization, leaders must gain greater visibility into their assets so that they can incorporate security baselines into their policies. Asset inventories – a key capability offered through the Department of Homeland Security’s Continuous Diagnostics and Monitoring (CDM) program – supports this objective.

Even when agencies know what and where their assets are, they do not always firmly establish policies, creating a need for exception processes. Agencies should update policies to reflect current operational activities; then you can automate compliance.

3. Keep pace and simplify your approach to controls. To the extent possible, agencies should replace agency-specific information assurance objectives and corresponding security control baselines with well-defined core baselines, such as FedRAMP, to minimize redundancy and support ease of automation.

As agencies move from the previous version of NIST’s Security and Privacy Controls for Information Systems and Organizations(NIST 800-53r4) to 800-53r5, we encourage an analysis of how to move to more automated controls reviews, using existing capabilities to reduce cost and effort.

Establish a roadmap for automation that supports security and compliance, with the goal being incremental adoption of a more proactive approach, replacing manual processes with automation to the greatest extent possible.

4. Get your DevSecOps house in order. With the adoption of Agile practices, agencies continue to mature their approaches to DevSecOps across the enterprise.

However, some organizations have adopted DevSecOps at the program or portfolio level but have not yet devised a strategy for DevSecOps at the enterprise level. As agencies increasingly look to hybrid cloud models to achieve mission objectives, leaders must continue to mature DevSecOps processes, including adopting new tools for security and compliance automation and performing security-related functions earlier in the development lifecycle.

The technology landscape in this area is changing quickly, propelling leaders to work with trusted contractors to understand the tool landscape (and tool roadmaps) in order to make informed investment decisions for use across multiple environments.

5. Get smart on OSCAL. With the new C-ATO paradigm, NIST and FedRAMP are looking to make Open Security Controls Assessment Language (OSCAL) the standard language for machine-readable expressions of control catalogs, control baselines, systems security plans and assessment plans and results. NIST’s involvement in developing OSCAL, alongside industry, means that OSCAL is likely to be adopted broadly within the federal landscape over the next few years. In fact, NIST 800-53r5 already includes an OSCAL version of the Control Catalog.

Of course, the foundational elements described above – including having a clean compliance program – are essential to moving to a machine-readable control model. Identify the resources who will be your go-tos on OSCAL and how you can adopt it in the future.

Charting the course

The shift to C-ATO involves technology, processes, and perhaps most critically people to achieve adoption. As your organization begins to develop its plan for moving to a C-ATO model, choose a trusted partner with expertise in ATO processes, continuous monitoring, and organizational challenge management to increase the likelihood of success.

Reach out to a CGI expert to explore the next steps in your C-ATO journey.