The first step to journey into data security is to become aware that software and architectures are changing, and so are data protection requirements in modern applications. New technologies, architectural patterns, advances in cryptography, and regulatory constraints all create new sets of requirements.
One of these sets of requirements is application level encryption, which is surfacing more and more lately in finance, healthcare (think about application-level end-to-end encryption for sensitive patient data), and others.
Where does it come from?
Changes in the threat landscape, attack techniques, and necessary security posture require us to think harder about preventing data leaks with encryption. Compliance requirements that don’t just mandate certain techniques to be implemented and demonstrated to auditors, but actually impose fines on organizations that leak sensitive data, drive increased requirements to protect the data properly.
Previous generation measures are just the starting point: encrypting the filesystem (data-at-rest encryption) protects against someone stealing disks from your data center and setting up TLS (data-in-motion encryption) prevents wiretapping and simple impersonation, but that’s it.
So, as architects explore options of doing more, they stumble upon the ever-ambiguous application-level encryption, field-level encryption, client-side encryption, end-to-end encryption requirement.
As CTO of data security company Cossack Labs, I deal with these concerns a lot both for our products and while helping customers choose their encryption-strategy wisely. In this article, I will walk you through the basics of different application-level encryption approaches, their pros and cons, typical mistakes, and threat models. Sometimes I will use existing software as an example and sometimes you will have to bear with me as we imagine completely new software designs!