Sorry it took so long to reply...

   ----------
   From:       HP3000-L
   Sent:       Friday, May 02, 1997 5:52 PM
   To:         HP3000-L
   Cc:         gstigers
   Subject:    Job Streams & passwords
   
   As we continue to setup our development environment, SECURITY / 3000
   expired an account manager password, under which most job streams run
   (not a good idea for a lot of reasons). So we run into yet another
   classic MPE issue: what do we do about passwords in job streams? I am
   foremost concerned with good security: let people do their jobs
   without
   getting in their way, and present anyone else with a brick wall. I
   see
   three possibilities, and welcome feedback, both constructive and
   critical.

   Have you considered setting-up an individual user under which jobs
are streamed?  For instance, for "production" JCL, you may have a user
JOB.account which has a home group of JOBS.account.  The JOBS group may
have all necessary security, and the user (JOB) password may be expired
at any frequency you wish.  You may set-up a user-level UDC so that any
attempt to execute a job located in a different group causes a logoff.
(That helps keep those pesky little enterprising users from writing a
job which will logon as high capability JOB and do whatever they want.) 
If a user wishes to write a job which logs-on as themself and with their
normal capabilities, they can, but you can at least continue to expire
their password and have your "production" jobs logon.
   
   First is to make the most of MPE capabilities. MPE does prompt for
   passwords on job streams; if there was a time when this wasn't the
   case,
   that time was before my time. However, this both decreases security,
   and
   can rapidly become a pain, since start-up & Operations Support will
   both
   be streaming jobs within non-sys accounts. Some of the more routine
   account-level jobs could still have embedded passwords. The only
   scheme
   I have come up with is, in each account, have a password protected
   userid with out IA access, homed to a password protected group
   containing the job streams, and put an ACD on the job streams. So,
   almost no one can access the job streams, except as allowed by the
   ACD.
   But, this is a lot of maintenance, changing expired passwords in the
   jobs is still a chore (time to learn sed, awk, & perl!), and is a
   rather
   obscure solution, requiring copious documentation and some training.
   This is the idea for which I am most interested in getting feedback,
   both pro and con.

   One thing you may wish to consider... As you describe below, STREAMX
will allow you to specifiy which users may stream which jobs, and not be
prompted for passwords.  For instance, you may lock your JCL in an
account which allows access only to those with SM.  In that situation, a
user may have a need to stream one of the jobs, but you don't want to
give that person SM or the account password.  You can tell STREAMX to
allow that person to stream that job, without being prompted for
passwords.  You may further limit their ability by time of day,
terminal, etc.  In this situation, you can still limit who may stream
the job, and you don't have to give them the passwords or the ability to
modify the job.  While it may not be the ideal situation to not verify
security at every job streaming, you will have to weigh the
costs/benefits of prompting for one or more passwords every time a user
streams a job.  In our case, so much of our day-to-day processing
depends upon jobs that users would hunt me down in the parking lot if
they were prompted for passwords every time they streamed a job.

   
   Or we could use VeSoft's STREAMX. We are after all using
   SECURITY/3000
   and liking it. I appreciate that STREAMX has some intelligence about
   not
   prompting for passwords depending on who is doing the streaming,
   although someone somewhere will leave a session unattended, so that
   makes me a little nervous. But this would be a fundamental change to
   what Operations / Support is used to, so the jury is still out on
   that.
   And I cannot get over my prejudice against third-party software
   utilities that extend the OS.

   In this situation, I use MPEX for idle session logoff.  Granted, this
doesn't eliminate the possibility of the problem you describe.  However,
the first solution scenareo you describe won't fix that problem either. 
If you have embedded passwords, you are especially at risk.  There's
always a human element and window of vulnerability.  I too used to be
concerned about third-party software.  What I've gradually realized is
that HP just isn't going to "play the game" that some third party
companies do, and in the cases where they do "play the game", they don't
do it as well.  VESoft (and many other third-party vendors) have been
around long enough and are respected enough by the HP-3000 community
that I've gotten over most of my prejudice against them.

   
   Or, we could use any of pair of the above, or even all three. That
   would
   probably increase security, and it would increase the complexity, and
   need for documentation and training. That in turn could let us either
   so
   complicate things that we can't do our work, or let us get stupid and
   leave some gaping hole in our security.
   
   When you look at security products, also take a look at security
auditing products.  I use VEAudit by VESoft since I'm already using
Security/3000 and MPEX.  While it won't catch every problem, it is a
valuable tool.  I won't tell you that my system is completly protected,
but the VEAudit software will at least help me find out where I'm not
protected.  I can't fix a problem I don't know about, and VEAudit is one
tool in helping me find security problems.  If you decide to use
Security/3000, you may wish to take a look at the logon security portion
of the manual.

   If you haven't already, you may wish to compare your MPE user IDs
(and Security/3000 profiles) to your companies employee list.  The HR
folks aren't always good about letting the computer folks know a person
has left the company.  If you have an automated method of comparing an
employee list, you may change the password or disable the profile for
any suspect user ID.  You may wish to disable their account if they
haven't logged-on in a set number of days.

   In summary, I can understand your reluctance to use a third-party
utility for security.  In the situation you've described, I believe you
can do everything you wish with Security/3000.  I've been using it for
years, and have no complaints.

                        David N. Lukenbill

--------------------------------------------------------------------
David N. Lukenbill
Hughes Missile Systems Company, Louisville
[log in to unmask]