Upgrading security

Upgrade actions

Table 1 lists the actions you must perform when upgrading to a higher CICS release, regardless of your current release and the target release. The sections that describe these actions in detail are tagged with All versions.

Table 2 lists the actions that depend on your current release and your target release. The sections that describe version-dependent actions in detail also lay out the applicable current-target pairs.

Review TLS protocols and ciphers in use

All versions

Recent versions of the TLS protocol provide enhanced security. You might want to review and upgrade the TLS protocols if necessary. As of CICS TS 6.1, CICS introduces support for TLS 1.3. You can enable TLS 1.3 anytime as long as you're at CICS TS 6.1 or later. See Enabling TLS 1.3 in CICS. If you are upgrading from a release earlier than CICS TS 6.1, you must complete the CICS upgrade first before enabling TLS 1.3.

Also review ciphers that are being used by CICS, including those specified in the cipher suite specification files and, if any, the 2-digit cipher lists coded directly in resource definitions. You are advised to change weak ciphers to stronger ones to improve the level of security for inbound and outbound connections. For example, as of CICS TS 6.2, cipher suites that use NULL, Triple DES (3DES) and RC4 encryption are removed from the CICS-supplied default cipher suite specification file (defaultciphers.xml). If you have your own unchanged copy of defaultciphers.xml in USSCONFIG/security/ciphers from a previous release, it is recommended that you copy the new version from USSHOME/security/ciphers to USSCONFIG/security/ciphers. For more information, see Changes to samples.

Review security definitions of REXX for CICS TS

All versions

If you reinstall REXX for CICS, review its security definitions.

REXX transactions are defined in a file that is used as CSD input. They use the default values of RESSEC and CMDSEC. As of CICS TS 6.2, the default values are set to RESSEC(YES) and CMDSEC(YES). Although this does not affect existing definitions in the CSD, it's recommended that implement security definitions for REXX for CICS users. For more information, see REXX for CICS TS: CICS command and resource security.

Review the impact of extensions to command and resource security checks

All versions

Command security applies if the XCMD system initialization parameter is specified (that is, not set to NO) for the CICS region. Resource security applies if any of the Xnnn SIT parameters is specified for the CICS region. Releases of CICS extend the resource types, their resource identifiers, and associated commands that are subject to command security checking and resource security checking. Check the resources and commands that are changed.

Define new Category 2 transactions to RACF

All versions

Category 2 transactions are initiated by CICS users or are associated with CICS users. You must define these transactions to RACF, and authorize users or groups of users to use them. Sample CLIST DFH$CAT2 is provided to assist with this. For a list of CICS transactions, see All supplied transactions and associated security categories.

Migrate from APPC PEM

All versions

Support for CICS Advanced Program-to-Program Communications (APPC) Password Expiration Management (PEM) is stabilized. The APPC PEM server does not support password phrases. To support authentication with password phrases when using CICS Transaction Gateway, you must migrate from APPC to IP interconnectivity (IPIC) and change your application code to use a current External Security Interface (ESI) API such as CICS_VerifyPassword and CICS_ChangePassword as described in the CICS Transaction Gateway for Multiplatforms product documentation. Information about APPC PEM can be found in previous versions of CICS TS documentation, for example APPC password expiration management.

Review external security settings for CMCI

This action depends on your current release and your target release.

• Your current release: 5.4 5.5
• Your target release: 5.6 or later

The GraphQL API, CICS bundle deployment API, and user of MFA in the CICS Explorer® require the CMCI JVM server. In 5.6 regions, this is enabled by default in regions that use the CMCI. In 5.5 regions, this is off by default. In 5.4 regions, this is enabled by APAR PI87691. If you installed and implemented the change in APAR PI87691, no action is required for 5.4.

If you disable the CMCI JVM server by using the feature toggle, no further action is required, but the GraphQL API, CICS bundle deployment API, and user of MFA in the CICS Explorer will not be available.

If you use the CMCI JVM server, you must define additional security profiles to maintain operation of the CMCI API. You can use the sample CLIST EYU$CMCI in SEYUSAMP, which includes sample RACF profiles. For more information, see Step 11 in Configuring a WUI region to use the CMCI JVM server.

Additionally, if you want to set up the CICS bundle deployment API, which allows Java™ developers to deploy CICS bundles by using the Gradle or Maven plug-in, you need to define additional security settings. You can use the sample CLIST EYU$BUND to define the required RACF profiles. For more information, see Step 3 in Configuring the CMCI JVM server for the CICS bundle deployment API.

Migrate to using CICS surrogate user checking in JCL job submissions

This action depends on your current release and your target release.

• Your current release: 6.1 or earlier
• Your target release: 6.2 or later

Protection for JCL jobs that are submitted to the internal reader by using spool commands is provided by surrogate user checking. From CICS TS 6.2, the default job user ID that is assumed when the JOB card does not specify the USER parameter is subject to the INTRDRJOBUSER system initialization parameter. By the default of INTRDRJOBUSER, the task user ID is assumed. However, in 5.5, 5.6 and 6.1, the default job user ID is subject to the feature toggle com.ibm.cics.spool.defaultjobuser, which assumes the CICS region user ID by default; therefore, when you upgrade to 6.2 or later, be aware of the change in the default job user ID.

Protection for JCL jobs that are submitted through the TDQ is provided by resource security on the TDQ. Additional protection is provided by surrogate user checking if the USER parameter is specified on the JOB card.

From CICS TS 6.2, surrogate user checking for JCL jobs is subject to the XUSER system initialization parameter and is enabled by default.

For enhanced security, migrate to using CICS surrogate user checking to secure JCL job submissions. There are two options:

• Option 1: Jobs submitted by some or all applications run under the task user ID.
• Option 2: Jobs still run under the CICS region user ID, but only with authorization.

In either case, it is necessary to have a profile for the CICS region user ID in the JESSPOOL class to give the region user ID authority to submit jobs for the job user IDs, regardless of whether CICS surrogate user checking is active or not.

Option 1: Migrate to a configuration where jobs submitted by some or all applications run under the task user ID

1. Identify application code that uses SPOOLWRITE and submits jobs without a USER option on the JCL.
2. If some applications must submit JCL under the CICS region user ID, add USER=&SYSUID to the JOB statement. You must also grant the task user ID surrogate authority to submit jobs on behalf of the job user ID.
3. Identify the group of users who are allowed to run these applications.
4. Define surrogate checks to allow only this group of users to submit JCL under the CICS region user ID.
5. Identify the group of users who are allowed to run the other applications that submit jobs without a USER option on the JCL. It is assumed that these will need to run under the task user ID, and have the authority to do so.
6. Ensure that XUSER=YES and INTRDRJOBUSER=TASK (or their defaults) are set for the region.
7. Test the new configuration.

Option 2: Migrate to a configuration where jobs still run under the region user ID, but only with authorization

1. Identify application code that uses SPOOLWRITE and submits jobs without a USER option on the JCL.
2. Identify the group of users who are allowed to run these applications.
3. Define surrogate checks to allow only this group of users to submit JCL under the CICS region user ID.
4. Grant the task user ID surrogate authority to submit jobs on behalf of the job user ID.
5. Set XUSER=YES and INTRDRJOBUSER=REGION for the region.
6. Test the new configuration.

What application changes are needed

Applications that use WRITEQ TD to submit jobs without a USER option do not need any application change. They need RACF definitions only if you specify JOBUSERID on the TDQ definition.

You need to define additional surrogate checks, or change an application if it specifies a USER option on the JOB card, with a user ID different from the task user ID.

Learn more details in Security for submitting a JCL job to the internal reader.

Review security definitions for command and resource security checking

This action depends on your current release and your target release.

• Your current release: 6.1 or earlier
• Your target release: 6.2 or later

To conform with a zero trust strategy, as of CICS TS 6.2, both CICS transactions, excluding CJXA and CICSPlex® SM transactions (CO**), and the TRANSACTION resource have CMDSEC(YES) and RESSEC(YES) by default. You might need to update your security definitions for some transactions.

Impact of CMDSEC(YES) and RESSEC(YES) on CICS and user transactions

Some CICS Category 2 transactions are subject to command and resource security checking and might require you to reconfigure security. For more information about the access needed, see CICS transactions subject to security checking. If you fail to configure security correctly, your applications might not be able to work as before.

For user transactions, when you define and add new user transactions, CMDSEC and RESSEC are turned on by default to enable command security and resource security checking. This applies to all methods of defining transaction resources, including the CREATE TRANSACTION SPI command, the CSD DEFINE TRANSACTION SPI command, resource definition online (RDO), the CSD update batch utility program DFHCSDUP, CICS bundles, CICS Explorer, BAS, CICS Transaction Server resource builder, and so on. Ensure your security definitions define the correct access for users who need to run those transactions, as well as the commands and resources those transactions use.

For existing user transactions already defined in CICS, CICS does not automatically enable command security and resource security checking. CICS retains the previously saved information in the CICS system definition (CSD) file. However, it is recommended that you upgrade these transactions to enhance the security of your applications.

Updating security definitions to implement command and resource security

1. To identify security definitions that are required for resource security, you can use CICS security definition capture (SDC) during manual or automated application testing in a CICS test region with minimal security.

   Note: CICS security definition capture identifies security definitions only for paths that are actually run. If the error paths use additional resources that need to be secured, these security definitions need to be added. Identifying these paths needs some form of code scanning. If you don't have the source code, DFHEISUP can also be used to identify commands that need to be secured.
2. After you have updated your security definitions, run the DFHCSDUP utility to upgrade the CSD and restart the region. If applications stop working, messages DFHXS1111 and DFHXS1117 are issued to provide more troubleshooting information. You can also use the CICS security request recording (SRR) tool to troubleshoot more complex issues.

Overriding RESSEC(YES) and CMDSEC(YES)

For CICS transactions, if you wish to override the new security checking behavior and continue using old transaction definitions, the DFHCOMPK and DFHCOMK2 compatibility groups contain the transaction definitions of the previous releases. You can make a copy of the group and restore the transaction definitions to those of the previous releases.

For user transactions, if you want to override this change, you need to explicitly set CMDSEC(NO) and RESSEC(NO) when defining transactions. For example, issue CREATE TRANSACTION CMDSEC(NO) RESSEC(NO) from your program.

Increase minimum key size for TLS connections

This action depends on your current release and your target release.

• Your current release: 6.1 or earlier
• Your target release: 6.2 or later

As of CICS TS 6.2, CICS uses a minimum key size of 256 for ECC keys and 2048 for RSA, DSA and Diffie-Hellman keys during TLS handshakes. All certificates used in TLS handshakes must have keys that are at least the minimum size. If a smaller key is used, the TLS handshake fails and message DFHSO0123 is issued with a return code of 508. You need to increase the key sizes within your certificates.

If you want to continue using the smaller minimum key size as in previous releases, set feature toggle com.ibm.cics.tls.minimumkeystrength=1024.

For more information about the system SSL values used in CICS, see Setting the System SSL environment for CICS.

Update IBM XML Toolkit for z/OS

This action depends on your current release and your target release.

• Your current release: 6.1 or earlier
• Your target release: 6.2 or later

If you use WS-Security, you must update IBM® XML Toolkit for z/OS® to v1.11.

Define new Category 1 transactions to RACF

This action depends on your current release and your target release.

• Your current release: 5.5 or earlier
• Your target release: 5.6 or earlier

Category 1 transactions are for CICS internal use only and must not be started from a user terminal. They run under the CICS region user ID. You must define these transactions to RACF, and authorize the region user ID to access them. Sample CLIST DFH$CAT1 is provided to assist with this. See Authorizing the region user ID to access category 1 transactions.

For a list of CICS transactions, see All supplied transactions and associated security categories.