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

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

White House Going With 'Security By Obscurity' As Excuse For Refusing To Release Healthcare.gov Security Details

from the hackers! dept

These days, in the computer security world, it's pretty well known that if you're relying on security by obscurity, you're not being secure. Somehow that message has not reached the techies working on Healthcare.gov. I guess it shouldn't be much of a surprise, given what a disaster the rollout of that site was, but everyone was claiming that the whole thing was under control these days, since real techies had been brought in to fix things. In fact, everyone was so happy with Mikey Dickerson's miraculous saving of the program that the White House set up a special US Digital Service for him to lead, allowing him to save other US government projects from near certain disaster.

But when the Associated Press filed a Freedom of Information Act request to find out how Healthcare.gov was handing its security it got rejected because, according to the White House, it might teach hackers how to break into the system:

In denying access to the documents, including what's known as a site security plan, Medicare told the AP that disclosing them could violate health-privacy laws because it might give hackers enough information to break into the service.

"We concluded that releasing this information would potentially cause an unwarranted risk to consumers' private information," CMS spokesman Aaron Albright said in a statement.

Of course, that suggests that merely revealing the security steps the site has taken will reveal massive vulnerabilities -- and, as most people with even the slightest bit of technological knowledge know, if that's the case, then it's likely the site has already been compromised. If revealing the security setup for the site will leave it open to being hacked, we should probably assume the site was hacked a long, long time ago. If they're deploying security right, merely telling the world what they're doing wouldn't increase the risk. The fact that they're afraid it will suggests that the security plan is dangerously weak.

Filed Under: foia, healthcare.gov, security, security by obscurity
Companies: associated press

Tech Company Officials Meet With Obama Officially About Healthcare.gov, But Focus On NSA Surveillance Instead

from the good-to-see dept

It came out yesterday that President Obama was scheduled to meet privately with a group of "tech" execs officially about the status of the healthcare.gov website. However, as some expected, it appeared that the meeting focused much more on the NSA's overreach and the need for reforms. While somewhat disappointing that the meeting was held privately, it looks like the execs made it clear that the NSA surveillance efforts were doing a lot more harm than good and something needed to change.

Schmidt, of Google, opened the meeting and laid out industry officials' concerns. Obama seemed sympathetic to the idea of allowing more disclosure of government surveillance requests by technology companies, according to a tech industry official who was briefed on the meeting. The official asked to remain anonymous because the meeting was private.

Mayer, the Yahoo! executive, brought up concerns about the potentially negative impact that could be caused if countries, such as Brazil, move forward with legislation that would require service providers to ensure that data belonging to a citizen of a certain country remain in the country it originates, the official said.

That would require technology companies to build data centers in each country — a costly problem for American Internet companies, the official said. The White House noted in a statement after the meeting that the group discussed the "economic impacts of unauthorized intelligence disclosures."

We've been saying since the Snowden leaks first came out that the tech industry needed to be a lot more vocal about how bad the NSA's actions are for pretty much everyone, so it's good to see at least some effort to continue to push that story. Of course, the list of attendees also includes AT&T's Randall Stephenson -- and AT&T has been one of the companies most complicit in the NSA's activities, something the company refuses to talk about, and unlike the actual tech companies, seems completely unwilling to address.

Filed Under: barack obama, eric schmidt, healthcare.gov, marissa mayer, nsa, nsa surveillance, randall stephenson, surveillance
Companies: at&t, google, yahoo

Mike Rogers Is Now Opportunistically Concerned About The Privacy Of Americans

from the both-sides-of-mouth-completely-operational dept

Mike Rogers, who once famously stated that no privacy violations occur if no one finds out their privacy has been violated, is now very concerned about Americans' privacy. Of course, this is because he's in an adversarial role, rather than playing defense.

As we're all aware, the much-anticipated and highly-touted national healthcare website made its very shaky debut recently. Immediately inundated by millions of Americans looking for a better deal on healthcare, the website performed with all the reliability of a dollar store electronic device, falling completely apart at the slightest touch.

