Re: STRSRVJOB and database journal entries

Charles,

> As other have said, the problem is programmers having
> authority to debug production jobs live in the first 
> place.

No need to single out programmers.  The problem could occur any time any
user had *SERVICE authority on a production system.

While it would be nice (and logical) to have an audit trail anytime Job
A interfered with Job B, the situation also argues for limiting access
to *SERVICE special authority, and auditing any user who carries that
special authority.

Too many audit entries you say?  Do any of you carry *SERVICE in your
day-to-day profile?  I wonder why?  I wonder how many times in a regular
week you are required to do *SERVICE types of functions.  If the answer
is (as I suspect) less than once a week, than maybe you ought to tuck
that one away and save it for a rainy day.

JMHO.

jte

--
John Earl | Chief Technology Officer
The PowerTech Group
19426 68th Ave. S
Seattle, WA 98032
(253) 872-7788 ext. 302
john.earl-Ua2wos9bJ7y1Z/[email protected]
www.powertech.com 
Celebrating our 10th Anniversary Year!
 

 
This email message and any attachments are intended only for the use of
the intended recipients and may contain information that is privileged
and confidential. If you are not the intended recipient, any
dissemination, distribution, or copying is strictly prohibited. If you
received this email message in error, please immediately notify the
sender by replying to this email message, or by telephone, and delete
the message from your email system.
--

> -----Original Message-----
> From: security400-bounces-Zwy7GipZuJhWk0Htik3J/[email protected]
> [mailto:security400-bounces-Zwy7GipZuJhWk0Htik3J/[email protected]] On Behalf Of
> Wilt, Charles
> Sent: Thursday, June 29, 2006 12:10 PM
> To: Security Administration on the AS400 / iSeries
> Subject: Re: [Security400] STRSRVJOB and database journal
> entries
> 
> I think the point is that the journal records the fact
> that user BOB
> made the change to the file, but that the reality is that
> programmer
> MARY was responsible for the value being what it was.
> 
> As other have said, the problem is programmers having
> authority to debug
> production jobs live in the first place.
> 
> I've never heard of any auditors who don't recommend
> preventing
> programmers from having such access to the production box.
> You if chose
> to allow such access then you are choosing to allow such
> access.
> 
> Having said that, I suppose a case could be made that
> MARY's changing of
> a variable using debug ought to be able to be logged
> somewhere if it
> isn't already.  But I don't think the log entry should
> show in BOB's job
> or the file journal.  Instead, the audit journal would be
> a good place
> for the info to be logged or even MARY's job log.
> 
> 
> 
> Charles Wilt
> --
> iSeries Systems Administrator / Developer
> Mitsubishi Electric Automotive America
> ph: 513-573-4343
> fax: 513-398-1121
> 
> 
> > -----Original Message-----
> > From: security400-bounces-Zwy7GipZuJhWk0Htik3J/[email protected]
> > [mailto:security400-bounces-Zwy7GipZuJhWk0Htik3J/[email protected]] On Behalf Of
> Bob Crothers
> > Sent: Thursday, June 29, 2006 1:40 PM
> > To: 'Security Administration on the AS400 / iSeries'
> > Subject: Re: [Security400] STRSRVJOB and database
> journal entries
> >
> > But in the case below, isn't the Journal accurate?
> >
> > Program reads in database record.  Pgm changes data,
> hits
> > break point before
> > the update is issued.  Person uses CHGPGMVAR to change
> one of
> > the fields and
> > then resumes execution.  Record update is done.  Journal
> > accurately shoes
> > what the data was when the record was
> written/updated...AFTER
> > the chgpgmvar!
> >
> > Not seeing the problem.
> >
> > Bob
> >
> > > -----Original Message-----
> > > From: security400-bounces-Zwy7GipZuJhWk0Htik3J/[email protected]
> [mailto:security400-
> > > bounces-Zwy7GipZuJhWk0Htik3J/[email protected]] On Behalf Of
> mlazarus-sSJ1ceXosh9vBvnq28/[email protected]
> > > Sent: Wednesday, June 28, 2006 12:51 PM
> > > To: security400-Zwy7GipZuJhWk0Htik3J/[email protected]
> > > Subject: Re: [Security400] STRSRVJOB and database
> journal entries
> > >
> > >  You are also required to have at least *USE authority
> to
> > the target job's
> > > *USRPRF.  So, if the system in question has a gaping
> security hole
> > > (allowing the user to debug the job in the first
> place), I
> > wouldn't expect
> > > IBM to log all changes to the journal, especially
> since
> > those changes were
> > > to memory, not yet in the database.
> > >
> > >  -mark
> > >
> > > Original Message:
> > > -----------------
> > > From: Hall, Philip [email protected]
> > > Date: Wed, 28 Jun 2006 11:31:15 -0500
> > > To: security400-Zwy7GipZuJhWk0Htik3J/[email protected]
> > > Subject: Re: [Security400] STRSRVJOB and database
> journal entries
> > >
> > >
> > > > I started a debug session for another job, using
> > chgpgmvar I changed a
> > > > program variable that was due to be written to a
> database
> > file and then
> > > I
> > > > looked at the journal.
> > > > There was no trace of the fact that the job that
> wrote
> > the modified
> > > value
> > > > was interrupted in any way.
> > > > This looks like a problem, doesn't it?
> > >
> > > Only if you put debug versions of your objects into
> production.
> > >
> > >
> > > ------------------------------------------------------
> --------------
> > > mail2web - Check your email from the web at
> > > http://mail2web.com/ .
> > >
> > >
> > >
> > > _______________________________________________
> > > This is the Security Administration on the AS400 /
> iSeries
> > (Security400)
> > > mailing list
> > > To post a message email: Security400-Zwy7GipZuJhWk0Htik3J/[email protected]
> > > To subscribe, unsubscribe, or change list options,
> > > visit:
> http://lists.midrange.com/mailman/listinfo/security400
> > > or email: Security400-request-Zwy7GipZuJhWk0Htik3J/[email protected]
> > > Before posting, please take a moment to review the
> archives
> > > at http://archive.midrange.com/security400.
> >
> >
> > _______________________________________________
> > This is the Security Administration on the AS400 /
> iSeries
> > (Security400) mailing list
> > To post a message email: Security400-Zwy7GipZuJhWk0Htik3J/[email protected]
> > To subscribe, unsubscribe, or change list options,
> > visit:
> http://lists.midrange.com/mailman/listinfo/security400
> > or email: Security400-request-Zwy7GipZuJhWk0Htik3J/[email protected]
> > Before posting, please take a moment to review the
> archives
> > at http://archive.midrange.com/security400.
> >
> >
> 
> _______________________________________________
> This is the Security Administration on the AS400 / iSeries
> (Security400) mailing list
> To post a message email: Security400-Zwy7GipZuJhWk0Htik3J/[email protected]
> To subscribe, unsubscribe, or change list options,
> visit:
> http://lists.midrange.com/mailman/listinfo/security400
> or email: Security400-request-Zwy7GipZuJhWk0Htik3J/[email protected]
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/security400.
> 


_______________________________________________
This is the Security Administration on the AS400 / iSeries (Security400) mailing list
To post a message email: Security400-Zwy7GipZuJhWk0Htik3J/[email protected]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/security400
or email: Security400-request-Zwy7GipZuJhWk0Htik3J/[email protected]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/security400.