Encryption is the key to defence-in-depth strategies

Database encryption is often overlooked by even security-conscious IT administrators and managers. Rion Datta, Information Risk Management Consultant, MIEL eSecurity, details the importance of this aspect of information security.

Database encryption is still to catch on in the Indian enterprise. Why is this so?

While the efforts of many IT administrators and managers have been focussed on the security of data-in-transit and on controlling access, many feel that encrypting (and subsequently) decrypting data sets in databases will lead to significant loss of performance and is therefore not a viable proposition.

Encryption serves as an important component of any defence-in-depth strategy, and is meant to complement existing security layers such as access control. In the absence of encryption, an attacker who is able to breach access controls will be able to compromise the integrity of the database.

What is the first step in encrypting a database?

Undoubtedly, ensuring that only authorised users can access it. Within a database, access control means creating users and granting them the privilege to act on objects and execute certain commands and perform tasks. The built-in controls and mechanisms within a database are the best way to implement access control.

Once access controls are in place, encrypting databases is the second line of defence. Even if access controls are circumvented, encryption provides an additional barrier and should limit damage to critical data.

Are there any issues while following an encryption strategy?

There are two things to note. First, encryption does not protect data from being deleted. Second, encryption does not protect data from being modified, although it does provide a way to tell if unauthorised changes have been made.

There are several strategies to encrypt data-at-rest, and each strategy has its own advantages and disadvantages.

How about an outline of common strategies that can be followed to encrypt databases?

Encryption of data-at-rest can be performed in several ways. One way is to encrypt the actual database files at the operating system level. An example of using this strategy is to encrypt an entire database file using Microsoft’s EFS within a Windows environment. But there are several weaknesses to this strategy.

You cannot selectively encrypt individual pieces of data; on the other hand, encryption of the entire file causes serious performance problems while reading the database. Encrypting the entire file not only adds to the overhead of reading all the data, but also leads to additional overhead when recording pointers, indexes and other internal data structures that must be encrypted and decrypted for any operation of the database.

Another weakness is that different pieces of data cannot be encrypted with different keys, which is critical when different user groups (such as HR, sales) access the same database.

File-based encryption only protects data from operating system-level attacks. It does not protect the data from a user who breaches the database.

What are the best practices that organisations can use to overcome these limitations?

A more efficient and effective way to encrypt information in a database is to do it on a column and row basis. To understand this concept, think of a table containing a list of customers.

Within this customer table there is information such as customer ID, customer name, address, and the customer’s redit card number. In this table there is little reason to encrypt the customer ID; it is most likely that you would only want the credit card information encrypted.

You gain several advantages by only encrypting your most sensitive data, which in this case is credit card information. One advantage is that you can minimise the performance hit. For instance, when a user attempts to search the table for a specific user, they incur very minimal overhead because the only data that must be decrypted is the data-found row–a small subset of the data. Even better is that when you select from other tables which do not require encryption, there is absolutely no additional overhead.

What about protection from internal breaches?

One of the serious problems encryption solves is protecting data from being read by administrators. This is accomplished by encrypting data using a key unknown to the database administrator. Most importantly, the encryption must be dependent on restricting the administrator from discovering this secret code, and using it to decrypt the information within the database. For instance, if the administrator can simply reset the password of an account, log-on to the account, and access the data, encryption has failed to protect the data from administrators. Encryption should therefore be based on a secret code such as a password.

Of course, this means that when the user needs to change his or her password, it also involves resetting the decryption keys. To explain, the encryption system that we are referring to here would use a single key to encrypt and decrypt data in each column. A copy of this key, called the column key, is then stored encrypted with the user’s password.

Using this technique, encryption is truly dependent on a secret code, giving you a way to store data within your database that even an administrator cannot view.

Encryption and decryption processes may create performance bottlenecks. How can these be overcome?

An important decision is picking data to encrypt. Database lookups are designed to be efficient. Unlike typical file systems, databases are expected to look through millions of rows, searching for specific items in seconds. This need for fast access and retrieval places additional hardship on encrypting databases.

A database cannot afford to encrypt and decrypt each piece of data it must search. Therefore, it is critical to properly plan encryption based on how applications will use the database.

Before deciding which columns to encrypt, you should first gather a list of the most common statements executed against the database. Most large applications are highly dependent on a handful of queries. Analysing the use and frequency of SQL statements allows you to make an informed decision on how encrypting a column will affect performance.

What are the other issues that have to be considered during database encryption?

One of the main problems with encryption is key management. Very often we see encryption implemented by hard-coding a password into a procedure or script. Even if you use the most robust encryption algorithms and the strongest keys, this implementation of database encryption is inherently flawed.

Defence in-depth should not rely on one layer of security to protect another. In this case, once access control is circumvented, so is encryption. This does little to improve the security posture of your database. Encryption should be layered on top of access control and should protect data even when access controls are circumvented.

Is home-grown database encryption feasible?

Building your own security system is not a task most people should undertake. There are numerous details to be dealt with, such as padding or dealing with NULL values that result in complications and leave you open to attack if implemented incorrectly. Your best bet is to find a system that provides all the features you need. While encryption will require some additional administrative work, you should find a solution that minimises this impact.

When evaluating a solution, it is important to understand how the system works and to ascertain whether the solution provides true encryption, or whether it breaks down when access controls break down.

Talk to the vendor to understand the underlying architecture. If the vendor is not open about it, chances are they do not want to know that something is wrong. An encryption system should not attempt to hide the implementation details by concealing how the code works.