RE: DB2 Users -- BPCS-L

Jim, 

Please note, SSA Chicago HAS DOCUMENTATION which gives you valuable
information in order for you to plug many of the problems mentioned on
your previous eMails.  There is hope, but it requires some work !!! In
any nutsell, you can configure the BPCS security in two ways: 

1. By using the group profile security of the AS/400 and the SSA user
profile.  This may be the "recommendation" from SSA, but this IS NOT the
best solution. Simply put, it does not do too good of a job  Consider
this, it DOES NOT matter if a given user at the AS/400 security level
has or does not have access to the command line.  Once they are inside
of the BPCS environment, the SSA group profiles takes precedence. From
there, they get access to the command line and can perform any command
BPCS (the application) would perform doing its regular job.  Yes, that
is creating files, updating files, deleting files, etc.

2. The second option is a better choice.  I do not have the actual
document from SSA Chicago in front of me, but in summary you want to do
the following. Again, this is a high level summary, do get the document
from SSA which goes through quite a bit more details before implementing
something like this.
   a. Ensure all objects in the BPCS environment are in fact owned by
the user profile SSA
   b. Grant *ALL object authority to user SSA
   c. Grant *USE object authority to user *PUBLIC.  This will allow
users to query the data ONLY with various tools

Up until this point, there is no major change as far as your user
community is concerned. Why ? because their AS/400 user profile is still
part of the SSA group profile.  The next step will actually close the
backdoor access to modifying or deleting data or files completely...
   D. Remove the SSA group profile from all AS/400 user profiles.

BPCS will not break because users will be running the BPCS program which
are owned by the SSA profile and the file themselves do have specified
SSA group profile with all object authority.  This will also prevent any
other As/400 programs (again, not owned by the SSA profile) from
modifying or deleting BPCS data.

Other things that you should consider to improve security on your system
are:
1. ODBC direct access to the BPCS files. Not allowed unless you have
PC-based applications accessing BPCS data.  In event in that situation,
I would recommend granting access on a file-by-file basis.
2. FTP access from the AS/400 and up to the AS/400.
3. Unrestricted access to production environment by the IT programmers.
4. There are certain AS/400 command which should be for the exclusive
use of the security administrator and maybe his/her backup.  Yes, when
you count these individuals in your organization you ought to be able to
count them with the fingers of one of your hands and when you are done,
you should have at least 3 fingers left.  These commands you should
secure with some sort of as/400 authorization list where *PUBLIC user
has *EXCLUDE and specific user ids are granted access to these.

I hope this helps.

_____________________________________
Jose J. Torres - MS, PMP, CISA
IS Project Manager 
Phelps Dodge International Corporation


-----Original Message-----
From: bpcs-l-bounces@xxxxxxxxxxxx [mailto:bpcs-l-bounces@xxxxxxxxxxxx]
On Behalf Of Reinardy, James
Sent: Thursday, June 10, 2004 9:36 AM
To: SSA's BPCS ERP System
Subject: 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.



_______________________________________________
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.