Application-layer Encryption Explained

AppSec That Actually Protects Customer Data

You know those news articles that start, “two million customer records were stolen containing names, emails, and home addresses"? You can stop that from happening.
Application-layer Encryption (ALE) is an architectural approach where you encrypt data before sending it to a data store. If the data store is compromised on a running machine, then the encrypted data remains safe from attackers.

The Two-Layer Problem

In most cloud applications today, there are only two layers between an attacker and the data: the web application firewall (WAF) and the server application.
This is crazy.
Apps inevitably have vulnerabilities as do their underlying libraries and environments. These are complex systems created by human beings. Mistakes and unanticipated behavior are the norm.
Security teams recognize this and do what they can to mitigate the issues. In practice, this means heavy reliance on WAFs to stop threats. But WAFs can be evaded easily, are often a new surface area for attackers to exploit, and can’t defend against application-specific logic errors.
Just one mistake can result in disaster.

AppSec: The Bigger Picture

Application Security (AppSec) is what you do to develop and ship a secure application. It has many parts, which include:
  • Patch management: keep dependencies and environments up-to-date with security fixes.
  • Dependency vetting: formal scrutiny of toolchain and environment dependencies.
  • Secure development lifecycle (SDL): everything from developer training to security-related architecture reviews to security-based QA.
  • Scanning: code scanning and external penetration tests.
  • Product features: security or privacy related features such as single-sign on and multi-factor authentication.
  • Application-layer encryption: to prevent a breach from resulting in the loss of unencrypted data.
Far too often teams feel it’s good enough to have some external testing and a patch management program. Robust security requires a defense-in-depth approach where architects ask what-if questions about failures. For example, “what if there’s a bug in our access control?” Or, “what if a hacker gets access to our production network?”
AppSec without layers is like cereal without milk: better than nothing, but sadly inadequate.

Why Security Layers Matter

Application-Layer Encryption Implementation Choices

1. Code vs. Proxy

Encryption/decryption can either happen inside the application with direct calls to encrypt() or decrypt() routines, or a separate service can be used to intercept communications to a storage service and encrypt/decrypt data on its way through. Both are valid and have their own risks and challenges to make sure protection isn’t easily undermined.

2. Client vs. Server

Client-side encryption is a form of ALE that, if implemented properly, uses end-to-end encryption to create zero-trust data systems. ALE can also be implemented as a server-side encryption scheme with gated access to keys and strong audit trails on data access. For both, the question of who holds and controls the keys is critical.

3. Key Management

Key management is the Achilles heel of most ALE schemes. Key reuse is tempting. Key rotation is often poorly managed. Access to keys is often widespread. Some implementations put keys in the database instead of a key management service. Strong implementations use layers of keys that work together with the top layers segmented by type of data and tightly controlled.

Understanding Application-Layer Encryption

When companies claim to encrypt data “at-rest”, they likely mean they’re using some form of transparent disk encryption or transparent database encryption. This is what you get when you check the encryption box on AWS, GCP, or Azure. But this does nothing to stop access to the data on a running server.
Transparent encryption protects data on a powered-down hard disk only. The value of this comes into play when hard drives are lost, stolen, or go bad and need to be thrown away.
Application-layer encryption is at-rest encryption, too, but unlike its transparent cousin, it protects data on a running server from live attackers. With ALE, you get a backstop against network breaches, application vulnerabilities, misconfigurations, injection attacks, overly curious admins, subpoenas, and stolen credentials.

4 Benefits of Application-layer Encryption with IronCore Labs

IronCore’s products provide the strongest security possible for client-side ALE and server-side ALE with advanced key management, data transparency, access controls, and more. We do the key management, the encryption, and the data handling right. Additionally, we bring these benefits:
  1. Virtually Isolate Customers
  2. Search on Encrypted Data
  3. Customer-held Encryption Keys
  4. Get Started Quickly

1. Virtually Isolate Customers

A multi-tenant architecture allows a cloud application provider to use the same resources (databases, application servers, etc.) for multiple customers. This makes sense from cost, management, and scaling perspectives, but it adds risks of data contamination and data leaks between customers (tenants).
In these multi-tenant systems, the burden for enforcing customer data isolation falls on the app. And this works just fine most of the time. But a single injection attack can end up exfiltrating the data of all customers at once. And logic errors have no backstop.
Application-layer encryption where each tenant has a dedicated key (optionally held by the customer with CMK) brings virtual isolation of data. It’s as if you have a separate database or filesystem or key-value store for each customer without the hassle and expense of actually spinning up all those machines.
With virtual tenant isolation, no request can fetch data from multiple customers at once.
IronCore’s SaaS Shield makes it easy to implement strong tenant security and data isolation.

2. Search on Encrypted Data

One potential issue with application-layer encryption is the inability of the database to make sense of the data. So if you encrypt data before storing it in a SQL database, you won’t be able to use SQL to filter on that data.
For many, this blocks their ability to adopt the better data protection and appsec that ALE provides.
However, if the data you’re encrypting is fundamentally text, such as names, emails, addresses, usergenerated content, file attachments, and so forth, then you can still operate on that data, even after it’s encrypted.
Cloaked Search is a product that allows you to index all of your encrypted data and to search it using Elasticsearch or OpenSearch without breaking the properties of application-layer encryption.

3. Customer Managed Keys

More sophisticated customers have their own policies around encryption. They want to control their data by managing the keys that encrypt the data. There are a number of different schemes around Customer Managed Keys (CMK), Bring Your Own Key (BYOK), Enterprise Key Management (EKM), and so on.
Of these, the strongest and generally the best is to allow customers to either manage or to hold their own encryption keys. This is sometimes called Bring Your Own Encryption (BYOE) or Customer Held Encryption Keys (CHEK). Whatever you call it, IronCore helps you deliver it to your customers.

4. Get Started Quickly

It’s easy to add application-layer encryption. For server-side encryption, per-customer encryption, and customer managed keys, check out IronCore’s SaaS Shield product. For the fastest start, we offer drop-in protection for your data stored in AWS S3 buckets.
And if you’re looking for zero-trust application-layer encryption or end-to-end encryption solutions, check out our Data Control Platform, which has support for a large number of platforms, languages, file types, and use cases.
Talk to us to learn more.

Products

Documentation

Trust Center

Find Us