Oracle Auditing Traps
Burleson is the co-author of the bestselling
Privacy Security Auditing: Includes Federal Law Compliance with
HIPAA, Sarbanes-Oxley & The Gramm-Leach-Bliley Act GLB", by Rampant
The Auditing Traps
The common auditing traps are well-known in the
IT security field and are taught in almost every business school in
the USA. Given the wide knowledge of these exposures it is
surprising how often they are disregarded by the IT manager.
Cover all layers - Protecting the application
layer is only part of the solution. A comprehensive auditing
solution must check for access at the web cache layer (cached HTML
data), application server caches, database caches and backdoors, and
access violations at the server level.
Exclude privileged users - Another common trap
is allowing privileged employees to bypass security and audit
mechanisms. Your Systems Administrator and DBA have no business
touching your auditing mechanism, and while they may be responsible
for the integrity of the data, a third-party must be used to perform
all auditing collection, administration and reporting duties. There
have been many serious lawsuits where a dishonest DBA entered a
database and changed financial data, disclosed confidential
information and violated Federal data access regulations.
Not knowing how it happened –Finding a security
violation and never being able to determine the cause creates a huge
legal liability for any corporation, and this is very common among
IT shops that choose to use piecemeal solutions to their privacy and
auditing mechanism. In one case, a user was found to be committing
fraud, but without an audit trail of exactly what transpired the
organization had no way of understanding the scope of the damage.
Non-uniform audit rules –Another of the common
traps is applying different rules to auditing of different systems.
This is often the result of the limitations of the application
code. For example, you may be able to add a complete auditing
solution to the system that was developed in-house, but you do not
have the same luxury when using an ERP product (SAP. PeopleSoft)
because you cannot touch the application code.
With all of these exposures and threats the
savvy IT manager must be able to cover themselves from even the most
unlikely scenario. Here are some of the common ways that the IT
manager ensures that they have a compliant, robust and comprehensive
Segregation of Auditing Duties
While general security and auditing are passive
activities, a comprehensive solution to auditing requires real-time
reporting of active attempts to bypass security. Remember, smart
shops close all back-door data access (e.g. ODBC) and enforce data
access via the application layer. However, we must still create an
alert mechanism for all data access attempts at all layers, whether
malicious or benign.
This segregation of duties is critical because
it is considered malfeasance to give the "Keys to the Kingdom" to
anyone charged with maintaining the servers and databases. In many
cases disgruntled employees may view confidential information for
personal gain and sometimes create mechanisms to disclose the
information if they are terminated from employment (see horror
stories later in this paper).
Now, let's change focus and examine how the IT
manager can satisfy their due diligence requirements while
satisfying their auditing challenges.
Security, Privacy and Auditing Misconceptions
After interviewing dozens of IT managers, a
common set of misconceptions arise about compliance with Federal
regulations for security and privacy. This is not surprising, given
that the legalese of the actual laws is almost indecipherable, but
the IT manager needs to know about the realities of these important
new laws. Some of the most common misconceptions include:
Prevention alone is sufficient –Traditional
security measures focused on "perimeter" security (e.g. firewalls)
are an important component of mitigating the risks of inappropriate
data access or changes. But with most error and fraud occurring
from within the organization, it's important to have the
ability to understand exactly what is happening to the data . A
complete record of data access and change provides this "detective"
capability which augments existing security.
Application access, privilege controls and logging
are enough - This is a very serious misconception because it
ignores the other important access areas. As we see, all data
access must be audited directly at the data source.
Preventing fraud is the only goal - Many IT
managers fail to account for the possibility of human error, which
is more prevalent than fraud, in their auditing plan. A
comprehensive solution must account for legitimate errors by
end-users and IT staff.
Now that we see the common misconceptions let's
examine the importance of auditing data at the data source, the
database management layer.
Auditing Data at the Source
All IT managers know that simple triggers and
code extensions can be used to enforce security and privacy at the
application layer. The real problem is securing the data source and
all intermediate repositories and providing the ability to
understand the root cause of the violation.
There are many challenges involved with
auditing at the database level. If you want to understand "how" a
violation happens, you must audit all events of interest,. These
events include privileged access by IT personnel, the auditing of
all changes to the data, auditing all viewing of confidential data,
and recording all changes to the database infrastructure, both by
DDL and changes to executable database procedures. Let's take a
close look at each auditing requirement.
Auditing Privilege/permission and Logon events
must have a complete record of the users who have data access
including; "who" is attempting to get it; "what" they have rights to
do with the data, "why" they are changing the data, and "when" the
data was viewed or changed.
many databases such as Oracle provide primitive logon triggers for
determining logon events, they don't work with many modern ERP
products (SAP, Oracle Applications, PeopleSoft) because they use
pre-spawned connections to the database. User authentication and
access management is done by the application server and the
individual users are not exposed to the database.
"who" aspect of data auditing can be confounded if you use a tool
such as SAP or Oracle applications that pre-spawns anonymous
connections to Oracle. The application controls user access and
authenticated users are directed into the database under the control
of the application (Figure 8).
Figure 8 - External application authentication
these types of architectures an end-user has no direct privilege
against the data source and the permission to view and access data
is granted via the application. Because the application controls
all database access, you don't have to be concerned about back-door
access with non-application interfaces such as Crystal Reports or
However, it is critical to audit the activity of privileged users,
including DBAs, who have direct access to the database and can
access or modify the application's underlying data.
Oracle auditing book, click here
excellent Oracle auditing product, click here