Security

Here we continue our discussion of security over each path into the system, considering more complications over system access through batch jobs. With z/OS, the security comes from SAF; that is, the security software—RACF, ACF2, or TopSecret. We will examine some less well-known ways a user can submit a batch job that runs with some other userid, including through CICS submissions, Network Job Entry (NJE), and IBM’s Sterling Connect:Direct.

When a CICS transaction submits the JCL for a batch job to execute, you might expect the batch job would execute under the userid of the terminal-sitting user who typed in the transaction name.  Instead, however, the batch job inherits the userid of the CICS region, which may have permission to access many sensitive data sets.

IBM gives us a way to control this: The PROPCNTL resource class provides a way of telling the security software, “Here’s a userid (the userid of the CICS region) that should never be allowed to be inherited by batch jobs.” Of course, you can’t implement this on current CICS regions without reviewing all the current transactions to see which, if any, submit batch jobs, which is likely an unreasonable task. You can at least implement a policy that any new CICS region will have the PROPCNTL protection implemented. Then, new applications at least can be set up with a USER= parameter on the JOB card and use the SURROGAT resource class described in the October/November 2011 z/Journal column to permit CICS to submit them. (You can access that column at www.mainframezone.com/it-management/mainframe-security-security-over-system-access-through-batch-jobs.)

NJE is a method to let JES in one data center send batch jobs (among other things) to execute under JES in another data center. By default, the batch job must include a userid and password to execute. But IBM gives us a resource class in SAF called NODES. With the NODES resource class, we can tell the system to accept jobs over NJE without passwords and to even translate their userids to some other userids. The NODES resource class uses combinations of the name of the sending NJE and the userid of the batch job to determine whether to reject the job, accept it if it has the correct password, or accept it without a password. This makes it possible to say things like, “If it’s from our New York data center and it’s for the userid JOHN, then accept it without a password, but make it execute here with the userid SMITH.” This can be very convenient, allowing us to separate data centers we trust from those we don’t. 

This is also a common way for security exposures to be introduced when, for the sake of convenience, someone puts a NODES class rule in the security software accepting any job for any userid from any source without having to provide a password. A thorough evaluation of z/OS security for batch jobs will include review of NODES class rules in the security software.

Connect:Direct and similar programs sometimes are implemented in ways that use the scheduling of batch jobs to provide automatic copying of files from one data center to another on a repeating schedule. For the jobs to be able to access their input and output files, they need to be set up to execute with specified userids. One easy way to do this is to use the techniques described in the previous column (such as SURROGAT and JOBFROM and XA ACID) to authorize Connect:Direct to submit batch jobs for other userids. It then becomes important to control access to the Connect:Direct files where the JCL and schedules and data centers are defined. Software such as Connect:Direct may also have its own SAF calls to restrict what userids it can submit.

In short, for effective batch security, you need a way to force every batch job to execute with a SAF userid (described in the October/November issue) and careful control over all the ways one userid can submit batch jobs for a different userid without having to provide a password. 

Any hacker (or employee) who wants to abuse the system, and has obtained TSO access, will look to weaknesses in these controls to find the next step in his attack. Don’t let this happen.

The next column will continue with an examination of security over each path into the system.

Stu Henderson provides IS consulting and training. His Website provides articles, newsletters, and useful links for management, security staff and auditors, including the “RACF User News” and the “Mainframe Audit News.” He teaches security and audit seminars nationwide and in-house.

Email: stu@stuhenderson.com; Website: www.stuhenderson.com