The Devil and Database Encryption

Most every week I have a call from my credit card company’s security department to see if the recent activity on our account is actually ours. We used to get these calls maybe a couple of times a year, but now it is literally weekly.

A while back our credit card processor for SOS transactions notified us of new, stricter, security measures that we must follow or face the possibility of very substantial penalties. As a result, our customer credit card transactions now live in an encrypted database on a standalone computer that is not connected to our network or the Internet, and authorizes charges through a quaint dial-up modem connection directly to the processor’s system.

Arguably, financial data is a more tempting target for bad guys than most healthcare information, but there is little question that any data stored and moved around via electronic means is vulnerable. HIPAA requires that covered entities, and soon, business associates, take steps to determine the potential risk to the data that is in their systems, and to address the risk through a variety of security measures. These measures run the gamut from locked doors, user access passwords and workstation timeouts, through military-grade data encryption.

I have been thinking a good bit about the last of these: encryption. From CMS’s summary in HIPAA Security Series, Security Standards – Technical Safeguards (page 6-7):

4. ENCRYTION AND DECRYPTION (A) – § 164.312(a)(2)(iv)
Where this implementation specification is a reasonable and appropriate safeguard for a covered entity, the covered entity must:
“Implement a mechanism to encrypt and decrypt electronic protected health information.” (EPHI)

Encryption is a method of converting an original message of regular text into encoded text. The text is encrypted by means of an algorithm (i.e., type of procedure or formula). If information is encrypted, there would be a low probability that anyone other than the receiving party who has the key to the code or access to another confidential process would be able to decrypt (i.e., translate) the text and convert it into plain, comprehensible text.

There are many different encryption methods and technologies to protect  data from being accessed and viewed by unauthorized users.

  • Sample questions for covered entities to consider:
    Which EPHI should be encrypted and decrypted to prevent access by persons or software programs that have not been granted access rights?
  • What encryption and decryption mechanisms are reasonable and  appropriate to implement to prevent access to EPHI by persons or software programs that have not been granted access rights?

Generally, the safeguards you are expected to implement scale proportionately to the risk and the size of your organization. Thinking about the data stored in your billing and EMR systems, you would have to judge the risk to your data as very high if you have the database installed on a notebook computer that is routinely carried around by a staff member. Likewise, data moved across a network over a wi-fi connection would have to be considered as high risk. Even a solo practitioner or two person practice in either of these scenarios would probably be seen as negligent if the data were not protected by available encryption technology.

In the case of the notebook computer, I would think that whole-disk encryption should be in force, as there are likely to be letters, emails, and other sensitive data on the system that would not be protected if just your practice management/EMR database were encrypted.  Microsoft includes its BitLocker encryption system in Windows Server 2008 and the high-end versions of Windows Vista and Windows 7, but there also are many third party disk encryption products that one could use.

Wi-Fi protection means that you should use the best possible wi-fi encryption technology, at this moment, WPA2, coupled with a truly random password. Doing so would prevent virtually anyone “eavesdropping” on your wireless traffic from extracting meaningful information.

The correct path is not so obvious when it comes to encryption of primary databases, especially in the offices of small providers without dedicated IT personnel. Encryption is seeded by a string of characters, similar to a password or passphrase, called an encryption key. It is analogous to the key to your home or office, except that you can’t just break a window or call a locksmith if you lose the key. Good encryption is, for all practical purposes, impossible to crack. So, although the conscientious provider or practice owner’s first impulse probably would be to strongly encrypt, the risk analysis should include the risk of losing the encryption key, and therefore access to all the data stored in the database! The end result would be the same as a catastrophic hard drive failure with no backup — complete data loss and a very serious HIPAA violation.

Database encryption is only workable, therefore, in the presence of a formal, well-considered, bullet-proof procedure for encryption key management. Google that last phrase (“encryption key management”) and you will see that there are government documents several hundred pages in length that describe the procedures that must be followed to assure that  keys are both secure, and also readily available to those who need them.

To encrypt or not to encrypt? Devil or deep blue sea? What do you think? There are simple, keyless encryption schemes that are not terribly secure. Do you use something like that? Do you have a proven procedure for key management that you would be willing to share? You could lock your server in a bank rated vault, but then what if you forget the combination? We are back where we started! Anyone have any answers? Please click the title of this entry and leave us your comments.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This site uses Akismet to reduce spam. Learn how your comment data is processed.