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