Oracle Auditing

[sjwales]

So the Internal Auditors decided that we need to do a little more Oracle Auditing than we are now.

So, I did the following:

In init.ora:

audit_trail = db
audit_sys_operations = true

I bounced the instance.

When the instance came back up:

audit dba, resource whenever successful;
audit all on sys.aud$ by access;

However, when I try to connect / as sysdba and try to make anything appear in sys.aud$, I'm getting nothing.

I've created and dropped objects.
I've granted and revoked privileges.
I've issued alter system commands.

Nothing.

Anyone have a likely suggestion as to why I'm not generating records in the Audit Trail?

Thanks
Steve

stephen.wales@riotinto.com

 

[SantaMufasa]

Steve,

What, precisely did your auditors say are the minimum requirements for your Oracle auditing? Auditors usually want to know specific values such as: When did Who change What tuple's old value to its new value.

Oracle Auditing shows Who used which Oracle privilege to change which table. Those pieces of information are usually far from sufficient.

Let us know.

Mufasa
(aka Dave of Sandy, Utah, USA @ 00:10 (14Oct04) UTC (aka "GMT" and "Zulu"), 17:10 (13Oct04) Mountain Time)

 

[sjwales]

Well, the auditor we had in gave a very vague finding that we need to set Audit options to audit what the DBA's are doing. So, I've been instructed to set up auditing of what effectively is actions taken by me and my colleague.

From the research I've done to date, tracking what I do in the likes of creating and dropping objects and granting and revoking privs, and the types of "alter ..." commands.

It's not application auditing, but more DBA auditing in the case of someone doing something "bad".

I believe they want it for more of a CYA than anything. Because when you don't trust your SA's and DBA's, you've got bigger problems than making auditing work.

Steve

stephen.wales@riotinto.com

 

[SantaMufasa]

Steve,

Point out to whomever is responsible for your auditing decision making that if the outside auditors offer vague findings, then you can produce vague responses. If Auditors uncover audit exceptions, then they (as auditors) need to be precise in what will resolve the audit exception. Oracle AUDITing has the deficiencies that I mention, above. You need to obtain sign-off from either the external auditors or from your internal auditors that the (very lacking) information that Oracle produces from it AUDIT module is sufficient to resolve the audit exception. If you don't obtain some sort of up-front concurrence/sign-off that Oracle auditing is sufficient, then you run the risk of someone coming back later saying, "Sorry, you still don't comply."

If, instead, auditors want to see WHEN WHICH DBA is making WHAT specific structural changes to the database, then it will require audit triggers on data dictionary objects.

Let us know,

Mufasa
(aka Dave of Sandy, Utah, USA @ 17:37 (14Oct04) UTC (aka "GMT" and "Zulu"), 10:37 (14Oct04) Mountain Time)