Much has been made about the roll out and subsequent failure of a website that was supposed to be the crowning jewel of the Affordable Care Act. Health and Human Services Secretary Kathleen Sebelius was called before a Congressional hearing to field questions and complaints from legislators who wanted clarification on what went wrong and, more importantly, whom to direct their irritated constituents towards.

Mike Rogers was on hand and delivered a longish rant/question about the live roll out of untested code. While there are some good points in his query/beration (i.e., hot fixes are insecure, the site is a failure), Rogers suddenly felt compelled to defend something he's taken a laissez faire approach to in recent months: the privacy of Americans.

Rogers, who questioned Health and Human Services Secretary Kathleen Sebelius during a hearing last week, has taken issue with concerns about the safety of Americans' healthcare information.

"What was really shocking to me is even by their own words, they admitted that there was a high degree of risk when they offered the website to go public, they never told anybody about that. They said that they think the risk was acceptable. But their information wasn't at risk, American people's information was at risk," he said.

Rogers is upset that all the personal information people willingly submitted to a barely functioning government website might be exposed or put at risk by the agency's continual code fixes, almost all of which goes untested for security flaws before being rolled out.

So, now Rogers is worried about possible privacy issues. He doesn't want to protect Americans' data from government intelligence agencies, but he wants to make sure it doesn't fall into the hands of other Americans or foreigners who might exploit the personal or financial data. Kudos for that I guess, but its not as if his favored intelligence community has been extra careful with what it's collected.

Sure, it may be locked down tight in occasionally not-on-fire servers in Utah, but it's hardly secure. Any number of American analysts have access to that data, with little more than some forced-into-practice minimization procedures and its defenders' assurances that NSA employees are patriotic, virtuous Americans guarding it from abuse.

Not only that, but what the agency collects is far more inclusive than what Americans are volunteering to the government site. Let's not forget that the TSA is already probing into Americans' personal and financial data just to determine whether or not they can travel within the country with a minimum of security molestation. So, it's not as if this information isn't already in the hands of several government agencies already -- with all the risks that entails.

But to claim this is a problem but not the NSA's massive data collections is a bit rich. That information has been abused in the past and, worse, it's been freely shared with other countries in unminimized form. Protecting the privacy of Americans isn't something you get to do part time, Rep. Rogers, but I suppose if no one finds out their personal data has been leaked all over the net by a faulty .gov website, then it's not really a problem, is it?

Filed Under: healthcare.gov, mike rogers, privacy

Contractors Who Built Healthcare.gov Website Blame Each Other For All The Problems

from the nice-try dept

With all the problems associated with the Healthcare.gov rollout, a bunch of fingers (including ours) pointed at the usual list of government contracting cronies who built the thing. The deal was done under an existing contract (so no open bidding) and involved the same "usual suspects" who have been connected to a number of other large government computer systems debacles. Not included anywhere in the list were companies with experience building large-scale web services -- which you'd think would be helpful here. However, in testimony before Congress, the contractors are insisting that it's not their fault. CGI Federal was the main contractor behind the site, and Cheryl Campbell, a senior VP from the company, is in charge of trying to point fingers elsewhere, mainly at the Centers for Medicare and Medicaid Services (CMS), which CGI Federal says was in charge of the actual building of the site.

CMS serves the important role of systems integrator or "quarterback" on this project and is the ultimate responsible party for the end-to-end performance of the overall Federal Exchange.

Basically: it's the government's fault. We just build the damn thing. If they didn't tell us to build the right thing, or test it properly, well, it's their fault. Also, someone else we won't name is really at fault:

Another contractor was awarded the contract for the Data Services Hub portion of the Federal Exchange.

Oh, and also another unnamed contractor:

The first set of issues for users dealt with the enterprise identity management (or EIDM) function provided by another contractor, which allows users to create secure accounts.

