If you work with an organization that must adhere to the Health Insurance Portability and Accountability (HIPAA), you know by now that encryption is now a de facto primary aspect of HIPAA compliance after the passing of the HITECH Act.
There are a couple of reasons for this increased focus on encryption.
First, the U.S. Department of the Health and Human Services (HHS) issued guidance wherein "unsecure protected health information (PHI)" is essentially any PHI that is not encrypted or destroyed. Under this definition, it doesn't matter how many chains, walls, doors, biometric gizmos and guards with lethal weapons you have at your service. As long as PHI is not encrypted, it is considered unsecured.A second and more compelling reason why encryption is now a requirement is the introduction of HITECH's breach notification initiative, which requires HIPAA-covered entities to send notification letters if there is a breach of unsecured PHI. However, as HHS pointed out, the use of encryption grants safe harbor in the event of a breach because encrypted PHI is not unsecured PHI.
Oddly enough, in the same breath, HHS also notes that "covered entities and business associates are not required to follow the guidance." However, cleaning up the mess behind a breach notification can cost millions of dollars, so one would have to be supremely confident — or reckless — in not taking advantage of the encryption safe harbor. With such mixed signals, though, it is not hard to see why encryption is called a de facto requirement.
What type of encryption?
Since encryption means different things to different people, an important question is "what type of encryption should I use?"
In the past, companies offered hard drives that used strong encryption. However, analysis showed that strong encryption was used but only to protect the password and not the data that was stored on the devices. The actual data stored on the hard drive was encrypted with an encryption algorithm developed by the company, which proved to be anything but strong.
This illustrates the potential pitfalls of choosing any type of encryption package — a lack of strong, secure encryption. Obviously, some encryption programs do a better job of protecting data than others, but how can a company choose the right one?
HHS does not provide any guidance in this area, and that is a smart move. HHS does many things, but it is not in the position to determine the technical requirements that would separate strong from weak encryption. Instead, HHS defers to the National Institute of Standards and Technology (NIST) to direct organizations to a number of special publications on the subject.
The publications are endless, tedious documents which are long on theory and short on technical requirements. However, a little detective work leads to concrete specifications that one can work with.
While these requirements are for federal agencies, they could also serve as a great guide for private practices. Since HHS deferred to NIST when it comes to encryption, companies need to meet the expectations of what NIST considers "proper" encryption for sensitive data.
Further proof that HHS deferred to NIST is found in the guidance, where encryption for "data at rest" and "data in motion" are specifically mentioned. The latter refers to data going through networks, including wireless networks. The former refers to data that is stored: laptops, external hard drives, CDs or DVDs, backup tapes, etc.
Data in motion
Of the two, encrypting data in motion is more straightforward: Valid encryption processes must "comply with the requirements of Federal Information Processing Standards (FIPS) 140–2." While there are many technical requirements involved, many vendors offer products that are FIPS 140-2 validated, so finding such a solution is easy.
Organizations must look for a solution that is FIPS140-2 validated, not FIPS140-2 certified. The former means that NIST evaluated, and validated, the encryption. The latter is used interchangeably with the former, but is technically meaningless and is mostly marketing speak. While encryption is in the spirit of NIST's requirements, it hasn't been validated.
Data at rest
Finding appropriate data at rest encryption requires a little digging. According to the suggested NIST publication — Special Publication 800–111, Guide to Storage Encryption Technologies for End User Devices — "Federal agencies must use FIPS-approved algorithms contained in validated cryptographic modules. Whenever possible, AES (Advanced Encryption Standard) should be used for the encryption algorithm because of its strength and speed."
Also, a footnote makes reference to NIST SP 800-57, "Recommendation for Key Management," and notes that it "provides detailed information on key management planning, algorithm selection and appropriate key sizes, cryptographic policy and cryptographic module selection."
This information is relegated to a footnote. This is unfortunate since this publication is what most HIPAA-covered entities are looking for. As organizations review section 5.6.2 of the publication, they can identify encryption algorithms that are valid for use, the minimum key sizes and the length of their validity. In addition, examples are given on how all of the above comes together, and summarized in a table. Any encryption weaker than this, and you might not be covered.
HIPAA-covered entities can expect safe harbor if, and only if, they adhere to these strict standards and guidelines. The fact that a company's data is encrypted is meaningless without taking into account the NIST requirements. Organizations that properly adhere to HIPAA standards understand the impact of breach notifications. By proactively leveraging the proper encryption technologies, companies of all sizes can avoid these breach notifications while ensuring the security of their sensitive data.
