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.

Last Penetration Test (PenTest)

Description

Ensures that a PenTest has been performed based on the system's risk. This is done as part of the Cybersecurity and Risk Assessment Program (CSRAP) process. Per ARS 5.0, this is a requirement for HVA, FIPS High, and systems with PII/PHI.

Scope/Criteria

Measured in days. If the measuring scale goes beyond 1 year, an adjustment would need to be made.

Calculation

Last PenTest date:
*Risk Level 3: <= 365 days
*Risk Level 2: <= 365 days
*Risk Level 1: < = N/A

System risk level 1 (FIPS Low): N/A

System risk level 2 (System is financial or contains PII): Moderate

System risk level 3 (System is HVA or MEF or FIPS High): Moderate

Last Cybersecurity and Risk Assessment Program (CSRAP)

Description

Ensures that an CSRAP has been performed and provides coverage for controls that are not yet automated and integrated into the OA Program.

Scope/Criteria

Measured in days.

Calculation

Last CSRAP date:
*Risk Level 3: <= 365 days
*Risk Level 2: <= 365 days
*Risk Level 1: < = 365 days

System risk level 1 (FIPS Low): Low

System risk level 2 (System is financial or contains PII): Moderate

System risk level 3 (System is HVA or MEF or FIPS High): High

Vulnerability Risk Tolerance

Description

Provides the average AWARE score for all systems components

Scope/Criteria

AWARE Score current vs. previous 30 days

Calculation

Calculated for each Vulnerability: CVSS Score * Age * System Risk Category * 2 (If Exploitability flag = "Yes")

System calculation is the average score for all vulnerabilities identified for the system (High & Critical for MVP)

System risk level 1 (FIPS Low): Moderate

System risk level 2 (System is financial or contains PII): High

System risk level 3 (System is HVA or MEF or FIPS High): High

Resiliency Score

Description

Provides an overall risk score for an IS and/or Component

Scope/Criteria

All POA&M within the FISMA boundary

Calculation

Aggregate risk score attributed by Open POA&Ms based upon criticality (L = 10, M = 15, H = 30, C = 45)

System risk level 1 (FIPS Low): Moderate

System risk level 2 (System is financial or contains PII): Moderate

System risk level 3 (System is HVA or MEF or FIPS High): High

Residual Risk

Description

Understanding the number of accepted risks in correlation with active risks/vulnerabilities on the system

Scope/Criteria

All risks associated with the information system boundary

Calculation

Target: (thresholds scale)

Calculation: Total # of risk acceptances that are valid

System risk level 1 (FIPS Low): Informational

System risk level 2 (System is financial or contains PII): Informational

System risk level 3 (System is HVA or MEF or FIPS High): Informational

Asset Risk Tolerance

Description

Represents the confidence that the reporting is accurate based on past reported asset data per system

Scope/Criteria

All assets within the FISMA Boundary

Ref: Unaccounted change of +/-40% over the last 30 days flags a value as unreliable (prior month’s inventory – current month’s inventory)/prior month’s inventory >40% or < -40%

Calculation

Target = + or - 40%

Weight = N/A

Calculation: Unaccounted change of +/-40% over the last 30

System risk level 1 (FIPS Low): Low

System risk level 2 (System is financial or contains PII): Low

System risk level 3 (System is HVA or MEF or FIPS High): Moderate

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:

Risk tolerance level

Exceeds the prescribed CMS risk tolerance level for the corresponding system risk threshold tier based on FIPS 199 categorization, High Value Asset (HVA) identification, and other factors.

Delayed remediation

Has delayed remediation of critical and/or high-impact vulnerabilities

POA&M non-compliance

Is non-compliant with CMS Plan of Action & Milestones (POA&M) resolution timelines policies:

• Critical: 15 days
• High: 30 days
• Moderate: 90 days
• Low: 365 days

Lack of continuous monitoring

The system is unable to execute continuous monitoring processes and tasks, such as:

• System has not been scanned in accordance with CMS minimum requirements
• System has not been patched in accordance with CMS minimum requirements
• System is non-compliant with required monitoring/assessment frequencies within two assessment frequency cycles

The System/Business Owner and ISSO will be notified of non-compliance via email. A 30-day grace period will be given to remediate the issue. After the 30 calendar day grace period has lapsed, systems that fail to meet metrics will be terminated from the OA Program.

Systems that are terminated from the OA Program because of non-compliance will be issued a one-year traditional ATO, and will be provided with a list of the actions required to fully rejoin the OA Program. Required actions will include a comprehensive CSRAP and Penetration Test. Other actions may be identified based on specific circumstances.

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.