Audit Serve, Inc.

The Worldwide Connection for Audit, Security, Control and SOX Professionals

Tape Management Security Within An MVS 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

Background

Magnetic tapes are still a major component used to store data within a data processing environment. The method in which tapes are used in one's environment is the basis for assessing the risk in the event that unauthorized changes are made to datasets contained on the tape.

In addition to being used for system backups, tapes are commonly used as the source for data input and output for system processing. Installations may receive tapes from other systems that are used as data input or provide tapes to other installations that are used as input into their systems. An installation may store the previous day's work on tapes, which is restored the following day to initiate their batch processing environment. This method is commonly used by installations whose on-line transactions are captured on files and which are later posted against the previous day's master files (i.e., referred to as memo-posting).

The purpose of this article is to discuss the various tape security features provided by the external security systems and tape management systems. However, the types of controls that should be used by an installation to protect the integrity of the tape datasets should be based on how tapes are used by an installation and the overall exposure in the event that unauthorized updates are made to tapes.

Tape Security Concepts

The tape volume serial number (VOLSER) is the method used to uniquely identify tape volume. The VOLSER is specified in the tape label, which is the first set of information contained on the tape. MVS uses the tape label, which conforms to ANSI standards, to identify dataset names that are contained on the tape, record format, record length, and block size. If a tape does not contain a label or the tape label is a non-standard tape label, MVS will not perform a check to determine whether the datasets specified in the JCL of the submitted job is actually processing the correct tape. A tape management system will prompt the operator to specify the VOLSER of the tape which is mounted. This is done in order to perform a comparison between the dataset on the JCL to the dataset defined in its database for the VOLSER. This is based on the assumption that the VOLSER has been defined to its database.

The external security systems (i.e., ACF2, RACF, Top Secret) provide tape security at the tape volume level and the tape dataset level.

Volume level security consists of defining the tape's volume serial number to the external security system in order to administer the users who are permitted access to the tape volume. When using tape volume security, no distinction is made of the tape datasets that are contained on the tape. This would require installations to track the volumes which contain specific tape datasets in order to determine the volumes which contain sensitive tape datasets requiring restrictions. In addition, if the same tape volume is not used for the tape processing cycle, the security definitions for the tape volumes would constantly require updating.

Tape dataset security protects tape datasets in the same manner as datasets stored on disk volumes. The external security systems provide an installation option to protect all datasets by default. This default protection for DASD datasets should not impact an installation since the naming conventions of all DASD datasets that are used by the system and the applications that they support should be known. However, installations receive tapes from outside sources and are not necessarily aware of the dataset names unless the tape labels are read. In addition, each time a tape is received from an external source the security entitlements would be required to be updated. This may be considered an inconvenience that prompts installations not to use tape dataset security by default.

One method used to counter this inconvenience is to bypass the tape label (i.e., bypass label processing). If bypass label processing (BLP) is specified in the submitted job, security validation would be bypassed. The ability to bypass the tape label is a privilege or an access level assigned to an individual by the installation through the external security system.

Installation might bring up the compensating control that operators are required to mount tapes which represents a segregation of duties supplementing the lack of tape security. This is not considered a compensating control since few installations are willing to install the controls necessary to verify the sensitivity of the datasets contained on the tape. In addition, the authority to decide which individuals can update a specific tape is not the operators' responsibility.

When using a tape management system, an additional check is performed to determine whether the tape dataset specified in the JCL of a submitted JOB actually resides on the mounted tape volume. This is done by comparing the tape dataset specified on the JCL to an entry that the tape management system has stored in its database. When the external security system is not performing tape dataset validation on its own, the basis for initiating the security validation is based on whether the tape management system has identified the tape dataset on its database.

There may be cases in which an installation receives tapes from external sources whereby the tape datasets and VOLSER are not defined in the tape managements system's database. In this case, tape processing should be continued. This is accomplished by the user coding EXPDT=98000 (i.e., Expiration Date 98000 processing) on the JCL of the submitted JOB. However, coding EXPDT=98000 will instruct the tape management system not to compare the dataset name specified in the JCL to its database. Therefore, the tape management system will not initiate a security call to the external security system to perform security validation. EXPDT=98000 may also be used by a user to bypass security validation for tape datasets which are actually defined on the tape management system's database.

The ANSI standard which MVS uses for reading tape labels does not allow tape dataset names to exceed 17 characters in length. However, a tape dataset is allowed to be defined with a maximum length of 44 characters. MVS will read the dataset name specified on the tape label and only pass a 17 character dataset name to the external security system for security validation.

