Thanks for returning for the final installment in this blog series! If you need to catch up, please see Episode 1, Episode 2 and Episode 3, posted each of the last three days.
Here in Episode 4, we are tackling HITECH Breach Notification for Unsecured Protected Health Information; Interim Final Rule part (a)(ii), which covers data in motion. This will be the longest section, so grab a cup of coffee and let's rock! For your reference, here is the full passage again:
Protected health information (PHI) is rendered unusable, unreadable, or indecipherable to unauthorized individuals if one or more of the following applies:
(a) Electronic PHI has been encrypted as specified in the HIPAA Security Rule by ‘‘the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key’’ and such confidential process or key that might enable decryption has not been breached. To avoid a breach of the confidential process or key, these decryption tools should be stored on a device or at a location separate from the data they are used to encrypt or decrypt. The encryption processes identified below have been tested by the National Institute of Standards and Technology (NIST) and judged to meet this standard.
(i) Valid encryption processes for data at rest are consistent with NIST Special Publication 800–111, Guide to Storage Encryption Technologies for End User Devices.
(ii) 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.
Let's go in order. First, for Transport Layer Security (TLS), we are directed to another NIST Special Publication, this time 800–52, Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations. Here's a quote, directly from the document's Minimum Requirements section:
The cryptographic module used by the server shall be a FIPS 140-validated cryptographic module. All cryptographic algorithms that are included in the configured cipher suites shall be within the scope of the validation, as well as the random number generator.
That's pretty straight-forward. NIST wants you to use NIST validated encryption. Makes sense, we expected that. Okay, we're off to a great start!
Let's look at IPsec VPNs next, governed by NIST Special Publication 800– 77, Guide to IPsec VPNs. Here's an excerpt from the Executive Summary. (Italics below are mine.)
NIST's requirements and recommendations for the configuration of IPsec VPNs are:
- If any of the information that will traverse a VPN should not be seen by non-VPN users, then the VPN must provide confidentiality protection (encryption) for that information.
- A VPN must use a FIPS-approved encryption algorithm. AES-CBC (AES in Cipher Block Chaining mode) with a 128-bit key is highly recommended; Triple DES (3DES-CBC) 1 is also acceptable. The Data Encryption Standard (DES) is also an encryption algorithm; since it has been successfully attacked, it should not be used.
- A VPN must always provide integrity protection.
- A VPN must use a FIPS-approved integrity protection algorithm. HMAC-SHA-1 is highly recommended. HMAC-MD5 also provides integrity protection, but it is not a FIPS-approved algorithm.
That's also pretty blunt, laid out right in the first few pages. The only discrepancy here from previous guidance is that they call it "FIPS-approved" instead of the usual "FIPS validated". It's still a clear reference to the NIST program and the only resources available to confirm approval - the public validation list. Note that CAVP is responsible for validating algorithms and maintains public lists for each algorithm. That would be enough to satisfy the minimum requirements here, although deploying FIPS validated algorithms is not enough to claim full conformance to the standard. So for comprehensive coverage, a FIPS validated module is still required.
Let's go to the last alternative category, SSL VPNs, which refers to NIST Special Publication 800–113, Guide to SSL VPNs. This one is probably the most interesting (and confusing). SP 800-113 clearly states in several places that Federal agencies require FIPS 140-2 encryption, but never explicitly extends the requirement beyond those government offices. It gets complicated because the Breach Notification Final Interim Rule clearly refers to this document... which dedicates probably 80% of the content in the SP to discussing how to meet the FIPS 140-2 standard. So the bulk of the document concerns the validation, even though it does not call it a mandate. It's like handing someone a copy of Rosetta Stone but not actually asking them to learn the language. It's a strong implication, so let's chalk this one up to 'strongly recommended' even if not 'required'.
Anything that didn't fall into one of those categories (TLS, IPsec VPN or SSL VPN) lands squarely on the "others which are Federal Information Processing Standards (FIPS) 140–2 validated" box.
So if you're keeping score at home, part (a) lays out five scenarios:
All scenarios lead back to the same conclusion. HIPAA and HITECH are both pieces of federal legislation and enforced by a federal agency, which refers to another federal agency for judgment on encryption benchmarks. FIPS 140-2 is the only certification that unequivocally meets the demands of these government bodies.
Please use these links and excerpts to complete your own research, but be sure to ask yourself, "Do I really want to risk liability by using anything less than FIPS 140-2 validated encryption?"
The Breach Notification for Unsecured Protected Health Information; Interim Final Rule itself makes a strong point - you can choose to skip encryption and still potentially comply with the HIPAA Security Rule. But if you are hoping to avoid breach notification and penalties, you will be out of luck. Here is another excerpt from the Interim Final Rule, explaining the disconnect and solution. (Italics below are mine.)
Under 45 CFR 164.312(a)(2)(iv) and (e)(2)(ii), a covered entity must consider implementing encryption as a method for safeguarding electronic protected health information; however, because these are addressable implementation specifications, a covered entity may be in compliance with the Security Rule even if it reasonably decides not to encrypt electronic protected health information and instead uses a comparable method to safeguard the information.
Therefore, if a covered entity chooses to encrypt protected health information to comply with the Security Rule, does so pursuant to this guidance, and subsequently discovers a breach of that encrypted information, the covered entity will not be required to provide breach notification because the information is not considered ‘‘unsecured protected health information’’ as it has been rendered unusable, unreadable, or indecipherable to unauthorized individuals.
On the other hand, if a covered entity has decided to use a method other than encryption or an encryption algorithm that is not specified in this guidance to safeguard protected health information, then although that covered entity may be in compliance with the Security Rule, following a breach of this information, the covered entity would have to provide breach notification to affected individuals.
For example, a covered entity that has a large database of protected health information may choose, based on their risk assessment under the Security Rule, to rely on firewalls and other access controls to make the information inaccessible, as opposed to encrypting the information.
While the Security Rule permits the use of firewalls and access controls as reasonable and appropriate safeguards, a covered entity that seeks to ensure breach notification is not required in the event of a breach of the information in the database would need to encrypt the information pursuant to the guidance.
The Interim Final Rule can be very difficult to follow, but this much is clear: They consistently refer judgment to the appropriate government agency - NIST. As the National Institute of Standards and Technology, it is their experts that set the benchmarks, procedures for implementation, and decide what is approved and what is not. At the end of the day, NIST is very black and white with their program for testing and validating encryption modules. Everything that appears on the public validation list is approved, and everything else is not. For the needs of federal agencies and the military, NIST goes so far as to say that any unvalidated encryption is considered to be the equal of plaintext. Essentially, without validation, it cannot be trusted, not even a little bit. The privacy and security of citizens' health information has rightfully been deemed a priority and should be treated with the same respect.
If you are a Covered Entity, you need to do a complete audit of the encryption in use throughout your organization. Every software solution from every vendor being used by every authorized individual and every Business Associate should contain a certified encryption module that appears on NIST's public validation list. If it's not there, start asking direct questions of the vendor. Start with "Why isn't it validated?" and don't let them dodge the question. The validation should clearly display the vendor's name and the operating environment that you are using. If it's not clear that they are FIPS 140-2 validated and have a certificate number to reference, they probably aren't validated and you are in that gray area, subject to interpretation by the HHS. Nobody wants to be in that gray area when a device is lost, so get FIPS validated!
Thank you for reading my four episode opus. If you have any questions or feedback, please email me at Walt@SafeLogic.com or ping me on Twitter @SafeLogic_Walt.