Here we continue our discussion of security over each path into the system and consider started tasks and consoles. When an operator at a console in the computer room types the command “START MARY” and hits ENTER, the system finds the Job Control Language (JCL) named MARY and executes it. The JCL for MARY, with an EXEC statement specifying what program to execute and DD statements defining what data sets to make available to that program, looks similar to a batch job. However, it’s a started task, representing yet another path into the system.

Started tasks (also called started procedures and abbreviated as STCs) introduce their own security concerns. These relate to how they can be started, how they’re controlled by the security software (RACF, ACF2, or TopSecret), what privileges they have, and where they’re defined.

While we usually visualize a started task as being started by an operator at the computer room console, there are several other ways to issue a START command. MVS can issue START commands in parmlib members COMMNDxx and IEACMDxx. MVS issues START commands for functional subsystems, such as JES, DB2, WebSphere MQ, and other software. Programs can issue START commands through a Supervisor Call. START commands can be included in the JCL for batch jobs. This means that, depending on the configuration for FTP, they can be issued over FTP. TSO users can turn their TSO sessions into virtual consoles if they have the necessary privileges, and then issue START commands.

You can control which users can issue operator commands, including START, by means of your security software, using rules in the OPERCMDS resource class.

The security software can assign a userid to each started task. (Each security software has its own method for doing this, often making the userid the same as the name of the started task; MARY in our example.) This may or may not constitute a security exposure, depending on who can modify the data sets where the JCL for started tasks is stored.

The userids assigned to started tasks may have privileges in the security software. With RACF, started tasks can also be granted the TRUSTED or PRIVILEGED attributes, which let them bypass all security on the system.

To evaluate your started task security, identify the started tasks on your system and the userid assigned to each. Determine which started tasks have privileges in the security software (and whether they should have such privileges). Review controls over who can update the data sets where the JCL for started tasks is stored. A common conflict illustrates the issues.

This conflict involves auditors stating that giving unneeded privileges to started tasks represents a security exposure. Systems programmers disagree, stating that since started task userids don’t represent people, they aren’t a risk. To resolve such differences, you need to look at where the started tasks are defined and who can modify their JCL. The JCL for each started task is a member of a partitioned data set called a “proclib” or procedure library. The proclibs are specified in the JCL and control files for JES itself. Data set rules in the security software can restrict who can write to the proclibs.

Any user who can write to the proclibs can then modify the JCL for started tasks. It can be very easy to insert an extra jobstep into the JCL, which would then, of course, be executed under the userid and privileges of that started task. If the started task has privileges that let it bypass security, this rogue jobstep could then modify or copy any data set on the system.

For example, consider an installation where all production payroll batch jobs execute with the userid PAYROLL. If this installation makes the userid for a started task the same as the name of the started task, then anyone who can update the proclibs could add a started task named PAYROLL, which would then execute under the userid PAYROLL. This started task could then update the payroll master file without detection.

A thorough self-evaluation of started task security will include review of the data set rules covering the proclib data sets, the resource rules for the OPERCMDS resource class, the actual need for specific started tasks to have privileges (as documented by the vendor), and the ways userids are assigned to started tasks. In RACF installations, ensure that all started task userids have the PROTECTED attribute. All this should lead to a statement of actual risk and the cost of any suggested improvements to reduce this risk. Then you will know how well you’ve secured this path into your mainframe system.