Of course, it's not too difficult to figure out who the "other" contractor is. Because it's on the panel too. QSSI built the Data Services Hub and the "EIDM" functions mentioned, and QSSI is owned by Optum, whose executive vice president Andy Slavitt is testifying as well. And, you know, it's not his fault. First, he insists that the Data Service Hub worked splendidly throughout, no matter what anyone else might say. EIDM, of course, is having some trouble, but that? Why, other vendors are to blame there too:

It is relevant to note that the EIDM tool is only one piece of the federal marketplace’s registration and access management system, which involves multiple vendors and pieces of technology. While the EIDM plays an important role in the registration system, tools developed by other vendors handle critical functions such as the user interface, the e-mail that is sent to the user to confirm registration, the link that the user clicks on to activate the account, and the web page the user lands on. All these tools must work together seamlessly to ensure smooth registration

In other words, if only those other vendors did their job right, the whole thing would work much better. Oh yes, also someone (nameless) decided to change the specs at some late date:

It appears that one of the reasons for the high concurrent volume at the registration system was a late decision requiring consumers to register for an account before they could browse for insurance products. This may have driven higher simultaneous usage of the registration system that wouldn't have occurred if consumers could "window shop" anonymously.

The final note, going back to CGI Federal, is to remind Congress that building websites is really hard.

Unfortunately, in systems this complex with so many concurrent users, it is not unusual to discover problems that need to be addressed once the software goes into a live production environment. This is true regardless of the level of formal end-to-end performance testing -- no amount of testing within reasonable time limits can adequately replicate a live environment of this nature.

That's true to some extent, but it doesn't excuse many, many of the overall problems with the system, which did not appear to be built with any recognition of how to build a high-traffic transactional website. While CGI Federal would like to point fingers at everyone else, it was its name on the contract, which it received through questionable means, and it should take at least some responsibility for it. Perhaps, if it was so "complex," it shouldn't have taken on the job.

Filed Under: blame, contractors, healthcare.gov
Companies: cgi federal, optum, qssi

Petition Launched To Get The White House To Open Source Healthcare.gov Code

from the should-have-done-it-before dept

After the disastrous technological launch of the healthcare.gov website, built by political cronies rather than companies who understand the internet, there has been plenty of discussion as to why the code wasn't open sourced. At that link, there's a good discussion from On the Media, with Paul Ford, discussing what a big mistake it was that the government decided not to open source the code and be much more transparent about the process. It discusses the usual attacks on open source and why they almost certainly don't apply to this situation.

And, now, a "We the People..." petition has been launched, asking the White House to open source the code to Healthcare.gov:

Release to the open source community the source code to healthcare.gov, specifically all code written by CGI Federal.

It is believed that the enrollment issues with healthcare.gov are likely due to poor coding practices in components that are unavailable to the world's development community to evaluate. Code funded by taxpaying citizens should be made available to the general public as government funded development is generally public domain software. Please release the code so we may help fix any found issues.

Of course, there are a few issues with this. First of all, while things created by government employees is automatically public domain, works created by contractors is not. So while conceptually we can argue that the code should be open sourced, it's not required by law. Second, and more importantly, it's a lot harder to take proprietary code and then release it as open source, than it is to build code from the ground up to be open source (and it's even more difficult to make sure that code is actually useful for anything). Indeed, if the code had been open sourced from the beginning, perhaps they wouldn't make embarrassing mistakes like violating other open source licenses.

By this point, open sourcing the code isn't going to fix things, but if more attention is put on the issue of closed vs. open code in government projects, hopefully it means that government officials will recognize that it should be open source from the beginning for the next big government web project.

Filed Under: healthcare.gov, open source, white house

Healthcare.gov Violates Open Source License

from the this-could-be-interesting dept

With all of the other problems associated with the launch of the Healthcare.gov website, you'd think that some of those expensive government contractors would understand open source licensing and how it works. Apparently not. It would appear that the site uses DataTables, which is a free and open source plug-in for jQuery, allowing for much better data handling and display. But, as most people who understand open source software recognize, there are often conditions for such usage, including the need to retain the license information in the software. DataTables is available as both a GPL v2 and BSD license, and even the DataTables team notes that basically all you have to do is "keep the copyright notices in the software."

But Healthcare.gov did not do that.

Oops. While it's not exactly "blatant software piracy" as some consipiracy-theory sites are claiming, it is a violation of the license, and thus, a form of copyright infringement. SpryMedia, the company behind DataTables has responded by saying it's "extremely disappointed". While the almost always sensationalistic Russia Today is claiming that SpryMedia "plans to sue" that doesn't seem to be supported anywhere else. So far, there's just a tweet saying that it's "excellent to see DataTables being used" and that "leaving the copyright header in place isn't too much to ask :-)."

