RE: Sarbanes Oxley reporting

I was requested to implement the whole sox stuff last year, then the work was externally audited and passed an ISO certification.

Don't ask me what is an ISO certification on a Sox box but in October I was notified that the work was certified. It surely changed my life, I just have to find what.  

The solution adopted was to create no object at all on DB but to keep information on the server under the form of ASCII files under root ownership. Root launch the sox script from his cron with sudo su - oracle. This way the DBA don't have access to the result and can't modify the scripts or the results. There is a set of 22 sox scripts each one run one to four sql that address one sox points and output result goes into an expected state directory.

First time you run this, you validate the results and this is your set of reference files. Subsequent runs are compared to the reference files (awk, diff, cmp) and only mutations are reported. If a mutation is 'normal' then you assert it and the new situation becomes you reference file. If the mutation is not normal, then you just singled out a 'violation'.

Sox policy is all about human being asserting mutations into a DB. It gives useless job to people who take it very seriously.  

Sleeping in progress, please wait......  

(sleeping at work or doing nothing is not a Sox violation)  

Bernard Polarski

Oracle DBA  

From: Jared Still [mailto:jkstill_at_gmail.com] Sent: maandag 12 februari 2007 19:48
To: Oracle-L Freelists
Subject: Sarbanes Oxley reporting  

Those of you that work in the USA, or even for USA based companies know what I'm referring to here.

I am curious what type of reporting you do to document the tests for your SOX controls in regards to Oracle databases.

The Sarbanes Oxley legislation is rather loosely written, leaving its interpretation pretty much open to negotiation between a company and its auditors.

The reason for asking is that my reports have been accused of being too verbose, or rather, have too much data, and not enough information.

I disagree, and if anyone reading them would simply read the instructions on the first page, they would not have so much difficulty.

But I digress.

It would be most interesting to see what kind of reports others are using to Satisfy SOX requirements for Oracle.

Comments on possibly improving the reports I am currently generating would also be welcome.

The following types of reports for Sarbanes Oxley are supplied for various tests throughout the year. All are in Excel.

Each Excel file is for a single database.

• database_roles.xls - a list of all roles, with all privileges granted to all roles. It is recursive, in that when a role is assigned to a role, it can be clicked on to drill down on the privileges. One role per page.

This one does require some guidance if the auditor is unfamiliar with the privileges.

• oar.xls - oracle application roles - (something of a misnomer here) This Excel file includes the following worksheets:

  System Accounts: All known Oracle/Application/Busisness specific   database accounts are documented here, with the account owner and purpose.
  eg. SYSTEM, SCOTT, SAPR3, FNDAPP, etc. accounts

  Known Roles : Similar to System Accounts, but for Database Roles

  Account Reconciliation: List of accounts in the database. Those not found
  in the System Accounts worksheet are flagged in Red.

  Access Reconciliation: Roles assigned to accounts. Accounts not found   in the System Accounts worksheet are flagged in Red.

  Role2User: Roles assigned to users/roles, in ROLE order. Unknown accounts
  flagged in red.

  Role2Privilege: Similar to Role2User, but for individual privileges.

  User2Privilege: Similar to Role2User, but for user/role mapping to   privileges, in user/role order.

• ora_parms.xls - database parameters report. This reports those parameters that are deemed relevant to security. eg. REMOTE_OS_AUTHENT
• profiles.xls - report on database profiles one page for each profile (including DEFAULT) and a page for the function used for password verification for each profile.
• sessaud.xls - report on logons/logon attempts basically a dump of dba_audit_sessions for the relevant time period. Not really much use other than as evidence of which accounts have logged on to the database. Excel's autofilter feature makes it easy to see the list of accounts that have logged on.
• baseline.xls - this report details what objects have changed in the database, and when. One worksheet for each type of object. Ideally one should be able to trace a changed object back to a change control ticket.

Changed/new/deleted objects are highlighted in blue.

---

That does it for my reports.  I'm looking for ideas on
how to consolidate this data into something auditor are
more likely to read without looking quite so confused 
when doing so.

Discussion of how others are satisfying SOX reporting 
requirements for Oracle databases should be interesting
and useful.


Jared


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