Three Tier Oracle Security in London ~ Paul M. Wright

(nix, oracle, java, www, cloud ) intersect (safety, security, reliability, integrity)

Three Tier Oracle Security in London ~ Paul M. Wright RSS Feed


The dust has settled after Infosec and so what remains must by definition be memorable. In my case, I remember discussing the etymology of the word Oracle with a charming marketing exec. Yes, even before the Greeks, Alexander consulted Amun’s Oracle at Siwa and it must have been good advice as he went onto to “liberate” half of Eurasia. More pertinently I enjoyed talking to Oracle folks about single sign on which is one of the most active inhouse Oracle Security sectors.

Then I moved onto Arcsight . They have packaged some of the ideas about centralised log correlation using an Oracle depository which I discussed years ago in my Oracle Forensics book. I was impressed with the detailed thoroughness of the Arcsight solution (five timestamps per entry!). I find the relationship between networked time and distributed SCNs fascinating.. more to come on this later.

The highlight of the show for me was discussing Guardium’s DAMS technology with some knowledgeable folks. Guardium has grown into quite a big product and interestingly expanded into a holistic change management tool which can integrate with business processes connected to security. I like IBM research and enjoyed speaking to the team there. It is doubly interesting that there are still challenges that have not been solved by either Guardium, Sentrigo or Imperva e.g. alerting to users logging on that currently have the DBA role is a basic requirement but cannot be done properly by either products as neither can run SQL as part of a rule. DAMS are becoming reliable now and ready for serious Enterprise integration but can still be improved. Each one has different advantages which will suit different client requirements.

Also we should not forget that for some activity monitoring purposes the Oracle DB can cope quite nicely on it’s own. Basic audit to SYS.AUD$ for low occurrence events provides low perf hit audit which is cheap and will suffice in some cases. Additionally in 11g the AUDIT_SYSLOG_LEVEL parameter provides extra facility for sending OS audit to SYSLOG, which by default is only accessible to root. Interestingly when AUDIT_SYSLOG_LEVEL along with AUDIT_SYS_OPERATIONS is set to TRUE then all SYS* operations are recorded to /var/log/secure even if AUDIT_TRAIL is set to NONE. Or if AUDIT_TRAIL is set to DB for SYS.AUD$ then SYS* actions go to syslog and nonSYS* actions go to the DB….hmmm…

So if DBA accounts do not have root access then AUDIT_SYSLOG_LEVEL parameter can provide some separation of duty. root unix SysAdmins can audit DBA accounts even though they the DBAs have access to the oracle unix account. This would not have been the case with traditional OS audit via *.aud files which are accessible from the oracle unix account.

In my experience banking does try to separate root access from the DBA account holders, so there can be value in using AUDIT_SYSLOG_LEVEL in this way … but there are a couple of points to bear in mind.

1. A user with oracle unix account or just SYSDBA privilege can still turn off the audit trail anyway as it is controlled from the DB!
2. Any audit to the DB is almost useless from security perspective as a low privileged user that escalates to DBA can then delete those escalatory actions from SYS.AUD$. Of course they would have turned off AUDIT_SYS_OPERATIONS and AUDIT_SYSLOG_LEVEL first to omit SYSLOG entries.

So..the only evidence of audit trail omission after an exploitative escalation would be a mandatory audit entry showing the SYS connection and reboot. Therefore from a security perspective auditing should be handled externally from the database. This is true of all systems. Effective Audit has to be an external function. That is why DAMS like Guardium, Imperva and Sentrigo have a significant role to play for the forseeable future IMO.

Unfortunately I don’t have time to go into more detail on this currently, but will be following up especially with regards to host based DAMS which potentially have the most to offer for high security environments.


Leave a Reply

You must be logged in to post a comment.