What is a Database?

A database is a software solution that stores, manipulates, and retrieves data. Think of an Excel spreadsheet, but a database operates on a much larger scale. A database is like thousands of Excel spreadsheets, some with millions of rows, accessed simultaneously by thousands of individuals. To be accurate, that is a relational database, but relational databases are the most common type of database and you get the general idea.

It seems pretty intense, but that is why the technology is so valuable. These “spreadsheets” are called tables, and there are relationships between them. For example, one table might contain the name and address of a customer, while another table contains more information about that customer. The second table refers to the customer in the first is through a customer ID. That is the relational part of relational databases.

To access this data, you must use a language called SQL. SQL is an English-like language that databases understand. It is almost identical across all database types. It lets users query data using ‘select’ or modify data using ‘insert’, ‘update’, and ‘delete’. There is another category of SQLs called DDLs. Administrators use DDLs to manage the database, for instance, to create or remove tables.

Who uses the database and how?

Writing SQL is not too difficult, but it is uncommon for people working with databases to know SQL or use it. Most people use applications that translate what they are trying to do into SQL.

Generally, there are three kinds of accounts in databases:

• Database Administrators, or DBAs, are responsible for managing the database. They often write SQL, but they also use applications designed for administrators. Those make certain operations easier by eliminating the need to write the SQLs. DBAs have unlimited access to the database and the data. They can access anything and change whatever they like. In addition to individual DBA accounts, DBAs usually have access to special built-in privileged database accounts. Usually, they also have access to the operating system on the database server.
• Application accounts are not for real individuals. The application servers use those to access the application data. The real end-users use the software on the application servers, and that software sends SQLs to the database using an application account.
• Databases sometimes have accounts for analysts and other individuals who need direct access to the data. They sometimes write SQL but often use special tools to access the data.

The Database Security Model

Databases have two mechanisms to give users access. “Privileges” grant users global rights, like the right to read any table in the database. Those are typically for DBAs, granting them superuser rights. “Permissions” grant users access to specific tables or columns. Those are for all other accounts, granting them access only to particular information.

Usually, privileges and permissions are granted through a system or roles rather than directly to each user. A role is a collection of privileges and permissions you can grant to users or other roles.

The application must have access to all the data and always has permission to access everything. The security layer that grants each end-user access only to some of the data is inside the application. The application servers perform End-user authentication and authorization. The application server’s internal logic is responsible for ensuring end-users can only access what they are authorized to do. From the database perspective, the application has access to all the data.

The Strengths and Challenges of Database Security

You can easily enable security features in the databases, like encryption of data-in-transit and data-at-rest. You can also turn on built-in password policy rules. More importantly, database authentication is very mature, and it is unlikely anyone could connect without a valid username and password.

The biggest problem, though, is that most accounts have access to all the data. DBAs have access to everything because of their administrative privileges. The application account can access everything because the application needs it. Analysts and other accounts might have more limited permissions, but many times, they also have access to most (if not all) of the data.

That creates a challenge because how we use databases does not align with the database security model. There is no way to limit DBA or application access, and those account for nearly all the database activity.

Database Threats

Since connections to the database always use valid users and passwords, threats are limited to authenticated connections. Connections could originate from real users or someone impersonating them. So here is the list of threats:

• Internal DBA threat. That is the threat of an abuse of privilege by a database administrator. While DBAs tend to be trustworthy individuals, their unrestricted access makes them a security risk.
• DBA account compromise. That is an external threat of someone stealing DBA credentials. That can be, for example, from a breach of a DBA desktop. It could also be a credential theft of a shared privileged account, like SYS or SA.
• Application account compromise. That can be an internal or an external threat. It is about gaining access to the application credentials. That could be an application manager or developer with access to the credentials (internal threat) or an external actor who obtained those from a configuration file (external threat).
• Application compromise. That can be an internal or external threat. For example, exploiting a vulnerability in the application (like a SQL injection). It could also be developers abusing their access to the application code.
• 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.
• Local access. Most databases allow unauthenticated connections from particular operating system accounts on the database server. That means that gaining access to these accounts on the database server will grant you access to the database. Even if such access is blocked, it can usually be enabled or bypassed.

Securing a Database

That is where things get interesting. We’ll start with popular best practices for securing a database. That guidance usually involves:

• Account security. Identify inactive accounts and close them. Follow the least privileged principles for active accounts and enable a password policy.
• Encryption. Turn on encryption of data in transit and data at rest.
• Patching. Make sure you install the latest security patch.
• Vulnerability scanning. Run vulnerability scans and address them.

While important, none of these measures addresses the database threats listed above. They do not address even a single threat. That is because attackers have long ago adjusted to standard database defenses.

You need a valid username and password to get into a database, so account security measures won’t stop attacks. Getting in also doesn’t involve sniffing network packets or stealing files, so encryption isn’t helpful. Finally, modern databases rarely have authentication-related vulnerabilities, so scanning for vulnerabilities and applying patches isn’t targeting these threats.

So, how can we secure a database?

Effective database security leverages activity control. Activity control combines detective and preventive measures that apply security at the database session and SQL levels. Solutions like Core Audit will help you combat these realistic threats.

Activity Control

Activity control includes database auditing, advanced SQL blocking, anomaly analysis, and proactive and reactive forensics. It applies security measures to authenticated sessions that execute authorized activity.

For example, measures to secure DBA accounts would target activity rarely executed by DBAs. Detection could alert of DMLs (inserts, updates, and deletes) or access to sensitive data. Simpler detective measures would be at the session level, inspecting failed logins and connection sources, such as the programs, machines, and IP addresses DBAs use to connect.

Preventive measures for DBA accounts could block DBA access to sensitive data. Advanced SQL blocking can inspect each SQL and block ones that access the data schema. Another preventive measure for DBA accounts is enforcing a separation of duties. That requires DBAs to get prior authorization for certain activities from security personnel.

Other detective measures can secure the billions of SQLs coming from the application. Anomaly analysis is a powerful tool that can inspect each application SQL and alert when there is a change in the application activity profile.

You can place similar measures on local connections or any other account.

There are more capabilities for reactive and proactive forensics. The first aims to investigate security events, and the latter gives visibility into the activity to facilitate control design, gap analysis, identification of poor security practices, and more.

The bottom line is that controlling the activity allows you to secure the database against all threats. It takes some time and effort to determine the best approach for each subsection of the activity, but everything can be secured.

Final thoughts

Securing databases is an imperative. Databases hold the data we need to protect, and safeguarding them is at the core of information security. Traditional approaches are inadequate and fail to secure databases. However, modern solutions like Core Audit offer robust and effective security that will significantly reduce the risk of a data breach.

Contact us today, and let us help you protect your critical assets.