The news out of Washington D.C. this week was that the Government’s troubled Healthcare.gov web site isn’t just dysfunctional – it’s also insecure. This, after an independent security researcher named Ben Simo found an exploitable vulnerability on the U.S. Government’s Healthcare.gov portal that would allow a remote attacker to gain access to applicants’ accounts, according to reports on CNN and The Washington Post.
In other news: the sun rose in the East every day this week.
I’m joking – but just barely. In truth, the existence of a major and exploitable security hole shouldn’t be surprising to anyone who has been following the debacle (the Obama Administration’s wording – not mine) that is the Healthcare.gov rollout. Given the way this project has gone, we should be expecting many more.
As we now know, the massive project was woefully behind schedule and over budget as of this summer. That prompted internal warnings about the feasibility of the site’s October 1st “go live” date, especially after test versions of the site failed critical benchmark tests prior to its launch on October 1st. And, as you know from reading this blog: security flaws are one of the most visible (and dangerous) byproducts of ill-conceived application design and hasty development.
In the case of healthcare.gov, Mr. Simo discovered that the site did a poor job securing personally identifiable information submitted to the site – frequently parsing information like the user’s e-mail addresses and password reset information as part of dynamically generated links (URLs) sent to users in e-mails. Healthcare.gov also chose not to expire password-reset codes issued to users, meaning they could be used repeatedly as part of account takeover attacks.
Why would a site like healthcare.gov go out of its way to funnel session information to for-profit web analytics firms? It’s not clear – and the Department of Health and Human Services (HHS) hasn’t offered any explanation. One guess is that the calls to DoubleClick and other services were a byproduct of code re-use on the part of the firms hired to develop the site. In this scenario, software modules developed for other, commercial web sites were repurposed for healthcare.gov, including call-outs to the web analytics providers.
Those kinds of oversights (that is: “Hey, why are we sending session data to DoubleClick?”) would typically be identified and addressed as part of a robust testing and quality assurance phase. But healthcare.gov, at least in its current incarnation, never got that kind of vetting. Instead, the picture that emerged from leaked government memos is of a development project gone badly off course, with security tests conducted even while development and “hot fixes” were ongoing – which is kind of like trying to repair your car while driving it at the same time.
Now, in a pattern that is troublingly familiar, the contractors and government agencies responsible for the project are doubling down on their past mistakes: committing to an “end of November” deadline just four weeks hence that is as unrealistic as the October 1st deadline was for a massive online exchange that only began to take form in August.
What’s the difference? Supposedly, an Obama Administration orchestrated “technology surge” that will put some of the nation’s best and brightest on the job to fix healthcare.gov.
But a month is barely enough time to come up to speed with how a project as massive as a national healthcare exchange works – forgetting about actually fixing it. Nobody I’ve spoken with who has ever worked on a software project believes that the end of November deadline is realistic, or that four weeks will bring much improvement to a site built on such shaky foundations.
And, with the focus of the media on the site’s availability and usability, security is likely to be a low priority – at least in the “surge” phase, as contractors rush to get healthcare.gov up and running. What will the consequence be? If healthcare.gov does stand up by late November (and that’s a big “if”), expect a flood of ugly security flaws to bubble up in the subsequent weeks as citizen-developers scrutinize the site’s user security (authentication) and session security, including the handling of applicants’ personal data.
A likely source of problems will be the site’s interactions with any of the scores of public and private back end servers needed to assemble insurance estimates for applicants and calculate the (many) federal deductions they are entitled to.
I like being right. But in this case, I really hope I’m wrong. My larger hope is that the mess that is healthcare.gov – security and privacy issues or no - finally changes the Federal Government’s utterly broken and disreputable process for developing large scale software projects. As many articles have pointed out, healthcare is just the latest in a long string of multi-billion dollar software lemons, from an FBI case tracking system to air traffic control terminals. In many cases, the cost for the government and its contractors to develop a non-working system was many times what private sector firms spend to develop robust, functional platforms that perform many of the same tasks. If healthcare.gov is viewed, years from now, as the last in that string of lemons, then we can at least have squeezed a bit of lemonade from the whole affair.