Audit Serve, Inc.

The Worldwide Connection for Audit, Security, Control and SOX Professionals

CICS/VSE Security Within a VSE/ESA Environment

By: Mitchell H. Levine, CISA
Audit Serve, Inc.

                                                             

Low Cost & Highly Skilled 
IT Audit and SOX Consulting Resources Available Immediately
Call Mitch Levine at (203) 972-3567 or 
email levinemh@auditserve.com for additional information

Introduction

CICS (Customer Information Control System) is an on-line processing system which allows transactions to be entered by terminals which are processed concurrently by application programs. CICS is a program which runs in its own partition in VSE/ESA. Each CICS environment can have multiple regions. Each CICS region is made up of various system tables which define CICS resources such as signons IDs, CICS system initialization options, transactions, application programs, files, and terminals. CICS provides two methods for defining CICS resources: macro definitions and Resource Definition On-line (RDO).

Macro definitions are source modules that are assembled into executable modules loaded each time a CICS region is started.

The following CICS macro definition tables are used:

DFHSNT Signon Table
DFHSIT System Initialization Table
DFHPCT Program Control Table
DFHPPT Processing Program Table
DFHFCT File Control Table
DFHTCT Terminal Control Table
DFHDCT Destination Control Table
DFHTST Temporary Storage Queue
DFHJCT Journal Control Table

RDO uses the CICS System Definition File (CSD) to store terminals, transactions, and program definitions. File definitions, signons, and the System Initialization options continue to be stored in macro definitions. In the current release of CICS, CICS/VSE 2.2, released in March of 1993, IBM supports the use of both macro definitions and RDO.

Throughout this article we will describe the major areas of security within CICS/VSE using internal CICS security. The security interfaces to external security systems (e.g., Alert for VSE, CA-Top Secret, and CA-ACF2/VSE) will not be discussed in this article. However, the entire CICS internal security function has been eliminated from the MVS environment. It is likely that VSE will follow this trend and adopt a RACF-like approach to security (note: a RACF product VSE product is currently not available). Installations may now wish to consider installing an external security manager.

As the major areas in securing a CICS/VSE environment is discussed, one should notice many similarities to how CICS security is performed within the MVS environment.

This article was written to reflect a CICS/VSE 2.2 environment (release March, 1993) operating with VSE/ESA 1.3. However, it should be noted that the prior two CICS/VSE releases contained no significant changes relating to security and controls.

CICS Logon Security

Users are required to go through a successful CICS/VSE sign-on procedure in order to access protected CICS transactions. The user executes the CESN or CSSN transaction in order to supply their userid and password, which is compared to the userids and passwords defined in the CICS signon table (DFHSNT). The table is a macro definition that is assembled. Therefore, the source version of DFHSNT must be stored in a library which is restricted from access by all users except for the users responsible for administering userids.

IUI (Interactive User Interface) is the initial point of entry when a user accesses the system and provides the first level logon security. IUI is a task that runs under CICS and would be the initial logon prior to the CICS logon. After a successful logon, an installation can define the IUI to automatically initiate a CICS logon by passing the user's ID and password and performing the logon for the CICS user.

A security log is available to record all successful and failed logon attempts and user signoffs. All these events are stored in the CSCS transient data destination. The security log needs to be defined by an installation which can be verified by determining whether the CSCS is specified as an entry in the DFHDCT macro. In order to generate a report of these events an installations would have to write their own extract routine.

The method used by internal CICS security to store and administer userids does not provide an acceptable level of control. Therefore, an external security system should be considered in order to perform CICS logon and resource level security. The logon security provided by internal CICS security has the following control weaknesses:

The signon table is not encrypted, therefore passwords can be disclosed to unauthorized users

Users are not able to change their own passwords. Therefore, the user responsible for administering the CICS sign-on table would have permanent knowledge of a user's password.

No forced password change frequency

Does not have password construction controls (i.e., no requirements for a minimum number of characters in a password, and easily guessed passwords can be specified)

Audit trails are not available to identify changes to access entitlements

No limit on the number of unsuccessful logon access attempts

System Access

Internal CICS security provides full protection for restricting the transactions users can execute (i.e., transaction security). An additional level of security is also available which can restrict the CICS resources (e.g., files, programs) accessed through a transaction to specific users (i.e., resource security). Resource security is primarily used when there are specific functions within the transaction are required to be segregated to specific users and which can only be performed on the resource level.

Transaction security (i.e., refer to Figure 1 for an example) consists of restricting a user's ability to execute transactions through the use of security keys. This is accomplished by assigning a security value to the TRANSEC parameter with the transaction definition (i.e., DFHPCT if macro definitions are used or within the transaction definition of the CSD file if Resource Definition On-line is used) so that only users with an equivalent value within the transaction security key (SCTYKEY parameter with DFHSNT macro) will have the ability to execute the specified transaction (refer to figure 1). Since only 64 security keys (1 - 64) are provided, installations must perform a detailed analysis of their CICS system and application transactions in order to establish security groupings that match the requirements of individual job functions.

Figure 1:

DFHSNT

DFHSNT TYPE=ENTRY,
OPNAME='MITCH',
PASSWRD=AUDITOR,
OPIDENT=MIT,
USERID=MITCH,
SCTYKEY=(10,20)

DFHPCT (entry if macro definitions used)

DFHPCT TYPE=ENTRY,
TRANSID=PAYR,
TRANSEC=10

Transaction definition (entry if Resource Definition Online used)

