How to evaluate the security risk of your databases

Data has become one of our most important assets. We usually store data in databases, so knowing how to secure those is of vital importance.

This article can help you quantify the level of security of your databases on a scale of 1 to 10. CISOs and database administrators (DBAs) can use it to determine their security maturity level and identify steps to improve it further.

Find your database security rating

The table below summarizes security ratings on a scale of 1 to 10, with one being the lowest level of security and ten being the highest. All ratings are cumulative, so each rating includes all the requirements for all previous ratings.

The order of the levels reflects both an increase in security and an increase in cost and complexity. Lower levels are achievable without additional software, but achieving higher ones becomes increasingly difficult and requires appropriate products.

1. No security

Rating 1 is for databases that aren’t secured. All databases provide an inherent level of security, even if you made no effort to protect them. For example, they require credentials to connect and have roles and privileges. Managing data in a database is the first step toward securing it.

2. Standard security and least privileged

Rating 2 is for databases where both the database and operating system are configured by following industry standards and best practices.

This rating also requires that all database accounts are least privileged, which means that privileges granted to accounts are the minimum needed to perform their duties.

As part of the requirement for Rating 2, there should be an effort to eliminate shared accounts. If shared accounts exist, they should not be in regular use, and their credentials kept secret.

Limiting usage is especially true for privileged shared accounts built into the database. Database accounts such as SYS and SYSTEM in Oracle or SA in SQL-Server should not be used regularly, and their passwords should be kept securely with limited access.

This requirement can be challenging when, for example, the application uses a privileged account or when shared accounts are part of how we operate. However, reducing and controlling the usage of these accounts is essential to security.

3. Change control and metadata snapshots

Rating 3 is for databases that are under change control. That means that any changes to metadata such as users, privileges, configuration, and objects, should go through a change control approval process.

As part of the requirement for Rating 3, a daily snapshot of the configuration, users, privileges, and object metadata need to be made. Changes between snapshots should be promptly investigated and approved.

It is also advisable that these snapshots are cross-compared to similar databases to ensure consistent and uniform configurations, users, privileges, etc.

The challenge with change control is that it can be cumbersome and seen as useless red tape. However, lack of control over metadata changes quickly becomes a lack of control over the data.

4. Session monitoring and review

Rating 4 is for databases where all logins are monitored and regularly reviewed. Logins from unexpected users, programs, or machines, should be promptly investigated.

One of the easiest ways to breach database security is through credential theft. For example, stealing a DBA username and password would grant an attacker unlimited access to the data. Monitoring logins allows mitigating this risk.

Most databases allow auditing of logins and failed logins with minimal overhead. The implementation challenge is to provide an efficient review of the information via reporting.

5. Basic SQL auditing (DDL & DML)

Rating 5 is for databases where high-risk SQL activity is regularly recorded, reported on, and reviewed.

High-risk SQL activity includes:

• All DDLs (including DCLs) – SQLs that modify the database configuration, objects, users, privileges, etc.
• DMLs from unexpected sources such as privileged users and particular programs

The objective of this requirement is to apply control to activity that is infrequent and high-risk. Auditing rare activities do not usually create a performance overhead and requires a minimal time investment. The implementation challenge is to allow for a prompt and efficient review of the activities.

6. Full SQL auditing and network encryption

Rating 6 is for databases under full SQL auditing where all potentially risky SQL activity is regularly recorded, reported, and reviewed.

That translates to auditing large amounts of activity, including queries. For example:

• Access to sensitive tables with Queries and DMLs
• All DBA and privileged user activity
• All the activity from high-risk programs such a SQL Plus, Management Studio, etc.
• Activity by the application account that is not from the application servers
• Sensitive activity even when performed inside the database by stored procedures or triggers

Rating 6 also requires all database network activity to be fully encrypted to prevent network sniffing and spoofing.

The objective of this requirement is to start applying strict security measures on SQL activity and prevent many network attacks.

Encryption of network activity comes built-in for free in most databases and is easy to turn on. The main implementation challenge in this requirement is that auditing too many activities without an appropriate solution can have a significant database performance impact. A secondary challenge is to achieve efficient reporting for prompt review of the information with minimal time investment.

When searching for an auditing solution, note that some products do not avoid the database performance overhead, while others do not support network encryption.

7. Session anomaly detection and alerting

Rating 7 is for databases with automated detection and alerting on anomalous activity sources. Unlike the manual session review performed in Rating 4, this rating requires automation capable of detecting and alerting on changes in activity source profiles.

That includes:

• Alerting on new users, programs, machines, or a combination of those connecting to the database
• Detection of shared accounts (accounts used by several individuals) as well as individuals using multiple accounts

The purpose of this requirement is to supplement the human review with automation that will notice and highlight anomalous activity. That helps avoid accidental oversight as well as ensure quick detection and response. Implementation requires an appropriate solution to perform the analysis.

8. SQL anomaly detection and alerting

Rating 8 is for databases with automated detection and alerting on anomalous SQL activity. Unlike the manual SQL reviews in Rating 5 and 6, this rating requires automation capable of analyzing all the SQL activity in the database, including the application activity.

That includes:

• Unusual application behavior like potential SQL injections
• Abnormal activity levels. For example, an unusually high number of SQLs executed or rows accessed
• Activities at an odd time of day
• New SQLs touching sensitive tables

The objective of this requirement is far beyond avoiding accidental oversight and improved detection time. The aim is to apply control to the impossibly high activity volume in databases that cannot undergo human review.

Even low activity databases can execute millions of SQL queries per day, and without automation, it is impossible to apply any level of control to them. Implementation requires software that can capture all the activity with low overhead and perform the analysis.

9. Proactive forensic reviews

Rating 9 is for databases with regular proactive activity reviews. That means that a person familiar with the activity profile of the databases regularly inspects the activity (for example, once a month).

The purpose of the review is to identify behaviors that might otherwise go undetected, including both internal abuse and external attacks. The inspection could also highlight gaps in the controls, risky practices, and more.

Implementation requires a solution that can capture all the activity with minimal overhead, reduce and store it in a reasonable amount of disk space, and provide the forensic tools to analyze and review it.

10. Restrict access to DBAs and applications

Rating 10 is for databases that restrict access to accounts with otherwise unlimited access to the data, for example DBA accounts, privileged accounts, and the application account.

Such restrictions are not usually part of the native database capabilities and could include:

• Preventing privileged accounts from accessing schemas, tables, or objects that they should not be accessing. For example, DBA accounts should not usually access the data.
• Preventing access to an account from programs or machines that should not access it. For example, only the application program and the application server should access the application account.
• Preventing access to an account on days and at times when it should not be in use.
• Preventing accounts from accessing more data than is expected (rate-limiting)
• Enforcing separation of duties by requiring security personnel to pre-authorize certain privileged activities.

This requirement requires a solution to implement since it goes beyond built-in database preventive controls. Applying preventive controls to databases poses the operational risk of blocking legitimate activity. Deploying such measures must, therefore, be done carefully following appropriate best practices to minimize the potential for disruptions.

Final thoughts

If your security rating is not as high as you thought, don’t despair. Database security requires persistent pursuit that will gradually improve your rating.

Database security is an essential investment and will give you the confidence that your data is safe, secure, and reliable.