Encrypting your users’ data is no longer optional

While balancing privacy and innovation is one of today’s most critical issues in technology development, let’s identify data encryption’s opportunities.

Most of today’s digital businesses hold data on behalf of their users. These assets are valuable to both your business and your users, which means they are excellent targets for hackers. Holding onto their data has risks that can hardly be ignored. While Bill Gates said in his review of 2018 that one of the most critical areas of technology development in 2019 is the balance between privacy and innovation, it’s certainly the right time to ask yourself “how to protect my users’ data?”, especially if you work for a tech company or leading a digital project. With your users’ trust comes great responsibility, especially when more frequent data breaches have damaging consequences on companies’ brand and revenues.

The looming data breaches, their damaging effects on users’ trust and companies’ revenues.

The main risk you face while holding data is qualified by the term “data breach”. It consists of a partial or total leak of the data from your servers, or the cloud, to individuals harboring evil intentions. Over the last years these attacks have become more frequent and many companies, such as Yahoo, eBay, or Sony, have experienced critical leaks.

Still, what are the odds of being targeted by such attacks?

As Cisco’s Chief Security Officer John Stewart said, a data breach is bound to happen: “You’re eventually going to be hit, it is not worth the effort of thinking you won’t be hit.” and “The bottom line is that unfortunately, no organization is immune to a data breach in this day and age.”

Let’s keep in mind that your users’ data is a keepsake that embodies the trust relationship between you and them.

By breaking this trust, your organization sends a terrible message: you don’t consider your users’ well being, and you leave the door open for a competitor that will. Branding takes a long time to build, but a second to destroy.

Data breaches’ consequences are disastrous for any business. This can lead to situations where clients seek an alternative to your product, do not subscribe, or even leave.

Let’s make it short: losing control of customer’s data means losing customers.

And there is more and more data to prove it. On January 2018, Cisco’s Privacy Maturity Benchmark study revealed that 65% of organizations reported sales cycle delays due to clients’ data privacy concerns, with an average of 7.8 weeks delay, and a correlation between the organization’s privacy maturity level and the sales delay duration.

Cisco 2018 Privacy Maturity Benchmark Study.

Above branding and revenues issues, legislation has evolved to take privacy into account. With the GDPR’s implementation within the European Union and AB 375 in California, data breaches now have direct applicable legal consequences and financial sanctions. If your organization treats users’ personal data on the EU territory, the fine framework can be up to 20M€, or in the case of an undertaking, up to 4 % of your total global turnover of the preceding fiscal year, whichever is higher.

So now that you’re aware of Data Breaches’ damaging consequences, let’s explore the best users’ data protection options.

Actually, there are two options: securing the data access or securing the data itself. In 2019, If you want to protect your users’ data, there are two options: securing the data access or securing the data itself.

Securing the data access has its limits: unavoidable human mistakes.

Let’s review the steps necessary to secure the data access to your application together.

First, your code has to follow your organization’s security guidelines. It then has to go through a thorough code review and finally be audited by a third party. As long as there are no human mistakes, these processes guarantee you a secure code base.

Except that your software is most probably relying on a handful of external software dependencies, services, and hardware. Sadly, many of them are not built and configured with the same level of security expectations as your organization. This last statement is especially true for storage services that can easily have unsafe or confusing default configurations. Even the NSA experienced such an accident with the leak of Red Disk, over an Amazon S3 public bucket.

Moreover, even after all these steps, you have to be prepared for emergencies with a fast established process to find and deploy the fixes for security issues.

Altogether human mistakes are impossible to avoid and relying on the security of multiple components in an application means that errors are more likely to happen as each additional piece of code, dependency or service to secure adds a layer of uncertainty.

This is where encryption comes up.

Over the last decades, encryption has become one of the most popular and effective methods to secure end-users’ data privacy.

When it comes to secure the data itself, vote for end-to-end encryption.

Data encryption is defined as data’s transformation into another form, or code. When data is encrypted, only people with access to a secret key or password can read it.

In other words, encrypting the data ensures only authorized users can read it. The data is stored encrypted, and any leak from the storage only leaks the encrypted data. To get access to the clear data, one needs access to both the encrypted data and its associated encryption keys. In this regard, data encryption is a strong barrier to data breaches.

Among the multiple solutions to implement data encryption, let’s evaluate the most common ones: encryption at rest and end-to-end encryption.

In an application, many stakeholders can have access to data, primarily some or all of the employees that have access to the application server and the storage.

With encryption at rest, your application servers typically encrypt data before sending it to storage (e.g., a database server, or service in the cloud) and decrypt it after retrieving it from storage. This means any data leak occurring at storage level is not an issue anymore (e.g., an improperly secured database or a database backup made publicly available by mistake). However, all your users’ data are still accessible by the application servers themselves, some or all of your employees, and thus are vulnerable to attacks.

To send a confidential medical result to Patient Bob, Dr. Alice is using a fictive telemedicine app that adopts encryption at rest. The issue here is that Patient Bob’s data is still accessible in the app server and KMS.

In the event of an attack targeting your application servers, clear data becomes accessible at once. Popular services like AWS KMS are widely used to implement encryption in this fashion.

End-to-end encryption neutralizes servers’ breaches, but it’s not very user-friendly.

In the end-to-end encryption mode, the clear data is not accessible by the application’s employees, but only by the appropriate users. The data is transmitted as encrypted through the multiple layers of the application. The application servers and the storage only handle the encrypted data, and only the relevant user(s) can decrypt it. An attack on the application server leaks nothing, so that’s why you have to try attacking users one by one.

Here, Dr. Alice is using the same fictive telemedicine app, but here the app has embedded end-to-end encryption. Patient Bob’s medical data is only accessible at users’ device, neutralizing apps’ and servers’ attack.

As ideal as it sounds, end-to-end encryption adoption is very slow. The main hurdles are the difficulty in developing and setting up such technology, but also the impact on your application’s user workflows.

For example, common impediments on the user experience of PGP are that users have to manually save and retrieve a key to own several devices or that it is only possible to share to a group of users by encrypting again for every individual in the group.

Obviously, from a user experience standpoint, these issues are not acceptable, but we’ll develop this point in an upcoming blog post :)

The balance between privacy and user experience is an incredible challenge, and it’s the one we, at Tanker, chose to tackle. We strive to provide an open-source privacy solution as user-friendly as possible. Sign up and try it here: https://tanker.io/

---

PS: This article was originally written by Loïc Banet and published on Tanker’s Medium. As you might not be on Medium yourself, we've reproduced it here to give you a chance to see it in your notifications feed.

Comments

[Mitch Jackson]

This is an interesting thought experiment. I am curious how base functionality would be implemented.

Suppose I'm using Postgresql, and I encrypt the contents of every column at the application level before inserting values into the database.

How does one provide general search functionality, when the database engine cannot see the column values?

SELECT *
FROM customers
WHERE first_name LIKE 'DIMITRI%'
   OR last_name LIKE 'DIMITRI%'

How does one provide reporting functionality, when the database engine cannot see the column values?

SELECT sum(amount)
FROM card_transactions
WHERE amount >= 10
  AND amount <= 20
  AND transaction_timestamp >= '2019-01-01T00:00:00'
  AND transaction_timestamp <= '2019-01-31T23:59:59'
  AND processor = 'stripe'

[Dimitri Merejkowsky]

This is an interesting thought experiment

Thanks for your feedback!. As for encrypting databases, you have to realize you cannot encrypt indexed columns.

Some ideas:

• Don't encrypt metadata that is required server-side
• Do search client-side, or build an encrypted index

Cheers!