HealthCare.gov: How Secure Is It Now?HHS Progress Report Cites 'Bug Fixes,' But Not Security
Since the disastrous launch of HealthCare.gov on Oct. 1, the site and its systems have undergone hundreds of software "bug fixes" and dozens of hardware upgrades to significantly bolster reliability and performance, say Department of Health and Human Services officials.
See Also: LIVE Webinar | Stop, Drop (a Table) & Roll: An SQL Highlight Discussion
But what about the security of the site and information entered by its users? Some security experts are concerned about the lack of security discussion by HHS officials in their latest progress report.
"I suspect that hundreds of bug fixes will result in sustainable performance improvements as compared to the HealthCare.gov experience in October," says Kev Coleman, who heads research and data at HealthPocket, Inc., a technology and research firm that ranks health plans. "[But] the absence of security commentary in the government announcement makes me suspect that comprehensive security testing on the new version of the website has not been completed at this time."
Among the recommendations by Coleman and other security specialists: additional security testing; ensuring adequate in-house security expertise; and a greater emphasis on application scanning for current and future apps rolled out for the site.
The HealthCare.gov website and systems support federally-facilitated insurance exchanges of more than 30 states that chose not to independently operate online insurance marketplaces under the Affordable Care Act, more commonly known as Obamacare.
Under intense Congressional and public scrutiny for weeks, Obama administration officials say that while some technical issues are still being ironed out, HealthCare.gov is ready to deliver on its promise.
A HealthCare.gov "progress report" released by HHS on Dec. 1 summarizes the technical upgrades that have been made since October, saying the site is able to support 50,000 concurrent users, or 800,000 visitors daily.
The average visit is about 20 to 30 minutes, said HHS consultant Jeffrey Zients during a Dec. 1 press briefing. Zients, former acting director of the Office of Management and Budget, was brought in by HHS to oversee the "tech surge" of experts called in to repair the Obamacare website. The prime contractor leading the technology mitigation effort is Optum/Quality Software Services Inc., a unit of United Healthcare (see: Critiquing Insurance Exchange Fixes).
The repairs so far allow about 80 percent of consumers who want to enroll in healthcare coverage via the HealthCare.gov site to do so, Zients says. That's up from only 30 percent of consumers who were able to complete their enrollment in the first weeks of the HealthCare.gov launch, says a HHS Centers for Medicare and Medicaid Services spokeswoman.
Still, even with the repairs, sometimes there won't be enough capacity for all consumers who want to enroll via the site, Zients says. So, the HealthCare.gov technical team is also deploying a new queuing system that will allow users to provide their e-mail addresses to be notified of better times to revisit the site. The system will allow those consumers to move to the top of the queue when they return to the site, he says.
While network traffic on the website over the Thanksgiving holiday was high for a typical weekend, "There was no need to deploy the queuing system," he says.
In addition to the software fixes, hardware upgrades for the site include:
- New dedicated servers for supporting the registration database, improving throughput by 400 percent;
- 12 new dedicated servers and storage units to improve database throughput three-fold;
- A doubling of capacity for website applications; and
- A five-fold increase to network firewall capacity.
Combined, the technical fixes have improved performance of HealthCare.gov by reducing response times from 8 seconds to less than 1; cutting error rates - or per-page system timeouts and failures - from over 6 percent down to less than 1; and bolstering system stability, or "uptime," from only 42 percent to over 90 percent.
Additionally, a dedicated technical response team and new management structure centered in a command center with senior CMS leadership is monitoring the HealthCare.gov website and systems in real time, 24-by-7, Zients says.
What About Security?
Reacting to the progress report, some security experts say while the fixes will help improve the reliability of the site, data security needs to become a major government focus.
Under testimony to Congressional subcommittees, officials from HHS and vendors involved in the HealthCare.gov roll-out acknowledged that end-to-end security testing of all integrated system components was not completed before the Oct. 1 launch of the site. Critics say the absence of that thorough testing leaves consumer data vulnerable to potential breaches, and that new coding and fixes to the HealthCare.gov site during its repair could introduce additional security flaws, unless they too are risk assessed.
"The need for security testing depends on the fix or fixes implemented," says Coleman. For instance, "a spelling correction, while technically a software defect, does not require security testing after the correction is applied."
However, he adds, "Programming changes, ranging from script changes to new input fields and other modifications of functionality, inherently risk the introductions of new software problems and security vulnerabilities."
Independent security consultant Brian Evans says HHS needs to pay new attention to in-house security expertise and application security.
"It's not uncommon for organizations to treat application security as an afterthought and segregate the security experts from the development groups," Evans says. "HHS should ensure they have security subject matter expertise in-house to train developers. Security expertise needs to flow from the experts to the staff members who are developing and maintaining the product," he says.
Additionally, as mitigation work continues, "Web application security scanning is also a critical component to HHS' ongoing improvement processes," Evans says. "HHS should evaluate how to best utilize in-house products or third-party services to provide web application security scanning capabilities during development and for its production applications."
Finally, Evans suggests HHS take time to investigate its security pain points before determining solutions. "They must assess their practices and identify the root cause of their problems," he says. "Upon initiating any change initiative, HHS must possess the discipline to stay the course and avoid reverting back to its previous practices that created the website problems in the first place."