Introduction

The Centers for Medicare & Medicaid Services (CMS) Risk Management Handbook (RMH) Chapter 14: Risk Assessment provides the procedures for implementing the requirements of the CMS Information Systems Security and Privacy Policy (IS2P2) and the CMS Acceptable Risk Safeguards (ARS). This document describes procedures that facilitate the implementation of security controls associated with the Risk Assessment (RA) family of controls. To promote consistency among all RMH Chapters, CMS intends for Chapter 14. 

Risk Assessment controls

Security Categorization (RA-2)

Security categories describe the potential adverse impacts to organizational operations, organizational assets, and individuals if organizational information and information systems are compromised through a loss of confidentiality, integrity, and/or availability. Organizations conduct the security categorization process as an organization-wide activity with the involvement of chief information officers, senior information security officers, information system owners, mission/business owners, and information owners/stewards. Security categories are used in conjunction with vulnerability and threat information in assessing the risk to an organization. The security category of an information type can be associated with both user information and system information. Establishing an appropriate security category of an information type requires determining the potential impact level for each security objectives of confidentiality, integrity, and availability (CIA) associated with the particular information type.

At CMS, each new system must define its security categorization within the CMS FISMA Controls Tracking System (CFACTS). Before the System Security and Privacy Plan (SSPP) can be developed, the information system and the information resident within that system must be categorized based on the Federal Information Processing Standards Publication 199 (FIPS 199). NIST Special Publication 800-60 Volume I: Guide for Mapping Types of Information and Information Systems to Security Categories provides a guideline for mapping types of information and information systems to security categories and works in conjunction with FIPS 199.

The SSPP provides the detailed descriptions of all the implemented controls by the CMS ARS categories to minimize risks. Authorization boundaries are also developed and reviewed in correlation with the security categorization as the boundary has a direct effect on the categorization of the system. CMS has synthesized and identified the information types that apply to CMS into 11 information types:

Table 1: CMS Information Types

The security categorization for an information system is completed by the Information System Security Officer and approved by the Information System Owner. All CMS information systems categorized as High or Moderate are considered sensitive or contain sensitive information. All CMS information systems categorized as Low are considered non-sensitive or contain non- sensitive information. Organizations implement the minimum security requirements and controls as established in the current CMS Information Security ARS Standard, based on the system security categorization. When identifying information types and assigning appropriate security categorizations for CMS systems, it is essential that the Data Guardian, Information System Owner, Business Owner, Information System Security Officer, and Cyber Risk Advisor coordinate their efforts.

The following steps detail the CMS specific process for conducting a security categorization on an information system using CFACTS:

• Step 1: Login to CFACTS and select the “Assessment & Authorization (A&A)” dropdown tab from the top menu.
• Step 2: Click on the “Authorization Package - Records” under the “Quick Links” section.
• Step 3: Select the appropriate information system. You may also find the information system by clicking on the search icon in the top right of the page and specifying search criteria.
• Step 4: Once the information system has been located, click on the system name to open the authorization package for the system.
• Step 5: Select the “Security Category” tab from the top navigation tab of the authorization package.
• Step 6: Click “Edit” at the top of the authorization package window.
• Step 7: Answer the following question in the Organizational Users Section: “Is this system accessed by non-organizational users?”
• Step 8: Select the information types processed, stored or transmitted by the system.
  • For help determining who is considered an organizational user and a non- organizational user, see the help text by clicking on the question mark to the left of the question.
  • In the Information Type section, click on the right hand side of the “Lookup” title bar in the upper right hand corner.
  • In the “Record Lookup” pop up, select the checkbox to the left of each information type that is used by your information system.
  • Click “Ok” when done.
• Step 9: Answer the following question in the Personally Identifiable Information (PII) section: “Does this FISMA system collect, maintain, use or share Personally Identifiable Information (PII)?”
• Step 10: Answer the following question in the Protected Health Information (PHI) section: “Is the data maintained in this FISMA system considered electronic Protected Health Information (PHI)?”
• Step 11: Click “Save” at the top of the screen to save all changes.

