Re: Security <was RE: Fw: Rewarding challenge AS/400...>

[Chuck Lewis <clewis@xxxxxxxxxx>]

<37E8ED80.5D4B0161@conexfreight.com>
Content-Type: multipart/alternative;
  boundary="------------F572125F6954205C0239EDE2"
Sender: owner-midrange-l@midrange.com
Precedence: bulk
Reply-To: MIDRANGE-L@midrange.com
Errors-To: list-errors@midrange.com
X-List-Name: Midrange Systems Mailing List (MIDRANGE-L@midrange.com)


--------------F572125F6954205C0239EDE2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jim,

Here's what I did at my previous employer (locations ALL over North 
America) which
something similiar could help you in narrowing down who's where. All our user
profiles had an INLPGM. I Replaced that program with one that captures the 
user id,
device and date and time to a file and then calls the "original" INLPGM. 
What this
comes up with is a database of who signed on where (on what day and time) 
for the
last 12 signons. Our help desk people could check this database when 
someone called
and said "this is so and so and my device won't work" to narrow down what 
device the
user "most likely" uses. This same type of info would at least tell you 
what location
they are at (assuming that not everyone is QPADEVxxxxxx).

Chuck


Jim Langston wrote:

 > They write it in... a book?!?
 >
 > I tell all my users not to give anyone their password, not even 
me.  When I show
 > them how to log on for the first time (they have expired set to yes) and 
explain
 > to them how to change their password, I tell them not to give it to anyone.
 >
 > It sounds like that Supervisor needs to be explained what he whole idea of
 > passwords is.  About that time I think I would broadcast a message to *ALLWS
 > restating the policy of the IS department that people not give their 
password out
 > to anyone, including their supervisor.  Then I would go and set all 
passwords to
 > expired.
 >
 > Regards,
 >
 > Jim Langston
 >
 > Eric wrote:
 >
 > >         Being that many users do not know that they should not be 
signing on as
 > > other people, one option would be to present a screen to users every so
 > > often.  State that payroll wants the correct spelling of their name and
 > > what department that they are working in.  You could also specify that the
 > > name that they fill is not their USER ID.  This tends to weed out some of
 > > the culprits.
 > >         Nothing is full proof though.  At a company that I worked at 
once, I
 > > turned on password expiration in hopes of keeping people from using each
 > > other's passwords.  I thought I had it all worked out until one day 
while I
 > > was in the sales department I heard someone yell, "It's time for me to
 > > change my password.  Who has the book?".  I asked the person what book 
