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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.

Summary: 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. 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. 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.