What is Ongoing Authorization (OA)?

All FISMA systems must be proven secure before they are allowed to operate. This authorization process has traditionally focused on a compliance-based model. In an effort to modernize the way that the government manages its systems, the National Institute of Standards and Technology (NIST) released guidance that requires all agencies to adopt an “ongoing state of security” and conduct “ongoing authorizations”. CMS is adopting new processes, services, and tools to support the ongoing authorization model. These resources are designed to continuously monitor systems to address real-time threats. With ongoing authorization, system controls are constantly evaluated and tested to spot vulnerabilities. This allows you to make risk-based decisions quickly and confidently and engage in remediation efforts to minimize ongoing exposures.

Ongoing Authorization (OA) vs. traditional ATO 

The traditional ATO process has been used by the CMS community for decades. The OA process offers exciting new benefits for CMS FISMA systems.  

Is my system eligible for OA?

CMS information systems must meet the following requirements before being considered for onboarding into the OA Program. These prerequisites are part of the pre-assessment conducted by the OA Team and determine the eligibility of the system to receive an OA: 

1. Valid ATO which is not expiring in the next 6 months
2. A security & privacy assessment (CSRAP/SCA and PenTest) within the past 12 months
3. System/Business Owner and ISSO participated in the ISPG-provided Threat Modeling session (your CRA can help set this up for your team)
4. System must be fully OIT AWS cloud hosted – no hybrids
5. Security Hub (SecHub) must be enabled
6. Key Continuous Diagnostics and Mitigation (CDM) data feeds must be integrated into CDM architecture (HWAM, VUL)
7. Data integration into requisite reporting mechanisms and visibility in corresponding dashboards, reports, etc. verified
8. System ISSO with a valid CMS certification letter
9. System must meet metrics baseline requirement
10. No planned decommission of the system

The Ongoing Authorization Program Dashboard helps ISSOs and other security professionals to quickly identify what parts of their system meet the requirements for OA, and what steps they need to take (either to achieve or maintain OA).

OA Program onboarding process

If your system qualifies for the OA Program, you will complete the following process to onboard:

Maintaining your system’s OA

After a system has been onboarded to the OA Program, the system enters Continuous Monitoring status. During this phase, continuous assessment activities are conducted to ensure that the system is operating within the agreed-upon risk thresholds outlined in the OA Program welcome package . The following CMS programs and tools will be used to monitor the system:

• CMS CDM Program
• CMS Cybersecurity Integration Center (CCIC) monitoring
• Cyber Risk Reporting
• Ad hoc risk reviews

The OA Program also publishes the OA Cyber Risk Report, which includes security results from all risk information sources including: 

• Assessment of inherited controls
• Development environment testing
• CDM
• CCIC
• Cybersecurity and Risk Assessment Program (CSRAP) 
• Other assessment activities as required

Continuous monitoring result: triggers

Triggers directly monitor a system's security posture and can indicate risks beyond acceptable limits. During the continuous monitoring process, the OA Team manages both time-driven and event-driven triggers. 

Time-driven triggers are based on CMS’s predefined frequency by the OA Team, senior CMS leadership, and system security stakeholders. 

Event-driven triggers are based on a specific internal or external event of significance to the system.

Each trigger requires a unique response. Example responses to triggers include: 

OA Cyber Risk Report Trigger

If the OA Cyber Risk Report shows risk that is out of compliance with the documented risk tolerance, the OA Team will conduct a risk review to determine the severity and mitigation needed.

Incident or Cyber Threat Intelligence Trigger

An incident or relevant cyber threat intelligence may also trigger an OA Team risk review to determine the severity and mitigation needed.

Significant System Change

A significant change to a system should be reviewed by the CRA to determine if the security requirements of the system will need to change.

Triggers may come from any number of internal or external sources and may vary in degree of severity, requiring unique response times. The System/Business Owner and ISSO should independently review the OA Program Dashboard weekly to confirm system status.  

