Choosing And Implementing An Enterprise Database Encryption Strategy

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