remove systematic access to SYS1.PARMLIB by the CICS translator

We also have SYS1.PARMLIB restricted as described in the following STIG:

"STIG: IBM z/OS RACF Security Technical Implementation Guide - SYS1.PARMLIB contains the parameters that control audit configuration. Unauthorized access could result in the compromise of the operating system environment, ACP, and customer data. If the ESM data set rules for SYS1.PARMLIB allow inappropriate (e.g., global READ) access, this is a finding."

Also, if a compile job tries to access SYS1.PARMLIB and fails, the resulting compile gets a free ride on the DFHAPIR rules. That should be closed as well. If we say we have DFHAPIR rules and they can't be accessed, the entire compile should be aborted (perhaps allow the compile but don't generate any object).

Really does not make sense to open up the SYS1.PAMLIB to everyone needing to compile CICS programs, even if for just read. Would be much cleaner to have a DD to point to a parmlib and member that would or would not have the DFHAPIR member, and not get a security violation, ya'll do this for PLT programs. And why not a ASM XOPTS(xx) parameter to turn it off if not in use.

Our Corporate Security and Auditors prohibit access to SYS1.PARMLIB by unauthorized personnel. Our SYS1.PARMLIB access is set to UACC(NONE), with a few specific RACF Groups able to read it (CICS SYS PROGS, DB2 SYS, MQ SYSPROGS. The development community and Non SYS PROGS should not be able to view SYS1.PARMLIB.

.

The problem I see is the two Translator methodologies. Our Development team prefers a Job Step Transalation while Change Control uses the Integrated Translator.

.

Would prefer to see a DFHAPIR DD statement managed by the CICS Systems Programmer for both types of Translators. ANd should NOT be overriden by a developer. The presence of a // DFHAPIR DD statement indicates that DFHAPIR checking would be performed. Possibly a DFHAPIR option for the Translator.

.

IBM would like to understand more about why some users would have access to some data sets in the parmlib concatenation and not others. Can you provide a specific example of sensitive information in a parmlib member (specific members and parameters) that can only be discovered by viewing the parmlib member?
If you would be willing to provide some more information on this, that would be helpful. Thank you.

Our organisation has locked down (UACC=NONE) and restricted SYS1.PARMLIB to MVS Support in the ACL. Developer access not allowed for security reasons.

Same - Audit/Corporate Security exist in our environment. The SYS1.PARMLIB access, as it is UACC(NONE), with only a few specific RACF Groups able to READ it. Sensitive PARMs that SYS1.PARMLIB houses (that the general public should not be able to view). In addition customized members is added to non IBM PARMLIB datasets to improve software RSU rolled out process.

We have the same issue with SYS1.PARMLIB access, as it is UACC(NONE), with only a few specific RACF Groups able to READ it. This setting is required by our Audit/Corporate Security areas, due to other sensitive PARMs that SYS1.PARMLIB houses (that the general public should not be able to view).

I would like to have IBM update CICS/TS's 'DFHAPIR logic' as follows:
-allow a //DFHAPIR DD statement to be added to the batch CICS program Compile job.
(such as //DFHAPIR DD DISP=SHR,DSN=CICS.PARMLIB )
-IBM/CICS to update CICS/TS software so that *IF* a //DFHAPIR is coded, then the CICS Translator would NOT use the z/OS PARMLIB concatenation, but whatever dataset(s) appear on the //DFHAPIR DD statement.
-If not , it would continue to use the z/OS PARMLIB concatenation.

This item is not in our plans but is being kept in our backlog.

Correction: although CICS supports the DFHTABLE DD, the DFHAPIR parmlib member is not supported through DFHTABLE. I'm sorry for any confusion.

We would still like to understand more about why some users would have access to some of the data sets in the parmlib concatenation and not others. It would be helpful if you could provide more information about that.

The IEFPRMLB service that is used by CICS requires access to the entire Parmlib concatenation. Unfortunately, if users do not have access to some of the data sets in the Parmlib concatenation, attempting to access the Parmlib concatenation will result in an error.
The CICS translator supports coding a specific data set for these options via the DFHTABLE DD, which could point to a specific data set (and could be the same "user.PARMLIB" data set that is in the concatenation.)

IBM is likely to decline this RFE since the DFHTABLE DD can be used instead. However, IBM would first like to understand why some users would have access to some data sets in the parmlib concatenation and not others. If you would be willing to provide some more information on this, that would be helpful. Thank you.

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - z Systems Software
Product - z/OS
Component - BCP_General
Operating system - IBM z/OS
Source - None

For recording keeping, the previous attributes were:
Brand - Servers and Systems Software
Product family - Transaction Processing
Product - CICS Transaction Server
Component - Other
Operating system - IBM z/OS
Source - None

This is not something CICS could solve on its on its own. CICS is using a standard IEFPRMLB macro to invoke a z/OS service to read parmlib. Perhaps a zOS change could be made for example a LOG=NO option. In which case if not authorised it returns a not found response, similar to the way in CEMT and CPSM we ignore any resources in a browse which we are not authorised to read. We don't issue ICH408I and it is not a security vulnerability. If such a change were made, then CICS could exploit it.

The RFE will be transferred to z/OS for consideration.