Healthcare.gov: Actions Needed to Enhance Information Security and Privacy Controls
Published: 2016-03-23T00:00:00

Fast Facts:

Highlights:
section_title: Why GAO Did This Study
paragraphs: The Patient Protection and Affordable Care Act required the establishment of health insurance marketplaces in each state to allow consumers to compare, select, and purchase health insurance plans. States establishing their own marketplaces are responsible for securing the supporting information systems to protect sensitive personal information they contain. CMS is responsible for overseeing states' efforts, as well as securing federal systems to which marketplaces connect, including its data hub.
GAO was asked to review security issues related to the data hub, and CMS oversight of state-based marketplaces. Its objectives were to (1) describe security and privacy incidents reported for Healthcare.gov and related systems, (2) assess the effectiveness of security controls for the data hub, and (3) assess CMS oversight of state-based marketplaces and the security of selected state-based marketplaces. GAO reviewed incident data, analyzed networks and controls, reviewed policies and procedures, and interviewed CMS and marketplace officials. This is a public version of a limited official use only report that GAO issued in March 2016. Sensitive information on technical issues has been omitted from this version.
section_title: What GAO Found
paragraphs: The Centers for Medicare & Medicaid Services (CMS) reported 316 security-related incidents, between October 2013 and March 2015, affecting Healthcare.gov—the web portal for the federal health insurance marketplace—and its supporting systems. According to GAO's review of CMS records for this period, the majority of these incidents involved such things as electronic probing of CMS systems by potential attackers, which did not lead to compromise of any systems, or the physical or electronic mailing of sensitive information to an incorrect recipient. None of the incidents included evidence that an outside attacker had successfully compromised sensitive data, such as personally identifiable information.
Consistent with federal guidance, CMS has taken steps to protect the security and privacy of data processed and maintained by the systems and connections supporting Healthcare.gov, including the Federal Data Services Hub (data hub). The data hub is a portal for exchanging information between the federal marketplace and CMS's external partners. To protect these systems, CMS assigned responsibilities to appropriate officials and documented information security policies and procedures.
However, GAO identified weaknesses in technical controls protecting the data flowing through the data hub. These included
insufficiently restricted administrator privileges for data hub systems,
inconsistent application of security patches, and
insecure configuration of an administrative network.
GAO also identified additional weaknesses in technical controls that could place sensitive information at risk of unauthorized disclosure, modification, or loss. In a separate report, with limited distribution, GAO recommended 27 actions to mitigate the identified weaknesses.
In addition, while CMS has taken steps to oversee the security and privacy of data processed and maintained by state-based marketplaces, improvements are needed. For example, CMS assigned roles and responsibilities to various oversight entities, met regularly with state officials, and developed a reporting tool to monitor performance. However, it has not defined specific oversight procedures, such as the timing for when each activity should occur, or what follow-up corrective actions should be performed if deficiencies are identified. Further, CMS does not require sufficiently frequent monitoring of the effectiveness of security controls for state-based marketplaces, only requiring testing once every 3 years.
GAO identified significant weaknesses in the controls at three selected state-based marketplaces. These included insufficient encryption and inadequately configured firewalls, among others. In September 2015, GAO reported these results to the three states, which generally agreed and have plans in place to address the weaknesses. Without well-defined oversight procedures and more frequent monitoring of security controls, CMS has less assurance that state-based marketplaces are adequately protected against risks to the sensitive data they collect, process, and maintain.
section_title: What GAO Recommends
paragraphs: GAO is recommending that CMS define procedures for overseeing the security of state-based marketplaces and require continuous monitoring of state marketplace security controls. HHS concurred with GAO's recommendations.