When tape datasets are being accessed through a submitted job, the external security system checks the dataset specified on the JCL to determine whether the submitter of the job has been permitted access. The tape label is then checked to determine whether the last 17 characters of the tape dataset name specified on the tape label matches the dataset name specified in the JCL. The process would allow a user to create a job which specifies a tape dataset name with a high level qualifier to which they have access (e.g., name of their TSO userid). The user's job would pass security validation performed by the external security system and the check of the actual tape label by MVS. MVS ensures that dataset specified in the JCL matches the last 17 characters of the dataset defined on the tape label. Therefore, any tape which has tape datasets exceeding 17 characters would enable a user to "fool" MVS into thinking that they are updating the same dataset name of which the external security system had already performed security validation. If the tape dataset does not exceed 17 characters, and the dataset on the tape label did match the dataset specified on the JCL, then MVS would abend the job.

Tape management systems provide facilities that enable the integrity of the tape to be maintained. The tape management system provides facilities to ensure that a tape cannot be mistakenly scratched by tracking the expiration date specified for each tape. In addition, the location, read and write errors for tapes, and the cleaning of tapes can be tracked.

Tape Security Provided by CA-1

CA-1 provides its own internal security for protecting tape volumes by allowing installations to hardcode the password in the JCL used to initially create the tape volume. CA-1 would then require the correct password to be specified in the job to access the tape volume. However, the passwords can be disclosed by all users who have read access to the JCL libraries. In addition, a unique password is not assigned to each individual requiring access to a particular tape volume and therefore there is no accountability for individual users' actions. Finally, there are no audit trails provided for tapes that are accessed to ensure that all attempts to access the tape are appropriate.

CA-1 also provides internal security to restrict access to its tape management catalog (TMC). The TMC is a database which tracks specific information about each tape volume (e.g., expiration date). Individual users are assigned userids which allows them inquiry or update access at the record or field level. These access restrictions are defined in a table which must be assembled and installed by the installation. Therefore, little control is available for administrating access entitlements. Update access to the TMC should be restricted to the tape librarian. In all cases, update access to the DSN field within all TMC records must be restricted from all users. Otherwise, a tape dataset name can be changed to allow a user to change it to a dataset name to which they have access. This would allow the user to perform unauthorized updates to the tape dataset.

CA-1 version 4.9 provides an external security interface to the external security systems (i.e., ACF2, RACF, and Top Secret). This provides a secured logon for accessing the TMC. In addition, the external security system is called to validate access during critical points of tape processing. These critical points include a check to verify a user's authority to a tape dataset which validates the entire 44 character dataset name, the ability to update the TMC via ISPF or through a batch program, the ability to use Expiration Date 98000 processing, and the ability to access specific TMC records and fields. It should be noted that a security call (i.e., YSVC) is not made to Top Secret for batch updates made to the TMC. Therefore, a user would be able to write a program which performs unauthorized updates to the TMC unless an installation altered the security exit to perform this additional security call. The capability to perform this security call is provided for all security products in CA-1 version 5.0 using the direct security interface. The CA-1 external security interface is a pre-coded security exit, provided for each of the external security systems, which can be altered by an installation to provide additional security calls or suppress security calls.

CA-1 version 5.0 provides a new security interface which enhances the security function provided in version 4.9, but replaces the use of security exits with a direct interface (i.e., mainline code). However, the security exits provided in CA-1 version 4.9 may still be used. The additional security functions provided by the security interface include security calls to the external security systems to perform the following functions:

Bypass Label Processing (BLP)

Besides performing a security call to determine whether users are permitted the ability to code BLP in their submitted job in order to bypass the tape label, the access entitlements granted to users can distinguish between an inhouse tape and a foreign tape. When using the tape security provided by the external security system, the ability to bypass a label, which bypasses security validation, can be restricted to tape volumes that are opened for read or update access.

BLP should not be required for inhouse created tapes that are accessed since an installation should require the use of standard labels and the access entitlements to the tape datasets should be defined. However, since an installation might not be able to enforce standard labels for tapes received from outside sources (i.e., label foreign tapes), they would be required to bypass the tape to read the tape. The CA-1 direct security interface enables security calls to be performed to determine whether a user is able to perform BLP for a inhouse versus an external tape. CA-1 distinguishes between inhouse and foreign tapes by CA-1 by checking the TMC and determine whether a tape volume exists in the TMC. A tape which is not defined in the TMC is considered a foreign tape.

Expiration Date 98000

