Re: User trans track BPCS v4 - Security concerns

>  From Al Macintyre 405 CD with 4 facilities sharing one production 
environment on AS/436 V4R3 at http://www.cen-elec.com 

BPCS V4 security can be very effective provided someone is managing it who 
knows how it works & has good communication through the company regarding who 
all ought to be able to update what & who decides ... we have departments 
that are serious about security access to THEIR stuff ... we have departments 
that could care less about security - other issues are far more important.

We get a lot of new hires in which the request is "give this new person 100% 
of the same access as that pre-existing user has" ... now did that new person 
get comparable training?

I get a lot of requests in which I am told "this person needs access to that 
BPCS program to do their job right ... please adjust their security"  Ok, I 
have an arrangement with my boss ... I fulfil these requests, but I also 
notify both my boss, and the person in charge of that application that there 
has been an addition to their staff, just in case there is a problem with 
this.  Sometimes there is an explosion & the access approval is reversed.  
99% of the time my notification is met with not even a murmer.

I am the Chief Security Officer - only my boss & I are supposed to know the 
Master IBM Security passwords - MANY more people knew this stuff when we had 
consultants helping us, but I have been closing the doors they left open.   
We have an arrangement wherebye business partners can dial into our AS/400 on 
the ECS line, but I also have a hardware switch to disconnect that ability 
unless they have called in advance of a session to clear it with us.

I have a few power users who help with BPCS security & adjusting what is on 
what menus.  For 75% of our users, if they accidentally F3 out of BPCS to 
OS/400 menu, IBM security kicks in with *SIGNOFF instead.

>  BPCS V4 security has some holes.  

To this, we have added some holes of our own unique flavor.

The vast majority of our users have command line authority, which means that 
under how BPCS group security functions, IBM security will let them do 
ANYTHING to any record of any file of BPCS without leaving an audit trail.  
Although I have noticed several incidents of a nature that undermines the 
integrity of the BPCS data base, our corporate interest is more in the 
productivity of the total work force than the risks from a security nature.

Reports are generated by individuals within departments in which other 
individuals in the same departments need to access those reports.  This has 
led to us giving spool file authority to 100% of our users.  Occasionally 
someone deletes someone else's report by accident, but we see no problem with 
this, so long as everyone understands THERE IS NO SUCH THING AS A 
CONFIDENTIAL REPORT & any time you transfer data that is protected by 
security to a screen print or report form, the odds are that some other user 
might look at it.

As MIS Manager, I am periodically deleting reports from spool that are like 2 
weeks old, having consulted with the users involved ... do yuu need ORD500 
audit trails kept for how long ... etc. & various people ask me to leave 
stuff alone for a while, such as the CFO's reports from EOM sitting on one 
spool queue ... now think about this for a moment - if there are any reports 
that are seriously confidential, there they are all in one place, for any 
user to look at.

>  We are a multi-faciilty company in which
>  some users are authorized to do a wide range of transactions at the 
facility
>  at which they are based, and are authorized to LOOK at data in other
>  facilities but not update anything there.  We have not figured out how to
>  enforce that, but we can query on the user-id within inventory history ...
>  running a total only number of transactions by user by facility each month,
>  to catch any no-nos, after the fact. 

>  From:    Lisa.Abney@universalflavors.com

>  Al ... We have a very similar setup ... 4.0.5 (nonCD), with 9 manufacturing
>  facilities across the country, all operating out of the same environment.  
>  We use a warehouse name the same as the facility name for our "primary" 
>  warehouse at each facility.  
>  As we can set security at the warehouse level, and because
>  most "stuff" happens at the warehouse level, we think we are secure against
>  users at one facility changing data at another facility.  

We have factories in 3 cities.  one of the factories is host to 2 facilities.
We use a consistent number system --- the first character of the facility & 
all warehouses in that facility consistently "say" where it is --- the second 
character is the type of warehouse --- raw materials, finished, 
work-in-process, QC problem.

We are more concerned with human error than with risk of fraud.

We have several different kinds of users who are authorized to do 
transactions into warehouses.  

There are the people who work ONLY in their facility & have no involvement 
with the other facilities ... no problems there, until their job function is 
promoted & sometimes the training in their new responsibilities is a bit 
weak, regarding the new risks of the new position.  If in fact all your 
people are like this scenario, and you have not imitated the Central system 
of digging lots of security holes, then you are probably fairly safe.

There are the people who are authorized to work with data in ALL facilities & 
generally have had the training & experience to know what they are doing ... 
occasionally I get a call from one of these people ... OOPS ... I was doing 
transactions for this facility & by accident I was in that other facility & 
was oblivious to the fact that I was in the wrong one ... in this case the 
user normally has the experience to recognize that they made a mistake, knows 
how to check the audit trails, knows how to back out the error entries & only 
needs my help if it can';t be backed out because of some other activity that 
interferes.

The big problem we have had is with people who are authorized to work with 
data in THEIR facility & LOOK at data in other facilities, because we have 
some common sub-components & we are a job-shop make-to-order with short lead 
times.  So some customer wants something pulled up, and the factory involved 
does not have enough raw materials ... do we authorize high expense rush 
delivery what we need, or does another factory have some safety stock that 
can be dipped into?

We have tried to address this with remembered keys stickiness.  The filters 
default to that site's home facility --- key in some other facility, get the 
info, then it reverts to the home facility --- need a lot of lookups & this 
is a nuisance, so they adjust the remembered keys & forget to reset them, 
then later forget they are in the wrong facility.

>  Your comments about the V4 security makes me wonder ... 
>  where do you see the holes?

I have to be careful in describing problem areas so that I do not extend an 
invitation to trouble makers to drive heavy fraud through companies who are 
not seeing this or protecting against it.

Al Macintyre
Central Industries of Indiana Inc.
+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---