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.
Go to Adager's index of technical papers