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.
Recent data breaches have highlighted the importance of ensuring the security of health information, including Medicare beneficiary data. Such data are created, stored, and used by a wide variety of entities, such as health care providers, insurance companies, financial institutions, researchers, and others. GAO was asked to conduct a study of CMS efforts to protect Medicare beneficiary data accessed by external entities. GAO's objectives were to (1) identify the major external entities that collect, store, and process Medicare fee-for-service beneficiary data; (2) determine whether requirements for the protection of Medicare beneficiary data align with federal guidance; and (3) assess CMS oversight of the implementation of those requirements. GAO analyzed information about how external entities access data, reviewed CMS documentation on who they share data with, compared federal standards with CMS security requirements for external entities, and analyzed results of independent security reviews. GAO also interviewed CMS officials about their oversight activities. The Centers for Medicare and Medicaid Services (CMS) shares Medicare beneficiary data with three major types of external entities: (1) Medicare Administrative Contractors (MAC) that perform processing and distribution functions that support the payment of Medicare benefits; (2) research organizations (researchers) that use Medicare beneficiary data to study how health care services are provided to beneficiaries; and (3) qualified public or private entities that use claims data to evaluate the performance of Medicare service providers and equipment suppliers. 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 beneficiary data. While CMS has developed guidance for MACs and qualified entities, it has not developed equivalent guidance for researchers. Researchers must adhere to broad governmentwide standards, but are not given guidance on which specific controls to implement. According to CMS, the lack of specific guidance gives the researchers more flexibility to independently assess their security risks and determine which controls are appropriate to implement; however, without providing comprehensive, risk-based security guidance to researchers, CMS increases the risk that external entities possessing agency data may not have applied security controls that meet CMS standards. Additionally, CMS has established an oversight program for the security of MAC data, but has not established a corresponding program to oversee security implementation by researchers and qualified entities. Without effective oversight measures in place for researchers and qualified entities, CMS cannot fully ensure that the security of Medicare beneficiary data is being adequately protected. Regarding MACs, although they are subject to two types of independent annual assessments, which have regularly identified weaknesses in their implementation of security controls, the weaknesses that have been assessed as low-risk have not been consistently tracked in the CMS finding tracking system. Without more consistent tracking of these low-risk weaknesses, it may be difficult for CMS to determine if all weaknesses are being addressed in a timely manner. Examples of categories of recurring weaknesses that have been identified during annual assessments are listed in the table.