JCL and Mainframe Security

Introduction to Mainframe Security

Security is a critical aspect of mainframe computing environments. Mainframes often host an organization's most sensitive data and mission-critical applications, making security a top priority. JCL (Job Control Language) interacts with the mainframe security system in various ways, and understanding these interactions is essential for developing secure applications.

This tutorial covers the fundamental security concepts for mainframe environments, how they relate to JCL, and best practices for secure JCL development.

Security Software on z/OS

Most z/OS installations use one of three major security products:

• RACF (Resource Access Control Facility) - IBM's security product for z/OS, integrated with the operating system
• ACF2 (Access Control Facility 2) - CA Technologies' security product for z/OS
• Top Secret - Another CA Technologies security product for z/OS

While these products differ in implementation, they all provide similar core functionality for security in the mainframe environment. This tutorial primarily references RACF, but the concepts apply to all three products.

Key Mainframe Security Concepts

1. User Identification and Authentication

Users are identified by unique user IDs and authenticated through passwords or more advanced methods like multi-factor authentication. In the context of JCL batch jobs, the user ID associated with the job (either the submitter or a specified user) determines many of the job's access rights.

2. Resource Protection

Security products protect various types of resources:

• Datasets - Files containing data
• Programs - Executable code
• Transactions - CICS, IMS, or other transaction types
• Commands - System and subsystem commands
• Facilities - System services and functions

3. Access Control

Security software controls who can access which resources and what they can do with them. Access levels typically include:

• READ - Permission to view but not modify
• UPDATE - Permission to modify
• CONTROL - Higher-level access (in RACF)
• ALTER - Full control, including the ability to modify security settings

4. Logging and Auditing

Security-relevant events are logged for audit purposes. This includes login attempts, access to protected resources, security violations, and administrative actions.

JCL and Security

JCL interacts with security in multiple ways. Understanding these interactions is crucial for developing secure batch applications.

1. Job Statement Security Parameters

The JOB statement can include security-related parameters:

1
2
3
4
5
//JOBNAME JOB (ACCT),'JOB DESCRIPTION',
//         USER=userid,
//         PASSWORD=password,
//         GROUP=groupname,
//         SECLABEL=seclabel

• USER - Specifies the user ID the job will run under (requires appropriate authority)
• PASSWORD - Password for the specified USER (not recommended in modern environments due to security concerns)
• GROUP - Security group for the job
• SECLABEL - Security label for the job (used in multilevel security environments)

2. Dataset Security

When a JCL job accesses datasets, the security system checks if the associated user ID has the appropriate access rights:

• READ access is required for input datasets (DISP=SHR or DISP=OLD without updates)
• UPDATE access is required for output or updated datasets
• ALTER access is typically required to create new datasets

Example of a dataset access that requires security checking:

1
2
3
//STEP1    EXEC PGM=MYPROG
//INPUT    DD DSN=SECURE.INPUT.FILE,DISP=SHR
//OUTPUT   DD DSN=SECURE.OUTPUT.FILE,DISP=(NEW,CATLG,DELETE)

In this example, the job requires:

• READ access to SECURE.INPUT.FILE
• ALTER access to SECURE.OUTPUT.FILE (to create it)

3. Program Security

Many installations control which programs users can execute. This is often implemented through program control features of the security software or through dataset access controls on the program libraries.

1
//STEP1    EXEC PGM=PAYROLL

In this example, the job requires authority to execute the PAYROLL program. This might be controlled through:

• Program control (RACF program control, ACF2 program pathing, etc.)
• EXECUTE access to the program library (e.g., SYS1.LINKLIB)
• READ access to the program object in the library

4. System Command Security

JCL can issue system commands through the COMMAND statement (in JES3) or through programs that issue commands. These commands are subject to command security controls.

