Keep the snakes at bay

Recently, a state agency announced that their site had been compromised by computer hackers. The attackers left a ransom note on the web site claiming that they had captured 8.3 million patient records and 35.6 million prescriptions. The attackers also claimed to have created a password-protected, encrypted backup of the data.  For a mere $10 million the miscreants offered to “gladly send along the password.”


To quote the great philosopher Morpheus, “Welcome to the desert of the real.”


Warnings about security flaws in web applications have been ignored by most for as long as web applications have existed. A small contingent of evangelists, including folks in our own HP Application Security group, have consistently warned about the existence and exploitability of these vulnerabilities.


The U.S. Department of Health and Human Services Inspector General, in a report dated October 27, 2008, stated that “limited actions” by the Centers for Medicare & Medicaid Services (CMS) have “not provided effective oversight or encouraged enforcement of the HIPAA Security Rule by covered entities.” Voluntary compliance (an oxymoron?) was a key problem cited for this lack of effectiveness.


Some suggest that healthcare records simply should not be made available via the public internet. That’s a lot like saying people shouldn’t eat greasy cheeseburgers. It may be true, but it’s not gonna stop.


The first step to understanding the real problem is recognizing that the availability of information, even healthcare information, is a growing part of our everyday lives. You wouldn’t put sharp kitchen knives on the floor where your toddler could reach them, would you? If you did do something this dangerous, would you then punish the toddler for cutting himself?


We need to stop wondering why snakes bite and start wondering what we can do to put a healthy distance between our toes and the snakes.

The federal government has enacted new, strong provisions to begin forcing developers of healthcare management software applications to provide notice of breaches to the medical providers they serve, who can in turn notify the affected individuals. This is a huge step, because in the past HIPAA compliance was a burden borne by the medical providers. If they aren’t notified of the breach, nobody is the wiser…until somebody finds out at the pharmacy that all of their pain prescriptions have already been filled by some nice young gentleman.

Now that software application developers are held accountable for security, I believe we’ll start to see some distance between us and the snakes. By the time these software developers figure out they need a plan for their web application security, they’ll find out HP has been there all along.


Ken Swinney
R&D Group Manager
HP Application Security Center

Comments
(anon) | ‎05-08-2009 03:58 PM

How can we improve the knowledge of those creating the applications and make secure coding practices part of the development process? Many companies aren't willing, especially in these financially uncertain days, to spend the extra time/effort/capital to make certain that common and easy exploits are covered even though the small expense now will save them a significant amount in the future. Can you tell us about some HP security (especially web security) products that are used to review, test and simulate attacks on programs?

(anon) | ‎05-12-2009 08:55 PM

It's a great question, Anthony.  The fact that you're asking the question is a great start.  We've found that the best web application security methodologies begin with being intentional from the very beginning of the app lifecycle.  The short answer is that a great start to a better development process is to educate developers on the implications of security threats.  Most shops start with stressing the importance of input validation.  It sounds simple, but if you properly validate all user inputs into your apps, it's a great start.  You should give a lot of thought to whitelisting (if your app can handle whitelisting) good inputs, rather than blacklisting bad inputs.  In some cases this isn't feasible, but it's a lot easier to maintain long-term.  Another important best practice is to use parameterized queries.  Most SQL Injection attacks can be avoided with this single practice.  This has the added side benefit of improving your app's use of the procedure cache in your SQL Server.  I realize it's tough to get budget for anything these days, including security tools, but I'm reminded of Thomas Jefferson who said, "If you think education is expensive, try ignorance."  This is most definitely true of security.

(anon) | ‎05-14-2009 07:58 PM

"...Snakes, why does it always have to be Snakes?" This issue was borne from multiple bad desicions. First, remote users/admin delete access was left in place for the back up solution implimented by the VA Health Dept. Not to mention the practice of off site and off line storage of said back up copies. Second, the entire web presense was swiss cheese of security. If the infrastructure was not protected, the same will be for the front end. But in the end, you only know how well protected you are if you have survived an attack.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.