IT may not get much credit when it comes to saving patient lives, but there’s no denying that cloud technologies can help do just that. By making medical data immediately available to providers, cloud-enabled applications can share test results, identify medication allergies and improve patient outcomes. And that makes data encryption a healthcare provider’s best friend when it comes to safeguarding electronic protected health information (ePHI). Yet while most IT professionals would agree that encryption represents the gold standard for protecting ePHI, many misunderstandings persist. Today we’re going to look at Part I of encryption basics - specifically the best methods for encrypting data. In Part II, coming soon, we’ll address selecting the best algorithm/method, as well as managing encryption keys, encrypting data in transit and verifying encryption.

Let’s start by looking at how we interpret encryption requirements within HIPAA, in particular those that define the requirements for encryption of data at rest and classify it as an addressable control (sections (a)(2)(iv) and (e)(2)(ii)). This has led some organizations to think that because it’s classified as addressable, rather than mandatory, they can simply decide to not implement it. However, guidance provided in the HIPAA FAQ, published by HHS, makes it clear that encryption is essentially mandatory. How? Because it would be difficult to determine that it’s not a “reasonable and appropriate” control based on an assessment of risk regarding protecting the confidentiality of ePHI. Also, because of what encryption does to data, finding a reasonable and appropriate “equivalent alternative measure” is essentially impossible.

So, assuming we can all agree that encryption is the most likely “reasonable and appropriate” measure, let’s take a look at some best practices for encrypting data at rest. To start, today we’re going to talk about selecting the best method to encrypt the ePHI you store based on the format of the data.

Encrypting Data at Rest

There are basically two types (formats) of data that need to be considered: structured data and unstructured data.  Structured data is typically data that is stored in relational database systems such as Microsoft SQL, Oracle and the open source MySQL. Unstructured data is represented by files, directories, shares as well as some of the newer NoSQL databases including Hadoop and MongoDB.

The most common options for encrypting these data types include whole disk encryption, database encryption, agent based encryption and application layer encryption.  Let’s take a closer look at the advantages and disadvantages of each one.

• Whole disk encryption: this method involves encrypting the entire disk (or volume, mount point, partition) regardless of its content.  This is typically used to protect laptops and other portable devices and is designed to protect against physical theft of the device. The process requires that a password be entered when the device starts up and whenever authentication is required, like when your screen saver is activated; once entered, the actual data on the device is not encrypted and available for use.

  This is not an effective method for servers as they (and the applications running on them) are always on. Any unencrypted data is subject to loss if unauthorized access is gained to the server or application. In my opinion, this method just doesn’t meet the intent of the HIPAA encryption requirements.
   

• Database encryption: many relational databases including Microsoft SQL and Oracle have built-in encryption functionality that allows the user to specify which data elements (or all data elements) are encrypted.  This method encrypts the data before it is written to the database tables; access to decrypt the data can be tightly restricted so that any person or application without appropriate rights will only see meaningless cipher text, even while the server or application is running. This method provides true at-rest data encryption and meets the intent of the HIPAA encryption requirements.
   
• Agent based encryption: several solutions provide a software agent that resides on the server and provides an interface that enables a user to encrypt data regardless of its format, which allows the encryption of individual files, whole directories and even databases that reside on the server. Similar to database encryption, the agent encrypts the data before it is written to disk and provides the same level of access control to the encrypted data.  This method also meets the intent of the HIPAA encryption requirements.
   
• Application layer encryption: this method is employed as part of the application development process and results in all encryption/decryption functionality being built into the application that handles ePHI. Essentially, it integrates a crypto library that provides the encryption and decryption functions with an algorithm to encrypt data within the application before it is written to disk.  This method can also leverage existing key management functionality that is typically built into the crypto libraries and or integrate with an external HSM (hardware security module) for added encryption key security. This method also meets the intent of the HIPAA encryption requirements.

As you can tell, depending on what you’re encrypting, different ‘at-rest’ options are available – most of which meet stringent HIPAA encryption requirements. While critical, it’s only one part of the equation to ensure your data meets criteria and is well protected. Check back next month for Part II, when we’ll talk about selecting an appropriate encryption algorithm/method, managing the keys used in the encryption process, encrypting data in transit and encryption verification.