It isn’t easy to navigate regulations around Protected Healthcare Information (PHI). This article shows how startups can tackle PHI regulations with three types of encryption and meet a high data security bar with ease and confidence.
This concise and pragmatic guide for Founders and Lead Engineers helps navigate the highly regulated space of encrypting PHI using tools that help minimize total-cost-of-ownership and time-to-market.
Regulations in the US
HIPAA and HITECH are often some of the regulations in the US that govern how tech products must protect patient healthcare data. There are also non-regulatory 3rd party certifications, such as HITRUST CSF, which startups may encounter when trying to close a business partnership with a well-established institution. We’ll focus on HIPAA, for now.
HIPAA defines the encryption of Protected Health Information as an addressable requirement. An addressable requirement doesn’t mean it’s a good problem to have. It means we have this problem now. It requires us to “implement a mechanism to encrypt PHI whenever deemed appropriate.”
The requirement uses vague language because technology changes while the language used by laws does not. Prescribing a specific type of encryption would be out-of-date very quickly. The spirit behind the vague wording is for us to protect PHI with the latest best practices of encryption.
Here they are:
(1) Encryption in Transit
Transport Layer Security (TLS) protects data as it moves across a network. It uses X.509 certificates to verify the identities of communicating parties while providing confidentiality of data on the network.
Encryption in transit is an essential type of protection because we don’t trust intermediate network nodes.
To set up, all you need is an X.509 certificate signed by a trusted certificate installed on your server. But the total-cost-of-ownership keeps on giving: when those X.509 certificates expire, and your team must renew them. Failure to update so will result in a service outage since expired certificates prevent clients from connecting. Luckily, all the best solutions automatically update your certificates for you.
- Let’s Encrypt + CertBot: Free, Open-Source, but requires some configurations
- AWS Certificate Manager: Free, but tightly couples you to AWS, but fewer configurations to set up if you already deploy to AWS
(2) Encryption at Rest
Encryption at rest provides confidentiality when your PHI is on a physical storage medium. Even PHI in the cloud is on a physical device somewhere. This layer of protection ensures that your data is not recoverable from the physical medium without the key.
Encryption at rest is an essential type of encryption because we don’t trust the physical storage medium of your service provider.
Best solutions for encryption at rest are product-specific but generally referred to as Server-Side Encryption (SSE).
- AWS S3: In S3, Server-Side Encryption is free and easy, but you must remember to enable it. You can enable it at any time if you forgot to when you created the bucket, but AWS will only encrypt new data.
- AWS EBS: Server-Side Encryption is again free and easy, but you have to enable it on EBS volume creation. If you did not, you have to create a new encrypted volume and manually migrate everything over to the encrypted volume.
- Google: Everything is encrypted at rest automatically.
- Hammerspace: Everything is encrypted at rest automatically.
(3) End-to-End Encryption
End-to-End Encryption is a technique employed inside an application to encrypt and decrypt application data. It protects PHI in databases, files, applications, load balancers, microservices, clients, or 3rd party vendors. When a hacker breaks into a cloud system that employs End-to-End Encryption, it forces the hacker to find and reverse engineer a running application to steal keys and encrypted data. Encrypted data is entirely useless without the key.
End-to-End Encryption is an essential type of encryption because it’s the last defense against any cloud security event.
- Peacemakr: Open-Source, full-featured free tier, drop-in solution for End-to-End Encryption
- AWS Key Management Service: You could encrypt and sign, but you would still need an in-house solution for key distribution, management, and rotation.
As a leader, your decision comes down to this: if you’ve got the time and budget, then you could build many of these things in-house.
If, on the other hand, you are pressed for time, resources, and capital — focus your resources on your core business logic and find a security company to partner with to help with PHI encryption regulative requirements.
My only ask is: please do one or the other. Don’t skip adding encryption now, as most likely you’ll never get back to it, or when you do, the required re-architecture bill to add security retroactively will be too large to justify.
Besides, all the best startups take data security seriously.