- 10 minutes
Nearly 90% of healthcare providers were hit by a data breach in a span of two years, according to a 2016 study by the Ponemon Institute1. Healthcare incurs the costliest data breaches out of any industry, with the average incident costing roughly $9.42 million2. This data is particularly valuable to attackers, as high as $250 per record3 (a record being health information about a single patient). Over the last decade there has been a healthcare breach epidemic - including 4,419 breaches of 500 or more records contributing to a loss of over 300 million healthcare records between 2009 and 20214.
The quantity of healthcare data and its usage in a variety of applications is exploding. Today, 30% of global data is generated by the healthcare industry, with a 36% annual growth rate expected by 20255. The major handlers of this data are the vast array of Electronic Health Record (EHR) applications. EHR entries contain Protected Health Information (PHI) such as medical history, medication use, laboratory tests, diagnoses, biometrics, and more. By digitizing health information for individual patients, care can be administered more efficiently and effectively by sharing EHR profiles throughout provider networks.
Currently, the EHR applications handle the storage, distribution of, and authorization to access this data themselves. However, these applications commonly only perform encryption at-rest and/or in-transit, not end-to-end and only accessible to the patients or healthcare provider, meaning that large numbers of users’ PHI could be compromised by a single breach of the EHR application. The reason for choosing weaker security is that it allows records to be more functional for both providers and users. As an example, because the EHR application is in control of the data, even if a user or provider loses access to that data (for instance by losing their password) the data can be easily recovered. However, this ease-of-use and practicality comes with some major security concerns.
The US Department of Health & Human Services provides a list of recommendations on keeping electronic health information in EHR systems secure. These include “‘Access control’ tools like passwords and PIN numbers to help limit access to your information to authorized individuals” and “‘Encrypting’ your stored information” so that “your health information cannot be read or understood except by those using a system that can ‘decrypt’ it with a ‘key’”6.
Unfortunately, it is continually proven that at-rest encryption and access control are significant vulnerabilities, and these techniques should not be heavily trusted with sensitive data. Even if access to data is properly managed, the fact remains that if a system (including its administrators and any other employees with privileged permissions) has the technical ability to access sensitive data, that ability can be exploited by a hacker. When large amounts of data are accessible to a single system in this manner, a single breach event can mean the compromise of thousands, even millions of records, costing enterprises staggering amounts of money in both remediation and insurance.
This vulnerability was made clear by the 2015 breach of Anthem, in which 78.8 million records were lost7. Through the use of a phishing email, secure account credentials of Anthem employees were compromised. Control of these accounts was used to gain access to Anthem’s enterprise data warehouse, where all the lost records were readily accessible to attackers. The core issue of this attack was that the compromise of privileged individuals resulted in access to sensitive records of millions of users. A response in the breach report, that the attack “underscores the importance of comprehensive and frequent security awareness training for all employees of healthcare organizations” is a common but inadequate response to such events. Because it is impossible to perfectly safeguard secure credentials, the safety of these systems cannot depend on them. Instead, privileged accounts can have limited access to sensitive data, without impacting the experience of its end users or the functionality of the larger system. By implementing end-to-end encryption in their databases, EHR applications can accomplish exactly this - even in the event of a compromised individual account, the breach is limited in scope to that single user, rather than the entire system.
For a more in-depth dive on the tradeoffs of at-rest encryption and access control vs end-to-end encryption, read our blog post, “Why should I encrypt my database?”.
EHR providers do not need to have full access to the unprotected user data when stored, since they are not the entity actually providing the healthcare services. The fact that they still do offers them little more than a massive liability. A common trend when it comes to healthcare data breaches is that an organization had access to a needlessly large amount of data when it was breached. For instance, when Dental Care Alliance was compromised, hackers gained access to PHI of 1 million patients for almost a month8. The patients impacted came from more than 300 individual practices and had “names, addresses, dental diagnoses, treatment information, patient account numbers, billing information, bank account numbers and health insurance data” leaked. Because this product was architected to maintain access to all of its users’ data, this breach had a massive impact despite its customers being only small-to-medium-sized practices.
While there is some administrative merit to centralizing some of this information, there is no reason or benefit to this entity holding sensitive PHI at such a mass scale. If instead the information were protected at a per-provider (or better yet per-patient) level, a far greater number of independent security compromises would be required to achieve this extraordinary scale of information breach.
To achieve much higher security guarantees, end-to-end encryption becomes necessary. EHR applications would greatly benefit by making sensitive data accessible only to as few users as possible. This is a crucial security principle which has gone unheeded throughout much of this industry, resulting in the preventable loss of millions of records. Access control at its core does not accomplish this - this equates to having a single main controller of data which delegates access. This is inherently vulnerable, because that single controller is open to compromise and with it all of their managed health records. In order to properly secure this private data, it must be impossible for anyone not explicitly permitted to have access to it.
EHR applications can do this, and significantly reduce the potential impact of a data breach by choosing to encrypt their data on a per-user basis instead of having access to it all at once. Some are already beginning to move toward this model, as evidenced by EHR provider Doctolib’s acquisition of end-to-end encryption service Tanker9. With users in control of their own data, they alone determine which providers, even individual doctors, receive access. This can be accomplished much like a shared password manager, in which each party can receive access to the data through their own uniquely encrypted copy of the key to the data provided by a current key holder. Unlike at-rest encryption, millions of users’ data is no longer behind the same single point of failure, namely the EHR provider’s storage backend. At best, each user must now be individually compromised for their health records to be leaked, and at worst, the breach is limited to a single healthcare provider.
Traditionally, performing encryption in this manner comes with some serious drawbacks to usability - a provider error or user password loss can lead to health records being irretrievably lost. This is not a valid option for today’s EHR systems, especially when in the hands of older and less tech-inclined patients. Bridging this security and usability gap is where Bunkyr comes in.
When data is stored in a higher-security end-to-end encrypted format, account recovery becomes a large burden on the user - losing a password can mean permanent data loss. This problem is typically “solved” with recovery codes, but these are equally prone to loss and do not address the core user liability. Bunkyr solves the recovery problem for end-to-end encrypted data with its ability to securely generate an encryption key from something as simple as signing in with Google, Facebook, or Apple. This enables a user or provider to restore their access to encrypted data in the event of password loss by using something they have frequent and reliable access to, avoiding the risk of permanently losing their valuable healthcare data.
The goal is for recovery with Bunkyr to make strong encryption more practical for EHR systems to adopt. Additionally, planned Bunkyr SDKs can make the integration process as simple as a few lines of code for EHR providers.
A potential roadblock for adopting end-to-end encryption is the lack of ability to perform analytics. When data is fully encrypted and inaccessible to the EHR technology, it is no longer possible to read and interpret data without interaction by a patient or provider with the keys to decrypt the data. However, end-to-end encryption does not have to be implemented across all fields of data, and can instead be applied only to sensitive information. Bookkeeping fields, audit logs, and any other information needed for analysis can remain accessible in the form of anonymized data, adjacent to sensitive information which is viewable by authorized users and providers only.
As data breaches across all sectors continue to worsen, it is necessary improve the standard of information security practices. In applications such as EHR, improving our ability to apply even limited end-to-end encryption to the greatest extent possible offers tremendous value to the security of the industry - especially when the cost and number of users affected by breach events are extremely high, and only continuing to rise.
For more about how our system works (and how we protect the keys we generate), please take a look at our more detailed “how it works” page. You can request a demo or reach out directly to our engineering team for more information or to get started with the integration process.