Perimeter
7/23/2013
09:35 AM
Adrian Lane
Adrian Lane
Quick Hits
Connect Directly
RSS
E-Mail
50%
50%
Repost This

Choosing And Implementing An Enterprise Database Encryption Strategy

As long as your database information has value, you need encryption. Here are some tips for making enterprise database encryption work

[The following is excerpted from "Choosing and Implementing an Enterprise Database Encryption Strategy," a new report posted this week on Dark Reading's Database Security Tech Center.]

A lot of attention is given to securing database systems-- and rightly so: Databases are the target for attackers who wish to siphon off intellectual property, gather financial data that can be turned into cash and, in some cases, break in just for the sport of it. The attacks against computer systems are diverse, but the end target is typically the database.

The majority of research today centers on the security of database infrastructure -- in essence, the engine that stores, manages and serves data. But all too often we forget that it's the data an attacker is after. In fact, it's simpler -- and provides more universal protection -- to focus on securing the data as it's used, moved and stored than to worry about the complexities of different database systems used in your organization.

When you say "database encryption," what comes to mind? Encrypting data at rest? Perhaps you think of encrypted database backup, or maybe it's the Internet connection to the database. Actually, database encryption is all of these things. And there are several variations to each, providing slightly different advantages in terms of security, cost and performance.

Application-layer encryption
As the name implies, application-layer encryption is implemented by the application that uses the database to store information. Application developers usually leverage a third-party encryption library to encrypt data before it's sent to the database and to decrypt it when read from the database.

There are several advantages to this method of encryption. The data and the encryption keys are not stored in the database, so neither the platform nor database administrator can access them. In addition, the application developer decides how much data will be encrypted and with what level of granularity.

With all that said, this method of encryption has fallen out of favor with all but the most security-conscious of companies because it has some serious drawbacks: It's incredibly difficult to retrofit encryption at the application layer into a legacy application; every databaseread and write operation (SQL query) must be altered to use encryption, usually at tremendous cost in development time and testing. In addition, useful database features such as indexing don't work with encrypted data; as the encrypted output is random, the ordering of encrypted data elements will be, as well.

Finally, encrypted data is typically in binary format, meaning the tables must be reconstructed to accept binary instead of traditional text, date or monetary values. In short, application-layer encryption offers the greatest degree of security at the highest cost in complexity and implementation time.

Native database object encryption
All of the major relational database vendors offer one or more types of encryption. The first we call "native database object encryption," because the encryption engine resides inside the database. It's part of the database code, and you configure it to protect specific database objects (such as tables and schemas). Keys are held inside the database, in the system tables, so they are accessible to the database in the event of restarts.

The benefit of native object encryption is that it's an entirely self-contained encryption option. It's effective for media encryption because data is already encrypted before it's copied to storage drives or tape backups.

To read more about native object encryption -- as well as other encryption strategies and issues in implementation -- download the free report.

Have a comment on this story? Please click "Add a Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message. Adrian Lane is a Security Strategist and brings over 25 years of industry experience to the Securosis team, much of it at the executive level. Adrian specializes in database security, data security, and secure software development. With experience at Ingres, Oracle, and ... View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2008-3277
Published: 2014-04-15
Untrusted search path vulnerability in a certain Red Hat build script for the ibmssh executable in ibutils packages before ibutils-1.5.7-2.el6 in Red Hat Enterprise Linux (RHEL) 6 and ibutils-1.2-11.2.el5 in Red Hat Enterprise Linux (RHEL) 5 allows local users to gain privileges via a Trojan Horse p...

CVE-2010-2236
Published: 2014-04-15
The monitoring probe display in spacewalk-java before 2.1.148-1 and Red Hat Network (RHN) Satellite 4.0.0 through 4.2.0 and 5.1.0 through 5.3.0, and Proxy 5.3.0, allows remote authenticated users with permissions to administer monitoring probes to execute arbitrary code via unspecified vectors, rela...

CVE-2011-3628
Published: 2014-04-15
Untrusted search path vulnerability in pam_motd (aka the MOTD module) in libpam-modules before 1.1.3-2ubuntu2.1 on Ubuntu 11.10, before 1.1.2-2ubuntu8.4 on Ubuntu 11.04, before 1.1.1-4ubuntu2.4 on Ubuntu 10.10, before 1.1.1-2ubuntu5.4 on Ubuntu 10.04 LTS, and before 0.99.7.1-5ubuntu6.5 on Ubuntu 8.0...

CVE-2012-0214
Published: 2014-04-15
The pkgAcqMetaClearSig::Failed method in apt-pkg/acquire-item.cc in Advanced Package Tool (APT) 0.8.11 through 0.8.15.10 and 0.8.16 before 0.8.16~exp13, when updating from repositories that use InRelease files, allows man-in-the-middle attackers to install arbitrary packages by preventing a user fro...

CVE-2013-4768
Published: 2014-04-15
The web services APIs in Eucalyptus 2.0 through 3.4.1 allow remote attackers to cause a denial of service via vectors related to the "network connection clean up code" and (1) Cloud Controller (CLC), (2) Walrus, (3) Storage Controller (SC), and (4) VMware Broker (VB).

Best of the Web