Oracle Auditing Reliability and Completeness

For complete details on Oracle auditing, see my my book "Oracle Privacy Security Auditing", and you can buy it at this link and get instant access to Oracle auditing scripts.

Oracle Auditing reliability

Many IT shops fail to realize that a haphazard 'sampling? approach to Oracle auditing is insufficient. A continuous Oracle audit is required and the audit must be archived for long-term access. 

This is not an easy task.  In cases where you must audit the viewing of confidential data in Oracle, you might need to archive a volume of data greater than the size of the whole database, everyday, 365 days a year.  With many shops archiving hundreds of gigabytes of data every day, it becomes critical that all of the archived data be accessible and complete. 

For example, HIPAA requirements clearly state that user accesses to the database be recorded and monitored for possible abuse. Remember, this intent is not only to catch hackers but also to document the accesses to medical databases by authorized end-users.  In today's litigious society, prudent companies capture the ?who?, ?where?, ?what?, ?when? and ?why? for all access to confidential information.  The ?why? aspect is critical because authorized end-users may access confidential Oracle information for unsavory purposes.

The data volumes of Oracle audit information can be staggering.  Larger shops may capture trillions of bytes of Oracle auditing information every week, archive and store this data for several years, and have an automated mechanism to easily extract information about any individual in their database.

A comprehensive solution must also have the ability to audit all possible points of entry to the data.  It must audit Oracle access from the operating system (at the data file level), from the database management layer, the network and from the application layer (Figure 1).

 Figure 1 - The multi-layer data exposure issue

In a typical organization, Oracle data access occurs at many levels - - - at the end user presentation layer, at the middle tier (Oracle Application Server), at the application server layer, at the Oracle web server layer, at the standalone application screens and finally, at the Oracle database level directly. A properly compliant security implementation knows that it is almost impossible to clearly identify and secure all the remote data access points and that proper security and auditing is firmly in-place at the data source. Attempting to audit data from multiple remote layers is suicide, especially when hackers have learned to access information from outside the application layer, accessing the data directly from within the database or accessing the data files directly from the server.

The ability to capture data access at the Oracle database source is an absolute requirement for reliable Oracle data auditing.  While all legitimate data access is done via the application malicious hackers rarely access the system via the Oracle application screens.  Instead, they access the data directly from the Oracle files on the operating system or gather the data directly from the Oracle database layer.  We also see hackers gathering confidential information directly from the web cache layer, using buffer overflow techniques to grab information from outbound HTML pages.

Even at the database layer there are opportunities to bypass the Oracle application.  Ad-hoc query tools such as SQL*Plus, Crystal Reports and ODBC tools provide backdoors for legitimate users to bypass Oracle application layer auditing.  
 

If you like Oracle tuning, see the book "Oracle Tuning: The Definitive Reference", with 950 pages of tuning tips and scripts.  You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts.