In this e-mail, there is some stuff I am not spelling out clearly for
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
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
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
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 security is by obscurity and trust that your users won't make serious
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
Today, BPCS can be run from green screen, a variety of GUI such as Internet
You need to have security that is sensitive to the nuances of all access
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
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/
This mailing list archive is Copyright 1997-2020 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