Encryption at rest and encryption in transit for HIPAA compliance are not easy questions to answer

Given the number of breaches we’ve seen this Summer at healthcare institutions, I’ve just spent a ton of time recently on several engineering engagements looking at “HIPAA compliant” encryption (HIPAA compliance is in quotes since it’s generally meaningless). Since I’ve heard a number of developers say “we’re HIPAA compliant because we encrypt our data” I wanted to take a moment to unbundle that statement and make sure we all understand what that means. Cryptology in general and encryption specifically are difficult to accomplish; CISOs, CIOs, HIPAA compliance officers shouldn’t just believe vendors who say “we encrypt our data” without asking for elaboration in these areas:

• Encryption status of data at rest in block storage (the file system that the apps, databases, VMs, are stored on)
• Encryption status of data at rest in virtual machine block storage
• Encryption status of data at rest in archived storage (backups)
• Encryption status of data at rest in the Oracle/SQL*Server/DB2/MySQL/Postgre/(your vendor) databases (which sits on top of the file system)
• Encryption status of data in transit from database to app server
• Encryption status of data in transit from app server to proxy server (HTTP server)
• Encryption status of data in transit from proxy server to end user’s client
• Encryption status of data in transit from API servers to end user’s clients (iOS, Android, etc.)
• Encryption status of server to server file transfers
• Encryption key management in all of the above

When you look at encrypting data, it’s not just “in transit” or “at rest” but can be in transiting or resting in a variety of places.

If you care about security, ask for the details.