Application-layer encryption explained
Have you ever wondered why personal data keeps getting stolen from companies? It's because they aren't using encryption properly.
ALE Defined
It's a pattern that protects data on running machines
The layers problem
There's a disappointing lack of layers between attackers and data
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.
Applications inevitably have vulnerabilities, as do their underlying libraries and surrounding environments.
These are complex systems created by human beings. Mistakes and unanticipated behavior are the norm. Security teams do what they can to mitigate the issues. In practice, this often means relying on tools like WAFs to stop threats.
But WAFs can be evaded easily, are often an additional surface area for attacks. And they can't defend against application-specific errors. A data disaster is just a single flaw away.
Aspects of AppSec
Application security has five main concerns
AppSec is what you do to develop and ship a secure application, which should mean any application. There are five primary parts:
- Patch management: keep dependencies and environments up-to-date with security fixes, and vette dependencies.
- Secure development lifecycle (SDL): everything from developer training to security-related architecture reviews to security-based QA.
- Testing: automated code scanning for common vulnerability patterns and external penetration tests.
- Product features: security or privacy related features such as single-sign on and multi-factor authentication.
- Application-layer encryption: to protect the data even when an attacker gains access to a database.
Far too often teams feel it's good enough to have some code scanning and a patch management program. That's only two of the six AppSec concerns.
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?"
The numbers
The current approaches are failing horribly
- * Source 1: Ponemon Cost of a Breach Report 2020
- ** Source 2: GitHub Octoverse Security Report 2020
Meaningful protection
Not all encryption is equal
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.
Implementation patterns
Mix and match to create your ideal ALE implementation
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.
Benefits
It's more than just data protection
4 benefits of ALE with IronCore Labs
IronCore Labs' 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 the right way. Additionally, we bring these benefits:
- Virtually isolate customers
- Search on encrypted data
- Customer-held encryption keys
- 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 Labs' 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.
Cloaked AI is a product that allows you to encrypt vector embeddings used in machine learning as well as their metadata and still operate over them with nearest neighbor searches, filters, etc.
Deterministic encryption is a feature that allows you to filter or find data via exact matches.
3. Customer managed keys (CMK/BYOK/HYOK)
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 Hold Your Own Key (HYOK) Bring Your Own Encryption (BYOE) or Customer Held Encryption Keys (CHEK). Whatever you call it, IronCore Labs 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 Labs' 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.
