The American Recovery and Reinvestment Act (ARRA) has set aside $2 billion to improve Health Information Technology (a nice summary of this part of the bill is available here), particularly to encourage the use of Electronic Health Records (EHR). There are many reasons this makes sense – why should I have to fill out the same health history forms every time I walk into a doctor’s office or hospital? It’s important to remember, however, that any computer systems designed to help solve these problems will necessarily maintain and communicate incredibly sensitive and valuable health data. Of course, anytime the government starts talking about spending a couple billion dollars on something, a whole lot of people get involved. One of the biggest conversations has been on how to decide what is a "qualified" EHR.

The definitive answer to that question won’t come until the Office of Health and Human Services releases standards at the end of this year. However, existing certification standards give some idea of how the health industry currently handles security. The Certification Commission on Healthcare Information Technology (CCHIT), which is working on certification that complies with the ARRA, has around 50 security criteria for access control, auditing, authentication and other specific security features. However, the criteria and test scripts that are used to demonstrate compliance fail to describe any way to test or audit the software that implements these features to make sure it does so securely.

One of the ubiquitous challenges in software security is to get the focus away from the features and on to the details of how the software is built. When you say the word “security”, many people think of encryption and authentication features. What encryption algorithm are you using? How big are your keys? Security features are important, but if the software is not developed securely, features alone won’t protect you.

We were here five years ago, only we were talking about financial data, not health data. In 2004, the Payment Card Industry established the Data Security Standard (PCI DSS). It wasn’t until it was revised in 2006 that any mention of auditing or testing the code was included in the standard. Starting in 2008, the PCI DSS requires source code analysis, web application scanning or an application firewall.

I hope that those in charge of the new standards will look at the process the PCI DSS went through and recognize the value of code analysis and application scanning from the beginning. To that end, I will be joining the CCHIT Advanced Security working group starting in July and plan to both call attention to lessons learned in the past and promote the official adoption of industry best practices around the development of secure software. I will also be heading up a continued effort within Fortify to help organizations keep our health records secure.

Technorati Tags: ehr hit cchit healthcare security

With services like Twitter gutting the English language leaving only 140-character shells of real communication, the ability to minimally shorten URLs for sharing has become hugely popular. However, a recent hack against Cligs has shown that URL-shortening services can be a central point of security failure.

URL-shortening services began with href="http://www.tinyurl.com">TinyURL in 2002, whose creator wanted to link to cumbersome newsgroup URLs more easily. Although early exploits against predictable hash values led to some amusing redirects, such as ‘dick’ taking users to www.whitehouse.gov, they were mostly harmless. The greatest security concern to-date has been that shortened URLs introduce an extra level of abstraction between the user and the content they wish to view. We in the security community are fond of instructing users to only visit trusted domains with a reputation for being free of malware and other nasties, but this becomes nearly impossible in the face of multitudes of nearly indistinguishable shortened URLs.

Last weekend, hackers exploited a vulnerability in Cligs, a competitor of TinyURL, to redirect millions of users to a seemingly benign, but certainly unintended, site. Although the motivation for the attack is unclear (some suggest the unusual destination may have been a mistake on the part of an attacker who wanted to redirect users to a malicious site), the implications are dire. Had the site been a launch pad for malware or a phishing attack, the more than 2 million users who were sent there against their will would have little recourse.

From a business perspective this is an interesting example of security becoming a major competitive differentiator. For companies that provide a comparatively generic service like URL shortening, distinguishing oneself from competitors can be challenging. This attack suggests that companies who strive to grow market share without focusing on security run the risk of security becoming the competitive differentiator that drives users to other, more secure, services.