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@xxxxxxxxxxxxx
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@xxxxxxxxxxxx
[mailto:security400-bounces@xxxxxxxxxxxx] 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@xxxxxxxxxxxx
[mailto:security400-bounces@xxxxxxxxxxxx] 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@xxxxxxxxxxxx
[mailto:security400-
bounces@xxxxxxxxxxxx] On Behalf Of
mlazarus@xxxxxxxxxxxxx
Sent: Wednesday, June 28, 2006 12:51 PM
To: security400@xxxxxxxxxxxx
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 phall@xxxxxxxx
Date: Wed, 28 Jun 2006 11:31:15 -0500
To: security400@xxxxxxxxxxxx
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@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/security400
or email: Security400-request@xxxxxxxxxxxx
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@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/security400
or email: Security400-request@xxxxxxxxxxxx
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@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/security400
or email: Security400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the
archives
at http://archive.midrange.com/security400.




As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2021 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.