Electronic Health Information: CMS Oversight of Medicare Beneficiary Data Security Needs Improvement
Released: 2018-04-05T00:00:00

Letter

Background

Information security is a critical consideration for any organization that depends on information systems and computer networks to carry out its mission or business, and is especially important for government agencies, where maintaining the public’s trust is essential. Concerns about cyber threats to government systems and networks are well-founded, due to the dramatic increase in reports of security incidents, the ease of obtaining and using hacking tools, and advances in the sophistication and effectiveness of cyberattack technology, among other reasons. Without proper safeguards, systems are vulnerable to individuals and groups with malicious intent who can intrude and use their access to obtain or manipulate sensitive information, commit fraud, disrupt operations, or launch attacks against other computer systems and networks.

We and federal inspectors general have reported extensively on information security deficiencies that place federal agencies at risk of disruption, fraud, or inappropriate disclosure of sensitive information. Accordingly, since 1997, we have designated federal information security as a government-wide high-risk area. This area was expanded to include the protection of critical cyber infrastructure in 2003 and protecting the privacy of personally identifiable information in 2015.

Federal Law Establishes Security Requirements to Protect Federal Information and Systems

The Federal Information Security Modernization Act of 2014 (FISMA) is intended to provide a comprehensive framework for ensuring the effectiveness of security controls over information resources that support federal operations and assets as well as the effective oversight of information security risks. FISMA assigns responsibility to the head of each agency to provide information security protections commensurate with the risk and magnitude of the harm resulting from unauthorized access, use, disclosure, disruption, modification, or destruction of information systems used or operated by an agency or on behalf of an agency. The law also delegates to the agency’s Chief Information Officer (or comparable official) the authority to ensure compliance with FISMA requirements.

FISMA requires each agency to develop, document, and implement an agency-wide information security program to provide risk-based protections for the information and information systems that support the operations and assets of the agency, including those provided or managed by another entity. Such a program includes assessing risk; developing and implementing cost-effective security plans, policies, and procedures; developing plans for providing adequate information security for networks, facilities, and systems; providing security awareness and specialized training; testing and evaluating the effectiveness of controls; planning, implementing, evaluating, and documenting remedial actions to address information security deficiencies; developing and implementing procedures for detecting, reporting, and responding to security incidents; and ensuring continuity of operations. In addition, FISMA requires agencies to comply with NIST standards.

Office of Management and Budget Provides Guidance to Agencies on Implementing FISMA

In accordance with FISMA, the Office of Management and Budget (OMB) is responsible for the oversight of agencies’ information security policies and practices. OMB establishes requirements for federal information security programs and assigns agency responsibilities to fulfill the requirements of statutes such as FISMA. OMB requires agencies to oversee the implementation of security and privacy controls by contractors that collect, use, process, store, maintain, and disseminate federal information on behalf of a federal agency. For specific technical direction, OMB requires agencies to implement standards and guidelines established by NIST.

NIST’s Framework for Critical Infrastructure Cybersecurity Establishes a Baseline for Protecting Critical Information Assets

NIST has issued a suite of information security standards and guidelines, including Recommended Security Controls for Federal Information Systems and Organizations and the Framework for Improving Critical Infrastructure Cybersecurity. These documents collectively provide comprehensive guidance on developing and implementing information security programs to agencies and entities that perform work on their behalf.

The framework serves as a baseline for protecting critical information assets. In response to Executive Order 13636, NIST issued the framework in February 2014. It is intended to help organizations apply the principles and best practices of risk management to improve the security and resilience of critical infrastructure. The framework outlines a risk- based approach to managing cybersecurity that is composed of three major parts: a framework core, profile, and implementation tiers.

The framework core includes a list of functions, categories, subcategories, and informative references that describe specific cybersecurity activities identified as being in common across all critical infrastructure sectors. Additionally, the framework contains implementation tiers that provide context on how an organization views cybersecurity risk and the processes in place to manage that risk. Further, the framework provides guidance on documenting individual organizational profiles that describe how the functions, categories, and subcategories align with the business requirements, risk tolerance, and resources of the organization. According to NIST, the framework core represents a common set of activities for managing cybersecurity risk. The framework also states that, while it is not exhaustive, it is extensible, allowing organizations, sectors, and other entities to use subcategories and informative references that are cost-effective and efficient and that enable them to manage their cybersecurity risk. Table 1 lists the five functions and 22 categories of the framework core.

Subsequent to the issuance of the Cybersecurity Framework, a May 2017 executive order required agencies to use the framework to manage cybersecurity risks. It outlined actions to enhance cybersecurity across federal agencies and critical infrastructure to improve the nation’s cyber posture and capabilities against cybersecurity threats to digital and physical security. In addition, the order directed agencies to develop plans to implement the framework within 90 days. The order required agencies to include in their plans: the status of planning, organizing, and submitting IT budget materials, as directed in the Fiscal Year 2018 IT Budget Capital Planning Guidance, that are aligned with the framework, the proposed internal management of cybersecurity risk using the updated metrics aligned to the framework, a timeline to map existing and planned capabilities with the framework the proposed use of the terminology and concepts in the framework to organize and communicate cybersecurity activities and outcomes.

CMS Shares Medicare Fee-for- Service Beneficiary Data with Three Major Types of External Entities

CMS shares Medicare beneficiary data with three major types of external entities: (1) Medicare Administrative Contractors (MACs), the contractors that provide the core processing and distribution functions that support the payment of Medicare Part A, Part B, and Durable Medical Equipment (DME) beneficiary claims on behalf of CMS, (2) research organizations (researchers), academic and non-profit entities that use Medicare beneficiary data to assist CMS in monitoring, managing, and improving Medicare programs or the services provided to beneficiaries, and (3) qualified public or private entities that use claims data on behalf of CMS to evaluate the performance of Medicare service providers and equipment suppliers.

Medicare Administrative Contractors Access Fee- for-Service Beneficiary Data to Process Claims

MACs process more than 1.2 billion claims for Medicare Fee-for-Service beneficiaries annually. To do so, they interact with more than 1.5 million health care providers enrolled in the Medicare Fee-for-Service program. In addition to claims processing, some of the specific functions that the MACs perform include customer service for beneficiaries and providers, financial and debt management, audit and appeals functions, and medical reviews.

Each MAC contract covers a specific geographic area and a specific type of processing—either (1) Medicare Parts A and B claims or (2) DME claims for beneficiaries. Some MACs may hold multiple contracts and, thus, process multiple types of claims. In total, a network of eight MACs covers 16 multi-state jurisdictions, serving as the primary operational connection between the Medicare Fee-for-Service program and health care providers enrolled in the program. The geographic jurisdictions of the MACs that support Parts A and B and DME beneficiary claims are shown in figures 1 and 2, respectively.

In order to collect, store, and process information needed to process claims and make benefits payments on behalf of CMS, MACs connect directly to CMS systems. Specifically, MACs connect to CMS’s Virtual Data Centers (VDCs) through its CMSNet telecommunications network.

MACs process Medicare Fee-for-Service claims, which include beneficiaries’ PII and protected health information, through the VDCs. The VDCs consists of two large datacenters that are operated and managed by CMS that collectively serve as a platform for Medicare claims processing software systems. MACs use a combination of four CMS systems that operate within the VDCs to process claims. These systems and their functions are described in table 2.

Health care providers submit Medicare fee-for-service claims to the MACs. The claims are reviewed to check if the claim is in a valid format, if the requestor is valid, and whether it is a duplicate. In addition, MACs process claims in the Fiscal Intermediary Shared Systems, Multi-Carrier System, VIPS Medicare System, and Common Working File. Processing includes adjudicating claims, checking whether the services are covered by Medicare, and determining the price that should be paid to the provider for the service.

The links between external entities and CMS systems can take several different paths. Figure 3 shows how these entities are connected to CMS systems in order to obtain and use Medicare beneficiary data.

Researchers Access Fee- for-Service Beneficiary Data to Assist CMS in Monitoring, Managing, and Improving Medicare Programs and Services

Researchers use Medicare beneficiary data to study how healthcare services are provided to beneficiaries. Examples of research entities include universities and colleges, non-profit research institutes, and policy research organizations. CMS offers researchers a broad range of data on the Medicare program to support research on current and future spending, past and present enrollment, and claims, which can benefit the public through improved delivery of healthcare services. Research performed using this data may also assist CMS in monitoring, managing, and improving Medicare programs and services to beneficiaries.

