Using VESOFT Products To Implement The Hewlett-Packard
   Recommendations For Tuning Up Your HP3000 System Security
                 by Michael D. Hensley, VESOFT

Dear HP3000 System Manager:

The June 1990 issue of InterexPress included an article by Hewlett-
Packard information security program manager Jim Schindler entitled
"Step by Step: A set of security procedures for system managers".
As a vendor of HP3000 system software since 1980
(with over 10,000 packages -- MPEX, SECURITY, and VEAUDIT --
installed worldwide), VESOFT
shares HP's concerns and applauds their desire to help System
Managers improve system security.
However, most of the recommendations made by HP can not be
practically followed in a "real-world" environment using only MPE
commands and utilities.

Enclosed is a copy of HP's recommendations, together with information on
how our software  can be used to satisfy (and in most cases exceed) them.

Please note that there are a number of computer security issues that
HP did not address.
This letter merely presents the ways that VESOFT can help you
implement the procedures they did mention.
MPEX, SECURITY, and VEAUDIT all provide many more security
features; there just isn't enough space to describe them all here
(the combined reference manuals are now over 500 pages long)!

PLEASE NOTE: while the enclosed list may seem lengthy, we believe
that all of the information contained within it can be of great
benefit to you and your company.
Computer security is a complex subject, but a few minutes spent now
can save you much time later (especially if you have an audit coming
up soon) and may help prevent a serious loss of valuable company data
(and protect your own resume).

If you have any questions about any of these issues, or would like a
free demo tape of our products, please let us know.

Thank you,

Step One: Maintain account passwords:

   1. Verify that ALL accounts have passwords.
      Note that some HP and third-party software is installed without
      passwords. The system manager should promptly assign passwords
      to these accounts.
   2. Change passwords on all accounts, beginning immediately with
      accounts which have special capabilities (PM, SM, OP)...
   3. Change passwords on accounts that are installed with
      "default" passwords.

      Verifying that accounts have passwords, making sure that the
      passwords are not easily guessable, not too short, etc.
      -- these ideas all require that the System Manager
      or Security Manager visually scan a complete list of all
      account passwords.
      No one else can do it, because they aren't supposed to know the
      The list, which can only be produced by the :LISTACCT command,
      will be very big.
      There is no way to select subsets of accounts, like "accounts
      with special capabilities".
      Most importantly, doing this task manually is both extremely
      time-consuming and extremely error-prone.

      SECURITY/3000 can prevent anyone from logging on to any account
      that doesn't have an account password, and/or any user id that
      doesn't have a user password (or a SECURITY/3000 User Profile).
      Like virtually all SECURITY/3000 options, this can be enabled
      for all accounts, particular accounts, accounts with special
      capabilities -- the possibilities are too numerous to list here!

      VEAUDIT reports will show you:

         * passwordless users with SM/PM/OP capability;
         * all passwordless users;
         * a concise directory listing of all users, groups,
           and accounts and their capabilities, etc.,
           that indicates which ones don't have passwords.

   4. Purge accounts that are not needed for ongoing system operation.

      MPEX allows you to LISTF, STORE and/or PURGE files based on the
      last access, modify, restore, or create date. After purging all
      of the old files you no longer need, a single VEAUDIT command can
      purge all empty accounts on the system (except the ones you need
      to keep, even though they are empty).

      Of course, the VEAUDIT concise directory listing mentioned above
      is a very good way to make sure that you know what accounts are
      on your system, what capabilities they have, and more -- in a
      short, easy-to-use format.

   5. Institute procedures for changing all account passwords
      on a regular basis...

      Any manual procedure to ensure that passwords are regularly
      changed will, at least occasionally, fail to do so.
      SECURITY/3000 can automatically enforce password obsolescence,
      for both MPE and SECURITY/3000 passwords,
      guaranteeing that passwords will be changed on a regular basis;
      and, SECURITY/3000 keeps a "password history" to make sure users
      don't simply switch back and forth between the same two passwords.
      SECURITY/3000 can also immediately expire all SM/PM/OP account
      passwords; you can then change them all, knowing no one can log
      on using an old, unchanged one in the meantime.

      VEAUDIT provides a report that shows, among other things, account
      passwords that haven't been changed in the last 30 (or however
      many you like) days.

   6. Ensure that passwords cannot be guessed easily.

      With MPE alone, of course, you're left to a manual inspection
      of a long report again...

      SECURITY/3000 provides an extremely flexible password
      edit-checking mechanism.
      VEAUDIT, as we mentioned earlier, provides a report that shows
      passwords you currently have that are "easily guessable" (like
      SECRET, PASS, etc.), or are well-known "vendor defaults" (like
      HPONLY and RESTOREP, the default when :RESTORE creates an
      account, group, or user).

   7. Change relevant account passwords when employees with
      knowledge of passwords leave the organization.

      This is easier to say than to do.
      You must also change all jobs that contain the account
      password (and you have to find them first)!
      If you have multiple systems connected by NS, you must also
      find and change all jobs on other systems that log on via the
      :REMOTE HELLO command!

      STREAMX, part of SECURITY/3000, allows you to stream jobs that
      don't have embedded passwords or that have invalid embedded
      passwords -- in the !JOB-card or !REMOTE HELLO commands
      (STREAMX does a lot more than just insert passwords -- it is a
      virtual "job stream programming language"; see the SECURITY/3000
      reference manual for details)!

      If you are using SECURITY/3000 User Profiles, simply delete the
      user's profile from the SECUR database -- he will no longer be
      able to log on even if he does know the account password!

