It is by any objective measure one of the most talked about websites of the year. But is healthcare.gov, the central portal into the new health care exchanges setup under the Affordable Care Act, secure?
Unfortunately, few know the answer to that question. Of course, it’s easy to find somebody with a political ax to grind who will call the website a cyber-criminal’s dream come true. And if you listen solely to the administration and the private contractor that developed the site, the only thing they will tell you is, like all websites designed to handle millions of transactions, healthcare.gov is experiencing “growing pains.”
But FedScoop research, including interviews and email exchanges with a half dozen cybersecurity experts, shows that, yes, there are real concerns about the security of the personal information people must enter before a determination can be made about their eligibility for coverage. But claims that the exchanges are amassing volumes of personal information in one centralized database without any protections are simply not true.
In fact, the engine behind healthcare.gov, known as the Data Services Hub, was designed by the Centers for Medicare & Medicaid Services specifically to avoid storing personally identifiable information in one central location. In reality, the Hub, simply accepts data entered by visitors to the website (either a state-run marketplace portal, the federal portal setup for those states that have opted-out, or a so-called third-party “navigator”) and compares that data against information already contained in seven existing federal and state databases, such as those maintained by the Social Security Administration, Internal Revenue Service, Department of Homeland Security, and the Department of Veterans Affairs, among others.
“The Hub was specifically designed to minimize security risk by developing a system that does not retain or store Personally Identifiable Information,” states the fact sheet published by the Centers for Medicare and Medicaid Services.
This doesn’t mean that healthcare.gov is 100 percent secure. Far from it. One of the biggest concerns security experts have about the website is the speed at which the highly complex, transaction-oriented site was developed and the last-minute nature of the security audits and certifications. In fact, the Department of Health and Human Services own inspector general in August reported it could not complete a review of the steps taken to identify and plug vulnerabilities in the Hub because the contractor’s final report was not due until only 10 days before the site went live Oct. 1.
The Centers for Medicare and Medicaid Services said in a statement the system received its final authorization to operate based on an independent security controls assessment Sept. 6.
But that assessment isn’t enough to allay the fears of some cybersecurity experts, who point to the IG report, which found the Centers for Medicare and Medicaid Services had to postpone the date of the security controls assessment by two months so performance stress testing could be completed. And everyone knows how well the performance stress testing worked.
“Given the problems with performance and availability so far, I’m concerned that there will be security flaws that allow unscrupulous people or organizations to gain access to the personal information of a lot of private citizens,” said Dwayne Melançon, chief technology officer at Tripwire. “It is time to insist on tangible, objective data to measure the effectiveness of security controls around this critical process and the data involved in the process. That includes analyzing workflow, roles and responsibilities, data security — both for data in motion and data at rest — and gaining a clear understanding of how the integrity and confidentiality of this data is being monitored and enforced.”
FedScoop reached CGI Federal, the government IT contractor responsible for the site, but did not receive a response by press time.
Vulnerabilities
One of the major vulnerabilities in the way the system is currently set up is the multitude of avenues people have to sign up for coverage, said Christopher Budd, threat communications manager at Trend Micro.
There’s no “standardized, single authoritative site,” he said, referring to the fact that healthcare.gov is running exchanges in 36 states and the remaining 14 states are running their own. Adding to the confusion is an untold number of third-party sites called “navigators” that are supposed to help people through the process.
Budd fears a spike in fake sites aimed at identity theft. “This is a perfect environment for identity thieves and other criminals to put together bogus sites to get personal information they can use or sell on the digital underground,” he said.
“There is one big architectural vulnerability that comes from seven systems being connected into a single point of access,” said Matthew Standart, director of threat intelligence at HBGary, a subsidiary of ManTech International Corp. “The attacker also now has a single point of access to the data as well.”
Dr. Bill Curtis, chief scientist at CAST, a software quality analysis firm, and the director of the Consortium for IT Software Quality, points to recent examples of major data thefts that leveraged well-known software vulnerabilities as a potential reason for concern with a major government website plagued by glitches and incapable of handling large numbers of transactions.
“The reason we still have these common vulnerabilities is because software developers haven’t been trained in how to build secure software,” Curtis said. “You certainly hope that the people who built [healthcare.gov] built all of the appropriate safeguards and validations into the system. The problem that worries me is they got into a rush to finish the site.”
The other major concern for Curtis stems from the performance issues healthcare.gov has experienced to date. “The performance issues were really problems that a good website developer knows to avoid,” he said. “That suggests that the developers were not as sophisticated as you would expect to find at high transaction sites like eBay, Google or MSN.com.”
There may be something to Curtis’ analysis, according to a recent blog posting by Nidhi Shah, who works on research and development for HP’s Web Security Research Group. Shah analyzed some of the code behind healthcare.gov and found three specific technical issues he characterized as “red flags” that would likely encourage cybercriminals to attempt to exploit the site.
According to Shah, healthcare.gov uses an HTML 5 header that could expose the site to serious threats like Cross-Site Request Forgery.
“Failing to restrict cross-domain communication can allow a malicious site to send requests, including POST requests, to healthcare.gov on victim’s behalf and gain access to his health records, and possibly enough information to steal his identity,” Shah said.
Shah also said the site lacks protections against “clickjacking,” an attack where the attacker deceives a user into clicking on a hidden element on a Web page instead of the intended visible element. “To our surprise, healthcare.gov does not deploy any defense,” Shah said.
Finally, healthcare.gov uses cookies to maintain users’ site history and user identification. And while Shah could not determine if the user identification is also used as a session identification, the lack of an HTTPOnly header attribute and secure flags for cookies, could allow access to personal information.
“A user’s search history or visiting history could reveal sensitive information, such as the possible health issues, income level and marital status,” Shah said. “Healthcare.gov should employ these flags to protect cookies.”
“You worry,” Curtis said. “If they made those kind of mistakes, what other mistakes could they have made in the area of security. It’s hard to know until something happens. But the issue now is to do penetration testing and analysis of the code.”
