Re: OT - SarBox paranoia prevention ?
- From: Niall Litchfield <niall.litchfield@xxxxxxxxx>
- To: chip.briggs@xxxxxxxxx
- Date: Sun, 20 Feb 2005 13:19:00 +0000
On Sat, 19 Feb 2005 13:21:03 -0700, Chip Briggs <chip.briggs@xxxxxxxxx> 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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
