Re: OT - SarBox paranoia prevention ?

Thanks for the laughter, help, and ideas :)

Auditors do not want their company to become another Arthur Anderson so they will not sign off until risks have been mitigated to their satisfaction. Likewise, company management does not want to sign off (personal liability) until these auditors are satisfied - CYA on a grand scale.

The idea of wrapping database procedures to prevent modification is intriguing. Maybe wrapped and unwrapped versions could be promoted to production code libraries - with the wrapped version being placed in the database. A periodic audit check could compare a wrapped copy of production source code with the wrapped
version stored in the production database. If the wrap utility has not changed, the comparison should find no differences.

Also agree that code walkthru (peer review) needs to be part of code promotion process (trying to prevent Garbage In, Garbage Out).

When a DBA or application production person executes non-production code (e.g. anonymous pl/sql instead of production stored procedure), I do not know how to log that non-production code has been used to process production data. Monitoring and detecting use of non-production code is as much a problem as preventing it.

On an IBM mainframe running MVS, a system programmer had to specify which datasets could contain executable code that could be run with operating system authorization. Seems like a conceptually similar setup is needed for applications to prevent use of unauthorized code on application data.
Compounding this security issue is ongoing verification and authorization of programs on all platforms (how to prevent a rogue executable from impersonating authorized production application code).

Keep Smiling :)

--
http://www.freelists.org/webpage/oracle-l