Remember this scene from the Richard Donner Superman movie of 1978? After a freak helicopter accident, Lois Lane falls from a tall building. Out of nowhere, Superman makes his debut, calmly telling Lois, “Easy, Miss, I’ve got you!" She panics, yelling, “You've got me? Who's got you?” Superman smiles, then flies her to safety.
Of course, Superman is the Man of Steel: invincible, indestructible, unexploitable. Unfortunately, most things in our lives are not that robust.
In my earlier roles as a software developer, a QA tester, and later an architect, security and data protection were perceived very simply: We assumed someone else was taking care of the sensitive data by providing a transparent layer of protection (presumably encryption) somewhere down the stack.
My team didn't care about it as long as it did not impact application functionality and performance. We also held a firm belief that encryption was generally a hindrance, and that any non-transparent encryption would:
- Break function
- Impact database schema and storage requirements
- Degrade application performance.
In my more recent role of securing data in public clouds, especially SaaS, my passion changed to data protection: encryption, tokenization, and cryptography in general. In one role, I made a strategic decision to encrypt data at the application layer (elevating from the traditional approach of storage-level or transparent database file-level encryption). The application teams were, predictably, uncomfortable about shifting responsibility up the stack. But with time, detailed prescriptions, and definitive proof, we were able to allay their concerns.
Here's why key and secrets management remains a problem, and a three-pronged strategic approach to adopt for better data protection.
Why shifting data protection up the stack matters
Enterprises that process and store sensitive data—PCI, PII, PHI, et al.—and that do not have a shift-up-the-stack encryption strategy are fooling themselves by thinking that encrypting at the database, file, or storage layer is providing real protection. Such a strategy really only protects against someone stealing the physical disk. And it may satisfy auditors by demonstrating that the data is encrypted at rest. It does nothing to prevent data exfiltration, or to avoid breaches through attacks either from privileged insiders (database administrators, for example), or external attacks (OWASP Top 10) that exploit application vulnerabilities.
Now, this is not a novel data-protection strategy to minimize the impact of data breaches when they occur (remember, it’s a matter of when, not if). So, what is the crux of this strategy that was crucial on top of encrypting data at the application layer?
Application teams have been performing encryption at the application layer for a while, leveraging cryptographic libraries that come with the platform, standard encryption algorithms, and application-generated keys. This is a common model, and means developers do cryptographic stack and key management—in most cases, sub-optimally. This is not what are they hired and paid for, and hence they lack expertise in these critical areas.
Most enterprise application-level encryption implementations follow the same model: Generate a data encryption key (DEK) at the application layer (in some cases, from a hardware security module, or HSM) and store it in a properties file (or, in more than a few cases, hard-coded in the application itself), and encrypt the sensitive data.
Some developers are better than the rest when it comes to key management, and use another key to protect the DEK; ideally that key encryption key (KEK) is stored someplace else—not within the same properties file that stores the DEK, perhaps even in a database.
In very rare cases, in organizations that have a better security posture, that KEK may be protected with a password or some sort of secret, thus adding more defense in depth. Or the KEK is stored in a centralized key management system (KMS) or HSM, and fetched repeatedly to protect and unprotect keys during read and write operations. To fetch these keys, applications must authenticate to the KMS or HSM, which involves passing secrets such as passwords or API keys, which themselves must be stored someplace.
So, what’s wrong with this model?
Enter Superman. Lois Lane is the crown jewel (the sensitive data that needs to be protected), and Superman is the savior (the data encryption key). We know that Superman could do the job. But remember that most things in our life aren’t Superman-ish: In his role as the DEK, he needs to be managed and protected—after all, what’s the point of locking the door if the door key is left under the doormat?
So now if we have a KEK (Superman) to protect the DEK (Lois), as in the middle scene, the same problem arises: Who’s got his back? Typically, as we shift to the right and the roles change yet again, with Lois as the KEK, Superman is played by a “not nearly close to a Man of Steel” password or some secret, managed by a developer or database administrator. And that password or secret has an even greater chance of being poorly managed and exposed. Like any chain, the true strength is that of the weakest link. Where is our Superman now?
This illustrates that we create layers of depth with our defenses, but at the end of the chain, someone will always be Lois Lane, the “weak” damsel in distress who needs a Superman to rescue her—and we typically run out of Supermen at some level. So what do we do? Fortunately, there is a light at the end of the tunnel.
Modern, strong encryption is never cracked, but often bypassed. Experts say, “Encryption is easy; key management is hard.” I extend that phrase to include secrets management as well. It doesn’t matter how much encryption we do: if the keys and/or credentials to the keys are not well protected, it doesn’t take much for a hacker to obtain our crown jewels, resulting in significant impact on the business and its reputation. Adequate key and secrets management are just as important as implementing strong cryptography. Not doing so is all too often the Achilles’ heel of enterprise data security and privacy programs.
Here's a three-pronged approach to adopt.
1. Shift up the stack
Apply application-level data encryption for all critical sensitive data processed and stored by applications, at the field level (along with encryption of sensitive unstructured data), at the application tier, so that data travels and is stored in an encrypted state.
This minimizes risk of data breach due to insider threats (privileged users with access to databases and file systems) and external attacks via the various OWASP Top 10 web application security risks (SQL injection et al.), and also protects sensitive data in data warehouse systems, big data analytics nodes, backups, and archives.
The approach is to de-sensitize the data as much as possible, so that even if breached, it’s of no value to the attacker.
2. Abstract key management from developers
Application teams should not be involved in managing (storing, protecting, rotating) encryption keys, nor should they be allowed to have the knowledge or possession of actual keys. They should be provided with a key identifier or pointer, and provided with an abstraction layer that performs the crypto functions and key management—automating key generation, retrieval, caching, protection, and refresh.
3. Abstract secrets management from developers
Application teams should not be involved in managing (storing, protecting, rotating) secrets such as passwords, API secrets, etc. that allow them to consume encryption services, or connect to databases, nor should they be allowed to have direct possession of these secrets: they should be stored and managed within an enterprise vault, and developers should be offered SDKs and APIs to retrieve secrets from the secrets vault programmatically. The vault solution should also allow periodic rotation of secrets without impacting applications.
You don't need Superman, but you do need a solid data protection program
Enterprises must adopt the right security solutions and services, whether operating in an on-premises, hybrid, or cloud-only mode. Most major cloud service providers are now offering KMS and secrets vault services, which provide adequate management of secrets such as passwords, API keys, etc. Other COTS solutions implemented within enterprises can also provide abstraction of key and secrets management from developers. Enterprises must evolve solid strategies that leverage these tools and services to implement solid data-protection programs, with robust key and secrets management (Superman), to protect their crown jewels (Lois Lane).
Keep learning
Get up to speed on unstructured data security with TechBeacon's Guide. Plus: Get the Forrester Wave for Unstructured Data Security Flatforms, Q2 2021.
Join this discussion about how to break the Ground Hog Day repetition with better data management capabilities.
Learn how to accelerate your analytics securely into the cloud in this Webinar.
Find out more about cloud security and privacy, and selecting the right encryption and key management in TechBeacon's Guide.
Learn to appreciate the art of data protection and go behind the privacy shield in this Webinar.
Dive into the new laws with TechBeacon's guide to GDPR and CCPA.