The SOP ultimately reviews and approves the categorization of information systems that process, store, or transmit PII.

Risk Assessment (RA-3)

Risk assessment is the process of identifying risks, both business and technical, to organizational operations’ mission, functions, image, and reputation, including individuals, organizational assets, other organizations, and the Nation, resulting from the operation of an information system. As part of risk management, risk assessment incorporates threat and vulnerability analyses and considers mitigations provided by security and privacy controls planned or in place.

This publication focuses on the risk assessment component of risk management—providing a step-by-step process for organizations on: (i) how to prepare for risk assessments; (ii) how to conduct risk assessments; (iii) how to communicate risk assessment results to key organizational personnel; and (iv) how to maintain the risk assessments over time. Risk assessments are not simply one-time activities that provide permanent and definitive information for decision makers to guide and inform responses to information security and privacy risks. Rather, organizations employ risk assessments on an ongoing basis throughout the system development life cycle and across all of the tiers in the risk management hierarchy—with the frequency of the risk assessments and the resources applied during the assessments, commensurate with the expressly defined purpose and scope of the assessments.

Basic Risk Management

Risk assessment is a key component of a holistic, organization-wide risk management process as defined in NIST Special Publication 800-39, Managing Information Security Risk: Organization, Mission, and Information System View. Risk management processes include: (i) framing risk; (ii) assessing risk; (iii) responding to risk; and (iv) monitoring risk. Figure 2 illustrates the four steps in the risk management process—including the risk assessment step and the information and communications flows necessary to make the process work effectively.

As laid out by NIST in 800-30, the first component of risk management addresses how organizations frame risk or establish a risk context—that is, describing the environment in which risk-based decisions are made. The purpose of the risk framing component is to produce a risk management strategy that addresses how organizations intend to assess risk, respond to risk, and monitor risk—making explicit and transparent the risk perceptions that organizations routinely use in making both investment and operational decisions. The risk management strategy establishes a foundation for managing risk and delineates the boundaries for risk-based decisions within organizations.

The second component of risk management addresses how organizations assess risk within the context of the organizational risk frame. The purpose of the risk assessment component is to identify: (i) threats to organizations (i.e., operations, assets, or individuals) or threats directed through organizations against other organizations or the Nation; (ii) vulnerabilities internal and external to organizations; (iii) the harm (i.e., adverse impact) that may occur given the potential for threats exploiting vulnerabilities; and (iv) the likelihood that harm will occur. The end result is a determination of risk (i.e., typically a function of the degree of harm, i.e., impact to the organization, and likelihood of harm occurring).

The third component of risk management addresses how organizations respond to risk once that risk is determined based on the results of a risk assessment. The purpose of the risk response component is to provide a consistent, organization-wide response to risk, or “risk mitigation plan”, in accordance with the organizational risk frame by: (i) developing alternative courses of action for responding to risk; (ii) evaluating the alternative courses of action; (iii) determining appropriate courses of action consistent with organizational risk tolerance; and (iv) implementing risk responses based on selected courses of action.

The fourth component of risk management addresses how organizations monitor risk over time. The purpose of the risk monitoring component is to: (i) determine the ongoing effectiveness of risk responses (consistent with the organizational risk frame); (ii) identify risk-impacting changes to organizational information systems and the environments in which the systems operate; and (iii) verify that planned risk responses are implemented and information security and privacy requirements derived from and traceable to organizational missions/business functions, federal legislation, directives, regulations, policies, standards, and guidelines are satisfied.

