Organizations depend on data, and databases are where that data lives. Databases are the heart that pumps this data throughout your organization and keeps it alive. But data volumes soar, regulations tighten, and treating database security as a collection of isolated technical tasks is a recipe for disaster.
Yet, many companies still treat database security as a set of isolated, small technical tasks rather than a structured process with an ongoing evaluation. This database security evaluation checklist will help you bridge that gap with a structured process and an ongoing evaluation. Let’s transform good intentions into organized, result-driven activities.
This article is organized by strategic objectives, with a practical checklist to help you effectively protect your data.
Why Evaluate?
Database security protects your critical and confidential data. It’s the innermost and last line of defense that stands between your data and all the threats and malicious actors inside and outside your organization. That is the line that must not fail.
Therefore, it is critical to ensure that database security is effective and working properly to detect and prevent breaches from real-world threats.
It’s also valuable to optimize your investment so that you’re not wasting time and money on ineffective efforts. It is only prudent to continue with your current security practices if they provide effective protection. An evaluation can help you determine if it’s advantageous to switch investments to other practices that will yield better results.
An annual review is the minimum required frequency for performing an evaluation and updating what’s needed. Without it, your security is unlikely to perform well and leave you exposed.
The Checklist
1. General Security Effectiveness
There are basic rules of thumb that will help you quickly determine if your database security is working. It is a good starting point to gauge whether you have a functioning database security operation or not.
A. Visibility
Key Question: Do you have visibility into what is happening in your database?
Consider these basic questions:
- Do you have a list of users, programs, and IPs that connected to your database in the past month?
- Do you have the list of people who accessed sensitive data in the past week?
- Do you know how much sensitive data was extracted yesterday?
Visibility is fundamental. If you have no idea what’s going on in your database, your database cannot be secure. It is impossible to secure what you cannot see.
B. False Positives
Key Question: Is your security system generating false positive alerts?
It may be counterintuitive, but a small number of false positives is a good indication of a healthy security system. If your system is too “quiet,” it is probably not doing its job and will fail to detect a real attack. We must avoid too many false positives. Those are ineffective and lead to alert fatigue. However, a small regular amount of realistic events indicates things are working properly.
If your security is passive by design, meaning it is not intended to send alerts, you should consider active components. Passive measures alone cannot detect or respond to attacks, leaving you exposed.
A healthy security system must show “signs of life” and generate relevant alerts with a good signal-to-noise ratio, not just random events.
C. Forensic Investigations
Key Question: Is your team conducting occasional forensic investigations in response to incidents?
Every environment has events that demand investigation from time to time. If your security team never conducts forensic investigations to rule out an attack or a breach, then you don’t have effective security.
Similarly to false positives, if everything always seems to hum along perfectly, then your security systems are not working.
2. Asset lists
A basic step in any security operation is to maintain lists of assets: what are we protecting, and who has access to it. It is essential to keep these lists up to date and ensure access is reviewed and approved.
A. Database Discovery
The first step is to have an up-to-date inventory of all the databases on the network. You must list both production and non-production databases and identify which ones contain sensitive information.
Verification: Have you performed a network scan recently to detect new instances? It is also advisable to stay in touch with DBA teams to help control the data sprawl.
B. Sensitive Data Identification
Within the list of sensitive databases, it is necessary to identify the tables and columns that contain sensitive information. This information changes over time as applications evolve, so checking in with various teams occasionally will ensure you always know where critical assets reside.
Verification: Have you touched base with the legal team recently to inquire about new sensitive data requirements? Have you kept in touch with DBAs and application teams about potentially sensitive data they manage?
C. Administrator (DBA) Accounts
DBA accounts pose threats of both internal abuse and credential theft. These high-value target accounts for hackers should be carefully monitored. An initial step is to maintain an up-to-date list of all the privileged accounts in the databases. That includes both individual and shared accounts.
Verification: Ensure that old privileged accounts are closed, that passwords are routinely rotated, and that all these accounts are monitored (see below). It is recommended to run a scan to locate accounts with sensitive privileges (like “alter user”, “select any table”, etc).
D. Application Accounts
Application accounts are the most active accounts in the database, accounting for nearly all SQL activity and sensitive data accesses.
It is imperative to know which applications access sensitive databases. The application landscape is constantly evolving, and over time, it is common for new applications to develop and old applications to gain access to more data.
Verification: Conduct regular reviews that identify which applications connect to sensitive databases and ensure that only necessary and authorized applications maintain access to critical data.
E. Other Accounts
Sometimes, databases have other accounts that are not applications or administrators. These accounts are subject to the least privileged requirements (see below). It is essential to maintain a list of these accounts, document their justification, and ensure they have minimal data access and no system privileges.
Verification: Ensure you have an up-to-date list of every account in the database, the active accounts in regular use, and a classification of each account by type. Carefully review the privileges and access for accounts that are not DBA or application accounts.
F. Individuals with Data Access
It is essential to maintain an up-to-date list of all the individuals with access to sensitive data. This list must include DBAs with system privileges, developers with accounts in the production database, application managers with access to the application account, and more.
Verification: While this list is not trivial to compile or verify, you can put it together through a combination of two methods. First, identify accounts that have data access based on either system privileges or permission grants. Second, validate that all the programs and IPs used by those sensitive accounts are accounted for. For example, ensure all the programs and IPs used by the application account belong to the application or to one of the individuals on your list with access to that account.
3. Lists of Threats, Risks, and Controls
A fundamental security practice is to identify risks and assign controls. In the database world, it is common for the list of risks to be vague, and many of those risks to lack proper control. It is vital to ensure your list of risks is realistic and up-to-date. It is equally critical to address each one.
A. Threats & Risks
Ensure you have an updated list of threats you perceive as posing a realistic risk. Consider:
- SQL injection and other application flaws
- Administrator abuse (20% of breaches are by internal actors)
- Credential Theft
- Ransomware
- Data theft
- Unauthorized modification
B. Controls
Ensure you have controls against each threat. Since database security is the last line of defense, unaddressed risks are a significant concern.
4. Passive Controls
Passive controls are actions you take because they are good practice, but it is impossible to measure their actual contribution to security. For example, password policies that require a particular complexity. It is impossible to know whether they prevent an attack or provide meaningful security value. It is a passive best practice that we follow because we think it is a good idea.
Due to their passive nature, these best practices require regular validation and testing to ensure they are still in place and perform as expected.
A. Password Policy
Password policies pose a tricky balancing act that should be regularly reviewed. On the one hand, requiring frequent rotation and strong passwords eliminates the risks of password guessing and exploiting old or stolen credentials. On the other hand, these policies lead to an elevated security risk of stolen credentials because users write down their passwords.
Therefore, when reviewing password policies, you must not only ensure the policies function as expected, but also ensure the user behavior is mitigated.
Verification: Test the password policies to ensure they work as expected. Check the user’s behavior in response to the policies and how they manage their passwords.
B. Least Privileged
The Least Privileged principle requires that users have only the privileges required to perform their duties. However, in databases, this principle is ineffective against the primary users – the DBAs and the application.
For other users in the databases, it is vital to validate that they don’t have excessive rights. For example, such users rarely need to modify data. Many times, they don’t even need access to all the data. This requires a careful, regular review (at least annually) and a change control process that ensures all changes are approved.
Verification: Ensure users don’t have excessive privileges and that the change control process is effective. Change control and change review are critical to ensure changes to privileges are validated and approved.
C. Change Control
Many changes occur in databases. In the configuration, the schema, users, permissions, and more. A change control process forces a review and approval of these changes.
For various reasons, changes sometimes happen outside of the change control process. Additionally, changes can be malicious, indicative of an attack. It is, therefore, recommended to add an active component of change review that regularly monitors for changes, allowing you to close the loop on your change control process.
Verification: Ensure you have a change control process that everyone follows. Make sure you also have an independent monitoring solution. That is essential to guarantee you are aware of all changes, whether initiated by change control or not.
D. Encryption
Encryption has three areas of application in databases: encryption of data in transit, encryption of data at rest, and backup encryption.
Encryption of data in transit (network encryption) is easy to activate and should be turned on. It has low overhead, it protects network communication to the database, and there is almost no reason not to use it.
Encryption of data at rest has multiple variations. You can encrypt at the physical disk level, file system level, database level (TDE), and column level. Each level has its own pros and cons, but the main problem is that this type of encryption is complicated to set up and manage.
Data at rest encryption is mostly used when compliance requirements demand it. It is only effective against theft of files or physical drives. It is ineffective against SQLs from users connected to the database, which is the primary method for data theft.
Backup encryption is highly recommended, and you must ensure all copies of the data outside the database are secure.
Verification: Validate network encryption is on and that no one can connect without encryption. Ensure your backups are encrypted. If you are not encrypting data at rest, validate your compliance requirements do not require it.
E. Backup
Backing up your database is necessary for operational reasons, but with the threat of ransomware, it is even more critical now. While it’s almost certain that your database is backed up, it’s not entirely obvious that your backups are done right.
Often, you discover the backups were flawed exactly when you need them. It could be a missing file, incorrect configurations, or various other problems that prevent a successful restore.
It is crucial to periodically verify that your backups work and allow you to successfully recover the database.
Verification: Attempt to restore a recent backup and ensure the database boots up and works as expected.
F. Database Version & Patch
While staying on the latest version and patch is considered good general security practice, it is not always practical with databases. It is because patching or upgrading a database can have far-reaching consequences, triggering unexpected application failures. Any patch or upgrade needs to be carefully tested beforehand to minimize this risk. Additionally, patching requires downtime that can be difficult to orchestrate.
However, you must ensure the vendor still supports your database version. Your patch level must also be reasonably recent without major vulnerabilities. Upgrades and patching must be done, but on a realistic schedule or when an imperative need arises.
Verification: Ensure your database is still supported by the vendor and consider upgrading if it is near its EOL date. Validate your patch level is not too old and check a CVE database to verify it has no significant vulnerabilities.
G. Limited Network Connectivity
Databases must be accessible from the application servers, DBA machines, and the machines of a limited number of other users who use them. They must be as isolated from the internet as possible, and should also be as isolated as possible from other computers on the corporate network. The objective is to restrict access to the limited number of subnets or devices inside the corporate network that connect to the database.
Network configurations tend to shift. It is vital to verify that the database has not been accidentally linked to an undesirable network.
Verification: Ensure you cannot ping the internet from the database server. Also, check from several computers inside the corporate network whether they can ping the database or connect to the database port.
H. Database Tools & Applications
A vulnerability may exist in tools or applications that connect to the database. Apart from the primary applications that manage the data, databases are often accessed by various applications for data analysis, reporting, and more. Databases are also accessed by a variety of tools for administration, performance tuning, monitoring, security, etc.
Verification: Obtain a list of all the tools and applications that connect to the database. Ensure the accounts they use are granted only the least privileges required. Check these tools one by one to ensure they are recently patched. Consult a CVE database to verify they have no known dangerous vulnerabilities.
I. Vulnerability Assessment
Vulnerability assessment scanning isn’t very valuable in databases. However, if you purchased a vulnerability scanning solution, be sure to scan all your databases.
Verification: If you own a vulnerability assessment solution, validate that you have a recent successful scan.
J. Penetration Testing
Pen testing is a powerful concept to help identify security weaknesses and vulnerabilities. Unfortunately, it is, nowadays, usually a commodity, lacking both the talent and inspiration required to achieve its lofty goal. When it comes to databases, commercial penetration testing is often even weaker than that.
However, your organization likely has sufficient talent to do this internally, and it won’t even require a budget. While your DBAs are not security experts, they are intimately familiar with both databases and your operations. All it takes is a change in perspective driven by guidance, examples, and some healthy imagination.
Challenge your DBA team to assume the role of the red team for a day. Possibly not even playing a red team. They can merely ponder how they would steal data, given all they know about the environment.
While it could be a technological attack, it doesn’t have to be. They could walk up to an unattended desktop at lunch time, read a password file from a network drive, manipulate a junior helpdesk engineer, and more.
Verification: Attempt to play the “how could you steal data today if you wanted to” challenge with the DBA team.
K. Education & Training
Eventually, security usually comes down to people. Personnel are the weakest link in the security chain. A little goes a long way when it comes to investing in your people.
Consider these aspects of personnel education and training:
- Building defenses. Do your developers, DBAs, and other database-related personnel know how to build secure code (e.g., use bind variables), secure databases, and more?
- Testing defenses. Do your QA testers, developers, DBAs, and other database-related personnel know how to test for security flaws? Do they even know what they look like so they can recognize them? For example, a database error can disclose information that will lead to an attack. Or that if certain characters (like single quote) yield an error, they may suggest a possible SQL injection vulnerability.
- Self-security & awareness. Do your DBAs and other database-related personnel know how to identify and avoid a phishing attack? Can they protect themselves and their endpoints so that they do not provide a point of entry for hackers?
- Sensitive data. Are database personnel aware of the data you consider sensitive? Are they aware of your policies and standards for handling and protecting sensitive data?
Technology can protect data, but it’s the people who defend it. Even the best policies collapse when teams fail to follow them or don’t understand why they exist.
Security culture isn’t built overnight, but it compounds over time. Consistent training and security discussions can build a security culture where security is baked into everything from its inception.
5. Active Controls
Active controls are controls that react to activity. They may also take action, but they always provide you with feedback. For example, they can produce alerts and reports about activity that occurred. They can also provide preventive capabilities and block activity before it happens.
Since securing a database is ultimately about controlling the activity, these are the main and most effective tools at your disposal. Passive controls aim to make attacks more difficult to execute, but only active controls can detect or block them.
There are many ways to slice and dice the activity to achieve effective controls, but the following primary aspects must be covered in some way.
A. DBA Control
Los DBA y otras cuentas con privilegios tienen acceso ilimitado a todos los datos de la base de DBA Control
DBAs and other privileged accounts have unrestricted access to all the data in the database. These accounts pose threats from both internal abuse and credential theft, so controlling them is of utmost importance.
These accounts are difficult to control for several reasons, not least of which is that DBAs usually manage the security controls. Therefore, solutions that control DBAs should be resilient to DBA manipulation, such as turning off auditing or deleting audit data.
There are a variety of activity controls against DBAs, like:
- Detective Controls. e.g., reporting on DBA activity.
- Preventive Controls. e.g., preventing DBA access to sensitive data
- Separation of Duties Controls. e.g., certain tasks require DBAs to have an authorization code from security personnel.
Verification: Evaluate the effectiveness of your controls on DBA and privileged accounts. Ensure you control all these accounts (listed in section 2c). Consider whether you’d be able to detect or prevent an abuse of privilege by a DBA. Consider whether you’d be able to detect or prevent malicious activity from a stolen privileged account.
B. Application Account Control
Applications run the majority of the database SQL activity. They are difficult to control due to the billions of SQLs they execute. However, the application account has access to all the data and poses a significant threat that cannot be ignored.
The application account risk originates from three primary sources:
- Application Vulnerabilities, such as SQL injection, pose a significant and well-known threat that you must not ignore. These threats must be detected rather than prevented. That is because preventive controls on application activity can cause unexpected application failures with a potential for data corruption.
- Application Account Abuse by an application manager, developer, or other internal actor. Internal actors account for over 20% of data breaches.
- Credential Theft of the application credentials. Application credentials are particularly vulnerable since they are stored in the application.
Verification: Ensure you have controls for detecting application vulnerability exploits (like SQL injection). Validate that you can detect or prevent application account misuse, such as abuse by an application administrator or credential theft by a hacker.
C. Controlling Users with Production Access
Databases often have users other than DBAs or the application. Such users must have the minimum needed privileges, but they usually have access to sensitive data. Regardless of the permissions granted, privilege escalation is a risk for anyone with database access.
It is, therefore, good practice to monitor all the users in the database. Whether they are developers, data analysts, or anyone else, all accounts pose a risk from abuse and theft.
Verification: Ensure you have detective or preventive controls for every user in the database. Check that this list is up-to-date and includes all the accounts that require control.
D. Sensitive Data Control
Sensitive data access is the most sensitive activity in the database. Controlling this activity is at the core of effective activity control. While fundamental, it can be complicated to accomplish due to the potentially high volumes of SQL activity.
Verification: Ensure you have an up-to-date list of all the sensitive tables. Validate that you have effective controls that flag suspicious access to sensitive information.
E. Detective & Preventive Controls
Detective and preventive activity controls each have their own pros and cons. Preventive controls stop malicious activity, while detective controls are more sensitive and more likely to detect an attack or a breach.
Prevent what you can and detect the rest: with the right mix of detective and preventive controls, you can attempt to prevent as much as possible and detect attacks you cannot stop.
Verification: Ensure you have sufficient detective controls that will alert you to a breach or attempted breach. Aim to increase the number of preventive controls as much as possible without false positives.
F. Encrypted Session Control
Encrypted sessions pose a specific threat because many activity control solutions are unable to monitor them. A database client can request an encrypted session, whether the database mandates encryption or not. It is, therefore, imperative to ensure your current activity control solution can handle encrypted sessions.
Verification: Ensure you can control sessions connected with encryption (SSL).
G. Anomaly Detection
Databases execute billions of SQLs, rendering it impossible to review each one manually. It is, therefore, imperative to have automation that can detect suspicious or anomalous activity.
Anomaly detection is also necessary to identify small changes in the activity profile that will go unnoticed by human review. For example, when a user connects from a different IP address.
But what is an anomaly? An anomaly can be any change in the database activity behavioral profile. For example, a user connecting from a different location, accessing different data, running different SQLs, or retrieving more rows. Anomaly detection must be tailored to a specific database so that it only targets changes that don’t occur frequently in that environment.
When anomaly alerts are in place, you will get a small number of false positives from time to time. It is a sign of an active and functioning security system that is calibrated sensitive enough to notice the inevitable occasional changes in the activity profile.
As the database activity profile changes, you will occasionally need to adjust the anomalies so that they continue to cover all the activity and remain sensitive enough.
Verification: Ensure you have mechanisms deployed to control large activity volumes. Validate that you get alerts about small changes in the activity profile. Check that you get relevant false positive alerts from time to time. Be sure to adjust the anomalies so that they fit your current database activity profile. Confirm that you cover all the database activity.
H. Forensic Capabilities
When a security incident or a breach occurs, you will be required to conduct a forensic investigation to find out what happened. However, if you wait until that time, you are unlikely to have the information needed for the investigation.
It is, therefore, imperative to routinely conduct small investigations to rule out occasional false-positive events. That is the only way to ensure you have all the data and capabilities for when the time comes.
Verification: Ensure you routinely conduct forensic investigations to rule out false positives. Verify you have all the required information and abilities to investigate any event.
6. Non-production Controls
Non-production databases exist in environments used for development, testing (QA), training, and more. These databases often contain sensitive data copied from production and pose a significant threat because:
- They are rarely secure.
- Many individuals who access them regularly have no authority to view sensitive data.
- These environments have fluid software versions, configurations, and security controls. Development and test environments change constantly.
Non-production databases are a security nightmare. They pose both an internal and external threat. The most realistic solution to secure them is to ensure they contain no sensitive information. The process of removing sensitive data is called data masking, also known as obfuscation, anonymization, and more.
A. Locate Sensitive Data Outside Production
Locating all sensitive data outside of production can be a challenge. It is, however, imperative to obtain and maintain a list of all these environments. There are three primary methods, and we recommend using a combination of those:
- Network scan. Locate all the databases on the network and account for each one (production and non-production).
- Ask production DBAs. When data is copied out of production, it is usually done by the production DBA responsible for that database. They are likely to know where data is copied to.
- Ask development/QA teams. These teams are the primary users of data out of production and likely know where it resides.
Verification: Ensure you know where sensitive data resides outside of production databases (test, dev, training, etc.). That is something that changes over time and requires occasional rediscovery.
B. Mask Sensitive Non-production Databases
Data outside of production must be masked. Masking poses several challenges, such as:
- Locating the sensitive data inside the databases
- Designing a masking policy that balances hiding the sensitive information and retaining its utility for the QA or development teams.
- Getting the masking process to perform well and work efficiently.
Verification: Ensure you locate all the sensitive data inside those databases. Make sure that data is properly masked and doesn’t expose sensitive information. Validate with the development or QA team that they are using the masked data and are happy with it. Due to data quality issues, those teams often revert to using the original data.
Final Thoughts
It may seem like database security is composed of many pieces, but it is imperative to address at least some of each strategic objective. It is better to do a little from everything than to achieve a few objectives completely and ignore others.
This checklist is your roadmap to a structured security program. By addressing these objectives annually, you shift your defense from a reactive task list to a proactive, organized, and continuous process. Start the evaluation today – your data cannot afford to wait.
If you have thoughts, questions, or need additional help, please don’t hesitate to contact us. We’re here to help!
Comments
AI Recommended
Ask a Question
If you have a question or a comment, please let us know. We’ll be happy to hear from you.