they
 > > were looking for.  She said that whenever an employee changes their
 > > password, their supervisor makes them write their name and new password in
 > > a book for employee reference.  They keep by the printer so everyone can
 > > access it.
 > >
 > > Eric Kempter
 > >
 > > -----Original Message-----
 > > From:   Jim Langston [SMTP:jlangston@conexfreight.com]
 > > Sent:   Tuesday, September 21, 1999 8:17 AM
 > > To:     MIDRANGE-L@midrange.com
 > > Subject:        Re: Fw: Rewarding challenge AS/400...
 > >
 > > One of my biggest headaches is that we have 3 remote sites on our WAN.
 > > Atlanta, San Diego and Atlanta (and I'm in Los Angeles).  I can fairly
 > > easily
 > > confirm who works here, but it is harder out there.
 > >
 > > I know when I started creating user profiles I would put descriptions in
 > > the
 > > text field explaining what their position was and where they were located
 > > I.E. LA Counter Supervisor (Counter)
 > > so that I could determine at least where to find someone.
 > >
 > > The older profiles, on the other hand, give no indication of who they are
 > > or where they work.  I.E.  System User (Anna)
 > >
 > > The name in parenthesis is the name of the group profile they are under.
 > >
 > > I guess I'll just have to start from #1 and confirm everyone, and then 
fill
 > > out the comments.
 > >
 > > One of my many, many, many projects I need to do.
 > >
 > > Regards,
 > >
 > > Jim Langston
 > >
 > > "Kahn, David [JNJFR]" wrote:
 > >
 > > > Jim,
 > > >
 > > > I think the only thing you can do is to audit your user profiles on an
 > > > on-going basis. Set yourself a timescale to get through them all, then
 > > > parcel them up into so many per week or per month. When you get to the
 > > end
 > > > start again at the beginning and repeat indefinitely. It's a PITA 
for you
 > > > and irritating for your users but in the light of...
 > > >
 > > > >I then took a list of our users to our head accounting person/person
 > > > >in charge and asked them who still worked here.  She didn't know.
 > > >
 > > > ... I don't see any realistic alternative. You might be able to verify
 > > > against active security badges or something like that, but that's just
 > > > another system with its own set of holes.
 > > >
 > > > John Earl's recent posting "AS/400 on alt.hacker" graphically 
illustrates
 > > > the weakness inherent in assuming active account = good account. It 
might
 > > > also be a good idea to check for multiple concurrent sessions by user
 > > > profile. This can also give you an indication that profiles are being
 > > > shared.
 > > >
 > > > Dave Kahn
 > > > Johnson & Johnson International (Ethicon) France
 > > > Phone : +33 1 55 00 3180
 > > > Email :  dkahn1@jnjfr.jnj.com (work)
 > > >            dkahn@cix.co.uk      (home)
 > > >
 > > > -----Message d'origine-----
 > > > De: Jim Langston [mailto:jlangston@conexfreight.com]
 > > > Date: 20 September 1999 20:06
 > > > A: MIDRANGE-L@midrange.com
 > > > Objet: Re: Fw: Rewarding challenge AS/400...
 > > >
 > > > Well, usually no one tells me they left.  And if I find out later, I
 > > delete
 > > > them,
 > > >
 > > > or I find out when I analyze user passwords, and see the last date they
 > > > changed
 > > > their password was over 30 days ago.
 > > >
 > > > But if someone is using some else's account...
 > > >
 > > > There was a case, for instance.  Someone had left before I had came 
here,
 > > > analyzing passwords was fine.  The, this person came back. And then 
I see
 > > > the message in QSYSMSG that their password was disabled.
 > > >
 > > > Looking at the display station it was disabled from I quickly 
figured out
 > > > what had happened.  There was a user who did not have the authority to
 > > > do something years ago, call them UserA, so this other user, UserB,  let
 > > > them use their account.  UserB then left the company.  No one was around
 > > > to delete UserB's account, and UserA continued to use it.  UserB comes
 > > > back to the company, and changes their password (how they figured out
 > > > what their current password was, I don't know, as they must change it
 > > > every 30 days).  UserA then tries to log in to UserB's account, and
 > > disables
 > > > it since the password was changed.
 > > >
 > > > UserA was talken to (talked to?) and told this was a definite no no,
 > > never
 > > > do
 > > > it again, UserB was talken to and told never to give anyone their
 > > password,
 > > > a message was broadcast that everyone is to use their log in and no one
 > > > else's,
 > > > if they needed authority have their manager contact me or they weren't
 > > > supposed
 > > > to be doing it in the first place.
 > > >
 > > > I then took a list of our users to our head accounting person/person in
 > > > charge
 > > > and
 > > > asked them who still worked here.  She didn't know.
 > > >
 > > > So what to do?
 > > > +---
 > > > | This is the Midrange System Mailing List!
 > > > | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
 > > > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
 > > > | To unsubscribe from this list send email to
 > > MIDRANGE-L-UNSUB@midrange.com.
 > > > | Questions should be directed to the list owner/operator:
 > > david@midrange.com
 > > > +---
 > >
 > > +---
 > > | This is the Midrange System Mailing List!
 > > | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
 > > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
 > > | To unsubscribe from this list send email to
 > > MIDRANGE-L-UNSUB@midrange.com.
 > > | Questions should be directed to the list owner/operator:
 > > david@midrange.com
 > > +---
 > > +---
 > > | This is the Midrange System Mailing List!
 > > | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
 > > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
 > > | To unsubscribe from this list send email to 
MIDRANGE-L-UNSUB@midrange.com.
 > > | Questions should be directed to the list owner/operator: 
david@midrange.com
 > > +---
 >
 > +---
 > | This is the Midrange System Mailing List!
 > | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
 > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
 > | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
 > | Questions should be directed to the list owner/operator: 
david@midrange.com
 > +---

--------------F572125F6954205C0239EDE2
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
Jim,

Here's what I did at my previous employer (locations ALL over North 
America) which something similiar could help you in narrowing down who's 
where. All our user profiles had an INLPGM. I Replaced that program with 
one that captures the user id, device and date and time to a file and then 
calls the "original" INLPGM. What this comes up with is a database of who 
signed on where (on what day and time) for the last 12 signons. Our help 
desk people could check this database when someone called and said "this is 
so and so and my device won't work" to narrow down what device the user 
"most likely" uses. This same type of info would at least tell you what 
location they are at (assuming that not everyone is QPADEVxxxxxx).

