Designing Good Audit Trails for an Oracle Database
The talk is all about building a good audit trail for your Oracle database. What I mean by good is a well designed audit trail and not one simply based on a set of technical settings BUT a well designed and thought out audit trail. First, who are you trying to satisfy? external regulations or even internal ones; do you want to be reactive - i.e. simply collect and store, do you want to be pro-active - i.e. use the audit trail in real time or semi real time to react to an incident and block or stop it. If you have to comply with regulations to gather certain audit trail evidence then there is no reason that you should simply comply with the regulations - often they are not good enough to use the audit to investigate a breach or to detect a breach. This is because they are designed by committee not designed by you and for your business.
One area I will focus on, then, of course is the good design. The audit trail needs to be designed first in terms of events; the events that you want to capture and we discuss these first as well as some sample events that I feel should be included. These are at a business level in a table in an MS Word document; these are not audit settings in the database. Once we have the list of events we can then decide what the technical solution is going to be (standard audit, unified audit, FGA, third party... ) and as part of this we decide what raw audit to be collected and how, then how to mine that raw audit to see if the event has occurred and we also bring in reporting and escalation and alerts. This is a designed audit not a list of random settings recommended by someone else.
I will also show the results of some hacking and what is captured with the base standard audit settings from Oracle and then implement a good set of policies in my database and show that the hacking is now captured in the audit trail.
Come along and learn about audit trails and good designs for capturing activity in the core database engine.