To obtain Medicare data from CMS, researchers must apply for access to a specific dataset, such as the Carrier file which includes claims for services provided by physicians and other non-institutional providers. In the application, the researcher provides information explaining how the data are to be used and stored, and CMS reviews and approves (or denies) the application. The researcher then enters a data use agreement with CMS for access to specific sets of Medicare beneficiary data, which are to be used only for stated research objectives. The data use agreement specifies which beneficiary data can be accessed, for what purpose, the duration of access, and data protection and confidentiality requirements. Unless the agreement authorizes the release of the data in accordance with CMS policy, it is not to be released by the researcher. As of October 2017, 195 research entities had received Medicare data.

Researchers access Medicare beneficiary data in one of two ways. To gain access from their computers, they connect to CMS’s Chronic Conditions Warehouse/Virtual Research Data Center (CCW/VRDC) through a CMS-provided secure network connection. Within the CCW/VRDC, researchers are given access to an individually tailored computing environment containing only copies of the specific sets of beneficiary data they have been authorized to use. Researchers can then conduct their analysis on the data using software tools provided by CMS within this secure environment.

Researchers can also access data by having it shipped to them in encrypted form through the U.S. mail. Once it has been received, researchers decrypt the data and load it into their own information systems for analysis. The data use agreements specify requirements for protecting beneficiary data obtained in this fashion.

Qualified Entities Access Medicare Fee-for-Service Beneficiary Data to Evaluate the Performance of Service Providers and Equipment Suppliers

Qualified entities use CMS claims data to assess the effectiveness of Medicare service providers and equipment suppliers. The Medicare Data Sharing for Performance Measurement Program, originally established to comply with the Patient Protection and Affordable Care Act, requires qualified entities to combine the Medicare data with claims data from sources other than Medicare to produce and publicly disseminate CMS- approved reports on provider and supplier performance with regard to measures of quality, efficiency, effectiveness, and resource use.

Like researchers, after they have been approved to access data by CMS, qualified entities must enter into a data use agreement with CMS. The agreement specifies which beneficiary data can be accessed, for what purpose, the duration of access, and data protection and confidentiality requirements. A separate agreement is required for each qualified entity’s activity. The Medicare beneficiary data to be accessed are encrypted and can either be shipped to the qualified entity on an external hard drive or saved within the CCW/VRDC to be accessed through a Secure File Transfer System connection. Once it has received the electronic files, the qualified entity decrypts the files and analyzes the data on its own system(s).

As of October 2017, ten organizations had received Medicare data as a qualified entity. Each entity is responsible for analyzing and reporting on provider performance for one or more specific geographic area.

CMS Established Information Security Requirements that Align with Federal Guidance for Some, but Not All, External Entities

CMS has developed requirements for implementing security controls that align with federal guidance for two of the three types of external entities that access Medicare Fee-for-Service data. Specifically, adherence to the requirements, which CMS defined using a risk-based process, is mandatory for MACs and qualified entities. However, CMS does not consider the requirements to be applicable to researchers because they are not CMS contractors. Without providing comprehensive, risk-based requirements for implementing security controls to all external entities that have access to Medicare beneficiary data, CMS increases the risk that external entities possessing CMS data may not have applied security controls that meet CMS standards.

CMS Requirements for MACs and Qualified Entities Reflect a Risk- Based Assessment and Generally Align with the NIST Cybersecurity Framework

To assist agencies in the selection of appropriate security controls, NIST developed the Cybersecurity Framework, which specifies controls that support the core security functions of identifying, detecting, preventing, responding to, and recovering from security incidents. Further, to ensure that controls are selected that achieve the security goals of the organization, NIST recommends that organizations use risk-based methods to tailor the selection of controls within this framework for implementation. According to NIST risk management guidance, the tailoring process includes identifying a baseline of security controls, assigning specific values to organization-defined security control parameters, such as password complexity, and supplementing baselines with additional controls and control enhancements.

Once an agency has assessed security risks and identified appropriate controls to mitigate them, NIST recommends that the agency establish specific requirements for implementing those controls to ensure consistency both internally and externally to the agency. This is important in meeting the requirements of FISMA, which requires that a federal agency’s security efforts include information and systems provided or managed by another agency, contractor, or other source. Additionally, the Cybersecurity Framework recommends that contracts or other formal agreements abide by NIST guidance to provide a means to ensure privacy and security controls; it also states that contractors are to protect PII in the same manner as their customers.

CMS developed minimum security requirements based on applicable federal guidance, for its own internal systems and for the systems operated by its contractors, such as MACs and qualified entities. These requirements are documented primarily in CMS’s Acceptable Risk Safeguards (ARS).

