Re: Security Questions -- MIDRANGE-L

See below.  --Paul E Musselman
PaulMmn@ix.netcom.nospam.com


>We are currently going through all of the users on our systems and removing
>any that have not been deleted for one reason or another. Through our
>looking, we have noticed people with authority that really didn't need it
>(like *SAVRST and *ALLOBJ). We are currently reviewing what people need for
>authority.
>
>1) What have you guys done to maintain security?

We've created a number of programs that run through our production
libraries and enforce our security plan.  And we actually run it
every now and then.

>
>2) How do you create new users? Do you have a "general" user which you copy
>from? Do you start from scratch?

We have a CRTUSR command that does the basic setup:  profile, jobq,
outq, directory entry, etc.  We have additional commands that enable
us to copy application authority from one user to another (even from
a user that's been terminated).  We examined many of our applications
to learn how they create internal authority, and built our copy
applications.

We have to be careful when users change jobs-- we tend to add
authority, and never remove it.  So, if a user moves around a lot,
they tend to be authorized to everything.  We do have the capability
to remove authority for an application, so we need to remove first,
then copy from a user in the new position.

>
>3) How do you eliminate the possibility of a user using the username for a
>password and not allow 'password' for a password?

We activated some of the PWD* system values to force numeral, etc.
etc.  Plus, we change passwords every 60 days, and prevent re-use of
32 passwords, which means even a poor password can't be re-used too
often!

Once problem we have is users who 'increment' their passwords:
SAUERKRAUT1, then SAUERKRAUT2, then SAUERKRAUT3, etc.  Because of the
politics, we can't tighten the rules as much as I'd like (ie prevent
same character in same position).

The problem is that we can make the rules too complicated, so users
can't pick a new password, can't remember it, and write it down and
tape it to the side of their screen

>
>4) How often do you review the users and security?

Less often than we should!   (:

>
>5) Payroll notifies us when people quit or have moved to a new position, but
>it doesn't tell us when remote users quit or have moved on. How do you
>handle this?

Every now and then we scream at everyone and INSIST that we be told
when -anyone-, =anywhere= leaves the company.  But people 'filter'
the responses to us-- "Oh, he never had any access; we don't have to
tell about -him-."

We also have customer locations which have access; they tend to share
profiles and passwords, and we never know when someone leaves.

We occasionally print a list of all users at a location, then mail it
to the location and have someone in their HR or management review the
list and tell us who's no longer there.

We have a TRMUSR command-- this diables the profile, rips it out of
OV/400, removes authority from applications (and archives the
authority to backup files in case we need to copy it to a new user).

We do have a routine that runs weekly that changes password to *NONE
and disables profiles that haven't been used in (PWDEXPITV + 30)
days.  This is an attempt to catch the profiles for people that
aren't really here.  Of course, this doesn't help if the profile has
been shared or stolen.


>
>Any suggestions would be appreciated.
>
>Mike Wills