Re: BPCS - Program Security

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