CMS designed the ARS as a tailored selection of NIST controls reflecting FISMA requirements as well as the agency’s own policies, procedures, and guidance; other federal and non-federal guidance; and industry leading practices. According to the agency, the requirements in the ARS are intended to ensure that systems meet a minimum level of information security and privacy assurance and reflect the agency’s information systems security policy. CMS requires all employees, contractors, sub- contractors, and their respective facilities supporting agency business missions and performing work on behalf of the agency to observe this policy.

Because MACs are CMS contractors, the agency requires them to align their security practices with the ARS as well as with broader federal guidance, including NIST’s catalog of recommended security controls, its minimum security standard for federal information systems, and OMB’s guidance on information management. Additionally, as part of the Qualified Entity Certification Program and consistent with NIST guidance, CMS requirements state that systems used by qualified entities to process Medicare beneficiary data have been assessed at a moderate impact level and accordingly are held to the ARS implementation guidance using the minimum controls specified for moderate risk systems.

According to agency officials responsible for developing and maintaining the ARS, CMS used a risk-based process to select security controls to include in the requirements, thus ensuring that the ARS appropriately reflected agency needs and priorities. The process began with a review of baseline control requirements outlined in NIST guidance to ensure that all of those controls were reflected in the requirements. Then, the agency reviewed the rest of the NIST information security controls that were not included in the baseline and determined whether to include them in the ARS as “optional” controls. For example, the officials stated that certain controls appeared to apply primarily to national security systems and would not be needed for CMS applications. In all, the agency decided not to include 13 of the 165 controls specified in the NIST Cybersecurity Framework, none of which were designated by NIST as mandatory baseline controls.

By undertaking this process of assessing the risk associated with each of the information security controls, the agency helped to ensure that its ARS reflects security requirements that are necessary and appropriate for its own systems and for systems operated by contractors on its behalf. A complete description of the NIST Cybersecurity Framework controls and how the ARS aligns with them can be found in appendix II.

CMS Does Not Provide Security Guidance for Researchers

While CMS requires MACs and qualified entities to implement security controls consistent with NIST guidance and provides additional guidance to ensure that those controls are consistent with CMS standards, it does not provide supplemental guidance tailored for researchers. Specifically, as part of its data use agreements with researchers, CMS includes a broad requirement to implement security and privacy protections that are consistent with NIST and OMB guidance. However, the agency has not provided risk-based guidance defining the minimum acceptable security controls that researchers should implement to protect Medicare beneficiary data. Nor has CMS provided guidance to researchers on how to select and implement specific security controls.

According to CMS officials who oversee researcher access to CMS data, all researchers are required to prepare data management plans that outline their planned safeguards for protecting Medicare beneficiary data in their custody. In determining what controls to implement, however, they have only broad federal guidance, such as NIST’s catalog of controls, to use as a reference. The officials stated that CMS has not developed specific requirements based on an assessment of the risks associated with researcher functions that would define a minimum set of required safeguards. This is in contrast with the MACs and qualified entities, which have specific requirements based on the ARS that they are to implement to adequately protect data received from CMS.

The lack of specific requirements does not affect all data that researchers access on behalf of CMS. In many cases, researchers access and process Medicare beneficiary data on systems operated by CMS and are not responsible for implementing the security controls for those systems. In such cases, the researchers access beneficiary data within a virtualized environment, called the CCW/VRDC, which allows CMS to monitor data retrieval and use.

However, in other cases, CMS provides beneficiary data to researchers on external hard drives or other physical media that are outside of the Chronic Conditions Warehouse. In those cases, researchers receive Medicare beneficiary data that they transfer to and process on their own systems. These systems are secured according to individual researchers’ own policies and procedures, which may or may not be consistent with CMS requirements applied to other entities.

CMS requirements tailored specifically for researchers could address topics such as password complexity, patch management, and encryption of sensitive data, all of which otherwise may be implemented inconsistently by different researchers. According to CMS officials responsible for overseeing researcher access to data, CMS does not require researchers to adhere to its Information Systems Security and Privacy Policy or to implement the controls specified in the ARS because researchers are not agency contractors. The CMS officials said it was not necessary for the agency to set specific security requirements for entities that do not have a contractual relationship with the agency. Additionally, these officials stated that they believe the lack of specific guidance gives the researchers more flexibility to independently assess their security risks and determine which controls to implement based on that assessment.

However, by not providing guidance to researchers that includes security implementation requirements tailored to CMS-authorized uses of Medicare data, CMS cannot ensure that researchers implement security measures that are commensurate with the sensitivity of the data that is provided to them. As a result, there is an increased risk that sensitive PII and protected health information may be at risk of compromise.

CMS Has Not Consistently Overseen the Implementation of Security Controls by External Entities

CMS has established a program to oversee the MACs’ implementation of security and privacy protections over Medicare beneficiary data, but it does not consistently track low-risk weaknesses in the CMS FISMA Controls Tracking System. MACs are subject to two types of independent annual assessments that regularly identify weaknesses in their implementation of security controls. The assessments have identified several recurring categories of weaknesses; however, the agency does not track low-risk weaknesses that could be related to these recurring categories. Additionally, CMS has not established a corresponding program for overseeing the implementation of security controls by researchers and qualified entities. Without more consistently tracking identified issues at MACs and establishing effective oversight measures for researchers and qualified entities, CMS cannot fully ensure that the security of Medicare beneficiary data is being adequately protected.

CMS Has Overseen Independent Assessments at the MACs, but Has Not Consistently Tracked Issues Identified by Those Assessments

Requirements for agencies to oversee the implementation of security protections are established in law and federal guidance. For example, the NIST Cybersecurity Framework specifies that organizations should assess security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome. The framework states that, as part of the process for conducting security control assessments, organizations should track and monitor weaknesses and develop remedial actions. Further, according to the framework, the security assessment process is intended to provide feedback to organizations that can use the information to make risk- based adjustments to protections for their systems and networks.

In addition, both FISMA and the Medicare Prescription Drug, Improvement, and Modernization Act (MMA) of 2003 set specific requirements for CMS oversight of the implementation of information security controls by the MACs. FISMA requires an annual independent evaluation of an agency’s information systems, including those provided or managed by contractors, to ensure compliance with NIST requirements. Further, OMB’s FISMA guidance specifies regular testing of all security controls with an agency-determined, risk-based subset to be tested annually. The MMA likewise requires the MACs to undergo an independent evaluation of their information security program on an annual basis. Specifically, an independent assessor is to annually test an appropriate subset of a contractor’s systems and assess compliance with federal requirements for information security policies, procedures, standards, and guidelines, as defined by OMB.

MACs Undergo Two Types of Annual Assessments

In order to meet the requirements of the MMA and FISMA, CMS established two separate annual information security assessment processes for the MACs. Specifically, to comply with MMA, CMS has overseen independent annual evaluations of these contractors since the law was enacted in 2003. CMS selected an independent assessor to perform all of the MMA assessments. The assessor first reviews documentation of the implementation of security controls by the contractor and then reviews technical security controls onsite at each MAC. In 2010, CMS expanded the MMA assessments into more technical areas and has included penetration testing as part of the assessments.

In addition, agency officials that oversee the MMA assessments stated that CMS reviews contractor policies and procedures for configuration management twice a year and conducts an on-site review of the implementation of selected technical controls every June. In 2016, the independent assessor performed tests in nine categories of security controls at eight MAC datacenters. In total, these assessments reported 168 weaknesses, of which 53 were categorized as high or moderate risk and 115 were low-risk.

Further, to comply with FISMA requirements that all controls are tested regularly, CMS requires MACs to test one-third of their system security controls annually. CMS determines the control families to be tested in any given year and rotates the selection each year so that all controls are tested by the end of the 3-year testing cycle. For the 2016 FISMA assessment, CMS selected 121 security requirements within 8 control families.

The independent assessor is responsible for assessing the security controls and making recommendations on how to correct weaknesses and address identified vulnerabilities. To determine compliance with CMS requirements, controls are assessed against the minimum security requirements defined in the CMS ARS.

According to CMS officials from the Medicare Contractor Management Group, the two annual assessment processes together ensure that sufficient testing is being conducted each year. For example, in any given year, the MMA assessments may cover different security controls than the FISMA assessments. In addition, the FISMA assessors may identify outstanding recommendations that were made from the prior year’s MMA assessment and provide a status update on progress made to address open recommendations.

Corrective Actions and Milestones Have Not Always Been Tracked Consistently

