SOX is process oriented. You document certain things (processes) that you
do/don't do and why you aren't doing them. How you document that and
control that is not up to the SOX auditors, but to the company itself. You
need to show that you are doing due diligence and all that good stuff. As
our company is headquartered in the US, I have to deal with the SOX auditors
all the time. At no time in all our audits has there been any requirement
to document DBA activity yet (other than showing user security, privileges
etc). Touching financial systems, now that is a different story. If it
potentially can affect the financial statements, then beware.
--
Terry Dykstra
Canadian Forest Oil Ltd.
"DA Morgan" <damorgan_at_x.washington.edu> wrote in message
news:1114969895.945079_at_yasure...
> Galen Boyer wrote:
>
> > On Sat, 30 Apr 2005, damorgan_at_x.washington.edu wrote:
> >
> >
> >>So if complying with federal law requires FGAC and FGA and other
> >>capabilities built into 9i and 10g so be it. If in the EU you don't
> >>have laws equivalent to SarbOx you have far less incentive to
> >>upgrade.
> >
> >
> > Hey Daniel,
> >
> > Are the FGAC and FGA able to pass all Sarbanes-Oxley requirements? In
> > this, I mean, I know I can solve any requirement with the Oracle tools,
> > but do Sarbanes-Oxley audits recognize that fact and therefore they
> > audit the implementation, or do they just say, "You have what access to
> > the database? No way hose!!!"
> >
> > With FGAC and FGA one can legitimately give sqlplus access to end-users
> > and completely still pass audit muster. But the Sarbanes-Oxley doesn't
> > allow "direct" access to the database. Hm..., so I have an app user
> > that owns nothing but synonyms with appropriate access to the
> > application schema and logon triggers transporting those users to the
> > app user. These users can have sqlplus access, correct? Or is
> > Sarbanes-Oxley going to shut that down?
> >
> > What exactly is "direct" access?
>
> The issue here is a bit more complex. End users access databases via
> front-end tools so compliance relates to certifying the tool and
> auditing changes to the tool. Developers don't count because they are
> not allowed into production systems that are SarbOx compliant and if
> for some reason they do gain access it is fully audited which, of
> course, could be done in just about any version of Oracle.
>
> The issue that causes the grief before 9i is the ability to audit the
> actions of DBAs. In any version of Oracle prior to 9i auditing a DBA
> logging in as SYS or INTERNAL is essentially impossible. If you can
> construct a method of auditing ... they can defeat it.
>
> So it isn't about SQL*Plus vs. some other tool. It isn't even about
> the privileges one has when logging on. But rather about auditing
> and accountability. If any value is changed the C-level management
> can be criminally liable if they can't create an audit trail not all
> that different from a "chain-of-evidence" audit trail the police use
> when handling evidence in a criminal case.
>
> Of course it is in your best interest to keep everyone and everything
> possible out of production as it minimizes risk. But it is not the
> access or the tool, in and of itself, that is the issue.
>
> HTH
> --
> Daniel A. Morgan
> University of Washington
> damorgan_at_x.washington.edu
> (replace 'x' with 'u' to respond)
Received on Mon May 02 2005 - 09:54:59 CDT