Step Two: Maintain user passwords:

   Note: All of the features described above for account
   passwords also apply to user passwords -- obsolescence, flexible
   password editing, VEAUDIT reports, etc.  These features are all
   designed both to replace very difficult, error-prone, manual
   methods and to implement things that can't be done manually
   at all.

   1. All users within special capability (PM, SM, OP, NM, NA)
      accounts should have user passwords.

      As mentioned above, SECURITY/3000 can prevent any user from
      logging on to any account (or just to "special capability"
      accounts) without an MPE user password or, optionally, a
      SECURITY/3000 User Profile (with its own password).

      Since a user with AM capability can give himself any capability
      that his account has, VEAUDIT reports consider an AM user in an
      account that has SM, PM, or OP to already have SM, PM, or OP;
      whether his AM-user id currently has it or not.

      Some of the relevant VEAUDIT reports include:

         * passwordless users with SM/PM/OP capability;
         * all passwordless users;
         * users protected only by account-level passwords
         * users with AM capability

   2. All users within accounts accessible by more than one
      person should have individual user passwords.

      With MPE alone, this requires assigning a separate MPE user ID
      to each user.
      Although MPE provides session names, there is no way to ensure
      that a given user will log on with a particular session name.
      Sometimes you may have to have users share a functional user id,
      like CLERK, but you
      still want to provide a unique identifier for each user.
      SECURITY/3000 User Profiles allow you to put one-way encrypted
      SECURITY/3000 passwords on individual session names.

   3. Purge obsolete and unused users from all accounts.
   4. Change relevant user passwords when employees with
      knowledge of passwords leave the organization.

      This is a good policy to establish, but... what if you forget?
      Or what if the user's manager forgets to notify you that someonehas
      left his department? And which passwords are "relevant", anyway?

      SECURITY/3000 obsolescence lets you ensure that old MPE user IDs
      cannot be used indefinitely to log on to your system.
      If no one is regularly using and changing a password, it will
      expire and no one can later "discover" (or remember!) it and log on.
      If someone is using the password, he will be given the chance
      to change it at logon time shortly before it expires.
      SECURITY/3000 also lets any user change his own password, any
      time he wants to (the easier it is for a user to change his
      password, the more likely he is to do it).

      Don't forget -- any user with AM capability can add as many MPE
      user IDs (without passwords) as he likes, whenever he wants to.
      Not only are there VEAUDIT reports to show directory changes
      (see below), but if you enable SECURITY/3000 User Profiles,
      simply adding a new MPE user id will not let anyone log on.
      You can selectively permit and/or forbid AM (and other) users
      to maintain User Profiles, account by account (or user by user,
      or by capability...), and log every add, change, delete, etc.

      VEAUDIT reports show (among many other things):

         * MPE passwords unchanged in the last nn (however many) days;
         * SECURITY/3000 passwords unchanged in the last nn days;
         * SECURITY/3000 user listing
         * recent MPE directory changes
         * recent SECURITY/3000 users changes

