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
passwords.
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
disconnected.
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
solution.
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
below.
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,
"%LISTF @.@.@(ISPROG and PROG.PMCAP and ISRELEASED),SEC",
will show you all :RELEASEd PM program files. (Do you notice
how closely the command syntax matches the wording of the HP
requirement?)
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
it?);
* globally-readable job streams that contain SM/PM/OP
passwords;
* globally-readable job streams that contain any embedded
passwords;
* 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
restrictions).
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.
Conclusion:
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.