A job scheduling system is a required component of an MVS data center in order to support an installations batch processing environment.

A job scheduling system provides operational controls which ensures that the required work is performed. Some of the operational benefits provided by a job scheduling system which automates the entire batch processing environment includes: provides a mechanism for planning the job processing cycle ensures that all of the required inputs are received submits the job based on required dependencies (e.g., submits job at a specific time, submits job after the successful completion of another job, and submits job once a file is received or created) monitors the successful execution of a job and initiate job reruns Job scheduling systems provide other control functions that are not available with the manual processes that were used for submitting jobs. These manual processes require individual users to have update access to the production datasets that were access ed by the jobs. This approach would allow individuals to submit unauthorized jobs to access such production datasets. In addition, the manual processes used for job scheduling do not provide the operational benefits that were previously described. When using a job scheduling system, the authority to access production datasets is restricted to the job scheduling system or application userids running under the control of the job scheduling system. This approach removes the need for individual users to have update access to production datasets. However, due to the access capabilities that are provided to the job scheduling system, the functions provided to individual users who utilize the job scheduling system must be identified and analyzed to ensure that they are properly controlled. This article discusses the controls available within Computer Associates CA-7 job scheduling product (Release 3.0). Using the CA-90s security architecture, CA-7 offers a complete external security interface to the ACF2, RACF, and Top Secret external security systems. Both the CA-7 internal security and the external security interface will be examined in this article. CA-7 Internal Security General The main components used in the review of CA-7 internal security is the CA-7 initialization file, the user security module, and the SASSTRAN and SASSDSCR modules which control the access to CA-7 functions. The CA-7 initialization file is a source module containing the installation security requirements, which include: terminals that are defined to CA7

the data sets which log CA-7 activity the JCL libraries from where CA-7 will search for jobs that it is instructed to execute security exits that are being used The CA-7 initialization file is identified based on the file specified within the //UCC7IN DD statement of the CA7 Started Task. Logon Security CA-7 is a system software product which is initiated as a Started Task. Users gain access to CA-7 through VTAM by specifying the appropriate APPLID. When using CA-7 internal security, the ID entered is compared to the ID specified in the CA-7 User Security Module. The CA-7 User Security Module is an assembled module whose name is identified within the SECURITY,NAME= of the CA-7 initialization file. The IDs that are used with CA-7 internal security does not require a password to be specified. The CA-7 Logon Validation Exit can be used to transfer control to the external security system during logon validation. This approach is necessary when using internal CA-7 security since CA-7 logon validation offers no logon security controls (e.g., ID not disabled after a specified number of unauthorized access attempts) or password construction controls (e.g., no minimum number of characters in a password). Resource Security The SASSTRAN and SASSDSCR modules are the two security modules used by CA-7 internal security to restrict access to CA-7 commands (i.e., system and user) and panels. Since the SASSTRAN and SASSDSCR are assembled modules that are stored in the CA-7 load library, the correct source equivalent version of the module must be obtained when performing a security review. The SASSTRAN module defines resource security for CA-7 system and user commands. CA7 user commands provide the functions required to schedule and execute the job schedule and other system programming related functions. The CA-7 user commands provide operational assistance for controlling the CA-7 address space and provides the commands to administer internal CA-7 security. The actual segregation of duties requirements are discussed later in this article. ALL CA-7 system commands are preassigned to the SCMO application group. Within the SASSTRAN module, each CA-7 system command is assigned an access level (i.e., 0 - 15). When a user attempts to issue a system command, the access level for each CA-7 system command is compared to the access level to which the user has been assigned in the SCMO application group for the users OPID entry in the User Security Module. If the users SCMO value is greater or equal to the value assigned to the command in the S ASSTRAN module, then the user is allowed to issue the command. The method used to determine access to CA-7 user commands is different from system commands since the application group is not preassigned to the user commands. In fact

