Using JESEXIT6 to Prevent Production Programs From Being Retrieved From Non-Production Load Libraries

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

Control issue

The production batch processing environment consists of jobs which are submitted to execute production programs. The dataset in which the program is retrieved is specified in the //STEPLIB DDname that immediately follows the program execution statement (i.e., //stepname EXEC PGM=program name). If a STEPLIB is not specified, then the dataset name specified in the //JOBLIB statement is used.

Many installation are required to change the load libraries within their JCL member when they are migrated from the test to production environment. This is not required if they use symbolic overrides during job submission to specify the load library from which they should retrieve the program. If the installations hardcode the dataset name for the load library from which programs are retrieved, then they may neglect to change the dataset name to production load library dataset name. This would allow the production batch processing to be executed from a non-production library. In addition, if a person gains unauthorized access to the production JCL or PROC libraries, they can change the dataset name specified in the STEPLIB or JOBLIB to a non-production load library to which unauthorized individuals may have access.

To prevent the accidental use of the test load library to retrieve programs used during the batch production process, during the change management process. the JCL PROCS should be reviewed to ensure that only production load libraries are specified. However, a preventive control should be in place to prevent the execution of a production job which retrieves load modules from non-production load libraries.

Solution

JES2 which is MVS's subsystem used to convert JCL and submit jobs to the MVS initiator for execution, provides an exit (JESEXIT6) that is called prior to JCL conversion.

The JES exit (JESEXIT6) is defined in the JES2 initialization parameters where it is enabled. The actual load module for the exit is contained in SYS1.LINKLIB or a library in the LNKLST concatenation. Since the exit is coded by an installation, the exit may not contain any code if it is not in use. The exit is called based on the ENABLE parameter which is specified in the JES2 initialization parameter file.

JESEXIT6 can be coded by an installation to verify that all load libraries specified in a production job retrieve only programs from production load libraries. Otherwise, the exit should force a JCL error, which prevents the job from executing. In addition, the exit should generate a message on the system console to allow an installation to identify the attempted execution of a non-production program.

Since legitimate non-production jobs are also submitted, the exit must be able to distinguish between production and non-production jobs. Since all production jobs should be submitted through a controlled process (e.g., job scheduling system), there are specific userids which are assigned to perform this function. The exit is able to identify the userid which submitted the job by searching the JES2 control blocks. If the job scheduling system submits both production and non-production jobs, then the userid inheritance option should be used, instead of the job scheduling userid for all submitted jobs. The userid inheritance option (i.e., available in CA-7) allows an installation to define the userid under which a job submitted from the scheduling system will execute.

The next step of the exit should identify the load libraries from which programs are retrieved by searching the JCL for the JOBLIB and STEPLIBs that are specified. The exit must then determine whether the load libraries are production or non-production load libraries.

There are two approaches which may be used to determine whether the program is being retrieved from production load libraries. The first approach is to hardcode the production load libraries in the exit, which is compared to the load libraries specified in the submitted job. However, this approach would require the installation to update the exit each time that a new library is required to be added.

The other approach is to establish a userid which is granted read access to the production load libraries. A RACROUTE request (i.e., security call) for the userid is made to the external security system to determine whether the userid has read access to the load library specified in the job.

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.