Strategies and Considerations for Auditing Your Database System


One of the main drivers of auditing is compliance. The Health Insurance Portability and Accountability Act in the United States requires health care providers to provide audit trails on anyone and anyone who touches data in their records. The EU General Data Protection Regulation has similar requirements. In addition, there are many internal rules and regulations imposed by the companies themselves. Besides compliance, other audit grounds include monitoring and analyzing database activities for malicious and abnormal activity, developing threat detection with real-time monitoring, and integrating 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 audit:

  1. Unified Oracle Database Audit
  2. Operating system audit
  3. Monitoring and auditing database configuration files

Unified Oracle Database Audit

Oracle Database Unified Auditing was introduced in Oracle 12c R1. It’s important to note that mixed mode is enabled by default and traditional auditing is deprecated in Oracle 21c, Emad said. Oracle has worked on improving performance over the years. Additionally, you can push audits to SYSLogs and Windows Event Logs (18c, 19c and 21c).

There are common and local audit policies in container databases (CDBs). The common audit policy is available for all pluggable databases (PDBs) in the multi-tenant environment. Audit policies are created and defined in CDB ROOT. Leads and audits are only linked to common users and common roles. Local audit policies can be set at the CDB or PDB level and cover both local and common users and roles.

Audit strategies can include a few different tactics. You can establish a set of auditing rules / policies that will be common in your database landscape. In coordination with your organization’s security team, you can reference the CIS (Center for Information Security) and STIG (Security Technical Implementation) custom policies. The process of classifying data in your organization is a driving force in identifying sensitive data. Based on this, you can implement more rigorous security controls and comprehensive audit policies. The Oracle Database Security Assessment Tool (DBSAT) produces a report called “Oracle Database Sensitive Data Assessment”.

Emad recommended not bypassing auditing through Oracle as Oracle proactively addressed audit-related security vulnerabilities, demonstrating the importance of auditing for detecting threats and potential data breaches.

Some of the features of unified auditing include:

  • First level unified audit statements (19c)
  • DB_GUID audit record field for SYSLOG and Windows Event Viewer
  • Auditing HTTP and FTP Oracle XML DB Services (21c)
  • Unified Audit Policy Configuration Changes Effective Immediately (21c)

Operating system audit

Auditing the operating system is a powerful method for securing and hardening your database environment. Unfortunately, many organizations do not implement it in their infrastructure.

Users can perform SYS operations without auditing. Unified audit “overflow” files are generated as binary operating system files when the Oracle database system is either in a mounted state or in 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 record that user “SYS” is logged in with the operating system account “oracle”, but this information is not as detailed as we would like; we would like to know the DBA or the system analyst who accessed the database to obtain forensic evidence, Emad said. This is a problem because you normally log in with your own OS account and then switch to the Oracle OS account.

Monitoring and auditing database configuration files

Auditing and monitoring Oracle Database configuration changes is an area largely ignored by many organizations. Do you:

  • Monitor and archive listening logs?
  • 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, and so on. Listener log files should be rotated for performance and for future forensic investigation. If you configure valid node verification (VNC), rejected listener connections are logged in the listener-only log. The audit will not capture this as a “connection failure” because the connection does not reach 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


Comments are closed.