84-10-15 Securing Tandem Systems Previous screen Jeffrey L. Ott Payoff Tandem computers are the systems of choice for online transaction processing in institutions worldwide. This article provides detailed guidance for securing Tandem systems, focusing on Tandem's NonStop Guardian security and the Tandem-developed security application, Safeguard.
Introduction Tandem computers are employed extensively in heavy volume, OnLine Transaction Processing environments. Tandem systems can be found in 24 of the top 25 US banks; 32 of the top 50 European banks; 250 brokerage and security firms; 60 major insurance companies; and in 40of the world s busiest stock and commodities exchanges. Tandem computers run 75% of all automated teller machine transactions, 66% of all worldwide credit card transactions, and 50% of all public E-mail systems. Despite this large presence in computing environments worldwide, Tandem computers are as yet enigmatic to information security practitioners and information systems auditors. This is primarily because Tandem systems are designed with fault tolerance, low maintenance, and low overhead in mind. In many large financial institutions, only two employees provide Tandem system administration and management (i.e., perform operating system upgrades, capacity planning and tuning, and other related maintenance tasks). Compare this with the number of people generally required to support a large mainframe and it is obvious why the Tandem system is often forgotten until something specific is required of it. Tandem Computers, Inc., which developed its first fault tolerant computer in 1976, is also partially responsible for the lack of security awareness on its systems. Safeguard, the Tandem's security application, is the only security application used with the system. It was not until the company's recent D30 release of the NonStop Kernel—Tandem s operating system—and Safeguard, that Tandem pursued certification of its security environment with the National Computer Security Center (NCSC). Although Tandem's security environment does not provide the controls and granularity of more established and refined security packages, such as CA-ACF2 and RACF, it is possible to secure a Tandem system. This article addresses the various components of Tandem security, focusing on basic NonStop Guardian security, Safeguard security, and the interaction between the two. In addition, the chapter provides suggestions for minimizing risk and improving administration in a Tandem system.
Tandem Architecture Basics Organizations choose Tandem computers for their OnLine Transaction Processing because of Tandem s proven fault tolerance, which is achieved through an integrated hardware and software design. All of the critical system components are mirrored, or duplicated. Tandem computers provide redundant power supplies, buses, I/O channels and disk drives—all for establishing a backup path in case the primary path is unavailable. The NonStop Kernel and fault tolerant software are written to recognize and use these alternate routing and backup paths. Tandem developed the Mackie Diagram as an aid for visualizing the layout of a system. Exhibit 1 illustrates a Mackie Diagram of a rudimentary Tandem system. Tandem systems are typically composed of two to 16 Central Processing Unit. As illustrated in Exhibit 1, CPUs numbering begins with Central Processing Unit 0 and follows from there. Each CPUs operates independently of, and cooperatively with, the other CPUs in the system. Previous screen This enables a multiple-CPU Tandem system to survive and continue processing should one or more of the CPUs fail. A high-speed interprocessor bus (IPB) connects each CPUs to the system. The bus handles the communications between each CPUs in the system, but does not handle communications between separate Tandem systems. There are two channels on the IPB—the X-channel and the Y-channel—and each has its own controller. If one of these buses were to fail or otherwise become unavailable, the remaining channel would ensure the continued processing of the system. I/O channels extend from each CPUs and are connected to dual-ported controller devices. The dual-ported controllers are accessible from one of two CPUs. Tandem disk drives are mirrored in that for every logical disk, there are two physical disk drives on the system, the primary and the mirror. A drive is generally referred to by its logical name and no distinction is made between the primary and the mirrored drive. A drive does not need to be mirrored; in fact, some organizations place nonessential data, such as test systems and data, on “broken mirrored” drives. However, should the drive fail, all data on that drive is at risk of being lost. Disk drives are also dual-ported, enabling data to be routed to that drive through one of two controllers. As illustrated in Exhibit 1, data destined for the volume $SYSTEM disk can take any one of four possible routes to reach the drive.
Mackie Diagram of a Basic NonStop System
Importantly, controllers do not necessarily need to be connected to two adjacent CPUs, as the controllers for the $SYSTEM disk drives are in Exhibit 1. Instead, to achieve maximum performance and load balancing, controllers can be connected between any two CPUs, as illustrated in the ASYNC controller connections.
Tandem Naming Conventions The following sections outline the naming conventions for Tandem systems. Diskfile Naming. The Tandem file-naming convention is analogous to the DOS PC naming convention. Tandem volumes are analogous to PC drives; Tandem subvolumes are analogous to PC directories; and Tandem diskfiles are analogous to PC files. The Tandem system can have many volumes. On each volume, there are multiple subvolumes and, in each subvolume, there can be many diskfiles. A subvolume, however, cannot contain another subvolume. Volume names are preceded by a $ and are followed by a drive name of up to eight alphanumeric characters (e.g., $SYSTEM, $DATA01, or $AUDIT). Subvolume names are preceded by their respective volume name and can also be up to eight alphanumeric characters in length (e.g., $SYSTEM.SYSTEM,$DATA01.PRODDATA, $AUDIT.SAFE). Diskfile names also contain up to eight alphanumeric characters. A fully qualified filename will include the system name of the system that it resides on. The system name is placed before the volume designation and is preceded by a \. The system name is optional and is only required when referencing files outside of the current system. Examples of a fully qualified filename are: \NY.$SYSTEM.SYSTEM.USERID, \TEST.$DATA01.PRODDATA.USERS, and \AK1.$AUDIT.SAFE.A0000001. A properly constructed diskfile name will reference in this manner: \system.$volume.subvolume.filename. User Naming. Previous screen The Tandem naming convention for users is based on user groups and the users within the group. Names are viewed either by the numeric representation of
Understanding Nonstop Guardian Security Tandem takes a three-tiered approach to security in its NonStop Guardian application: authentication, authorization, and auditing. Each of these tiers is discussed in the following sections.
Authentication Authentication is the process in which users' requests for access are evaluated by the system. Tandem's screening process is based on a user hierarchy that groups users by job function and by the operations that the specific groups are authorized to perform. User Hierarchy. The Tandem user structure is hierarchical in design. The user ID 255,255is always placed at the top of the structure of any Tandem system. On most systems, this ID is called SUPER.SUPER. It is possible to change the name, but it is not possible to change the unique user ID of 255,255. Generically, this ID is referred to as the Super ID, and it is the ultimate ID on any Tandem system. Because it can perform any action on any object on the system, the Super ID is highly sensitive and its password must be protected. Group Managers form the next tier of the hierarchy. Group Managers have a subset of Previous screen the capabilities of the Super ID. Their range of influence is limited to the objects owned by users in their own groups. Within each group are the group members. Group members have the capability to perform many activities on the system, most of which are limited to objects owned by themselves. A special group, generally referred to as the Super Group (255,n) have special capabilities as determined by the group number. This group should be limited to the system operators, because they are capable of performing sensitive system operations (e.g., altering device states and Central Processing Unit). At the bottom of the Tandem user hierarchy is the user ID 0,0, generally referred to as NULL.NULL. A Tandem system is delivered with only two IDs: 255,255 and 0,0. Whereas SUPER.SUPER has all of the power on a Tandem system, NULL.NULLhas only those powers of the general user. However, NULL.NULLdoes have the ability to stop processes from running as 0,0, such as Tandem Advanced Control Language (TACL) sessions that are not logged in. Exhibit 2 outlines the capabilities of each user group on a Tandem system.
Default User Capabilities
User Type User id User Capabilities General User n,n (where n can be any *Log onto the system at any number from 0-254) TACL prompt. *Display system and user status. *Assign and change own passwords. *Create, rename, delete, and manage own files and programs. *Set security of own files. *Create subvolumes. *Display users on the system by using the USERS command in TACL. *Set the PROGID flag of files. *Run, stop, or debug own processes. *Set remote password. *List contents of any volume or subvolume on the system. Group Manager n,255 *Has capabilities of a General User. *Add and delete users within own group. *Log onto any user within own group without knowing the password. *Set the PROGID flag of any file owned by own group's member. SUPER Group 255,n *Capabilities of a General User. *Monitor CPU use. *Reload CPU s. *Alter I/O paths in the system. *Bring up or take down devices. SUPER.SUPER (Super ID) 255,255 *Highest level user on any Tandem system. *Unlimited access to all system resources. *Perform the function of any other user on the system. *Add and delete user groups. *Add and delete any user. *Start, stop, or debug any process on the system. *Start, stop, or debug any privileged program. *Set or remove the License attribute of any program using privileged code. *Set the PROGID flag on any program. *Log on as any user without knowing user's password. *Can read, write, execute, or purge any file. Previous screen *Change the file attributes of any file or program on the system.
User Type User id User Capabilities ------General User n,n (where n * Log onto the system at any TACL prompt. can be any * Display system and user status. number from * Assign and change own passwords. 0-254) * Create, rename, delete, and manage own files and programs. * Set security of own files. * Create subvolumes. * Display users on the system by using the USERS command in TACL. * Set the PROGID flag of files. * Run, stop, or debug own processes. * Set remote password. * List contents of any volume or subvolume on the system. Group Manager n,255 * Has capabilities of a General User. * Add and delete users within own group. * Log onto any user within own group without knowing the password. * Set the PROGID flag of any file owned by own group's member. SUPER Group 255,n * Capabilities of a General User. * Monitor CPU use. * Reload CPU's. * Alter I/O paths in the system. * Bring up or take down devices. SUPER.SUPER 255,255 * Highest level on any Tandem system. (Super ID) * Unlimited access to all system resources. * Perform the function of any other user on the system. * Add and delete user groups. * Add and delete any user. * Start, stop, or debug any process on the system. * Start, stop, or debut any privileged program. * Set or remove the License attribute of any program using privileged code. * Set the PROGID flag on any program. * Log on as any user without knowing user's password. * Can read, write, execute, or purge any file. * Change the file attributes of any file or program on the system.
Network Users. Users on a Tandem system are identified as being either local or network. A network user is one who has started a terminal session on one system and is attempting to access objects on another. A network user must be authorized for remote access to a system. To achieve this authorization, identical user name and user IDs must be established on the local and remote systems, and remote passwords must be employed. For example, if user AUDIT.BOB 10,34 on system \NYC needs to access system \LOND, user ID AUDIT.BOB 10,34 must be set up on the remote \LOND system. This process requires a coordinated effort between the system administrators for both systems and provides a limited amount of security if the system administrator on \NYC does not have the ability to add users to the system \LOND. If the user ID 10,34 on \LOND was already assigned to PROD.USER22, the Previous screen request could not be completed. User names and IDs must be identical on both systems. Remote passwords are static: once set, they rarely change. Remote passwords are used to grant the authority for one-way or two-way access between systems. Generally, remote passwords are assigned by the ID of the user (e.g., either a Group Manager or Super ID in Guardian security). Because most users who request access to remote systems want to create, read, and write files on those systems, the systems are provided with two-way access. Remote passwords are established using the RPASSWORDutility. Assuming that the user name and ID are identical on both systems, the local administrator will add remote passwords for the system that the user wishes to access. At the same time, the remote administrator will add the identical remote passwords on the second system. The user is usually unaware of these steps, because remote passwords are transparent to the user and are used by the systems to determine whether to grant access to the remote system. Passwords. Password controls are very limited on Tandem systems that do not have Tandem's Safeguard security application. In fact, there are no password controls on a native NonStop Guardian system, unless special efforts are made to create them. The password controls available in NonStop Guardian and Safeguard are compared in Exhibit 3. Passwords that are used with NonStop Guardian can be up to eight characters in length, are case sensitive, and can be any combination of letters or characters, including special and nonprinting characters.
Comparison of NonStop Guardian and Safeguard Password Controls
Password Control NonStop Guardian Safeguard Password required No Yes Password history maintained No Yes Password expiration No Yes Password expiration grace No Yes period Password expiration warning No Yes message Remote password Yes Yes authentication Password change during logon No Yes Blind password entry No (Can be forced through Yes modification of the PASSWORD program) Minimum password length No (Can be forced through Yes enforcement modification of the PASSWORD program) Password file encryption No (Can be forced through Yes modification of the PASSWORD program) Verify old password before No Can be forced through Yes change modification of the PASSWORD program) Password Control NonStop Guardian Safeguard ------Previous screen Password required No Yes Password history maintained No Yes Password expiration No Yes Password expiration grace period No Yes Password expiration warning message No Yes Remote password authentication Yes Yes Password change during logon No Yes Blind password entry No (Can be forced through modification of the PASSWORD program) Yes Minimum password length enforcement No (Can be forced through modification of the PASSWORD program) Yes Password file encryption No (Can be forced through modification of the PASSWORD program) Yes Verify old password before change No (Can be forced through modification of the PASSWORD program) Yes
In earlier releases of the NonStop Kernel, Tandem supplied the patch variables for the PASSWORD program to force some password controls. The final four control options in Exhibit 3 refer to these patch variables. However, Tandem no longer supports this practice. Manual patches to programs such as PASSWORD are dependent on internal program variable names that remain consistent through operating system updates and program changes. Moreover, because these are manual changes, each time there is a SYSGEN or operating system update, patches must be reapplied to the problematic program. This is neither the safest nor the best implementation of security. Tandem encourages the implementation of Safeguard rather than the use of manual patches. User names, user IDs, passwords, remote passwords, default file security settings, and user default volume and subvolume information are kept in the $SYSTEM.SYSTEM.USERID file. This critical file can be found on any Tandem system. It is one of the first files that is attacked when someone is attempting to gain unauthorized access to the system. If the patch to the PASSWORD program has not been applied, it is possible for someone with read authority to the USERID file to read the password of every user on the system. TACL. The primary command interpreter on a Tandem system is Tandem Advanced Control Language (TACL). Users log onto a system at a TACL prompt by using either a user name (e.g., SECURE.SAM) or a user ID (e.g., 30,101). One of the tasks that TACL performs is user verification at logon. When user SECURE.SAM logs onto the system using the password Rockies, the TACL LOGON command issues a VERIFYUSER call. VERIFYUSER examines the $SYSTEM.SYSTEM.USERID first to determine if the logon attempt is being performed by a valid user ID. If the user ID is valid, VERIFYUSER verifies the password. The user is allowed three attempts to enter the correct password before TACL suspends the terminal session for 60 seconds. After every unsuccessful logon attempt to follow, the Previous screen terminal will be suspended for 60 seconds. This process will continue until a successful logon has been completed. Once VERIFYUSER authenticates the logon attempt, the user s TACL session begins and access to the system is granted. Similar to the PASSWORD program, TACL can be manually patched by using the BIND program to provide additional security to NonStop systems. BIND options must be manually applied each time there is an update to the operating system. Exhibit 4 illustrates the controls that may be implemented by applying patches to the TACL program. It is important that security professionals remember, however, that these patches are not encouraged by Tandem.
Security Variables for Internal TACL Program Parameters
TACL Parameter Description Default Setting AUTOLOGOFFDELAY Determines the number of -1 minutes an idle TACL session will wait until it automatically logs off. BLINDLOGON If enabled by the value of 1, 0 requires passwords to be entered on a separate line than the logon id. This prevents passwords from being typed in the clear. (Note: This also prohibits the use of embedding passwords in script files, which is good for security and may be required by poorly designed operating procedures.) CMONREQUIRED If enabled by the value of 1, 0 all processes requiring the local system s $CMON approval will fail if $CMON is unavailable or running slowly. CMONTIMEOUT Specifies the number of 30 seconds TACL should wait for a local$CMON process. NAMELOGON If enabled by the value of 1, 0 the logon process will only accept the user name (i.e., ACCTNG.FRED) and not the user ID (i.e., 45,77) during the login process. Since every Tandem system uses the same user hierarchy and numbering scheme, this prevents someone from using the user ID (ie: 255,255) for an attack. NOCHANGEUSER If enabled by the value of 1, 0 forces users to log off before logging in with another user ID. REMOTECMONREQUIRED Similar to 30 Previous screen CMONREQUIRED, but applicable to remote systems. All operations requiring the remote $CMON approval will fail if the remote system s $CMON is unavailable or running slowly. REMOTECMONTIMEOUT Specifies the number of 30 seconds TACL should wait for a remote $CMON process. REMOTESUPERID A value of 0 will prevent a -1 TACL session started by a remote user from logging on as the Super ID (255,255). TACL Parameter Description Default Setting ------Previous screen AUTOLOGOFFDELAY Determines the number of minutes an idle TACL session will wait until it automatically logs off. -1
BLINDLOGON If enabled by the value of 1, requires passwordsto be entered on a separate line than the logon id. This prevents passwords from being typed in the clear. (Note: This also prohibits the use of embedding passwords in script files, which is good for security and may be required by poorly designed operating procedures.) 0
CMONREQUIRED If enabled by the value of 1, all processes requiring the local system's $CMON approval will fail if $CMON is unavailable or running slowly. 0
CMONTIMEOUT Specifies the number of seconds TACL should wait for a local $CMON process. 30
NAMELOGON If enabled by the value of 1, the logon process will only accept the user name (i.e., ACCTNG.FRED) and not the user ID (i.e., 45,77) during the login process. Since every Tandem system uses the same user hierarchy and numbering scheme, this prevents someone from using the user ID (ie: 255,255) for an attack. 0
NOCHANGEUSER If enabled by the value of 1, forces users to log off before logging in with another user ID. 0
REMOTECMONREQUIRED Similar to CMONREQUIRED, but applicable to remote systems. All operations requiring the remote $CMON approval will fail if the remote system s $CMON is unavailable or running slowly. 30
REMOTECMONTIMEOUT Specifies the number of seconds TACL should wait for a remote $CMON process. 30
REMOTESUPERID A value of 0 will prevent a TACL session started by a remote user from logging on as the Super ID (255,255). -1
Authorization The following sections describe the second tier of security—authorization—in the NonStop Guardian system. Process Protection. NonStop Guardian does not provide security for processes. However, it does have a mechanism for the protection of running processes. When a process is started, it takes on the identity of the user ID that started it. This is called the Creator Accessor ID (CAID). The process is also assigned a second identification by the system, called the Process Accessor ID (PAID). The PAID determines if the process has the authority to perform the function Previous screen that it is attempting (e.g., accessing a diskfile or halting an executing process). Generally, the PAID is the same as the CAID. However, this can be changed through the use of the PROGID file attribute. If the PROGID file attribute is on, the PAID of the new process will take on the identity of the file owner and not that of the CAID. The net effect is that the process will run as the owner of the program and not as the ID that is running the application. This enables the user who is running the program to have access to everything that the program owner would have access to. The PROGID attribute can be set by the owner of the file, the owner s group manager, or the Super ID. The attribute is often used by the system operators to make complete tape backups. Under normal conditions, when the BACKUP program is executed by a system operator, only the files accessible to the system operator s ID will be backed up. However, by setting the PROGID attribute as the Super ID, system operators can bypass this default access and perform a full backup. System operators should follow these steps to do so:
á The owner of the BACKUP program should be set as the Super ID.
á Execute access to the BACKUP program should be granted to the system operator's group, or 255,*.
á The PROGID flag of the BACKUP program should be set.
á The BACKUP program should be executed to back up every file on the system. In the interests of security, the Super ID password should not be widely distributed. Moreover, use of the PROGID attribute should be monitored and restricted in an organization's security policy. Diskfile Security. NonStop Guardian does not provide security at the volume and subvolume levels. However, every Tandem diskfile label contains the owner of the file and the file s security string. This information can be obtained by issuing a FILEINFO command or a FUP INFOcommand. The creator of a file is the initial owner. The initial security string of the file is set as the creator's default security string at the time of creation. The owner of the file has complete control over the files regardless of the security string attributes, as do the owner s group manager and the Super ID. Other users may access the file depending on the attributes of the security string. There are four types of diskfile access: read, write, execute, and purge(RWEP).
á Read. Read access permits a file to be read or copied. If the file is a TACL OBEY file, it can be executed. á Write. Write access permits a file to be modified or its definition to be altered. á Execute. Execute access permits a program file to be executed. á Purge. Purge access permits a file to be deleted or renamed. Each position in the RWEP security string contains one of the seven following codes to determine file access for that position: á Owner (O). Only the owner of the file on the local system can perform the requested Previous screen operation. á User (U). Only the owner of the file on a local or networked system can perform the requested operation. á Group (G). Any member of the owner's group on the local system can perform the requested operation. á Community (C). Any member of the owner's group on a local or networked system can perform the requested operation. á Any (A). Any user on the local system can perform the requested operation. á Network. (N). Any user on the local or networked system can perform the requested operation. á Super ID. Only the Super ID (i.e., 255,255) on the local system can perform the requested operation. A file access request is permitted based on the PAID of the requesting process and on the security codes in the file s security flags. Access is permitted if the PAID matches that of the file owner, the owner s group manager, or the Super ID. Access is also permitted if the file security string contains the appropriate code for the requested action. If, for example, SECURE.SAM 30,101 wants to read a file with the RWEP string “AOGO,” the request will be granted, because read access is granted to A— “Anyone” who is a local user. However, if SECURE.SAM wants to execute the program, he or she will receive an Error 48, indicating a security violation, because SECURE.SAM is not a member of the 255 Group, G.
Auditing NonStop Guardian does not provide auditing of security events, except for messages of system events on the OPERLOG or at the operator s console. However, Tandem has provided the ability to send security related events from TACL sessions to a process named Command Interpreter Monitor Process or $CMON. $CMONis a user-written application that can be designed to monitor and control security related events, and is commonly used for monitoring and controlling the following tasks:
á Logon and log off control (e.g., terminal restrictions, time restrictions, and limiting concurrent TACL sessions). á Process creation. á Process execution priority modifications. á Invalid logon attempts. á Adding users. á Deleting users. á Changing logon or remote passwords. Previous screen Because Tandem supports only the $CMON calls by TACL and does not supply or support the $CMON application, $CMON must be written in-house. It is also available from the International Tandem User s Group (ITUG) tape library. The source code must be modified as needed by an in-house Tandem programmer. Importantly, TACL does not monitor the $CMON process. Therefore, it is possible for someone to write a $CMON process for harvesting logon IDs and passwords or for other malicious intents.
Tandem Safeguard Security Tandem's Safeguard application is an extension to the NonStop Kernel operating system. When Safeguard is running, all user authentication, diskfile, process, and other object authorization is handled either by Safeguard or in conjunction with Safeguard. Some system utilities will respond differently when Safeguard is running. Safeguard provides many security features to the NonStop Kernel security that are necessary for today s data processing environments. Safeguard can be installed as a standalone process or as part of the operating system in a SYSGEN. As a standalone process, Safeguard must be started manually at a terminal or through a startup OBEY file. It can be stopped by the Super ID. When Safeguard is started as part of the operating system, it comes up with the system and cannot be stopped without bringing down the entire system. This implementation of Safeguard ensures that Safeguard will always be running and helps to provide the highest level of security. Safeguard provides object-oriented security, which places the security at the object to be protected. There are ten Tandem object types: á Device. á Subdevice. á Diskfile. á Object type. á Process. á Subprocess. á Subvolume.
á User. á Volume. á Terminal. Security is defined at each protected system object through the use of a Protection Record and an Access Control List (ACL). ACLs look and work the same, regardless of what object they are protecting. Because most ACLs work is performed at the diskfile level, an in-depth discussion of ACLs will be presented in the diskfile section. Safeguard is not simply a large, omnipotent application; it is the close integration of the following eight components: á SAFECOM. This is the user interface, or the command interpreter, to the Security Previous screen Management Process (SMP). á Security Management Process (SMP).
á Runs as the $ZSMP process pair.
á Starts SMON processes. á Restarts SMON process on a failed and reloaded Central Processing Unit. á Manages changes to the Safeguard subject and object data base. á Manages user authentication. á Coordinates overall Safeguard processing. á Handles and processes Safeguard commands. á Creates audit records of attempts to access the subject and object data bases. á Security Monitor (SMON). á Manages all attempts to access protected objects.
á A separate SMON process is started in each CPUs.
á SMON processes are named $Zsnn where “nn” is the CPUs number. For example, $ZS00 runs in CPUs 0 and $ZS01 runs in CPUs 1. á Handles all authorization for object access controlled by I/O processes running in its CPUs. á Handles all authorization for processes with Safeguard protected process names running in its CPUs. á Creates audit records of attempts to access the objects under its protection.
á System Files.
á $SYSTEM.SYSnn.OSMP.
á $SYSTEM.SYSnn.OSMON.
á $SYSTEM.SYSnn.SAFECOM.
á $SYSTEM.SYSnn.PASSWORD.
á $SYSTEM.SYSnn.LOGON.
á $SYSTEM.SYSnn.SAFEACT.
á $SYSTEM.SYSnnX.SAFEART. á Configuration Data Bases. Previous screen á $SYSTEM.SAFE.CONFIG (Safeguard configuration information).
á $SYSTEM.SAFE.CONFIGA (Audit configuration information and terminal definition records).
á $SYSTEM.SAFE.OTHER (Authorization records for all objects other than disk) á Subject Data Base.
á $SYSTEM.SYSTEM.USERID.
á $SYSTEM.SYSTEM.USERIDAK.
Object Data Base: $
Safeguard User Management When Safeguard is started, one of the first things that it does is take over the USERID file. All user management should be performed through Safeguard; therefore, the programs ADDUSER, DELUSERand RPASSWORD should either be removed or secured so that they cannot be used. Unless Safeguard is configured otherwise, users can still be managed by either the Super ID or by the users' group managers. Each user record has configurable attributes associated with it, including the owner, password expiration date, password change and expiration specifications, and auditing requirements. A user's information listing can be viewed by issuing an INFO USER Safeguard command. Exhibit 5 is an example of a Safeguard user information listing.
Safeguard User Information Listing
User authentication is greatly enhanced by Safeguard. Users can be restricted to specific terminals, password histories can be maintained, passwords can be expired, and users can be suspended (i.e., FROZEN)and unsuspended (i.e., THAWED). When Safeguard is running, TACL allows Safeguard to authenticate the users. This enhances the users' abilities to manage their own passwords with the use of password expiration messages and password expiration grace periods. Super ID Control. With Safeguard, it is possible to invoke DENY access for the Super ID. By using object ACLs and other controls, it is possible to minimize the excessive use of the Super ID that often occurs with Tandem systems. However, because many organizations have designed their systems to rely on the frequent use of the Super ID, they are uncomfortable with the possibility of the Super ID being denied. In answer, Tandem designed the option for making the Super ID undeniable. Entering SUPER_SUPER_IS_UNDENIABLE in the ALLPROCESSORS paragraph of the SYStem GENeration configuration file will allow the Previous screen Super ID to access any system object regardless of any explicit denies in an ACLs.
Safeguard Diskfile Security The mechanics of Safeguard process and device security are the same as those for diskfile security; however, diskfile security is more dynamic. A security administrator may have to handle file access requests from other departments frequently, whereas once a device or process ACLs is set, it will rarely require modification. A security administrator who understands the process of establishing diskfile security can apply this knowledge for the analysis of process and device security. Diskfile authorization can be affected by ACLs at the volume, subvolume, or the file levels. It is also affected by two global Safeguard parameters: DIRECTION-DISKFILE and COMBINATION-DISKFILE. Diskfile Access Control Lists. If a diskfile is directly protected by an ACLs, the FILEINFO will show **** where the Guardian security flags were once shown. However, a file may be protected by Safeguard at the volume or subvolume level even if the file is not, and Safeguard would still handle the authorization. A diskfile is protected by NonStop Guardian security until it is placed under Safeguard's control by the file owner. The file owner employs the ADD DISKFILE command to make this transfer. Safeguard establishes an ACLs for the diskfile and, from that moment on, only the owner can access the file. If the file is open when security is transferred to Safeguard (e.g., an application data file), Safeguard will not take control of the file until after the file is closed and reopened. An ACLs is an access matrix. The ACLs lists which users can access the object and with what authority. To view a diskfile s ACLs, the security administrator should enter INFO DISKFILE (filename). An ACLs is always listed by ascending user ID, and from specific reference to general reference, in the following order: á Local users (e.g., 30,254). á Network users (e.g., \LOND.30,254). á Local groups (e.g., 30,*).
á Network groups (e.g., \LOND.30*). á Every local user (e.g., *.*). á Every networked user (e.g., \LOND.*.*). Although there can be a maximum of 50 entries in an ACLs, the number of individual entries should be minimized through the use of groups. Large ACLs are difficult to manage and maintain. The security administrator should limit the use of individual user IDs in ACLs to the specifications of the overall security policy. An individual user may be referenced in one or more ACLs entries. For an access to be permitted, all requested access rights must be permitted in the same ACLs entry. Because of this restriction, a careful analysis of user access requirements must be made before ACLs entries are made. It may be necessary to deny an access at the individual level of a right granted at the group level. This is made possible with the DENY entry. For example, although the group 130,* is permitted access to a file, a request might be made to limit user 130,1 to read-only access. When all other access rights are denied (i.e., W,E,P,C, and O), Previous screen user ID 130,1can only read the file. An analysis of user access requirements should not stop here. Final authorization to the file must also take into account the security at the volume and subvolume level. In total, the final authorization may take into account up to three different and possibly conflicting ACLs. By default, Safeguard only checks for ACLs at the diskfile level, as determined by the Safeguard global parameters CHECK-VOLUME and CHECK-SUBVOLUME.A Tandem system with nothing but diskfile-level security can be difficult to administer. Therefore, it is best to provide security at the volume and subvolume levels as well. ACLs at the volume and subvolume level look the same as those at the diskfile level, with a few exceptions. When access is being permitted in up to three different locations, there can be conflicting and confusing results. Tandem eliminates this with the global parameters DIRECTION- DISKFILE and COMBINATION-DISKFILE. DIRECTION-DISKFILE. This parameter sets the direction in which Safeguard searches for access rights. Options for this parameter are VOLUME-FIRSTand FILENAME-FIRST. If the setting is VOLUME-FIRST, Safeguard begins the ACLs search at the volume level, then moves to the subvolume level and, lastly, searches at the diskfile level. The FILENAME-FIRST setting reverses this process, forcing Safeguard to search for ACLs in the order of diskfile, subvolume, and volume. At each ACLs level, Safeguard has four possible intermediate answers relative to granting or denying access: á Yes (Y). á No (N). á No Mention (NM). This answer appears if the ACLs contains no reference to the requesting user ID. á No Record (NR). This answer appears if there is no ACLs at that level. These are considered intermediate answers, because final authorization is subject to the COMBINATION-DISKFILE parameter. COMBINATION-DISKFILE. This parameter defines the manner in which conflicting ACLs are resolved. The settings for COMBINATION-DISKFILE are: á FIRST-RULE. Safeguard uses the first ACLs that contains the specified user ID. á FIRST-ACL. Safeguard uses the first ACLs it finds and stops its search. á ALL. Safeguard uses all available ACLs and access must be permitted by ACLs at all levels. To assist the security administrator in establishing the appropriate access rights, Tandem developed a matrix called the diskfile access determination table. To illustrate how the table is used, the following Safeguard global parameters and specifications may be applied to an example: á DIRECTION-DISKFILE = FILENAME-FIRST. Previous screen á COMBINATION-DISKFILEM = FIRST-RULE.
á CHECK-VOLUME = On.
á CHECK-SUBVOLUME = On.
á CHECK-FILENAME = On.
á The volume ACLs reads: *.* R.
á The subvolume ACLs reads: 30,* R,W,E,P; 40,* R,W.
á The diskfile ACLs reads: 40,1 E. If user ID 203,56 wanted to read the file in this example, Safeguard would evaluate the access in the following way. Because the DIRECTION-DISKFILE is set at FILENAME-FIRST, the first level evaluation would return a NM, because there is no mention of user ID 203,56 in the ACLs at the diskfile level. The second level, the subvolume, would evaluate a NMfor the same reason. The third level, the volume, grants every local user(i.e., *,*) read access and evaluates to Y. The determination results of NM, NM, Y point the security administrator to a corresponding row of the diskfile access determination table. The FIRST-RULE of this row designates a permit, and thereby grants user 203,56 read-access to the file. In another example, a diskfile not directly protected by an ACLs will result in a FILEINFO that contains the following results: á File Owner: 255,255 (i.e., the Super ID). á NonStop Security Flags: “————” This indicates that only the Super ID can read, write, execute, or purge the file.
á The subvolume ACLs reads: 030,*E,P.
á The volume ACLs reads: *.*R. Using the same global parameters as in the first example, Safeguard would authorize a request by user ID 30,21 to execute this program. If the security administrator or the Super ID had looked only at the diskfile level, and had seen the security flags in the FILEINFO, it would have appeared that the application could only be executed by the Super ID. Again, the security administrator must look at all levels to determine the final outcome of the authorization request. The first level is at the file level, because DIRECTION-DISKFILE is set at FILENAME-FIRST. This first level evaluates to NR, because there is no ACLs present. The second level, subvolume, evaluates to Y, because the user 30,21 is referenced in the group authorization that permits execute and purge. The third level, volume, evaluates to N, because the ACLs entry states that only local users are restricted to read- only access. The evaluation returns of NR,Y,N would then be referenced in the corresponding row of the matrix. The row would show that the FIRST-RULE permits user ID 30,21 to execute the program. The security administrator must have a thorough understanding of all of the factors that influence access authorization before making any changes to diskfile (i.e., volume and subvolume) security. Results may not appear as expected, which can potentially cause system outages and downtime. The security administrator should never change Safeguard global parameters without a careful and thorough analysis of the implications of such Previous screen changes to existing security.
Safeguard Auditing Safeguard greatly improves the auditing of security related events. Auditing can be set at the global level, the user level, and the object level. By default, nothing is audited except for the following events, which are always audited: á The starting and stopping of Safeguard.
á ALTER Safeguard configuration commands. á Modification of the audit service. á Audit service events, including add or alter audit pool; audit rollover; and audit service NEXT and RELEASE commands. á Add or modification of Safeguard protected terminals.
á Sensitive commands in PUP, TMF, and TAPECOM.
á Volume BACKUP and RESTOREcommands. Auditing Attributes. The following attributes can be set either at the global level or on individual user or object records.
á AUDIT-ACCESS-PASS. This attribute is set for successful attempts to log onto the system or to access an object.
á AUDIT-ACCESS-FAIL. This attribute is set for unsuccessful attempts to log onto the system or access an object.
á AUDIT-MANAGE-PASS. This attribute is set for successful attempts to manage (i.e., add, modify, read, or delete) a protection record.
á AUDIT-MANAGE-FAIL. This attribute is set for unsuccessful attempts to manage (i.e., add, modify, read, or delete) a protection record. Each audit attribute includes an additional specification that can help focus event auditing:
á NONE: No attempts are audited. This is the default setting.
á ALL: All attempts are audited.
á LOCAL: Only local attempts are audited.
á REMOTE: Only remote attempts are audited. Safeguard audit trails consist of one or more audit pools. An audit pool is a subvolume containing audit files. Initially, the first audit pool resides in $SYSTEM.SAFE, but it is often moved to another volume to limit contention on the $SYSTEM volume. Audit files are Previous screen named A000000n, where “n” is the file sequence in the audit pool. Tandem does not provide an audit reporting program for reviewing the audit trail. An in-house program must be written or a third party reporting package must be purchased to generate audit reports. Two packages that are widely used by Tandem security administrators for producing audit reports are AuditView, by Computer Security Products of Missassauga, Ontario, and Safeguard Reports Plus, by Software Professionals of San Mateo, California.
D30 Considerations In the D30 NonStop Kernel release, Tandem's Safeguard offers valuable new tools for the security administrator. Two of these new features, the user alias ID and Warn Mode, are highlighted here. One of the greatest problems for security administrators on a Tandem system is the use of shared IDs. In most Tandem environments, several people have access to the Super ID password and use it frequently. Some applications require the use of one ID to start, manage, and stop them. The use of shared IDs eliminates accountability and makes it difficult to determine which one of, for example, twelve operators, over a three-shift day, used the ID to perform any one action. Tandem s release of the D30 NonStop Kernel and Safeguard introduces the alias user to combat this confusion. Tandem developed the user alias option to provide a generic user name that can be applied to other platforms that may exist at a customer s site, thereby reducing the number of logon IDs a user may have to remember. This new feature allows a single user to log onto all of the different platforms by using a common user name. For example, a user's CA-ACF2ID may be SLSS004 and his or her Tandem ID may be CIS.SLSS004. The alias option allows this user to log onto the Tandem system using their CA-ACF2 ID, SLSS004. Historically, users of the Super ID have had to share the Super ID password, and have often employed elaborate schemes to both protect the password and communicate password changes to others. Added to this problem was the lack of individual accountability. Even in detailed audit reports, it was impossible to determine who was using the Super ID at any given time. Now, through the use of aliases, users who need access to the capabilities of the Super ID can be assigned a Super ID alias. After the alias has been assigned, the Super ID itself can be frozen. The use of aliases addresses two long-standing security problems on Tandem systems. First, it enhances individual accountability of the users of the Super ID and of other sensitive IDs. Second, it reduces the possibility of direct attacks on the user ID 255,255, or SUPER.SUPER.Because the Super ID and its user ID (i.e., 255,255) are system defaults that are issued on all Tandem systems, they are the first target of direct assaults. If alias naming conventions are properly established, an assault against the Super ID aliases would be extremely difficult. Aliases should be used wherever there are shared IDs on the Tandem system. Another new Safeguard feature in the D30 release is Warn Mode. In the previous implementations of Safeguard, once an ACLs was placed on an object, the ruling based on the ACLs was immediately enforced until the ACLs was removed or frozen. With Warn Mode, ACLs can be defined for objects but not enforced. In addition, an access that would have been denied if the ACLs ruling had been enforced is permitted, and the action can be audited. This allows security administrators to monitor specific situations and to determine if their ACLs are properly implementing the intended security policy. The warning mode is available at the system level only, and not on a per-object basis. Because Warn Mode cannot be issued on an object-by-object basis, this option should only be used for a short period of time and on a limited basis. For example, the warning mode could be used during major security configuration changes. In this example, Safeguard would be placed in Warn Mode. After the security administrator made changes Previous screen to object ACLs, the audit trail could be monitored during a critical period of time, such as when the primary application is started. By reviewing the audit trail for access warning messages, the information security department could determine any mistakes in an object s ACLs and make any necessary corrections. This procedure would eliminate any potential application downtime due to errors made by the information security department and, at the same time, provide a reasonable measure of security through the auditing of ACLs activity. Companies have been slow in moving to the D30 release of the NonStop Kernel. However, from a security standpoint, the move to D30 should be a high priority for the information security administrator responsible for the Tandem environment.
Conclusion Tandem computers often run the most critical applications for an organization, yet they are provided far fewer resources (i.e., personnel and funding) than any other platform. Financial institutions that transfer billions of dollars through their wire transfer systems daily leave their Tandem systems with no security (i.e., Safeguard is not installed) or false security (i.e, Safeguard is installed but not implemented). It cannot be overemphasized that Tandem's Safeguard is the only means of achieving an acceptable level of security on a Tandem computer. As with any computer security, a significant amount of analysis and understanding must be undertaken before significant changes are implemented in a Tandem system. If due care is not taken for these purposes, the system could be exposed to attacks or system downtime. Proper training must be given to those responsible for implementing or administering security, and these personnel must add to that training hands-on system time to become familiar with system tools and utilities. If this is not possible, it is appropriate to bring in outside experts to review, implement, and maintain the security of the system. With Safeguard, Tandem has provided a security extension to the NonStop Kernel that provides authentication, authorization, and accountability that is strong enough to have received a NCSC classification of C2. With proper and careful analysis, a Tandem computer system can be secured to a level that is commensurate with the sensitive nature of the processing that it performs. Author Biographies Jeffrey L. Ott Jeffrey L. Ott is a Partner at Available & Secured Knowledge (ASK) Consulting, LLC, in Berthoud, Colorado.