Call: +44 (0)1904 557620 Call
Blog

Pete Finnigan's Oracle Security Weblog

This is the weblog for Pete Finnigan. Pete works in the area of Oracle security and he specialises in auditing Oracle databases for security issues. This weblog is aimed squarely at those interested in the security of their Oracle databases.

[Previous entry: "Happy 17th Birthday to this Oracle Security Blog"] [Next entry: "Joel Kallman Day"]

Designing Good Audit Trails for an Oracle Database



I have been asked to speak at the UKOUG Autumn Tech event. This is an online conference event and the https://ukoug.org/general/custom.asp?page=autumntechagenda21#menu1 - (broken link) agenda grid is live and I will speak at 15:00 to 15:45 BUT the link to the details of my talk is incorrect as it points to a Graham Spicers talk. I have asked UKOUG to fix this but it doesn't matter for now as I can discuss the contents of the talk here.

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.