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
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-2391
Published: 2014-04-24
The password recovery service in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 makes an improper decision about the sensitivity of a string representing a previously used but currently invalid password, which allows remote attackers to obtain potent...

CVE-2014-2392
Published: 2014-04-24
The E-Mail autoconfiguration feature in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 places a password in a GET request, which allows remote attackers to obtain sensitive information by reading (1) web-server access logs, (2) web-server Referer log...

CVE-2014-2393
Published: 2014-04-24
Cross-site scripting (XSS) vulnerability in Open-Xchange AppSuite 7.4.1 before 7.4.1-rev11 and 7.4.2 before 7.4.2-rev13 allows remote attackers to inject arbitrary web script or HTML via a Drive filename that is not properly handled during use of the composer to add an e-mail attachment.

CVE-2011-5279
Published: 2014-04-23
CRLF injection vulnerability in the CGI implementation in Microsoft Internet Information Services (IIS) 4.x and 5.x on Windows NT and Windows 2000 allows remote attackers to modify arbitrary uppercase environment variables via a \n (newline) character in an HTTP header.

CVE-2012-0360
Published: 2014-04-23
Memory leak in Cisco IOS before 15.1(1)SY, when IKEv2 debugging is enabled, allows remote attackers to cause a denial of service (memory consumption) via crafted packets, aka Bug ID CSCtn22376.

Best of the Web