Application Security // Database Security
2/12/2013
11:13 PM
Connect Directly
RSS
E-Mail
50%
50%

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
Comments
Newest First  |  Oldest First  |  Threaded View
Townsend Security
50%
50%
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 - http://hub.am/152aYqd
solcates
50%
50%
solcates,
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
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-7392
Published: 2014-07-22
Gitlist allows remote attackers to execute arbitrary commands via shell metacharacters in a file name to Source/.

CVE-2014-2385
Published: 2014-07-22
Multiple cross-site scripting (XSS) vulnerabilities in the web UI in Sophos Anti-Virus for Linux before 9.6.1 allow local users to inject arbitrary web script or HTML via the (1) newListList:ExcludeFileOnExpression, (2) newListList:ExcludeFilesystems, or (3) newListList:ExcludeMountPaths parameter t...

CVE-2014-4326
Published: 2014-07-22
Elasticsearch Logstash 1.0.14 through 1.4.x before 1.4.2 allows remote attackers to execute arbitrary commands via a crafted event in (1) zabbix.rb or (2) nagios_nsca.rb in outputs/.

CVE-2014-4511
Published: 2014-07-22
Gitlist before 0.5.0 allows remote attackers to execute arbitrary commands via shell metacharacters in the file name in the URI of a request for a (1) blame, (2) file, or (3) stats page, as demonstrated by requests to blame/master/, master/, and stats/master/.

CVE-2014-4911
Published: 2014-07-22
The ssl_decrypt_buf function in library/ssl_tls.c in PolarSSL before 1.2.11 and 1.3.x before 1.3.8 allows remote attackers to cause a denial of service (crash) via vectors related to the GCM ciphersuites, as demonstrated using the Codenomicon Defensics toolkit.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Where do information security startups come from? More important, how can I tell a good one from a flash in the pan? Learn how to separate ITSec wheat from chaff in this episode.