Pratum Blog

Under ARRA, covered entities and their business associates are now compelled to disclose breaches of protected health information (PHI) to the Secretary of Health and Human Services (HHS). If the breach involves 500 or more individuals the notification must be immediate. If less, a log must be kept of all breaches and submitted annually to HHS. HHS will then post on their website a list of all organizations which had a breach, the nature of the breach and the number of people involved.

The organization must also attempt to make individual notifications to those affected. If the breach involves 500 or more individuals or just TEN individuals for whom there is no current contact information, the notifications must also include broadcasts through mass media in the markets where people are affected.

The one get out of jail free card that was granted is for PHI which is rendered unusable, unreadable or indecipherable. In the past many organizations believed they could anonymize data and it would be safe. Typically though in order to truly anonymize data you have to strip out so much relevant information that the remaining data is no longer useful for any sort of analytical purposes. So…unusable is out.

What about unreadable and indecipherable? Encryption seems to be our only real option at this point. HHS will soon be releasing the final guidance on this topic but I don't expect anything shell shocking. There has been lots of press over the past few years regarding the encryption of data both at rest and in motion. I'm a big proponent of both. Should you lose a laptop and the hard drive is fully encrypted, you're covered. No breach. If someone attacks a database server and your database tables are encrypted you're probably covered there too. However, if your web application which accesses the database is breached, you are up that proverbial creek without a paddle.

At some point in every process or application we need data to be readable. Otherwise why would we need it in the first place? By encrypting data in motion or at rest all we are doing is funneling the attacks to one focal point. Our applications. They must be secured. They are the key weakness in this new equation. We can implement SSL for the socket connections and encrypt a hard drive or database table but if our applications are weak, we're toast.

Application security has grown by leaps and bounds over the past several years. The problem is we continue to see the same mistakes in code. Buffer overflows, unvalidated input, unprotected file access and other flaws continue to get written into our applications. Applications must go through a more rigorous security testing process whether they are written by a team of a thousand over the course of years or a team of two over a case of Red Bull. Oh…and we need to be teaching security at our colleges and universities, but that a topic for another day.

If we have any hope of protecting our data we must secure our applications. While encryption and other security technology will prevent data leakage or thefts in some instances, they can't protect against them through approved applications. We can, and should do more.


Get our blog posts delivered to your inbox:

The information we track while users are on our websites helps us analyze site traffic, optimize site performance, improve our services, and identify new products and services of interest to our users. To learn more please see our Privacy Policy.