Audit Serve, Inc.

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

What Security is Available for IBM VSE?

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

Introduction

The introduction of the IBM 4300 and 9370 machines and the VSE/ESA operating system, has instilled a new found loyalty within its VSE user base. Due to the new outlook granted to the VSE computing world, security offered within the VSE environment must be analyzed to determine whether it meets one's long-term security and control objectives.

VSE/ESA represents more than a version of its predecessor, VSE/SP. The increase in the number of available partitions, address spaces, real storage, virtual storage, I/O devices, and I/O channels categorizes VSE/ESA as a new generation of the VSE operating system.

VSE/SP users had addressed the limitations of VSE by running multiple copies of VSE under VM, which permitted the extension of the12 partition platform limitations of VSE. This also allowed a separate test system to be established, enabling system programmers to test new releases of the operating system by defining additional guest VSE machines under VM.

Today, when using VSE/ESA and PR/SM offered by the ES9000 processor, LPARs (i.e., logical processors) can be defined to create a separate environment for system programmers to test their changes. The alternative to the use of VM or PR/SM to establish a separate test environment consist of system programmers loading a test system during non-business hours.

MVS users will find many similarities between the VSE and MVS environment since both MVS and VSE supports System Network Architecture (SNA), Virtual Telecommunications Access Method (VTAM), and the Customer Information Control System (CICS).

