Application Security // Database Security
11:13 PM

Database Encryption Depends On Effective Key Management

You wouldn't leave your keys in your car—so don't leave encryption keys stored next to the database

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.

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Townsend Security
Townsend Security,
User Rank: Apprentice
2/19/2013 | 12:07:03 AM
re: Database Encryption Depends On Effective Key Management
As a data security company that offers encryption key management, we see organizations leaving their "keys under the mat" all the time.- It is surprising how often a level 1 merchant comes to us because their auditor finally dinged them on how they have been managing their encryption keys.- What's even more scary is when a company comes to us, puts their encryption and key management project on hold, and then sees their name in the headlines after a major breach.- And this has happened more than once.- We recently put together a collection of encryption key management resources to help organizations better understand key management and that it doesn't need to be a costly or difficult project -
User Rank: Author
2/13/2013 | 10:42:00 PM
re: Database Encryption Depends On Effective Key Management
Another key problem(no pun intended), with Encryption and Key Management, is that not only must the key be protected, but it must be available. -Availability denotes access must be given to the key for the intended use, and not-malicious use. -

In the firewall world we have accomplished access to network resources via a criteria-effect based model. A Data Firewall should be applied around the data itself. -Allow only approved-behaviors-to access the data in a clear format to accomplish their business function(i.e. the Database Engine, not privileged users)

Abstracting Key Management from individuals and processes can be achieved with the right architecture. -This increases scalability, reduces management complexity, and ensures keys are not vulnerable to the users and processes that leverage them.
Manage your encryption and keys via policy; not via people and process.
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
5 Security Technologies to Watch in 2017
Emerging tools and services promise to make a difference this year. Are they on your company's list?
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2015-10-15
The Direct Rendering Manager (DRM) subsystem in the Linux kernel through 4.x mishandles requests for Graphics Execution Manager (GEM) objects, which allows context-dependent attackers to cause a denial of service (memory consumption) via an application that processes graphics data, as demonstrated b...

Published: 2015-10-15
netstat in IBM AIX 5.3, 6.1, and 7.1 and VIOS 2.2.x, when a fibre channel adapter is used, allows local users to gain privileges via unspecified vectors.

Published: 2015-10-15
Cross-site request forgery (CSRF) vulnerability in eXtplorer before 2.1.8 allows remote attackers to hijack the authentication of arbitrary users for requests that execute PHP code.

Published: 2015-10-15
Directory traversal vulnerability in QNAP QTS before 4.1.4 build 0910 and 4.2.x before 4.2.0 RC2 build 0910, when AFP is enabled, allows remote attackers to read or write to arbitrary files by leveraging access to an OS X (1) user or (2) guest account.

Published: 2015-10-15
Cisco Application Policy Infrastructure Controller (APIC) 1.1j allows local users to gain privileges via vectors involving addition of an SSH key, aka Bug ID CSCuw46076.

Dark Reading Radio
Archived Dark Reading Radio
In past years, security researchers have discovered ways to hack cars, medical devices, automated teller machines, and many other targets. Dark Reading Executive Editor Kelly Jackson Higgins hosts researcher Samy Kamkar and Levi Gundert, vice president of threat intelligence at Recorded Future, to discuss some of 2016's most unusual and creative hacks by white hats, and what these new vulnerabilities might mean for the coming year.