If the trigger identifies remediation activities, those activities will be tracked to completion by the OA Team, including any need for re-authorization or renewal of the OA. Items of non-compliance are identified and entered on the trigger log (with severity assigned). Non-compliant fields will turn red on the OA Program Dashboard. The System/Business Owner, ISSO, and CRA must work together to resolve these triggers with mitigations or other actions. 

Systems will be considered non-compliant with OA Program requirements if they fail to meet 1 out of 5 metrics (i.e. 20%). The ISSO  coordinates remedial actions based on trigger severity. Items of non-compliance below the defined threshold are identified and entered on the Trigger Accountability Log (TRAL) by the CRA. The CRA then notifies the System/Business Owner and  ISSO of non-compliance via email.

Trigger severity guide 

The following guide helps System/Business Owners and ISSOs determine the severity of a trigger experienced by their system, and offers the timeline for remediation. 

OA Program non-compliance process 

If a system fails to meet 1 out of 5 of the OA Program metrics, the System/Business Owner and ISSO will be notified via email and given a grace period of 30 calendar days to get the system back into compliance (i.e. green on all metrics). If the deficiencies have been fully addressed, the system may remain in the OA Program. 

If the deficiencies are not fully addressed during the 30-day probation period, the system team will be required to present their progress in correcting deficiencies to the Chief Information Security Officer (CISO) and AO for their review and consideration for continued participation.

A system will be considered non-compliant based on the following criteria:

Re-entry into the OA Program

It is possible for a terminated system to re-enter the OA Program. The System/Business Owner may request re-entry when the system has successfully met the required actions set in the one year traditional ATO. The CRA will evaluate the completion of the required actions.

This may occur at or before the one year time period is up. However, the system’s metrics must have remained green for at least 6 months prior to rejoining. 

Rejoining will require the re-issuance of the OA letter for the system.

Frequently Asked Questions:

How do I access the OA Dashboard?    

First, ensure that you have the TABLEAU_DIR_VIEWER_PRD job code on your EUA profile. We have already added this code for known CMS ISSOs and System/Business Owners, but contractors will likely not have it.  Request the job code through EUA if you do not have it.     

Next, follow the instructions from the OA Program Dashboard - Quick Start Guide. (Note that Step 2 of the Quick Start Guide references the “Projects page”. The correct link on the navigation on the left side of the page is “Explore”. The Explore page then lists available projects.)

Is there a status report of the Security Hub integration for each system?

Yes, the SecOps group tracks this. ISPG also reflects this information through mediums like CFACTS. For more information, please see CFACTS or ask your Cyber Risk Advisor (CRA).

How is system data collected and disseminated for OA?

The automation of data collection is from the Continuous Diagnostics and Monitoring (CDM) program. Since we are starting in the OIT AWS Cloud, we have all aspects of the CDM data. We are still working on how that data is normalized and aggregated down to our data warehouse to support the reports through our reporting platform. The use of Security Hub is one way we are disseminating data, and we are also working on an OA concept report we are developing alongside users and internal SMEs. The Ongoing Authorization Program Status Dashboard is populated using available CDM data feeds regardless of the system’s OA status or participation in the OA program. Our aim is to make data dissemination for OA usable for everybody.

Will OA be inclusive of hybrid PaaS/SaaS systems such as Salesforce?

Platform as a Service (PaaS) and Software as a Service (SaaS) systems will not be considered for OA at this time.

|OIT Specific| How will non-critical findings from Security Hub be communicated?

Non-critical findings will be communicated directly through Security Hub. There will not be any Jira tickets created for non-critical findings (which includes some of the Highs and certainly the Moderates and Lows). 

How will the new automated CDM approach support the same level of useful metadata that the former manual HW/SW inventory previously provided?

The information will still be just as understandable, and delivered daily. The expanded reporting will be helpful in giving you a fuller picture. You can expect a more robust set of metadata for your use.