Implementing CICS Security with RACF can be a complex and demanding process. In order to do it to a level that creates a good balance can take time and requires good knowledge and understanding of both CICS and RACF. So I will explain the various steps in securing CICS with RACF. Let’s begin with the CICS Userid. This is a Userid that is assigned to the CICS Started task when CICS Initialises. Defining the CICS Userid is done thru a RACF ADDUSER command. The PROTECTED attribute should be specified in order to prevent this userid being used to log on to the z/OS system such as TSO. Protected Userids cannot be revoked even if little used. CICS Started tasks are define in the RACF STARTED Class and the Userid Associated with that Started task is defind in the STDATA segment of the STARTED Class. Once CICS has started it will need to issue an Open for the VTAM ACB (Access Control Block). This is controlled by the VTAMAPPL Class. The following RACF commands will define this access RDEF VTAMAPPL CICSPROD UACC(NONE) PERMIT CICSPROD CLASS(VTAMAPPL) ACC(READ)SETROPTS RACLIST(VTAMAPPL) REFRESH I will explain RACLIST in the next and how to control who can sign onto the CICS System.
Who Can Sign Onto the CICS System?
The Security Administrator can define a Class Descriptor to be RACLISTed. There are many CICS Classes that must be defined as RACLIST. It is done thru a RACF SETROPTS command. RACLIST allows RACF to build a Data Space for a Class. This means that when CICS needs to request that RACF check to see if a Userid has access, a check is made in the relevant Data Space instead of accessing the RACF DataBase, so it is much faster. There are many SIT (System Initialization Table) options that pertain to RACF Security. The first is the Default Userid. DFLTUSER= This is the Userid assigned to a terminal before signon. This DFLTUSER can be defined as a Surrogat of the CICS Region Userid if XUSER=YES is specified.
It should have no access to any transactions, other than those intended to be used by all users. This forces the User to issue CESN for Userid/Password, or CESL for Userid/Passphrase in order to signon. When signon completes, an ACEE (Accessor Control Environment Element) is built and assigned to the terminal. Of course to invoke the CICS signon Transaction, SEC=YES must have been specified in the SIT. In order to allow access to the CICS APPLID, this must be allowed by defining a Profile in the APPL Class. The DFLTUSER should be defined in this profile as a minimum. The APPL Class should be RACLISTed.
Securing CICS resources such as Transactions, Programs, Files, etc can take time and a balance has to be found, in my view, as to what is enough and what is too much. Let’s introduce the main RACF Class Descriptors that affect CICS Resources. TCICSTRN/GCICSTRN – Transactions.
Each Pairing of Classes has a Single Entity and a Grouping Entity, so that: RDEF TCICSTRN CEMT UACC(NONE PERMIT CEMT CLASS(TCICSTRN) ID(SYSPROG) ACCESS(READ) SETR RACLIST CLASS(TCICSTRN) REFRESH
The above allows the group SYSPROG READ Access to a single entity – CEMT RDEF GCICSTRN SYSPROGTRANS UACC(NONE) ADDMEM(CEDA,CEDB,CECI,CEBR) PERMIT SYSPROGTRANS CLASS(GCICSTRN) ID(SYSPROG) ACCESS(READ) SETR RACLIST CLASS(GCICSTRN) REFRESH
The above allows group SYSPROG to the transactions specified in the Entity name of SYSPROGTRANS. In each case the Class must be refreshed as it is RACLISTed. These two Classes for Transactions are the most popular because we should be securing Transactions, both System and User. However, TCICSTRN/GCICSTRN only secures Attached Transactions. These are Transactions that are terminal oriented, which of course is most of them. STARTed Transactions that do not specify a Terminal are NOT covered by these two Classes.
With reference to the CICS RACF Security manual, Started transactions that do not specify a Terminal are covered by classes ACICSPCT/BCICSPCT - XPCT=YES. So in order to have Attached transactions covered by RACF, specify XTRAN=YES in the SIT/Overrides, but be aware YES here is the default, so if you specify SEC=YES, then RACF will be called to check if the Userid has access to the Transaction. If you have not specified this transaction in TCICSTRN, access will be denied.
So if you are establishing RACF Security, my advice is to specify the following: RDEF TCICSTRN * UACC(READ) SETR RACLIST(TCICSTRN) REFRESH. This will allow all transactions to have READ access and then you can start to define the individual transactions security until you have completed them and then you can change the UACC(READ) to RALT TCICSTRN * UACC(NONE) and RACLIST REFRESH.
Remember that when the ACEE, mentioned above, is built, it will contain the Userid and every group it is connected to. When CICS checks if the Userid has access to the transaction, it passes the ACEE to RACF for verification. Another question to consider is that if you protect the Transaction, have you protected the Program? CICS doesn’t care how many different transactions invoke the same program. So maybe you need to consider specifying MCICSPPT/NCICSPPT - XPPT=YES. In order to check if the Userid has access to the program. Another way of course is to check in the program that EIBTRNID specifies the correct transaction.
In exploring RACF security in CICS, all resources below Transations are considered lower level security or RSL. This applies to Programs, Files, Temporary Storage Queues, Transient Data Queues, Journals. The SIT/Override option is RESSEC. Specifying ALWAYS, should be avoided as this will cause RACF to be checked for every access to a Lower level Resource. Better to specify ASIS (default) and specify the checking against the individual Transaction with CEDA DEFINE TRANSACTION(transid) RESSEC=YES. Let’s discuss accessing files from an application.
The Class Descriptors are FCICSFCT for the single entity, and HCICSFCT for the grouping entity. Security access to files must be set with access intent, so that if your wish to update a VSAM file (EXEC CICS WRITE FILE..) then you must specify UPDATE access in the Class Descriptor RDEF FCICSFCT FILEA UACC(NONE) PERMIT FILEA CLASS(FCICSFCT) ID(APPLPROG) ACCESS(UPDATE) RACLIST REFRESH
Remember UPDATE access is sufficient for a KSDS because the access is by Key. But CONTROL access must be specified for an ESDS as the access is by RBA (Relative Byte Address). Next I want to discuss the Command Security and make you aware about a surprising fact concerning Master Terminal transaction CEMT and how most installations do not protect this transaction sufficiently.
Command Security – XCMD=YES, offers a more granular approach to securing CICS actions. The CMDSEC option in the Overrides can be ASIS (default), but not ALWAYS. Supplied Transactions CEMT, CECI, CEDF, CEDG, CEDX, CEDY are delivered with CMDSEC=YES, so that the moment you specify XCMD=YES, CEMT/CECI functions will be checked by RACF to make sure that you can issue PERFORM, DISCARD and SET. So it is important that you define these functions to the appropriate Class Descriptors CCICSCMD/VCICSCMD. This is also true from within an Application program that might issue EXEC CICS PERFORM SHUTDOWN. Command Level Programmers should be made aware that their CEMT functions within their programs can be checked if the Transaction issuing them has CMDSEC=YES, with NO being the default.
Securing CEMT is not always done correctly, it invokes program DFHEMTP. This program does NOT check to see who initiated it. So that any Transaction can be defined to invoke DFHEMTP. The Transaction needs to be defined so if I cannot access CEDA, I can write a program and issue EXEC CICS CSD DEFINE TRANSACTION(ZZZZ) PROGRAM(DFHEMTP) CMDSEC=NO, then issue EXEC CICS CSD INSTALL TRANSACTION(ZZZZ). I would need READ access to my program and READ access to ZZZZ, to issue ZZZZ PERFORM SHUT.
Final Thoughts
One of the most complex issues of CICS security, is trying to workout how to secure CEMT. As already discussed, this transaction can be secured with TCICSTRN/GCICSTRN. But this means that every CICS region will have CEMT secured the same, even if there are Development Regions. It might be necessary to have CEMT in these regions defined more loosely, so that Development programmers can bring CICS down and use Newcopy. So the way around this is to specify in the Overrides XTRAN=CLASSNAME. This is user defined such as DEVCTRN. Then define your own Class Descriptors, e.g TDEVCTRN/GDEVCTRN in the Dynamic CDT. Be very careful, do NOT choose a POSIT value of 5, as this value is used for the supplied CICS Classes. So when you issue SETR CLASSACT(TDEVCTRN) RACLIST, RACF will classact both TDEVCTRN and GDEVCTRN BUT if you then decide to Class Inact these 2, RACF will class inact every Class Descriptor that matches a POSIT of 5. So all CICS Classes will be deactivated, thus disabling all CICS security. Chose a POSIT value 19–56 and 128–527. So in your Dev Regions, specify XTRAN=DEVCTRN, CICS will prefix this name with T and G and : RDEF TDEVCTRN CEMT UACC(NONE) PERMIT CEMT CLASS(TDEVCTRN) ID(APPLPROGS) ACC(READ) RACLIST REFRESH.
z/OS Systems Programmer and CICS/TS Systems Programmer of 30 years. Mainframe Training and Software support.