Databases have long been the source of much attention when it comes to security. For good reason, their very purpose is to store data. The quintessential security issue in the news is a data breach. By necessity, databases deserve our attention and security cycles. We can think about security at the database layer from many perspectives, some of which are informed by the technology stack involved. This article will cover database hardening from each of the confidentiality, integrity, and availability (CIA) triad perspectives.
Confidentiality
Confidentiality issues represent one of the primary sources of anxiety around security incidents; Data is stolen or accessed by some unauthorized entity. There are many ways that this can happen and it’s dependent on your application or environment threat model. Some notable things to think about and work on to protect your databases against confidentiality-oriented attacks include:
- Performing regular account reviews to ensure that all those who can access the database are legitimate and validated.
- Protecting connecting applications against SQL injection attacks. This is best done using safe SQL constructs provided by security libraries or the development framework in use.
- Utilizing a web application firewall alongside the above tip to add another layer of resilience to potential oversights in parameterized SQL queries.
- Considering restricting the kinds of device types that can connect to the database (e.g., servers vs user workstations).
- Investing in capabilities to restrict network egress or control it to flow through very specific choke points to create control over how and what things leave the environment.
- Ensuring that the database uses a strong form of authentication, ideally with assumed roles and credentials that are securely managed (e.g., application secrets store, password managers, etc.).
Integrity
Data tampering is a more subtle form of attack that may not be as headline-grabbing as a breach or a ransomware attack, but the potential harm is real. Protecting against integrity-oriented attacks can happen through a more recovery-oriented practice, leveraging good backups and restore procedures. Recovering from an incident, while important, does nothing to decrease the risk of that thing actually happening in the first place. In addition to the things referenced above under confidentiality, think and work through the following:
- Generate audit logs for authentication events and for more sensitive, protected data, enabling audit logs where technically feasible.
- Make sure somebody is responsible for actually looking at audit logs periodically for suspicious things.
- Minimize the number of connections into and out of the database wherever possible, regularly auditing them to guarantee relevancy.
- Get into the habit of using more granular permissions for all accounts, whether they belong to a user or an application service. Integrity issues are going to be all about write issues. When thinking about the threat model and data flow of a particular account, it’s oftentimes the case that global write or read access is not actually necessary.
Availability
Evolutions, like ransomware, have reinforced to us all that data suddenly not being available can be just as disastrous as when it is tampered with or stolen. Making sure that your critical databases are available when you need them can be approached in a few different ways:
- Use cloud services that have been highly rated for uptime and resiliency (think 99.999%). Or alternatively, if you’re not using cloud services, deploy resources to fit a high availability model.
- Back up the database regularly. While this can assist with issues of integrity, as mentioned above, it can be used just as easily to restore data in the event a primary has been lost.
- Protect the backups from potential mismanagement or targeted attack. Examples of this might include:
- Limiting permissions to access the backups in any way
- Requiring multi-factor authentication re-prompt to delete anything or modify a backup
- Restrict the network pathways to the backups.
- Thoroughly and regularly test recovery procedures to make sure that you can recover from a number of different availability scenarios quickly and with complete and accurate data afterward.
Concluding Thoughts
While it hasn’t received as much attention in the form of marketing headlines recently, database security is still very important. It’s also not something that can be approached from one simple angle. Like most things in security, it’s a holistic problem.
Before taking on any of the work covered in this article, think about the risk management needs and threat model of your particular data and databases. Some data doesn’t need to be secret; sometimes availability and integrity are most important. It’s all dependent on the organization and what it uses data for.
Want more cybersecurity insights? Visit the Cybersecurity channel:
