RE: SOX Reporting Requirement
- From: "Dimensional DBA" <dimensional.dba@xxxxxxxxxxx>
- To: <david.barbour1@xxxxxxxxx>, "'Frits Hoogland'" <frits.hoogland@xxxxxxxxx>
- Date: Thu, 28 Aug 2014 11:54:33 -0700
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@xxxxxxxxxxx
<http://www.linkedin.com/pub/matthew-parker/6/51b/944/> View Matthew
Parker's profile on LinkedIn
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
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@xxxxxxxxx>
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@xxxxxxxxx
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@xxxxxxxxx>
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 .............
Other related posts:
