Expanding CICS security on the mainframe

While CICS security is generally adequate in terms of locking down resources, there are some instances where the existing resources may be used differently or non-CICS components might seek to be secured. Find out how to improve your protection. Find out how to improve your protection in this tip.

Out-of-the-box CICS does a pretty good job of locking down resources. The rules are kept in the very secure Resource Access Control Facility (RACF) repository, and CICS performs authorization checks outside the reach of application code and most system code. However, there are instances when an enterprise may want to use an existing rule in a new way or seek to secure something CICS can't understand.

Using the CICS QUERY SECURITY command
Most External Security Manager calls require Authorized Programming Facility authorization, which is difficult to get in CICS, where most code runs in problem state. IBM gave us the EXEC CICS QUERY SECURITY command for accessing security services.

As documented in the CICS Application Programming Reference Manual (APRM), EXEC CICS QUERY SECURITY has two basic forms. One form queries rules for CICS defined resources (e.g., transactions, files) based on resource classes specified in the System Initialization Table (SIT). The second form allows a program to check any security rule. The output parameters tell the caller what accesses the user has to the resource: ALTER, CONTROL, READ or UPDATE. Another parameter controls the issuance of security violation messages to the CICS job log. You can eliminate a lot of console clutter by turning off ICH408 messages, but I would recommend leaving a debug switch in the program to enable the error messages in a pinch.

Securing CICS Resources
As mentioned above, CICS already does a pretty good job of securing its resources. However, there are some cases when you may want to check a user's authorization for a resource before actually touching it. This enables the application to produce a pretty error message instead of ABENDs or the dreaded "unpredictable results."

For instance, assume we want to train new employees on the production system where they can read files but not update them. To make the experience as real as possible, we check the user's security and bracket any update logic with a check of the authorization flag.

To do this, we add the following command to the beginning of a business (not CICS) transaction:



This command checks the user's authority against the CICS RACF rules class as specified in the SIT, just as if the transaction had tried to do I/O against file CIFFILE. After a successful execution of the command field, UPDTFLAG will be set to CICS Value Data Areas (CVDA) values UPDATEABLE or NOTUPDATEABLE. Based on that information, the application can set switches to be passed through the business transaction. As the transaction progresses, each program can check the flags to see if an update should be actually be done or not. Once the user is fully trained, the security team can authorize the employee with a simple rule change.
The APRM lists the possible resource types. Note that some of them might return "not found" from the QUERY command if the resource isn't defined on the region.

Securing non-CICS resources
Sometimes the problem isn't securing a CICS resource, but rather something inside of it. For instance, a company wants all of its representatives to be able to look at all customer records while ensuring that they can only update accounts in states for which they are trained. For this, we assume every customer record has a two-byte state ID for where they live.

The next step is to define a RACF class, for instance STATECTL, to hold the resource rules. There are 50 resources in STATECTL -- one for each of the states. All representatives have read access to each resource in the class. However, employees have update access only to the resources representing the states for which they're authorized.

To check a representative's access, the application should issue this command at some point:



Thus, to check if a representative is able to update records for a customer in Texas, the program would move "TX" to field INPSTATE and issue the command. If field UPDTFLG comes back UPDATEABLE, the representative can proceed. Otherwise, the employee should see an error messaging asking him or her to forward the call to a representative trained for Texan customers.
For the sake of completeness, note that the second form of this command may be used to check CICS resource access, too. For instance, if SIT parameter XTRAN is set to CICSTRN, CICS uses resource RACF class GCICSTRN to check transaction authorization rules. Therefore, to check a user's transaction access, a program could use this command:



However, this gets to be complicated quickly, as the program has to be sensitive to the CICS and RACF environment.

These dopey examples break the cardinal rule of keeping security checks out of application code. However, the additional functionality may be valuable enough to bend the rules a little. There's also no reason why the QUERY SECURITY command couldn't be isolated into a module owned by technical support, with its own safeguards around it.

ABOUT THE AUTHOR: For 24 years, Robert Crawford has worked off and on as a CICS systems programmer. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2.

What did you think of this feature? Write to SearchDataCenter.com's Matt Stansberry about your data center concerns at  [email protected].

Dig Deeper on IBM system z and mainframe systems