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
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 Microsofts 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?
You gain several advantages by
encrypting only your most sensitive data. One advantage is that you can
minimise the performance hit
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 customers 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 rowa 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
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 users 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
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
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
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.