6 Questions to Ask Before Encrypting Data
Why and how to Encrypt
In the era of Facebook data scandals and Edward Snowden whistleblowers, data has never been as valuable as it is today.
Consumers are starting to catch on that their data is actually valuable. Enterprises and businesses have always understood (and profited from) the value of data. When you have something valuable, you protect it.
One of the most powerful tools we have to protect application-layer data is encryption, but it’s challenging to evaluate and integrate an application layer encryption system into products, processes, and businesses.
Depending on who your customers are, different values drive the demands for data protection. We explore six focusing questions to ask before committing to application layer data encryption.
Question 1: Why Do You Need Application Layer Data Encryption?
So, you think there’s a need to encrypt your data. There probably is. But why? By encrypting the data, what is the value-add to the customer or end-user?
Good answers
Often, products in regulated industries, such as health care, defense, and finance, require it as a prerequisite to enter the market. Regulations often drive the requirements, such as GDPR, CCPA, HIPAA, FIPS, Common Criteria, NIST Cybersecurity Framework, etc. — but not always.
When consumer products integrate encryption, what they’re saying is that data is valuable and worth protecting.
For example, the secure messaging app Signal holds a strong belief that your communications should be private, and the encryption enforces that privacy — without the end-user even having to think about it.
Bad answers
Any request not linked to a specific business goal or concrete go-to-market strategy is a red flag.
For example, if an investor says to a founder: “You’ll have better market adoption with encryption in your product, so you should add it ASAP.” This is terrible advice. It prescribes a direction without expanding on the underlying value system that’s driving the demand.
Even if it’s true, it doesn’t help the founder build a secure system, because it fails to speak to a specific threat model.
Question 2: What Is Your Specific Threat Model?
Just encrypting data solves nothing.
Encrypting data transforms the problem of protecting your sensitive data into the problem of protecting your encryption keys. This way, your encrypted data can safely traverse less-secure and untrusted parts of the system.
To define a threat model is to identify the parts of your system that are trusted and untrusted. Risk only comes from sensitive data passing over untrusted portions. Within the untrusted portions of your system, the following three axes segregate risk even further:
- Space: A compromise in one part of the system should not compromise any other parts of the system.
- Time: A compromise in the past should not compromise the future operation.
- Use: A compromise related to over-use should not be possible.
In the end, you’ll have an answer to the question: “Secure against who or what?”
Good threat models
The more explicitly defined boundaries between trusted and untrusted, the better.
For example, maybe you committed to protecting the PII (Personally Identifiable Information) in your logs.
Then, it’s straightforward to satisfy your threat model by encryption your logs in the trusted portion of your system (your server). Now, you can safely offload logs to the untrusted part of your system, your log backup solution.
Bad threat models
Vague boundaries between trusted and untrusted parts of your system are insecure because different interpretations lead to miscommunications.
Further, if you declare too much of your system to be “trusted,” it exposes you (and your customers) to a broader attack surface. Finally, if you don’t segment your risk domains, then a single breach may compromise the entire system.
Question 3: What Is the Total Cost of Ownership of Application Layer Encryption?
The total cost of ownership is dependent on your implementation.
Build your own
- Upfront costs: Extremely high.
- Ongoing costs: Extremely high.
Unless you have an entire product security team, crypto team, SRE team, QA team, and in-house red-team, and you’re building an extremely focused highly-specialized system, this approach is probably not for you.
Building an encryption system in-house incurs the most cost, risk, and long-term engineering debt (in the form of bugs, legacy code, and non-standard implementation).
Even if open source or third-party managed services do not do exactly what you’re looking for, perhaps it’s worthwhile asking yourself why the standards chose not to.
Deploy an open-source project
- Upfront costs: Medium.
- Ongoing costs: High.
Although using open-source encryption tools can significantly mitigate upfront costs, the open-source community provides little to no cost mitigation for on-going expenses.
For example, Hashicorp’s Encryption as a Service is part of its open-source offering. Still now, in addition to running your own set of highly available services, you also have ensured the high availability of theirs.
Often, this forces you to hire an area expert to maintain and scale the solution. And how about the long-term security of running an open-source project?
To avoid security breaches from newly discovered security vulnerabilities, you have to update regularly. Lastly, consider your engineers: now, they’ll need a set of debugging tools for the encrypted portions of your system. Was it included as part of the open-source project, or are critical engineering needs not met?
Use a third-party managed service
Upfront costs: Low.
Ongoing costs: Medium.
Fully-managed services are excellent because they just work. The initial overhead is low. They abstract away all the grit of the technical implementation.
Backward compatibility works. As for security updates, you don’t even need to think about them outside of just updating your software.
So, what’s the catch? Why do we still see home-baked encryption systems?
Because finding a strong threat model in third-party managed services is difficult. For example, most KMS solutions require your key to be in the cloud, their cloud, (prohibiting you and your customers from using on-prem keys).
If you’re going after health care, defense, and finance — tread carefully, secrets are seldom permitted in the cloud (like encryption keys). Even if you’re not in those verticals, watch out.
For example, consider a threat model that includes privacy against third-party services, such as Google’s Pub/Sub service. So, if you encrypt your data with Google’s KMS services, and then send it over Google’s PubSub, what exactly are you doing? And why?
Question 4: Will It Scale?
As you 10x, from 10K to 100K and 1M clients, what happens to the encryption and decryption services? Will they be able to keep up?
Good answers
Systems that scale tend to offload the bulk of encryption and decryption operations to the pieces of software performing those operations.
To achieve this, you’ve got to securely distribute keys to parts of your system that need them, and that secure key distribution mechanism needs to scale well too.
Bad answers
When many clients blast a centralized service with “this is my plaintext, please encrypt it” and “this is my ciphertext, please decrypt it” are the most expensive types of systems to scale.
Scaling will increase cost, both in the form of dedicated engineering time, SRE time, and raw cloud-compute time (depending on the type of encryption system).
It might be tempting to use a centralized system as a root of trust, and build on top of that — but now you’re building an in-house solution.
Question 5: Will It Support Customer-Controlled Keys and On-Prem Key Ownership?
On-prem key ownership comes from a threat model that is suspect of cloud-deployed services. Many customers will not explicitly ask for this, but most enterprise customers will expect it — especially in regulated verticals such as health care, defense, and finance.
In consumer space, we see a spike of customer-controlled keys too, especially with the advent of cryptocurrency wallets or even secure communications apps.
Good answers
Providing the option for on-prem key ownership for when your customer’s threat model requires it today will ensure you never get locked out of a market due to insufficient security.
A smooth, non-disruptive, and self-service transition mechanism from in-cloud key ownership to on-prem key ownership, is also expected.
Bad answers
Ignoring this requirement as a “good problem to have” will make it extremely difficult to break into pragmatic majority markets when you attempt to cross the chasm in any well-regulated vertical.
Even in the consumer space, there is a shift towards on-device key ownership for those that take their security seriously.
Question 6: Does It Support Crypto-Agility?
Crypto-agility refers to the ability to dynamically switch from one cipher-suite to another, without having to release new software. Crypto-Agility is a critical aspect of modern application layer encryption schemes.
For instance, imagine you decide to use RSA-2048 in a secure key delivery mechanism, but RSA-2048 will one day be obsolete. As attacks evolve, building secure systems need crypto-agility to pivot off compromised encryption algorithms and compromised implementations quickly.
Good answers
A well versioned, dynamic, and centralized control pane is the only way to provide crypto-agility for application-layer encryption.
Specifically, decisions on: “What crypto-algorithm should this client use?” or even “What key should that client use to encrypt?” should be centralized and controlled from a centralized single pane of glass — not hardcoded or decided by the clients.
Bad answers
Any hard-coded decision about algorithms, modes of operations, or key lengths caked into clients will result in a world of hurt when you try to rotate off of those decisions later.
If there are no versioning mechanisms already in place in the legacy clients, it’s not even possible to retire old algorithms.
Introducing Peacemakr
Peacemakr is an application layer data security platform. It abstracts away all the hard problems described above behind a simple interface. It uses a dedicated SaaS to provide centralized configuration management for all integrated clients.
The SDKs focus on end-user simplicity and performance, so you don’t need a dedicated security team to build and maintain secure application-layer encryption in your product.
Unlike KMS solutions, Peacemakr is a full-stack solution for application-layer encryption. It offers secure key delivery, key lifecycle management, crypto-agility, and even on-prem key derivation for you and your customers with a single solution.
For more information, check out https://peacemakr.io or our open-source Peacemakr Crypto SDKs on GitHub.
Even if you don’t want to integrate directly into your applications, there’s an open-source peacemakr-cli that encrypts and decrypts strings or files in your system.
This is especially useful for debugging secured ciphertexts, or, even just encrypting your logs.
