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@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.