Databases have long been the subject of much security scrutiny. 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 of database-layer security from many perspectives, some of which are informed by the technology stack involved. This article will cover database hardening from each of the perspectives of the Confidentiality, Integrity, and Availability (CIA) triad.
Privacy issues represent one of the main sources of anxiety around security incidents; The data is stolen or accessed by an unauthorized entity. This can happen in several ways and it depends on your application or environment threat model. Here are some notable things to think about and work on to protect your databases from privacy-focused attacks:
- Perform regular account reviews to ensure that everyone who can access the database is legitimate and validated.
- Protect connecting applications against SQL injection attacks. This is best done using secure SQL constructs provided by security libraries or the development framework being used.
- Use a web application firewall alongside the tip above to add another layer of resilience to potential oversights in parameterized SQL queries.
- Consider restricting the types of device types that can connect to the database (for example, servers versus user workstations).
- Invest in capabilities to restrict network egress or control its passage through very specific choke points to create control over how and what leaves the environment.
- Ensure the database uses some form of strong authentication, ideally with assumed roles and securely managed credentials (e.g. application secret store, password managers, etc. ).
Data tampering is a more subtle form of attack that may not grab the headlines like a breach or ransomware attack, but the potential harm is real. Protecting against integrity-focused attacks can be done through a more recovery-focused practice, leveraging good backup and restore procedures. Recovering from an incident, while important, does nothing to lessen the risk of that thing actually happening in the first place. In addition to the things referenced above under privacy, think about and work on the following:
- Generate audit logs for authentication events and for more sensitive protected data, enabling audit logs when technically possible.
- Make sure someone is assigned to regularly review audit logs for suspicious items.
- Reduce the number of inbound and outbound database connections as much as possible, auditing them regularly to ensure they are relevant.
- Get in the habit of using finer-grained permissions for all accounts, whether they belong to a user or an app service. Integrity issues will relate only to write issues. When thinking about the threat model and data flow of a particular account, often times global read or write access isn’t really necessary.
Developments like ransomware have confirmed to all of us that data suddenly unavailable can be just as disastrous as when it’s tampered with or stolen. Ensuring your critical databases are available when you need them can be approached in a number of ways:
- Use cloud services that have been rated highly for availability and resiliency (think 99.999%). Or, if you’re not using cloud services, deploy resources to accommodate a high availability model.
- Back up the database regularly. While this can help with integrity issues, as mentioned above, it can be used just as easily to restore data in the event of a lost primary.
- Protect backups from potential mismanagement or targeted attack. Examples of this could include:
- Limit access permissions to backups in any way
- Require a new multi-factor authentication prompt to delete anything or edit a save
- Limit network paths to backups.
- Thoroughly and regularly test recovery procedures to ensure that you can recover quickly from a number of different availability scenarios and with complete and accurate data afterwards.
Although it hasn’t received as much attention in the form of marketing headlines recently, database security is still very important. Nor is it something that can be approached from a simple angle. Like most things in security, it’s a holistic issue.
Before undertaking any of the work covered in this article, consider the risk management needs and threat model of your particular data and databases. Some data does not need to be secret; sometimes availability and integrity are most important. It all depends on the organization and how it uses the data.
Want more information on cybersecurity? Subscribe to the Cybersecurity as a Business Enabler channel: