Database encryption: Protecting the crown jewels

Databases are the lifeblood store of information for every organization. Without them, the organization’s efficiency, productivity and scope to prosper would be curtailed severely.

Protecting the company crown jewels is something that most organizations take seriously, using network security, robust authentication and access controls within their toolsets.

The main problem is that you are just one IT security manager faced with thousands of potential attacks. Sooner or later, someone will try to gain access to your databases and steal the data contained in them. IT security measures plug gaps we know about, but cybercriminals are very clever, very lucky or very manipulative – often all three. They mount many attacks in the sure knowledge that at least one will succeed. Just look at organizations like FireEye and Malwarebytes. If they can be breached, how can a less cyber security-savvy organization cope?

Potential data theft scenarios

Let’s assume that your organization has been hacked. First and foremost: what was the cybercriminal looking for? Any data they can use as a ransom or which they can sell – or both? This could be data currently inside a database, but many users will also have reports, documents and presentations containing information they extracted from the database. These are nice, easy targets.

Let’s say you happen to be a government organization running a virus track-and-trace system and you might store everything in a spreadsheet. Let’s also assume that there is a cybercriminal who has compromised your defenses and is snooping around the network looking for anything of value. Or maybe this is a member of staff, already inside the network, feeling malicious or just nosey.

If you’re facing a disgruntled employee inside the finance department, they can access sensitive data because it’s part of their job. For them, information theft is simple – they just log in to the database and extract all the staff records and corporate finances onto a USB stick and away they go. The same could be true if an external hacker managed to compromise a user account through phishing or social engineering.

The case of the administrator or the hacker are likely to be similar to each other. They can both exfiltrate documents, reports and spreadsheets which users have created. But they can also copy the entire database – including files that contain many of the corporate crown jewels.

Finally, the administrator as the authorized user holds the keys for the backups, so can steal a whole backup that contains not only database files but also all the ad-hoc documents created by users

Types of database encryption

There are a variety of technologies for database encryption.

Transparent Data Encryption (TDE), usually provided as an option from the database vendor, is commonly used. This encrypts data so that, in the event that the database files themselves are stolen, the information remains secure. With no impact on the way the database works and with no need to change the application, this is an attractive option.

Another option is Column Level Encryption (CLE) which encrypts specific data fields. CLE offers stronger protection from within the running application but requires manual setup in the database and application software changes. Again, the cybercriminal or administrator thief is foiled by this kind of security.

Data masking is a further technology that is aimed at hiding sensitive information from database authorized users. For example, rather than showing the entire credit card number to the call center operator, data masking could hide all but the last four digits. This technology conceals data from application users when they have no need to see it. However, the information stored in the database is not secured.

There are, however, problems with these approaches. Our first challenge is that TDE and CLE are specific to the database technology vendor. In a perfect world this would be fine. But in real life, organizations grow over time, through acquisition and because of changes in technology direction. This leads to an infrastructure consisting of multiple vendors’ technologies.

To encrypt all your databases, you now have to purchase, deploy, manage and maintain multiple different database security products. Not a great situation.

In addition to that, there are reports, spreadsheets, documents, logs and temporary files scattered all over the organization, unprotected from disillusioned employees and determined hackers.

Since we’re assuming that the cybercriminal has already gained access to the network, endpoints and servers, this is an alarming situation.

Focus on the data

At the end of the day, we’re trying to protect information. If you can organize your infrastructure in such a way that, when data gets stolen, it’s in a form that is complete garbage to the thief, then the information remains protected even though it’s in the wrong hands.

Enter data encryption. More specifically: file-level encryption. Data encryption traditionally gets a bad rap as it’s seen as something complex, expensive and scary, so we tend to toy with it rather than embrace it. For example, full disk encryption is easy – we leave it up to the OS vendor and just forget about it. The catch is that full disk encryption doesn’t actually stop anyone stealing data from a live system. And TDE for databases is fit-and-forget too – but all it does is to create another security silo outside of which data becomes unprotected.

File-level encryption seems to be treated as something dangerous; something a bit edgy that needs to be applied with care only to the most sensitive information. Which is odd, since modern file-level encryption can – and in my opinion – should be applied universally.

The problem with only encrypting the most sensitive data is that it’s difficult to pinpoint exactly and reliably what “sensitive data” really is. And, most importantly, where it is. I’ve already pointed out that people will run reports, write documents and manipulate potentially sensitive information in spreadsheets. And people do what’s easy – not necessarily what the IT department expects them to do. It might be company policy to store all documents on the user’s “P:” drive, but maybe it’s easier to store them locally – especially if the individual is just playing around with some numbers.

The great thing with file-level encryption is that it works for databases, too. Databases, under the covers, are just a bunch of files, so if we just encrypt all the underlying files then the entire database is naturally secure against both our hacker and the rogue admin stealing them. So now we have a single piece of security technology that works not only across all vendors’ databases, but also across all unstructured, report, temporary and log files.

This approach offers comprehensive protection without changing any software. And any misconfigured storage that’s open to the internet now contains only encrypted data. We don’t actually want anyone to get in and steal them, but regardless, they’re useless to an outsider. Even the rogue administrator or finance executive can only steal encrypted data.

Mix-and-match is good

A single security solution is not able to fill all security gaps, and even if they were able, I would suggest avoiding that approach. Why make life easy for a cybercriminal? Using a carefully selected suite of tools is a superior method of securing networks and data, placing lots of roadblocks in front of hackers.

It doesn’t matter if information is stored in a database, a Word document, a presentation or a spreadsheet. By accepting that data breaches will happen it becomes apparent that building security into the data is the only approach that ensures persistent information protection.