An important requirement for ensuring database security compliance is the ability to keep privileged users “under control.” This process is often called “separation of duty” and is directly related to minimizing insider threats.
Most security regulations including Payment Card Industry Data Security Standard (PCI-DSS), Sarbanes-Oxley (SOX) and Health Insurance Portability and Accountability Act (HIPAA) require the implementation of strict separation-of-duty practices in order to tackle the increasing presence of insider threat.
Principle of least privilege is a well-known best practice in the security industry in which users should always be granted the minimum privileges needed to perform their tasks. But what about users who are in charge of administering a database? These users frequently require extensive administrative and system privileges that allow them access to sensitive data, including PII (personally identifiable information). Today’s enterprises face a difficult task trying to keep these privileged users under control through the implementation of strict separation of duty policies that allow users to perform their jobs and simultaneously secure the sensitive application data stored in databases.
Database Management System (DBMS) software, like most other commercial software, has not been designed to provide the strict separation of duty controls that are required by today’s security and compliance regulations. The administrative privileges that these applications provide for management and administration can lead, either directly or indirectly, to a complete compromise the data contained in these systems. The separation of duty controls between the differing administrative functions is very poor.
In my opinion, the main reason software does not have a strong separation of duty between administrative tasks is because this was not an initial design goal. DBMS software usually has an administrative account that provides complete control of all the resources, data and configuration changes, usually including privileges over the native auditing facility. Even from accounts that contain limited administrative privileges, it is often possible, even though it is not documented, to escalate privileges to super-admin.
DBMS software has two primary kinds of separation of duty issues. First, there are administrative privileges and accounts that grant full control over the software including access to all confidential data. Second, certain restricted administrative privileges that give control over a portion of the complete administration task can be abused to escalate to super-admin privileges.
The first DBMS separation of duty issue is usually created in the design process and is well-known and documented by software vendors. We all know that a person who has Database Administrator (DBA) privileges can read or modify any data that is stored in a database. Some years ago it was probably okay and fairly common to have super-admin DBAs that can access any data in the database. That is no longer the case as databases are required to adhere to strict regulations.
The second group of issues is less known and is sometimes associated with vulnerabilities (security flaws) or design issues in the software. Here are some examples:
Oracle Database provides CREATE LIBRARY and CREATE PROCEDURE privileges. These system privileges are provided to give specific capabilities to the accounts or roles that hold them. The first one allows users to create library objects within the database that points to external files. The second one allows for the creation of database stored procedures.
These two privileges can be used –or abused in this case– to create a library within the database associated with an external Dynamic Link Library file that contains a function to execute operating system commands. After this, it is possible to create a stored procedure that calls the external library function to execute operating system commands. These operating system commands usually run under the Database software owner account, giving full unrestricted access to all database confidential data.
Of course, there are counter measures to prevent this kind of elevation of privileges techniques but they are usually not known and not implemented.
The administrative privileges also expand the attack surface in a database. For example, in an Oracle Database someone that has the EXECUTE_CATALOG_ROLE role has execute permissions granted to a much bigger amount of packages and procedures which can contain escalation of privileges vulnerabilities. An example of such a vulnerability is SQL Injection in DBMS_CDC_PUBLISH.ALTER_AUTOLOG_CHANGE_SOURCE which allows a user with EXECUTE_CATALOG_ROLE role to escalate to DBA privileges giving access to all database data.
Oracle Database Vault
DBMS software vendors are aware of these issues and limitations and they are providing some solutions to address them. An example of this is Oracle Database Vault, an add-on option installed on top of an existing Oracle Database. The main goal of Database Vault is to provide separation of duty to protect against the insider threat.
In an Oracle Database with Oracle Database Vault installed, it is possible to protect sensitive application data from DBA access. In this way, DBAs will still be able to perform their daily administrative tasks and the sensitive application data will not be accessible to them because the system privileges do not have power over the Oracle Database Vault protected data.
This, in theory, provides the separation of duty controls required for most security regulations. Unfortunately, this add-on software is good at providing a solution to the first problem (administrative privileges giving full access to all database data) but is not adequate at providing a solution to the second one (abusing certain administrative privileges to escalate privileges and compromise sensitive data). There are still many ways in which a user with administrative privileges can escalate their privileges and compromise all the data stored in the database. The two examples above can be applied to a database protected with Oracle Database Vault.
Native Auditing Limitations
Another requirement of most security regulations is the need to keep audit trails of all operations in a database, especially the ones related to administrative tasks and have access to sensitive data. DBMS software usually provides native auditing capabilities that can be used for record keeping and provides accountability of database operations. This native auditing capability is also subject to attack by privileged or administrator users.
For example, in Oracle Database the SYS user is audited in a different way than other users. The standard native database auditing options do not have an effect over the actions performed by users with SYSDBA privilege. Because of this, it is possible to perform operations as the SYS user without leaving a trace in the standard native database auditing trails. Also, because of some escalation of privilege vulnerabilities it is possible for users with certain privileges to escalate to SYSDBA privilege and perform operations without being recorded.
Today’s DBMS software does not offer a complete out-of-the-box solution to protect from the insider threats represented by highly privileged users. This poses a serious security risk because organizations have difficulties not only protecting the sensitive data from privileged users, but also keeping records of all the activity performed by them.
In the face of these issues, there are counter measures that can be taken to mitigate the risks posed by high privilege misuse. Traditional security best practices like reducing the attack surface and the principle of least privilege are very good examples. Also, there are some other measures that are less known and specific to each database type, for example, in Oracle, you can configure the database to use a separate low-privilege user for external procedure execution, allowing you to avoid using the same user that is running the database server process.
The important thing is to know the limitations of your DBMS software and to apply additional protections to secure them. Third party security software can help identify these risks and implement the counter measures needed to minimize them. Also, the third party database activity monitoring (DAM) software can help keep the required audit trails for all the operations performed by high privilege users.