>*>*>*>*>*>*>*>*>*>*>*>*>*>*>*>*>*>*>*>*>*>*>*>*>*>*>*>
*> <*
<* The HP3000's 'SECURITY/3000' System (part 1) *>
*> <*
<* by Sterling *>
*> <*
<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<
SECURITY/3000 is a third party security package for use on HP 3000 series
computers. It replaces several commands and bundles several utility programs
to monitor system security. In part 1, I will try to provide an overview of
the obstacles that the SECURITY/3000 package presents for any would be
intruders, and discuss the usages of the LOGON system.
SECURITY/3000 is popular because it attempts to shore up the security
weaknesses found in the basic HP MPE Operating System. In order to insure user
ID integrity, HP's logon security system uses passwords. However, these
passwords provide only an illusion of security because:
* There is only one password for each level (user, group, or
account) of security. Thus, knowledge of this password
guarantees that level of security is penetrable.
* On many HP3000 systems, several users log on with the same
USERNAME.ACCTNAME which means they share the same
passwords--this reduces security and provides no auditability.
* Many users treat passwords as a dispensable nuisance, and
therefore readily reveal their passwords to unauthorized
persons.
* Passwords are stored in the system in clear text. Thus, they
may be readily found in job streams, discarded LISTDIR
listings, or on :SYSDUMP tapes.
SECURITY/3000 provides several new features:
USER ID INTEGRITY
~~~~~~~~~~~~~~~~~
In addition to conventional MPE passwords, SECURITY/3000 can use a system of
personal profile passwords -- answers to personal questions such as "WHAT IS
YOUR MOTHER'S MAIDEN NAME?", "WHAT IS YOUR FIRST LOVE'S NAME?", etc. Instead
of asking the same question all the time, SECURITY/3000 asks a random one out
of a number of questions (up to 30, user-configurable). And, instead of
keeping the answers stored in clear text, it encrypts them using a special
one-way encryption system, through which the answers cannot be decrypted by
anybody (not even VESOFT). By this, DP personnel are relieved of problems
associated with having readable passwords on the system.
Thus, passwords are automatically given a psychological security significance;
knowledge of all personal passwords is required to be sure of being able to
access the system, even though the user is asked only one at logon time; and,
passwords are made impossible to determine. Even voluntary disclosure is made
difficult. (The default questions can be configured with custom ones, or
SECURITY/3000 can be configured to instead prompt for a single question rather
than a random personal question).
Furthermore, SECURITY/3000 can be configured to differentiate users by session
name by expanding the USER ID to include session name in addition to user and
account name. This feature permits a better account structure by allowing
"generic" users to be created with user names describing the users' function
and session names identifying the user (e.g. JOHN,ENTRY.PAYROLL and
MARY,CLERK.AP). Thereby, several users could be set up under a common user
name but with different session names, and each one would have unique personal
profile answers, time and day restrictions, menu files, etc. SECURITY/3000
can therefore enforce the use of correct session name by requiring that a user
logs on using the same session name which was configured when added to the
security system.
In addition, SECURITY/3000 permits the system manager to configure a user with
a wildcard ("@") representing the session name and/or user name and/or account
name, which allows authorization of an Account Manager to log on as any valid
user in his account, or the System Manager to log on as any valid user on the
system, or an ordinary user to log on to several different accounts, etc.
This permits greater flexibility while still maintaining a high level of
security and providing positive user identification.
SECURITY/3000 may be activated for the entire system, for selected accounts,
for only certain users, or for only those logons to certain LDEVs (terminals,
DIAL-UPs, DS lines, etc.).
TIME OF DAY, DAY OF WEEK, AND TERMINAL RESTRICTIONS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Most security violations will not occur on Tuesday afternoon at 2:30 in the
middle of the company's payroll department; they will most likely be done in
the dead of night on a weekend across a telephone line. If the payroll
clerks work only on weekdays from 9 to 5 on terminals 31, 32, 33, and 35, any
attempt to access the PAYROLL account at any other time from any other place
is inherently a security violation. HP's logon security system does not
protect against this, but SECURITY/3000 does!
LOGON MENUS VS ':'
~~~~~~~~~~~~~~~~~~
After a user has logged on successfully, it is often undesirable, for reasons
of security and/or user-friendliness, for the user to converse with MPE by
typing MPE commands. Rather, one would want a menu of allowed commands and
programs the user is permitted to access to be displayed on the terminal;
then, the user could choose one of them.
Of course, restricting users from MPE (so that they never get a ':') vastly
improves system security because users are prevented from attempting to breach
security using various "holes" existing in MPE (e.g. :FCOPYing a file
containing a password to the terminal, reading passwords in :RELEASEd job
streams [a hole that doesn't exist if the supplied STREAMX utility is
installed] or even doing :LISTFs in sensitive groups and accounts).
This approach is far more common than the often-used method of blocking out
MPE commands by setting up UDC's with the same name, (which can be
circumvented with little effort, such as executing the commands from within
EDITOR or FCOPY) because it is far easier to implement and maintain a system
which INCLUDES the things a user is allowed rather than EXCLUDES the things a
user is not allowed.
VIOLATION REPORTING
~~~~~~~~~~~~~~~~~~~
Unlike HP's logon security system, which reports security violations only to
the system console, SECURITY/3000 reports them to the system console (in
inverse video, to distinguish them from ordinary console messages), prints a
user-definable memo to the system line printer, and logs them to its own log
file for future reference (thus providing a permanent record for further
interrogation). This "three-alarm" system makes sure that attempted security
violations are acted upon, not ignored. [supposedly]
AUDIT TRAIL
~~~~~~~~~~~
Although an Account Manager ID should be able to add, change, or remove user
security within his own account, there must be some means provided to keep
track of his actions. Under HP's logon security system, an Account Manager
ID can be used to create a fictitious user ID, log on to the system under it,
and do something that he shouldn't be doing without being afraid of getting
caught. With SECURITY/3000, all user additions, changes, and deletions are
logged to the SECURITY log file, thus allowing an auditor or System Manager
to determine who created, altered, or removed a given user ID.
ENFORCING REGULAR PASSWORD CHANGES BY OBSOLETING MPE PASSWORDS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
OBSOL, SECURITY/3000's MPE Password Obsolescence System, ensures that MPE
passwords are changed on a regular basis, which can be defined for each
password. Users are warned before a password will expire (configurable as to
the number of days) to get their password changed.
PERMITTING USERS TO CHANGE THEIR OWN MPE PASSWORDS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
MPE's security makes changing user passwords quite difficult. Since only an
Account Manager can change a user password, changing passwords is actually
discouraged! A user will feel reluctant to take the time to get hold of his
Account Manager to have his password changed (even if he, the user, suspects
it has been compromised); an Account Manager is very likely to put off
changing passwords if it means changing them for all 100 users in his account.
The SECURITY/3000 package contains "PASCHG" a program that allows users to
change their own passwords (not other users' unfortunately); this poses no
security threat; in fact, it actually improves security by making it easier
for users to get their own password changed.
ELIMINATING PASSWORDS IN JOB STREAMS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The requirement of keeping passwords in clear text in job streams is a big
security flaw because anyone with READ access to the job stream can read the
passwords, and any listing of the job contains the password. More
importantly, since changing a password means having to change every single job
that contains it, these passwords are virtually guaranteed never to be
changed.
STREAMX eliminates the need to embed passwords, lockwords, and other sensitive
information in job streams, while adding additional flexibility to jobs by
permitting parameter passing.
DIAL-UP, TERMINAL AND DS SECURITY
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Also desirable is the ability to put a password on a DIAL-UP line, DS line, or
terminal, regardless of the user trying to log on. That way, if a hacker
or "inside" violator attempted to log on to a DIAL-UP, he would have to know
the password for the DIAL-UP, which could be changed every day.
In addition, the high level of user authentication that the logon procedure in
SECURITY/3000 provides can be linked with the terminal and DIAL-UP security by
conditionally invoking the SECURITY/3000 logon security based on LDEV to which
a user is logging on.
This type of terminal security is provided by the TERMPASS utility.
AUTOMATIC LOGOFF OF INACTIVE USERS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Another threat to system security is a very common one: a user goes on a
break or to lunch without logging off. By this, a would-be thief could just
walk up to a terminal and use it--without even having to log on. There are
times when users forget to sign off even before going home for the day, (which
holds up system backups.
The LOGOFF utility allows automatic log off of terminals on which users have
been inactive for a given period of time.
Now that we have had a general overview of SECURITY/3000's many features, lets
take a much more detailed look into the logon security system.
WHAT HAPPENS AT LOGON TIME
~~~~~~~~~~~~~~~~~~~~~~~~~~
With the Logon Security System if SECURITY/3000 invoked, whenever a user logs
on (before he gets the ':' prompt and after he types in his MPE passwords [if
he has any]), SESSION, TIME, DAY, and TERMINAL restrictions which may have
been placed on the user are verified--if the user is not within the allowed
time and day limits or if he is attempting to log on from a terminal he is not
authorized to use, he is denied access to the system (i.e. logged off), an
inverse-video message describing the failed logon attempt is sent to the
console, a memo is printed off the line printer, and an entry is logged to the
SECURITY log file.
If the user, for some reason, replies incorrectly to the original question, he
is given as many more chances as are configured (two by default); he is asked
to reply to the SAME QUESTION additional times--if he does not give the
correct answer on any of these attempts, he is logged off and the violation
reporting described above is done. If, however, he replies correctly to any
of the question prompts, he is allowed on the system.
Here is an example of the logon conversation:
:HELLO JOHN,CLERK.PAYROLL
WHERE WAS YOUR FATHER BORN? << incorrect answer entered >>
Error: The answer given was INCORRECT
WHERE WAS YOUR FATHER BORN? << now a correct answer is entered >>
Welcome! You are now signed on.
END OF PROGRAM
: << you have signed on successfully, you are now in MPE >>
An Account or System Manager can set up a special LOGON MENU for some or all
users. If this has been done, a menu will roll up on the screen immediately
after the logon question is answered.
At this point, the user should enter the number of the selection that he
wishes to invoke, or 'E' to exit. If he enters a selection number, that
selection is invoked, and, when it is done, the menu is redisplayed. When the
user types 'E', he is logged off the system.
How to ADD users to the Logon Security System
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Of course, before the system can ask users questions at logon time, it must
know the correct answers. So, the Account or System Manager must add each
user to the Logon Security System data base (ANSWER.DATA.SECURITY), specifying
the user name, account name, and session name (which comprise the "USER ID")
and time, day, and terminal restrictions, the menu file name (WHICH MUST HAVE
BEEN CREATED ALREADY) and then have the user input the answers to the personal
profile questions.
To enter users, log on as Account Manager (to add users under an account) or
System Manager (to add any user) and then
:RUN USER.PUB.SECURITY,ADD
Following are the items that this option prompts for:
(type '?' for help any time you don't know what to enter or how to enter it)
Enter user name:
Enter the MPE user name of the user to be added into the Logon Security
System. This user must exist in MPE already. Or you may enter an "@", which
means "any user" (or hit <return> to exit).
Enter account name:
You are asked this only if you are the System Manager; if you are an Account
Manager, this will default to your account name. You may enter an "@" which
means any account (or hit <return> to exit).
Enter session name:
The system permits securing users by session name as well as user name and
account name. Enter the session name which the user should use at logon or
hit <return> if the user will not use a session name, or enter an "@" if the
user may log on with different session names.
NOTE: This feature may be used to create a better account structure --
instead of creating MPE users by first name (JOHN, MARY, etc.) the
Account Manager can create "generic" user names based on the functions
existing within a department (CLERK, SUPER, MANAGER, etc.). When
several people share the same function, the Logon Security System will
differentiate them by session name which can be the person's first name.
Example of such logons are :HELLO MARY,MANAGER.PAYROLL and :HELLO
JOHN,CLERK.PAYROLL. The session name may be retrieved by your
application programs and then carried through your application system
along with the transaction record.
Enter user's real name:
This is the real name of the user (for instance, JOHN Q. DOE). This
information is used on the printed security violation memo and some log file
entries.
Enter the permitted terminal numbers:
Enter up to 30 logical device numbers on which the user is to be permitted to
log on, separated by commas (for instance, '220,55,73'). Hit <return> to
permit access by the user on all terminals. (See the "REMOTE" section of this
manual for details about putting a password on a dial-up, DS line, or other
terminal, regardless of where the user is logging on to.)
Enter the day-of-week access restrictions:
To permit the user to log on only on certain days of the week, enter a day of
the week (e.g. 'WEDNESDAY' means the user can log on only on Wednesdays) or
two days of the week separated by a '-' (e.g. 'MON-FRI' means the user can log
on only on Monday through Friday). Days may be spelled out or abbreviated to
3 characters. Hit <return> to permit access on all days.
Abbreviations allowed: 'SUN', 'MON', 'TUE', 'WED', 'THU', 'FRI', 'SAT'
Enter the time-of-day access restrictions:
To allow the user to log on only at certain times of the day, enter the
starting hour followed by a '-' followed by the ending hour (e.g. '9-17' means
that the user can sign on from 9 am to 5 pm). Hit <return> to permit access
at any time of day.
Enter the menu filename:
If you wish to set up a logon menu for this user, enter the name of the menu
file. THE MENU FILE MUST HAVE ALREADY BEEN CREATED (see "LOGON MENUS FOR
SECURITY AND CONVENIENCE" in this manual for details on how to set up a menu).
If you wish the user to instead be allowed to access MPE directly, just hit
<return>.
If you did not create the menu file already, hit <return> (for none), continue
entering the user info, and add the menu file later (see "How to CHANGE users
in the Logon Security System" later in this file).
Should the user be asked personal profile questions (Y/N)?
If you want the user to be asked a personal profile question at logon, type
'Y'. If you do not want a personal profile question to be asked (but still
have all other access restrictions apply), type 'N'.
The user is then added to the Logon Security System, a message is printed
acknowledging the addition of the user, and you are prompted for another user
(hit <return> to exit). Note that all successful user additions are logged to
the SECURITY log file.
NOTE: The ADD option requires Account/System Manager capability!
Following is an example of this option:
:RUN USER.PUB.SECURITY,ADD
SECURITY/ADD Version 0.5 (VESOFT (C) 1981) For help type '?'
Enter user name: CLERK
Enter account name: PAYROLL
Enter session name: JOHN
Enter user's real name: JOHN Q. DOE
Enter permitted terminal numbers: 34,35,36,37,50,52,53,54
Enter day of week access restrictions: MON-FRI
Enter time of day access restrictions: << <return> hit >>
Enter menu filename: CLERK.MENU.PAYROLL
Should the user be asked personal profile questions (Y/N)? Y
WHAT IS YOUR MOTHER'S MAIDEN NAME? << user answers, no echo >>
WHAT ELEMENTARY SCHOOL DID YOU GO TO? << user answers, no echo >>
WHERE WAS YOUR FATHER BORN? << user answers, no echo >>
WHAT IS YOUR FIRST LOVE'S NAME? << user answers, no echo >>
*** User has been added ***
Enter user name: << <return> hit to exit >>
Note that all successful user ADDs are logged to the SECURITY log file.
ANOTHER NOTE: Before starting the ADD option you may wish to get HELP.
To do so say
:FILE CICAT.PUB.SYS=USER.HELP.SECURITY
:HELP
IMPORTANT: Before this user attempts to log on, the Logon
Security System must be activated--see "ACTIVATING THE LOGON SECURITY
SYSTEM" later in this file.
How to CHANGE users in the Logon Security System
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It may occur that an incorrect response was given to the ADD-time
configuration and personal profile questions or you may want to permit a user
to change his answers to the personal profile questions (which is all he is
permitted to do in this option); so to make changes to existing user profiles:
:RUN USER.PUB.SECURITY,CHANGE
The CHANGE option prompts you for: (type '?' for help at any prompt)
Enter user name:
Enter the user name of the user to be changed. If you are not an Account or
System Manager, this defaults to the logon user, (or hit <return> to exit).
Enter account name:
Enter the account of the user ID to be changed. If you are not System
Manager, this defaults to the logon account, (or hit <return> to exit).
Enter session name:
Enter the session name entered at user ADD time. If none was entered, hit
<return>.
This option now displays a menu of items corresponding to the configuration
and personal profile questions, and you are prompted for the item to be
changed. After you change an item, it continues to prompt you until you hit
<return>. (If the menu rolls off the screen, type 'R' to redisplay it.) An
Account or System Manager can change anything; an ordinary user can change
only his answers to the personal profile questions.
Following is an example of the CHANGE option:
:RUN USER.PUB.SECURITY,CHANGE
SECURITY/CHANGE Version 0.5 (VESOFT (C) 1981) For help type '?'
Enter user name: CLERK
Enter account name: PAYROLL
Enter session name: JOHN
R: Redisplay this menu
U: User info (user, account, session)
N: User's real name
T: Permitted terminal numbers
D: Day-of-week access restrictions
H: Time-of-day access restrictions
M: Menu file name
A: Ask personal profile questions?
1: WHAT IS YOUR MOTHER'S MAIDEN NAME:
2: WHERE WAS YOUR FATHER BORN:
3: WHAT ELEMENTARY SCHOOL DID YOU GO TO:
4: WHAT IS YOUR FIRST LOVE'S NAME:
Enter item number to change: M << change menu file name >>
Menu file name is now: PAYCLERK.MENU.PAYROLL
Enter NEW menu file name: PAYSUPER.MENU.PAYROLL
Enter item number to change: << <return> hit to exit >>
*** User has been changed ***
Enter user name: << <return> hit to exit >>
Note that all successful user CHANGEs are logged to the SECURITY log file.
How to COPY users in the Logon Security System
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On some systems a certain user (System Manager, for example) may be required
to access more than one account and therefore may log on with more than one
user ID. This is where the copy option will save you time because it allows
an Account or System Manager to copy a given user's security configuration and
personal profile answers to a new user in the data base. An Account Manager
can copy only users within his account, whereas the System Manager can copy
users anywhere on the system. To enter copy mode, execute a:
:RUN USER.PUB.SECURITY,COPY
Following are the items that this option will ask for
(type '?' for help at any prompt)
Enter original user name:
The user name of the user to be copied. This user must exist in the data base
already, (or hit <return> to exit).
Enter original account name:
The account of the user to be copied.
If you are not System Manager, this defaults to the logon account.
(Hit <return> to exit.)
Enter original session name:
The session name with which the user is configured in the user data base (the
session name that was specified at ADD time). If no session name was
specified, hit <return>.
Enter new user name:
The user name to which the original user's security parameters (configuration
and personal profile answers) should be copied. This user must exist in MPE
already, (or hit <return> to exit).
Enter new account name:
The account to which the original user's security parameters should be copied.
This account must exist in MPE already. If you are not System Manager,
defaults to the logon account, (or hit <return> to exit).
Enter new session name:
The session name which the user should use at logon, or hit <return> if the
user will not use a session name.
Following is an example of the copy option:
:RUN USER.PUB.SECURITY,COPY
SECURITY/COPY Version 0.5 (VESOFT (C) 1981) For help type '?'
Enter original user ID
Enter user name: CLERK
Enter account name: PAYROLL
Enter session name: JOHN
Enter new user ID
Enter user name: CLERK
Enter account name: ORDER
Enter session name: JOHN
*** User information has been copied ***
Enter original user ID
Enter user name: << <return> hit to exit >>
Note that all successful user COPYs are logged to the SECURITY log file.
How to DELETE users from the Logon Security System
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When you delete users from MPE, you should delete them from the Logon Security
System as well. Users must exist in MPE in order to be deleted from the Logon
Security System, so if you wish to delete a user from both, you should delete
him from the Logon Security System by using this option BEFORE doing a
:PURGEUSER. To do this:
:RUN USER.PUB.SECURITY,DELETE
This option prompts you for (type '?' for help at any prompt)
Enter user name:
The user name of the user to be deleted, (or hit <return> to exit).
Enter account name:
The account of the user to be deleted. If you are an Account Manager and not
the System Manager, this will default to the logon account, ( or hit <return>
to exit).
Enter session name:
The session name specified at user ADD time.
If none was specified, hit <return>.
NOTE: This option requires Account/System Manager capability!
Following is an example of the DELETE option:
:RUN USER.PUB.SECURITY,DELETE
SECURITY/DELETE Version 0.5 (VESOFT (C) 1981) For help type '?'
Enter user name: CLERK
Enter account name: PAYROLL
Enter session name: JOHN
*** User has been deleted ***
Enter user name: << <return> hit to exit >>
Note that all successful user DELETEs are logged to the SECURITY log file.
How to SET UP users who use MULTIPLE LOGON IDs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Users are normally defined in the Logon Security System with the specific
session name, user name, and account name (user ID) with which they log on.
In some environments, a user may be authorized to use more than one user ID to
log on, depending on the function he is performing. For example, a user who
uses the Payroll, Accounts Payable, and General Ledger systems may log on with
three user IDs, i.e. JOHN,CLERK.PAYROLL, JOHN,CLERK.AP and JOHN,CLERK.GL. For
this, the COPY option of the USER.PUB.SECURITY program is useful because one
user may be set up with the proper security parameters and the information may
be COPYd to the other two user IDs.
It is also possible that an Account Manager will want to be allowed to log on
as any user in his account; or the System Manager will want to log on as any
user on the system. The Logon Security System permits you to set up a user
who is authorized to log on using many different user IDs by specifying "@"
as the session name and/or user name and/or account name.
For example, if you wanted to set up the System Manager, Mike, so that he
could log on as any user on the system, you could create a user called
MIKE,@.@
by responding to the prompts of the ADD option as follows:
Enter user name: @
Enter account: @
Enter session name: MIKE
If you wanted to set up the Account Manager of the PAYROLL account, Jane, so
that she could log on as any user in her account, you would create a user
called JANE,@.PAYROLL by responding to the ADD prompts as follows:
Enter user name: @
Enter account: PAYROLL
Enter session name: JANE
Jane would be allowed to log on using any valid user name in the account, and
the same personal profile and security restrictions would be used.
ACTIVATING THE LOGON SECURITY SYSTEM
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Logon Security System may be imposed on the entire system, for selected
accounts, for only certain users, or for only logons to certain LDEVs
(terminals, dial-up lines, DS lines, etc.).
To activate the Logon Security System for selected accounts or users, the
Account or System Manager must set up an "OPTION LOGON" UDC that will invoke
the USER.PUB.SECURITY program. The UDC is stored in the file
SECURUDC.PUB.SECURITY
SECURUDC
OPTION LOGON, NOBREAK
comment
comment *******************************************
comment JCW is set 1717 by TERMPASS when $SECURITY
comment keyword is specified for the logon port.
comment Please see the TERMPASS.DOC.SECURITY.
comment *******************************************
comment
IF JCW<>1717 THEN
SETJCW SECURITYANSWER=0
CONTINUE
RUN USER.PUB.SECURITY,LOGON
IF SECURITYANSWER = 1 THEN
BYE
ENDIF
ENDIF
Because the Logon Security System is activated by a UDC, you can limit the
system's scope by setting the UDC at the level (either user, account, or
system) where it is appropriate. So to invoke the Logon Security System for
the logon account, the Account Manager can do the following:
WARNING: DO NOT PERFORM THE FOLLOWING UNLESS YOU HAVE AUTHORIZED
YOURSELF AS A USER (see "How to ADD users to the Logon
Security System" in this section). OTHERWISE, YOU MAY LOCK
UP YOUR ACCOUNT!
:SETCATALOG SECURUDC.PUB.SECURITY;ACCOUNT
(In spite of this warning, if you DID lock up your account, log on to some
other account, create the following file in your editor:
!JOB MGR/password.ACCOUNT/password << the locked-up account >>
!SETCATALOG;ACCOUNT
!EOJ
and :STREAM it.)
Once the SECURUDC is set, whenever a user who is affected by this UDC tries to
sign on, the Logon Security System is invoked and the time, day, and terminal
restrictions, etc., will be applied.
If the account or a user in the account has a logon UDC, that UDC should be
changed to do as its first command the execution of SECURUDC; e.g. if you
want to have a logon UDC that does a SHOWJOB, use the following UDC:
LOGONUDC
OPTION LOGON, NOBREAK
SECURUDC
SHOWJOB
***
Note that the UDC SECURUDC must have also been set for the user or account in
question, e.g.
:SETCATALOG MYUDC, SECURUDC.PUB.SECURITY
It is also recommended that you
:ALLOCATE USER.PUB.SECURITY
to speed things up when logging on, and also so that it will function during
backups.
LOGON MENUS FOR SECURITY
~~~~~~~~~~~~~~~~~~~~~~~~
Of course, by restricting users from MPE (so that they never get a ':') you
are vastly improving security on your system because users are prevented from
attempting to breach security using various "holes" existing in MPE
(e.g. :FCOPYing a file containing a password to the terminal, :SHOWCATALOGs,
or even doing :LISTFs in sensitive groups and accounts).
SECURITY/3000's menu subsystem implements this kind of closed system where you
specify what the user is allowed to do.
If you, the Account or System Manager, want to limit a user's access via a
menu, you must first build a file (the "menu file") in your editor describing
the menu (the user must have READ access to it).
A menu file consists of:
*HEADER Optionally, any number of '*HEADER' lines, which contain
text to be printed when the menu is invoked. A common use
for this is to print some form of menu identification, e.g.
*HEADER ****************************
*HEADER MAIN ACCOUNTS PAYABLE MENU
*HEADER ****************************
You may also put escape sequences to control the display
on a *HEADER line (e.g. <escape-H> <escape-J> to home the
cursor and clear the screen before displaying the menu).
*CAPTION Up to 24 selection descriptors. Each section descriptor
consists of one
'*CAPTION' line followed by a number of body lines.
The '*CAPTION' line defines what this selection should be
identified as on the menu, e.g.
*CAPTION INVOICE ADDITION
The body lines contain the commands to be executed when
the selection is chosen. A body line can be:
MPE Any MPE command or commands, including :RUN,
command :IF, :ELSE, and :ENDIF, e.g.
FILE D=DATA.PUB.AP
RUN INVADD.PUB.AP
LISTF XYZ.PUB;$NULL
IF CIERROR = 907 THEN
RUN UPDATE.PUB;PARM=1
ELSE
DISPLAY Update system in use
ENDIF
DISPLAY which causes the specified string to be
displayed to the terminal, e.g.
DISPLAY This system inoperative until Friday
DISPLAY Contact Joe Martin at ext. 283
VEMENU which invokes VEMENU with the specified menu file.
This permits "nested menus", e.g.
VEMENU NEWORDER.ENTRY.PURCH << menu file >>
USE which executes commands from the specified file,
e.g.
USE ENTRY.PROC.GL << file containing set of
file equations and
commands for entry of
GL information >>
EXIT which exits VEMENU and logs the user off the system.
Thus, a simple menu file may be created as follows:
:EDITOR
/ADD
1 *HEADER *************************************
2 *HEADER ACCOUNTS PAYABLE SYSTEM
3 *HEADER CHOOSE ONE OF THE FOLLOWING:
4 *HEADER *************************************
5 *HEADER
6 *CAPTION VENDOR MAINTENANCE
7 FILE APDB=APDB.DATABASE.AP
8 RUN AP010
9 *CAPTION INVOICE MAINTENANCE
10 FILE APDB=APDB.DATABASE.AP
11 RUN AP020
12 *CAPTION CHECK PRINTING
13 FILE STRMFILE=CHKPRINT.JOB.AP << job stream
14 RUN STREAMX.PUB.SECURITY;PARM=1 << which asks
15 *CAPTION ARCHIVE << for starting check # >>
16 DISPLAY Sorry, archive system not yet ready
17 DISPLAY -- see system management
18 *CAPTION GO TO ACCOUNTS RECEIVABLE MENU
19 VEMENU ARMENU.PUB.AR
/KEEP MAINMENU.PUB.PAYROLL
/EXIT
Then, add the user to the Logon Security System, entering the name of the menu
file when prompted for it; if the user has already been set up in the Logon
Security System, use the CHANGE option to change his menu file name to the
menu file he is to use. If you decide that a user should go directly into MPE
when he logs on instead of using a menu, just hit <return> when prompted for
the name of the menu file.
Whenever a user who is configured in the Logon Security System with a menu
file logs on, the menu contained in that file is displayed and he is asked to
choose a selection or hit 'E' to exit. When a selection is chosen, the
commands specified in the selection body are executed.
When that menu option has completed, the user is returned to the menu and
asked to choose another selection. This continues until either the user
enters 'E' or a selection chosen by the user executes an 'EXIT' command. When
the user exits the menu, he is automatically logged off. AT NO TIME IS THE
USER EVER LET INTO MPE!
Of course, different users can have different menu files. For instance, if
you have an Accounts Payable system--in which you have clerks who can add and
delete invoices; supervisors who can add and delete vendors as well as
invoices; and a manager who can add and delete vendors, add and delete
invoices, and print checks--you can have one menu file for clerks, another
menu file for supervisors, and a third for the manager. (Remember that if
several users share the same function, you can have them all use a common user
name and differentiate them by their session)
ATTEMPTED SECURITY VIOLATION LOGGING
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When an attempted violation occurs, the Logon Security System makes it
possible to catch the violator "in the act" by immediately providing the
necessary information about the attempted security breach.
If a violation attempt occurs--meaning a user has responded incorrectly to a
logon question or has attempted to log on at an unauthorized time, on an
unauthorized day, or from an unauthorized terminal--the Logon Security System
will immediately:
* Send a descriptive message to the system console, in inverse
video, to distinguish it from other console messages
* Print a violation memo off the system line printer (device class
LP) or a designated printer (see "SETTING ATTEMPTED SECURITY
VIOLATION MEMO ROUTING PARAMETERS" in this section).
* Log an entry to the SECURITY log file.
LOG.DATA.SECURITY
This file is initially built as a 5,000-record circular file,
so if the file fills up, new entries will be appended while
the oldest entries are dropped.
This provides sufficient information for the System Manager to immediately
respond to the attempted security breach. The System Manager may also "hang"
the terminal at this point (while someone is waiting to be logged on) for a
while to give himself more time to respond, or to disable that device so that
additional logon attempts are disallowed.
How to LIST the security LOG FILE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Information about all changes to user status (add, change, delete) and all
violation attempts are logged to the SECURITY/3000 log file with pertinent
information about the time and date of the action, terminal on which the
action took place, and the user who performed the action (including session
name). SECURITY/3000 may be configured to log all successful logons,
providing an excellent audit trail of system access.
The following violation messages are logged:
BAD USER Logon attempted by unauthorized user
BAD RESPONSE Question was answered incorrectly
BAD DAY Logon attempted on unauthorized day
BAD TIME Logon attempted at unauthorized time
BAD TERMINAL Logon attempted on unauthorized terminal
INVALID TERMINAL PASSWORD Invalid terminal password was entered
(see the "REMOTE" section of this
manual for details).
and the following update messages are logged:
Add Addition of a user to the Logon Security System
Change Change made to a user in the Logon Security System
Copy Security profile copies from one user to another
Delete User deleted from Logon Security System
and the following successful logon messages are optionally logged:
'SUCCESSFUL LOGON' Valid logon through LOGON SECURITY
'SUCCESSFUL TERMINAL LOGON' Valid logon through the TERMPASS
This file can be later listed to the terminal or line printer, and can be
cleared after review. An Account Manager can list messages in his account,
and the System Manager can list the entire file; (only the System Manager can
clear the file.) An ordinary user is not permitted to use this option.
:RUN USER.PUB.SECURITY,LISTLOG
When you run this option, you are prompted for whether the listing is to go to
the line printer (reply 'L') or to the terminal (reply 'T'). If the line
printer is selected, the log file is dumped (in a readable format) to the line
printer (device class LP). If the terminal is selected, the same printout is
generated except that users' real names are not printed.
To redirect the listing from the default (DEV=LP) to some other device or a
disc file, issue a file equation for SECLIST, e.g.
:FILE SECLIST=MYLOGLST;ACC=OUT;DEV=DISC;NOCCTL;REC=,,,ASCII;SAVE
Following is an example of the use of this option:
:RUN USER.PUB.SECURITY,LISTLOG
SECURITY/LISTLOG Version 0.5 (VESOFT (C) 1981) For help type '?'
Listing to (L)ine printer or (T)erminal: T
Type : Date Time Dev Logon Target user/
Violatn type
Add :20JUL85 5:17PM 33 DON,MANAGER.PAYROLL ENTRY.PAYROL
Violat:21JUL85 9:23AM 117 READER,LABOR.PAYROLL BAD USER
Violat:21JUL85 9:23AM 117 SALLY,ENTRY.PAYROLL BAD RESPONSE
Change:21JUL85 10:17AM 25 BILL,MANAGER.SYS ENTRY.PAYROL
Violat:24JUL85 2:33PM 117 R1,ENTRY.PAYROL BAD DAY
Violat:26JUL85 1:54PM 103 R1,ENTRY.PAYROL BAD TERMINAL
Logon :26JUL85 2:00PM 25 ENTRY.PAYROL SUCCESSFUL LOGON
*** Log file has been printed ***
How to CLEAR the security LOG FILE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Of course you may have good reason to clear the SECURITY log so:
:RUN USER.PUB.SECURITY,CLEARLOG
to clear the log file.
This option will not prompt you for any input.
NOTE: This option can be used by the System Manager only.
A sample run of this option follows:
:RUN USER.PUB.SECURITY,CLEARLOG
SECURITY/CLEARLOG Version 0.5 (VESOFT (C) 1981) For help type '?'
*** Log file has been cleared ***
CONFIGURING SECURITY/3000
~~~~~~~~~~~~~~~~~~~~~~~~~
Several configuration options (described below) may be specified in the
security configuration file,
SECURMGR.PUB.SECURITY
This file is created at installation time with default values, which may be
modified as described in the options below.
DISALLOWING CONCURRENT SESSIONS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As you may know, MPE allows several users with an identical user/account name
(e.g. USER.PAYROLL) to be logged on simultaneously. A user is therefore
permitted to be logged on to more than one terminal and have more than one
session running concurrently, which may be undesirable.
As one of our users pointed out, "No individual could fully control the
activity on two terminals at a time and hence while on one terminal,
unauthorized use could be made of the other."
The Logon Security System may be configured to disallow more than one session
with a given user ID to be logged on concurrently. Remember that we consider
session name to be part of the user ID, so JOE,USER.GL and MARY,USER.GL are
recognized as being different, even though the MPE user name is the same.
With concurrent sessions disallowed, if someone attempts to log on with a user
ID exactly the same as a user who is already logged on, he is not let on the
system. Furthermore, a message is sent to the already-logged-on terminal to
let that user know that someone is attempting a secondary logon.
To disallow concurrent sessions, add the following line to the SECURMGR file:
CONCURRENT-SESSION=NO
Of course we would rather allow concurrent sesseons, so change it to:
CONCURRENT-SESSION=YES
By default, concurrent sessions are permitted.
ELIMINATING SESSION NAME CHECK
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SECURITY/3000 differentiates users by session name by expanding the user ID to
include session name in addition to user and account name. This feature
permits a better account structure by allowing "generic" users to be created
with user names describing the users' function and session names identifying
the individual user (e.g. JOHN,ENTRY.PAYROLL and MARY,CLERK.AP). Thereby,
several users could be set up under a common user name but with different
session names, and each one would have unique personal profile answers, time
and day restrictions, menu files, etc.
SECURITY/3000 therefore enforces the use of correct session name by requiring
that a user log on using the same session name with which he was configured
when added to the security system. If he was configured with a session name
of JOHN, for example, and tries to log on using no session name or a different
session name, he will not be recognized as an authorized user and therefore
will not be let on the system.
For those who do not wish to enforce session name or set up "generic" users
and would rather use MPE's approach of optional session name, it is possible
to instruct the Logon Security System to ignore the session name at logon by
adding the following to the SECURMGR file:
SESSION-NAME=OFF
However, if you choose not to enforce session name, all users must have been
set up in the Logon Security System with the session name the same as the user
name or with a session name of '@'. For example, if you are adding a user who
should log on as JOHN.PAYROLL, he must be set up at ADD time with a user name
of 'JOHN', an account name of 'PAYROLL' and a session name of 'JOHN' or '@'.
When he logs on, however, he should not use the session name but rather just
JOHN.PAYROLL.
(When SESSION-NAME=OFF, the SECURITY data base is checked for an authorized
user with a session name which is the same as the user name.)
By default, session name is a valid part of the user ID.
DISABLING A TERMINAL ON WHICH AN ATTEMPTED VIOLATION HAS OCCURED
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If a user is unsuccessful in logging on (either by not responding properly to
personal profile question, attempting to log on at an unauthorized time or
day, etc.), it is often desirable to "hang" that user's terminal so that he is
unable to attempt further logons.
To do this, determine the time in seconds for which you would like the
terminal hung and then add a line to the SECURMGR file in the format:
PAUSE=numseconds
where 'numseconds' is the number of seconds for which the terminal will be
hung. Then, when a user has an unsuccessful logon attempt, he will be hung
for the amount of time specified.
By default, 'numseconds'=0, which means that the user will not be hung at all.
SPECIFYING NUMBER OF ATTEMPTS TO ANSWER QUESTION AT LOGON
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You may specify the number of attempts users are allowed to answer the
question at logon by adding a line to the SECURMGR file in the format:
TIMES=attempts
where 'attempts' is the number of times the question will be asked.
By default, 'attempts'=2.
LOGGING SUCCESSFUL LOGONS
~~~~~~~~~~~~~~~~~~~~~~~~~
You may wish to know who is logging on through the dial-up line, or whether a
particular logon is being utilized. For how to log successful logons which
come through your dial-in lines or are specific to a port.
You may enable SECURITY/3000 to log successful logons which pass through the
USER program by adding a line to the SECURMGR.PUB.SECURITY file in the format:
LOG-LOGON=ON
This keyword will be seen by the LOGON security program and cause all
successful logons to be written to the LOG.DATA.SECURITY file for later
review. No other configuration is required and this keyword may be added or
removed at any time. When the log file is reviewed later the message:
SUCCESSFUL LOGON
will be displayed.
SETTING ATTEMPTED SECURITY VIOLATION MEMO ROUTING PARAMETERS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The security violation memo which is generated when a violation attempt has
occurred is a useful tool for immediately taking corrective action.
You may change the memo parameters--device to which the memo is routed, outpri
of the memo, and number of copies to generate--by adding a line to the
SECURMGR file in the format:
DEV=device,outpri,copies
where
'device' is the device to which the memo is routed.
'outpri' is the output priority with which the memo will be
generated.
'copies' is the number of copies of the memo which will be printed.
Therefore, if you want the memo routed to a special printer in the DP
Auditor's office where someone will be able to take immediate investigative
action, declare this on the 'device' parm. If you want to give the memo top
priority to ensure that it is printed right away, specify an outpri of 13; if
you want to defer printing the memo, specify an outpri of 1, which will cause
the memo to remain in the spooler for later printing or purging.
If you do not declare a 'DEV=' line in the SECURMGR file, the memo will be
created with default attributes (dev=LP, outpri=8, copies=1).
If you do not want the security violation memo at all (but will still have the
attempted violation console message and log file entry), do not declare a
'DEV=' line in the SECURMGR file, and add this file equation:
:FILE SECLIST=$NULL
to SECURUDC (the UDC which invokes the Logon Security System before the
command which :RUNs USER.PUB.SECURITY.)
HOW SECURITY VIOLATIONS ARE REPORTED
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Whenever an attempted violation occurs, a security memo is printed to the line
printer; the default format of it is:
TO: SYSTEM MANAGER
FROM: SECURITY/3000
RE: SECURITY VIOLATION
WE WOULD LIKE TO CALL TO YOUR ATTENTION THE FACT THAT THERE WAS A
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvv VIOLATION BY:
USER: uuuuuuuu
ACCOUNT: aaaaaaaa
GROUP: gggggggg
SESSION NAME: ssssssss
USER NAME: nnnnnnnnnnnnnnnnnnnnnnnnnnnnnn
LOGICAL DEVICE: lll
ON wwwwwwwwwwwwwwwwwwwwwwwwwww
PLEASE INVESTIGATE.
where
'uuuuuuuu' represents the user name
'aaaaaaaa' represents the account name
'gggggggg' represents the group name
'ssssssss' represents the session name
'lll' represents the logical device number
'nnnnnnnnnnnnnnnnnnnnnnnnnnnnnn' represents the user's real name
'wwwwwwwwwwwwwwwwwwwwwwwwwww' represents the time and date when
the violation (attempt!) occurred
'vvvvvvvvvvvvvvvvvvvvvvvvvvv' represents the type of violation
(BAD USER, BAD DAY, BAD TIME,
BAD TERMINAL, or BAD RESPONSE).
By using the above abbreviations ('uuuuuuuu', 'aaaaaaaa', etc.),
you can modify the memo format as you please. The format is stored in
MEMOFORM.DATA.SECURITY
NOTE: If you have :HEADON on your LP, the header on the memo will
indicate the user name (in this case, the violator!) on it, and
the operator may deliver this memo to the violator!
HOW THE QUESTIONS FILE IS MAINTAINED
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The personal profile questions that are asked at logon time of all users in
the system are not fixed by SECURITY/3000; they can be set up with custom
questions--up to 30 of them (remember, only ONE of the questions, at random,
will be asked at logon time). The questions are stored in the editor-format
file called
QUESTION.DATA.SECURITY
When SECURITY/3000 is installed from VESOFT, there are already some sample
questions in this file, so it may not be changed at all.
So, if you want to add a question to the file, just do the following:
:EDITOR
/TEXT QUESTION.DATA.SECURITY
/ADD
6 HOW LONG DID YOU LIVE IN THE PLACE WHERE YOU WERE BORN?
7 //
/KEEP
/EXIT
If you must delete a question from the file, do:
:EDITOR
/TEXT QUESTION.DATA.SECURITY
/REPLACE 6
6 HOW LONG DID YOU LIVE IN THE PLACE WHERE YOU WERE BORN?
6 DELETED << you type >>
/KEEP
/EXIT
Again, NEVER execute an actual DELETE command!
You may want to have only ONE question in the file--this question will be the
only one asked at logon time. Therefore, if you would like to use an MPE-like
password rather than personal profile questions, you can have the one question
in the file be
Enter USER password:
which looks just like
MPE's password prompt; but don't forget that the passwords in SECURITY/3000's
Logon Security System, unlike MPE passwords, are stored in one-way encrypted
format.
If the QUESTION file is empty (zero records, not just only 'DELETED' records),
no questions will be asked at logon time; this is useful in case you do not
want SECURITY/3000's personal profile questions, but only its other features.
Remember that you can impose the questions on only selected users by answering
'N' to the "Should the user be asked personal profile questions?" prompt when
you ADD the user.
NOTE: The maximum number of questions is 30.
ACCESSING THE USER PROFILE DATA BASE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Information about all the users you have authorized in the Logon Security
System (i.e. answers, permitted terminal numbers, permitted times of day/days
of week, real user names, etc.) is stored in the IMAGE data base
ANSWER.DATA.SECURITY
To write reports against this data base (e.g. show the user names and the
permitted days of week for all users, sorted by user ID), merely access this
data base with QUERY or any of your programs. Of course, the personal profile
answers are one-way encrypted, and therefore cannot be determined.
Note that you can open the data base through QUERY in READ mode only! Also,
as an added security feature, you may change the data base password (as
follows) and SECURITY/3000 will still be able to (magically!) access the data
base:
:HELLO MANAGER.SECURITY,DATA
:RUN DBUTIL.PUB.SYS
>>SET ANSWER PASSWORD 1=password
>>EXIT
CONCLUSION: PART 1
~~~~~~~~~~~~~~~~~~~
That's it for the particulars on how the LOGON portion of SECURITY/3000
works. In Part 2, I will discuss various utilities and security logs
associated with SECURITY/3000.
Back to the master Table of Contents.