Using JESEXIT6 to Prevent Production Programs From
Being Retrieved From Non-Production Load Libraries
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
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.
This article appeared in a past issue of the Audit Vision
E-Mail Newsletter.
|