1
2
3
4
5
6
7
//STEP1    EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSIN    DD DUMMY
//SYSUT2   DD SYSOUT=(A,INTRDR)
//SYSUT1   DD *
/*$VS,'S MYJOB'
/*

This example submits a JES2 command to start a job. The user would need appropriate authority to issue this command.

5. Started Task Security

Started tasks (STCs) are jobs that are started by the operator or automatically by the system. They often run with special security privileges. JCL procedures for started tasks require careful security consideration.

Security for started tasks is typically managed through STARTED class profiles in RACF or equivalent facilities in other security products.

Secure Temporary Dataset Naming

Temporary datasets (those with names beginning with ampersands or with DSN=&&name) have special security considerations:

1
2
3
4
5
6
7
//TEMPDD   DD DSN=&&TEMP,
//            DISP=(NEW,PASS),
//            SPACE=(CYL,(1,1))
            
//TEMPDD2  DD DSN=&SYSUID..TEMP.DATA,
//            DISP=(NEW,CATLG,DELETE),
//            SPACE=(CYL,(1,1))

Security considerations:

• Temporary datasets with names like &&TEMP have system-generated unique names and are generally protected by their temporary nature
• Datasets with names like &SYSUID..TEMP.DATA resolve to userdefined names (e.g., USER123.TEMP.DATA) and are subject to normal dataset security rules
• Use system symbols like &SYSUID to ensure unique, user-specific temporary dataset names instead of hardcoded names

JCL Security Best Practices

1. Principle of Least Privilege

Apply the principle of least privilege by:

• Running jobs with the minimum required privileges
• Avoiding the use of highly privileged IDs for routine jobs
• Using specific security groups tailored to job requirements

2. Avoid Hardcoded Credentials

Never include sensitive information in JCL:

• Avoid the PASSWORD parameter on JOB statements
• Don't include passwords in SYSIN data or included procedures
• Use secured passtickets, surrogate user capabilities, or other secure authentication methods

3. Secure Dataset Naming and Access

Follow secure practices for dataset usage:

• Use installation naming standards that facilitate appropriate security controls
• Use system symbols like &SYSUID to ensure unique, user-specific dataset names
• Request only the access level needed (e.g., DISP=SHR instead of DISP=OLD if updates aren't needed)
• Delete temporary datasets when they're no longer needed

4. Secure Procedure Libraries

Protect procedure libraries appropriately:

• Ensure PROCLIB datasets have appropriate access controls
• Audit changes to production procedure libraries
• Implement change management for procedure updates

5. Job Card Security Parameters

Use JOB statement security parameters appropriately:

1
2
3
4
//MYJOB    JOB (ACCT#),'PRODUCTION JOB',
//            USER=PRODJOB,
//            GROUP=PRODGRP,
//            NOTIFY=&SYSUID

• Use the NOTIFY parameter to ensure job results are sent to the appropriate user
• Use appropriate accounting information for charge-back and audit purposes
• Only use USER and GROUP parameters when specifically required and permitted

6. System Command Security

Be cautious with system commands in JCL:

• Avoid including privileged commands in JCL where possible
• If commands are necessary, ensure they're protected by appropriate security controls
• Consider using authorized programs rather than direct command submission

7. Sensitive Data Handling

Protect sensitive data within jobs:

• Direct sensitive output to secured datasets rather than SYSOUT
• Use appropriate MSGCLASS values to control who can view job output
• Don't include sensitive data in JCL comments or SYSIN data where it might be widely visible

Role of Security Exits in JCL Processing

Many installations implement custom security exits that perform additional checks during JCL processing:

• JES2/JES3 Exits - Can perform security checks during job submission, execution, and output processing
• SMF Exits - Can track and control resource usage
• Dynamic Exit Facilities - Allow additional security controls at various processing points

These exits can implement installation-specific security policies beyond the standard security product controls. Always be aware of any custom security exits at your installation that might affect JCL processing.

Auditing and Compliance

JCL jobs and their security implications can be subject to audit and compliance requirements:

• Security-relevant actions in batch jobs are typically logged to the System Management Facility (SMF)
• Security violations are recorded and often trigger alerts
• Regular security audits may review JCL procedures for compliance with security policies
• Change management processes typically govern modifications to production JCL