CICS Security, TLS Enhancement, Updated CICS Documentation and More
The Virtual CICS user group is an online user group that has been meeting for over 10 years. It meets every other month, which works out at six meetings each year. And, at each meeting, there’s a presentation. At the July meeting, Colin Penfold, technical leader for IBM CICS Transaction Server Security, spoke about recent updates to CICS security.
If you don’t know Penfold, he’s been at IBM for almost 40 years, the last 30 in CICS. He’s designed a number of features in CICS, including Channels and Containers, the Link 3270 bridge, and CICS support for the IBM Health Checker for z/OS. For the last decade he’s been the technical leader of CICS Security, during which time he has designed security features in CICS including TLS enhancements, distributed identity support, and several new authentication mechanisms including MFA.
TLS Enhancements
Penfold started his presentation by saying that he would be talking about what’s new in CICS TS 5.6 and the CICS TS Open Beta, which was released on July 9 2021.
He began by looking at enhancements to Transport Layer Security (TLS).
Server Name Indication (SNI) was introduced with Internet Engineering Task Force RFC 6066. SNI allows a server with a single IP address and port to host multiple secure websites, each with their own server certificate, eg Amazon (AWS). CICS TS supports SNI as a client.
Note: SNI is supported rather than required. It’s used if the server supports it, and there’s no configuration.
The problem when accessing a server with multiple websites is that, without SNI, the server certificate being returned doesn’t match the calling URIMAP. With SNI, it does.
For CICS sites, upgrading to TLS 1.3 is a major change. There are three new ciphers for 1.3, and these ciphers are incompatible with TLS 1.2. There are also some performance changes. On the plus side, there’s now a single handshake, more secure algorithms and a change to caching.
These changes required changes to the system initialization table (SIT) with the introduction of the parameter MAXTLSLEVEL and the removal of the parameter ENCRYPTION. ONLY has been removed as an option to the MINTLSLEVEL command, and numeric ciphers have been deprecated and will be removed.
The CIPHERS option on resources IPCONN, TCPIPSERVICE, and URIMAP now defaults to defaultciphers.xml rather than numeric ciphers. Also, USSCONFIG must have the file /security/ciphers/defaultciphers.xml. That means when MAXTLSLEVEL=TLS13 is specified, numeric ciphers are no longer supported, and all definitions must use xml files. People who try to change/install numeric ciphers will find that it fails.
To aid migration, currently with MAXTLSLEVEL<=TLS 1.2, where people specify:
EXEC CICS WEB OPEN CIPHERS(353839)
<URIMAP(urimap)>
A warning message is issued once per program issuing the command. Existing requests are still honoured, but a new translate will fail.
Sites wanting to migrate to using TLS 1.3 will need to upgrade to z/OS 2.4, and upgrade to CICS TS Open Beta. They will then need to:
- Copy and customize defaultciphers.xml
- Prepare RDO definitions, which means all resources must use xml files in CIPHERS, and TLS 1.3 ciphers must be included
- Upgrade certificates (i.e. RSA key size must be at least 2048 bits, and ECC keys size must be at least 256 bits)
- Set MAXTLSLEVEL=TLS13. All ciphers will be defined in USSCONFIG. If any ciphers are found to have security flaws, they can now be changed in one place.
For users replacing outbound default ciphers, they must override the system-supplied default 2-digit ciphers (a very limited set) used on:
EXEC CICS WEB OPEN
EXEC CICS INVOKE SERVICE
And replace them with defaultciphers.xml. The feature toggle to enable this is: com.ibm.cics.web.defaultcipherfile=true.
CICS Scenarios and Best Practices
Moving on to scenarios and best practices, Penfold noted that CICS security documentation has been restructured. Education on concepts and terminology is aimed at new joiners. Advice on security in application architecture scenarios is aimed at application architects. Security configuration tasks for these scenarios is aimed at new systems programmers. The idea is that best practice advice and recommendations are absolutely clear to the reader. Penfold also showed some design example diagrams.
Penfold then went on to talk about the IBM Health Checker for z/OS, which is designed to encourage best practices. It will report where sites are not conforming to advice. Basically, it helps to identify potential configuration problems before they impact availability or cause system outages. It programmatically checks the current active z/OS and sysplex settings and definitions for a system. It then generates output with detailed messages to inform users of any potential problems and suggested actions to take to resolve them.
Health Check output is visible as option CK in SDSF. Checks are associated with a product or subsystem. In fact, IBM provides over 150 health checker checks. Each check tests configuration or state information. This results in a SUCCESS, WARNING, or EXCEPTION message.
New CICS Health Checks are based on best practice reviews of customers, and cover the security configuration of regions definitions, CICS resources, and CICS zFS security. Best practice advice is aimed at production or production-like regions. Examples of checks include:
SEC=YES
XTRAN=YES|class
XUSER=YES
Monitoring and Preventing Threats
Penfold then moved on to monitoring and preventing threats. The new Open Beta shows the TLS protocol in monitoring records. This can be for inbound and outbound performance records.
The enhanced security (XS) monitoring capability is available with CICS TS 5.6. Penfold explained that the world has changed since this was first introduced. The XS security domain had no stats monitoring fields. That’s because when it was introduced in 1992:
- Most requests were 3270 signon
- Only password/passtickets
- Request on RO TCB
- Used DES encryption
Nowadays, XS handles more authentication types (e.g. password/passphrases with KFDAES, MFA, Kerberos and certificates). In addition, CPU and elapsed time authenticating has greatly increased. To avoid bottlenecks, requests cannot now all go through the RO TCB. Open TCBs are used or attached. TCBs (and probably ESM requests) consume 24-bit storage.
New Security Statistics and Settings
There are new security statistics, and there are new areas being monitored. For example the total elapsed time that the user task spent verifying passwords, password phrases, PassTickets and MFA tokens, the total elapsed time that the user task spent verifying basic authentication tokens, the total elapsed time that the user task spent verifying Kerberos tokens, and the total elapsed time that the user task spent verifying JSON web tokens.
Instruction Execution Protection (IEP) helps separate data storage from program storage, and prevents code from being executed on data storage, and therefore prevents buffer overflow exploits. In the past, it has been possible to hide code in data.
There are certain prerequisites for IEP: z/OS 2.4 or 2.3 with appropriate APARs. And users need to be using a z14 or higher. There are also new settings:
STORAGE OBTAIN and RELEASE
EXECUTABLE={YES|NO}
IARV64 GETSTOR
EXECUTABLE={SYSTEM_RULES|YES|NO}
EXECUTABLE is ignored if the hardware or software does not support IEP.
DSA storage in the new Open Beta is either executable or data (non-executable).
Where someone tries to execute code in a data area, there’s a new IEP program check (0c4). The kernel ESTAE will identify 0c4 as an IEP program check with error code 0c4/akes. The PSW will be pointing to the next instruction and the Breaking Event Address Register (BEAR) will contain the last branch address.
If sites really need to make data areas executable, there are API and XPI options, and definitions to allow this. It’s primarily intended for ISVs and requires SYSEIB.
Simplified and Improved Diagnostics
Lastly, Penfold moved on to the simplified and improved diagnostics. The information for security failures has been improved. For example, problems can often occur where the userid is a functional userid or the transaction started on another region. It’s difficult to identify the end user. A new DFHXS1117 message will accompany the DFHXS1111 messages, giving the available origin data information. The information will vary depending on the entry point, but the distributed identity will be reported if available.
Security definitions for CAT 1 transactions have been removed. The situation is that only the region userid is allowed to run CAT 1 transactions. CICS already knows the region userid, the CAT 1 transactions, and how a transaction is started. So, that makes asking an external security manager (ESM) redundant. In addition, removing the ESM check makes it more secure. This is mentioned in the Auditor section of the CICS documentation to ensure auditors are aware.
You can find out more about the Virtual CICS user group here.
You can see and hear the whole of the July user group meeting, and watch the step-by-step way to build an API here.