Tracking and remediation are key parts of an organization’s security program that help to ensure that identified issues are addressed promptly and effectively. CMS requires the MACs to develop corrective action plans to remediate most of the weaknesses identified by the MMA and FISMA assessments. CMS requires that these weaknesses, along with plans of action and milestones for correcting them, be captured and tracked in its CMS FISMA Controls Tracking System, which is an agency- wide system for tracking the remediation of identified weaknesses. The tracking system maintains the certification and accreditation documents for all MAC systems and manages plans of action and milestones, their remediation activities, and completion. CMS monitors the disposition of all issues captured in the CMS FISMA Controls Tracking System, which helps to ensure that the MACs take steps to address weaknesses within required time frames.

However, because CMS does not routinely track low-risk weaknesses, it may not be ensuring that all weaknesses consistently receive appropriate management attention and timely remediation. Specifically, with regard to the MMA assessments, CMS requires MACs to develop a corrective action plan to remediate only high and medium-risk weaknesses, which are tracked using plans of action and milestones. CMS does not require the tracking of low-risk weaknesses, which are shown in the assessment reports as recommended improvements rather than weaknesses in need of correction. In certain cases, MMA assessments have classified weaknesses as low-risk, and they have not been tracked in the CMS FISMA Controls Tracking System, even though similar weaknesses were classified by other assessments as medium- or high-risk, and were tracked. In contrast to the MMA assessments, CMS requires that MACs track all weaknesses identified in FISMA assessments in the CMS FISMA Controls Tracking System.

Examples of inconsistently classified weaknesses reported in the 2016 MMA assessments include (1) maintaining complete and up-to-date inventories of information system components and (2) ensuring that protections against malicious software are installed and kept up-to-date. Of the six assessments that reported that MACs did not have a complete and accurate listing of systems and devices supporting Medicare claims processing, three classified this weakness as medium-risk and created a plan of action and milestones, while the other three assessed a low-risk level and did not create a plan of action and milestones. Similarly, eight assessments reported that MACs either did not have malicious software protections installed or they were not up-to-date. Of these eight, CMS officials stated that three were classified as medium-risk and were tracked by CMS, while the other five were assigned a low-risk level and not tracked.

The inventory and malicious software protection weaknesses that were tracked inconsistently are related to categories of weaknesses that have posed recurring challenges for the MACs in recent years. Since 2009, both the MMA and FISMA assessments have reported incomplete implementation of several types of high-risk security requirements across all the MACs. The weaknesses identified during these assessments— which generally involved configuration management, system security plans, and system inventories—have yet to be fully resolved. Table 3 describes these key categories of weaknesses.

According to CMS officials, weaknesses identified in the annual MMA assessments may be ranked at different risk levels because the specific circumstances of each finding can vary. However, documentation of the specific weaknesses identified in the 2016 MMA assessment reports does not make clear why findings that are characterized in similar terms or have the same name may have been assigned different risk levels.

CMS officials who oversee the information security testing at MACs stated that they are aware of the recurring areas of weaknesses identified in the annual assessments and have been taking actions to address them. For example, in 2009, CMS began requiring MACs to submit evidence that their configuration management programs complied with CMS requirements. According to the officials, since this program has been put into place, configuration management processes at the MACs have become more consistent and more thoroughly documented.

Nevertheless, the 2016 FISMA assessments concluded that a MAC’s system security plan did not include procedures for testing changes made to their production environments, and the MAC was not tracking changes made to the production environments. According to the CMS officials, the fact that recurring issues such as these have not yet been fully resolved may be due to the root causes of the deficiencies not yet being addressed.

Without more consistent tracking of identified issues through plans of action and milestones, it may be difficult for CMS to fully determine the extent to which security weaknesses identified during assessments of the MACs are remediated. Weaknesses that appear to be low-risk may be indicators of more significant underlying issues and, thus, may not be receiving appropriate management attention or prompt remediation, unnecessarily exposing Medicare beneficiary data to security risks.

CMS Does Not Have Effective Oversight Processes and Procedures for Researchers and Qualified Entities

While CMS has established assessment programs for MACs, the agency has much more limited security oversight mechanisms in place to ensure that qualified entities and researchers with access to Medicare beneficiary data implement appropriate security controls. CMS oversight processes and procedures for qualified entities and researchers consists primarily of reviewing the data protections that researchers and qualified entities describe in the data management plans they submit when requesting access to Medicare beneficiary data.

According to CMS officials who review these plans, they may ask follow- up questions to obtain more information or make recommendations on how to better implement security safeguards in accordance with CMS requirements. However, no further reviews are conducted for any qualified entities or researchers. For example, CMS does not conduct on- site reviews of the implementation of security controls and does not collect or review evidence of whether the controls have been appropriately implemented. Further, it does not conduct or require any independent testing of security controls.

