The need for improvement may be due to any of the following:

• BATCHALLRACF not turned on. The consequence is that jobs are submitted without identification by the so-called UNDEFINED USER (????????). This task will involve preliminary work to change batch JCL jobcards to include USER=userid, where userid is a batch userid with specific access. All such userids will have the PROTECTED feature (no password). They will have SURROGAT profiles of the type userid.SUBMIT with access list having job-SUBMITTER userids, such as CICS region userids, Scheduler started task userid etc.
• Unjustified security risk when a single userid with unlimited RACF access is assigned and for all production batch jobs submitted via a scheduling system (eg ESP, Jobtrac, OPC etc). This single userid with its unlimited access will be replaced with many new batch userids, each having appropriate access and dedicated to whole application, housekeeping function, etc.
• Profiles for batch userids not having PROTECTED status exist in class SURROGAT, but authorized submitters are individual userids belonging to personnel from development or support areas, using JCL with PASSWORD=xxxxx in the jobcard. In this case removing PASSWORD=xxxx from the jobcard is needed as well as making the batch userids PROTECTED.
• Network Job Entry (NJE) from one RACF LPAR to another is not RACF controlled. In this case profiles in class WRITER (outbound jobs) on the sending LPAR and profiles in class NODES (inbound jobs) on the receiving LPAR should be created.
• Remote Job Entry (RJE) is not RACF controlled. Profiles in class JESINPUT should be defined.
• Security policy restricts who can submit/cancel batch jobs but class JESJOBS is not active. Profile definitions and activation of this class may be needed.

Some details of implementing SURROGAT protected job submission
The upgrade is divided into two parts:

PART 1

1. We will assess the current production batch environments to ensure that all active batch jobs being submitted through the scheduling product reside in libraries with approved access list, paying particular attention to access UPDATE. Identify if some of them are run by UNDEFINED userid.

2. We will work with the client to identify the access needed by a newly created batch userid. Mostly, this userid will be running jobs, submitted from various CICS applications/packages. If the client is unable to provide such information, we will use the UAUDIT keyword to monitor his entire access for a month and then place this userid on the access list of the resources accessed during this month.

3. We will define the new batch userids complying with a naming standard and will provide the necessary access. Profiles batchuserid.SUBMIT with proper access lists will be created in class SURROGAT.

PART 2

We will monitor for four weeks the batch workload as jobs are submitted as scheduled by the Scheduling product. When fully satisfied that all access have been properly given, we will advise the client to approve the cutover of each Userid. Just before cutover hanges to JCL jobcards will be done to ensure that each job has USER=batch userid and does not have PASSWORD=xxxx. Shortly after all batch userids will be given PROTECTED status. We will monitor the batch userid for an additional week after which the userid will loose its UAUDIT keyword and will become entirely the responsibility of the client's security staff.

back