Daniel,
I would like to point out several problems with BPCS security. 
As I have not managed a BPCS environment during the last 4 years, 
maybe some problems were resolved in the new versions, although I doubt it.

a. A user that has command line can activate any program by CALLing directly. 
   For example, you can block ACP100 (vendor maintenance) in BPCS security, 
   but a user can simply CALL ACP100C from a command line. 

b. A user that has command line can CALL SYS600C and modify 
   the BPCS security definitions.

c. A user that has FTP, or ODBC, or File transfer access, 
   can retrieve and modify BPCS files at will. 
   BPCS does not manage separate system level object authorities 
   for sensitive files.

d. In particular, A user that has FTP, or ODBC, or File transfer access,
   can modify the BPCS security files, 
   granting unplanned application authorities.

e. BPCS does not use commitment control and has 
   no vendor defined journaling policy. This affects both your 
   security if you chose to implement journaling on your own, 
   and your disaster recovery plans.

Fortunately, the solutions are not very complicated:

Step 1
Remove command line access from users who do not need it.

Step 2
Fully audit the powerful users who have command line 

Step 3
Change the default object authority to modify the sensitive files, 
and allow data modification only to those who need it.
This will not work for files like IIM!!

Step 4
To protect files like IIM either create a database journal and audit it 
for unapproved changes, or add auditing database triggers.

Step 5
If FTP, or ODBC, or file transfer are used on your AS/400, 
buy a commercial security product to manage authorization to these services.

Step 6
If you are concerned with disaster recovery, define database journaling 
for all of the BPCS files. The performance penalty is negligible, 
but storage must be managed carefully.


Shalom Carmel
www.venera.com - exposing AS/400 insecurity

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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

This mailing list archive is Copyright 1997-2022 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.