The Centers for Medicare & Medicaid Services (CMS) and its parent, the U.S. Department of Health and Human Services (HHS), took “significant security risks” when they let the HealthCare.gov public exchange enrollment system go live on Oct. 1, 2013 — and they still have no good way to know whether the system has security holes.
Gregory Wilshusen and Nabajyoti Barkakati, directors at the U.S. Government Accountability Office (GAO), come to that conclusion in a report on information security and privacy controls weaknesses at HealthCare.gov.
HealthCare.gov helps consumers and small businesses use the state exchanges managed by HHS to apply for qualified health plan (QHP) coverage. HealthCare.gov also helps consumers in states with state-based PPACA exchanges find those exchanges, and a HealthCare.gov consumer information “data hub” helps state-based exchanges verify whether consumers are eligible for PPACA QHP subsidies.
Congress required the HHS secretary to certify that HealthCare.gov was secure before letting it open for business.
Officials at HHS told the GAO that independent security firms had completed testing of the data hub and the HHS-run exchange systems that went live Oct. 1, with no open warnings of high-risk problems. Every state that connected to the data hub complied with CMS security procedures, HHS officials told the GAO.
The GAO directors say they disagree with the idea that CMS took no significant risk when it let HealthCare.gov systems go live.
“The fact that CMS’s security contractor had not been able to test all of the security controls for the [HHS-run exchanges] in one complete version of the system meant that there was an increased risk that undetected security control deficiencies could lead to a compromise that jeopardized the confidentiality, availability, and integrity of HealthCare.gov and the data it maintained,” the GAO directors write.
Four of the states with state-based exchanges received only interim authorizations to connect because of problems such as unresolved, high-risk security problems and a large number of unresolved, relatively low-risk problems, the directors say.
Another problem is that HHS did not have, and still does not have, a backup site it can use when the main HealthCare.gov system has problems, the directors say.
One cause of the security weaknesses is that CMS project managers and its contractors did not always agree on how security controls at the HHS-run exchanges were supposed to work or who was in charge of making the controls work properly, the directors say.
CMS has not always taken basic security steps such as requiring users of HHS-run exchange systems to have strong passwords, and it has not always kept the support systems for the HHS-run exchanges from connecting with the Internet, the directors add.
CMS had not completed testing of the HHS-run exchange systems as of June, and it dealt with some matters, such as the security of network infrastructure controls “inherited” from a cloud-based services system “as being out of scope for security controls assessments,” or assuming that those inherited controls were adequate, the directors say.
Because CMS did not put those controls through comprehensive tests, it has not had reasonable assurance that the controls were working properly, the directors say. They added that CMS should put HealthCare.gov through a thorough security assessment that includes the infrastructure and the platform as well as all deployed software elements.
The directors also made 22 other recommendations that were too sensitive to put in the public report. They put detailed recommendations about fixing technical information security weaknesses in a separate report with limited circulation.
See also: Sebelius: We’ve built the exchange hub