The number of data breaches in the healthcare industry is growing exponentially—and the breaches are becoming more severe. This phenomenon can be attributed to the increased black-market resale value for stolen medical records and personal health information (PHI), as well as the sophistication of cybercriminals. As a result of these risks—and of all the HIPAA penalties, legal costs, reputational damage, and potentially lost business when electronic personal health information (ePHI) is breached—healthcare organizations are slowly but surely adopting one vital IT practice: encryption.
As information technology continues to transform healthcare, sensitive patient data is increasingly transferred in different ways. From this device to that, from here to there—and the only real way to protect that data is to encrypt it. Whether it’s guidance regarding reasonable and appropriate device storage standards, or extra protection in addition to the HIPAA-required encryption of data in transit, some confusion about healthcare encryption best practices still exists. Chad Kissinger and Jeremiah Martin of OnRamp addressed this topic specifically in a webinar hosted last year, and their advice is as pertinent today as ever.
The first thing to know is what is necessary vs. what is recommended. Intended to guide healthcare industry businesses on the best practices to avoid IT security threats, the HIPAA Security Rule requires covered entities and their business associates to implement technical safeguards to protect all ePHI. As such, HIPAA makes particular reference to encryption “on the fly” and “at rest,” access controls, encryption key management, risk management, auditing, and monitoring.
When it comes to data in transit, it’s well documented that encryption is required, and that you must follow certain standards. But in some regulatory documents, the exact requirements are not explicitly stated. For instance, The Department of Health & Human Services’ guidance language within the Breach Notification Rule is vague.
These standards seek to implement a proper failsafe that makes data unreadable, unusable, and unrecoverable by outside parties. The safest bet is to comply with all encryption recommendations, regardless of whether or not they are required.
Notes from the Health and Human Services website:
- Valid encryption processes for data at rest are consistent with NIST Special Publication 800-111, Guide to Storage Encryption Technologies for End User Devices (sets standard for cyphers and FIPS compliance)
- Valid encryption processes for data in motion are those which comply, as appropriate, with NIST Special Publications 800-52, Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations; 800-77, Guide to IPsec VPNs; or 800-113, Guide to SSL VPNs, or others which are Federal Information Processing Standards (FIPS) 140-2 validated.
A key takeaway from the guidance above is that your solution should be FIPS 140-2 validated. Fortunately, the National Institute of Standards and Technology (NIST) has created a program called the Cryptographic Module Validation Program (CMVP) to help businesses figure out whether or not their encryption is up to snuff. Not only will CMVP check to see if your cryptographic module (firewall, router, etc.) is FIPS compliant, but they’ll also tell you how to deploy, configure, and test your module.
It’s important to remember that encryption doesn’t guarantee that hackers won’t ever breach your security. Currently, 256-bit encryption is the industry gold standard because easy access to computing power able to crack that level of safety does not exist. Someday this will change, and you’ll have to overhaul and replace your entire module; this is noteworthy because if you’re renewing your encryption process every two years, for instance, you may need to re-encrypt all of your backup files with your new technology. You’ll want to consult with your service provider to see what options are available. Re-encryption with new technology is a leading way that enterprises breach security and privacy rules, second only to lost laptops and other devices.
Other ways to mitigate loss of ePHI beyond encryption include:
- Proper key management, such as storing keys separately from data. The Breach Notification Rule states that if you can’t prove that a key is separate and secure from, for example, a stolen laptop or hard drive, you’re in violation of compliance. Centralized key management and periodic key renewal are good ideas because it’s not always about losing hardware, it’s also about losing people. If your chief information security officer (CISO) is the “keeper of the keys” so-to-speak, and he leaves, you’ll have to rotate your encryption—much more laborious than a simple key renewal.
- Authentication at the file level can help protect ePHI from those that need to access a server but don’t need actual access to the data on it. Additionally, if an admin logs into the system from an infected computer, data that isn’t encrypted may then be automatically compromised.
- Malware protection is huge. In certain situations, it may not be reasonable to encrypt data at rest because coders need access to it to write and run programs, and in these situations, malware protection is vital.
- Masking, truncating, and de-identifying data in environments where it needs to be readily available to programmers is a great alternative measure.
Even when encryption is reasonable, taking these steps provides excellent complementary measures that can reduce the scope of your company’s risk.
Additional considerations include considering transmission protocols other than TSL/SSL, making multiple backup copies of your encryption key (if you lose this, your data is gone forever), and ensuring that these keys aren’t solely held by one person.
By following these tips, you are taking control of your HIPAA compliance and employing best practices to maximize your security in an increasingly unsecured world. For comprehensive information on HIPAA compliance, visit http://www.hhs.gov/hipaa/for-professionals.
Additional Resources on This Topic: