Securing CICS with RACF

Feb 17, 2023

I have been a z/OS and CICS Systems Programmer for over 30 years and have been teaching more than 25 years.  I have worked in permanent and contract roles.  I have installed CICS and related software many times.

I am well versed in the Application side of CICS using Command level and with CICS Debugging in both the Transaction level and CICS Systems Dumps using IPCS. I have written many courses in CICS namely (CICS for System Programmers, CICS Transaction Debugging, CICS Performance and Tuning, CICS Command Level Programming and CICS Internals).

I am also well versed in z/OS and in 2013 I upgraded the Bank of America z/OS systems from V1.12 to V1.13 on more than 20 LPARS. I have written courses in RACF, SMPE, JES2, TSO/ISPF, JCL, Storage, VSAM and z/OS for System Programmers. I know and have taught Assembler and I’m conversant in COBOL programming language.

I have also written many articles and shared them on Linkedin.

I have conducted training for Customers in many countries, including, Australia, New Zealand, South Africa, India, Singapore, Malaysia, Hong Kong, Thailand, The Philippines, The Netherlands, Belgium, Hungary and the UK. Many of my customers are from financial industries, and I have worked at and taught for Development Bank of Singapore (DBS), Citibank, Bank of America, Westpac, Commonwealth Bank.

I have taught for IBM in the UK, Australia, India and Singapore.

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.

0 Comments

Sign up to receive the latest mainframe information

This field is for validation purposes and should be left unchanged.

Read More

Mainframes: Silent Giants of the Digital Era

Mainframes: Silent Giants of the Digital Era

In the whirlwind of technological advancements, it's easy to overlook the foundational pillars that support our digital world. Mainframes, often perceived as relics of a bygone era, continue to play a pivotal role in orchestrating the symphony of modern data. These...

Thoughts from a Mainframe on Halloween

Thoughts from a Mainframe on Halloween

It was a dark and stormy night in the data center. 🌩️ The fans hummed softly, and the LEDs blinked like little ghosts in the darkness. I had experienced many Halloween nights as a mainframe, but this one was different. There was an eerie presence in the air — and it...