Importance of database encryption
12 Mar, 2021 8 min read
We’ve all got one – usually more than one; and many of them are very sensitive - we’re talking about databases. Databases are the crown jewels for every organisation - without them an organisation's efficiency, productivity and ability to prosper are at risk. The problem is, while most organisations take effort to protect their crown jewels using network security, robust authentication and access controls they’re still vulnerable. The issue is there is just one IT security manager faced with thousands of potential attacks from thousands of cybercriminals - there needs to be a better way.
Face the facts - your organisation will be hacked
At some point, someone will try to gain access to where your data is stored and steal it. Sure, there’s plenty of IT security measures on the market but most of them simply plug the gaps that we know about. The reality however is that cybercriminals are very clever, very persistent and very manipulative – often all three.
A typical approach is for a cybercriminal to mount many attacks with the hope that at least one will succeed. Just look at organisations like FireEye and Malwarebytes. If they can be breached, then how will a less cyber security-savvy organisation avoid the same fate?
Okay, so, now you know that your organisation is going to be hacked. The first question to ask is, what would the cybercriminal be looking for? Perhaps it’s data they can use as ransom, or data which they can sell; most likely both. This data could be currently inside a database, but many of your users will also have reports, documents and presentations containing information that they extracted from the database. These are nice, easy targets.
A typical approach is for a cybercriminal to mount many attacks with the hope that at least one will succeed. Just look at organisations like FireEye and Malwarebytes. If they can be breached, then how will a less cyber security-savvy organisation avoid the same fate?
Okay, so, now you know that your organisation is going to be hacked. The first question to ask is, what would the cybercriminal be looking for? Perhaps it’s data they can use as ransom, or data which they can sell; most likely both. This data could be currently inside a database, but many of your users will also have reports, documents and presentations containing information that they extracted from the database. These are nice, easy targets.
Information theft is real
Let’s say you happen to be a government running a virus track and trace system – just picking a random thought – in which case you might store everything in a spreadsheet. After all, everyone loves a spreadsheet. Let’s also assume that there is a cybercriminal who has compromised your defences and is cruising around the network looking for something of value. Or maybe, it’s a member of staff who is already inside your network, feeling malicious or just nosey.
Another scenario might be a disgruntled employee inside the finance department who can access sensitive data because it’s part of their job. For them, information theft is simple – they just login to the database and extract all of the staff records and corporate finances onto a USB stick and away they go. The same would be true if an external hacker managed to compromise a user account through phishing or social engineering.
The thing is, whether it’s an internal administrator or an external hacker, they can both withdraw documents, reports and spreadsheets which users have created and they can both copy the entire database – with files that contain many of the corporate crown jewels.
The scariest part is, the administrator, as the authorised user, also holds the keys for the backups. This means they can steal a whole backup that contains not only database files but also all the ad-hoc documents created by users.
Another scenario might be a disgruntled employee inside the finance department who can access sensitive data because it’s part of their job. For them, information theft is simple – they just login to the database and extract all of the staff records and corporate finances onto a USB stick and away they go. The same would be true if an external hacker managed to compromise a user account through phishing or social engineering.
The thing is, whether it’s an internal administrator or an external hacker, they can both withdraw documents, reports and spreadsheets which users have created and they can both copy the entire database – with files that contain many of the corporate crown jewels.
The scariest part is, the administrator, as the authorised user, also holds the keys for the backups. This means they 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, here’s our rundown on three common approaches.
1. Transparent Data Encryption
Commonly used as it’s usually provided as an option from the database vendor. This encrypts data so that in the event that the database files themselves are stolen, the information remains secure against the thief. This is an attractive option as there’s no impact on the way the database works, and no need to change the application.2. Column Level Encryption (CLE)
This approach encrypts specific data fields. This Column Level Encryption 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.3. Data masking
This technology is aimed at hiding sensitive information from database authorised users. For example, rather than showing the entire credit card number to the call centre operator, data masking could hide all but the last four digits. It conceals data from application users when they have no need to see it. However, the information stored in the database is not secured.The problem with database encryption
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, organisations grow over time, whether it be through acquisition or because of changes in technology direction, and this leads to an infrastructure consisting of multiple vendors’ technologies.
To encrypt all these databases, these businesses now have to purchase, deploy, manage and maintain multiple different database security products. Not an ideal situation. And, to add to that all those reports, spreadsheets, documents, logs and temporary files are scattered all over the organisation – all unprotected against disillusioned employees and determined hackers.
Since we assumed earlier that the cybercriminal has already gained access to the network, endpoints and servers, this is an alarming situation.
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, organisations grow over time, whether it be through acquisition or because of changes in technology direction, and this leads to an infrastructure consisting of multiple vendors’ technologies.
To encrypt all these databases, these businesses now have to purchase, deploy, manage and maintain multiple different database security products. Not an ideal situation. And, to add to that all those reports, spreadsheets, documents, logs and temporary files are scattered all over the organisation – all unprotected against disillusioned employees and determined hackers.
Since we assumed earlier that the cybercriminal has already gained access to the network, endpoints and servers, this is an alarming situation.
Focus on the data
Enter data encryption. Specifically, file-level encryption. After all, at the end of the day, it’s the information itself which we’re trying to protect.
With our unique approach to Data encryption, you no longer have to decide what Data to protect. SecureData technology protects everything, in every place, all the time. It does this by making encryption an inherent property of your Data, as opposed to a collection of reactive systems, restrictive tools that impact usability, and incomplete policies that can never keep up.
It basically allows a business to organise their infrastructure so that when the 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.
Now traditionally, data encryption gets a bad rap. That’s because it’s perceived as something complex, expensive and scary. Because of that, many businesses tend to toy with it rather than embrace it.
For example, full disk encryption is deemed easy – as it’s common to 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 – all it does is create another security silo outside of which data becomes unprotected.
File-level encryption also 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 work out exactly, and reliably, what ‘sensitive data’ really is. And 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 may well be that the company policy is 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 also works for databases and no software changes are required. 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 with SecureData 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.
It’s a failsafe solution because 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 if they happen to, they’re useless to an outsider. Even the rogue administrator or finance executive can only steal encrypted data.
With our unique approach to Data encryption, you no longer have to decide what Data to protect. SecureData technology protects everything, in every place, all the time. It does this by making encryption an inherent property of your Data, as opposed to a collection of reactive systems, restrictive tools that impact usability, and incomplete policies that can never keep up.
It basically allows a business to organise their infrastructure so that when the 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.
Now traditionally, data encryption gets a bad rap. That’s because it’s perceived as something complex, expensive and scary. Because of that, many businesses tend to toy with it rather than embrace it.
For example, full disk encryption is deemed easy – as it’s common to 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 – all it does is create another security silo outside of which data becomes unprotected.
File-level encryption also 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 work out exactly, and reliably, what ‘sensitive data’ really is. And 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 may well be that the company policy is 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 also works for databases and no software changes are required. 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 with SecureData 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.
It’s a failsafe solution because 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 if they happen to, they’re useless to an outsider. Even the rogue administrator or finance executive can only steal encrypted data.
Mix and match is good
Like all things in IT security, it’s always good to mix and match.
Contrary to what you’re probably seeing else, a single security solution will never be able to fill all security gaps, and even if it could, 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 as it places a lot of roadblocks in front of the hackers.
With a suite of tools it doesn’t matter if the 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 even when data is stolen.
To find out more about how SecureAge Technology can be added to your arsenal, visit https://www.secureage.com/article-product-overview
Contrary to what you’re probably seeing else, a single security solution will never be able to fill all security gaps, and even if it could, 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 as it places a lot of roadblocks in front of the hackers.
With a suite of tools it doesn’t matter if the 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 even when data is stolen.
To find out more about how SecureAge Technology can be added to your arsenal, visit https://www.secureage.com/article-product-overview