Step three: Control system access:

   1. Configure all modem ports to TYPE 16, SUBTYPE 1 to ensure
      that sessions will terminate when the associated line is

      This configuration change indeed ensures that anyone who hangs
      up a dial-in line will be logged off.

      A much more serious problem, however, is the user who logs on
      (whether through a dial-in line or not), and then walks away
      from his terminal.
      Since, as far as the system knows, anyone who uses that terminal
      is the same user that was so carefully identified by passwords
      at logon time, this becomes a major security violation.

      The LOGOFF feature of SECURITY/3000, simply put, will log off
      anyone who leaves an unused terminal (dial-in or not) logged on.

   2. Investigate whether your PSDN [X.25] vendor can restrict
      access to your system to specific X.25 addresses.

   3. :DOWN modem ports until required.

      Unfortunately, this won't do you much good unless you have 24-hour
      operations support so that someone is there to :UP the modem port
      when you do need it!
      Even if you do have someone there, there are weaknesses in this
      method (Do you always remember to :DOWN it again when they're
      done?  Did you :DOWN all of your modem ports again after the last
      system restart?).  See our response to point 5 below for a better

   4. Investigate hardware and software technologies for
      restricting dial-in access to authorized users.

      SECURITY/3000 provides terminal passwords, requiring anyone who
      logs on to a specific port or set of ports (like "all dial-in
      lines") to enter an extra password.
      This way, even normally authorized users can't dial in unless they
      know the terminal password.

      SECURITY/3000 also allows you to prohibit users from logging on
      to particular user IDs or accounts by: time-of-day, day-of-week,
      terminal, number of jobs running in a given account, existence
      of a particular file, etc. -- almost any arbitrary condition (or
      combination of conditions) you may want to specify!

   5. Require positive authentication of any caller requesting
      access to your system, such as the HP support engineer
      asking to connect to your system to gather data.

      One possible use of SECURITY/3000's ability to prohibit users
      from logging on based on "arbitrary conditions" (mentioned above)
      would be to set up a logon for MANAGER.TELESUP that requires a
      console operator to ":REPLY pin,YES" every time someone
      tries to log on as MANAGER.TELESUP (or, maybe, whenever they
      log on to a dial-in line)!

   6. Assign PSDN [X.25] passwords, if possible, and change them
      on a regular basis.

Step Four: Restrict privileges:

   1. When appropriate, use LOGON UDCs (with NOBREAK and
      :CONTINUE) for users that do not require access to MPE.

      This one is easy to set up!  However,
      the main problem here is that the user will have to re-log on
      to change from one application to another.
      Logging on is one of the slowest activities on an HP3000 (for
      many good reasons).

      SECURITY/3000 provides a much more flexible solution via its
      logon MENUs.  If you set up a user with a logon MENU, then
      when that user logs on he won't get direct access to MPE
      -- instead, he'll be shown the menu and asked to select the
      option he desires from it.
      SECURITY/3000 MENU options can execute MPE commands (or, if you
      own MPEX, MPEX commands), stream jobs, RUN programs, and more!
      MENUs can be used to perform virtually any task on the HP3000
      that could be performed without them!

      VEAUDIT reports will show you if your system UDCs can be
      easily disabled by anybody!

   2. Review the need for special capabilities (PM, SM, OP, NM,
      NA) at the account, group and program levels, and remove any
      unnecessary capabilities.  A group with PM capability should
      not have SAVE:ANY access.

      Note: that last sentence is so important, it will be discussed

      Special capabilities are perhaps one of the most frequently
      misunderstood aspects of system security.
      Not granting them to users who need them is just as bad as giving
      them out freely to everyone.
      A common example: in order for a user to control a printer in his
      own department, he must be :ALLOWed each of the spooler commands
      every time he logs on, or every user on the system must be
      :ALLOWed these commands at all times!
      We have even seen users given SM capability so that they could
      execute the :CONSOLE command to do what they want (sort of like
      opening a lock with a cannon -- it works, but makes it hard to
      close the door again afterwards...).  SECURITY/3000 has a way
      to automatically grant spooler (and other console) commands to
      particular users each time they log on.

      The VEAUDIT concise directory listing, as mentioned earlier, is
      a much more convenient way to determine what capabilities each
      account, group, and user has.  In addition, VEAUDIT reports:

         * users with SM/PM/OP capability;
         * groups with PM capability that don't need it;
         * users with AM capability -- including all capabilities their
           account has, which they can easily obtain.

   3. Remove all programs from your system which allow
      unprivileged users to obtain special capabilities.

      VEAUDIT provides a report of all privileged programs, so that
      you can identify them, determine what they do, and remove the
      ones that don't belong on your system.

   4. Program files with PM capability should not be RELEASEd.

      This is a very important recommendation, but -- how are you
      going to find these files?
      In fact, the PM program doesn't even have to be RELEASEd; simply
      having Write:ANY access is bad!  (For details, you might consult
      the book "Thoughts And Discourses On HP3000 Software"
      by Eugene Volokh).

      A single MPEX command,
      will show you all :RELEASEd PM program files.  (Do you notice
      how closely the command syntax matches the wording of the HP

      Other kinds of :RELEASEd (or globally-writable or even -readable)
      files can create security loopholes, too.  VEAUDIT will reveal:

         * globally-writable program files in PM groups (of course);
         * globally-writable job streams that logs on as SM/PM/OP users
           (or do you read every line of every SM job before you :STREAM
         * globally-readable job streams that contain SM/PM/OP
         * globally-readable job streams that contain any embedded
         * globally writable jobs that log on anywhere;
         * all globally writable files (including :RELEASEd).

      Of course, simply finding all :RELEASEd files is not
      enough -- how will you :SECURE them?  One at a time?
      MPEX's fileset-handling capabilities, combined with its many file
      attribute variables and functions, allow you to very easily
      :SECURE all :RELEASEd PM programs on your system.

   5. User-developed and third-party programs with PM capability
      should be reviewed for security implications and should be
      secured by a lockword if appropriate.

      As we mentioned above, VEAUDIT will find all PM programs on
      the system for you so that you can make sure you know what they
      all are.

Step five: Restrict access to sensitive information

   1. Restrict READ access to UDC files, job streams and other
      files containing user names, account names, passwords,
      remote system names, remote logons, phone numbers and other
      sensitive information.

      Restricting READ access only applies to the disc file; it won't
      help much if a copy of an SM job you were working on (or a
      program with embedded IMAGE passwords...) is later found in
      a trash can!
      R:GU access doesn't work on printouts!

      STREAMX allows you to completely avoid embedded passwords,
      lockwords, :REMOTE HELLO passwords, and much, much more!
      This applies to job streams, SECURITY/3000 menus, and
      MPEX command files, all of which can be executed by users
      who only have eXecute access!

   2. Secure the NETCON database and other files containing
      system or network configuration information.

   3. If possible, remove embedded passwords from job streams.

      But, of course it isn't possible!  MPE requires you
      to embed passwords in job streams!

      STREAMX lets you avoid having to embed passwords.
      It automatically inserts passwords (both
      "!JOB-card" and "!REMOTE HELLO" passwords) into job streams at
      job submission time.
      If the job contains an invalid password, STREAMX will replace
      it with the correct one; this allows you to change passwords
      immediately without having to find and edit all of your jobs.
      STREAMX will also automatically insert file lockwords.
      (All of this is, of course, subject to normal security

      VEOPEN, another SECURITY/3000 feature, eliminates the need to
      embed IMAGE passwords in jobs and programs!

      VEAUDIT report 303 will show you job streams that have embedded,
      valid, passwords in them.

   4. Move sensitive files created by system maintenance
      processes such as BULDACCT.PRV.TELESUP.

   5. Restrict access to documentation relating to sensitive
      utility programs.

Step six: Monitor system activity:

   1. Enable System Logging events #2 (Job Initiation), #3 (Job
      Termination) and #15 (Console Log Event).

   2. Review system logs regularly for suspicious activity.

      Unfortunately, although MPE can log all kinds of interesting
      information, there is no convenient way to select from and
      report on these log files.

      SECURITY/3000 has its own logging facility, with very flexible
      reporting capabilities.  You can log all logons, job stream
      submissions, password changes, attempted security violations,
      and more.  You can sort and select log records based on any
      arbitrary conditions; e.g., you can list all access to the
      PAYROLL from the dialup lines, or all jobs submitted by the
      user JOE,CLERK.AP, or all attempted (but disallowed) logons
      between 10 PM and 5 AM.


   Computer security is a very complex subject.  As we have seen,
   HP is doing their best to make you aware of many of the potential
   pitfalls and the need to "cover them up".
   VESOFT provides many tools (shovels?) to help you accomplish this.

Go to Adager's index of technical papers