Audit Serve, Inc.

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

Preventing Top Secret Users From Submitting Jobs That Run Under The Authority Of Batch ACIDS

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

Within an MVS environment utilizing Top Secret as its security system, all users are assigned an ACID (i.e., userid) and password. MVS tasks (e.g., CICS) and third party vendor system software products (e.g., CA-7) are also assigned an ACID. An address space can be established for these products by either defining them as batch ACID or a STC ACID. If the product is defined as a batch job, then a password can be assigned. This is a control weakness since the security administrator would have knowledge of the password which enables them to submit a job under the authority of the batch ACID by specifying the userid and password in the JCL. However, most installations do not assign a password to batch ACIDS.

Top Secret provides the ability to define users who are able to submit jobs which execute under the access authority of another ACID without requiring them to have knowledge of the user's password. This process is referred to as cross authorization. When a job is submitted for execution, Top Secret interrogates the JOB card of the submitted JCL to determine whether a USER= is contained on the JOB card. Top Secret will then determine whether the submitter of the job is authorized to submit using the authority of the ACID specified in the USER=. In a normal processing environment, users submit a job and are not required to identify themselves by specifying their ACID and password on the JOB card. This is due to the fact that the system automatically performs this function during job submission.

The purpose of this article is to explain how users may submit a job under the authority of a batch ACID, which is defined without a password, when they have not been cross authorized to perform this function. This capability may be restricted using a new Top Secret resource class which may only be used if an installation has JES2 version 3.1.3 and Top Secret version 4.3 installed. This article will discuss the installation procedures of this control and other control alternatives.

Technical View of Job Submission Validation

When a job is submitted to the internal reader, the job opens an internal reader to store the JCL. During the OPEN process, control blocks are built within the user's address space. One of these control blocks has pointers to the access method routine which is used to write the JCL to the internal reader. During the execution of the PUT macro, the access method is identified, which in this case is HASPHAM , since it is a job submission to the internal reader. HASPHAM is the access method that is used to read and write to the JES2 spool (i.e., stores the JCL prior to the execution of Job Steps). The access method is identified by searching the RPL control block which points to the ACB which has the address of ASPHAM specified.

Top Secret gains control during the OPEN process to prepare for its interrogation of the JOB card . It does this by front ending the SVC used in the OPEN process (i.e., DEBCHECK). Once it identifies the fact that the job is being submitted to the internal reader, Top Secret inserts the address of its TSSJINIT module (i.e., module that interrogates JOB card for USER=), replacing the address of HASPHAM. Later in the process, Top Secret's TSSJINIT module is executed. TSSJINIT scans the JOB card to verify that USER= on the Job card is actually person the submitting the job or if the user is cross authorized to submit under the authority of the ACID specified in the USER=. If a USER= is not specified on the JOB card, then Top Secret places the ACID of the user that submitted the job in the USER= of the JOB card. If the job passes Top Secret's validation then Top Secret passes control to HASPHAM which continues with the job's processing (i.e., storing the JCL into the JES spool to ready the job for execution).

How Top Secret Validation May Be Bypassed

The Top Secret TSSJINIT execution may be bypassed by a user submitting an assembler program which performs an OPEN to allocate an internal reader dataset. It then inserts the address of HASPHAM into the RPL control block after the completion of the OPEN process (i.e., which is after Top Secret replaces HASPHAM address with the TSSJINIT address). This action is possible since the control block is stored in the user's private address space. The user's address space has no storage key restriction to prevent them from updating the control block. HASPHAM is a module that resides in Common Storage whose address can be obtained from commonly addressable JES2 control blocks. For the life of an IPL, the address of HASPHAM always remains the same.

The ability to submit a job under the authority of a batch ACID is only possible when the batch ACID is not assigned a password and it is not a started task. If the ACID specified in the USER= has been assigned a password then the job will fail since a matching password was not supplied in the JOB card.

Solutions

If an installation is not currently operating JES2 release 3.1.3 and Top Secret 4.3, the solution is to define all batch ACIDS with a password. This approach would prevent users from submitting jobs under the authority of a batch ACID since they would require knowledge of the batch ACID's password. However, security administrators would have knowledge of the password which would enable them to submit jobs under the authority of the batch ACID.

If an installation is currently operating JES2 release 3.1.3 and Top Secret 4.3, the JESJOBS resource class (i.e., JES2 process which obtains control after Top Secret performs its validation of JOB card and propagates the ACID onto the JOB card) may be used. JESJOBS performs an additional security call to determine whether the user is permitted to submit a job under the authority of the ACID specified on JOB card.

In order to enable this security check, the JESJOBS resource class should be defined in Top Secret's RDT table. The JESJOBS RDT entry restricts all users from submitting jobs unless they have been explicitly granted the ability to submit a job for a particular ACID. In order to allow all users to submit jobs under their own ACID, the permission should be specified in the ALL record. The syntax of the resource is as follows:

SUBMIT. (node which job is submitted from) ( jobname)(ACID that job can be submitted under)

The resource should be set as follows:

SUBMIT.*.*.%

"%" indicates that users can only submit jobs using their own ACID.

For those users who require the ability to submit jobs under the authority of another userid, their individual user profile should be defined with the JESJOBS resource specifying the ACIDS to which they require access.

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.