5 reasons to use application-level encryption to prevent data leaks in fintech

Facing a blend of old and new regulations, fintech companies, neobanks, and banks-as-a-service use application-level encryption (ALE) to encrypt transaction data, PII, and data sensitive with payments and accounts context. What Pro’s and Con’s application-level encryption has compared to the traditional database data-at-rest encryption?

First, nowadays, encrypting the file system against someone stealing disks from your data centre and setting up TLS is not enough. To prevent data leaks, modern fintech are to elaborate their encryption strategy and meet new regulatory requirements, threats & attack techniques, as well as customers’ expectations. That is where you face application-level encryption (ALE), field-level encryption, client-side encryption, and end-to-end encryption. 

Each of these terms points to a combination of data flow choices and security guarantees. ALE means that data is encryption on the application-side that uses this data. Application encrypts the data before sending it via network, and data goes encrypted through all services, is stored in a database encrypted – until another application (or the same one) decrypts the data. ALE doesn’t depend on TLS / data-at-rest encryption and peacefully co-exists with them. Thus, your data security doesn’t depend on infrastructure settings or database configuration.

Client-side encryption means that encryption happens on client-side applications. End-to-end encryption happens on client apps in a way that no secrets or keys are available to the server-side. Read this article to get much deeper in security details.

Secondly, using TLS between various components of your infrastructure is a necessary measure, but TLS only protects you from eavesdropping between services. While ALE keeps data encrypted as long as you choose—up to a fully end-to-end encrypted lifecycle.

Thirdly, in one shot, ALE (as well as data tokenisation / pseudonymisation) covers most data-related risks, like physical disk access; adversarial system administrator or DBA; a database-level leakage risks; leakage through logs, snapshots, and automated backups; data in transit between application components. 

At the same time, with ALE you gain greater agility and more control on performance and capacity impact. You can encrypt only what needs protection, leaving meta-data in plaintext.

Fourth, ALE lets you trust your infrastructure less. ALE implements data protection on all underlying layers, including all layers of storage and sometimes transit. Outdated TLS settings or expired TLS certificates won’t lead to data leaks when the data is application-level encrypted.

Also, ALE provides a higher level of security against insider and advanced adversary risks. Think about the risks of insiders or privileged adversaries gaining access to the database in processing financial transactions and storing transaction data.

And finally, using ALE simplifies compliance and makes implementing regulatory requirements helpful in other practical goals. ALE is becoming a good practice for systems with increased security requirements, with a general drift toward perimeter-less and more exposed cloud systems. We can expect to see requirements for deeper integration of encryption arrive in general and industry-specific regulation.

This comes at a price: implementing ALE is harder than just ticking a few boxes to set up TLS or database encryption: it’s easier to get it wrong. Yet, with correct tools and design choices, ALE reaps more benefits with less performance overhead than many other approaches. 

---

This blog post is written by Pavlo Farb, a Security Engineer at Cossack Labs. We help companies to protect their sensitive and valuable data.