What Security Is Available for Tandem Guardian 90?

Background

The Tandem Non-Stop system based on the Guardian 90 operating system is a unique processing environment that is different from IBM MVS and DEC VAX/VMS environments due to its fault-tolerant capabilities. This fault-tolerant operation, is accomplished through redundant hardware, backup power supplies, alternate data paths and bus paths, alternate controllers, and mirrored disks (i.e., writing data to two separate disks).

The operating system contains additional functions which support the fault-tolerant capabilities. The operating system provides both multiprocessing (i.e., parallel processing in separate processors) and multiprogramming (i.e., interleaved processing in one processor). The ability to have multiple independent systems loosely coupled as one network eliminates the risk of a single point of failure. The operating system continuously checks the integrity of the system by ensuring that each of the defined processing modules are active. In the event that a processing module fails, the operating system notifies the system and application processes in order to take the pre-specified action, such as re-routing workloads.

The Tandem NonStop system is made up of multiple processes (i.e., program running on the system) running in a loosely coupled environment.

The Tandem system contains multiple CPUs, each with its own private memory and multiplexed input/output channel. The processor modules communicate with one another over a pair of high-peed interprocess or buses (i.e., Dynabus). Peripheral device controllers are connected to the input/output channel of two processor modules so that the device is accessible even if the CPU fails. The system can be expanded by adding additional processor modules (i.e., up to 16 per system). Through the use of Tandem's Expand software, up to 255 systems can be joined to the network. In addition a fiber optic extension (i.e., FOX), can be used to join systems into a network.

The NonStop hardware architecture and the Guardian 90 operating system architecture prevents a single hardware or software malfunction from disrupting system operations. In this parallel processing architecture, the workload is divided among the processors, which perform multiple tasks simultaneously. This system architecture provides maximum throughput since workloads are routed to the least congested processor.

The purpose of this article is to discuss the security controls provided by the Guardian operating system and recommend control approaches.

Introduction to Tandem Security

Basic Guardian security is included with the product, and provides the user with user authentication controls for logging onto the system and file security, The security functions provided in Guardian works directly with the Guardian operating system so that security calls are not made to an external process. Safeguard is a layered product with a separate callable set of procedures.

The architecture of the hardware plays a significant role on how security functions in a Tandem system. Each processor has its own copy of the Security Reference Monitor (SMON). SMON is the braintrust used in determining when to call Safeguard or Guardian for security validation. The overall Security Reference Monitor (CSNP) runs as a fault tolerant process pair that in contained is two different CPUs (i.e., primary and backup) and is responsible for cooridinating updates across all systems. It also ensures that individual SMONs are functioning.

Guardian's file specification consist of files, subvolumes (i.e., stores a collection of files), and volumes. All programs and data files are referred to as files.

When accessing a file, the volume and subvolume associated with the file must be specified. The syntax of a file specification consists of the following:

$xxxxx.yyyyy.zzzzz
where:
xxxxx is the disk drive on which the file resides
yyyyy is the subvolume on which the files resides
zzzzz is the file name

Tandem provides Tandem Advanced Command Language (TACL) that allows the user to logon onto the system, use commands and utilities, and execute programs.

USERIDs are constructed to assign a user to a specific group. The USERID consists of two identifiers (x,x). The first identifier is used to assign the user to a specific group and the second identifier is used to uniquely identify the user.

Privileged user IDs are as follows:

255,255 is the Super ID

255,n is the Super Group

n,255 is assigned to a group manager

Guardian provides internal security which is set at the file level. Therefore, in order to protect all of the files in a subvolume, each file must be protected individually. Tandem's Safeguard security replaces Guardian's security when defining access entitlements. Safeguard allows for security to be set at the file, subvolume, and volume level.

When using Guardian security, file protection is assigned according to the following type of user that is accessing the file:

- Super ID (local only)

U Owner of the file (local or remote)

C member of owners group (remote or local)

N Any user (remote or local)

O Owner (local)

G member of owner's group (local)

A Any user (local)

Local access is referred to as those users that logon to a terminal that is directly connected to the system. Remote access is referred to as those users that logon onto to a remote system. Remote systems are connected to local systems through an Expand link.

Within a Safeguard Security environment, access can be set on an individual user level or for all users within a group using Access Control Lists (ACLs).

Password Controls

Within a Guardian security environment the Binder utility is used to change the PASSWORD and COMIT programs to provide the following controls over passwords:

encrypt password file

prevent passwords from being typed in clear test

minimum password length in a password

It should be noted that these controls are only available when using TACL and is not available through inhouse written command interpreters or the COMMINT command interpreter that was provided by Tandem in earlier versions of Guardian but is no longer distributed in the the Guardian operating system. In addition, these changes are made by altering a program and cannot be done through a set of panels. The setting can be customized for individual users by defining the user with a TACLCSTM file which is stored in the user's default subvolume. However, since the PASSWORD and COMIT programs must be licensed there is no exposure of a user changing their TACLCSTM file to point to their own unauthorized version. The TACLCSTM file should still be secured from the user and other users since it controls the manner in which the user's TACL process functions.

