Tandem Audit, Tandem Articles, Guardian Audits, Guardian article, Tandem Consulting, Tandem non-stop

On-line Security in a Tandem/Guardian 90 Environment

By: Mitchell H. Levine, CISA
Audit Serve, Inc.

 


The article entitled, 'What Security is Available for Tandem Guardian 90' discussed the security controls provided by the Guardian operating system and the Safeguard security product. The article addressed operating system security issues with certain information related to on-line transaction processing security. Throughout this article, a background on Tandem's Pathway transaction processing system and the related security controls that are available will be discussed.

Introduction to Pathway

Pathway is an online transaction processing (OLTP) monitor which displays and accepts input from various types of input devices, data manipulation, and data output. Tandem NonStop system provide two types of database management system products: the Enscribe database and Nonstop SQL (Structured Query Language).

An online transaction environment consists of multiple Pathway systems with each running its own set of processes. Each Pathway system has a Pathmon which is the central process. A pathway environment runs under a single Pathmon environment which consists of TCPs and servers.

Pathway uses a requester-server approach for its online transaction processing which consists of dividing terminal handling (requestors) from database operations (servers). The requestor operations consist of screen programs written using SCREEN COBOL. The Screen cobol requestor programs do not perform any I/O (i.e., no update of databases) except to terminals. They can send messages to server programs which perform the data manipulation.

Pathway server programs which handle the data manipulation and data output activities are written using COBOL85, C, TAL, MUMPS, Fortran, Basic, or Pascal, although COBOL and C are the most commonly used languages.

The requestor programs coordinate the data input from a variety of sources which include:

Fixed Terminals

Fixed terminals send requests to Pathway servers through screen Cobol requestor programs which are managed by the Pathway Terminal Control Process (TCP). The TCP coordinates the communication between screen programs and their I/O devices and establishes links between screen programs and the Pathway server classes. A user's terminal interfaces with the TCP program which sends a message to a server class which performs the database operations.

Pathsend Requestors

Pathsend Requestors are Guardian programs that access Pathway servers through the Linkmon process which is part of the Pathsend facility. Other Pathway processes can use this vehicle to send transactions to a Pathway environment using Pathsend requestors using the Linkmon process which allows users access to Pathway server classes.

Personal Computers (PCs) and Workstations

PCs and workstations access Pathway servers using Remote Server Call (RSC) which is a Tandem client/server product. The RSC uses Pathway requestors to access Pathway servers through the LINKMON process which is part of the Pathsend facility.

Intelligent Devices

Pathway supports the use of intelligent devices (e.g., ATMs) which access Pathway servers through Screen Cobol requestor programs and the TCP. The IDS (Intelligent Device Support), which is part of the TCP, handles the device processing activity. Tandem's GDS (General Device Support) is also used for many of these intelligent devices to translate requests into a format that is recognized by the TCP.

Pathcom is the command interface (i.e., command language interpreter) to Pathmon which provides a single point of control with OLTP applications and operations (i.e, start and stop all pathway components). Pathcom consists of object related commands which interactively define and manage all Pathway objects. The Subsystem Programmatic Interface (SPI) is an alternate method for managing Pathway where a program issues commands directly to Pathway.

Overall Pathway Security

Within an online transaction environment, separate Pathway processes would be assigned to each application which is identified by its Pathmon process name. Each Pathway process is normally started during the system start-up. This is done using Pathcom commands which are usually issued automatically by Obey files which are defined to the start-up process. By reviewing the Obey files used during system start-up, one can identify all of the Pathway processes defined on the system or the 'STATUS *, PROG $SYSTEM.SYSTEM.PATHMON' TACL command can be issued to identify the Pathway processes that are currently active.

Each Pathway environment is defined with its various resource types such as: programs (i.e., requestor and server), files, and terminals. The Pathway Configuration File defined for the Pathmon process name is used to identify these resource types. When reviewing the Obey files for the Pathcom command that was issued to start each Pathway application, the Pathway Configuration file name would be specified in order to load its parameters into memory.

Although files are defined in the Pathway Configuration File, they also must be defined in the Cobol server programs that are used to access the databases. In order to avoid having to stop the application to recompile the program when the file name is changed, installations normally specify symbolic names for file entries within the Pathway Configuration File. The symbolic name would be referenced in the Cobol program.

