Why is Database Security So Critical?

A serious data breach means someone got into your database and stole data. Databases are the gatekeepers of your data, and anyone who wants to get it must get it from the database.

While you should protect all infrastructure components, none is more important than the database. Regardless of how they start, a database is where all breaches end.

Many organizations do not pay sufficient attention to database security for various reasons. Some do not believe it is possible to protect them, others think they do not have the necessary resources, have concerns about costs, and more. But the truth is that the right technology and partner know-how will let you protect your databases at an affordable price. And that protection is the most critical step in IT security.

Database Threats

Oddly enough, the internet is full of nonsense about database threats. Even blogs and articles from reputable sources repeat such baseless claims. The list below aims to set these facts straight:

Internal Threat

Yes, the internal threat is a big problem. To quantify it more accurately, about 20% of data breaches involve a malicious internal actor. The Verizon DBIR is a good source of information, stating similar numbers every year. Some countries, like Germany, report the internal threat as high as 26%. Regardless of whether it is 1 in 4 or 1 in 5 breaches, this is a significant threat we must not ignore.

This threat is yet another reason organizations must invest in database security. Data-centric defenses, in general, and, in particular, database security are the only defenses against internal actors.

External Threats

The majority of attacks are from external actors. However, it is critical to understand how such actors penetrate the database. Since databases are not supposed to be connected to the internet directly, all such attacks must come through an intermediary.

From a database security point of view, it is irrelevant whether the attacker got into the organization through a phishing attack, some other type of social engineering attack, a configuration mistake, or something else. The important part is that they got in and are now going for your data. The remainder of this list breaks down how that happens.

Local Server Access

While it is hard to put a number on the threat from local database server access, it is possible to set a minimum boundary. Consider that over 40% of data breaches involve ransomware, and almost any ransomware attack must, by definition, compromise the database server. There is simply no other way to encrypt the data files.

So, regardless of whether the threat from local server access is 40% or higher, it is a significant threat we cannot ignore.

Valid Accounts

Threats through valid accounts include credential theft, impersonation, and similar attacks. But everything else on this threat list, like internal threats, SQL injections, and more, also manifests through a valid account. While we cannot estimate the exact threat level from valid accounts, they are the primary method of penetrating a database.

But why bundle credential theft with, for example, abuse of privilege from internal actors? It is because of how we address these threats. If we cannot trust activity from authenticated connections, we must identify malicious activity inside those connections. It does not matter whether someone stole the credentials or the user abused their privilege. More on this later.

SQL Injection

It may be surprising, but there are no good numbers about the threat level from SQL injection. While it is estimated to be high, especially for internet-facing applications, different sources publish varying numbers across a wide range.

While SQL injection is only one type of application vulnerability, it is undoubtedly the most common. Web application security solutions like WAF consistently fail to address it, while modern database security solutions like Core Audit offer an effective defense. Modern database defenses address more than just SQL injection and are, nowadays, the preferred solution. The situation nowadays is in sharp contrast to two decades ago, when WAF technology emerged.

Human Error

Human errors can create vulnerabilities in databases. For example, by granting too many privileges, neglecting to close accounts, using simple passwords, and more. However, evidence suggests this is not a significant cause of database breaches. While human errors are a core reason for perimeter penetration, they are not a cause for penetrating databases.

However, identifying and fixing such errors is good practice. Setting up change control processes (see below) is an essential step in that direction.

Minor risks

Some theoretical threats pose minuscule threats to databases. We mention these since such claims exist in various blogs and articles. They are, however, nonsense.

Modern databases do not have any significant vulnerabilities, buffer overflows, or similar weaknesses. At least not ones responsible for a breach, since this lack of vulnerabilities is particularly true for authentication-related vulnerabilities that allow attackers to connect without a password. There is no magic packet or undocumented secret backdoor to let someone into your database. While it is essential to apply security patches, exploiting a database vulnerability without a valid username and password is rare.

Also, you should not connect a database directly to the internet. Databases must reside only in secure internal networks. Therefore, databases are not vulnerable to Denial of Service attacks (DoS). And that goes double for Distributed Denial of Service attacks (DDoS). Any attempt to protect a database against such attacks is pointless.

Threat Summary

The bottom line is that a database breach leverages a valid user and password to connect to the database. These are the primary paths:

• Internal DBA threat. That is an abuse of privilege by a database administrator.
• DBA account compromise. That is an external actor that breached a DBA desktop, stole a DBA password, or the password of a shared privileged account (like SYS or SA).
• Local access. Most databases allow unauthenticated connections from particular operating system accounts on the database server. A breach like that is usually by an external actor, but it can also be an abuse of privilege.
• Application account compromise. That is an external actor who gained access to the application password, or an internal actor abusing their access.
• Application compromise. That is an exploit of an application vulnerability, like a SQL injection.
• Other account abuse or compromise. Similarly to the DBA account, other database accounts can be abused by their rightful owners or compromised by an external actor.

