Database Encryption Depends On Effective Key Management

Increasingly enterprises are heeding regulators' calls for stronger database encryption to keep information protected from wide scale breaches. But without solid key management practices, these organizations may find that their move to encrypt more data stands as nothing more than an empty gesture.

"Key management is the very most important part of encryption," says Pravin Kothari, CEO of CipherCloud. "If you don't handle the keys right, then it's better to just keep the information unencrypted and in plain text."

The shared secret between an encrypted system and an authorized user or account, encryption keys are what make it possible to carry out the most difficult cryptographic feat of all: safely decrypting the data once it has been obfuscated. This makes these keys awfully valuable. If organizations don't take care where and how they are stored, they leave the encrypted data vulnerable to theft or to permanent loss if the keys are misplaced.

"Encryption is really quite straightforward. Encryption is just a mathematical process of converting a set of data into a different set of data," says Richard Moulds, vice president of product management and strategy for Thales e-Security. "Key management is really where the brains need to be applied and where the pitfalls can occur. At the end of the day, keys have to be kept secret, otherwise the encryption was a waste of time in the first place."

And yet, Kothari would estimate that in his engagements with enterprises only about 20 percent of the most mature financial organizations really do encryption management well. Database encryption deployments particularly suffer from insecure key management due to scalability issues when dealing with native encryption on numerous databases and across multiple platforms.

[Are your backup databases putting your organization at risk? See Backup Databases: The Data Security Achilles Heel.]

"People get into trouble when the encrypted databases really start to proliferate," says Todd Thiemann, senior director of product marketing for Vormetric. "If you get above five databases, that gets to be a real headache to manage."

He says he's seen plenty of examples of organizations making key management missteps.

"In one episode, we witnessed where the SSH keys needed to get into Amazon were stored on an internal Wiki page," he says. "That's not a very good security practice. You need to get a handle on this stuff and to get some control over it so you can maintain a good security posture and demonstrate to your auditors that everything's on the up and up."

That starts with the cardinal rule of database encryption key management, which is to never store the keys on the same server as the database that's been encrypted using them.

"That's not much different than leaving your car with the keys in it," Kothari says. "It is very critical to keep control of the keys and keep the keys completely separated from the encrypted data."

Whatever location organization's do choose for storage, it should be secure and it also should be well documented and governed by the same kind of backup and recovery mechanisms as the ones used for the data itself. Because if the keys are misplaced or destroyed by a disaster, the data is as good as gone.

"Some of the horror stories that we hear really revolve not so much around security or keys being stolen, but rather keys being mislaid or lost," Moulds says. "If you lose those keys then you've basically scrambled that data forever. It's a surprisingly common occurrence."

Beyond storage, enterprises need to think carefully about governing who acts as administrator over those keys. Auditors will be looking for organizations to institution a separation of duties so that the same people in charge of the data, usually the DBAs, don't also have control over the keys.

"Typically DBAs are happy to offload that sort of responsibility since they're focused on maintaining the database and they're happy to hand that off to the security team," Thiemann says.

Kothari recommends not just a separation of duties, but an added layer of security by ensuring that there are multiple custodians overseeing the keys. That way should something happen to one administrator or that administrator goes rogue, there is a set of checks and balances to ensure that someone else can recover the keys.

"You need to have multiple custodians so that a single one custodian can't control access to the data," Kothari says.

Control over the keys has also heightened into bigger issue in the cloud era, Kothari says. In many situations, organizations allow their cloud provider to control the keys but he believes organizations need to take their key management to "the next level" and maintain control over the keys when encrypted data rests on a cloud provider's infrastructure.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.