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 Regulation has similar requirements. In addition, there are many internal rules and regulations mandated by companies themselves. Besides compliance, other reasons for auditing include monitoring and analyzing database activities for malicious and abnormal activities, developing 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:
- Oracle Database Unified Auditing
- Operating System Auditing
- 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. Additionally, 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 pluggable databases (PDBs) in the multitenant environment. Audit policies are created and defined in CDB ROOT. Tracks and audits are only related to common users and common roles. Local audit policies 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 Security)-and STIG (Security Technical Implementation)-tailored policies. 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. Oracle 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. Unified 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 information 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 connections 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 https://questoraclecommunity.org/learn/recordings-presentations/best-strategies-to-audit-your-database-system. You can also follow Emad on Twitter (@Emad_Mousa) and visit his blog https://databasesecurityninja.wordpress.com.