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. It 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 it gives a good general idea, and relational databases are the most common type of database.

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 refers to those rows through a customer ID.

To access this data, you must use a language called SQL. SQL is an English-like language that databases understand and 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 those to manage the database, for instance, to create or remove tables.

Who uses the database and how?

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

Generally, there are three kinds of database accounts and users in the database:

• 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 everything in the database and can make any changes they want. 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 used by the application servers. They are not for real individuals. The real end-users use the software on the application servers, and that software sends SQLs to the database using an application account.
• Analysts and other accounts are used by individuals who need direct access to the data in the database. 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 giving them superuser rights. “Permissions” grant users access to specific tables or columns. Those are usually for all other accounts giving them access to particular information.

Privileges and permissions are usually not granted directly to users but through a system or roles. A role is a collection of privileges and permissions you can grant to users or other roles.

The application needs access to all the data, so it always has permission to access everything. The security layer that only grants each end-user access to some of the data is inside the application. End-user authentication and authorization are performed inside the application server. 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

Databases allow you to easily enable security features like encrypting data-in-transit and data-at-rest. There are also built-in password policy rules you can turn on. More importantly, database authentication is very mature, and it is highly 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 database 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 valid connections. Connections could be 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 are usually 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 that got 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 certain 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, 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 before. Not a single threat is addressed by any of these measures. That is because attackers have long ago adjusted to regular database defenses.

Getting into a database requires a valid username and password, so account security measures won’t stop it. It 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. These are 3rd party solutions like Core Audit that help you combat realistic threats.

Activity Control

That is the realm of database auditing, advanced SQL blocking, anomaly analysis, and proactive and reactive forensics. It is about applying 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 or connection sources listing the programs, machines, and IPs 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 way to approach 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, but modern solutions like Core Audit offer robust and effective security that will significantly reduce the risk of a data breach.

Talk to us today and let us help you protect your most critical assets.