User authority controls --- employees changing jobs -- MIDRANGE-L


This has been an intriguing discussion thread. In my view, a 
"moving employee" generates two categories of system access 
concerns: Risk A and Risk B  ---->


  A. Risk that the transferred employee is disabled in the new role until 
       the proper system authorities are granted.

      This is not so serious because it should come to QSECOFR attention
      all by itself when the employee's new supervisor complains
      about an impossible tangle of system access hang-ups.


  B. Risk that authority to objects used in the prior job is not
       promptly terminated.

      Presuming that the new supervisor complains that his/her new
      employee can't do anything productive in his/her new job, then the
      urgent demand to fix Risk A should be all the alert QSECOFR would
      need to trigger the Risk B fix.


Now ..... if the "should work all by itself" fix to Risk A does  NOT  happen
all by itself, the implication is that something about the individual's 
authorities in the prior position were too broad  .....  and/or ........
something about the overall security of OS/400 requires a             
very sophisticated analysis.

Here's a very instructive presentation of OS/400 vulnerabilities ranked in
order of how many understandable English words are needed to explain them:
http://www.unbeatenpathintl.com/BOH-Benefits/source/1.html

Here's an idea for an affordable "fine-tooth-comb" analysis of every
conceivable OS/400 security vulnerability: Bill of Health (R)
 http://www.upisox.com/bill.html
The product provides robust information about every discovered risk and
detailed guidance about how to go about removing each one.


Warmest regards,
Milt Habeck
mhabeck@xxxxxxxxxx
North America: (888) 874-8008
International: (262) 681-3151





________________________________

From: Mike Cunningham
To:  midrange-l@xxxxxxxxxxxx
Sent: Friday, March 16, 2007 2:10 PM
Subject: RE: User authority controls


This sounds like exactly what we are doing, trying to figure out what HR is 
doing. We give ourselves notice of a title change but right now our network 
admins don't do anything with it because they say they don't know what to 
do. From a title change they can't tell if the person actually changed jobs 
or not. When you say you "take appropriate action" is that calling someone 
to find out what happened and then making whatever changes are necessary?

p.s. In order to be sure that SSMITH is  Sally Smith and not Sam Smithfield, 
We created a cross reference table that mapped userid to an employee number 
so we don't have to guess what two go together. We scan all userids weekly 
and look at the linked HR records and see if the person is still employed 
just as a double check of the e-mail notifications our HR office sends out. 
We also do the opposite and scan HR files and look for active employees who 
don't have accounts (in our standards all employees get an account) and 
report those as problems also. Sometimes (rarely but it happens) the HR 
notification of a new hire does not come out until after someone has been at 
work for a week or more. We are also scanning Active Directory LDAP accounts 
to match them up to iSeries userids (standard is both userids will be the 
same) and HR files and tell our network admins what accounts they should 
disable/delete.

________________________________

From: midrange-l-bounces@xxxxxxxxxxxx on behalf of Roger Harman
Sent: Fri 3/16/2007 2:14 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: User authority controls

When I started here, they used the concept of naming a user profile by
the job type.  I converted to using names a few years ago and everyone
has loved it.  Besides matching the network & email naming, it just
makes life easier.   Can you remember who RMBY11 (Retail Merchandise
Buyer #11) is?  I can't, but I can easily know who SSMITH is.

As to job changes....  we run a SQL report over the HR transaction
database nightly.  We look for job code changes and cost center changes
and match the name to user profiles.  If we get a hit, we take
appropriate action.  The job change may have no effect on their access
or we may disable the profile if they've moved, say, from Merchandise to
Foods - particularly important for Time & Attendance access.

BTW... we also run a daily termination list and match it to user
profiles (iSeries and network) and disable those.

We review both manually since there is a good possibility of false
positives - SSMITH user profile may be Sally Smith but it was Sam Smith
who left the company.  I hope to improve the process by adding a
notation for computer access to the HR record to eliminate the false
positives - track it like we do special licenses, company issued
property, etc.


________________________________

mcunning@xxxxxxx 03/16/2007 8:30:15 AM >>>

We have a good handle on authority setup for new employees and on
removing authority for  employees who are leaving. What we struggle with
are those employees who change jobs within the college. Sometimes those
are people leaving one department and going to another, sometimes those
are people just getting a title change. Our HR office is very good at
telling us who new hires are and who is leaving but not so good at jobs
changers. I am curious to know how you handle these people from an
authority control perspective. One idea we had was to look for any title
changes and treat them as if they left the college and are coming back
in as a new employee. Disable their account and revoke all authority
then grant just the base level of authority to the new job until we hear
from that persons new supervisor. Of course this then requires going
into all the systems where mcunning has an account and disabling it.
Another thought was to stop creating accounts based on someone's name
but use their position instead. So my userid would not be MCUNNING but
ITSDIR. ITSDIR is granted authority not MCUNNING. When MCUNNING changes
jobs the ITSDIR account would be disabled and my new job account would
be enabled. When the new ITSDIR comes on board we reactivate that
account. We use to use this method a long time ago but our users
revolted because it is sometimes very hard to turn a title into 10
characters and have it make sense. Try coming up with 10 characters for
Director or Desktop  Computing/Academic Computing/Media Services.