RE: Restrict ability to alter variables in debugger on production -- MIDRANGE-L

Walden

This is from a company where developers (not sure how many) could do debugging over liver production data. A problem could be fixed in a couple minutes. Now it takes a couple hours, in their words, to get all the approval, etc., since SOX entered the picture. This is second hand to me - another person at work asked me about this.

I remember at a previous employer having a mechanism that involved the help desk. A developer would call to get his/her name added to an authorization list for a command (program?) that let them CALL QCMD with *ALLOBJ or whatever. At the same time, security auditing was set up to log all activity by the user profile of the developer. When they left QCMD, they had none of this special authorization. The job log was kept, and the security audit entries were retrieved, as I recall. Without this, developers had no authority to anything that did not happen as a regular user. This assumed some kind of menu-level authority.

Memory is wearing out, but that's the general idea. Of course, clients like FTP and ODBC would need to be considered, but this mechanism seems as if it should handle those, since the person had to call this program specifically. Maybe modifying the profile's initial program is another way to implement this.

Regards
Vern

At 09:32 AM 11/11/2004, you wrote:

>This will prevent them from
>changing production data.

Changing production data isn't the only problem, it's changing values in
a running program. Take the example of a check run. You read the correct
name and payment from the database, but right before the write to the
print file you change the value of the name to "Walden" and the value to
"$1,000,000" and then after the print you change it back. This won't be
caught anywhere.

Vern, who is asking this question though. Is it coming from an actual
auditor or from someone preparing for the audit? The PCAOB seems to be
allowing a degree of "reasonableness" to be applied by the auditing
firms. Remember, you need to control, not prevent, access. Perhaps
something like a second set of eyes when debugging production programs
would be acceptable -- that is, when debugging production programs a
second programmer (or perhaps a manager, or someone from accounting, or
someone designated by the audit committee) must be present when the
debugger is running.

-Walden


------------
Walden H Leverich III
President & CEO
Tech Software
(516) 627-3800 x11
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com

Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.