Effective information security and privacy-related risk management is a holistic activity and requires integration of risk input from the information system level (Tier 3) through the organization’s business processes (Tier 2) and up through the governance of the enterprise (Tier 1). Risk management among the top and bottom tier are bi-directional as the highest tier directs the lower tiers through policy and processes, and the lower tier feeds tactical risk back up the enterprise. The RMF primarily operates at Tier 3 but does involve interactions in the other two tiers through feedback from ongoing authorization decisions, dissemination of updated threat and risk information to authorizing officials and information system owners.

Risk Models

Risk models define the risk factors to be assessed and the relationships among those factors. Risk factors are characteristics used in risk models as inputs to determining levels of risk in risk assessments. Risk factors are also used extensively in risk communications to highlight what strongly affects the levels of risk in particular situations, circumstances, or contexts. Typical risk factors include threat, vulnerability, impact, likelihood, and predisposing condition. Risk factors can be decomposed into more detailed characteristics (e.g., threats decomposed into threat sources and threat events). These definitions are important for organizations to document prior to conducting risk assessments because the assessments rely upon well-defined attributes of threats, vulnerabilities, impact, and other risk factors to effectively determine risk.

As noted above, risk is a function of the likelihood of a threat event’s occurrence and potential adverse impact should the event occur. This definition accommodates many types of adverse impacts at all tiers in the risk management hierarchy described in NIST Special Publication 800- 3910 (e.g., damage to image or reputation of the organization or financial loss at Tier 1; inability to successfully execute a specific mission/business process at Tier 2; or the resources expended in responding to an information system incident at Tier 3). It also accommodates relationships among impacts (e.g., loss of current or future mission/business effectiveness due to the loss of data confidentiality; loss of confidence in critical information due to loss of data or system integrity; or unavailability or degradation of information or information systems). For purposes of risk communication, risk is generally grouped according to the types of adverse impacts and possibly the time frames in which those impacts are likely to be experienced.

High Value Assets

Per OMB Memorandum M-19-0311 Federal Agencies must extend their risk management approach to include High Value Assets (HVA). HVAs are assets, information systems, information, and data which unauthorized use could cause a significant impact to the United States’ national security interests. HVA risk assessments require the agency to incorporate enterprise- wide risk considerations to include operational, business, mission, and continuity. Agencies' assessment of risk should consider not only the risk that an HVA poses to the agency itself, but also the risk of interconnectivity and interdependencies leading to significant adverse impact on the functions, operations, and mission of other agencies. Agencies' assessment of risk to an HVA should be informed by an up-to-date awareness of threat intelligence regarding agencies' Federal information and information systems; the evolving behaviors and interests of malicious actors; and the likelihood that certain agencies and their HVAs are at risk owing to demonstrated adversary interest in agencies' actual, related, or similar assets.

CMS information systems are encouraged to implement the requirements mentioned in the HHS High Value Asset Program Policy , the controls from the Cybersecurity and Infrastructure Security Agency (CISA) High Value Assest Control Overlay and the CMS Acceptable Risk Safeguards (ARS) which specifies security control implementations that aim to make HVAs more resistant to attacks, limit the damage from attacks when they occur, and improve resiliency and survivability.

CMS must conduct independent third party or CISA led HVA assessments within the CISA defined frequency, methodology standards and assessment specific requirements. CISA has established Tier Designations 1, 2 and 3 which determines the above frequency, standard and requirement.

HVA Assessment Process

In accordance with FIPS 200, Minimum Security Requirements for Federal Information and Information Systems, NIST 800-37, Guide for Applying the Risk Management Framework to Federal Information Systems and the HHS IS2P, CMS are responsible for the ongoing assessment and authorization of all information systems classified as HVAs. In coordination with the Division of Security & Privacy Compliance (DSPC), assessments are conducted to ensure the accuracy of the information pertaining to the security posture of information systems, and the tailoring and implementation of security and privacy controls following the selection of the appropriate baseline mapped to the CMS IS2P2. CMS HVA assessements are required to include and be consistent with CISA HVA assessment requirements and expectations.

The Information System Security Officer (ISSO) is responsible for preparing their information system for upcoming assessments by

1. Participating in assessment activities as detailed in the assessment schedule
2. Request access to the CISA file repository for RVA artifacts requests (HSIN).
3. Remediating identified issues in a timely manner as stated in the HVA Assessment Report.

CISA-Led HVA Assessment Process

CMS, in co-ordination with the Office of Management and Budget (OMB), Cybersecurity and Infrastructure Security Agency (CISA) and Department of Health and Human Services (HHS), must perform certain actions to ensure effective identification and timely remediation of weaknesses based on HVA system assessments. All Tier 1 designated HVAs are to be assessed by CISA once every three (3) years. The below actions follow the Binding Operational Directive 18- 02 with CMS specific additions:

1. Submit to CISA a single Rules of Engagement (ROE) and complete an RVA intake form once the system has been identified for a CISA RVA.
   • For CMS: The applicable ROE is maintained between HHS and CISA and applies to all HVA assesments across the departments
2. For each HVA and related system(s) to be assessed, one ROE Appendix A titled “RVA Services for High Value Assets and Related Systems,” authorizing CISA to conduct a HVA Risk and Vulnerability Assessment (RVA) on the CMS HVA and related systems.
   • For CMS:
     • Appendix A specifies all of the IPs in scope for the assessment. Note that it will likely be necessary for the assessment to stop and the Appendix to be revised if IPs must be added during the assessment.
     • Appendix B will also be necessary if third party contractor os involved in the assessment
3. Fully participate in the HVA assessment activities authorized by the ROE.
4. Fully participate in a Security Assessment Report (SAR) after RVA completion.
   • For CMS: As of FY2021, CISA has revised the HVA assessment methodology to include both the security architecture (previously SAR) and technical assessment (previously RVA) during a single engagement.
5. CMS systems shall impose no restrictions on the timing and/or frequency of the assessments, the services to be provided by CISA, or the scope of the systems that are part of or related ot the HVA being assessed.
   • For CMS: The expected scope of the HVA assessment will be the full operational “footprint” of the HVA. The hosting site and supporting services should expect to be involved. Generally any systems that are providing inheritable controls to the HVA will be included in the assessment.

After completion of the assessment, the BO and ISSO must ensure timely remediation of identified vulnerabilities and report remediation plans and progress by following the below

1. Within 30 days of receipt of the HVA asessment reports identifying major or critical weakness to an assessed CISA, remediate all major critical weaknesses and provide notification to CISA that each identified weakness was addressed.
   • For CMS:
     • High, Major or Critical findings must be reported to CISA as remediated within 30 days. This is in addition to HHS requirements specified in the HHS HVA Policy and CMS POA&M requirements.
     • The 30 days timing is considered to be in relation to the final assessment report. Remediation efforts should be undertaken as soon as possible afterthe potential finding is identified to maximize the available remediation time.
2. If it is determined by the designated Senior Accountable Official for Risk Management (SAORM) that full remediation cannot be completed within the initial 30 day timeframe, develop and submit to CISA a remediation plan with remaining major or critical weaknesses within 30 days of the receipt of the RVA and/or SAR reports.

i. For CMS: The HHS SAORM is the HHS CIO, and must approve anything other than full remediation within the initial 30 days after the final report is issued, in addition to all CMS approvals.

1. This remediation plan shall include justification for the extended timeline, the proposed timeline and associated milestones to remediation (not to exceed one year), interim mitigation actions planned to address immediate vulnerabilities, and, if relevant, the identification of constraints related to policy, budget, workforce, and operations.This remediation plan must be signed by the designated SAORM prior to submission to CISA.
2. HHS reports the status of each remaining major or critical weakness to CISA every 30 days until full remediation is achieved. Status reports must address HVA assessment results through combined reporting and must be submitted every 30 days after the submission of the remediation plan described above.
3. HHS notifies CISA via monthly status reports of any modifications to remediate plan timelines and when full remediation has been achieved. The notifications for modifications and full remediation must be certified under signature of the designated SAORM.

