Re: Restrict ability to alter variables in debugger on production

As near as I can tell, SOX has many similarities to ISO-9000.  There
is virtually no telling you WHAT must be done.  Rather, the regulation
states that the organization must have policies, those policies must
pass the muster of external audit, and the organization must be able
to demonstrate compliance with those policies.

On Fri, 12 Nov 2004 06:56:39 -0000, Raby, Steve (GE Advanced
Materials, consultant) <steve.raby@xxxxxx> wrote:
> All the solutions then point out to the fact that there is no way anyone can 
> fix anything 
> in a live environment without impinging on SOX or data protection. That to me 
> is 
> an absolute nonsense, SOMEBODY has to be able to look at data, SOMEBODY 
> has to be able to fix data. 

I don't think that is the case; whoever is interpreting SOX for you is
making a grave error.  SOX does not care HOW data is changed, all it
cares about is a defined process, including approvals where necesary,
and an audit trail so that any changes are transparent.

For example, if Order Entry blows up, and some values on the order
need to be adjusted to process the order, this can be done.  However,
there has to be an approval process (perhaps signature of the IS and
Acct Managers), the before and after values need to be kept, and the
change information has to be filed somewhere.

There is no reason that an organization can't have policies for "IS
Staff Access to Production Data" and for "Manual adjustment of
production data", as long as those policies have approval mechanisms
and transparency.

> All this generating of test data as already pointed out may not be able to 
> recreate 
> the problem. The impression that I am getting from most of the replies here 
> is 
> that programmers cannot be trusted to look at data, or that they cannot be 
> given 
> the authorisation and sign some declaration of none disclosure. This is a 
> pretty 
> sad state of affairs in my humble opinion.  

I agree, although I don't take it as personally as you appear to be
taking it!  In my view "no production access" is a mis-interpretation
of the statute.  The issue is not who has access, but the mechanisms
for engaging such access, and the procedures for keeping track of when
the access is used.  Joe Pgmr can have access to production data, but
such access should require approvals to use, should be logged, and
changes made should be noted and filed.

> And as for copying data to a test environment taking a long time, well if 
> that is what 
> it take then that is what it takes, or use one of the "unauthorised" methods, 
> the 
> choices are limited! The solution below I think would be discounted straight 
> away 
> as it relies on someone bothering to put down what they did, not the system 
> recording what they did!

To all of you out there working in shops that are cracking down . . 
DO NOT GAME THE SYSTEM.  DO NOT CHEAT.  To do so would be to prove
that such system are necessary, and indeed to prove that you cannot be
trusted.  If you can't do the job because of restrictions imposed by
over-zealous SOX auditors, point it out, but work within the system. 
If you are directed to cheat, get it in writing.

-- 
Tom Jedrzejewicz
tomjedrz@xxxxxxxxx