Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 








Oracle Auditing traps

Oracle security Tips by Donald Burleson

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

The Oracle Auditing Traps

The common Oracle auditing traps are well-known in the Oracle security field and are taught in almost every business school in the USA.  Given the wide knowledge of these exposures Oracle is surprising how often they are disregarded by the Oracle 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), Oracle  application server caches, Oracle database caches and backdoors, and access violations at the Oracle server level. 


?         Exclude privileged users - Another common trap is allowing privileged employees to bypass security and audit mechanisms.  Your Systems Administrator and Oracle 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 Oracle DBA entered a database and changed financial data, disclosed confidential information and violated Federal data access regulations.


?         Not knowing how Oracle 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 Oracle shops that choose to use piecemeal solutions for 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 common trap is to apply different rules to auditing of different systems.  This is often the result of the limitations of the Oracle 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 Oracle manager must be able to cover themselves from even the most unlikely scenario.  Here are some of the common ways that the Oracle manager ensures that they have a compliant, robust and comprehensive solution. 

Segregation of Oracle 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.  For example, the Database Administrator (DBA) often needs to view database information as part of their administrative duties, and Federal laws mandate that this data access be tracked just as data access within the application layer.


This issue of ?privilege user? access is a serious security exposure.  Because the auditing solution must audit the access of Systems Administrators and DBA's, these employees must not have any control or responsibilities for the auditing mechanism.


This segregation of duties is critical because Oracle 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).


Shops falling under the scope of Federal privacy laws such as HIPPA are required to appoint a full-time employee, independent from the SA and DBA staff to control the auditing.  This job role has many names including the Security Privacy Auditing Manager (SPAM), Privacy Access Manager (PAM), Security Privacy Administrator (SPA)  and sundry other job titles.


Regardless of the title, the SPA must possess a combination of technical, application and management skills, unique to each organization.  For example, large health care companies normally employ a Medical Informatacist as the SPA, usually a highly trained Medical Doctor (MD) with skills in application design, systems architecture, systems administration and database administration. Financial institutions will employ a Certified Public Accountant (CPA) with a strong technical background.


In sum, the auditing collection, consolidation and reporting must be the responsibility of a separate Oracle entity, solely charged with managing all data privacy audits.  Any access outside the application layer, whether malicious or part of routine DBA duties, must set-off alarms for the SPA.


Now, let's change focus and examine how the Oracle manager can satisfy their due diligence requirements while satisfying their auditing challenges.

CYA for the Oracle Manager


The Oracle manager has a legal and fiduciary responsibility for the corporate data resource . This is a responsibility that should be taken very seriously. 


For example, HIPAA laws provides that a leak of information calls for a fine of up to $250,000 per incident and may result in the imprisonment of the executive in charge for a period up to 10 years. The severity of the penalty and the personification of responsibility is enough to make the executives of many organizations take this law and the issue of privacy and information protection very seriously.


As the Oracle manager you are also required by law (e.g. HIPAA) to provide a clear security policy that can be verifiable and, more importantly, auditable. In the normal course of business in any organization, some personnel will have to access data that is considered sensitive, so prohibiting their use is not feasible. HIPAA does not prohibit that access, but specifies that normal access be recorded as a policy, which should specify who can access what data, and any such access information should be recorded, or in other words, audited.


Even more important, the discovery phase of litigation against home-grown auditing solutions can be devastating.  Every line of code is put under a magnifying glass and security experts from around the world will be called-in to judge the lack of quality of your solution.  In almost every case the code is found wanting, and the responsible Oracle manager is held personally accountable for the exposure.  Here are some tips from the security experts: 

Don't Underestimate the Bad Guys

Kevin Mitnick, the noted computer felon likes to show how security breeches are commonly the result of employee errors.  In his book 'the Art of Deception?, Mitnick talks about his techniques to get trusting employees to disclose confidential information and privileged passwords.  In one case Mitnick was able to secure a privileged password using the name Lemonjello, and then bragged about the na?e employee who handed-over a system password to someone called ?Lemon Jell-O?.  In this case the Oracle staff was never able to ascertain the root cause of the breech because their mechanism for the dissemination and auditing of secure information was inadequate. 


While external fraud remains a serious issue we must also remember that most data access violations happen internally, and most are the result of unintentional access rather than malicious fraud.


  • Don't lose prospective partners - Whenever you share data with partner companies their due diligence requires them to verify your privacy and security mechanisms.  It's far faster and easier to just name a vendor product than Oracle is to make them undertake a multi-week examination of your home-made mechanism.  Some Federal regulations also mandate that you have a standardized information exchange interface.  For example, HIPAA mandates that the information related to health insurance must be exchanged in a standard, predefined way. For instance, all the information that typically goes to the insurance company from the provider during a claim filing must be in a certain format, defined by the law.


  • Don't get sued by customers - In today's litigious society, almost every breech of privacy and security is followed by expensive litigation.  On the issue of medical records privacy, the situation is even more fluid and prone to severe security lapses. HIPAA addresses this problem by mandating the audit requirements of these records and strictly enforcing the requirements by placing stiff penalties for non-compliance.


?         Don't lose goodwill - Security and privacy breeches are big news and slack companies are pasted across the headlines anytime a major exposure occurs.  This can be crippling to a company's reputation and brand loyalty, especially in the financial services arena when companies are judged by their absolute commitment to financial security.


There are many common misconceptions about privacy and security auditing, even amongst Oracle management.  If you fail to grasp the volume, scope and complexity of an auditing solution you can place your entire company at risk.  Let's take a closer look at these common misconceptions.   

If you like Oracle tuning, see the book "Oracle Tuning: The Definitive Reference", with 950 pages of tuning tips and scripts. 

You can buy Oracle direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts.



Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2020

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.