CISA will manage the progress and report submissions associated with these actions. If deadlines outlined above are not being met, CISA will enage the CMS CISO.

Vulnerability Scanning (RA-5)

A vulnerability is a weakness that can be accidentally triggered or intentionally exploited, usually due to misconfigurations. Vulnerability scanning is a non-destructive form of testing that provides an organized approach to the testing, identification, analysis and reporting of potential security issues on a network. Vulnerability scanners can be run against a host either locally or from the network. Some network-based scanners have administrator-level credentials on individual hosts and can extract vulnerability information from hosts using those credentials. Other network-based scanners do not have such credentials and must rely on conducting scanning of networks to locate hosts and then scan those hosts for vulnerabilities. In such cases, network-based scanning is primarily used to perform network discovery and identify open ports and related vulnerabilities. Network-based scanning without host credentials can be performed both internally and externally—and although internal scanning usually uncovers more vulnerabilities than external scanning, testing from both viewpoints is important. External scanning must contend with perimeter security devices that block traffic, limiting assessors to scanning only the ports authorized to pass traffic.

For local vulnerability scanning, a scanner is installed on each host to be scanned. This is done primarily to identify host Operating Systems (OS) and application misconfigurations and vulnerabilities—both network-exploitable and locally exploitable. Local scanning is able to detect vulnerabilities with a higher level of detail than network-based scanning because local scanning usually requires both host (local) access and a root or administrative account. Some scanners also offer the capability of repairing local misconfigurations.

The foundation for effective vulnerability scanning includes having an asset inventory management process (e.g. automated tools and their processes) in place. Without a robust asset inventory management process in place there is an increased risk that the asset inventory is incomplete which may impact downstream processes to include vulnerability scanning and security configuration. This may lead to vulnerabilities and misconfigurations going unidentified and may result in exploitable conditions.

The results from a vulnerability scan can show the path an adversary can take once they have gained access to the network and how much data they could collect. Vulnerability scans can also support penetration testing (CA-8) by providing information on targets for the penetration testing team to look into. Some examples of scanning activities are:

1. scanning for patch levels;
2. scanning for functions, ports, protocols, and services that should not be accessible to users or devices; and
3. scanning for improperly configured or incorrectly operating information flow control mechanisms. Based on the information provided, the organization can then remediate vulnerabilities identified and work towards improving the security of the network.

For CMS, the security categorization of information systems guides the frequency and comprehensiveness of vulnerability scans. All data centers must have a vulnerability scanner in place before connecting to the CMS network, either through their own vendor-provided scanner or by establishing a connection with the Continuous Diagnostics and Mitigation (CDM) team at the CMS Cybersecurity Integration Center (CCIC). One of the services provided by the CCIC includes vulnerability scanning, with support in place for all scanning needed from infrastructure to endpoint. The CCIC supports risk analysis at CMS by ingesting scan logs and identifying risks through its Security Incident Event Management (SIEM) tool. In order to set up vulnerability scanning for new systems, please send an email to the CDM Manager using this email address: EVM-CMP@cms.hhs.gov.

If a datacenter chooses not to utilize the vulnerability scanning service provided by the CCIC then they are able to choose a vendor-provided one. There are requirements that must be met for those System Owners who decide not to use the CCIC. These requirements include the baseline configurations that must be scanned against, such as those found in Risk Management Handbook Chapter 5 Configuration Management (CM-6). Information for meeting these requirements are found in the CMS CCIC Integration Requirements document. For access to this document, please reach out to the CDM Manager by sending an email to: EVM-CMP@cms.hhs.gov.

When vulnerabilities are discovered they must be mitigated within a given timeframe. This timeframe varies depending on the criticality of the vulnerability:

• Critical vulnerabilities within 15 days from discovery
• High vulnerabilities within 30 days from discovery
• Moderate vulnerabilities within 90 days from discovery
• Low vulnerabilities within 365 days from discovery

If the identified vulnerabilities cannot be mitigated within the given time frame and exceed those thresholds then they must be documented in the designated POA&M as weaknesses and mitigated through timelines defined for the corresponding level of weakness.

The table below outlines the CMS ODPs for RA-5:

Table 2: CMS Defined Parameters – Control RA-5

Update Tool Capability (RA-5(1))

The purpose of this control is to ensure that CMS has the capability to update the scanning tools it uses for vulnerability scanning efforts. New vulnerabilities are a constant and it is essential to update the capability of the tools used as new vulnerabilities are discovered, announced, and published. Better scanning methods are therefore developed in response to the ever-changing threat landscape. As new updates and versions of the vulnerability scanning tools become available, they must be updated in order to ensure that the latest capabilities are deployed in scanning the CMS network. Vendor-provided tools will include a process to update as agreed between the vendor and datacenter.

Update Frequency/Prior to New Scan/When Identified (RA-5(2))

The purpose of this control is to ensure that CMS is updating the vulnerabilities it is scanning for on a regular basis through a defined frequency, prior to each new scan, and when identified. Readily updating the vulnerabilities that are scanned helps to ensure that potential vulnerabilities in the information system are identified and addressed as quickly as possible.

The table below outlines the CMS ODPs for updating the information system vulnerabilities:

Table 3: CMS Defined Parameters – Control RA-5(2)

System Owners whose systems are not covered by the CCIC must provide documentation to demonstrate their vendor-provided tools are updated no less often once every 72 hours, immediately prior to a new scan, and when new vulnerabilities are identified and reported.

 Discoverable Information (RA-5(4))

The purpose of this control is to ensure that CMS is determining the information that potential adversaries can discover in the event of malicious activities against the CMS network. In addition, this control requires that corrective actions are identified and then taken to eliminate the information discoverable to adversaries. In order to ensure that vulnerability scans are prompting appropriate corrective actions, organizations must be able to determine what information is discoverable by adversaries. For systems that are scanned by the CCIC, the CDM team utilizes a Security Intelligence Hub (SIH) that acts as a central repository of vulnerability information and holds such data specific to that scan for one (1) year. Included in this information are corrective actions that the ISSO can take to remedy the identified vulnerabilities in their systems. The ISSO may request access to this repository by sending an email to the CDM Manager at: EVM- CMP@cms.hhs.gov.

System Owners whose systems are not scanned by the CCIC must provide documentation to the CDM team detailing the information discoverable on their systems to adversaries. This can be done by performing annual searches of common internet locations to find out what information is available on the internet about your system. The procedures for documenting this discoverable information should follow the basic who, what, when, where, and why format. Once this information is determined and documented, the Division of Cyber Threat and Security Operations, System Owner, and Contractor Staff will establish a meeting to identify and carry out the appropriate corrective actions.

The table below outlines the CMS ODPs for RA-5(4):

Table 4: CMS Defined Parameters – Control RA-5(4)

 Privileged Access (RA-5(5))

There are systems on the CMS network that require privileged access. In order to conduct vulnerability scans on these systems, there must be an ability for the scanners to receive privileged access to these systems. A complete analysis of the privileged areas of system appliances cannot be performed without the necessary privileged access. The purpose of this control is to ensure that CMS identifies the information system components that require privileged access and the vulnerability scanning activities that require such access, as well as ensuring that privileged access is implemented for these activities.

The table below outlines the CMS ODPs for RA-5(5):

Table 5: CMS Defined Parameters – Control RA-5(5)

This can be achieved by obtaining appropriate management approval to allow privileged users such as Firewall Privileged Users and Intrusion Detection Privileged Users to perform vulnerability assessment from the privileged accounts perspective.