Re: Installing 3rd Party Software using QSECOFR??

knowledge is power... I just want to know whats going on in their install,
and then make my own risk assessment. Anyone who says "Trust Me"
is not to be trusted.
jim franz

To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Thursday, June 15, 2006 9:31 AM
Subject: Re: Installing 3rd Party Software using QSECOFR??

However, answering yes to any or all of those questions should not
disqualify the vendor.  Some may simply be required.  Perhaps a "Yes,
because..." answer may be desired.

Heck, I have to loosen up system values on one lpar just to put ptf's on
from IBM.  Like QALWOBJRST.  That machine is in our DMZ.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





"Jim Franz" <franz400@xxxxxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
06/15/2006 09:20 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
"Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
cc

Subject
Re: Installing 3rd Party Software using QSECOFR??

I suspect we're near the point where that will simply disqualify a

product

from consideration purely on some audit rules.

That is what it takes to wake up many vendors to actually commit an ounce
of
time to recode the install process. Often the vendors themselves don't
have
the security expertise inhouse.
For most products in the iSeries market - their roots are in the 80's and
90's. They may have rewritten much of the product and still not touch the
install.

From all the problems floated in this thread, we still lack a definitive

checklist of what to ask a vendor. It's real clear that just the profile
name to install with is not the whole problem.
I do not have a formal checklist, but my earlier post lists a handful of
questions or concerns, and that is where I usually start with:

Are they changing your system values?
Are they adding their own version of IBM code??
Are they using interfaces IBM did not intend or limits you running your
box
at sec lvl 50?
Are they altering configuration objects like job descriptions, classes,
device descriptions, etc (that other applications already use)?
Are they adding their own user profiles or altering existing profiles?
Are they adding a backdoor communication method? or any communication cfg?

Jim Franz

----- Original Message ----- From: <rob@xxxxxxxxx>

To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Thursday, June 15, 2006 8:30 AM
Subject: RE: Installing 3rd Party Software using QSECOFR??

But I'd argue that audit rules that forbid installation under QSECOFR

but

think it's ok to use any user profile with the following special
authorities:  *ALLOBJ *AUDIT *IOSYSCFG *JOBCTL *SAVSYS *SECADM *SERVICE
*SPLCTL; is simply doing "busy" work instead of "real" work.  Much like
the silly audit rule about limiting your users to one 5250 session when

no

rules are in place about accessing the data with multiple other tools,
like Excel, simultaneously from the same user.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





qsrvbas@xxxxxxxxxxxx
Sent by: midrange-l-bounces@xxxxxxxxxxxx
06/14/2006 11:08 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
midrange-l@xxxxxxxxxxxx
cc

Subject
RE: Installing 3rd Party Software using QSECOFR??






midrange-l-request@xxxxxxxxxxxx wrote:

  5. RE: Installing 3rd Party Software using QSECOFR?? (QSCANFSCTL)

qsrvbas@xxxxxxxxxxxx wrote:

The _only_ company that should be asking you to install (or even sign

on) with QSECOFR is IBM.

<snip>

A flat QSECOFR requirement makes me wonder if the product itself was

written with a solid understanding of OS/400.

It's more likely the instructions were overly simplified to say QSECOFR
which any System i/i5/iSeries/AS400 administrator should understand.

There are many shops out there with a minimal knowledge of i5OS/OS400.
Just saying QSECOFR minimizes mistakes.

Oh, I don't doubt that and that's a fairly good point.

But OTOH, it's trivial to call the Check User Special Authorities
(QSYCUSRS) API with, for example, '*ALLOBJ   *SECADM   *IOSYSCFG' as the
primary input parm and check the indicator that's returned. If the
indicator comes back as 'N', you send a message that says "You need
*ALLOBJ *SECADM and *IOSYSCFG to install" and exit. The API allows the
authorities to come from group authorities and elsewhere; it simply

checks

whether the authorities are available to the job.

That's not a lot more difficult than testing if the user is QSECOFR and,
if it isn't, sending a message saying "You need to be QSECOFR to

install"

and then exiting.

If necessary, the first message might add "...You can install as QSECOFR
for those authorities.".

But _requiring_ QSECOFR? That's an odd step beyond _allowing_ a QSECOFR
install or even suggesting one. I suspect we're near the point where

that

will simply disqualify a product from consideration purely on some audit
rules. There simply is no need for it and hasn't been a need for quite a
few years.

Tom Liotta

--
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788 x313
Fax    253-872-7904
http://www.powertech.com


__________________________________________________________________
Switch to Netscape Internet Service.
As low as $9.95 a month -- Sign up today at
http://isp.netscape.com/register

Netscape. Just the Net You Need.

New! Netscape Toolbar for Internet Explorer
Search from anywhere on the Web and block those annoying pop-ups.
Download now at http://channels.netscape.com/ns/search/install.jsp
--
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.


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

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


--

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.