Two security facilities are provided as part of a native VSE environment; IUI and LOGREP. IUI (Interactive User Interface), which was introduced with VSE/SP version 2 release 1 (1985), is a task that runs under CICS. IUI is the initial point of entry when a user wants to establish an interactive session to either (I) use an editor (IBM's ICCF or CA-VOLLIE) to perform program maintenance and submit jobs or (ii) to submit batch jobs through IUI provided panels. IUI only provides logon security with no protection of system resources.

LOGREP is a combination of the Access Control Facility (ACF) and the Access Control Logging and Reporting (ACLR) products. ACF is a VSE-provided security product used to validate access to system resources. ACLR is an entirely separate (i.e., additional purchased product) VSE program that records and provides reports on protected resources which are accessed. Since these products function as one security facility, they will be referred to as "LOGREP" for the purposes of this article. LOGREP provides a mechanism to protect resources on the system, such as data files and program libraries. LOGREP cannot protect program libraries that under the control of a full screen editor (i.e., VSE provided, ICCF), terminals, and CICS resources.

ICCF (Interactive Computing and Control Facility) provides its own security, which consists of logon security, and restricts access to all types of datasets in addition to ICCF-controlled program libraries. After a successful logon under the control of IUI, if a user requests an ICCF session, IUI passes the userid and password to ICCF and initiates an interactive ICCF partition for the requesting user. Resource validation performed by ICCF security is virtually eliminated when LOGREP security is active, since resource validation, with the exception of ICCF-controlled program libraries, is performed solely by LOGREP, which bypasses ICCF security validation. In older releases of LOGREP (i.e., prior to version 1 release 2, 1984), ICCF was required to be installed in order to use LOGREP security. Such is no longer the case.

Since the introduction of the new library format, AF/Librarian, many of the security approaches have changed. This article is the first of two articles which will discuss the batch security approaches available in a VSE environment when using native VSE security (i.e., IUI and LOGREP security facilities) or a third party security software product (i.e., CA-ACF2/VSE, CA-Top Secret/VSE, or Legent's Alert for VSE). The second article, contained in the next issue of Audit Vision, will address on-line VSE security which encompasses CICS security.

Security issues pertaining to VM users which access VSE guests will not be discussed herein. In addition, due to the limited use of ICCF security when LOGREP is active, ICCF security features are not discussed in this article.

Interactive User Interface Security

The IUI (Interactive User Interface) is the initial process which gains control when a VSE-connected terminal is turned on. IUI is a CICS transaction which places a VSE logo on the user's terminal and prompts the terminal user for a userid and password. VSE provides an IUI control file which stores users profiles, consisting of a userid and password, for each terminal user. A default IUI control file is provided with a security administration userid and various other non- privileged userids. The security administration ID (SYSA) is then used to invoke IUI screens that are used to define other UIU users.

IUI only provides logon security without any form of security relating to VSE resources (e.g., libraries access by a job). The IUI logon security process is critical to entire native VSE security process since it activates an ICCF partition when a user requests an ICCF session to edit a module. IUI passes the userid and password to ICCF to determine whether the user is defined in its security table. All access to ICCF-controlled libraries will still be validated using ICCF security.

In the next release of VSE, only the userid is passed to ICCF and LOGREP and no password validation will be performed. IUI will be solely responsible for password validation. However, the userids defined in the IUI control file, ICCF security table, and LOGREP's DTSECTAB must still be identical.

In addition, whenever system resources are accessed in an interactive partition (e.g., ditto), LOGREP security is invoked. IUI will also pass the userid and password to LOGREP's DTSECTAB (i.e., security file), and therefore bypassing the LOGREP logon security.

In both cases, when IUI passes the userid and password to ICCF and LOGREP, logon validation is performed behind the scenes. Consequently, userids and passwords that are stored in IUI, ICCF, and LOGREP must always be identical. Otherwise, the logon process will fail. What is meant by the concept of logon security being bypassed is that the user will not be prompted to logon when requesting access to ICCF or when accessing a resource interactively.

IUI provides some logon security controls which include:

userids and passwords that are stored in its control file are scrambled

minimum of 4 characters required in a password

passwords required for all userids

password change frequency set on an individual userid level

terminal timeout after a period of inactivity

suspension of userid after a site-specified number of logon attempts

One major inherent weaknesses of IUI logon security is the lack of audit trails to track valid and invalid logon attempts. In addition, there are no automated password construction controls (e.g., to prevent reuse of previously used passwords, creating passwords which are easily guessed).

In order to maintain the integrity of IUI, the IUI control file should be protected from unauthorized replacement using LOGREP security. IUI logon security validation is always in effect and cannot be disabled.

LOGREP Security

Introduction to LOGREP Security

LOGREP userids and passwords are stored in DTSECTAB, which is an installation-assembled module which also defines security entitlements for system and application libraries (i.e., controlled by AF/Librarian), data files, and privileged programs. LOGREP does not provide a screen interface to administer the DTSECTAB module, therefore all users who can access the DTSECTAB load module can make unauthorized changes to a user's resource entitlements. In order to ensure that only security administrators can update the DTSECTAB module, the DTSECTAB should be defined as a protected resource (TYPE=MEMBER, NAME=DTSECTAB), which is only accessible to the security administrator. In addition, the system library or sublibrary in which DTSECTAB resides (IJSYSRES.SYSLIB) must be restricted. It should be noted that DTSECTAB is loaded into memory during the system IPL and all changes that are made to the disk-based DTSECTAB module will not take effect until the next IPL or when a DTSECTAB module is cataloged.

The security administrator for LOGREP (i.e., TYPE=USER, AUTH=YES entry in the DTSECTAB) is able to bypass all access authorization checks. However, all accesses are logged to LOGREP log datasets.

Resources and users are defined with separate entries in DTSECTAB. Resources (i.e., libraries, files, privileged programs) are not protected unless they are explicitly defined in DTSECTAB. Therefore, it is important for an installation to identify the naming conventions used for all datafiles and program libraries in order to ensure that they are defined to DTSECTAB as protected resources. The next release of VSE/ESA (Version 1 Release 3) will provide a pre-generated DTSECTAB so that an installation will not need to know all sensitive VSE programs and VSE provided libraries requiring protection.

DTSECTAB distinguishes between various resources that can be protected using the TYPE= parameter which can be set to the following:

FILE - protect a data file (disk or tape dataset)

LIB - protect a library and sublibrary (i.e., if second high level qualifier specified)

MEMBER - members within the specified library/sublibrary that is accessible to users assigned the specified access control class

Users are permitted access to resources by being assigned an access control class which is the same numeric access control class assigned to the protected resource. The type of access to a resource that a user is permitted can also be specified by (I) assigning an access control class for read and update access or (ii) to log all accesses to a resource. In addition, a universal access setting (UACC= ) can be set for each protected resource which specifies the level of access (e.g., read) to a specified resource that all users will be granted .

Disk File Security

Data files within a VSE environment may either be VSAM, DAM, or SAM, or ISAM file types. LOGREP distinguishes between read and update access for VSAM and SAM files. Security for DAM and ISAM files can only be limited to complete or no access since it is possible in VSE to open a file for input and modify the DTF (macro used to access DAM files) so that it is actually opened for output. ISAM files are not supported by IBM and can only used on older disk devices. The next release of VSE ,Release 1 Version 3 (i.e., available March 1993) will provide the ability to distinguish between read and update access within DAM files.

Tape Security

File entries in LOGREP's DTSECTAB module applies to both disk and tape data files. However, security validation for tape files only occurs if the tape contains a standard tape label. The overriding of a tape label (i.e., (i) allowing tape data file to be opened for processing when a file on tape does not match the file specified in submitted job or (ii) specifying within the program's DTFMT file definition that the tape is an unlabeled tape when the tape is actually a labeled tape) is tightly controlled by canceling all jobs that attempt to override a tape label.

Tape security within a native VSE environment may be bypassed for a multi-file tape by users who open a tape with no-rewind. Users who open a tape with no-rewind can forward space past the tape label and bypass tape dataset security validation (i.e., prevent VSE from returning to the load point to check the tape label). Therefore, VSE prohibits the use of tape volumes that contain multiple files. However, many vendor tapes contain multiple files which would require an installation to either (I) disable security to load the tape or (ii) create a separate tape for each file. The next release of VSE/ESA, provides a new option to enable security which would only disable security validation for tapes but not disk files (i.e., setting SEC=YES, NOTAPE in the IPL startup).

The VSE tape security controls provide standard security for tape datasets but does not offer the flexibility of a tape management system (e.g.,CA-DYNAM/TLMS) required by most installations to fully implement tape dataset security. By not providing a mechanism which defines tape volumes, there is no assurance verification method to ensure that all tape datasets are protected and no method to distinguish between inhouse and foreign tapes.

Batch Security

Jobs may be submitted in (I) batch using IUI panels or (ii) interactively through ICCF (i.e., and other editor products like CA-VOLLIE). When using native VSE security (i.e., IUI and LOGREP security), there is no inheritance of a user's userid from their initial logon in order to perform security validation for the resources that are accessed by the submitted job. Therefore, the user must include a //ID JCL statement which specifies their userid and password. This method of the user to identify themselves by hardcoding their userid and password in the JCL represents a control weakness since the user's password may be disclosed to all users having read or update access to the sublibraries where the JCL is stored.

In the next release of VSE, userid inherence is provided for all jobs that are submitted through IUI and ICCF. This capability is achieved by IUI inserting the user's userid into the JCL during job submission. The user's password will not be inserted into the job since passwords will no longer be used by LOGREP's DTSECTAB member in order to identify the user to perform security validation for resources which are accessed.

Security Integrity

LOGREP security is enabled during system start-up (i.e., IPL) by specifying SEC=YES in the IPL procedure. If SEC=YES is not defined, then IUI logon security will still function but there will be no security validation performed by LOGREP for resources (e.g., files) that are accessed using VSE's AF/Librarian (e.g., replace a module in a library) or jobs that are submitted.

The logging of resources that are accessed (i.e., defined by the LOG=parameter specified for resource entries in the DTSECTAB) and the audit trails of unauthorized access attempts to resources are stored in the IJSTSL1 and IJSYSL2 datasets. These datasets should be protected in DTSECTAB (TYPE=FILE,NAME=IJSTL1 and TYPE=FILE,NAME=IJSTL2) and restricted from all users. There are no commands provided which suppresses the recording of logged events.

System Utilities

VSE provides the DITTO (Data Interfile Transfer, Testing and Operations Utility) utility which is used manipulate data on tape or disk. Some of DITTO's commands retrieve data without performing an OPEN (i.e., which is the point where LOGREP detects a security access and initiates validation), which bypasses security validation. Therefore, read access to DITTO should be restricted so the TYPE=MEMBER,NAME=DITTO is specified in the DTSECTAB. In addition, since DITTO will function if it is renamed, read access to the library which stores DITTO (IJSYSRES.SYSLIB) must be restricted from all users.

The FILECOPY utility, used by operations to restore a single file or an entire volume, requires a user to have update access to all files on the system in order to perform this function. Therefore, users who are provided with this ability should be limited to as few individuals as possible.

VSE System Functions

VSE provides Supervisor Calls (SVCs) which are instructions that can be issued by programs to perform system related functions. SVC #13 gains control in system key 0. This would allow a program to be coded in a specific manner which can potentially bypass security validation performed by LOGREP and all theirs party security systems (ACF2/VSE, Allert for VSE, Top Secret/VSE). Users who are responsible for MVS should be familiar with the security mechanisms available to control SVCs within MVS. This consists of defining the SVCs which must be issued by programs stored in APF libraries. The APF libraries are then restricted from unauthorized users. VSE does not require SVCs to be issued by programs that reside in specific libraries. Therefore a program can be in any library which issues SVC #13.

This article was written more than one year 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.