How should databases be protected?
05 Jul, 2021 6 min read
There’s simply no denying that Data is the currency of the future. All businesses have one or more databases and are naturally heavily reliant on them not only to store information, but also to utilise the data to make business informed decisions. Whether it’s payroll data, employee records, customer information, financial information or even inventory data today’s list of Data is endless. Understandably, with such a huge wealth of data stored in databases, it is a lucrative spot for data leakages or hacking to occur.
What do we need to protect when securing databases?
When we look at protecting company databases, there are three levels we need to look at:
Perimeter-level: Our IT infrastructure comes into the picture here - network servers, hardware and other inbound/outbound channels that can potentially distribute malicious software.
End-user level: Organisations use Endpoint Protection software to prevent each machine from injecting malware or other problems into the network. Web filtering is also often used to help users to avoid visiting dangerous websites.
Data-level: Protecting the data itself, whichever database it resides in.
Perimeter-level: Our IT infrastructure comes into the picture here - network servers, hardware and other inbound/outbound channels that can potentially distribute malicious software.
End-user level: Organisations use Endpoint Protection software to prevent each machine from injecting malware or other problems into the network. Web filtering is also often used to help users to avoid visiting dangerous websites.
Data-level: Protecting the data itself, whichever database it resides in.
What are some of the best practices to adopt?
Here are some of the best practices companies usually adopt to protect their database on all three levels.
Protect your physical database
Whether your database is located on-premise or in the cloud, we should never overlook the actual place our data is stored in, maintained, and utilised from. Placing surveillance on who has physical access to the equipment and locking the rooms simply limits access to only authorised people - it doesn’t offer 100% protection.
What many businesses don’t realise is that if both your web server and data are on a common network, any access to your web server admin account will compromise access to your database. So, to prevent data damage or data loss, we should separate database servers and web servers. This is particularly important since web servers have a higher chance of getting attacked since they are publicly accessible.
Regularly update and patch
As with all things tech-related, it’s always important to regularly update your operating system and database software with security patches to protect against vulnerabilities. It is also good practice to ensure all database security controls provided by the database are enabled, especially if your database is connected to a large number of third-party applications or plugins that each require their own patches. Often what happens is that cyber criminals will target these third-party apps or plugins to bypass your database security so to keep intruders out, you need to maintain a strong defence.
Limit user access
Try to limit the number of people that have access to the database. Where possible, give the bare minimum privileges to administrators that will allow them to do their job. To manage passwords and permissions, some companies use dual or multiple factor authentication measures or automate access management using an access management software.
Other common measures include enforcing the use of strong passwords, locking accounts after three or four login attempts and implementing a procedure that ensures accounts are deactivated when staff leave the company. Again, it’s not a 100% failsafe, but a necessary precaution, especially if you don’t have a file-level encryption solution.
Monitor database activity
Regularly conduct an audit of your database by analysing the log files of the database itself, but also their applications. Audit logs usually alert database administrators to attempted logins and suspicious activity and this will reveal who has accessed the information, when they visited, and what they did.
Encrypt ALL your Data (including backups)
Even with perimeter-level, application-level and end-user level measures in place, there’s always a chance a hacker could infiltrate your systems. If this wasn’t true then the number of data breaches we see in the news wouldn’t be happening.
Data breaches happen on two levels, externally by cybercriminals or internally by an employee accessing a file that they don’t have permission to. If you’re encrypting your data though it means it will appear gibberish unless it is decrypted with the proper keys. So even if your data gets in the wrong hands, it remains unintelligible and meaningless to anyone who is not authorised to view it. It’s akin to reading a newspaper article written in a foreign language that you’ve never learned before. That piece of news won’t mean anything to you.
Encrypting data in your databases should also extend to your data backups and decryption keys, which should be stored at a separate location from your main database. Afterall, if your decryption key is stored in the same location as the operating data it defeats the purpose - it’s like leaving your house keys under a mat outside your front door. A backup database is also recommended.
Protect your physical database
Whether your database is located on-premise or in the cloud, we should never overlook the actual place our data is stored in, maintained, and utilised from. Placing surveillance on who has physical access to the equipment and locking the rooms simply limits access to only authorised people - it doesn’t offer 100% protection.
What many businesses don’t realise is that if both your web server and data are on a common network, any access to your web server admin account will compromise access to your database. So, to prevent data damage or data loss, we should separate database servers and web servers. This is particularly important since web servers have a higher chance of getting attacked since they are publicly accessible.
Regularly update and patch
As with all things tech-related, it’s always important to regularly update your operating system and database software with security patches to protect against vulnerabilities. It is also good practice to ensure all database security controls provided by the database are enabled, especially if your database is connected to a large number of third-party applications or plugins that each require their own patches. Often what happens is that cyber criminals will target these third-party apps or plugins to bypass your database security so to keep intruders out, you need to maintain a strong defence.
Limit user access
Try to limit the number of people that have access to the database. Where possible, give the bare minimum privileges to administrators that will allow them to do their job. To manage passwords and permissions, some companies use dual or multiple factor authentication measures or automate access management using an access management software.
Other common measures include enforcing the use of strong passwords, locking accounts after three or four login attempts and implementing a procedure that ensures accounts are deactivated when staff leave the company. Again, it’s not a 100% failsafe, but a necessary precaution, especially if you don’t have a file-level encryption solution.
Monitor database activity
Regularly conduct an audit of your database by analysing the log files of the database itself, but also their applications. Audit logs usually alert database administrators to attempted logins and suspicious activity and this will reveal who has accessed the information, when they visited, and what they did.
Encrypt ALL your Data (including backups)
Even with perimeter-level, application-level and end-user level measures in place, there’s always a chance a hacker could infiltrate your systems. If this wasn’t true then the number of data breaches we see in the news wouldn’t be happening.
Data breaches happen on two levels, externally by cybercriminals or internally by an employee accessing a file that they don’t have permission to. If you’re encrypting your data though it means it will appear gibberish unless it is decrypted with the proper keys. So even if your data gets in the wrong hands, it remains unintelligible and meaningless to anyone who is not authorised to view it. It’s akin to reading a newspaper article written in a foreign language that you’ve never learned before. That piece of news won’t mean anything to you.
Encrypting data in your databases should also extend to your data backups and decryption keys, which should be stored at a separate location from your main database. Afterall, if your decryption key is stored in the same location as the operating data it defeats the purpose - it’s like leaving your house keys under a mat outside your front door. A backup database is also recommended.
Always protect the data first
While we can reinforce our infrastructure, and educate employees on cybersecurity in the hope of reducing the likelihood of suffering a data breach, but, at the end of the day, data breaches will continue to happen. It’s a reality that we have to accept and these have proven time and time again that in the event of a data breach, they simply cannot protect the data. The only way to get 100% data protection therefore is via encryption. It’s been proven to be one of the most effective database security practices because it is implemented at the point where protection is most needed, to the data itself, at the point of creation.
The inconvenient truth is, companies often focus on setting up perimeters, setting up standard operating procedures for staff to follow, only to overlook the most fundamental and easiest form of protecting data at the source -file-level encryption. To read more about the common misconceptions organisations have about data security, and how to solve these security gaps, check out our whitepaper - Databases - a hot spot for data leakage.
The inconvenient truth is, companies often focus on setting up perimeters, setting up standard operating procedures for staff to follow, only to overlook the most fundamental and easiest form of protecting data at the source -file-level encryption. To read more about the common misconceptions organisations have about data security, and how to solve these security gaps, check out our whitepaper - Databases - a hot spot for data leakage.
Protecting Your Data with File-Level Encryption
A lack of Data security comprises the processes and tools that protect information assets. While there are indeed many ways to protect your database - some organisations use Transparent Data Encryption (TDE), others prefer Column Level Encryption (CLE), while others use Data Masking - each of these methods come with their own set of limitations. To find out more about these limitations you can read this article by our Technical Director, Nigel Thorpe.
The most important thing to remember at this juncture is that protecting your data at the file-level ensures ALL your data remains protected, every file, every place, every time and no other security solution offers the same. Remember, even if the perimeter is unpatched and data is breached, persistent protection from file-level encryption means data remains unintelligible to any unauthorised party. The icing on the cake is, since file-level encryption protects both structured and unstructured data, it can work as a single protection solution and it eliminates any need for staff training or alteration of the way your employees work. With the SecureAge Security Suite, the encryption process is transparent, seamless and inherent.
Check out our ‘Security Suite for Databases’ solution to find out more about this solution.
The most important thing to remember at this juncture is that protecting your data at the file-level ensures ALL your data remains protected, every file, every place, every time and no other security solution offers the same. Remember, even if the perimeter is unpatched and data is breached, persistent protection from file-level encryption means data remains unintelligible to any unauthorised party. The icing on the cake is, since file-level encryption protects both structured and unstructured data, it can work as a single protection solution and it eliminates any need for staff training or alteration of the way your employees work. With the SecureAge Security Suite, the encryption process is transparent, seamless and inherent.
Check out our ‘Security Suite for Databases’ solution to find out more about this solution.
