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

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
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-6335
Published: 2014-08-26
The Backup-Archive client in IBM Tivoli Storage Manager (TSM) for Space Management 5.x and 6.x before 6.2.5.3, 6.3.x before 6.3.2, 6.4.x before 6.4.2, and 7.1.x before 7.1.0.3 on Linux and AIX, and 5.x and 6.x before 6.1.5.6 on Solaris and HP-UX, does not preserve file permissions across backup and ...

CVE-2014-0480
Published: 2014-08-26
The core.urlresolvers.reverse function in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3 does not properly validate URLs, which allows remote attackers to conduct phishing attacks via a // (slash slash) in a URL, which triggers a scheme-relative URL ...

CVE-2014-0481
Published: 2014-08-26
The default configuration for the file upload handling system in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3 uses a sequential file name generation process when a file with a conflicting name is uploaded, which allows remote attackers to cause a d...

CVE-2014-0482
Published: 2014-08-26
The contrib.auth.middleware.RemoteUserMiddleware middleware in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3, when using the contrib.auth.backends.RemoteUserBackend backend, allows remote authenticated users to hijack web sessions via vectors relate...

CVE-2014-0483
Published: 2014-08-26
The administrative interface (contrib.admin) in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3 does not check if a field represents a relationship between models, which allows remote authenticated users to obtain sensitive information via a to_field ...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
This episode of Dark Reading Radio looks at infosec security from the big enterprise POV with interviews featuring Ron Plesco, Cyber Investigations, Intelligence & Analytics at KPMG; and Chris Inglis & Chris Bell of Securonix.