Re: DB2 Users -- BPCS-L

In this e-mail, there is some stuff I am not spelling out clearly for security reasons. I am trying to give a summary big picture here. Later we can address some of these sub-topics in more detail.

There are a bunch of reccommendations out of IBM and other places for what you need to do on your iSeries to have good security with respect to satisfying government regulations like Sarbanes Oxley and good internal controls. Unfortunately BPCS Security design is one of many popular packages that are rather skew to those objectives, and many companies want their users to have easy access to cheap software like Query/400 and Excel, and other things whose designs run contrary to notions of good security, good system performance, and good internal controls. Some outfits tech support also runs skew to these issues ... for example a tech support place once walked one of our non-technical managers step by step how to update DB2 using SQL, because this was the most expedient solution for the tech support person.

iSeries security is not simple - there are many layers of complexity. You need to take many days of IBM intensive classes to appreciate it all, and they will in essence tell you to do stuff to fix your 400 security that will break BPCS ... education is needed that goes outside of what IBM offers, so as to understand how to fix your security without breaking BPCS. Such classes are available from several vendors.

There is some BPCS software that we do not use because according to SSA tech support, for it to work right, we have to make SSA a 400 security officer then sign on as SSA. Well I not want to use that stuff enough to off-set the down sides of making everyone a 400 security officer.

Everything we do to the SSA group profile affects all the members of the group ... all your BPCS users.

DB2 also has many layers ... for example we can have trigger programs that fire off when someone changes some piece of info. Exploring this stuff is like very advanced programming. It may be that your people did not consciously insert any such software into your system, but any time you aquire 3rd party software, and not fully understand what it is doing under the covers, it might be doing stuff that is not in best interests of your security, performance, internal controls.

You do not have to have people that understand every possible risk and how to search for it. You can get 3rd party software that will inspect your 400 and identify all your risks.

BPCS security has been re-written for various BPCS versions, so what is a rule of thumb for one version is not neccessarily valid for another. Similarly OS/400 had security enhancements, and a lot has to do with your 400 system value settings, not just those related to security. For example, there is a value that under IBM rules has nothing to do with security, that if set inappropriately, means that you have no security against hackers.

BPCS security is not simple to understand or to manage. You can buy add-on 3rd party software to enhance your access to BPCS security so that it becomes simple to manage, and understandable to non-technical people such as auditors.

BPCS documentation has several holes, and is not well organized ... you can become an expert on everything that is supplied by SSA and you won't know everything you need to know to manage BPCS security properly. With respect to Sarbanes Oxley, perhaps you want to know about bugs in BPCS software that corrupt your data. You are not going to find out about these bugs in the official BPCS documentation. There is some great 3rd party documentation, but that is another place where you unlikely to get an education in the BPCS bugs that can corrupt your data.

If a user can access BPCS via Client Access and if you follow the standard instructions from SSA about how to secure your BPCS your security is by obscurity and trust that your users won't make serious mistakes because much of BPCS security is based on the assumption that the users access is via green screen in which they can only run software through the menus.

Today, BPCS can be run from green screen, a variety of GUI such as Internet Browsers. You need to have security that is sensitive to the nuances of all access methods.

We are on BPCS V405CD on OS/400 V5R1. We habitually use DFU and SQL to go in the "back door" in Wargames the movie sense, to change BPCS data without any GAAP audit trails.

Most of our users have security access far in excess of what they are actually using. In hopes of weaning future users off of dependency upon stuff that is a poor security, poor internal controls reality, I have added many things to many menus ... for example my users can access a directory of all our files and all our software and run any program (if their BPCS security allows it) and do RUNQTY *N against any BPCS file from a menu option.

Most of our users have command line access. Most of our users have ESCAPE key access. Most of our users have UPPER SHIFT ESCAPE key access Any of our users who have access to reports have access to everyone's reports. A few of our users are able to get BPCS data and reports into Excel or e-mail or other PC applications ... when I say a few ... MANY have security that allows them to do this, only a few are sufficiently motivated to actually figure it out.

A hot topic recently for us has been stuff getting posted (attempted) to General Ledger fiscal periods that we are done with. I am beginning to suspect another BPCS bug because BPCS is not supposed to let people post stuff to fiscal periods that are closed. At some point I may need to Journal or Log the GJW file to back trace how this is happening because we do not have the budget to buy quality audit add ons.

-
Al Macintyre  http://www.ryze.com/go/Al9Mac
BPCS/400 Computer Janitor at http://www.globalwiretechnologies.com/