Chuck


Jim Langston wrote:
>They write it in... a book?!?
>
>I tell all my users not to give anyone their password, not even me.  When 
>I show
>them how to log on for the first time (they have expired set to yes) and 
>explain
>to them how to change their password, I tell them not to give it to anyone.
>
>It sounds like that Supervisor needs to be explained what he whole idea of
>passwords is.  About that time I think I would broadcast a message to *ALLWS
>restating the policy of the IS department that people not give their 
>password out
>to anyone, including their supervisor.  Then I would go and set all 
>passwords to
>expired.
>
>Regards,
>
>Jim Langston
>
>Eric wrote:
>
> >         Being that many users do not know that they should not be 
> signing on as
> > other people, one option would be to present a screen to users every so
> > often.  State that payroll wants the correct spelling of their name and
> > what department that they are working in.  You could also specify that the
> > name that they fill is not their USER ID.  This tends to weed out some of
> > the culprits.
> >         Nothing is full proof though.  At a company that I worked at 
> once, I
> > turned on password expiration in hopes of keeping people from using each
> > other's passwords.  I thought I had it all worked out until one day 
> while I
> > was in the sales department I heard someone yell, "It's time for me to
> > change my password.  Who has the book?".  I asked the person what book 
> they
> > were looking for.  She said that whenever an employee changes their
> > password, their supervisor makes them write their name and new password in
> > a book for employee reference.  They keep by the printer so everyone can
> > access it.
> >
> > Eric Kempter
> >
> > -----Original Message-----
> > From:   Jim Langston [SMTP:jlangston@conexfreight.com]
> > Sent:   Tuesday, September 21, 1999 8:17 AM
> > To:     MIDRANGE-L@midrange.com
> > Subject:        Re: Fw: Rewarding challenge AS/400...
> >
> > One of my biggest headaches is that we have 3 remote sites on our WAN.
> > Atlanta, San Diego and Atlanta (and I'm in Los Angeles).  I can fairly
> > easily
> > confirm who works here, but it is harder out there.
> >
> > I know when I started creating user profiles I would put descriptions in
> > the
> > text field explaining what their position was and where they were located
> > I.E. LA Counter Supervisor (Counter)
> > so that I could determine at least where to find someone.
> >
> > The older profiles, on the other hand, give no indication of who they are
> > or where they work.  I.E.  System User (Anna)
> >
> > The name in parenthesis is the name of the group profile they are under.
> >
> > I guess I'll just have to start from #1 and confirm everyone, and then 
> fill
> > out the comments.
> >
> > One of my many, many, many projects I need to do.
> >
> > Regards,
> >
> > Jim Langston
> >
> > "Kahn, David [JNJFR]" wrote:
> >
> > > Jim,
> > >
> > > I think the only thing you can do is to audit your user profiles on an
> > > on-going basis. Set yourself a timescale to get through them all, then
> > > parcel them up into so many per week or per month. When you get to the
> > end
> > > start again at the beginning and repeat indefinitely. It's a PITA for 
> you
> > > and irritating for your users but in the light of...
> > >
> > > >I then took a list of our users to our head accounting person/person
> > > >in charge and asked them who still worked here.  She didn't know.
> > >
> > > ... I don't see any realistic alternative. You might be able to verify
> > > against active security badges or something like that, but that's just
> > > another system with its own set of holes.
> > >
> > > John Earl's recent posting "AS/400 on alt.hacker" graphically 
> illustrates
> > > the weakness inherent in assuming active account = good account. It 
> might
> > > also be a good idea to check for multiple concurrent sessions by user
> > > profile. This can also give you an indication that profiles are being
> > > shared.
> > >
> > > Dave Kahn
> > > Johnson & Johnson International (Ethicon) France
> > > Phone : +33 1 55 00 3180
> > > Email :  dkahn1@jnjfr.jnj.com (work)
> > >            dkahn@cix.co.uk      (home)
> > >
> > > -----Message d'origine-----
> > > De: Jim Langston 
> [<mailto:jlangston@conexfreight.com>mailto:jlangston@conexfreight.com]
> > > Date: 20 September 1999 20:06
> > > A: MIDRANGE-L@midrange.com
> > > Objet: Re: Fw: Rewarding challenge AS/400...
> > >
> > > Well, usually no one tells me they left.  And if I find out later, I
> > delete
> > > them,
> > >
> > > or I find out when I analyze user passwords, and see the last date they
> > > changed
> > > their password was over 30 days ago.
> > >
> > > But if someone is using some else's account...
> > >
> > > There was a case, for instance.  Someone had left before I had came 
> here,
> > > analyzing passwords was fine.  The, this person came back. And then I 
> see
> > > the message in QSYSMSG that their password was disabled.
> > >
> > > Looking at the display station it was disabled from I quickly figured 
> out
> > > what had happened.  There was a user who did not have the authority to
> > > do something years ago, call them UserA, so this other user, UserB,  let
> > > them use their account.  UserB then left the company.  No one was around
> > > to delete UserB's account, and UserA continued to use it.  UserB comes
> > > back to the company, and changes their password (how they figured out
> > > what their current password was, I don't know, as they must change it
> > > every 30 days).  UserA then tries to log in to UserB's account, and
> > disables
> > > it since the password was changed.
> > >
> > > UserA was talken to (talked to?) and told this was a definite no no,
> > never
> > > do
> > > it again, UserB was talken to and told never to give anyone their
> > password,
> > > a message was broadcast that everyone is to use their log in and no one
> > > else's,
> > > if they needed authority have their manager contact me or they weren't
> > > supposed
> > > to be doing it in the first place.
> > >
> > > I then took a list of our users to our head accounting person/person in
> > > charge
> > > and
> > > asked them who still worked here.  She didn't know.
> > >
> > > So what to do?
> > > +---
> > > | This is the Midrange System Mailing List!
> > > | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> > > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> > > | To unsubscribe from this list send email to
> > MIDRANGE-L-UNSUB@midrange.com.
> > > | Questions should be directed to the list owner/operator:
> > david@midrange.com
> > > +---
> >
> > +---
> > | This is the Midrange System Mailing List!
> > | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> > | To unsubscribe from this list send email to
> > MIDRANGE-L-UNSUB@midrange.com.
> > | Questions should be directed to the list owner/operator:
> > david@midrange.com
> > +---
> > +---
> > | This is the Midrange System Mailing List!
> > | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> > | To unsubscribe from this list send email to 
> MIDRANGE-L-UNSUB@midrange.com.
> > | Questions should be directed to the list owner/operator: 
> david@midrange.com
> > +---
>
>+---
>| This is the Midrange System Mailing List!
>| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
>| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
>| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
>| Questions should be directed to the list owner/operator: david@midrange.com
>+---

--------------F572125F6954205C0239EDE2--



+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---