As an additional check for qualified entities, instead of assessing their security controls, CMS assesses their responses to questions relating to 213 moderate-level data security controls from 26 control families set forth in the ARS. However, once the initial document review has been completed, CMS does not perform any in-person or document reviews of security controls that are in place unless the qualified entity reports a major change in its data security environment after initial approval.

According to officials of the Office of Enterprise Data Analytics, which is responsible for overseeing access to Medicare data by researchers and qualified entities, CMS has, in the past, conducted remote and on-site reviews as a pilot project. These reviews examined selected researchers’ security controls, based on factors such as the use of data described in the researchers’ data management plans. According to these officials, the pilot project is no longer being conducted because funding for the program has stopped.

The need to ensure that these entities have effectively implemented information security controls is demonstrated by data breaches that these organizations have reported. Of the 195 research entities that CMS has data use agreements with, six have suffered data breaches involving the loss of over 500 records containing PII covered under the Health Insurance Portability and Accountability Act of 1996, which they reported to the HHS Office of Civil Rights. These breaches included Internet-based intrusions into researcher systems as well as other IT- related incidents.

According to CMS officials who oversee access to Medicare data for researchers and qualified entities, the data use agreement requires organizations to report any breach of PII or personal health information from the CMS data files to the agency. These officials also stated that the six organizations did not report any breaches to CMS and that they were unaware that the organizations had reported compromises. The officials noted that if the breaches did not involve PII or personal health information from CMS data files provided under a data use agreement, the organizations were not required to report this information to CMS. Further, these officials stated that the agency is currently revising its data management plan to include a requirement for organizations to fully disclose all breaches to the agency, which may impact whether or not to grant access to Medicare data for organizations that were breached.

Given that, in the past, researchers’ systems have been successfully attacked, effective implementation of security controls is critical to reducing threats of compromise. However, without more robust oversight processes and procedures, CMS cannot determine whether qualified entities or researchers have implemented security controls appropriately and, thus, cannot ensure that the risks associated with their use of Medicare beneficiary data have been adequately mitigated.

Conclusion

CMS shares Medicare beneficiary data with external entities primarily for processing Medicare claims, supporting medical research, and evaluating the performance of Medicare service and equipment providers. CMS has set basic requirements for protecting the security of Medicare beneficiary data that it shares with MACs, qualified entities, and researchers. However, CMS has not required the documentation of low-risk weaknesses in the CMS FISMA Controls Tracking system so that CMS can track the MACs’ remediation of weaknesses that have been identified in recurring annual assessments. In addition, MACs and qualified entities are given guidance that generally aligns with federal guidance and is based on an assessment of risks specific to CMS to ensure that appropriate controls have been included. However, CMS has not provided guidance to researchers on how to select and implement specific security controls. Until CMS provides more comprehensive, risk- based guidance on implementing security controls to all of its external partners, there is an increased risk that researchers will not fully implement appropriate protections for Medicare beneficiary data.

CMS has developed and implemented an oversight program for the MACs’ implementation of security controls based on two types of annual independent assessments, which together help ensure that sufficient testing is being conducted each year. However, CMS has not ensured that the MACs track and remediate identified weaknesses consistently, including weaknesses that have been identified in recurring annual assessments. Further, CMS has not established an oversight program for qualified entities and researchers to assess whether they are implementing security controls as they are required. Without more effective oversight programs in place, CMS lacks full assurance that external entities are appropriately implementing security protections for Medicare beneficiary data.

Recommendations

We are making three recommendations to the Administrator of the Centers for Medicare and Medicaid Services:

Develop and distribute guidance for researchers defining minimum security controls and implementation guidance for those controls that is consistent with NIST guidance. (Recommendation 1)

Develop processes and procedures to ensure that findings from all MAC assessments are classified consistently and tracked appropriately. (Recommendation 2)

Develop processes and procedures to ensure that qualified entities and researchers have implemented information security controls effectively throughout their agreements with CMS. (Recommendation 3)

Agency Comments and our Evaluation

We received written comments on a draft of this report from HHS. In the comments (reprinted in appendix III), the department concurred with our three recommendations and discussed actions that the department has planned or taken. If fully and effectively implemented, the intended actions should help HHS to address weaknesses in processes and procedures for ensuring the protection of Medicare beneficiary data used by the department’s contractors. The department also provided technical comments, which we have incorporated in the report, as appropriate.