The CA-1 direct security interface, like the CA-1 security exit, performs a security call in order to determine whether a user is permitted to code Expiration Date 98000 in their submitted job. However, the CA-1 direct interface also performs a security call in order to determine whether a user is able to perform Expiration Date 98000 processing for a inhouse versus a foreign tape.

Creating a tape with no label or non-standard label tape

All tapes used for internal tape processing should be required to have a standard label in order to allow CA-1 to read the volume serial number. This initiates a series of checks to ensure that the correct tape is being mounted. The CA-1 direct security interface performs a security call to determine whether a user is allowed to create a tape with no label or a non standard label. In addition, the CA-1 direct interface can perform security calls based on whether a tape is an inhouse or foreign tape.

Regardless of whether the CA-1 security exit or the CA-1 direct interface is used to initiate security calls to the external security system, CA-1 passes the entire 44 character dataset name based on the datasets which are defined for a tape VOLSER being accessed.

Tape Security provided by CA-DYNAM/TLMS

The tape security capabilities of TLMS has been greatly enhanced with the new release of TLMS (version 5.4) which will be available in the first quarter of 1993. In previous releases, a security interface to the external security system was not available to initiate security calls to the external security system to validate tape datasets being accessed and restrict the use of bypass label processing.

Internal TLMS security (i.e., TLTPOPTS table) was available prior to release 5.4 to restrict access to TLMS inquiry and update functions to TLMS's Volume Master File (i.e., is used to track tape definitions). However, the integrity of the Volume Master (VMF) can be circumvented by users who create their own version of the TLMS userid table within their ISPF session which will be searched prior to LNKLSTxx where the table resides.

In addition to the TLMS security interface to the external security systems that is used to perform security calls to validate access to tape datasets and the use of BLP, TLMS version 5.4, provides security calls for many other critical tape processing functions which will be discussed in the remaining part of this article.

The functions performed by the TLTPOPTS table (i.e., TLMS Security Table), which is used to define userids which were allowed to issue TLMS command to inquire and update the VMF, can be replaced by the TLMS interface to the external security systems (i.e., ACF2, RACF, and Top Secret). The logon interface (i.e., external security system validates user's ability to access theVMF volume) is enabled by setting the SECINQ and INQACC parameters of the TLMSIPO member to YES. The individual TLMS commands, which are used to access the VMF, are restricted using the CACMD resource class and their assigned resource entities. The individual commands can be restricted using masking characters for the entire command and specifying the first letter of the command which represents their assigned grouping, as follows:

R - Read
U - Update commands
L - librarian commands (e.g., clean, certify, scratch)
M - maintenance commands e.g., break chain)

If internal TLMS security is to be used when TLMS version 5.4 is installed, then PROMPT=NOshould be specified. Otherwise the user will only be required to specify the userid, and not the password, in order to have access to entitlements granted to the specified userid.

TLMS provides a series of parameters within the TLMSIPO member which initiates a security call to determine whether the user is permitted the ability to perform the following functions:

Code Bypass Label Processing in their JCL to bypass a tape label (BLPSEC=YES)

create a tape with no label (NLSEC=YES)

create a tape with a non-standard label (NSLSEC=YES)

perform expiration date 98000 processing (FORSEC=YES)

perform tape dataset validation for the entire 44 character dataset name (SECOPN=YES and IDSNVER=YES)

A global security option (SECURE=YES) is also provided allowing the individual options to function according to how they are defined. If SECURE=NO is specified, then all of the individual options will be ignored.

Based on enabling the security calls for the various types of tape processing, users must be permitted access to their associated resource class and entity (e.g., to allow a user to create a non-standard label tape the resource type is CATAPE and the resource entity is NLRES). In some cases, the function is a system-wide option that does not involve granting a user access to a specific resource (e.g., validation of the complete 44 character dataset name).

As mentioned in the CA-1 section, dataset names in the tape management systems database may be changed, which permits users to change it to a dataset name to which they have access. This would allow users to perform unauthorized updates to the tape dataset. TLMS provides the UPD (i.e., Update Dataset Command) which can be used to perform this same function and should be restricted from all users.

This article was written more than three years ago. Events may have changed since this article was written.

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.

Technical Articles | Conferences | Audit Programs | Audit Serve Seminars | Consulting Services | Audit Vision Newsletter | What's New | Contact US

This website has been optimized for Netscape and Internet Explorer 4.0 and above.  Your comments and suggestions are always welcome, please email webmaster@auditserve.com.
Copyright © 2000  All rights reserved.  27 Pine Street, Suite 700, New Canaan, CT 06840 USA.