Re: Programmer DFU access

Dan,

"Bale, Dan" wrote:

> Johnny,
>
> The auditors are going to have an issue with *ANY* tool used to change
> production data that isn't part of the normal application system.  Doesn't
> matter if it's DFU, DBU, WRKDBF, or a programmer's quick-fix, one-time-only
> program.  If something outside the normal application system makes changes
> to the data, the auditors want a record of it - the who, what, & why.
>
> Just finished up at a client a few months ago where they had this same issue
> with programmers changing production data using DBU.  They wrote a front-end
> to DBU that required the user/programmer to enter their name, the name of
> the person requesting the change, and the reason for the change.  DBU audit
> was turned on, the spool file was saved to a data file that was tied to the
> record entered on the DBU front end.  Don't know if this satisfied the
> auditors or not.

I put together something similar once, and discovered a big problem with it.  
The
spool file can always be manipulated/changed/deleted by the person who reated it
(even if it's in an outq they have *EXCLUDE authority to :(  ).

Our solution was to have an automatic SNDNETSPLF ship the spool file to another
system, into an outq that was *PUBLIC *EXCLUDE.  The new spool file ended up
being owned by  the owner of the SNDNETSPLF job, so it was slightly more secure.

jte


--
John Earl                               johnearl@400security.com
The PowerTech Group                     206-575-0711
PowerLock Network Security              www.400security.com
--


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---