RE: SOX Reporting Requirement
Date: Thu, 28 Aug 2014 11:54:33 -0700
Message-ID: <004c01cfc2f1$820905d0$861b1170$_at_comcast.net>
As Frits mentioned the rules sometimes have no real backing.
You should ask your compliance team for the current copy of the SOX controls the company is operating under. You will find that those controls were normally written by the compliance personnel of your company not by an external auditor or from the law itself. New rules are modification to the rules passed on to you happens in many times because someone went to a conference or read a new book or blog instead of an actual law change or there is someone new in the position trying to prove themselves. (Not always the case as I have been in some companies that actually had really poor SOX controls and we went through 6 months of fixing them.)
Once your read those documents then it is easier to determine what is necessary to be done on your side or determine the SOX control needs to be rewritten which is totally within the law. It is one of the missing pieces in a lot of organizations are the technical SOX controls where the tech side was not involved in writing the controls and are presented to your as sacrosanct unchangeable law, when they are not.
SOX controls are financial compliance rules extended into the Technical side of the space. Can you name a financial system like EBS or SAP that actual have the types of controls you are being asked for built into them already as 3rd party applications?
The answer is no and normally on the finance side the actual control is more around the physical and SW security controls that only the appropriate people who follow the financial rules have access to make the changes and that the technical side has some form of audit controls as to who accessed the systems and when, rather than wanted a record of every state change of the data.
I have dealt with some organizations who actually wanted to track every state of the data and who touched it. Normally when you sit down with the CFO and have a discussion about the controls you will find out they have a significantly different opinion then the specific compliance person and you normally can get the rule changed to be something more appropriate. A simple walk through of the end of year book close process and potential of running book close multiple times normally does it. It is normally why the Finance system stores the end state of the row, except for maybe in the GL world for journal entries.
If you want to track every change then there are other systems/software you can purchase. I have tested systems such as Oracle Database Firewall, Oracle Database Audit and Imperva.
Matthew Parker
Chief Technologist
425-891-7934 (cell)
Dimensional.dba_at_comcast.net
<http://www.linkedin.com/pub/matthew-parker/6/51b/944/> View Matthew Parker's profile on LinkedIn
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of David Barbour
Sent: Thursday, August 28, 2014 11:18 AM
To: Frits Hoogland
Cc: oracle-l mailing list
Subject: Re: SOX Reporting Requirement
Well we do have an imaginative buch in our compliance department.
With respect to the Total Recall, it looks like it would work, but it requires the Advanced Compression Option which we do not currently have licensed. So either I revert to Plan A or inquire if their imagination includes a budget.
On Thu, Aug 28, 2014 at 12:40 PM, Frits Hoogland <frits.hoogland_at_gmail.com> wrote:
If you actually look at what is in SOX itself, you might be surprised. There is no implementation description.
In my experience the audit requirements which the auditor requests are most of the time based on the imagination of the auditor.
Hint: you might want to ask where the requested implementation is specifically detailed black on white.
Frits Hoogland
http://fritshoogland.wordpress.com
frits.hoogland_at_gmail.com
Office : +31 20 5939953 <tel:%2B31%2020%205939953>
Mobile: +31 6 14180860 <tel:%2B31%206%2014180860>
(Sent from my iPhone, typo's are expected)
> Op 28 aug. 2014 om 17:05 heeft David Barbour <david.barbour1_at_gmail.com>
het volgende geschreven:
>
> Morning,
>
> I was wondering how others might be handling the SOX reporting/auditing
issue we've been assigned.
>
> The audit folks want to know when DML occurs on a particular table and the
original and new value(s). I've implemented FGA on the table and can
capture the change. Using the transaction ID, I can then go back to the
flashback_transaction_query and get the original values. Of course, the
only guarantee of being able to pull the undo sql containing the original
values is that the query is performed before the undo retention expires.
Pre-supposing I have a job that queries dba_fga_audit_trail and grabs the
undo in time, what might happen next? I was thinking of storing the values
in a table created specifically for this purpose. Then I'd probably create
a view to generate the report.
>
> I'd appreciate any other ideas or refinements. This is a pretty busy
database and I've got to be careful bumping undo retention too high. I'm
undoubtedly missing something .............
-- http://www.freelists.org/webpage/oracle-lReceived on Thu Aug 28 2014 - 20:54:33 CEST