Re: BPCS - Program Security (shalom@xxxxxxxxxx) -- BPCS-L

Hello, 

Hello Shalom, 

I am not sure what release of BPCS you last managed as you didn't
mention it in your note, nor if you have been following the many
discussions on BPCS-L for these security related issues over the past
few years? If you check the archives there are much more detailed
discussions that can explain the below even further.

At any rate the situation you describe has certainly changed for clients
who are on support or remained current on BPCS releases. 

Problem A can be resolved in any currently supported release of BPCS
(BPCS CD - V6.1) by implementing BMR 51582 (or equivalent BMR, depending
on BPCS release) and is delivered in base release of V8.x releases by
following the installation instructions Appendix regarding implementing
increased security. This uses *OWNER adopted authority and iSeries
object security to ensure the user doesn't have that authority to CALL a
program or use files they are not authorized to and alters the command
line and ATTN key programs to ensure the user operates under his own
authority when at the command line.

Problem B is in fact resolved in V6.1 and higher releases, regardless of
the user's authority to the object. It can be easily resolved in other
releases if you have the source for that program, by adding a call to
SYS610B to check the user's authority to run SYS600D before launching
the first screen.

Problem C same resolution as problem A and since BPCS data files are
part of the iSeries database, the iSeries security is what must be used
to lock it down when access is attempted from outside the BPCS product
as you describe.

Problem D same resolution as problem A, same issue as issue C.

Problem E can be resolved by journaling as stated or using products
designed for high availability such as Mimix.

Thanks,

Genyphyr Novak
Senior System Software Engineer
SSA Global R&D

-----Original Message-----

date: 17 Apr 2005 13:31:07 -0000
from: shalom@xxxxxxxxxx
subject: [BPCS-L] 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