Welcome Guest. | Log In | Register | Membership Benefits

The State Of Database Encryption

Many early adopters of database encryption are starting to realize limitations of their choices

Jun 02, 2011 | 10:00 AM | 

By Ericka Chickowski, Contributing Writer

With database breaches on the rise and auditors getting tougher about data protection practices, the pressure on organizations to encrypt sensitive databases has picked up steam considerably over the last few years. In order to not only get auditors off your organization's back but also actually mitigate the risk of a disastrous breach, enterprises must consider the important details of an encryption deployment.

"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.



Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dark Reading encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dark Reading moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. Dark Reading further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
Subscribe to RSS



Database Security Reports

report Securing The Data Warehouse
Many enterprises are building data warehouses to centralize the ever-increasing information flowing through their organizations into useful repositories. This makes good business sense, but it opens up a slew of concerns from a security standpoint. IT professionals can apply many of the same security best practices used with databases, but there are new lessons to be learned as well.

report Defend Your Data From Malicious Insiders
The biggest threat to your company?s most sensitive data may be the employee who has legitimate access to corporate databases but less-than-legitimate intentions. And while the incidence of insider data breaches has decreased, external attacks often imitate them--and do serious damage. Follow our advice to mitigate the risk.

report Ensuring Secure Database Access
Role-based access control based on least user privilege is one of the most effective ways to prevent the compromise of corporate data. But proper provisioning is a growing challenging, due to the proliferation of "big data," NoSQLdatabases, and cloud-based data storage.

Other reports from the Database Security Tech Center:

Related Content

Establishing a Strategy for Database Security is No Longer Optional
As databases continue to grow in size, complexity and importance, enterprises struggle to identify the most appropriate controls regarding their use and misuse. The report identifies best practices, including: Implementing database activity monitoring to mitigate the high levels of risk from database vulnerabilities, and address audit findings in areas such as database segregation of duties and change management; using data security measures, such as data masking and data encryption; and monitoring privileged-user access and access to critical data.

Database Activity Monitoring Is Evolving Into Database Audit and Protection
In this report, Gartner writes that "Database audit and protection (DAP) represents an evolutionary advance in database activity monitoring tools." DAP suites provide comprehensive, cross-platform support in heterogeneous database environments to protect sensitive data from inappropriate use. Organizations are increasingly concerned with optimizing database security and mitigating risks associated with database vulnerabilities.

Protecting Against Database Attacks and Insider Threats: Top 5 Scenarios
Data security presents a multi-dimensional challenge in today's complex IT environment. Multiple access paths and permission levels have resulted in a broad array of security threats and vulnerabilities. We invite you to read this new eBook: "Protecting against database attacks and insider threats" to learn the top five scenarios and essential best practices for preventing database attacks and insider threats.

Demo: Distributed Database Security with Real-time Monitoring and Audit Protection
Organizations across the globe continue to experience compromised data caused by malicious attacks, web application vulnerabilities or unauthorized changes. View this demo and learn how IBM InfoSphere Guardium? database activity monitoring can help protect your sensitive data in distributed DBMS environments with a holistic approach to data security and compliance.

Look Beyond Native Database Auditing To Improve Security, Audit Visibility, And Real-Time Protection
Today's attacks on enterprise databases are more sophisticated than ever, and they occur so fast that it's often difficult to stop them in real time. Despite significant efforts to protect enterprise databases, the number of records breached has grown each year - due to all types of internal and external attacks and violations of corporate policy.




Featured Webcasts
Featured Whitepapers
Featured Reports