Security Experts:

Examining The Security Implications of Healthcare.gov

Get Well, Healthcare.gov! Please.

After hearing about all the technical issues with Healthcare.gov, I started to think about the security implications of these sites and, with some light investigation, concluded that there’s more than functionality and availability that’s ailing Healthcare.gov. There’s significant potential for compromise.

While all websites are potentially vulnerable to attack, some of the state health insurance exchanges are probably even more so based on the public information returned when visiting the sites. Likely threats include SQL Injection, which could result in loss of patient information, and distributed denial of service (DDos) attacks, which could take down services for extended periods of time.

Unhealthy State of the Union

Is Healthcare.Gov Secure?Problems start with the fact that the federal and many of the state sites have totally different architectures and implementation technologies. This dramatically increases the available attack surface. If a hacker weren’t able to breach one, he’d have umpteen others to target. And since they are all different, they all have different vulnerabilities. It's basically a playground for attacking the government, and attackers can start with the architecture they understand best or that appears most vulnerable. 

Visiting some of these sites almost felt like I was traveling in a time machine. Several of them look like they were built a decade ago with what would now be considered nearly obsolete technologies. It’s been a long time since I’ve seen a new large-scale website built in ASP.NET. 

Unfortunately, the use of these very old development platforms makes it clear that not all the states put the right resources into building these portals. Attackers aren’t naïve to this fact. Examining the HTML and HTTP traffic details from just a few of the exchanges, I found that a ton of backend implementation details are made visible to the client—and this is prior to login. This kind of development is generally ill-advised as it lets attackers find holes in the business logic and code interactions so as to target attacks more efficiently.

What’s more, there are so many different software code bases to maintain and fix for mutually exclusive vulnerabilities.  It’s a management nightmare and, given the quality of the current implementations, something the states probably aren’t prepared to handle. 

A better plan would have been to contract a single solid company to build the software and then distribute it to the states. If a state then needed to make changes to its specific portal, it would be easy to hire in professional services from that same company.  At least that way, it's just one attack surface to manage—and not more than a dozen. 

An Apple a Day

In the context of the Web, it follows the "broken window theory." Just as broken windows in a warehouse might suggest there is no night guard on duty, signs of poorly designed websites are dead giveaways that the developers either don’t care enough to keep it clean, functional, and protected, or they just don’t have the experience to do so. 

If a warehouse has motion detectors, patrols, etc., vandalism could be kept in check. Without those things, vandalism escalates.  Buggy code is no different, and it makes for a very attractive target with minimal risk.

Bottom line is that attackers will always shoot for low-hanging fruit, and now there's plenty of it.  And to make matters worse, breaching a .gov website could bring the notoriety that many attackers seek. So not only are these sites easy targets, but they’re attractive, too.

What’s the Prognosis?

At the moment, the prognosis looks a bit grim. The sites are just too complex and too buggy for anything to provide effective protection from a sophisticated threat.  So in the short term, users are out of luck and will be forced to use a system that may likely get hacked in the near future. 

As the government works on getting the sites up and running smoothly, it would behoove them to spend some time scanning and fixing vulnerabilities in addition to functionality and availability because, as it stands, the various healthcare portals are likely to get some serious attention from malicious users. And though nothing will be able to block all of the potential holes these sites are likely to have, it’d be wise to invest in several security solutions –including Web application firewalls, intrusion deception, DDoS protection, and IDS. These can be layered on top of the existing websites and would help reduce the problem until the code can be properly fixed. 

Otherwise, consider the consequences of a breach on one of these sites, as they effectively house the personally identifiable information (PII) of a massive number of Americans.  Just imagine what would happen if a large percentage of the U.S. population’s social security numbers and personal information were leaked and sold on the black market.  What would that do for our nation’s security wellbeing?

view counter
Michael Callahan is the vice president of global product marketing for the Security Business at Juniper Networks. Prior to Juniper, Callahan was the vice president of product and solution marketing, enterprise security products group at HP. Callahan joined HP through the acquisition of TippingPoint where he served as vice president responsible for corporate, field and product marketing. Prior to joining TippingPoint, he served as vice president and chief marketing officer for CREDANT Technologies. Callahan also spent seven years with McAfee in various marketing roles. He holds a bachelor’s degree in engineering from Ohio State University and a MBA from the University of South Carolina.