Database encryption – is it worthwhile?

The Wall Street Journal recently reported giant US-based health insurer Anthem had suffered a massive breach of its sensitive customer database. It is thought the entire contents of the database was successfully retrieved by the intruders, who had obtained a legitimate employee’s credentials.

The Journal cited a source familiar with the breach, who said the sensitive database was not encrypted and that encryption would have made it more difficult for the intruders to obtain the information.

This gives rise to an important security architecture question: when should you encrypt a database? What are the benefits?

Would database encryption help?

We have very few public details to work off, but in this case I believe database encryption would not have altered the outcome.

The intruder had obtained a legitimate employee’s credentials, likely through Spear Phishing. Therefore, the intruder is likely to have access to the same systems and the same data as the employee. Any encrypted database field must be automatically decrypted by a function before the employee can read it, meaning the employee and the intruder are both served clear text copies of the data, regardless of database’s encrypted state.

There are benefits to encrypting sensitive data at rest.  But despite the article source’s proposed encryption, the database would still be vulnerable to being read by an illegitimate user with legitimate credentials.

What would have helped?

Stronger controls around establishing an unambiguous identity of the person behind the keyboard.

If the intrusion occurred by simply stealing a user’s credentials (username and password), then two factor authentication would have prevented this breach, simply because the intruder would not have physically possessed the token or device necessary to complete the login.

All too often we see two factor only being used on remote access solutions. However, it can also be used on sensitive internal systems too, where supported. If you already have it, put it to good use!

Another option here is a hybrid – use a Hardware Security Module (HSM) and a smart card terminal to manage employee keys for reading/writing the data. It’s a form of two factor authentication (the employee must physically have the card) and the data is encrypted on the database. However, this approach may be prone to replay attacks if the card is left mounted, and kills any work-from-home options unless the employee has a card reader.

Stronger controls around running out-of-band software: e.g. malware.

The employee may have been victim to malware, plus it is likely the intruder needed to install some kind of software at some point to help establish their operations.

In this case, a corporate Application Whitelist or Application Locker policy (to prevent the installation and execution of untrusted software) would have eliminated an intruder’s option to install any software they need.

Also, an Application Firewall (Layer 7 Firewall) may help in this regard, but is only effective if the payload crosses the firewall and it can be read (decrypted) by the firewall. Thus, an Application Firewall does not replace an Application Whitelist, but augments it.

Rate limiting or reporting on large data runs

It is likely that an employee reading all records of all customers within a short time frame is an uncommon event.

A simple application control to limit or report on excessive database record usage would have helped raise the alarm before all the customer data was obtained.

When should a database be encrypted?

Database encryption is useful if you believe it is plausible an intruder may be able to copy the entire database file from the operating system it sits on, without needing to access the application that sits above the database. An example would be an intruder who gains administrator access to a server’s operating system – all they have to do is copy the database file. They do not need access to the database application, nor the business logic that uses it.

In that instance, properly encrypted data within the database file would make that file largely useless to the intruder once it is retrieved, unless they could also find the database’s key or otherwise break the encryption.

Full database encryption can be resource intensive, especially when searching or joining records – all fields must be decrypted before they are used by functions or read by the user. If encryption is of interest, consider running a Risk Assessment to identify which fields are sensitive and should be encrypted, allowing the remaining fields to remain clear text. Keep in mind that unique keys should remain unencrypted where possible to aid searching speed.

Summary

Database encryption, or field encryption, is mostly useful to prevent an entire database file from being copied and read at the operating system level. However, encryption is of limited use when the data is automatically decrypted for assumed legitimate users.

In those cases, stronger controls around establishing the unambiguous identity of the user and restricting out-of-band software will be more useful to the organisation.