multiple application groups are available to be used by the user commands. Within t he SASSTRAN module, the individual CA-7 user commands are assigned an application group and an access level. This is then compared to the access level that the user has been assigned and to the application group as specified in the User Security Module. CA-7 panels provide functions similar to CA-7 user commands. Since the job scheduler is the only job function which requires the ability to change job definitions and schedule jobs, and the operator and users only require inquiry access to determine ho w jobs are set-up, having one level of access to a particular CA-7 panel would not be sufficient to provide the segregation of access that is required. Therefore, a security method is provided for CA-7 panels which segregates the type of access that a us er can be provided with (e.g., READ, ADD, UPD, DELETE, SUBMIT). The SASSDSCR module is used to define the type of access and their associated access levels required by users to perform specific CA-7 panel (i.e., screen) functions. CA-7 panels are defined to the SDMO application group. The individual users access is determined based on the access level they are assigned to the SDMO group which is specified in the User Security Module. Each CA-7 panel is assigned a screen name which appears on the bottom of each screen (e.g., --015--). Within the SASSDSCR module, each screen is defined to a SCR= field and access level for each type of function (e.g., UPD=1). When a user tries to perform a screen function, CA-7 will identify the screen name being used the function being performed. CA-7 will then determine the access level required to perform that function based on the screen being used by retrieving the access definitions defined in the SASSDSCR module. CA-7 will determine whether the user has the required access level as defined for the user within the SDMO field of the users OPID contained in the User Security Module. It is important to group the level of access for the various panels consistently to prevent the assignment of access that exceeds what is required for the users job function. CA-7 External Security CA-7 provides an external security interface for logon, resource security, and job submission. Installations which utilize the CA-7 version 3.0 and the appropriate release level of the external security system (i.e., ACF2 version 5.2 and above, RACF version 1.7 and above, and Top Secret version 4.3 [note: this was also made available as a separately installed PTF of Top Secret version 4.2, GEN level 9006 PTF CO54645]). This security interface allows the logon and password selection controls of the external security system to be used, which replaces the CA-7 logon process. It is possible to use the external security interface for logon security while still using CA-7 internal security for resource security. The external security interface is enabled by the EXTERNAL=YES being specified in the CA7 initialization file. CAIRIM (i.e., Computer Associates Resource Initialization Resource Manager) automatically identifies the external security system that is used by an installation. CAIRIM is an initialization program that prepares the operating system for all of the Computer Associates (CA) products used by an installation and provides an automatic startup facility for each of these CA products. CAIRIM also pro vides a generic security interface for CA products to perform security calls to ACF2, RACF, Top Secret, and other security products, and also informs the CA products which external security system is installed.

The /DISPLAY,ST=SEC command was introduced in CA-7 version 3.0 which lists the security definitions currently defined regardless of internal or external CA-7 security is used. The CA-7 external security interface provides predefined resource names for CA-7 user commands, CA-7 system commands and CA-7 panels. The resource names are the same for ACF2, RACF, and Top Secret. However the actual resource class is different for each of the external security systems. ACF2 CA-7 commands and panels use the TYPE(PAN) within its generalized resource rules Top Secret The PANEL resource name is used for CA-7 panels and CACMD for CA-7 commands. RACF The PA@EL resource class is used for CA-7 commands and panels Controlling CA-7 Components Regardless of whether CA-7 internal or external security is used, the type of sensitive functions which can be performed through CA-7 remain the same. The only difference is the method that is used to secure these functions. Restricting CA-7 Functions The first area of control is the restriction of the CA-7 commands and panels based on the requirements of the individual job function. CA-7 provides three types of functions which represent different aspects of the job scheduling system. The first function is the scheduling of jobs which is typically performed by the job scheduler. The task consists of setting up the daily job schedule based on each jobs execution dependencies. The next function is the execution of the job schedule which is typically performed by the operations or production control group. The managing of the batch processing environment requires the operator to use the CA-7 commands and panels to monitor the workload, redirect jobs, restart jobs after failures, and execute unscheduled jobs. CA-7 provides functions which should not be used by any job function on a routine basis or in some cases, should be prevented entirely. An example of this includes CA-7 commands which allow load modules executed by CA-7 to modified using the CA-7 version of the infamous ZAP utility. The only differ ence in the CA-7 version of the ZAP utility is that the user performs this function under the authority of CA-7 which has access to the load module. JCL Changes JCL libraries are defined to CA-7 in order to fetch the job from the appropriate JCL libraries for submission. Typically, JCL changes are made externally from CA-7 utilizing a controlled change management process to prevent unauthorized changes. However, some installations may choose to allow the editing of JCL to occur through CA-7. CA-7 panels and commands provide the ability to make permanent or temporary changes to JCL.

There are two levels of access that is required for a user to be able to edit JCL using CA-7. First, the individual must have access to the panel which provides the editing of the JCL. Second, they must have access to the dataset which can be secured by CA-7 using security definitions within the USERID macro (i.e., USERID macro is identified in the CA-7 initialization file and stored in the CA-7 load library). The CA-7 external security interface also provides the capability of allowing the external security system to control the users who can edit specific JCL datasets through CA-7. In addition, a user exit (SASSXX07) is available to perform additional JCL dataset validation. Non-scheduled JCL overrides consist of temporary changes to JCL that occur for one execution cycle only. An example of this need to make a one-time JCL change is to insert date parameters for jobs that are date dependant or to point to a different library to fetch an emergency program change (note: this approach for emergency changes is not recommended). In order to control this sensitive function, the JCL overrides should be prevented by restricting all access to the CA-7 panel function which performs JCL overrides. An alternative approach is to establish a review process for all jobs that execute fro m the override library. However, prior to CA-7 version 3.0, there was no method available to identify whether a job was executed from the override library. External Communicators The external communicators (SASSBSTR, SASSTRLR, and U7SVC) provide a mechanism to allow jobs outside CA-7 to execute CA-7 commands. The external communicators are executed within the users job which also contain parameter cards to perform a logon and t hen execute CA-7 commands. U7SVC, SASSTRLR and SASSBSTR can execute virtually any CA-7 command. In order to perform this function the user needs to execute the external communicator load module stored in the CA-7 load library. Internal CA-7 security will perform resource security validation for any commands submitted through these external communicators. However, a user can specify any ID in the job without having knowledge of the users password. The exposure of a user having execute access to these external communicators can be significantly reduced within CA-7 3.0 environments which use the external security interface. This is because the ICMDSECT load module can be altered to turn off the bi t setting to prevent a user from submitting a job under the authority of another user which executes an external communicator. Executing the Correct Version of a Job CA-7 requires the JCL libraries to be defined to CA-7 within the CA-7 Initialization File in order to determine where to fetch execution JCL for jobs submitted by CA-7. When defining each dataset in which JCL members are stored, an alternative dataset c an be specified to be

searched first by CA-7 in order to locate the execution JCL specified for the job. The ALT= parameter is used for this purpose. If the ALT parameter is being used to specify an alternate dataset in which to search for a JCL member, a review should be performed to determine whether this is appropriate. Otherwise, the wrong version of a job could be submitted for execution. Segregation of Batch Processing Environments The use of job scheduling systems extends beyond the production application system. Other areas like systems programmers, application programmers, and security administrators, also use the job scheduling system to submit their jobs. In addition, it is common to have the QA environment (i.e., user acceptance testing) defined with a complete batch environment which is similar to the production environment. In order for CA-7 to submit work for all of these environments, one alternative was to assign the CA-7 started task access to the resources used by all of these processing areas. However, since the JCL for the jobs submitted by non-production environments are controlled by these individual areas, they can potentially submit jobs which impact data of other processing areas. Another alternative is to assign batch processing IDs for each of the processing areas that are submitting work under CA-7. This would require the ID of the batch processing environment in which the job is submitted under to be specified in the JOB card each of their jobs JCL. CA-7 provides an alternative to this approach using the SUBACID process in which specific jobs that are scheduled within CA-7 are assigned IDs under which they execute. Both alternate solutions provide an effective means for segregating the access to the resources of each of the batch processing environments that submit jobs through CA-7.