3 Truths about Encryption and BYOK
Many people making important decisions about data security have a fuzzy understanding of how encryption actually works. Their confusion can easily be exploited by hackers, governments, and vendors pushing incomplete solutions.
That’s because, on the surface, encryption seems reasonably easy to understand with real-world analogies to keys, locks, secrets (both good and bad), and safe-crackers (good, bad, and questionable).
As you dig deeper, though, encryption quickly gets opaque. Even for the security experts with whom I work every day, discussions of algorithms, key management, cipher text, salts, hashes, and anonymization, can be strenuous and taxing.
To give you a clear path forward through the maze of information, I’ve created 3 simple truths about encryption that separate fact from fiction.
Truth #1: Your cloud data is rarely at rest.
If you encrypt data-in-transit and data-at-rest, then you’ve covered both ends of the spectrum and have complete security coverage, right?
Wrong. Protecting two end points does not equal “end-to-end” security. That’s because most vulnerabilities are in the middle, involving data-in-use, i.e., data after it has been delivered to the cloud but before it’s stored at rest. This wide middle area encompasses people (some of whom are unhappy inevitably), processes (some of which have flaws), third-party tools (often with mysterious details), and even government subpoenas demanding access.
The Cloud Security Alliance (CSA) publishes an annual list of “Top Threats” that includes account hijacking, malicious insiders, insecure APIs, insufficient identities, and data breaches and loss. You address none of these threats by merely encrypting data-at-rest.
Data-at-rest encryption protects data when it’s not being used and is stored on physical media. That’s no skin off a hacker’s nose, because hackers aren’t stealing hard drives from data centers. They’re breaking into the application layer and stealing credentials, exploiting weak APIs, and finding other security gaps. After all, why bother trying to crack strong disk encryption when you can go through the application and steal data outright?
TAKEWAY: Remember the middle. That’s where the action is.
Truth #2: Cloud encryption is not what you think.
Moving to the cloud lets you outsource infrastructure, application maintenance, and physical security, all of which bring clear business benefits. Outsourcing data security, though, requires more caution because a cloud provider rarely will share your legal responsibility to protect sensitive or regulated data.
Most cloud providers should and do encrypt data-in-transit and data-at-rest. Those measures are mere table stakes.
The rapid growth of the CASB (cloud access security broker) space has raised awareness that you shouldn’t put all your security eggs in one basket. CASB systems provide a range of intermediary security services between enterprises and business-critical cloud applications, including data encryption that separates the encryption process from the cloud service provider.
Many cloud providers have mixed feelings about CASB vendors. They like enhancing the overall security story but are reluctant to allow anything between the customer and their service. For this reason, cloud vendors like Microsoft and Salesforce have launched “native” encryption services that allow customers to specify specific fields or files to be encrypted when at rest. While these add-on services can improve security, they lack a fundamental separation of duty. The same entity that stores the data also encrypts it and holds the keys. Because the data is encrypted at rest only, the cloud service decrypts the data on-demand, whenever it’s not at rest.
TAKEAWAY: Keep the encryption process separate from cloud service provision.
Truth #3: BYOK: You bring your keys—and share them with outsiders.
To increase customer confidence, some cloud providers have added BYOK (bring your own keys) options that allow customers to generate keys locally and have more direct control over key management.
Encryption keys are viewed as shorthand for security: “Keep your keys, and your encrypted data will be safe.” While that’s true, it’s not the whole truth. It’s also true that where the encryption takes place and whether you share those keys matter immensely. Generating and storing your own keys are good practices, but if you share those keys and allow remote decryption, you undermine most of the security value of the keys.
At face value, cloud BYOK offerings let you “keep your own keys”. In reality, they don’t let you keep the only copy. The keys are shared on-demand with the cloud service. Imagine changing the locks to your house and getting new keys cut at your hardware store to make your home more secure. Now imagine making lots of copies of these keys and sharing them with several vendors that want access to your house. Putting copies in the hands of many third parties opens your home to vulnerabilities, making your brand new keys less effective.
If you share keys, all you have is a promise, not a guarantee. Promises are good but not legally binding. “The vendor promised that data wouldn’t get stolen” isn’t a valid defense if you’re charged with a HIPAA, GLBA or PCI violation.
TAKEAWAY: Keep the keys to yourself.
In summary–Go Beyond Protecting Data at Rest
If you aren’t comfortable with outsiders having access to your sensitive data, then stick with these uncompromising principles to make encryption effective:
- Never share your encryption keys.
- Separate the encryption process from the cloud provider. If BYOK = SYOK (share your own keys) with a third party, the value of encryption is negated.
- Implement multi-cloud security policies. We all work across multiple clouds and apps like Salesforce that connect and share data with hundreds of external applications and processes.
Understand when your data will be encrypted and when it will be in the clear. Data-at-rest encryption is just table stakes. Most of today’s threats target active data, in-use by applications, APIs, third-party tools, and more.