section_title: Letter
paragraphs: The Patient Protection and Affordable Care Act (PPACA), signed into  law on March 23, 2010, includes provisions to reform aspects of the  private health insurance market and expand the availability and  affordability of health care coverage. It required the establishment of  health insurance exchanges, now commonly referred to as  “marketplaces,” in each state by January 1, 2014. These marketplaces  are required to allow consumers and small employers to compare, select,  and purchase health insurance offered by participating private issuers of  qualified health plans.
The Department of Health and Human Services’ (HHS) Centers for  Medicare & Medicaid Services (CMS) is responsible for overseeing the  establishment and operation of these marketplaces, including creating a  federally facilitated marketplace in states not establishing their own.  States choosing to implement their own marketplaces are responsible for  securing the information systems that support the marketplace and their  connections to the federal marketplace and for protecting the data  collected and processed by the marketplace.
Given the high degree of congressional interest in the development and  launch of the marketplaces, GAO has conducted a body of work in this  area in order to assist Congress with its oversight responsibilities, of  which this is the final report. This report examines the privacy and  security issues related to the implementation of the Federal Services Data  Hub (data hub)—a portal for exchanging information between the federal  marketplace and CMS’s external partners—and CMS’s oversight of the  state-based marketplaces. Our specific objectives were to (1) describe  the extent to which security and privacy incidents were reported for  Healthcare.gov or key supporting systems; (2) assess the effectiveness of  the controls implemented by CMS to protect the data hub and the  information it transmits; and (3) assess the effectiveness of CMS’s  oversight of key program elements and controls implemented by state- based marketplaces and the effectiveness of those elements at selected  state-based marketplaces to protect the information they contain.
This is a public version of a limited official use only report we issued in  March 2016. Sensitive information, such as detailed descriptions of  information security weaknesses, has been omitted. Nevertheless, it  addresses the same objectives and scope as the limited official use only  report. Also, the overall methodology used for both reports is the same.
To address our first objective, we reviewed and analyzed data on  information security and privacy incidents reported by CMS affecting  Healthcare.gov and its supporting systems. Specifically, we reviewed a  list of reported incidents and the information in CMS records associated  with each incident, such as the incident reports and documentation of  actions taken to mitigate the incidents. We analyzed this information to  identify relevant statistics on the reported incidents.
To address our second objective, we analyzed the overall network control  environment, identified interconnectivity and control points, and reviewed  controls for the network and servers supporting the data hub. Specifically,  we reviewed controls over the data hub and its supporting software, as  well as the operating systems, network, and computing infrastructure  provided by the contractor. In order to evaluate CMS’s controls over its  information systems supporting Healthcare.gov, we used our Federal  Information System Controls Audit Manual, which contains guidance for  reviewing information system controls that affect the confidentiality,  integrity, and availability of computerized information; National Institute of  Standards and Technology (NIST) standards and guidelines; and CMS  policies, procedures, practices, and standards. We performed our work at  CMS contractor facilities in Columbia, Maryland, and Chantilly, Virginia.
To address our third objective, we selected three states for review by  concentrating on states that received a high amount of PPACA grant  funding through 2014, while ensuring a mix of both population size and  contractors used. To assess the effectiveness of the three selected  states’ key management controls, we compared their documented  policies, procedures, and practices to the provisions and requirements  contained in CMS security and privacy standards for state-based  marketplaces. To evaluate the technical controls implemented for their  marketplaces, we analyzed the overall network control environment,  identified control points, and reviewed controls for the supporting network  and servers and compared these controls to those specified in our  Federal Information System Controls Audit Manual, NIST guidance, and  CMS guidance for state-based marketplaces. Lastly, to determine the  effectiveness of CMS oversight of the states’ program elements and  controls, we reviewed and analyzed CMS policies and procedures  regarding oversight of the state-based marketplaces and compared them  to federal guidance on security controls testing and GAO’s Standards for  Internal Control in the Federal Government. We also obtained and  reviewed oversight-related documentation that CMS provided to the three  selected states.
We conducted this performance audit from December 2014 to March  2016 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. A full description of our  objectives, scope, and methodology can be found in appendix I.
subsections: section_title: Background
paragraphs: PPACA directed each state to establish and operate a state-based health  insurance marketplace by January 1, 2014. These marketplaces were  intended to provide a seamless, single point-of-access for individuals to  enroll in private health plans, apply for income-based financial assistance  established under the law, and, as applicable, obtain an eligibility  determination for other health coverage programs, such as Medicaid or  the Children’s Health Insurance Program (CHIP).
In states electing not to establish and operate a marketplace, PPACA  required the federal government to establish and operate a marketplace  in that state, referred to as a federally facilitated marketplace. Thus, the  federal government’s role with respect to a marketplace for any given  state—in particular whether it established a marketplace or oversees a  state-based marketplace—was dependent on a state decision. For plan  year 2016, 13 states had a state-based marketplace, 4 had a state- based marketplace using the federal marketplace platform, 27 had a  federally facilitated marketplace, and 7 had a state partnership  marketplace. Figure 1 shows the states and the types of marketplaces  they use.
subsections: section_title: CMS and State-Based Marketplaces Exchange Data with Many Interconnected Systems and External Partners to Facilitate Enrollment
paragraphs: PPACA requires that CMS and the states establish automated systems to  facilitate the enrollment of eligible individuals in appropriate health care  coverage. Many systems and entities exchange information to carry out  this requirement. The CMS Center for Consumer Information and  Insurance Oversight (CCIIO) has overall responsibility for the federal  systems supporting Healthcare.gov and for overseeing state-based  marketplaces, which vary in the extent to which they exchange  information with CMS. Other entities also connect to the network of  systems that support enrollment in Healthcare.gov. Figure 2 shows the  major entities that exchange data in support of marketplace enrollment  and how they are connected.
Regardless of whether a state established and operated its own  marketplace or used the federally facilitated marketplace, PPACA and  HHS regulations and guidance require every marketplace to have  capabilities that enable them to carry out four key functions, among  others:
Eligibility and enrollment. The marketplace must enable individuals  to assess and determine their eligibility for enrollment in health care  coverage. In addition, the marketplace must provide individuals the  ability to obtain an eligibility determination for other federal health care  coverage programs, such as Medicaid and CHIP. Once eligibility is  determined, individuals must be able to apply for and enroll in  applicable coverage options.
Plan management. The marketplace is to provide a suite of services  for state agencies and health plan issuers to facilitate activities such  as submitting, monitoring, and renewing qualified health plans.
Financial management. The marketplace is to facilitate payments of  advanced premium tax credits to health plan issuers and also provide  additional services such as payment calculation for risk adjustment  analysis and cost-sharing reductions for individual enrollments.
Consumer assistance. The marketplace must be designed to  provide support to consumers in completing an application, obtaining  eligibility determinations, comparing coverage options, and enrolling in  health care coverage.
subsections: section_title: Federal Data Services Hub
paragraphs: The data hub is a CMS system that acts as a single portal for exchanging  information between the federally facilitated marketplace and CMS’s  external partners, including other federal agencies, state-based  marketplaces, other state agencies, other CMS systems, and issuers of  qualified health plans. The data hub was designed as a “private cloud”  service supporting the following primary functions:
Real-time eligibility queries. The federally facilitated marketplace,  state-based marketplaces, and Medicaid/CHIP agencies transmit  queries to various external entities, including other federal agencies,  state agencies, and commercial verification services, to verify  information provided by applicants, such as immigration and  citizenship data, income data, individual coverage data, and  incarceration data.
Transfer of application and taxpayer information. The federally  facilitated marketplace or a state-based marketplace transfers  application information to state Medicaid/CHIP agencies. Conversely,  state agencies also use the data hub to transfer application  information to the federally facilitated marketplace. In addition, the  Internal Revenue Service (IRS) transmits taxpayer information to the  federally facilitated marketplace or a state-based marketplace to  support the verification of household income and family size when  determining eligibility for advance payments of the premium tax credit  and cost-sharing reductions.
Exchange and monitoring of enrollment information with issuers  of qualified health plans. The federally facilitated marketplace sends  enrollment information to appropriate issuers of qualified health plans,  which respond with confirmation messages back to CMS when they  have effectuated enrollment. State-based marketplaces also send  enrollment confirmations, which CMS uses to administer the advance  premium tax credit and cost-sharing reductions and to track overall  marketplace enrollment. Further, CMS, issuers of qualified health  plans, and state-based marketplaces exchange enrollment  information on a monthly basis to reconcile enrollment records.
Submission of health plan applications. Issuers of qualified health  plans submit “bids” for health plan offerings for validation by CMS.
Connections between external entities and the data hub are made  through an Internet protocol that establishes an encrypted system-to- system web browser connection. Encryption of the data transfer between  the two entities is designed to meet NIST standards, including Federal  Information Processing Standard 140-2. This type of connection is  intended to ensure that only authorized systems can access the data  being exchanged, thus safeguarding against cyber attacks attempting to  intercept the data.
The data hub is designed to not retain any of the data that it transmits in  permanent storage devices, such as hard disks. According to CMS  officials, data are stored only momentarily in the data hub’s active  memory. The entities that transmit the data are responsible for  maintaining copies of their transmissions in case the data need to be re- transmitted. As a result, CMS does not consider the data hub to be a  repository of personally identifiable information.
section_title: State-Based Marketplaces
paragraphs: State-based marketplaces generally perform the same functions that the  federally facilitated marketplace performs for states that do not maintain  their own marketplace. However, in certain cases, known as state  partnership marketplaces, states may elect to perform one or both of the  plan management and consumer assistance functions while the federally  facilitated marketplace performs the rest. The specific functions  performed by each partner vary from state to state. Figure 3 shows what  functions are performed by each type of marketplace.
Regardless of whether a state operates its own marketplace, most states  need to connect their state Medicaid and CHIP agencies to either their  state-based marketplace or the federally facilitated marketplace to  exchange data about enrollment in these programs. Such data  exchanges are generally routed through the CMS data hub. In addition,  states may need to connect with the IRS (also through the data hub) in  order to verify an applicant’s income and family size for the purpose of  determining eligibility for or the amount of the advance payment of the  premium tax credit and cost-sharing reductions. Finally, state-based  marketplaces are to send enrollment confirmations to the federally  facilitated marketplace so that CMS can administer advance payments of  the premium tax credit and cost-sharing payments and track overall  marketplace enrollment.
section_title: Laws and Regulations Set Requirements for Ensuring the Security and Privacy of Personally Identifiable Information
paragraphs: Federal laws and guidance specify requirements for protecting federal  systems and data. This includes systems used or operated by a  contractor or other organization on behalf of a federal agency. The  Federal Information Security Modernization Act of 2014 (FISMA) requires  each agency to develop, document, and implement an agency-wide  information security program to provide security for the information and  information systems that support operations and assets of the agency,  including those provided or managed by another agency, contractor, or  another organization on behalf of an agency.
FISMA assigns certain responsibilities to NIST, which is tasked with  developing, for systems other than national security systems, standards  and guidelines that must include, at a minimum, (1) standards to be used  by all agencies to categorize all of their information and information  systems based on the objectives of providing appropriate levels of  information security, according to a range of risk levels; (2) guidelines  recommending the types of information and information systems to be  included in each category; and (3) minimum information security  requirements for information and information systems in each category.
Accordingly, NIST has developed a risk management framework of  standards and guidelines for agencies to follow in developing information  security programs. Relevant publications include:
Federal Information Processing Standard 199, Standards for Security  Categorization of Federal Information and Information Systems,  requires agencies to categorize their information systems as low- impact, moderate-impact, or high-impact for the security objectives of  confidentiality, integrity, and availability. The potential impact values  assigned to the respective security objectives are the highest values  from among the security categories that the agency identifies for each  type of information resident on those information systems.
Federal Information Processing Standard 200, Minimum Security  Requirements for Federal Information and Information Systems,  specifies minimum security requirements for federal agency  information and information systems and a risk-based process for  selecting the security controls necessary to satisfy these minimum  security requirements.
Federal Information Processing Standard 140-2, Security  Requirements for Cryptographic Modules, requires agencies to  encrypt agency data, where appropriate, using NIST-certified  cryptographic modules. This standard specifies the security  requirements for a cryptographic module used within a security  system protecting sensitive information in computer and  telecommunication systems (including voice systems) and provides  four increasing, qualitative levels of security intended to cover a wide  range of potential applications and environments.
NIST Special Publication 800-53, Security and Privacy Controls for  Federal Information Systems and Organizations, provides a catalog  of security and privacy controls for federal information systems and  organizations and a process for selecting controls to protect  organizational operations, assets, individuals, other organizations,  and the nation from a diverse set of threats including hostile cyber  attacks, natural disasters, structural failures, and human errors. The  guidance includes privacy controls to be used in conjunction with the  specified security controls to achieve comprehensive security and  privacy protection.
NIST Special Publication 800-37, Guide for Applying the Risk  Management Framework to Federal Information Systems: A Security  Life Cycle Approach, explains how to apply a risk management  framework to federal information systems, including security  categorization, security control selection and implementation, security  control assessment, information system authorization, and security  control monitoring.
NIST Special Publication 800-160, Systems Security Engineering: An  Integrated Approach to Building Trustworthy Resilient Systems  (draft), recommends steps to help develop a more defensible and  survivable IT infrastructure—including the component products,  systems, and services that compose the infrastructure. While  agencies are not yet required to follow these draft guidelines, they  establish a benchmark for effectively coordinating security efforts  across complex interconnected systems, such as those that support  Healthcare.gov and state-based marketplaces.
While agencies are required to use a risk-based approach to ensure that  all of their IT systems and information are appropriately secured, they  also must adopt specific measures to protect personally identifiable  information (PII) and must establish programs to protect the privacy of  individuals whose PII they collect and maintain. Agencies that collect or  maintain health information also must comply with additional  requirements. In addition to FISMA, major laws and regulations  establishing requirements for information security and privacy in the  federal government include the following:
The Privacy Act of 1974 places limitations on agencies’ collection,  access, use, and disclosure of personal information maintained in  systems of records. The act defines a “record” as any item, collection,  or grouping of information about an individual that is maintained by an  agency and contains his or her name or another individual identifier. It  defines a “system of records” as a group of records under the control  of any agency from which information is retrieved by the name of the  individual or other individual identifier. The Privacy Act requires that  when agencies establish or make changes to a system of records,  they must notify the public through a system of records notice in the  Federal Register that identifies, among other things, the categories of  data collected, the categories of individuals about whom information is  collected, the intended “routine” uses of data, and procedures that  individuals can use to review and contest its content.
The E-Government Act of 2002 strives to enhance protection for  personal information in government information systems by requiring  that agencies conduct, where applicable, a privacy impact  assessment for each system. This assessment is an analysis of how  personal information is collected, stored, shared, and managed in a  federal system. More specifically, according to Office of Management  and Budget (OMB) guidance, a privacy impact assessment is an  analysis of how information is handled to (1) ensure handling  conforms to applicable legal, regulatory, and policy requirements  regarding privacy; (2) determine the risks and effects of collecting,  maintaining, and disseminating information in identifiable form in an  electronic information system; and (3) examine and evaluate  protections and alternative processes for handling information to  mitigate potential privacy risks. Agencies must conduct a privacy  impact assessment before developing or procuring IT that collects,  maintains, or disseminates information that is in an identifiable form or  before initiating any new data collections involving identifiable  information that will be collected, maintained, or disseminated using IT  if the same questions or reporting requirements are imposed on 10 or  more people.
The Health Insurance Portability and Accountability Act of 1996  establishes national standards for electronic health care transactions  and national identifiers for providers, health insurance plans, and  employers, and provides for the establishment of privacy and security  standards for handling health information. The act calls for the  Secretary of HHS to adopt standards for the electronic exchange,  privacy, and security of health information, which were codified in the  Security and Privacy Rules. The Security Rule specifies a series of  administrative, technical, and physical security practices for “covered  entities” and their business associates to implement to ensure the  confidentiality of electronic health information. The Privacy Rule  reflects basic privacy principles for ensuring the protection of personal  health information, such as limiting uses and disclosures to intended  purposes, notification of privacy practices, allowing individuals to  access their protected health information, securing information from  improper use or disclosure, and allowing individuals to request  changes to inaccurate or incomplete information. The Privacy Rule  establishes a category of health information, called “protected health  information,” which may be used or disclosed to other parties by  “covered entities” or their business associates only under specified  circumstances or conditions, and generally requires that a covered  entity or business associate make reasonable efforts to use, disclose,  or request only the minimum necessary protected health information  to accomplish the intended purpose.
section_title: HHS Has Established Responsibilities for Ensuring the Security and Privacy of Health Insurance Marketplaces
paragraphs: CMS’s CCIIO has overall responsibility for developing and implementing  policies and rules governing state-based marketplaces, overseeing the  implementation and operations of state-based marketplaces, and  administering federally facilitated marketplaces for states that elect not to  establish their own.
State-based marketplaces and the federal government must share data  and otherwise integrate IT systems for the implementation and operation  of the marketplaces. According to federal regulations, state-based  marketplaces are responsible for protecting and ensuring the  confidentiality, integrity, and availability of marketplace enrollment  information, and must also establish and implement certain privacy and  security standards. CMS oversees state-based marketplaces and  compliance with those standards. Additionally, federal statutes, guidance,  and standards require the federal government to protect its IT systems  and the information contained within these systems.
As part of its oversight responsibilities, CMS developed a suite of  documents—known as the Minimum Acceptable Risk Standards for  Exchanges (MARS-E)—that addresses security and privacy standards for  the state-based marketplaces. The documents define a risk-based  security and privacy framework for state-based marketplaces and their  contractors to use in the design and implementation of their IT systems  and provide guidance regarding the minimum level of security controls  that must be implemented to protect information and information systems.  The MARS-E is designed to facilitate marketplaces’ compliance with  FISMA, the Health Insurance Portability and Accountability Act of 1996,  and the Privacy Act of 1974, among other relevant laws.
section_title: Prior GAO Reports Highlighted Concerns Regarding the Implementation of the Health Insurance Marketplaces
paragraphs: Over the past 2 years, we have issued a number of reports highlighting  challenges that CMS has faced in implementing and operating the health  insurance marketplaces’ IT systems. In September 2014, we reported  that while CMS had taken steps to protect the security and privacy of data  processed and maintained by the complex set of systems and  interconnections that support Healthcare.gov, weaknesses remained in  both the processes used for managing information security and privacy as  well as the technical implementation of IT security controls. Specifically,  we noted that Healthcare.gov and the related systems had been deployed  despite incomplete security plans and privacy documentation, incomplete  security tests, and the lack of an alternate processing site to avoid major  service disruptions.
We recommended that CMS implement 6 management controls and 22  information security controls to help ensure that the systems and  information related to Healthcare.gov are protected. The management  recommendations were aimed at ensuring system security plans were  complete, privacy risks were analyzed and documented, computer  matching agreements were developed with the Office of Personnel  Management and the Peace Corps, a comprehensive security  assessment of the federally facilitated marketplace was performed, the  planned alternate processing site made operational in a timely fashion,  and detailed security roles and responsibilities for contractors were  established. HHS concurred fully or partially concurred with our  information security program-related recommendations and all 22 of the  recommendations to improve the effectiveness of its information security  controls. As of December 2015, CMS had taken steps to address all 6  information security program-related recommendations and was in the  process of addressing the security control-related recommendations.
In March 2015, we reported that several problems with the initial  development and deployment of Healthcare.gov and its supporting  systems had led to consumers encountering widespread performance  issues when trying to create accounts and enroll in health plans. We  noted, for example, that CMS had not adequately conducted capacity  planning, adequately corrected software coding errors, or implemented all  planned functionality. In addition, the agency did not consistently apply  recognized best practices for system development, which contributed to  the problems with the initial launch of Healthcare.gov and its supporting  systems. In this regard, weaknesses existed in the application of  requirements, testing, and oversight practices. Further, we noted that  HHS had not provided adequate oversight of the Healthcare.gov initiative  through its Office of the Chief Information Officer.
We made recommendations aimed at improving requirements  management, system testing processes, and oversight of development  activities for systems supporting Healthcare.gov. HHS concurred with all  of our recommendations and subsequently took or planned steps to  address the weaknesses, including instituting a process to ensure  functional and technical requirements are approved, developing and  implementing a unified standard set of approved system testing  documents and policies, and providing oversight for Healthcare.gov and  its supporting systems through the department-wide investment review  board.
In September 2015, we reported that CMS established a framework for  oversight of IT projects within state-based marketplaces, but the oversight  was not always effectively executed. For example, CMS tasked various  offices with responsibilities for overseeing states’ marketplace IT projects,  but the agency did not always clearly document, define, or communicate  its oversight roles and responsibilities to states as called for by best  practices for project management. In addition, CMS did not involve all  relevant senior executives in decisions to approve federal funding for  states’ IT marketplace projects. Lastly, CMS established a process that  required the testing of state marketplace systems to determine whether  they were ready to be made operational, but the systems were not always  fully tested, increasing the risk that they would not operate as intended.
We recommended that CMS define and communicate its oversight roles  and responsibilities, ensure senior executives are involved in funding  decisions for state IT projects, and ensure that states complete testing of  their systems before they are put into operation. HHS concurred with all  of our recommendations and stated it had taken various actions that were  focused on improving its oversight and accountability for states’  marketplace efforts.
Most recently, in February 2016, we reported that CMS should take  actions to strengthen enrollment controls and manage fraud risk. We  noted, for example, CMS does not, according to agency officials, track or  analyze aggregate outcomes of data hub eligibility and enrollment  queries—either the extent to which a responding agency delivers  information responsive to a request, or whether an agency reports that  information was not available. In addition, CMS did not have an effective  process for resolving inconsistencies for individual applicants for the  federal Health Insurance Marketplace. Lastly, CMS approved subsidized  coverage for 11 of 12 fictitious GAO phone or online applicants for 2014  and the applicants obtained a total of about $30,000 in annual advance  premium tax credits, plus eligibility for lower costs at time of service.
We made 8 recommendations aimed at strengthening enrollment controls  and managing fraud risk, including that CMS consider analyzing  outcomes of the verification system, take steps to resolve inconsistencies,  and conduct a risk assessment of the potential for fraud in Marketplace  applications. HHS concurred with all of GAO’s recommendations.
section_title: Healthcare.gov and Key Supporting Systems Have Experienced Information Security Incidents
paragraphs: NIST defines an information security incident as a violation or imminent  threat of violation of computer security policies, acceptable use policies,  or standard security practices. A security incident can occur under many  circumstances and for many reasons. It can be inadvertent, such as from  the loss of an electronic device, or deliberate, such as from the theft of a  device, or a cyber-based attack by a malicious individual or group,  agency insider, foreign nation, terrorist, or other adversary. Protecting  federal systems and the information on them is essential because the  loss or unauthorized disclosure or alteration of the information can lead to  serious consequences and can result in substantial harm to individuals  and the federal government.
FISMA requires the establishment of a federal information security  incident center to, among other things, provide timely technical assistance  to agencies regarding cyber incidents. The United States Computer  Emergency Readiness Team (US-CERT), established in 2003, is the  federal information security incident center that fulfills the FISMA  mandate. US-CERT consults with agencies on cyber incidents, provides  technical information about threats and incidents, compiles the  information, and publishes it on its website, https://www.us-cert.gov/. US- CERT also issues guidelines for agencies to use when reporting  incidents. For the time period under our review, US-CERT defined seven  categories of incidents for federal agencies to use in reporting incidents,  and CMS added two categories of its own, which are described below in  table 1.
Between October 6, 2013, and March 8, 2015, CMS reported 316  incidents affecting Healthcare.gov or key supporting systems. These  included—among others—incidents which involved PII and attempts by  attackers to compromise part of the Healthcare.gov system. None of the  incidents described in the data included any evidence that an attacker  had compromised sensitive data, including PII, from Healthcare.gov.  Figure 4 shows the 316 reported incidents grouped according to the US- CERT and CMS-defined incident categories.
CAT 1 unauthorized access incidents made up 17 percent of the incidents  logged during the time period under review. Of those, only one incident— which CMS publicly disclosed last year—involved a confirmed instance of  an attacker gaining access to a Healthcare.gov-related server. In that  incident, the attacker installed malware on a test server that held no PII.  The rest of the CAT 1 incidents involved occurrences such as PII being  disclosed because of physical mail being sent to an incorrect recipient or  unencrypted PII being transmitted via e-mail to a limited number of  individuals.
CMS also assessed incidents’ impact, categorizing incidents as having an  impact of “Extensive/Widespread,” “Significant/Large,”  “Moderate/Limited,” or “Minor/Localized.” More than 98 percent of the  reported incidents were assessed as “Moderate/Limited” impact, and the  remainder, less than 2 percent, as “Minor/Localized” impact. See figure 5  for a breakdown of incidents by CMS-assigned level of impact.
CMS did not classify any of the incidents we reviewed as having  “Extensive/Widespread” impact, and classified only one incident as  having “Significant/Large” impact. In that incident, a list of CMS employee  account IDs, including passwords that had not yet been assigned to  employees and phone numbers, was transmitted to CMS staff via an  unencrypted e-mail message. In order to mitigate the incident, CMS  created new passwords for the affected employees and advised the  employees to log on and change their passwords.
A privacy incident generally refers to the unauthorized or unintentional  exposure, disclosure, or loss of sensitive information, including PII.  According to CMS, 41 of the 316 incidents were reported to involve PII  either not being secured properly or being exposed to an unauthorized  individual, as opposed to other security issues affecting Healthcare.gov  and key supporting systems. Of the 41 PII incidents in the CMS data, the  agency classified 40 as being of “Moderate/Limited” impact, and one as  being of “Minor/Localized” impact. The number of individuals affected by  these incidents was not fully documented. While CMS, as of October  2014, began including an estimate of the number of affected individuals in  incident reports, several of the reports we reviewed were from earlier  incidents and did not contain estimates of the number of affected  individuals. See figure 6 for a breakdown of the privacy incidents by CMS- assigned level of impact.
As noted above, none of these incidents were the result of an attacker  compromising data, but were rather the result of errors such as  information being sent to the incorrect recipient, PII being transmitted in  an unencrypted format, or system configuration errors causing PII to be  recorded to system logs or displayed in places it should not have been.
section_title: Information Security Weaknesses Associated with the Federal Data Services Hub Place Healthcare.gov Data at Risk
paragraphs: A basic management objective for any organization is to protect the  confidentiality, integrity, and availability of the information and systems  that support its critical operations and assets. Organizations accomplish  this by designing and implementing access and other controls that are  intended to protect information and systems from unauthorized  disclosure, modification, and loss. Specific controls include, among other  things, those related to identification and authentication of users,  authorization restrictions, and configuration management. As required by  FISMA, NIST has issued guidance for agencies on how to select and  implement controls over their information systems. Additionally, in June  2015, OMB directed agencies to take steps to strengthen their controls in  the areas of scanning and monitoring for attackers, patching  vulnerabilities in a timely manner, limiting the use of administrative  accounts, and requiring the use of two-factor authentication, especially  for administrators.
As we previously reported, CMS took steps to protect the security and  privacy of data processed and maintained by the complex set of systems  and interconnections that support Healthcare.gov, including the data  hub. The steps included developing required security program policies  and procedures, establishing interconnection security agreements with its  federal and commercial partners, and instituting required privacy  protections. For example, it assigned overall responsibility for securing  the agency’s information and systems to appropriate officials, including  the agency Chief Information Officer and Chief Information Security  Officer, and designated information system security officers to assist in  certifying information systems of particular CMS components.  Additionally, CMS documented information security policies and  procedures to safeguard the agency’s information and systems and to  reduce the risk of and minimize the effects of security incidents.
While CMS has taken steps to secure the data hub, we identified  weaknesses in the technical controls protecting the data flowing through  the system. Specifically, CMS did not effectively implement or securely  configure key security tools and devices to sufficiently protect the users  and information on the data hub system from threats to confidentiality,  integrity, and availability. For example:
CMS did not appropriately restrict the use of administrative privileges  for data hub systems. NIST Special Publication 800-53 recommends  that agencies follow the concept of “least privilege,” giving users and  administrators only the privileges and access necessary to perform  their assigned duties. OMB has also instructed agencies to tighten  policies and procedures for privileged users, including limiting the  functions privileged users can perform with their administrative  accounts. However, CMS did not consistently restrict administrator  accounts to perform only the functions necessary to perform their  assigned duties. CMS officials stated they are working to further  restrict administrative privileges and are reviewing accounts to ensure  permissions and roles are appropriate. By not enforcing least  privilege, CMS faces an increased risk that a malicious insider or an  attacker using a compromised administrator account could access  sensitive data flowing through the data hub.
CMS did not consistently implement patches for several data hub  systems. NIST Special Publication 800-53 recommends that  organizations test and install newly released security patches, service  packs, and hot fixes, and OMB has instructed agencies to patch  critical vulnerabilities without delay. However, CMS did not  consistently apply patches to critical systems or applications  supporting the data hub in a timely manner. CMS officials stated they  are reviewing the patch histories on all servers and are directing staff  to bring them up-to-date or provide a business rationale for not  applying specific patches. By not keeping current with security  patches, CMS faces an increased risk that servers supporting the  data hub could be compromised through exploitation of known  vulnerabilities.
CMS did not securely configure the data hub’s administrative network.
NIST Special Publication 800-53 recommends how such a network  should be configured. CMS officials stated that they are reviewing the  network’s configurations to identify a plan for remediation. Without  adhering to NIST recommendations, CMS may face an increased risk  of unauthorized access to the data hub network.
In addition to the above weaknesses, we identified other security  weaknesses in controls related to boundary protection, identification and  authentication, authorization, encryption, audit and monitoring, and  software updates that limit the effectiveness of the security controls on  the data hub and unnecessarily place sensitive information at risk of  unauthorized disclosure, modification, or exfiltration. According to CMS  officials, in response to the identified weaknesses, they have formed a  task force, comprised of the Deputy Chief Information Security Officer,  system maintainers and administrators, database administrators, and  security personnel, to work with the stakeholders responsible for the data  hub applications and the underlying platform and infrastructure. The same  officials stated that meetings will be held on at least a weekly basis to  monitor milestone dates, discuss activities, and identify potential barriers  to resolution of any given weakness. The control weaknesses we  identified during this review are described in greater detail in a separate  report with limited distribution.
section_title: CMS Has Not Fully Implemented Security and Privacy Oversight of State-Based Marketplaces, Three of Which Had Significant Weaknesses
paragraphs: CMS has taken various actions to oversee the security and privacy  controls implemented at the state-based marketplaces, including  assigning roles and responsibilities for oversight entities, conducting  regular meetings with state officials to discuss pending issues, and  establishing a new reporting tool to monitor marketplace performance.  However, CMS has not fully documented procedures that define its  oversight responsibilities. Further, while CMS has set requirements for  annual testing of a subset of security controls implemented within the  state-based marketplaces, it does not require continuous monitoring or  annual comprehensive testing. Until CMS documents its oversight  procedures and requires continuous monitoring of security controls, it  does not have reasonable assurance that the states are promptly  identifying and remediating weaknesses and therefore faces a higher risk  that attackers could compromise the confidentiality, integrity, and  availability of the data contained in state-based marketplaces. The need  for better assurance that controls are working was highlighted by the  results of the reviews we conducted of security and privacy controls at  three state-based marketplaces. For those three marketplaces, we  identified significant weaknesses that placed the data they contained at  risk of compromise.
subsections: section_title: CMS Has Established Policies to Oversee the Effectiveness of Security and Privacy Controls but Has Not Defined Specific Procedures, Time Frames, or Follow-up Actions
paragraphs: Effective organizational policies and procedures define key management  activities in detail, establish time frames for their completion, and specify  follow-up actions that must be taken to correct deficiencies. According to  GAO’s Standards for Internal Control in the Federal Government, an  organization’s policies should identify internal control responsibilities and  each unit’s responsibility for designing and implementing those controls.  Moreover, each policy should specify the appropriate level of detail to  allow management to effectively monitor the control activities and define  day-to-day procedures, which may include the timing of when an activity  is to occur and any follow-up corrective actions to be performed if  deficiencies are identified.
While CMS has developed policies for overseeing security and privacy  controls at the state-based marketplaces, it has not defined specific  oversight procedures, the timing for when each activity should occur, or  what follow-up corrective actions should be performed if deficiencies are  identified.
CMS has assigned roles and responsibilities for oversight entities,  conducted regular meetings with state officials to discuss pending issues,  and established a new reporting tool to monitor marketplace performance.  For example, as we reported in September 2015, CMS outlined  oversight roles and responsibilities. Three key offices—CCIIO, Office of  Technology Solutions (OTS), and Center for Medicaid and CHIP Services  (CMCS)—were identified as having responsibility for overseeing states’  efforts in establishing the marketplaces. Their primary roles and duties  included the following:
CCIIO led the marketplace implementation, and within that office,  State Officers were assigned to be accountable for day-to-day  communications with state marketplace officials.
OTS was responsible for systems integration and software  development efforts to ensure that the functions of the marketplaces  were carried out. A primary participant within OTS was the IT project  manager, who was the individual responsible for monitoring, among  other things, state-based marketplaces’ IT development activities.
CMCS was the office responsible for coordinating and approving  implementation of Medicaid activities related to the health insurance  marketplaces. The office carried out these responsibilities in  conjunction with CCIIO.
While CMS outlined general oversight roles, it did not define or document  the specific day-to-day activities of these offices and staff that are  responsible for the oversight. For example, according to CCIIO officials,  the state officers conduct oversight through weekly meetings with state- based marketplace officials. The same officials stated that the meetings  do not have a defined agenda or procedures, but that identified control  weaknesses or other security issues are discussed. Further, there are no  documented procedures that outline the specific responsibilities of the IT  project manager, who was the individual responsible for monitoring state- based marketplaces’ IT development activities.
In 2015, CMS began using a new reporting tool to monitor state  performance. The State Based Marketplace Annual Reporting Tool  (SMART) is intended to collect information to be used as the basis for  evaluating a state-based marketplace’s compliance with regulations and  CMS standards. Information collected through SMART includes  performance metrics, summaries from independent programmatic audits,  and an attestation to the submission of the most recent required security  and privacy documentation. The first submissions from the states were  due on April 1, 2015. According to CMS officials, they received the  submissions and, as of December 2015, were still reviewing them.
While SMART is intended to collect information on compliance with  regulations and CMS standards, including security and privacy controls,  CMS has not defined specific follow-up procedures or time frames,  including identifying corrective actions to be performed if deficiencies are  identified. CMS officials stated SMART is a reporting mechanism used to  provide a comprehensive picture of state-based marketplaces and that  CMS does not use it to identify corrective actions to be performed if  deficiencies are identified. However, until CMS defines and documents its  specific day-to-day procedures, the timing of when control activities are to  occur, and what follow-up corrective actions are to be performed if  deficiencies are identified, the agency does not have reasonable  assurance that it is providing effective oversight of security and privacy at  state-based marketplaces.
section_title: CMS Requires Testing of State-Based Marketplaces Only Every Three Years
paragraphs: FISMA requires that an agency develop, document, and implement an  agency-wide information security program. The program should provide  security for the information and information systems that support the  operations of the agency, including those provided or managed by a  contractor or other source. As part of the information security program,  the agency should require periodic testing and evaluation of the  effectiveness of information security policies, procedures, and practices,  to be performed with a frequency depending on risk, but no less than  annually. FISMA requires this testing to be comprehensive, including  testing of management, operational, and technical controls of every  information system identified in the inventory.
Further, in November 2013 OMB issued guidance to federal agencies on  managing information security risk on a continuous basis, which includes  the requirement to continually monitor the security controls in information  systems and the environments in which they operate. OMB noted that  managing information risk on a continuous basis allows agencies to  maintain awareness of information security vulnerabilities and threats to  support risk management decisions and improve the effectiveness of  safeguards and countermeasures. Rather than enforcing a static, point-in- time reauthorization process, agencies were encouraged by OMB to  conduct ongoing authorizations of their information systems and the  environments in which they operated, including common controls, through  the implementation of their risk management programs.
Although CMS has set requirements for periodic testing of the security  controls at the state-based marketplaces, it requires neither continuous  monitoring nor comprehensive annual testing. Any state seeking to gain  an “authority to connect” to the data hub is required to submit  documentation that it has properly secured its planned connection. The  standard “authority to connect” to the data hub is issued for a 3-year  period. Following the approval of the initial “authority to connect,” every  state is required to conduct reviews of the documentation on a yearly  basis, submit quarterly plan of action and milestone reports, and re-sign  the interconnection security agreement every 3 years or whenever a  significant change has occurred to the interconnected systems. As part of  the signed agreement, each state must specify the security controls it has  implemented and attest that the state IT system is designed, managed,  and operated in compliance with CMS standards. According to the  MARS-E, all security controls are required to be assessed over a 3-year  period and to meet this requirement a subset is to be tested each year so  that all security controls are tested during a 3-year period. However,  according to CMS officials, during the time of our review, the states were  not required to submit evidence that they had tested subsets of controls  each year.
CMS officials stated that they monitor the effectiveness of security  controls on an ongoing basis by reviewing documents that contain  information on reported weaknesses. The same officials stated that they  perform quarterly reviews of state marketplaces’ plan of action and  milestone reports, and changes to the system boundaries, hardware,  software, and data centers. These officials added that if serious  deficiencies are noted in their review, such as a large number of open  high or moderate findings, or findings that have been open for a long  time, they have the ability to terminate a state’s connection to the data  hub if the deficiencies are not remediated or sufficient progress is not  made in a timely manner. However, according to CMS officials, they have  not yet terminated any state’s connection to the data hub because states  have remediated deficiencies to their satisfaction in a timely manner.
Numerous significant security weaknesses have been identified in state- based marketplaces. For example, in the second quarter of fiscal year  2015, the 14 states that maintained their own state-based marketplaces  reported a total of 27 high open findings, 288 moderate open findings,  and 259 low open findings from their own internal assessments. One  state reported 20 of the 27 high open findings during that time period.
According to CMS officials, while they do not require comprehensive  annual testing or continuous monitoring of security controls, they perform  annual reviews of the system security plans for the state-based  marketplaces and require the states to submit new security assessments  anytime they make significant changes to the systems. CMS officials also  stated that they monitor various state-generated documents on a weekly,  monthly, or yearly basis depending on when the reports are being  required. States are advised to include any new assessment, audit, or  weakness discovered during normal day-to-day operations in those  documents. However, for the plan of action and milestones reports and  state-based marketplaces we reviewed, the CMS oversight process has  not resulted in timely identification and mitigation of security weaknesses.  Without more frequently monitoring of the full set of security controls in  the state-based marketplaces and the environments in which they  operate, CMS does not have reasonable assurance that the states are  promptly identifying and remediating weaknesses and therefore faces a  higher risk that attackers could compromise the confidentiality, integrity,  and availability of the data contained in state-based marketplaces.
section_title: Security and Privacy Weaknesses Place Selected State-Based Marketplaces’ Data at Risk
paragraphs: The need for better assurance that security and privacy controls are  working properly was highlighted by the results of our reviews of technical  controls at three state-based marketplaces, which identified significant  weaknesses in those systems. In September 2015, we reported on our  reviews of three state-based marketplaces that assessed the  effectiveness of key program elements and controls implemented to  protect the information they contain. We identified weaknesses in key  elements of each state’s information security and privacy controls, such  as security management, privacy policies and procedures, security  awareness training, background checks, contingency planning, incident  response, and configuration management. Further, we identified security  weaknesses in technical controls related to access controls,  cryptography, and configuration management that limit the effectiveness  of the security controls on the systems. For example:
One state did not encrypt connections to the authentication servers  supporting its system. The MARS-E requires passwords to be  encrypted when they are being transmitted across the network.  However, the authentication servers we reviewed were configured to  accept unencrypted connections. As a result, an attacker on the  network could observe the unencrypted transmission to gather  usernames and password hashes, which could then be used to  compromise those accounts.
One state did not filter uniform resource locator (URL) requests from  the Internet through a web application firewall to prevent hostile  requests from reaching the marketplace website. NIST Special  Publication 800-53 requires the enforcement of access controls  through the use of firewalls. However, the state did not fully configure  its filtering to block hostile URL requests from the Internet. As a result,  hostile URL requests could potentially scan and exploit vulnerabilities  of the portal and potentially gain access to remaining systems and  databases of the marketplace.
One state did not enforce the use of high-level encryption on its  Windows servers. NIST Special Publication 800-53 and MARS-E  require that if an agency uses encryption, it must use, at a minimum, a  Federal Information Processing Standards 140-2–compliant  cryptographic module. However, the state did not configure its  Windows Active Directory and Domain Name System servers to  require the use of Federal Information Processing Standards– compliant algorithms. As a result, the servers may employ weak  encryption for protecting authentication and communication,  increasing the risk that an attacker could compromise the  confidentiality or integrity of the system.
For each of the security and privacy weaknesses we identified, we also  identified potential activities to mitigate those weaknesses. In total, we  identified 24 potential mitigation activities to address weaknesses in the  three states’ security and privacy programs and 66 potential mitigation  activities to improve the effectiveness of their information security  controls. The results of our work were reported separately in “limited  official use only” correspondences. The three states generally agreed  with the potential mitigation activities and have plans to address them.
section_title: Conclusions
paragraphs: Healthcare.gov and its key supporting systems have experienced  information security incidents which involved both PII not being secured  properly and attempts by attackers to compromise the Healthcare.gov  system. However, for the incidents we reviewed, we did not find evidence  that an outside attacker with malicious intent had compromised sensitive  data.
Although CMS continues to make progress in correcting or mitigating  previously reported weaknesses within Healthcare.gov and its key  supporting systems, the information security weaknesses found in the  data hub will likely continue to jeopardize the confidentiality, integrity, and  availability of Healthcare.gov. The information that is transferred through  the data hub will likely remain vulnerable until the agency addresses  weaknesses pertaining to boundary protection, identification and  authentication, authorization, encryption, audit and monitoring, software  updates, and configuration management.
While CMS has taken steps to ensure that the information processed and  maintained by stated-based marketplaces is protected from unauthorized  access or misuse, it lacks a documented oversight program to ensure that  each state is implementing security and privacy controls properly. Given  the significant number of control weaknesses found during our review of  selected states, CMS not requiring continuous monitoring of security  controls at the state level may pose unnecessary and increased security  risks to the data hub and other Healthcare.gov systems.
section_title: Recommendations for Executive Action
paragraphs: To improve the oversight of privacy and security controls over the state- based marketplaces, we recommend that the Secretary of Health and  Human Services direct the Administrator of the Centers for Medicare &  Medicaid Services to take the following three actions: define procedures for overseeing state-based marketplaces, to  include day-to-day activities of the relevant offices and staff; develop and document procedures for reviewing the SMART tool,  including specific follow-up timelines and identifying corrective actions  to be performed if deficiencies are identified; and  require continuous monitoring of the privacy and security controls over  state-based marketplaces and the environments in which those  systems operate to more quickly identify and remediate vulnerabilities.
In a separate report with limited distribution, we are also making 27  recommendations to resolve technical information security weaknesses  within the data hub related to boundary protection, identification and  authentication, authorization, encryption, audit and monitoring, and  software updates.
section_title: Agency Comments and Our Evaluation
paragraphs: We sent draft copies of this report to the Department of Health and  Human Services (HHS) and received written comments in return. These  comments are reprinted in appendix II. HHS concurred with all of GAO’s  recommendations. Further, it also provided information regarding specific  actions the agency has taken or plans on taking to address these  recommendations. We also received technical comments from HHS,  which have been incorporated into the final report as appropriate.
In its written comments, HHS noted that the department and its federal  partners comply with relevant laws and use processes, controls, and  standards to secure consumer data maintained within Healthcare.gov and  its supporting systems. Further, it described the process it uses to  mitigate information security risks associated with the data hub, manage  security incidents, and oversee the security and privacy of data  transmitted by the state-based marketplaces.
We are sending copies of this report to the Department of Health and  Human Services. In addition, the report is available at no charge on the  GAO website at http://www.gao.gov.
If you or your staffs have questions about this report, please contact  Gregory C. Wilshusen at (202) 512-6244 or Dr. Nabajyoti Barkakati at  (202) 512-4499. We can also be reached by e-mail at  wilshuseng@gao.gov and barkakatin@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 III.
section_title: Appendix I: Objectives, Scope, and Methodology
paragraphs: Our objectives were to (1) describe the extent to which security and  privacy incidents were reported for Healthcare.gov or key supporting  systems; (2) assess the effectiveness of the controls implemented by the  Centers for Medicare & Medicaid Services (CMS) to protect the Federal  Data Services Hub (data hub) and the information it transmits; (3) assess  the effectiveness of CMS’s oversight of key program elements and  controls implemented by state-based marketplaces and the effectiveness  of those elements at selected state-based marketplaces to protect the  information they contain.
To address our first objective, we reviewed and analyzed data on  information security and privacy incidents reported by CMS that occurred  between October 6, 2013, and March 8, 2015, affecting Healthcare.gov  and its supporting systems. Specifically, we reviewed a list of reported  incidents and the information associated with each incident, such as the  incident reports and actions taken to mitigate the incidents. We also  reviewed the reported impact of each incident. In order to ensure the  reliability of the data, we reviewed related documentation, interviewed  knowledgeable agency officials, and performed manual data testing for  obvious errors. We then analyzed the information to identify statistics on  the reported incidents. Lastly, we interviewed knowledgeable officials and  reviewed CMS policies and procedures for incident handling.
To address our second objective, we reviewed relevant information  security laws and National Institute of Standards and Technology (NIST)  standards and guidance to identify federal security and privacy control  requirements. Further, we analyzed the overall network control  environment, identified interconnectivity and control points, and reviewed  controls for the network and servers supporting the data hub. Specifically,  we reviewed controls over the data hub and its supporting software, the  operating systems, network, and computing infrastructure provided by the  supporting platform-as-a-service.
In order to evaluate CMS’s controls over its information systems  supporting Healthcare.gov, we used our Federal Information System  Controls Audit Manual, which contains guidance for reviewing information  system controls that affect the confidentiality, integrity, and availability of  computerized information; Office of Management and Budget (OMB)  guidance; NIST standards and guidelines; and CMS policies, procedures,  practices, and standards.  reviewed network access paths to determine if boundaries had been  adequately protected; analyzed system access controls to determine whether users had  more permissions than necessary to perform their assigned functions; observed configurations for providing secure data transmissions  across the network to determine whether sensitive data were being  encrypted;  reviewed software security settings to determine if modifications of  sensitive or critical system resources had been monitored and logged;  and  inspected the operating system and application software on key  servers and workstations to determine if critical patches had been  installed and/or were up-to-date.
We performed our work at CMS contractor facilities in Columbia,  Maryland, and Chantilly, Virginia.
To address our third objective, we selected three states by concentrating  on states who received a high amount of federal grant funding through  2014, while ensuring a mix of both population size (I.e., large, medium,  and small) and contractors used to ensure we reviewed a variety of  approaches to system development and operation. To assess the  effectiveness of the three selected states’ key program elements and  management controls, we compared their documented policies,  procedures, and practices to the provisions and requirements contained  in CMS security and privacy standards for state-based marketplaces. We  also reviewed the results of testing of security controls; analyzed system  and security documentation, including information exchange agreements;  and interviewed state officials.
To determine the effectiveness of the information security controls the  three states implemented for information systems supporting their  marketplaces, we reviewed risk assessments, security plans, system  control assessments, contingency plans, and remedial action plans. To  evaluate the technical controls for the marketplaces, we analyzed the  overall network control environment, identified control points, and  reviewed controls for the supporting network and servers. We compared  the aforementioned items to our Federal Information System Controls  Audit Manual; NIST standards and guidelines; CMS security and privacy  guidance for state-based marketplaces; and Center for Internet Security  guidance.
To determine the effectiveness of CMS oversight of the states’ program  elements and controls, we reviewed CMS policies and procedures  regarding oversight of the state-based marketplaces and compared them  to Federal Information Security Modernization Act of 2014 requirements,  OMB guidance on security controls testing, and GAO’s Standards for  Internal Control in the Federal Government. We also obtained and  reviewed oversight-related information that CMS provided to the three  selected states. Lastly, we interviewed officials from the relevant CMS  offices that had oversight responsibilities.
We conducted this performance audit from December 2014 to March  2016 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.
section_title: Appendix II: Comments from the Department of Health and Human Services
section_title: Appendix III: GAO Contacts and Staff Acknowledgments
subsections: section_title: GAO Contacts
section_title: Staff Acknowledgments
paragraphs: In addition to the contacts named above, John de Ferrari, Edward  Alexander Jr., Lon Chin, West Coile and Duc Ngo (assistant directors);  Christopher Businsky; Mark Canter; Marisol Cruz; Lee McCracken;  Monica Perez-Nelson; Justin Palk; Michael Stevens; and Brian Vasquez  made key contributions to this report.