Case Study: Navigating ePHI data security without compromising on product

Over the last 20 years, the advancement in healthcare, and specifically within health adjacent technology, has made a massive improvement on overall patient health. However, this expansion of the use of technology has dramatically sped up the digitization of sensitive health data, and therefore increased the layers of security concerns. Many fast-growing healthtech companies put security on the long finger, and quickly find themselves accumulating vast amounts of highly sensitive data and, therefore, enormous risk exposure. It's imperative that these companies swiftly pay down their data security debt and begin taking the security of their patient data seriously.

Here’s a brief story to unpack how one company gets to this point, and how they can navigate the key engineering road bumps and decisions made along the way. 

The Security Problem with Getting to MVP

Let’s start with Company X, a healthtech startup based in London who serves customers in the EU. They, as have many before them, rushed through privacy and security-related product developments to get their product to market quickly. While they were aware of the need to implement privacy and security controls, as demanded by customers and regulators, they opted to prioritize speed and product velocity.

There are two schools of thought on this approach:

1. Some would say security and privacy by design are key regardless of the company's stage. Security should be a foundational building block from day one.
2. Others may say that without a product and customers, there is nothing to make secure and compliant, and so engineering effort is attributed to security and privacy only after some critical (and arbitrary) point is reached. For instance, when the demands from your customers, prospects or regulators reach a pitch that can no longer be ignored.
   

While Evervault does not recommend this approach, Company X fell into the second school of thought, along with many of its peers.

A Starting Point

After a couple months of development, Company X had the basis for a functional product and some early customers, and were ready (and obligated) to tackle data security.

To kick off, Company X organized their data security strategy into pillars using native AWS tooling. By looking to similar businesses in their peer group, they focused on the basics in the beginning:

• Inventory
• Authentication and MFA
• Patching
• Basic logging
• Monitoring and alerting
• Resilience and standardization of process

As a European company, they opted for ISO 27001 as a basis for information security governance and used GDPR as their baseline for privacy.

Data Processing Inventory

The inventory pillar of GDPR requires creating a record of data processing activities. So Company X started by mapping their data flows of personal customer data in order to have a clear understanding of what Special Category data was being processed and where. In doing this, they quickly realized that they needed to handle some of their special category data with additional care.

One option they looked into was simply enabling encryption at rest on native AWS Storage. This option was simple and easy to implement, but with some research they realized it provided little more than a tick box in practical terms. Encryption at rest often comes with common mistakes, (outlined here) but can still leave the company vulnerable to a serious data breach. Company X knew they needed to find a solution that would secure sensitive data at rest and in transit.

Enter Evervault.

Assessing the Data Flows

The first step is to take a look and understand their data flows. For example, Company X’s product requires customers to submit sensitive data –  including photographs, electronic descriptions of symptoms, medications, and previous medical histories about themselves and members of their families.

This information can then be shared with medical professionals in order to connect the right healthcare professionals with patients. At the time of initial setup, it was stored in plaintext across S3 buckets and RDS databases, although the AWS disk was encrypted. From here, given they had established a clear understanding of the inventory and data flow, it was easy to determine which sensitive fields needed to be encrypted from a privacy and compliance standpoint.

Defining Where Encryption Happens

Next, Company X needs to build a product program for encryption and secure data processing for their customer data

Stage 1: Encrypt Inbound Data with Inbound Relay

The first step is to ensure that sensitive patient data is encrypted as soon as it hits the healthtech app. With Evervault, the best way to solve this is to use Inbound Relay, a proxy that sits in front of their existing endpoints and intercept the data so it would immediately enter their data flows as ciphertext. An added benefit is that it doesn’t require any code changes on their end, so they are able to select the fields to encrypt that are absolutely necessary.

Of course, they need to account for allowing doctors and approved medical providers to view the patient data and information. Using serverless functions with short-lived run tokens, they can grant the doctors the ability to view this information only when required and can cryptographically ensure that they were the only viewers of this information.

The encryption keys are stored in Evervault’s secure key management system. This way, the decryption keys never touch the client environment, even in memory, reducing the attack surface. Evervault can ensure the key expiration and rotation system in place is congruent with Company X’s compliance requirements.

Stage 2: Protect Data Processing in a Secure Enclave

Next, it’s important to understand if Company X is doing any automated analysis with the medical data coming in. For example, they are developing some features around patient-submitted image analysis but haven’t considered that the submitted images may be at risk of exposure during processing. One solution is running these processes inside of an Evervault Cage, which is a container running inside of a secure enclave.

In this reconfiguration, encrypted patient data is sent to the Cage, where it is automatically decrypted and stays protected while it runs against the company’s models. The data is encrypted again once it exits the Cage, and any diagnostic results from the processing can securely be relayed to the doctor for review.

This means, Company X can still take advantage of burgeoning technology without having to compromise on security. Since the build is done from within Docker, most engineers don’t need to change any of their existing technology stack in order to get this working.

A More Secure Infrastructure

By prototyping out these changes, Company X can feel confident moving forward with implementation. Evervault offers them an additional layer of security and transparency with their existing and new patients about how their data was being handled. They are able to operate from a place of knowing their data is as secure as it could be. Additionally, it lowers their GDPR and HIPAA risk exposure and saves them countless hours of time that it would have taken to mitigate these risks on their own.

Company X will still have a long way to go, and security will always be top of mind for them as they grow – but they’ve taken some big steps in the journey to protect their customer data.

Conclusion

Building a startup is hard. There are always going to be conflicting priorities and customer needs. But focusing on security when you can, as soon as you can, can save you from the stress and financial burden of fines and breaches down the line. And most importantly, it can foster trust from your customers and prospective customers, who will feel confident in trusting you with their most important personal information.

If you’re ready to talk security, or want help mapping your data security flows, we would love to hear from you. Contact us, and let’s get started protecting your user data.