The SafeLogic Blog

After I cross-posted Ray Potter's HealthITSecurity.com editorial to one of my LinkedIn groups (HIPAA Survival Guide), it spawned a great conversation about the lack of clarity on the topic of encryption in healthcare IT. Ray's article and the subsequent debate raised new questions and new confusion, even among the most qualified and experienced folks in the group. It became obvious that additional guidance would be helpful, so here goes. This is Episode 1 of 4, to be posted each day this week.

First, let's do a rundown on a few of the acronyms and terminology crucial to understanding encryption in healthcare.

NIST is the National Institute of Standards and Technology. They are responsible for setting benchmarks and providing guidance for technological implementations. They also set minimum requirements for federal government agencies to follow. Because of this role, private sector companies use NIST guidance as a template even when it's not legally mandated.

FIPS 140-2 is the Federal Information Processing Standard 140 (Version 2). It governs cryptography, was written by NIST and is possibly their most well-known standard. NIST even established a department dedicated to the validation of encryption modules that meet the standard. FIPS 140-1 refers to the first version of the standard, while FIPS 140-2 is the current version. FIPS 140-3 is not an official version, although many use it to refer to a theoretical future revision.

FIPS 140-2 Level 1 is the appropriate validation level for software. Levels 2-4 are concerned with increasing levels physical security of hardware, including tamper resistance and seals that show evidence of attempted access. Cool stuff, but irrelevant for a software solution like those being deployed on healthcare providers' laptops and mobile devices.

CMVP is the Cryptographic Module Validation Program. It is the NIST department (mentioned above) that handles the testing and certification of encryption modules from the private sector. Their little sister department, CAVP, is the Cryptographic Algorithm Validation Program, which provides the certification of individual algorithms as a building block towards CMVP's FIPS 140-2 validation.

The CMVP maintains a public list of all modules that have been validated. If it's not listed, it didn't get tested, didn't qualify, or at least hasn't completed the process. (It used to take 12-18 months, before SafeLogic cut it down to 8 weeks.) Any technology vendor that has received FIPS 140-2 validation will proudly provide their certificate number upon request, and you should absolutely cross-reference it with the public list to confirm.

"FIPS validated" is the term for a certified algorithm or module. It will have a unique certificate number on the public list. "FIPS compliant" means that it is ready to be tested, but has not completed the process, so it cannot be confirmed. Likewise, "FIPS ready" or "designed for FIPS" or "pre-validated for FIPS" are not actual, verifiable claims.

So why do you care? Well, if you're working in health, a little thing called Safe Harbor provides a big motivation. This is the legal avoidance of notifying patients that their PHI (Protected Health Information) was exposed. Let's say that a physician's laptop is stolen. If you qualify under Safe Harbor, you're all good, just need to procure a new laptop for the poor doctor. If you don't qualify, you're embarking on a pretty terrible journey, letting people know that their data was lost and their identity is at risk of theft, and waiting for the penalty assessment from the Department of Health and Human Services (HHS) Office of Civil Rights (OCR). The most recent announcement was a $650k settlement with a nursing home. [Correction 7/15/16 - the nursing home had to report the breach, but the settlement was paid by the Business Associate directly responsible for the lost iPhone.] Not good. Even worse, this one was due to a Business Associate (BA) decision not to encrypt a device that had access to patient data. Organizations are no longer insulated from liability due to Business Associate Agreements (BAAs), so the stakes are very high. You need to know exactly what your vendors, partners, and Business Associates (BAs) are deploying, since they must be included in your risk assessments now.

Tomorrow, I will post Episode 2, diving into the HITECH Breach Notification for Unsecured Protected Health Information; Interim Final Rule itself. Stay tuned!