Terminal timeouts after a site specified period of inactivity is defined as part of installing TACL.

Safeguard provides the same level of password control through its command interpreter, SAFECOM.

Privileged Programs

Utilities or programs that are provided by Tandem will not allow a user to update a file in which they are not provided access entitlements to. However, Tandem provides the ability to attach an authority level to a program in which the program will run under.

Therefore, a user that normally does not have access to a file can be assigned execute access to a program which is allowed to update a specific file.

This process of performing access validation based on the authority assigned to the program instead of the authority assigned to the submitter of the program is referred to as PROG-ID. When using Guardian security, the authority of the program is based on the authority of the user who compiled the program. If the program is changed by a different user, then the authority under which the program will execute will change to the user who last changed the program.

When Safeguard is used, the authority of the program is based upon the owner of the program. This is referred to as the PROG-ID Accessor ID. Licensed programs is another form of a privileged program whereby the program may be coded to execute in supervisor state. Licensed programs bypasses all security checking regardless of whether one is using Guardian or Safeguard as the security system. In order to define a program as a licensed program, it must be enabled by the Super ID

PROG-ID and Licensed programs are normally used to allow unprivileged users to perform pre-defined functions which would otherwise necessitate them to have a privileged ID.

When performing a review of the privileged programs, documentation should be available to identify the purpose of each of these programs. If the program is written to perform a privileged function, users which have been provided execute access should be identified to ensure that only appropriate users have been provided with this ability. In addition, the PROG-ID programs should be reviewed to ensure that the programs are not written to allow the submitter to use TEDIT, TACL, or DEBUG to break out of the program and allow a user to access files that they are not authorized to access except through the pre-defined PROG-ID program that was written.

Privileged IDs

The Super ID is the most privileged ID on the system. It has the ability to access all resources on the system which includes the ability to administer security on the system.

However, as of Safeguard version C20, Safeguard has an option to deny the Super ID's access to specific resources using Access Control Lists (ACLs).

Normally, only Group Managers (n,255) and the Super ID can add users to the system. However, in a Safeguard environment, other users can be designated to perform this function by creating an OBJECTTYPE USER authorization record and assign them CREATE (add users) and/or OWNER (change user ID access) by creating an Access Control List (ACL). Normally, only the Super Group (255,n) can admister access entitlements to an object (e.g., file, subvolume, or disk). However, in a Safeguard environment other users can be designated to add users access entitlements by creating an OBJECTTYPE authorization record and creating an ACL to specify the type of access being granted (i.e., CREATE and/or OWNER). It should be noted transferring security administration responsibility is for all objects within the object type. Therefore, if a user is assigned CREATE authority (OBJECTTYPE DISKFILE), then the user can specify access entitlements to all files that are not protected by Safeguard.

Within a Safeguard environment, the privileged IDs that normally had the ability to create user IDs and add access entitlements can be prevented using the OBJECTTYPE OBJECTTYPE authorization records. To establish this control, an OBJECTTYPE OBJECTTYPE authorization record should be created and assigned to secrity adminstrators with CREATE authority. The ownership of the authorization record should be assigned to the security administrator ID and the Super ID should be explicitly denied access. The =INFO OBJECTTYPE OBJECTTYPE command is executed to verify if this control process has been installed. An example of the setting which prevents the Super ID the ability perform security administration functions is as follows:

LAST-MODIFIED OWNER STATUS
OBJECTTYPE OBJECTTYPE
11JUL92, 11:10 100,1 THAWED

150,1 C
255,255 DENY C,O

If it is decided not to remove the security administrative from the Super ID, the alternative in a Safeguard environment, is to freeze the Super ID. This would prevent its use until the security administrator "thaws" the ID.

In a Guardian based security environment, the Super ID is controlled by segregating the functions performed by the Super ID to other IDs. For instance, the ability to access the various resources on the system should be assigned to the various IDs or processes. In the event that specific resources have not been assigned to a particular ID, which would be the case when the Super ID is used, an alternative would be to establish emergency IDs that have access to these functions.

If access entitlements are properly set-up on the system, then there is no requirement to have the Super ID resident on the system, except when a new release of Guardian is being installed.

In a Guardian security environment, the only method that can be used to restrict the Super ID's routine use is to treat it as an emergency ID. When using the emergency ID, the password is divided into two parts and assigned to two different individuals. CMON, which is a separately running process (explained in System Access section) that is called by TACL, could then be used to identify when the Super ID is used.