TRansaction ==> PAYR
Group ==> PAYRO
TRANsec ==> 10

Resource security (i.e., refer to Figure 2 for an example) extends the capabilities of transaction security by having the capability to restrict the resources that a user executing a transaction can access. Resource security is established by performing the following:

Specify YES in the RSLC parameter of the transaction definition identifying the transactions for which you want resource (i.e., DFHPCT if macro definitions used or within the transaction definition of the CSD file if Resource Definition On- line is used).

Define a resource security key value between 1 - 24 within the RSL parameter for the resource which requires the additional level of checking. However, if PUBLIC is specified for the resource, then all users having access to the transaction (i.e., assuming transaction is protected via transaction security) would also have the ability to access the resource based on the specified functions that the transaction performs. If 0 is specified, then that particular resource cannot be updated by any transaction which has resource checking enabled (YES specified in RSLC parameter).

Specify the users who will be granted the ability to access the resource by specifying the same resource key which was specified in the RSLC parameter of the resource containing the SCTYKEY parameter with the user's entry within the Signon table (DFHSNT)

Figure 2:

DFHSNT

DFHSNT TYPE=ENTRY,
OPNAME='MITCH'
PASSWRD=AUDITOR,
OPIDENT=MIT,
USERID=MITCH,
RSLKEY=(2,4),
SCTYKEY=(10,20)

DFHPCT (entry if macro definitions used)

DFHPCT TYPE=ENTRY,
TRANSID=PAYR,
PROGRAM=PAYR0,
TRANSEC=10,
RSLC=YES

Transaction definition (entry if Resource Definition On-line used)

TRansaction ==> PAYR
Group ==> PAYRO
PROGram ==> PAY1
TRANsec ==> 10
RSLC ==> YES

DFHFCT

TYPE=FILE,
FILE=PAYROLL.MASTER,
RSL=2

When identifying the resources that are required to be restricted to individual users, resource security cannot be used to specify which users can have access specific resources. The functions performed by the transaction in terms of the resources (e.g., programs, files, journals) one can access must be understood in order to restrict the user to a specific resource.

For example, an installation that requires update access to the payroll master file to be restricted to a specific user cannot perform this by simply matching security keys for the user who requires access and the payroll master file entry in the File Control Table. The transactions which execute programs that update the payroll master file must be identified and the an indicator must be set on the transaction definition to alert CICS to perform resource checking. Remember, the transaction is the vehicle which the user utilizes to access a file.

In addition, before resource checking occurs, the user must have access to the transaction. It is possible for both the no security to be specified for the transaction and the resource checking to still occur.

Overall transaction security is the more manageable of the two forms of security provided by internal CICS security. The purpose of a resource security definition should be understood whenever a change in the programs for which the transaction executes occurs.

CICS resources are not protected by default, therefore internal CICS security (i.e., transaction security) should be used to protect all sensitive CICS transactions. If a CICS transaction is defined without transaction security, then all users can execute the transaction even if they have not signed onto the CICS region. It should be noted that if the security key is set to 1 then all users which have signed onto the region will have access to the transaction.

CICS transactions consist of IBM provided transactions (i.e., referred to as system transactions) and installation defined transactions (i.e., referred to as application transactions).

The following system transactions are used for development purposes and should not be defined within any production CICS region:

CEDF - allows CICS API programs to be intercepted in memory and logic altered

CECI - allows CICS API programs to be invoked without having to write an application program

CEBR - allows temporary storage queues to be browsed, deleted or copied and alters transient data destinations

The following system transactions are required to be contained on the production system but are sensitive and therefore should be restricted to the appropriate individuals:

CEMT - allows some System Initialization Table parameters and terminal definitions to be dynamically altered. In addition the status of system resources can be altered, tasks can be terminated, and the CICS region can be shut down.

CEOT, COBT, CEST perform some of the functions of CEMT.

The CICS tables and definitions are the basis for performing a CICS security review. The macro definitions are assembled modules which are defined in a library within the //LIBDEF PHASE statement for the job step within the CICS region's start-up JCL. The actual version (i.e., defined as xx) of the program (DFHPPTxx), transaction (DFHPCTxx), and file (DFHFCTxx) are identified by entries within the DFHSIT module, which is the CICS System Initialization Table, or by providing SIT overrides within the CICS start-up JCL. However, since these modules are all load versions, their source equivalent versions would have to be obtained from the systems group. It should be noted that each CICS region may use of different versions of the modules containing CICS resource tables.

As previously mentioned, some of the CICS resources (i.e., terminals and transactions) can be defined through an alternate method, Resource Definition On-line. The CSD file is defined for a CICS region via the //DLBL DFHCSD,'' within the start-up JCL for the CICS region. There also must be a file entry within the DFHFCT for the CSD file called DFHCSD.

This article was written more than one year ago. Events 
may have changed since this article was written.

Copyright  2006, Audit Serve, Inc. All rights reserved. Reproduction, which includes links from other Web sites, is prohibited except by permission in writing.

This article appeared in a past issue of the Audit Vision E-Mail Newsletter.

Technical Articles | Conferences | Audit Programs | Audit Serve Seminars | Consulting Services | Audit Vision Newsletter | What's New | Contact US

This website has been optimized for Netscape and Internet Explorer 4.0 and above.  Your comments and suggestions are always welcome, please email webmaster@auditserve.com.
Copyright © 2000  All rights reserved.  27 Pine Street, Suite 700, New Canaan, CT 06840 USA.