"The use of database encryption has expanded dramatically over the past 18 months and is poised to continue this growth curve. Enterprises are facing a growing regulatory and risk storm which has led to top down executive mandates to encrypt personal and confidential information where ever it is stored," says Gretchen Hellman, vice president of marketing and product management for Vormetric. "In addition, the primary inhibitor to using database encryption was performance concerns. Technical advances and the maturing of database encryption solutions have removed that objection. "
However, there is still plenty of room for improvement. In the database realm, encryption is just barely used by a majority of organizations. According to a recent Ponemon Institute study, 43 percent of organizations have not adopted database encryption technology, a figure hackers surely love.
"Encrypting databases is very important because databases are one of the best targets for hackers. They prefer to get millions of credit card numbers all at once rather than intercepting them one at a time, and a million or more records at once is what they can get from hacking a database," says Luther Martin, chief security architect for Voltage Security.
The question even among current adopters is how effective are their deployments? With so many options available from native database encryption to column-level tokenization, the choices for obfuscating or hiding data is dizzying. And when organizations don't employ best practices with their particular choice, their costs and complexities go up and the risk of a breach may not even necessarily go down. Today many of the earliest adopters of database encryption are starting to see the limitations of their choices, experts say.
As an example, organizations that depend on native database encryption tools are starting to bump into limitations with regard to centralized management and separation of duties if they aren't paired with third-party key managers and hardware security modules, Hellman says. As a result, earlier adopters of native tools are beginning to shift into other deployment models.
"One big change is people moving away from native database encryption to encryption using other approaches. This can be more secure, because you don't need to store either the encryption keys or the authentication credentials needed to get the keys in the database," Martin says. "And it lets you use some of the more recent innovations like Format-Preserving Encryption. Doing that doesn't require schema changes and preserves referential integrity in the database."
Additionally, many kinds of encryption technologies that cropped up around regulations such as PCI and designed to establish column-level encryption are starting to creak under pressure as the type of data required to be protected expands, Hellman says.
Consider the Sony breach, for example, which involved a database that did utilize some form of encryption but not enough. "The Sony breach is a strong example," Hellman says. "They had encrypted the table with credit card numbers as was required by PCI DSS, but user names, passwords, birthdates, and other private data was not encrypted."
The lack of thoroughness and cohesiveness within today's database and overall encryption deployments is perhaps one of the biggest challenges organizations face in making their encryption dollars money well spent, says Ulf Mattsson, chief technology officer for Protegrity. "Currently, organizations are using point solutions [database vendor-specific solutions or a solution that covers only few platforms in the organization] for encryption that are creating isolated islands which are costly to deploy, operate and audit. Because point solutions form isolated islands, the dataflow cannot be fully protected, introducing new attack points and vendor lock-in."
These islands can also wreak havoc on efforts to manage the jumbled mass of keys that enterprises collect for decryption. The decades old problem of key management continues to plague organizations to this day.
"Correctly implemented, encryption is nearly impossible to break, and the original data cannot be recovered without the key," writes Adrian Lane, analyst for Securosis, recently wrote. "The problem is that attackers are smart enough to go after the encryption keys, which is much easier than breaking good encryption. Anyone with access to the key and the encrypted data can recreate the original data."
This is partially why many organizations are turning to tokenization to protect regulated data within the enterprise, as it is irreversible. However, the debate of tokenization versus database encryption actually emphasizes another core problem with enterprise mentalities regarding database encryption. Security experts need to battle the "either-or" attitude pervasive about different encryption types and start developing a layered strategy just like for any type of security solution, Lane says.
"In most cases it’s not an either/or proposition. If you have sensitive information, you will be using encryption somewhere in your organization," he says. "If you want to use tokenization, the question becomes how much to supplant encrypted data with tokens, and how to go about it."
This approach holds for not only encryption within the database, but also across all of the other places data crosses within the infrastructure.
"Our clients are realizing that comprehensive, persistent, and end-to-end encryption is necessary across an organization to truly secure data," says Patrick McGregor, senior vice president of product management and encryption for Trustwave. "Limited solutions that focus only on a specific system, like databases, will fail to protect against many destructive threats."
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.