RE: DB2 Users

Al,

Thanks for a great summary of the subject!  You have confirmed some of
my suspicions.  As an aside, we are running 6.04 on v5r2m.  Our users
run green screen except for CEA.  I agree with your assessment of BPCS
security based on my observations.  We are fortunate to have some good
tools for analyzing the BPCS profiles at my disposal, my concern is much
more with the back doors, which are widely used here already.   Most of
our users have command line access now, but we have restricted it to a
few commands to allow them to display messages, work with their spool
files, etc.  As in your case, most users have the security necessary to
run query and issue ODBC queries against the database, but only a few
have the knowledge to use it.  We will look for some additional
education as you suggest.

Thanks again,

Jim Reinardy

-----Original Message-----
From: bpcs-l-bounces@xxxxxxxxxxxx [mailto:bpcs-l-bounces@xxxxxxxxxxxx]
On Behalf Of Alister Wm Macintyre
Sent: Wednesday, June 09, 2004 6:33 PM
To: SSA's BPCS ERP System
Subject: Re: DB2 Users

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/

_______________________________________________
This is the SSA's BPCS ERP System (BPCS-L) mailing list To post a
message email: BPCS-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change
list options,
visit: http://lists.midrange.com/mailman/listinfo/bpcs-l
or email: BPCS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/bpcs-l.