Supporting the continuous compliance and safety of FISMA systems through proactive, ongoing monitoring activities
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.
| Traditional ATO | Ongoing Authorization (OA) |
|---|---|
|
|
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:
- Valid ATO which is not expiring in the next 6 months
- A security & privacy assessment (CSRAP/SCA and PenTest) within the past 12 months
- System/Business Owner and ISSO participated in the ISPG-provided Threat Modeling session (your CRA can help set this up for your team)
- System must be fully OIT AWS cloud hosted – no hybrids
- Security Hub (SecHub) must be enabled
- Key Continuous Diagnostics and Mitigation (CDM) data feeds must be integrated into CDM architecture (HWAM, VUL)
- Data integration into requisite reporting mechanisms and visibility in corresponding dashboards, reports, etc. verified
- System ISSO with a valid CMS certification letter
- System must meet metrics baseline requirement
- 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).
Learn how to access and use the Ongoing Authorization Program Dashboard. (CMS internal link)
OA Program onboarding process
If your system qualifies for the OA Program, you will complete the following process to onboard:
The criteria above determines if your system is eligible for OA. The OA Team works to identify systems that meet the requirements for OA. As a System/Business Owner, you may receive proactive outreach from the OA Team if your system qualifies. System/Business Owners can also look at their specific system and reach out to the OA Team to request OA Program onboarding.
CMS information systems that have met the OA requirements will receive an OA onboarding invitation email. This email has instructions to get your system started with OA. Your tasks will include: letting the OA Team know you are interested in joining the program, obtaining the appropriate job codes, and working with your ISSO to stay in communication with the OA Team throughout the process.
The candidate email will include a welcome package for review by the System/Business Owner and ISSO that includes:
- Details on how to maintain OA status
- The process for non-compliance
- An OA Onboarding Memo
These artifacts must be reviewed by the System/Business Owner and the ISSO prior to joining OA. While reviewing these artifacts, the ISSO will ensure that all information in CFACTS is correct to date.
The ISSO will submit the signed memo into the ATO Request workflow in CMS Connect. The letter must be added as an attachment, and the certification form checkbox must be selected, as the memo takes its place. The CRA will change the OA Status field to OA Onboarding for that system in CFACTS. The System/Business Owner and ISSO must also participate in an ISPG-led Threat Modeling session during onboarding.
The CRA confirms the system is ready for onboarding and routes the OA Onboarding Memo to Authorizing Official (AO) for signature. The AO will return the signed letter to the CRA.
The CRA uploads the signed OA letter to CFACTS and notifies the System/Business Owner that the system has been placed into OA. The CRA changes the system OA Status in CFACTS to OA Member. It is now the responsibility of the System/Business Owner and the ISSO to maintain compliance.
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
CSRAP is one of the fundamentals of the OA Program. Find out more about this service and schedule your test.
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.