Database encryption demystified: Four common misconceptions

With new attacks being publicized daily, organizations that eschew data encryption as an integral part of their security strategy risk losing almost everything.
Written by Ashvin Kamaraju,, Contributor
Commentary - Data encryption has become a necessary component to most enterprise data security strategies. Enterprises can no longer rely on basic authentication and access control tools to protect sensitive data, as was commonplace five or so years ago when they only had a handful of databases to oversee. Today, companies are dealing with hundreds, even thousands, of databases, many of which have been replicated *ad infinitum* to virtualized servers, archives and disaster-recovery sites, both onsite and in the cloud.

Currently a single database may have 10,000 connections, more than even the most skilled DBA could manually monitor. Nor can databases discern between hackers and authorized users. If a database is accessed using the right username and password, information is made available regardless of whether the identity is stolen. And to make matters more precarious, databases store data in clear text within the database files, so that someone with malicious intentions can, with a little effort, access the data at rest without having to connect to the database.

Protecting database information at rest with encryption is a must for any organization responsible for critical information. It offers an added layer of protection from a multitude of threats, both internal and external. By protecting databases at their core, the data itself is safeguarded no matter how many times the databases themselves have been replicated or moved to another location. And not only does data encryption help meet several compliance regulations, such as PCI DSS, SOX, HIPAA, and GLBA, among others, it also protects organizations from disclosure and penalties under many of the state data breach laws, including New York and California.

But in spite of the obvious benefits and protections database encryption supplies, many enterprises have failed to deploy it. Several reasons exist for hesitation, many of which are based on misconceptions and hearsay. Putting to rest the following four common misperceptions may spur organizations to implement a data encryption strategy in a clearer, more confident fashion.

All data encryption is created equal
Three types of database encryption are typically considered: column-level, tablespace or database level, and file-level.

Column-level database encryption is the best-known type of encryption because most database vendors include this type of data protection with their databases. Column-level encryption works by encrypting columns within a database. Third-party column-level database encryption solutions can protect columns across heterogeneous database environments that may include databases platforms like DB2, Sybase, SQL Server, and Oracle, among others.

Tablespace-level encryption methods for the most part provide more granular controls for safeguarding data than column-level encryption can. Tablespace-level encryption lets them encrypt all the data to which the tables are referring. Tablespace-level encryption offers administrators the ability to choose the data they want to protect, even if that data is being accessed by multiple columns within the table.

File-level data encryption works by protecting the actual database file. Rather than encrypting row-by-row or column-by-column, file-level encryption encrypts in file system block chunks. It decrypts data before it is read into the database’s cache, allowing databases and applications to work as if no encryption solution has been deployed. Unlike other types of data encryption, file-level encryption can protect database configuration and trace files as well.

Database encryption and performance impacts
As applications and systems become at once more complex and more agile, the pressure to serve real-time applications and data to customers and end users within an organization intensifies. As a result, any sort of performance lag can negatively impact business processes. Since database encryption could lead to performance degradations, especially with column level encryption it is understandable why an enterprise would be reluctant to add data encryption into their security mix.

But performance impact varies depending on the type of solution. Of the three types of encryption methods discussed above, column-level encryption typically leads to the greatest degradation in performance. The mechanisms used to encrypt columns are invasive, for example, incorporating triggers used to intercept the encrypted data, API calls outside of the database server, and in some cases require a network roundtrip to complete. The number of columns encrypted, and the actions performed on those columns, including such common ones as insertions, deletions, queries, updates, and table scans, can dramatically impact overall network performance.

Tablespace-level encryption does not affect performance to the degree that column-level encryption does; however, both methods’ adherence to the database schema still have the potential to modestly impact overall performance.

In contrast, file-level encryption protects data at the file level, which means that information is protected even if it is extracted from the database and stored in places like reports or in database trace files. It can show up in different forms, such as spreadsheets or email archives, and still maintain its protection. Because data is protected regardless of the form that it is in, it does not trigger complex mechanisms or require application changes. Moreover, file-level encryption does not depend on the number of columns, tables, or tablespaces being encrypted.

Encryption key management is problematic and challenging
Key management becomes a pressing concern to organizations running more than a few databases, particularly when doing so in a heterogeneous environment. The pain is typically not evident when only a handful of databases are involved, but becomes acute as the number grows. Key management can be reasonably easy to implement, provided that management is centralized and automated across multiple databases.

Several differences exist between third-party solutions and database vendor-provided ones. Vendor-provided solutions tie in key management functions from within the database and so typically work best if a data center is using only a single vendor’s databases.

In contrast, third-party solutions by nature are designed to work in heterogeneous database environments and typically offer key management functionality that takes place independent of and outside of the databases themselves. As a result, they are less likely to impact overall performance of the storage network.

All data encryption solutions provide separation of duties
Solutions that handle key management from within the database complicate the ability to establish and maintain proper role separation because they put DBAs in control of encryption keys, as well as the data itself. Moreover, a gap often develops between DBAs and IT security departments because the latter aren’t authorized to touch the databases and therefore, have to rely on the DBAs to implement the correct security measures. Ideally, the security group should define policies and procedures and monitor data encryption, while the DBAs should be able to implement these controls with minimal impact on their main role: administering databases.

Solutions that separate key management from database administration simplify the separation of roles between security, IT operations and DBAs. Third-party solutions manage keys in external files or appliances and provide granular reporting and administration capabilities to deliver a strong role-separation framework. They can also churn out reports based on varying criteria for DBAs, IT managers, security officers, and C-level executives, among others.

With new attacks being publicized daily, organizations that eschew data encryption as an integral part of their security strategy risk losing intellectual property, destroying consumer confidence, and finding themselves liable to fines and litigation. The right data encryption strategy shouldn’t be difficult to deploy or manage, let alone have a negative impact on overall business performance. In most cases the only real impediment that prevents organizations from adopting encryption as part of a defense-in-depth strategy are misconceptions based on out-of-date technology. Today’s encryption solutions, particularly file-based systems, are not your father’s encryption tools.

Ashvin Kamaraju is vice president of product development and partner management for data security vendor Vormetric

Video Resources:
Watch “Understanding Enterprise Encryption and Key Management", “Enterprise Systems Encryption: Getting it Right,” and “How to Encrypt Data in Financial Services Enterprises" webcasts that explain how encryption can prevent data breaches that plagued so many organizations in 2011 and what pitfalls to avoid.

Editorial standards