End-to-End Encryption, Why You Should Start Now

Every week, some company somewhere is the victim of a data leak or a ransom attempt. Every day, a lot of effort is made to secure and protect data that ultimately fails.

Why?

It all breaks down from the inside.

One disgruntled employee and your customer, patient, doctors, nurses and even your own data can be used against you.

Against a rogue system administrator, a greedy DevOps or a hostile developer, most organizations are defenseless.

Especially, when we talk about PHI, we are legally bound to protect our patients and practitioners’ sensitive data. Failure is not an option.

As more organizations embrace the digital world and discover the complexity of giving their personnel the flexibility to work remotely with modern tools, they struggle to keep it all separate, accessible and secure. Whether it’s holding hospitals to ransom or putting entire companies out of business due to a data breach, we need to think about all possible forms of internal and external threats. While our cybersecurity awareness and security team have grown, the tools we use haven’t changed much.

And one specific tool is not getting all the attention it deserves: end-to-end encryption (E2EE).

Though more users are getting familiar with it for their chat message, their crypto-coins and their corporate internal tools, in most web user-centric applications, application-level encryption is simply not there. As cloud technologies advance, the infrastructure and network layers themselves benefit from the underlying and top-notch encryption of the cloud provider, but where the data acquires meaning -the application layer- nothing.

At ORO, we decided that we could not afford to wait for E2EE to become ubiquitous and easy. We decided that compliance would not mean a layer of human processes on top of a traditional user-restricted database, but end-to-end encryption from the core. Early on, we learned that to split the data into ‘usable’ chunks to define the ‘leak’ perimeter coupled with tight management of who has access to the decryption keys. In the same way that you identify and grade the type of sensitive information in your data, E2EE enforces those guarantees and ensures that they can’t be moved by a privileged user or a smart hostile internal actor.

Bonus: it makes it borderline impossible to make mistakes and accidentally or maliciously leak data: the system has no access to the keys, only users -patients/doctors- do. So no Developer, no DevOps, none of our IT, marketing, product or support team can access sensitive information without requesting it to someone with the keys.

We are lucky in health: we have that trusted actor with the legal obligation to protect PHI: our doctors. E2EE offers them those guarantees independently of ORO software quality and performance. But outside of health, you can still leverage all of it by allowing a special privileged user (your CISO, your DPO?) those rights/keys and fulfil your legal requirement (ceasure, audit,…).

For us, once those fundamentals were ingrained, we went further and addressed more complex cases like having one of our PHI-privileged actors compromised. We built a complex “sea of hashes” layer that was quite a lot of work but, for most organizations, should only be a second step.

As those threats grow and they will continue to, as our function becomes the management, grading and layering of security systems in increasingly complex ways, let’s pick the best tool for the job: E2EE. Not just as a gimmick or a feature checkbox, but by rethinking our product around it, its limitations and impacts on our users’ experience.

If you want to start, here is what we learned to ask ourselves:

• What is the most sensitive or valuable data we have?
• Of it, how can we separate them into valuable encrypted sets?
• Who should be able to decrypt these encrypted sets and how small can we make that group be?
• How do we build tools and telemetry around their use and not their content?

Let’s be clear: it’s not easy. With E2EE, security and even scalability highest standards (since all the encryption is done on the client side) can be met. But all our other needs (compatibility, reliability, maintainability, usability) have to be adjusted or changed completely to be solved at scale with E2EE.

I believe that, witnessing all the incidents and their impact on their identity, financial health and privacy, and experiencing the consequences of using that, users will soon demand application-level encryption.

My advice: don’t let them leave you for an E2EE competitor. Start now.

About the Author
Bruno has spent more than 20 years building software teams: apps for smartphones when they were called Personal Assistants, clouds when IaaS, innovation with Tier1 mobile operators, all of it. Not-so-funny cheese-obsessed Canadian-French, he’s building the modern healthcare both doctors and patients deserve.