Oracle Auditing Misconceptions

Oracle Security, Privacy and Auditing Misconceptions

 

After interviewing dozens of Oracle managers, a common set of misconceptions arose regarding compliance with Federal  Oracle  for security and privacy.  This is not surprising, given that the legalese of the actual laws is almost indecipherable, but the Oracle 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.

 Another important aspect of auditing is recording who was not granted access, not just who was permitted access, depending on the privilege setting. This could be due to a legitimate reason such as a bad password, but Oracle could also be a hacker trying to break in with multiple attempts at guessing the password. Oracle could even be an insider, a disgruntled employee trying to access information he or she is not authorized for. Whatever the reason may be, this kind of activity arouses suspicion and should be investigated.

 

?         Application access, privilege controls and logging are enough - This is a very serious misconception because Oracle 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 Oracle 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 Oracle staff.

 

?         Oracle is cheaper to build a custom audit mechanism - This is untrue - and dangerous.  While a once-over-lightly solution can be cobbled together quickly, mistakes of omission can cost your company millions of dollars in sanctions.  Worse yet, these ?cost effective? solutions almost always cost more in the long run as the Oracle manager discovers the huge costs associated with reporting, customization and consolidation with other audit trails.  Further, most Oracle organizations cannot afford to develop multiple audit systems to support their multi-platform environment.  We?ve already discussed that native tools cannot scale to accommodate the needs of a large enterprise.

Now that we have seen the common misconceptions let's examine the importance of auditing data at the data source, the database management layer.