Mining the Audit Trail - Techniques, Traps, Products, etc.

Question

I'm currently using the following version:
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE    11.2.0.1.0      Production
TNS for 32-bit Windows: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - ProductionMy AUDIT_TRAIL parameter is:
NAME                                 TYPE        VALUE
audit_trail                          string      DB_EXTENDEDI'm just curious on what techniques you use to mine the audit trail. Oracle does not seem to provide much information on ways of mining it outside of:
Auditing Suspicious Database Activity
I have a requirement to review the audit data for multiple databases on a daily basis. So I'm after something that will allow me to see suspicious activity, if any, with a high degree of effectiveness and accuracy.
One method would be to develop a library of scripts that looks for suspicious activity. The problem I have with that is I may miss audit records that are suspicious but outside the scope of the scripts. This concerns me. Additionally, I don't have the time to review all audit records for all the databases I have to manage. Another thought I had was to develop a list of patterns for known entries and select the rows that don't meet these patterns. I think this mitigates the concern I have with missing suspicious activity but I'm not sure of the performance implications of such an implementation (especially as the audit trail grows).
A third method would be to acquire a commercial product, but I haven't spent time searching for such a product yet.
Thanks for your input!

Answer 1

Mark D Powell wrote:
I think you first have to define what series of actions might constitute suspicious activity and then try to write generalized code that can locate and identify these patterns such as disabling table triggers, performing DML on the table, and re-enabling the table triggers. This pattern can be necessary/justified for performing certain actions such as a purge of the majority of the table data via selecting it out, truncating the table, and re-inserting the data since you not want the the insert triggers to fire for rows already processed. This would however not be a pattern of action you would expect to see outside of a maintenance window during normal processing hours.What you are explaining here is the crux of my problem. I see two approaches (mentioned in my original post). I feel like this approach here is fundamentally flawed because I don't think anyone can come with all possible scenarios. So we are bound to miss something at some point in time which is not a good thing.
The other approach I was thinking about was removing all the "expected" or records due to "normal business processing" from the result set making the remaining records interesting by default. Then after reviewing these records I could decide on whether they were "expected" (and then be added to the list of patterns to ignore) or truly an issue. I'm interested to see if anyone takes this approach and how they implemented it in a well performing, scalable and maintainable way.
The first thing that came to mind for me was Expression Filter, but I'm currently having performance issues (see my thread in the Expression Filter forum).
Naturally what actions you audit are going to determine what behavior patterns you can even look for to begin with and on how your applications work.Completely understand and agree.
I am in favor of auding pretty much all DDL in a production environment and as little else as possible. Objects should be created once and re-used many times so all DDL is on interest except truncate on tables that are routinely truncated say as part of the production batch.Unfortunately the requirements for auditing trickle down in my organization and it is pretty extensive. I'm seeing thousands of audit entries a day which makes it hard to sift through and find the records of interest.