Re: OT - SarBox paranoia prevention ?
- From: Chip Briggs <chip.briggs@xxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Sat, 19 Feb 2005 19:25:12 -0700
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 :)
--
//www.freelists.org/webpage/oracle-l
Other related posts:
