Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: OT - SarBox paranoia prevention ?

Re: OT - SarBox paranoia prevention ?

From: Niall Litchfield <niall.litchfield_at_gmail.com>
Date: Sun, 20 Feb 2005 13:19:00 +0000
Message-ID: <7765c8970502200519645f5393@mail.gmail.com>


On Sat, 19 Feb 2005 13:21:03 -0700, Chip Briggs <chip.briggs_at_gmail.com> wrote:
> Earlier this week, SarBox auditors wanted proof that DBA's
> could not change database stored procedures (which would
> prevent DBA's from applying vendor patches for vendor
> supplied stored procedures). Also presents a problem since
> DBA's managed stored procedure configuration. SarBox
> auditors do not like DBA privileged access to application data.

Things have changed somewhat since the late eighties/early nineties when I was a terrible auditor, never-the-less the KPMG approach was not on prevention, but on documenting, invoking appropriate procedures and risk assessment. DBA work would be high risk, because it falls outside of normal procedures and often is not well evidenced. In addition the DBA can, if they are good enough, probably make any change that they wish, and cover their tracks. I'd say that all of these make the DBA liable to be subject to a *lot* of audit. It isn't so much a question of lack of trust or of not liking sysadmins or dbas, but of recognising a weak point. DBAs that document well, follow procedures and evidence their work will likely not find sarbox *too* much of a PITA. Folk that think they are kings of the database and the fount of all knowledge will find sarbox a pain. To be honest they should.

> Looks like these auditors do not trust anyone and want duties
> segregated so no single person has the ability to cook any
> books (complete prevention for Enron repeat).

segregation of duties is good, and would be a good argument for example for having two different dbas for production and development, it can't be taken to the nth degree. No auditor worth their salt will imagine than sarbox will prevent the next corporate fraud (politicians that passed the laws might be so deluded). Auditor's know that the senior executives of any organisation can pull the wool over everyones eyes (until the cash isn't available to pay a bill). This problem is as old as corporations.

> Any ideas how to prevent execution of non-production code
> against production data, whether the data resides in a
> database or operating system files (unix and windows) ?

It can't be done. You can however control and evidence how code gets into production and who and how such code change is authorised. Good companies already do this. You can also audit on an exception basis.

That said I would love to know of a product that would aid the audit of os files and database code.

-- 
Niall Litchfield
Oracle DBA
http://www.niall.litchfield.dial.pipex.com
--
http://www.freelists.org/webpage/oracle-l
Received on Sun Feb 20 2005 - 08:21:57 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US