Healthcare.gov Is A Security Disaster… And Those Working On It Knew It, And Tried To Stop Independent Security Review To Hide It
from the well-that's-not-at-all-comforting dept
We’ve written before about how problematic the technology is behind the federal healthcare.gov website, pointing out that the federal government hired political cronies rather than web development experts to build it. There was an effort to open source the code, but after the feds put the code on github, they removed it after people started pointing out just how bad it was. Then, just about a month ago, we noted that the government turned down a FOIA request from the Associated Press concerning the site’s security practices, arguing that it might “give hackers enough information to break into the service.” As we noted at the time, if revealing the basic security you have in place will give hackers a road map to breaking into the site, the site is not secure at all.
A damning new report from the Goverment Accountability Office (GAO) more or less confirms this is the case. This is further backed up by an even more astounding “Behind the Curtain of the Healthcare.gov Rollout” released by the House Oversight Committee. To be fair, the GAO is non-partisan and known to be even-handed and fair. That’s not always the case with Congressional committee reports. Still, the two are worth reading together. The level of mess behind the project is rather astounding and it appears that the site still is not particularly secure, which obviously explains the refusal to do that FOIA release.
Here’s the GAO basic summary of the security situation for the site:
While CMS has 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 remain both in the processes used for managing
information security and privacy as well as the technical implementation of IT
security controls. CMS took many steps to protect security and privacy, including
developing required security program policies and procedures, establishing
interconnection security agreements with its federal and commercial partners,
and instituting required privacy protections. However, Healthcare.gov had
weaknesses when it was first deployed, including incomplete security plans and
privacy documentation, incomplete security tests, and the lack of an alternate
processing site to avoid major service disruptions. While CMS has taken steps to
address some of these weaknesses, it has not yet fully mitigated all of them. In
addition, GAO identified weaknesses in the technical controls protecting the
confidentiality, integrity, and availability of the FFM. Specifically, CMS had not:
always required or enforced strong password controls, adequately restricted
access to the Internet, consistently implemented software patches, and properly
configured an administrative network. An important reason that all of these
weaknesses occurred and some remain is that CMS did not and has not yet
ensured a shared understanding of how security was implemented for the FFM
among all entities involved in its development. Until these weaknesses are fully
addressed, increased and unnecessary risks remain of unauthorized access,
disclosure, or modification of the information collected and maintained by
Healthcare.gov and related systems, and the disruption of service provided by
That failure to restrict access to the internet was for test servers, one of which got infected with malware recently.
But the really damning story is that CMS, the Centers for Medicare and Medicaid Services, which was in charge of the product, seemed totally incompetent throughout this process — and directly chose to kill off an independent security review by MITRE, knowing the results would be bad and that they might get out:
Once MITRE completed their September Security Assessment, Mr. Schankweiler?s FFM
development team was unhappy with the report and sought to have it changed. On September
26, 2013, Darren Lyles, one of the IT security officials assigned to the FFM development team,
wrote Ms. Fryer:
The Draft SCA [security control assessment] Report has been called into question
by CGI [primary contractor building the FFM] and CIISG [Consumer Information
Insurance Group, the team within CMS that works with contractors to develop the
FFM and other Healthcare.gov components] Stakeholders. There are assertions
made in the report that are deemed to be erroneous and misrepresentative of what
actually occurred. I have attached the report that has been commented on by CGI
and would like to submit this for your review.
Michael Mellor, Ms. Fryer?s deputy, responded to Mr. Lyles: ?Keep in mind ? that the purpose
of the SCA is to provide an independent assessment of the security posture of a system. As part
of that independent assessment, the maintainer of the system likely will not agree with all of the
findings and the SCA report.?
Mr. Schankweiler, Mr. Lyles? superior, then responded to Mr. Mellor, insisting that the
report should be reviewed by senior CMS officials and worried the report would be seen by
others outside CMS: ?We need to hit the pause button on this report and have an internal meeting
about it later next week. It is important to look at this within the context of the decision memos
and ATO memo that is going up for Tony [Trenkle, CMS Chief Information Officer] and
Michelle [Snyder, CMS Chief Operating Officer] to sign.? Mr. Schankweiler then wrote the
report was ?only partially accurate, and extremely opinionated, false, misrepresentative, and
inflammatory.? Mr. Schankweiller noted that ?It is very possible that this report will be
reviewed at some point by OIG, and could see the light of day in other ways.? Mr.
Schankweiler offered to ?look at the report from the government perspective and provide …
On October 7, 2013, the lead security tester for MITRE, Milton Shomo, wrote Jane Kim,
a CMS official on Ms. Fryer?s EISG team, ?CCIIO [Centers for Consumer Information and
Insurance Oversight, one of the divisions at CMS responsible for running the exchange] and CGI
Federal had some issues with some of the information in our Marketplace ? draft SCA report
from the assessment we did in August and September. MITRE stands behind everything in our
report as an accurate description of the assessment.
There were a number of other similar problems, but it becomes clear that choices were made for political reasons, rather than technological or security reasons.