With all the glaring software problems of the Affordable Care Act website, why hasn't anyone hacked it yet?
At a time when hackers like the Syrian Electronic Army, al Qassam hacking group, Anonymous and the various Iranian related hacker groups have all proven successful at targeting the websites of multinational corporations, federal governments and the military, it would seem that HealthCare.gov, with its goldmine of personal data (once it gets going), would be no match for a skilled hacker team using the standard techniques of SQL Injection, "file include" vulnerabilities, or cross-site scripting attacks -- particularly since the site already crashes on its own (indicating poor code quality to begin with). So why aren't we reading "tango down" (hacker-speak for when a site is hacked) on the Twitter feeds of one of these groups?
It's an interesting question, because it seems impossible to think that the answer is HealthCare.gov is just too secure for hackers to break in. After all, no one can write "500 million lines" of code (assuming that figure is correct) without making a few mistakes. Add to that already mammoth undertaking severe time constraints, a tight budget, overlapping responsibilities from multiple contractors, requirements to link the site to a variety of external websites (Social Security Administration, IRS, Department of Homeland Security, Veterans Affairs, etc.) and there's just no way that software vulnerabilities, which hackers can use to break in, aren't part of the mix.
Here are four reasons why we haven't seen any public disclosure of a hack on HealthCare.gov:
- Hackers Are Waiting for the Right Time -- Now may seem like the perfect time to hack the Obamacare website: after all, the website is deeply flawed, it's a sitting duck, right? In reality, a lot of hackers probably view HealthCare.gov as too much of a moving target for them to invest the time and money to go after it. What most people probably don't realize is that hacking is costly and time-intensive: before a group of hackers, particularly in organized crime rings, are willing to invest their financial resources and manpower in analyzing millions of lines of code, they want to make sure that whatever exploit they develop doesn't become obsolete the next day because of a software change. At this time, HealthCare.gov is undergoing a ton of bug fixes and software upgrades, which probably makes it risky for certain types of hackers.
- Obamacare Administrators Don't Realize It's Been Hacked-- It's equally possible that with all the disorder surrounding the HealthCare.gov rollout, technical glitches and outages that the site has already been compromised -- but the IT teams just don't realize it. True, some hackers like to brag about their exploits immediately afterwards online, but the professional hacker -- think organized crime, identity theft rings and state-sponsored groups -- prefer to stay under the radar as long as possible to get as much data as they can before anyone realizes something is awry. This happens all the time with Fortune 500s. The Obamacare exchange is one of the largest repositories of personal information in US history, so it's a potential goldmine for organized crime. When they target the exchanges, it could take a few weeks or months before the government's IT team even notices.
- Hack Attacks are Not Being Disclosed -- Unlike private companies that have to comply with strict data breach disclosure regulations, the federal government doesn't have to notify the public when it's been hacked. Given the lack of transparency so far in the Obamacare rollout, and the high political stakes involved, it's not unreasonable to think that successful attacks on HealthCare.gov won't be disclosed -- at least not right away.
- Security is Working -- The last possibility is of course that the site hasn't been hacked because the security is much better than everyone thinks. This doesn't seem realistic at all though, particularly as there have been so many flaws in the website's basic operations. If HealthCare.gov wasn't equipped to prevent duplicate registry bugs or handle anticipated traffic volumes, could it really be prepared to defend against web-based attacks like cross-site request forgery, SQL injection or command execution? It's doubtful.
Also on HuffPost: