S 2.296 Basic factors to consider with z/OS-transaction monitors

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Administrator

The use of transaction monitors must be planned in detail and secured by means of appropriate mechanisms. As an aid, this safeguard describes some recommendations in an overview that have proved to be successful regarding the operation of transaction monitors from an information security point of view. Depending on the operational scenario, further specific planning and security mechanisms are normally required that cannot be detailed here. The database share of IMS is not considered within the framework of this safeguard in particular.

Transaction monitors are used on mainframe systems for online operations. They provide the users with access to their desired data using downstream database systems in dialogue operations. One of the core tasks of the transaction monitor is to ensure that the following conditions are met:

• A transaction must always be performed completely. If this is not possible, the system must be reset to the previous status (roll-back).
• The system should be in a consistent state before and after the transaction; otherwise, the system must be reset.
• Every user must only be granted access to his/her data and should be isolated from all other data.
• Upon completion of the transaction, it must be ensured that the changed state is stored and is available later in the same form. In the event of system failure, the transactions not yet stored must be repeated automatically, if required.

These conditions are applicable to both the online operations and transactions performed in batch mode.

Today, transaction monitors are normally used in a so-called three-tier configuration (presentation, application logic, data storage) and normally cover the following core functions:

• message queuing (administration of the message flow)
• lock administration (administration of the accesses and mutual protection)
• logging
• roll-back functions (reset to previous state)
• load balancing
• two-phase commit synchronisation (ensures that a transaction is performed completely or roll-back is performed)

Amongst other things, IMS TM (Information Management System Transaction Monitor) or CICS (Customer Information Control System) are used as transaction monitors. The IMS-internal DB part, VSAM databases (Virtual System Access Method), or DB2 (Database 2) are available for IMS as database system. For CICS, VSAM, IMS DB, or DB2 can be used as database system.

Even if the transaction monitors and database systems sometimes still offer proprietary protection systems for historical reasons, today a security system such as RACF (Resource AccessControl Facility) is usually used additionally. RACF allows for implementing authentication of the user, protection of the transactions, and access control to the data elements.

General considerations

The transaction monitors IMS TM and CICS are pure VTAM applications in terms of their historical development. They were initially designed for internal networks. Over the course of the past years, advanced interfaces have been provided due to the increasing importance of the internet. These make it possible to also allow accesses to applications of these transaction monitors from the internet.

The following recommendations are applicable to the entire field of transaction monitors and include the databases:

• All security mechanisms should be controlled by RACF, if possible. The internal security mechanisms must only be used where there are no adequate RACF functions.

• Before commissioning a transaction monitor such as IMS or CICS or a database system such as DB2, standards should be developed for all relevant definitions. The standards should refer to transaction names, table names, resource classes, etc. Such standards help to avoid errors in RACF definitions (see S 2.285 Determining standards for z/OS system definitions).

• It should be considered whether the introduction of role concepts (see S 2.30 Provisions governing the configuration of users and of user groups) simplifies user administration.

• For transaction monitors, security mechanisms should always be enabled in such a way that the corresponding rules can be defined externally. The use of external security functions such as RACF definitions should always be preferred over any existing internal functions.

IMS TM (transaction monitor, previously referred to as DC)

The following recommendations are applicable to the IMS transaction monitor. Depending on the operational scenario, further security mechanisms are normally required.

• IMS should be set using the definition in the IMS Security Macro in such a way that IMS uses RACF (parameter TYPE = RACFAGN / RACFTERM / RACFCOM). The IMS system must be defined by the RCLASS definition in such a way that this name (the IMS ID) can be listed as a Resource Class in RACF. If more than one IMS is operated in the z/OS system, it should be considered whether the names existing in RACF by default should be used (e.g. AIMS, TIMS, etc.) or whether proprietary (different) names should be assigned. When using proprietary names, these must be entered as Resource Classes in RACF.
  The IMS Security Macro can be used to activate the following tests, amongst other things (use of the default IMS ID IMS):
  • Application Group Name (AGN) check using RACF (via class AIMS), storage of the valid user IDs for IMS in RACF (RDEFINE)
  • transaction authorisation (via class TIMS or GIMS and SECLVL=TRANAUTH in the security macro)
  • terminal security (SECLVL=SIGNON / FORCSIGN in the security macro and resource class TERMINAL in RACF)
  • command authorisation (via class CIMS or DIMS)
  If there is a parallel Sysplex with data sharing, the IMS ID of the master IMS should be used as RCLASS value.
• It should be considered whether an exit (DFSSGNX0) should be used for signon verification (if the granularity of the RACF check is not sufficient).
• Standard profiles for the individual resource classes must be implemented in RACF application users may be admitted to. It is recommendable to develop standards facilitating the definitions before starting the definitions.

• It should be considered whether the security requirements require a terminal security using RACF (class terminal). Caution should be exercised when implementing a restrictive protection against undefined terminals, e.g. with the RACF command SETROPTS TERMINAL(NONE): At least some terminals must be approved for using RACF under TSO, since no one would be able to log into the system otherwise!
• Mapping of RACF resource classes to the internal IMS security rules is performed using definitions processed by the SMU process (Security Management Utility). A load module is generated from the definition file using a pre-processor and downstream assembly and link, with this module being placed on the IMS matrix dataset and providing the IMS security definitions in control block form, amongst other things. The source code file must only be accessible to employees requiring this file within the framework of their work.
• Accesses to IMS from the TCP/IP network (e.g. from the internet) are performed using the OTMA interface (OpenTransaction ManagerAccess). In order to protect this connection, the OTMASE=xxx parameter at least CHECK (better FULL) must be used to ensure that RACF is used for verification. In this, IMS commands are verified against class CIMS, transactions against class TIMS. The validity of the connection should be ensured by profiles in the FACILITY class in RACF.
• It must be considered whether the IMS programs (control region, message processing region, utilities) are to be protected using the RACF class Program in order to increase the security.
• The IMS files must be protected using RACF dataset profiles in such a way that employees may only access those files they actually require within the framework of their work. IMS users do not require any access to the IMS files. Files to be protected include, for example
  • APF (Authorised Programming Facility) files
  • system files
  • user files, e.g. PSB, DBD, ACB and PGM-LIB files
  Access to APF and system files must only be approved for the STC user IDs (Started Task Control) and authorised employees. Normal users do not require any access to these files (see also S 4.209 Secure basic configuration of z/OS systems).
  The access to user files must be controlled by RACF definitions (see S 4.211 Use of the z/OS security system RACF).
• MVS commands for IMS should be protected using RACF (see S 4.211 Use of the z/OS security system RACF).
• The started tasks should be protected using the RACF class STARTED (see S 4.211 Use of the z/OS security system RACF).
• In the event of particularly high security requirements for IMS, the access to the IMS control region may generally be protected by the RACF Resource Class APPL based on the VTAM LU name. Since each user must be defined either as individual user or in groups in so doing, it must be noted that this results in increased administration efforts. This particularly applies to installations with a large number of users.

CICS

The following recommendations are applicable to the CICS transaction monitor. Depending on the operational scenario, additional security mechanisms are normally required. More detailed information can be found in the IBM documentation CICS RACF Security Guide:

• If the CICS regions are to be run in the Non-Swappable mode (PPT entry to the SCHEDnn Parmlib-Member), it must be ensured that the NOPASS option is not set for the module DFHSIP in the PPT entry (Program Property Table). The NOPASS option bypasses password and RACF checks.
• The started task user IDs must be defined as described in S 4.211 Use of the z/OS security system RACF. The user IDs of CICS Started Tasks must not have the OPERATIONS attribute.
• The CICS files must be protected using RACF dataset profiles in such a way that employees may only access those files they actually require within the framework of their work. Files to be protected include, for example
  • Authorised Programming Facility (APF) files
  • system files
  • user files, e.g. PSB, DBD, ACB and PGM-LIB files
• Access to APF and system files must only be approved for the STC user IDs (Started Task Control) and authorised employees. Normal users do not require any access to these files (see also S 4.209 Secure basic configuration of z/OS systems).
  The access to user files must be performed within the framework of the RACF rules (see S 4.211 Use of the z/OS security system RACF).
• MVS commands for CICS should be protected using RACF (see S 4.211 Use of the z/OS security system RACF).
• For the CICS security, RACF is enabled in the SIT (System Initialization Table) by setting the parameter SEC=YES. The SIT may also be used to define whether transaction protection, program protection, or field protection of input masks is to be enabled using RACF. It must be ensured that these modifications may only be performed by authorised employees. Here, it must be taken into account that the selection of the SIT may be defined both by SYSIN input and using a parameter in the EXEC Statement of the procedure (in the Job Control Language). The SIT module must be placed in an APF library and protected using RACF profiles in such a way that only the employees responsible for this area are allowed to access it (see S 4.211 Use of the z/OS security system RACF). The source file of the SIT must also only be accessible to the correspondingly authorised employees and must be protected with the corresponding RACF file profiles.
• The command security must be enabled when defining the transactions (CMDSEC parameter). It must be considered whether the systems are to be distinguished by SECPRFX=YES. This is recommendable for different CICS jobs in one system.
• The procedures of the CICS regions are located on one (or several) procedure library (libraries). These must be protected by RACF in such a way that only employees requiring access to them within the framework of their work are allowed to change these procedures. It must be considered whether a separate PROCLIB (linked correspondingly to other PROCLIBs) increases the level of security and whether the risk of misuse can be reduced by separate access definitions.
• The login on CICS must require the input of the RACF user ID and password. It is recommendable to design a signon mask for login to CICS. Therefore, a default user must be defined in RACF for every CICS region. The specifications defined in the default user ID in the CICS segment are used by CICS for all terminal sessions until a signon with the personal user ID was performed. It is recommendable to grant only very few rights to the default user ID.
• The General Resource Classes Txxxxxxx (Member Class) and Gxxxxxxx (Group Class) should be enabled for transaction security; the classes Cxxxxxxx (Member Class) and Vxxxxxxx (Group Class) should be enabled for command security (using the SETROPTS command).
• Security mechanisms in the application should only be implemented where there are no adequate security functions in RACF or other security systems.
• It must be considered whether terminal protection based on the VTAM-LU (logical unit) is to be enabled. This safeguard increased the protection, but also the administration efforts.
• Access to the CICS region can be controlled using the VTAM ACB name (Access Control Block) via RACF. If this control is used, it is recommendable to establish a group concept in order to keep the administration efforts as low as possible.
• Different groups must be established for the CICS transactions and system commands. All CICS administration transactions and all critical CICS commands should be protected in such a way that only the employees actually requiring these transactions within the framework of administrative activities may access them. A substitution arrangement should be in place. It must be considered whether it is required to use further CICS Resource Classes (see CICS RACF Security Guide).

• CICS system definitions may either be performed using the RCT (Resource ControlTable) or the CSD (CICS System Definitions). While the older RCT still is created as load module via Assembly and Link, the CSD is created as VSAM file by the RDO dialogue (Resource Definition Online) using the transactions CEDA, CEDB, and CEDC and read by CICS. In both cases, both the relevant files and the transactions must be protected by RACF profiles in such a way that only CICS administrators may access these definitions. Amongst other things, the CICS-DB2 attachment is also defined here using the macro DB2CONN by defining the name of the DB2 subsystem, the authorisations regarding certain IDs, or relations between transaction, DB2 plan, and program, for example.
  It must be considered whether CEDC (which only performs read actions) is also to be protected. This depends on the content of the data.

DB2

The following recommendations are applicable to the DB2 database system. Depending on the operational scenario, additional security mechanisms are normally required. More detailed information can be found in the IBM documentation DB2 UDB Administration Guide:

• For every DB2 subsystem, an entry in the RACF Router Table must be performed, since these entries are not delivered by default.
• The general resource class DSNR must be enabled using the SETROPTS command. The profiles must be defined according to DB2 documentation and accesses must be configured using PERMIT commands. In advance, a group concept should be drawn up, for example as described in the IBM documentation DB2 UDB Administration Guide. If a VTAM LU 6.2 connection (Virtual Telecommunication AccessManagement) is used, it should be considered whether additional protection using class APPCLU is expedient.
• The DB2 files must be protected using RACF dataset profile in such a way that employees may only access those files they actually require within the framework of their work. Files to be protected include, for example
  
  • system files
  • user files as databases
  • Authorised Programming Facility (APF) files
  
  Access to APF and system files must only be approved for the STC user IDs (Started Task Control) and authorised employees. Other users do not require any access to these files (see also S 4.209 Secure basic configuration of z/OS systems).
  The access to user files must be performed within the framework of the RACF rules (see S 4.211 Use of the z/OS security system RACF).
• Access to the procedure libraries of the DB2 Started Tasks must be protected by RACF file profiles (see S 4.209 Secure basic configuration of z/OS systems).
• MVS commands for DB2 should be protected using RACF (see S 4.211 Use of the z/OS security system RACF).
• The DB2 started task user IDs must be defined in the RACF class STARTED as Protected User. The user IDs require accesses to the files of the started task procedures.
• All DB2 files should be protected using RACF Dataset profiles, with normal users not being granted any direct access to the database. Direct accesses should remain restricted to the administrators.
• It is recommendable to not issue any DB2 GRANT PUBLIC permit regarding DB2 catalogue tables. Instead, access rights should be granted on the level of user groups.
• It is recommendable to protect the internal system tables only using DB2 admin commands (GRANT in DB2). Access rights to user tables should be granted using RACF groups. In doing so, the RACF group must be authorised by means of the corresponding GRANTs in DB2. Individual user IDs or (preferably) entire groups can be authorised using the RACF command Permit. If possible, all security definitions should be moved to RACF.

Review questions:

• Is an additional security system used for the z/OS transaction monitor (e.g. RACF)?
• Are all security mechanisms for z/OS transaction monitors preferably controlled by RACF and are the internal security mechanisms only used where there are no adequate RACF functions?
• Are standards developed for all relevant definitions before commissioning a z/OS transaction monitor or database system?
• Are the MVS commands for z/OS transaction monitors and databases protected using RACF?
• Are all DB2 files in z/OS protected using RACF Dataset Profile?
• Is direct access to the DB2 databases in z/OS only granted to the administrators?