RE: Security400 digest, Vol 1 #83 - 2 msgs

1 - What has been done to maintain security?
Answer: I write out all of my users to an outfile and then query the
outfile. This can be done as follows:
Dspusrprf usrprf(*all) output(*outfile) outfile(*lib/*filename). Library and
file name of your choosing.
Note: The special authority field is 150 bytes. You will have to substring
out 15 fields of 10 characters each. To query on special authorities, you
will have to say in the record selection something like this:
First substringed field = *allobj
Second substringed field = *allobj
and so on.
This has to be done because in most shops users have different special
authorities and they are not sequenced the same way for each user.

You also have to look at limit capabilities. Most users should be set up as
*partial or *yes.

You can also query out by "previous signon date". This is very effective. If
a user hasn't logged on in at least 90 days, either they are not employed at
that company or they didn't need / use their ID.

This is the tip of the iceberg. Maintaining security is a mindset. The user
community must be made aware that audits are being run but nobody is being
spied on. It is from a "protect the company's data assets" that audits are
run.

I was recruited to this organization that had no AS/400 security for over 20
years and asked to implement security with no stoppage in productivity. A
very difficult task. So there was nothing to initially maintain. Now there
is.

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

This is difficult. Standards have to be in place. Which special authority is
needed? Limit capability? Job description? Group profile? Initial program?
Supplemental group profile? What about adding a user to an authority list
where the authority list controls access to a file(s), etc?

These are things that need to be looked at. You can start with a basic logon
model, copy users off it and make adjustments as you go. The best thing
would be to experiment with a test ID and try to do the tasks of the users
Asking for the ID(s).

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

This is quite easy. Using the WRKSYSVAL *SEC command, you can set system
values for logons. Page through the values and set them according to the
company policy. If there is no policy, this is a good way to set one up.
You can force various values on the user community. Once you see the system
Values, you can set them up appropriately.






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

Every day actually. I check for expired passwords, who may have changed
passwords without permission (very few people here can do that). This is an
auditing process that can be discussed at a later date.
On the first of every month, we perform the dspusrprf to an outfile and run
several queries against the user list. For example, who hasn't logged on
in 90 days. We look at special authority, group profiles, supplemental group
profiles. We want to make sure our system is consistently clean and
associates are in the correct groups.

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?

Again, who hasn't logged on will give you a good starting point. In the case
of a new position, naming convention is a nice way to go. If you have
several users in Data Entry. Perhaps their ID is something like DataEn01,
Dataen02, etc. They probably have or should have the same initial program
when logging on. Querying out the user outfile I've described should give
you another place to start.

I hope this helps.

Mike Mayer
Senior AS/400 Information Security Officer
Trans World Entertainment Corporation
38 Corporate Circle
Albany, New York 12203
800-540-1242 x 7277
mmayer@twec.com
http://www.fye.com



-----Original Message-----
From: security400-request@midrange.com
[mailto:security400-request@midrange.com]
Sent: Wednesday, July 17, 2002 1:00 PM
To: security400@midrange.com
Subject: Security400 digest, Vol 1 #83 - 2 msgs

Send Security400 mailing list submissions to
        security400@midrange.com

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.midrange.com/cgi-bin/listinfo/security400
or, via email, send a message with subject or body 'help' to
        security400-request@midrange.com

You can reach the person managing the list at
        security400-admin@midrange.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Security400 digest..."


Today's Topics:

   1. Security Questions (Wills, Mike N. (TC))
   2. RE: Security Questions (Jim Langston)

--__--__--

Message: 1
From: "Wills, Mike N. (TC)" <MNWills@taylorcorp.com>
To: "'midrange-l@midrange.com'" <midrange-l@midrange.com>,
   "Midrange - Security (E-mail)" <security400@midrange.com>
Date: Tue, 16 Jul 2002 16:49:27 -0500
Subject: [Security400] Security Questions
Reply-To: security400@midrange.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?

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

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

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

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?

Any suggestions would be appreciated.

Mike Wills

--__--__--

Message: 2
From: Jim Langston <jlangston@celsinc.com>
To: "'security400@midrange.com'" <security400@midrange.com>
Subject: RE: [Security400] Security Questions
Date: Tue, 16 Jul 2002 15:11:00 -0700
Reply-To: security400@midrange.com

-----Original Message-----
From: Wills, Mike N. (TC) [mailto:MNWills@taylorcorp.com]

>We are currently going through all of the users on our systems and removin=
g
>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 fo=
r
>authority.

1) What have you guys done to maintain security?
I use the security tools periodically to check the accounts on my AS/400 ab=
out once a month or every 2 months (when I remember).  It helps if your acc=
ount passwords are set to expire once a month or so, then you can run a sec=
urity report and see who has not changed their password within the last 30 =
days.  This is an easy way to find obviously obsolete accounts, but is not =
fool proof as I found out at my last company.  One person had left to go to=
 another office for a while, and when she came back 4 months later she call=
ed and said her password was bad.  Doing a little digging I saw the passwor=
d was last set about 15 days ago.  Doing a little more digging I found that=
 this user had given her password to a co-worker to allow him to do somethi=
ng, and when she left he just kept her account active, changing the passwor=
d when he had to.  A stern talking to to the both of them and an eye opener=
 on my side.

2) How do you create new users? Do you have a "general" user which you copy
from? Do you start from scratch?
I have always taken an existing account with the same privileges I wanted t=
o give the new user and copied it.  Modified it when necessary.  Also at on=
e company everyone had almost not provides, but were apart of a group which=
 had the rights they needed.

3) How do you eliminate the possibility of a user using the username for a
password and not allow 'password' for a password?
Security tools has a tool to check for default passwords, where the passwor=
d is the same as the user name.  You can either just print the report, or d=
isable the account also.  System values set the minimum/maximum length of p=
asswords and other things, and the easiest way to disable "password" as a u=
ser password is to not allow consecutive characters (2 of the same characte=
r side by side) which means they could use "pasword" but not "password".  Y=
ou can also require the user to enter at least one digit in their password.=
  You could also use a password validity checker if you wanted.  WRKSYSVAL =
QPWD* and browse through there.

4) How often do you review the users and security?
Once every month to 3 months, depending on how often I remember.

5) Payroll notifies us when people quit or have moved to a new position, bu=
t
it doesn't tell us when remote users quit or have moved on. How do you
handle this?
As stated before, if you set the password expiration level to something, us=
ing security tools (or roll your own) you can report on the last time users=
 changed their passwords.  As previously stated, this doesn't detect when s=
omeone else is keeping an otherwise inactive account active by using it wit=
hout authority.

Regards,

Jim Langston
Programmer/Analyst


--__--__--

_______________________________________________
This is the Security Administration on the AS400 / iSeries (Security400)
digest list
To post a message email: Security400@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/security400
or email: Security400-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/security400.



End of Security400 Digest