The Ultimate Solution to Simplify Your Data Center
Security Considerations
If you have any questions about the content of this page, please contact CICS Requests for clarification
All connections to CICS require a SIGNON be performed. This is usually accomplished by entering a logon ID and its associated password. Quite often these items are entered prior to actually selecting CICS. They are passed over from the menu system and are re-verified.
NWRDC employs ACF2 (from Computer Associates International, Inc.) as the security system for CICS. ACF2 controls who can logon to our CICS regions, when they can do so, and what they can do, once they get there. ACF2 in turn, is managed by our customers. Specific individuals (we call them "institutional security managers/administrators") are authorized to manipulate the access controls and the rules (for their institution) that ACF2 employs as CICS security.
- Elements Of CICS Security
- What Is Being Secured?
- What Is Not Being Secured?
- Security Function Codes Use
There are three elements of CICS security to consider:
- Region: We configure a number of "private" CICS regions, each dedicated to one of our major customer institutions. We also offer "public" regions for customers whose size makes a private region impractical.
- Logon ID: The logon ID represents an individual user of CICS. It is normally created and maintained by the employee's institution. Things like when the logon ID is valid; and how often the password must be changed come under this item.
- Rules: ACF2 rules control access to CICS resources. They are always created by NWRDC, an ACF2 requirement. They are maintained by the institution that owns the resource. Things like: who can signon to a region; and which users are permitted to access various transactions come under this item. These rules are region-specific.
Often, the last two aspects are maintained by the same security managers. When the CICS user does not actually work for the owner of the resource, a split in control occurs. Some communication between the resource owner and the logon IDD owner must occur. MRO support, described below, is an example of this situation. Very rarely, a user does not have a security manager to control his/her logonIDd. When the size or nature of the user's organization makes the establishment of a security manager impractical, NWRDC will assume that responsibility. The owner of CICS resources will always be responsible for all access to those resources. The NWRDC has no active responsibility in that arena at all, unless we are the owner of the resource.
Region Access
Access to a CICS region is considered a "resource." Region rules are written that control who is allowed to signon.
Transaction Security
CICS transactions are grouped into "resource sets." Rules are written to control which users can access the transactions in each resource set.
Security Functions
Rules are also written against user defined character strings. A CICS program can ask if the current user is authorized for one of these security functions. This is usually employed as a way of securing certain options within a program. See the section on the use of security functions later in this document.
JOB Submission
Batch jobs submitted from CICS are required to contain a valid JOB card. Jobs submitted without any password data assume the logon ID of the terminal operator. They will succeed or fail based on the batch ACF2 security rules for that logon ID. Jobs submitted with password data run independent of the terminal operator's logon ID.
Multi-Region Support
Some applications, may be implemented using CICS's MRO feature. Some transactions are actually run in a different CICS region from the one the terminal operator signed on to. In this case two resource rules must grant access. The security managers who control the resource rules in the "home" region have the first say. The security managers in the "remote" region get the final say.
At this time, we have not enabled "file" or "program" security for CICS. Either of these can be enabled (from our point of view) quite easily. The security managers would have to build new resource sets that contain related file-ids or program names. Rules would then be written to authorize appropriate users for the new resource sets.
Note: ACF2's CICS file security is in no way connected to ACF2's batch file security. CICS file security is based on the eight character file-ID (DDNAME) not the external data set name (DSN). Read and write authority, and a kind of "record type" security are available with ACF2's CICS file security.
Security function codes are simply character strings of up to 8 bytes long. A security manager may associate security function with as many users as appropriate. A single user may be associated with as many functions as necessary to perform his/her duties. There is a facility (SECTEST subroutine) whereby user programs may verify whether or not the terminal operator has access to a given function code.
User-defined functions should start with the appropriate transaction code followed by a suffix (1 to 4 char) for uniqueness. The following is a scenario describing one use of the security function codes. Security functions can be used to assign different levels of security to various terminal operators using the same transaction.
Let us assume transaction ABCD can be used to perform a variety of actions depending on who is using it: Some people are authorized to add and delete records; others should be allowed to only update existing records; while still others may only display data. The following functions would be assigned (as appropriate) to those operators authorized for transaction ABCD:
Level of Authority Function
------------------ --------
Add/Delete/Update ABCDADU
Update Only ABCDU
Display None
The CICS program XXABCD would LINK to subroutine SECTEST to verify that anyone attempting to add or delete a record is authorized for ABCDADU. Anyone attempting to update a record would have to be authorized for ABCDADU or ABCDU. In this example, anyone not authorized to display records would simply not be authorized.