Pete Finnigan's Oracle Security Forum (
Oracle Security >> Oracle Auditing >> Managing the XML OS Audit Trail
(Message started by: Pete Finnigan on May 29th, 2009, 2:53pm)

Title: Managing the XML OS Audit Trail
Post by Pete Finnigan on May 29th, 2009, 2:53pm
I've just enabled the XML OS audit trail on our UAT EE 10.2.0 databases in order to test out auditing and associated processes prior to rolling out to production.

SQL> show parameter audit_trail

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
audit_trail                          string      XML, EXTENDED

This is all working as expected, and I can collect the data centrally by querying the v$xml_audit_trail view as documented.

What do you believe is the best way to manage rolling over the audit logs?  Should I just have a script that deletes the files once the audit records have been collected and forwarded to our audit system?  I can see that this might result in a few missed records, but I can't think what else to do.  From the documentation there is a PL/SQL package that can be called but this is only available if you've got the Database Vault option installed.

At the moment I've got a Java procedure that runs a UNIX script to move/delete the .xml and .txt files and this can be called immediately after the audit rows have been processed.

Title: Re: Managing the XML OS Audit Trail
Post by Pete Finnigan on Jun 2nd, 2009, 8:42am

I can see your dilemma. The first question I would ask; is there a window that works better for doing the rollover; i.e. no or very little activity that may generate audit? - or how often are you doing the rollover? its a six and two threes problem. The more often you roll over the more chance that records are missing; the less often that you roll over the more chance that a DBA can manipulate the audit trail.

Two options: one use AUD$, the only benefit to using xml is that the audit is more easily correlated externally if the audit is XML but you seem from your discussion not to be taking advantage of that feature and the other aspect is that security is slightly better as the files are on the OS but that is hard to judge without seeing your set up to understand whether the DBA's can simply delete the files on the OS (you have in fact given them a Java procedure so you have removed that seperation of duties anyway). Going to AUD$ would in your case be no worse than what you have with XML. But it would allow you to purge and archive without loss of data.

The other option is to go to syslog instead (no extended option though) as this will allow seperation of duties and also real time removal of the audit from the box.




Powered by YaBB 1 Gold - SP 1.4!
Forum software copyright 2000-2004 Yet another Bulletin Board