We are sending copies of this report to the appropriate congressional committees, the Secretary of Health and Human Services, and other interested parties. In addition, the report is available at no charge on the GAO website at http://www.gao.gov.

If you or your staff have any questions about this report, please contact me at (202) 512-9342 or marinosn@gao.gov. Contact points for our Offices of Congressional Relations and Public Affairs may be found on the last page of this report. GAO staff who made major contributions to this report are listed in appendix IV.

Appendix I: Objectives, Scope, and Methodology

Our objectives were to (1) identify the major entities that collect, store, and process Medicare beneficiary data and that connect with Centers for Medicare and Medicaid Services (CMS) systems and networks; (2) determine whether requirements for the protection of Medicare beneficiary data align with federal guidance; and (3) assess the programs CMS has in place to oversee the implementation of security protections for Medicare beneficiary data.

To address our first objective, we analyzed prior GAO reports and CMS documentation, such as CMS data maps and system documentation. Additionally, we conducted interviews with agency officials to identify major external entities that access Medicare beneficiary data, including with Medicare Administrative Contractors (MAC) and researchers. We analyzed the information obtained from CMS to describe the type of Medicare data each entity has access to and purposes for which such access is provided. Further, we analyzed agency agreements with external entities to describe external uses for the data CMS collects and distributes.

Regarding our second objective, we analyzed CMS guidance, specifically its Acceptable Risk Safeguards (ARS), to determine baseline requirements for the protection of Medicare beneficiary data that have been established by CMS. To assess the completeness of this guidance, we compared the ARS to the National Institute of Standards and Technology’s (NIST) Cybersecurity Framework’s controls included in the “identify,” “protect,” “detect,” and “respond” categories. We did not include the “recover” category because it is more focused on data recovery than on the identification, protection, and detection capabilities necessary to prevent incidents. We compared the controls referenced by NIST to the controls that were documented in the ARS to identify controls that had not been included. We also interviewed CMS officials responsible for developing the ARS to determine the process that the agency uses to select controls.

Additionally, to determine how CMS required external entities to implement security measures, we reviewed formal agreements that were entered into with those organizations. For the MACs, we analyzed contracts to determine CMS security requirements. For researchers and qualified entities, we reviewed the data use agreement templates to determine what requirements CMS specified for selecting and implementing security measures.

To address our third objective, we analyzed system assessments performed by CMS and conducted interviews with CMS officials responsible for overseeing the security of Medicare beneficiary data provided to external entities. Specifically, we analyzed information security assessments to determine the nature and extent of reported findings, the disposition of assessment recommendations, and whether assessment results were being addressed in a timely fashion over the span of time that they have been conducted.

For the MACs, we reviewed assessments performed in accordance with the Federal Information Security Management Act and the Medicare Prescription Drug, Improvement, and Modernization Act of 2003. For researchers and qualified entities, we obtained information from CMS about ongoing and previously performed assessment programs. Through interviews with relevant CMS officials, we obtained and analyzed information about the findings that were not resolved in a timely fashion and about the constraints that prevented the ongoing assessment of researchers and qualified entities.

We conducted this performance audit from October 2016 to January 2018 in accordance with generally accepted government auditing standards. Those standards require that we plan and perform the audit to obtain sufficient, appropriate evidence to provide a reasonable basis for our findings and conclusions based on our audit objectives. We believe that the evidence obtained provides a reasonable basis for our findings and conclusions based on our audit objectives.

Appendix II: Analysis of CMS Acceptable Risk Safeguards

We compared the Centers for Medicaid and Medicare Services (CMS) Acceptable Risk Safeguards (ARS) with the National Institute of Standards and Technology (NIST) Cybersecurity Framework to determine the extent to which the ARS aligns with the framework. To do this, we compared the controls noted as informative references by the framework to the controls documented in the ARS. We did not assess the “Recover” category because it is more focused on data recovery than on the identification, protection, and detection capabilities necessary to prevent incidents.

Appendix III: Comments from the Department of Health and Human Services

Appendix IV: GAO Contact and Staff Acknowledgments

GAO Contact

Staff Acknowledgments

In addition to the contact named above, John De Ferrari (assistant director); Thomas Johnson (analyst-in-charge); Chris Businsky, Kavita Daitnarayan, Nancy Glover, Charles Hubbard III, Monica Perez-Nelson, and Richard Sayoc made key contributions to this report.