Re: Improving BPCS file security and ownership issues -- BPCS-L

Hello,

There is an enhancement BMR (not completed) for the authority issues in BPCS
to correct the product so that it ships as Clare has suggested in her note.
An additional BMR asks for security programs to be compiled as *OWNER (as
they are non-observable) so that it would be easier for users to switch to
using specific authority if they wish to.

History is that security in BPCS is unchanged from the days of green-screen,
when ODBC access via PCs was rare, and not an issue as far as anyone was
aware. When GUI came about in V6.x, and PCs were more common and access to
the AS/400 database via ODBC became easier and more of a security risk, the
product was still shipping with the same security model it had in the days
of green screen dumb terminals.

I suggest that if any companies are interested in the product shipping this
way (more security and also able to secure files from PC users this way),
please bring this BMR to the attention of your BPCS representative and/or
escalate the request to R&D through your account representative so that it
can get incorporated into a future release of the product. The BPCS files
and change of authority can not be re-delivered on the older releases, but
you can alternatively, request the second BMR listed below be completed on
the security programs so that *OWNER can be used on all of the BPCS
programs, adopting authority and allowing you to exclude all users from the
files unless they are inside the BPCS applications. This prevents PC users
from updating and/or viewing files on the AS/400 as well.

One caveat about running with BPCS objects using the *OWNER adopted
authority. There are a few GUI fat client programs in BPCS that use ODBC
access to refresh data to tables on the PC (read only). (On 6.1.00 very few
are left, only FRW download as far as I know and OLM frieght table refresh).
Even with programs compiled as *OWNER, and SSA owning the program, the ODBC
will not allow the users access to the data if PUBLIC is *EXCLUDE. Chances
are if you use FRW or there is a database refresh (this uses ODBC) then
those users will need at least *USE authority to the files (read-only, no
updates in BPCS are done via ODBC). This can be determined with a bit of
experimentation in a test environment, and affected users can be granted the
*USE authority to the files required. This is your most secure option for
BPCS and your data files, and will prevent updates from users via SQL and
other database utilities.

(It is my personal interest to see these BMRs implemented, as I wrote them
over 2 years ago - so if you are interested please let SSA know in an
official way!! :-)

BMR Number:  42833
Priority Code:  E
Version Reported: 6002
Platform Reported: AS400
Program:  SYS
Origin Code:  E
Completed Date: 00-00-00
Rejected Date:  00-00-00
Rejected Reason:

Improve File security in BPCS
Currently group profile of SSA owns all files in BPCS. This does not provide
enough security to prevent people from manipulating BPCS data files.
Currently the users only option to improve security is to set all the BPCS
files to PUBLIC *EXCLUDE so that users not enrolled in BPCS will not be able
to access the files.


Object Detail:

Object Platform Ver & Rel Stat Pri Completed
SYS        AS400      6002        A E 00-00-00
SYS        AS400      6004        A E 00-00-00
SYS        CLT        6002        WA E 00-00-00
SYS        CLT        6004        WA E 00-00-00
SYS        COLL       6002        WA E 00-00-00
SYS        COLL       6004        WA E 00-00-00
SYS        HPORA      6002        WA E 00-00-00
SYS        HPORA      6004        WA E 00-00-00
SYS        AS400      6100        A E 00-00-00
SYS        CLT        6100        A E 00-00-00
SYS        COLL       6100        A E 00-00-00
SYS        HPORA      6100        A E 00-00-00

Versions Affected/Corrected:  6002 6004 6100


BMR Number:  51582
Priority Code:  E
Version Reported: 6002
Platform Reported: AS400
Program:  SYS
Origin Code:  E
Completed Date: 00-00-00
Rejected Date:  00-00-00
Rejected Reason:

Compile secured source *OWNER
Due to AS/400 security and the fact that clients need to often have owners
other than SSA own all BPCS objects, in order to secure variousenvironments
from other users on the system, the BPCS secured source should be compiled
with User Profile *OWNER, rather than *USER. This will not affect any
persons with SSA owning all objects and SSA in theusers Group Profiles.
Programs affected for 6.0.02 would be: BPCSAPPC,BPCSAPPC, SYS650C, SYS652,
SYS653, SYS656, SYS656C, SYS656CB, SYS656CC, SYS656CD, SYS660, SYS660BC,
SYS660C, SYS660CVT, SYS662C, SYS664, SYS670, SYS671, SYS672, SYS673,
SYS673C, SYS674, SYS674C


Object Detail:

Object Platform Ver & Rel Stat Pri Completed
SYS        AS400      6100        U E 00-00-00

Versions Affected/Corrected:  6100

-----Original Message-----
From: Mack, Robert M. <Robert.M.Mack@sgcna.com>
To: 'BPCS-L@midrange.com' <BPCS-L@midrange.com>
Date: Tuesday, February 22, 2000 8:37 AM
Subject: RE: User profile SSA


Amen! This response gets gets framed with the caption "See it can be done!"
This solution can be applied to almost any AS/400 based vendor package.

There is only one other thing that I would add and that is since SSA (or
whatever group profile you specify)owns everything, then the PUBLIC
authority at the library level can be set to *EXCLUDE.  This way, anyone who
is not a member of the group and shouldn't have access just can't go
wandering through the  files.

Thanks again,
Bob Mack
Senior IT Auditor



+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---