The Super Group IDs (255,n) have the ability to start and stop processes and administer access entitlements to all objects. However, within a Safeguard environment, the security administrator function of the Super Group can be restricted as previously discussed.

Group Manager accounts are typically used in order to provide decentralized security administration and to allow the group manager to halt their users processes when they are in an endless loop. However, group manager IDs are allowed to logon onto any ID within their group without having knowledge of the password. If Group Manager accounts are used, then CMON should be used to identify when they logon as another user.

Within a Safeguard environment, the Super ID and Group Manager ID may be forced to logon with a password when they logon as a different user.

System Access

Within a Guardian security environment, an owner associated with each file, and is the user who created the file. Each user is assigned their own Guardian Default Vector which provides a default set of protection for all files which the user creates. This approach is the mechanism that is used to provide protection of all files. As mentioned previously, Guardian security is provided only at the file level and is not available for subvolumes, volumes, processes, and devices.

Safeguard provides default protection of all files, subvolumes, and volumes. In addition, Safeguard provides the ability to protect devices and processes. Users are assigned default Access Control Lists (ACLs) which provides default protection for all files created by the user. If a volume, subvolume, or file does not have an ACL specified, then no one has access.

CMON (Command Interpreter Monitor), a process which is called by TACL based on specific TACL commands that are issued by a user. CMON is a program that can be customized by an installation to perform specific actions which can provide preventive and detective security controls. The specific points in system processing at which CMON is called includes:

logons and logoffs

adding and deleting users

changing user passwords

altering priorities at execuion time

unauthorized logon attempts

In order for CMON to be called at the various points of system processing, it must be started as a process called $CMON. The starting of CMON can be performed automatically through Obey files, which is initiated by the Initial_Comint_Infile of the System Configuration file. A privileged user, Super ID, starts these obey files since some of the processes contained in the obey files requires privileged access.

It is important that CMON is automatically started during system start-up, otherwise, anyone who has access at the system level (i.e., using a command interpreter), can start their own CMON which may not be coded to log all activity.

Since CMON is a user written exit, it can be coded to not only establish an audit trail to identify sensitive activity (e.g., Super ID logon), but to prevent certain events from ocurring (e.g., prevent Super ID logon at specific time frames).

However, it is important to note that CMON is only called from TACL. Therefore, if a user starts another process (e.g., TEDIT), the activity of the editors are not monitored by CMON.

Safeguard provides the ability to log security events including the accessing of resources (i.e., successful and failed attempts) and the changing of the security set-up. This information is used to determine when sensitive resources are being accessed or changed.

Software Change Control

Within a change control environment it is assumed that one has various libraries that a change must migrate through, such as program development libraries, Test libraries, and production libraries. The typical control has a segregation of duties between the person who develops the program and the person who migrates it to the test and production libraries.

This approach can be performed within a tandem environment by restricting libraries to the appropriate person at the subvolume level, when using Safeguard. However, when using Guardian, security is only at a file level. Therefore, all programs that are being changed must be previously protected before they are migrated. Since one does not want to be in a situation where security is required to be changed prior to every program migration, the alternative is to assign the person responsible for migrations a separate ID which has default protection (i.e., using Guardian default security vector). This restricts all access except for the owner who is the migrator. This same approach may be used in a Safeguard environment using the default Access Control List.

On-line Transaction Processing

Pathway is the transaction processing method provided by Tandem. In a typical environment, a separate Pathway process would be assigned for each application.

Safeguard may be used to restrict those users who are able to logon to Pathway and to restrict the resources that can be accessed by the applications defined under Pathway. By restricting the resources defined in a Pathway application, Safeguard ensures that only access to those resources can occur through the Pathway application. In addition, Safeguard can optionally restrict other processes (e.g., a user TACL session or another Pathway application) from linking to Pathway process.

Safeguard does not provide the ability to restrict specific transactions (i.e., screens) or resources (i.e., data) that its users can access.

Within a Guardian security environment each Pathway application can be restricted to specific objects that they require. However, Guardian does not provide the ability to assign user IDs to run specific Pathway applications. Therefore, security must be established within the application or using a third party vendor product.

Safeguard Installation

Safeguard is a process that can be started in three different ways depending on the level of security that your installation requires.

The most secure installation approach is to SYSGEN Safeguard onto the system. This aborts the entire load of the system if Safeguard cannot be started. The second approach is to start Safeguard as part of the normal system initialization process (i.e., specifiy the initialization of the Safeguard process in the CIIN file). The third approach is to start Safeguard after the system is up and running.

The second and third method would provide for the dynamic shutdown of Safeguard while allowing system processing to continue. This would only allow the owner of a file, the owner's group manager, and the Super ID to have access. This restrictive process is used if the Safeguard security bit, which is contained in each file header, is set when the file is created. To ensure that this bit is set, it is suggested that each user's Default Access Control List contain this specification..