On-line Security in a Tandem/Guardian 90 Environment
By: Mitchell H. Levine, CISA
Audit Serve, Inc.
Low Cost &
Highly Skilled
IT Audit and SOX Consulting Resources Available Immediately
Call Mitch Levine at (203) 972-3567 or
email levinemh@auditserve.com
for additional information
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.
This article appeared in a past issue of the Audit Vision
E-Mail Newsletter.
|