Basic Practices

Basic security practices aim to harden a database but do not address common threats. These are essential steps, but they will not stop a breach.

1. Encryption. Turn on network and disk encryption. While no common threats target network packets or files, it is good practice and easy to implement.
2. Account Security:
   • Account Inventory. List all database accounts, and identify the individuals or applications associated with them.
   • Inactive Accounts. Close inactive accounts.
   • Individual Accounts. Ensure all the accounts are individual accounts, except application accounts and built-in shared administration accounts (like SYS or SA).
   • Password. Ensure no password is the default password or a hard-coded password.
   • Password Policy. Turn on password policies requiring a minimum password length, password complexity, account lockouts, etc.
   • Least Privileged. Ensure all accounts have the minimal privileges individuals require to perform their duties.
3. Patches. Install all security patches for the database and all associated software and tools. That includes the application software, reporting tools, database administration tools, performance management tools, etc.
4. Change control. Implement a change control process and independently validate all changes are approved. That includes changes to configuration, users, permissions, database objects, etc.

Best Practices

As mentioned above, basic security steps are essential, but cannot address the main threats. Addressing these threats is done through Activity Control, the primary method for database security.

Nearly all threats emanate from valid connections using appropriate privileges. Therefore, the only way to address them is by inspecting each SQL in each connection and applying appropriate detective or preventive controls.

Since activity controls aim to ensure connections only perform “good” activity, regardless of whether the threat is internal or external. What matters is the account activity profile and how to prevent it from doing something malicious.

1. DBA accounts and Local connections. DBAs are not usually supposed to access sensitive data. Many times, they do not run DMLs either. That means alerting or blocking these activities in administrative accounts is an excellent way to prevent a breach. Internal database controls cannot do that, but advanced activity control can. These controls mitigate any threat that manifests through a privileged account, including abuse by a DBA, credential theft, and local connections.
2. Application account. Applications tend to repeat the same SQL constructs over and over. While there might be several hundred thousand constructs, they, ultimately, all repeat. An anomaly analysis of application activity is an excellent way to identify changes in the application activity profile. That works for detecting SQL injection as well as most types of application misbehavior.
   While this also detects abuse of the application account or credential theft, you could also detect those through session controls (discussed below).
3. DDL Activity. Certain activity types, like DDLs and DCLs, merit extra precautions. DDLs let you administer the database, and DCLs are a subtype related to authorization (users and grants). Common practice is reporting on these SQLs to ensure changes are approved.
4. Sensitive Tables. Controlling access to sensitive data is fundamental, and anomaly analysis is an effective measure to identify changes in behavior relating to these tables. That will pinpoint unusual access by DBAs or other accounts, dangerous changes in the application behavior, and more.
5. Sensitive Programs. Some programs have no built-in restrictions on what their users can do, and allow them to execute any SQL. Administrators usually use these programs to manage the database, and analysts sometimes write SQL to take full advantage of database capabilities. The absence of restrictions merits extra monitoring which depends on how people use these programs. It can involve monitoring sensitive table access, DMLs, anomalies, etc.
6. Sessions and Activity Source. Session control is the simplest type of control and the easiest to understand. It involves monitoring who connects, from where, and when. Reporting can be for a subset of accounts, like DBAs or the application, to ensure all connections are from expected sources. Anomalies are crucial alerts highlighting a change in activity source (e.g., a different IP), an unusual time of day, a higher activity volume, and more.

Test Yourself

The questions below test your level of control over your databases. If you lack awareness, consider some of the best practices recommended above.

1. Do you receive false positive alerts from your database security solution?
   No security system is perfect. All solutions balance false positives and false negatives (undetected security events). Failing to get false positives means your security is too lax or non-existent. It means you will not be alerted even if you have a breach.
2. Do you know who accessed your sensitive data in the past week?
   Knowing who accesses sensitive data in your database is a key awareness indicator. If you do not know the answer, you are unlikely to know when there is malicious access. You are also unlikely to perform a successful forensic investigation of a breach.
3. Do you know the users, programs, and IPs that accessed your database this past week?
   That is a fundamental session control question. Awareness of the activity sources in your database is an essential control. If you are unaware, you would not know if there was a credential theft and would not be capable of performing a forensic investigation.
4. Do you believe you’ll know if an intruder exploited local access or a DBA account?
   That is a more complex question because an intruder might use the same activity source as the real user. However, it is a critical test since these are popular attack vectors.
5. Do you believe you’ll know if there was a SQL injection attempt?
   SQL Injection is considered a significant threat and the primary application attack vector. It is also notoriously difficult to detect, and anomaly analysis is the only effective method.

A decent security posture should allow you to answer these questions. After all, they cover the most popular paths to a data breach.

Final thoughts

Database security is at the core of protecting your data. This article explains the main threats, how to address them, and how to test yourself. If you fail to control your databases, you are far more likely to have a data breach and are unlikely to know about it.

Take control of your databases. Contact us today!