Healthcare.gov Is A Security Disaster... And Those Working On It Knew It, And Tried To Stop Independent Security Review To Hide It

(Mis)Uses of Technology

from the well-that's-not-at-all-comforting dept

Mon, Sep 22nd 2014 7:51am — Mike Masnick

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

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

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.

Healthcare Gov Report Final 9 17 14 (PDF)Healthcare Gov Report Final 9 17 14 (Text)

Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.

Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.

While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.

–The Techdirt Team

Filed Under: cms, gao, healthcare.gov, hhs, politics, security

26 Comments

If you liked this post, you may also be interested in...

Reader Comments

Subscribe: RSS

View by: Time | Thread

Ninja (profile), 22 Sep 2014 @ 7:39am

Good idea, bad implementation? Government as always heh
[ link to this | view in chronology ]
- Anonymous Coward, 22 Sep 2014 @ 7:56am
  
  Re:
  Pretty much. This isn't exactly news.
  
  However, for those semi-competent states, they did an impressive job given the timescales required on those sites.
  [ link to this | view in chronology ]
- Michael, 22 Sep 2014 @ 8:17am
  
  Re:
  there was a good idea here?
  [ link to this | view in chronology ]
- Chris Rhodes (profile), 22 Sep 2014 @ 10:33am
  
  Re:
  "Politics is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly and applying the wrong remedies." - Groucho Marx
  [ link to this | view in chronology ]
  - Ninja (profile), 23 Sep 2014 @ 6:57am
    
    Re: Re:
    Awesome quote.
    [ link to this | view in chronology ]
Anonymous Coward, 22 Sep 2014 @ 8:01am

more corrupt criminal actions by the most transparently criminal government in recent memory
[ link to this | view in chronology ]
- Anonymous Coward, 22 Sep 2014 @ 9:19am
  
  Re:
  Numerous security people were "sounding the bell" well before the idiotic GOA put out it's report.
  
  Example of a few:
  
  John McAfee on Obamacare: ‘This is a hacker’s wet dream’
  http://dailycaller.com/2013/10/03/john-mcafee-on-obamacare-this-is-a-hackers-wet-dream-video/
  
  No security ever built into Obamacare site: Hacker
  http://www.cnbc.com/id/101225308
  [ link to this | view in chronology ]
Andrew D. Todd, 22 Sep 2014 @ 8:35am

Postal Address Bug
At least in West Virginia, the system seems to have a bug which causes it to suppress apartment numbers in customer addresses, both those in communications from the exchange to consumers, and in the information passed on to insurance companies. As you might imagine, this is productive of some confusion, especially for people who live in large apartment buildings.

I am in a moderately large building (18 units), but I get the various notices only because the regular postman knows me by name and sight. Sometimes, things are delayed, as if the relief postman didn't know what to do with them, and left them for the regular postman to handle.

I don't know about the website, per se. I have avoided using it, and have, instead, resorted to the telephone number. The clerks are of course using the website itself, but they have hopefully become experienced with its peculiarities.
[ link to this | view in chronology ]
Anonymous Coward, 22 Sep 2014 @ 8:38am

"[...] adequately restricted access to the Internet [...]"

Thereby demonstrating that they've learned nothing from Home Depot...Target...JP Morgan...or hundreds of other incidents where getting broken into was bad enough, but failure to disallow mass data exfiltration was worse.
[ link to this | view in chronology ]
Anonymous Coward, 22 Sep 2014 @ 8:42am

Deleting emails, again?
Page 7 of the second report has an administrator writing an email which explicitly states:

"Please delete this email"

Yeah, that's kind of against the rules. According to the report, she not only deleted her own emails, she instructed her subordinates to do the same.
[ link to this | view in chronology ]
- John Fenderson (profile), 22 Sep 2014 @ 9:07am
  
  Re: Deleting emails, again?
  "Yeah, that's kind of against the rules"
  
  Is it?
  
  In the private sector, companies that have a duty to retain emails do so with a special server and don't rely on the sender or recipient of the email to do the retention. They can delete anything they like, but compliance is maintained nonetheless.
  
  I would hope (against hope) that government agencies ensure compliance in a similar way.
  [ link to this | view in chronology ]
  - Anonymous Coward, 22 Sep 2014 @ 9:11am
    
    Re: Re: Deleting emails, again?
    You would hope so, yes, but apparently not.
    
    However, this practice was not followed consistently and some emails were lost as a result. While some responsive emails sent within HHS might be retrievable, CMS admitted that “[w]hile we have not identified any specific emails that we will be unable to retrieve, it is possible that some emails may not be available to HHS.”
    
    They know they don't have all the emails. They don't know exactly how many were lost or what was in them, because, well, they're lost.
    [ link to this | view in chronology ]
    - John Fenderson (profile), 22 Sep 2014 @ 9:35am
      
      Re: Re: Re: Deleting emails, again?
      Yeah, I know. It appears that the email retention plan on the part of at least some agencies is pretty flawed. The first warning sign? That people have been using their private emails for official business to avoid retention policies. Where I work, you'd be fired immediately for doing that.
      [ link to this | view in chronology ]
      - Anonymous Coward, 22 Sep 2014 @ 10:00am
        
        Re: Re: Re: Re: Deleting emails, again?
        Where if you work for the government, using private email fits right in with the first rule, don't get caught.
        [ link to this | view in chronology ]
      - Anonymous Coward, 22 Sep 2014 @ 11:27am
        
        Re: Re: Re: Re: Deleting emails, again?
        It's a warning sign, yes, but I wouldn't institute a zero-tolerance policy. In the report, some people were using private email accounts, not to avoid retention policies, but so they could sneak out information to people who were supposed to be providing oversight but were being stonewalled.
        
        "CMS officials developing the exchange refused to share vital information with senior IT officials at HHS, even while communicating directly with White House officials. Left out of the loop, HHS officials resorted to using informants within CMS to obtain crucial information, often communicating over private email."
        [ link to this | view in chronology ]
