Strategies and Considerations for Auditing Your Database System

One of the major drivers behind auditing is compliance. The Health Insurance Portability and Accountability Act in the U.S. requires that healthcare providers deliver audit trails about anyone and everyone who touches any data in their records. The EU’s General Data Protection Reg­ulation has similar requirements. In addition, there are many internal rules and regulations mandated by com­panies themselves. Besides compliance, other reasons for auditing include monitoring and analyzing database activities for malicious and abnormal activities, devel­oping threat detection with real-time monitoring, and integration with SIEM (security information and event management) solutions for analysis.

Recently, Emad Al-Mousa, database security consultant at Saudi Aramco, shared strategies for auditing your database system. There are three types of auditing:

  1. Oracle Database Unified Auditing
  2. Operating System Auditing
  3. Monitoring and auditing database configuration files

Oracle Database Unified Auditing

Oracle Database Unified Auditing was introduced in Oracle 12c R1. It is important to note that Mixed Mode is enabled by default, and traditional auditing is depreciated in Oracle 21c, said Emad. Oracle has worked on performance enhancements over the years. Addition­ally, you can push audits to SYSLogs and Windows Event Logs (18c, 19c, and 21c).

There are both common and local audit policies in container databases (CDBs). The common audit policy is available to all plug­gable databases (PDBs) in the multitenant environment. Audit pol­icies are created and defined in CDB ROOT. Tracks and audits are only related to common users and common roles. Local audit pol­icies can be defined either in the CDB level or PDB level and cover both local and common users and roles.

Auditing strategies may include a few different tactics. You can establish a set of audit rules/policies that is going to be common in your database landscape. In coordination with your organization’s security team, you can reference CIS (Center for Information Secu­rity)-and STIG (Security Technical Implementation)-tailored poli­cies. The data classification process in your organization is a driver to identify sensitive data. Based on that, you can implement more rigorous security controls and comprehensive audit policies. Ora­cle Database Security Assessment Tool (DBSAT) produces a report called “Oracle Database Sensitive Data Assessment.”

Emad recommended not bypassing auditing through Oracle because Oracle has been proactively fixing security vulnerabilities related to auditing, demonstrating the importance of auditing for threat detection and potential data breaches.

Some of the features of Unified Auditing include:

  • Unified Auditing Top-Level Statements (19c)
  • DB_GUID Audit Record Field for SYSLOG and the Windows Event Viewer
  • Auditing for Oracle XML DB HTTP and FTP Services (21c)
  • Unified Audit Policy Configuration Changes Effective Immediately (21c)

Operating System Auditing

Operating System Auditing is a powerful method to secure and harden your database environment. Unfortunately, many organizations are not implementing it in their infrastructure.

Users are able to perform SYS operations without an audit. Uni­fied Auditing “spill over” files are generated as binary OS files when the Oracle database system is either in mount state or read-only mode.

When accessing the database server as a SYS user with a SYSDBA administrative role, all SYS operations will be logged in unified_ audit_trail. However, there is a problem. The audit table will log that the “SYS” user is logged in with OS account “oracle,” but this infor­mation is not as detailed as we would like; we would want to know the DBA or system analyst who accessed the database for forensic evidence, said Emad. This is an issue because normally you access with your own OS account then switch to Oracle OS account.

Monitoring and Auditing Database Configuration Files

The auditing and monitoring of Oracle Database configuration changes is an area that is widely missed by many organizations. Do you:

  • Monitor listener logs and archive them?
  • Monitor the sqlnet.ora file for changes?
  • Monitor changes in your database binaries?

The listener log file contains a wealth of information—details such as source IP address, hostname, etc. Listener log files should be rotated for performance and for future forensic investigation. If you are configuring valid node checking (VNC), rejected con­nections from the listener are recorded in the listener log only. Auditing will not capture this as a “failed login,” as the connection is not reaching the database system.

To learn more, check out Emad’s INSYNC presentation at  You can also follow Emad on Twitter (@Emad_Mousa) and visit his blog