Open source developers don't often sue over misuses of their licenses, though it does happen. Of course, a better solution than going to court would be for the government to fix the mistake, make a public statement about this and, potentially, donate to DataTables.

Filed Under: copyright, datatables, healthcare.gov, license, open source
Companies: sprymedia

Why Healthcare.gov Sucks? Because They Hired Political Cronies, Not Internet Native Companies To Build It

from the you're-doing-it-wrong dept

There's been plenty of talk lately about just how screwed up the launch of Healthcare.gov has been. While any massively large-scale internet launch is likely to suffer some problems, the level of disaster on this particular project has been quite impressive. This has led some to wonder why this happened, especially given the reputation of President Obama's "web-savvy" campaign team. The answers aren't too hard to figure out, of course. First off, the campaign team is quite different from the team implementing this -- which was handled by the Department of Health and Human Services. But, more importantly: it appears that the federal government basically handed this project over to the same crew of giant government contractors, who have a long history of screwed up giant IT projects, and almost no sense of the "internet native" world.

The Sunlight Foundation (link above) figured out the list of contractors who worked on the site, and noted that the big ones not only are well-known DC power-player insiders, but they're also big on the lobbying and political contributions side of things. You've got companies like... Booz Allen Hamilton, famous for promoting cyberwar hype and employing Ed Snowden. There's defense contracting giant Northrup Grumman. Then there's SAIC -- which I can't believe can still get government business. This is the same firm that famously was given a $380 million contract to revamp the FBI system, on which it went $220 million over budget, and then saw the entire system scrapped after it (literally) brought some users to tears, and the FBI realized it was useless in fighting terrorism. SAIC is also the company that NYC Mayor Bloomberg demanded return $600 million after a city computer project (budgeted at $68 million) actually cost $740 million. SAIC has a long list of similar spectacular failures on government IT projects.

As you look down the list put together by the Sunlight Foundation, it's all companies like this: giant monstrosities which are simply tied in closely with the government. All the large consulting firms are listed: Accenture, Deloitte, PricewaterhouseCoopers, McKinsey. What's missing? Basically any company with even the slightest smidgen of experience building and maintaining large-scale, public-facing web-based apps. The list has no "internet native" companies.

Many, many years ago, I worked for an e-commerce startup here in Silicon Valley, and I ended up (sort of by default) in charge of trying to open up the government market for what we were doing. It involved meeting with a slew of all-too-slick, ex-politician, ex-military "consultants" with no technical knowledge whatsoever, who, for $15k to $25k/month retainers plus a (large) cut of any deal, would drink hard liquor and promise to "connect" us with big companies with government connections, and then help us sneak past the government bidding process to get no-bid contracts. It was an eye-opening experience that highlighted for me that getting government contracts in the tech world was very much about who you knew, rather than any actual knowledge, skills or experience. While this was quite a long time ago, it would appear that little has changed.

Filed Under: cronies, government contractors, government it, healthcare.gov
Companies: booz allen hamilton, mckinsey, northrup grumman, saic