Within a Guardian security environment, each Pathway application (i.e., Pathmon process name) can be assigned its own userid for the purposes of restricting access to the required objects when performing its processing function. Guardian security may be used to assign a userid to the Pathmon process. The following types of resources can then be restricted to a specific Pathmon process name using Guardian security:

Devices (e.g., terminals)
Programs
Datafiles
Pathway Configuration File

By restricting these types of objects using Guardian security, a second level of security is provided in addition to the specification of programs, terminals, and files that would be defined for each Pathway application within its Pathway Configuration File.

Guardian does not provide the ability to restrict the specific users permitted to access a Pathway application and its OLTP functions. The Safeguard security product may be used to restrict the users who can access a Pathmon process name. This is done by restricting the Pathmon process name to the appropriate users via an Access Control List. Similarly to Guardian, Safeguard also restricts the resources that the Pathmon process can access. Safeguard can also restrict other processes (e.g., a user TACL session or another Pathway application) from linking to a Pathway application.

However, neither Guardian or Safeguard security provides the ability to restrict the OLTP functions (e.g., ability to execute a payroll transaction) which individual users can perform. This type of security is either built into the logic of the requestor and server programs or obtained from a third party vendor Product (e.g., CA-Onguard).

There are limited audit trails provided by Pathway. Two log files (LOG1 and LOG2) are defined within the Pathway Configuration File. Each log file can be used to record status change messages and error messages. These messages can be recorded to a disk file or routed to a terminal display. There are no audit trails of Pathcom commands issued which dynamically change the Pathway Control File. In addition, audit trails of users who access the Pathmon process name are not provided.

Controlling the Pathway Configuration File

The Pathway Configuration File is an edit file on disk that is loaded into memory (i.e., configure its processors in memory) during the start-up of the Pathway application. Dynamic changes can be made using Pathcom commands or the Subsystem Programmatic Interface (SPI). These changes are made to the Pathway Control File which is stored on disk and cannot be directly edited. This dynamic change process is an example of Tandem's Non-Stop processing architecture by being able to support system changes without interrupting the applications.

Each time the Pathway application is started, the Configuration file can be warm started (i.e., use options defined in Pathway Control File or cold started (i.e., use options stored in the disk based Pathway Configuration File).

The following levels of security are provided for restricting the ability to change Pathway Configuration options in memory/disk:

1) Userids require access to the Pathmon process name which can be protected by a Safeguard Access Control List in order to issue Pathcom commands to alter the Pathway Control File.

2) Normally only a local user would be able to access a Pathmon process name. Remote users who access the Pathmon process name across an EXPAND network would require a REMOTEPASSWORD. Since Pathmon will usually open a terminal, the remote passwords would be required for both systems.

3) To start the Pathmon one requires read access to the Pathmon Configuration file.

4) To make changes in memory, the user must also have write access to the Pathway Control File on disk.

To identify Pathway Control File within Pathway Configuration, use the STATUS PATHMON' command within Pathcom. The name of the Pathway Control File is located by the keyword 'PATHCTL' on the resulting display.

5) Single character vectors within overall Pathway parameters control who can alter the Pathway Control file (i.e., memory version only). The Owner and Security parameters within the overall Pathway section of the Pathway Configuation Control File are used to control this access.

6) To update the Pathway Configuration File the user requires write access to the file.

7) When making changes to the Pathway using the Subsystem Programmatic Interface (SPI), these commands can be restricted by using a Safeguard Access Control List to protect the Pathmon SPI subprocess name. This function cannot be used to protect Pathcom commands since Pathcom does not use the SPI subprocess interface.


This article was written more than one year ago. Events
 may have changed since this article was written.

 


For a free proposal to perform an audit of your organization or provide SOX support & testing services, contact Mitchell Levine of Audit Serve at (203) 972-3567 or via e-mail at Levinemh@auditserve.com.

Copyright  2006, Audit Serve, Inc. All rights reserved. Reproduction, which includes links from other Web sites, is prohibited except by permission in writing.

AuditNet - The Global Resource for Auditors

Free
Audit Vision
Newsletter

Since 1991
Join 3,500 other subscribers

General Data Protection Regulation Seminar

Copyright © 2015. All Rights Reserved.