Anonymous Coward, 22 Sep 2014 @ 8:53am

HIPAA class action lawsuit
http://www.hhs.gov/ocr/privacy/

Clearinghouses are specifically named as responsible.
[ link to this | view in chronology ]
Anonymous Coward, 22 Sep 2014 @ 9:08am

GitHub
I'm kind of amused that they posted some of the code on GitHub and later removed it. Did they seriously think that, after posting it, they COULD remove it in any meaningful way? Did they think nobody would immediately re-post it?
[ link to this | view in chronology ]
Anonymous Coward, 22 Sep 2014 @ 9:18am

And they actually contemplated faking documents:

Mr. Linares then suggested creating a standard-looking ATO form, backdated to the date of the Decision Memo so that this document would appear to be the document certifying the exchange to go-live on October 1, even though that document did not exist.

If this kind of thing is in emails that *weren't* deleted, I can't imagine what was in the emails that *were* deleted.
[ link to this | view in chronology ]
Anonymous Coward, 22 Sep 2014 @ 10:22am

why not ask someone who has the hacking ability and get them to implement the security? i'll bet the security would be a damn sight better than what they have atm!
[ link to this | view in chronology ]
- Anonymous Coward, 22 Sep 2014 @ 10:41am
  
  Re:
  This isn't a bad idea, but it does presume that people with that skillset would actually agree to work on the site AND that the people would in charge would listen to them.
  
  And as we've seen, large organizations don't tend to do that: case in point, Home Depot: http://www.nytimes.com/2014/09/20/business/ex-employees-say-home-depot-left-data-vulnerable.html?mod ule=Search&mabReward=relbias%3Aw&_r=0
  
  I live near DC. I've done security work -- rather a lot of it. I have a decent skillset corresponding to a subset of that required to secure a site like this. And there is NO WAY IN HELL I would agree to work on it because it's obvious on inspection that doing so would be fast-tracking myself to hell. The management of this project is completely concerned with schedule and doesn't give a damn about security, so anyone raising security concerns is likely to be ostracized, blamed, sidelined, ignored, anything but paid attention to. Why would I want to sign up for that?
  
  I'll give my one piece of consulting advice here, and for free: folks, every system involved in this effort should be completely blocked (outbound) by two layers of firewalls running two completely different stacks (hardware, OS, software) except for carefully-enumerated known destinations specified by IP/port/protocol and traffic to those destinations should be pushed through sanitizing, logging proxies and someone should be reading those logs and this entire setup should be reviewed once a week to make sure that the enumerated list is still current and doesn't include anything that it shouldn't. (That's not everything, but it's a start, and well, I did say it was free.)
  [ link to this | view in chronology ]
Anonymous Coward, 22 Sep 2014 @ 11:42am

This is old news on the security disaster. When Obamacare failed in its implementation, a committee was set up to investigate the causes. One of them was a near total lack of security put into the program. This was ignored and buried so that news of an army of fixers were in the process of getting Obamacare on line so it would work. No mentions of the security issues surfaced again until recently.

You can't just add security into the program after the fact. It has to be built in from the ground up or there will be all sorts of holes in it. No one is wanting to go back and fix it for security issues.

I did not sign up for Obamacare for this main reason. I caught it when it was reported the first time and made very suspicious of it when it failed to become a main agenda priority. All got very quiet on that aspect. That means someone knew and purposely was covering it up. There's only one reason to do that.
[ link to this | view in chronology ]
Jake, 22 Sep 2014 @ 4:35pm

You know, I went into this ready to be slightly sympathetic to the Department of Health on this one. These reports are kind of a double-edged sword; I fully appreciate the need to hold contractors to account for sloppy work, but at the same time I can't help but think that putting a detailed report on their fuck-ups in the public domain runs the risk of giving the black-hats ideas.

But on this occasion, I think we've gone a bit past that stage.
[ link to this | view in chronology ]
- Anonymous Howard (profile), 23 Sep 2014 @ 4:10am
  
  Re:
  Any serious deployment would be preceded by a lengthy public beta testing phase, where the source code would be published and said black hats would be rewarded lavishly for every found and reported security flaw in the system.
  
  This is, of course, not the case with cronies producing low quality software for outrageous prices.
  [ link to this | view in chronology ]
Anonymous, 4 Oct 2014 @ 11:37pm

An insider government secret "PEOPLE"
It's been called Federal Government Monopoly since the civil war in the 1800's
[ link to this | view in chronology ]
Anonymous, 4 Oct 2014 @ 11:42pm

Federal Government's Monopoly since the 1800's and the civil war and total takeover of the U.S. government by the Federal Government for competition.
[ link to this | view in chronology ]
anxiclear, 3 Dec 2014 @ 1:48am

anxiclear
Any serious deployment would be preceded by a lengthy public beta testing phase, where the source code would be published and said black hats would be rewarded lavishly for every found and reported security flaw in the system.
[ link to this | view in chronology ]