Release notes for V2.4.0

Contents

• Announcement
• Supported platforms and applications
• System requirements
• Installing IBM Security zSecure
• Incompatibility warnings
• Limitations and known problems

Announcement

System requirements

Supported platforms and applications

Installing IBM Security zSecure

For a complete installation roadmap on all steps to install, configure, and deploy a new installation of zSecure or an upgrade to zSecure V2.4.0, see the IBM Security zSecure CARLa-Driven ComponentsInstallation and Deployment Guide.

This documentation is available with the product at the IBM Knowledge Center for IBM Security zSecure Suite V2.4.0.

Incompatibility warnings

Command logging facility

zSecure V2.4.0 provides support for command logging. The zSecure ISPF user interface supports new fields to specify ticket identifiers and descriptions. This new support is activated by defining profile CKR.CKXLOG.** in the configured resource class (default XFACILIT). Individual functions related to command logging can be controlled by also creating more specific profiles. Creating this CKR.CKXLOG.** profile with UACC(READ), and not defining more specific profiles, changes the command confirmation level (as specified in SE.4) for all zSecure Admin users, and enforces that a ticket ID and description are entered for every generated command. If the CKR.CKXLOG.** profile is not defined, the new fields and options are not available in the zSecure ISPF user interface. Other parts of the zSecure Command Logging application are not affected by the presence or absence of the CKR.CKXLOG.** profile.

To allow users to specify ticket information, define a profile for resource CKR.CKXLOG.ID.SHOW. Users with at least READ access to the matching profile can use the CKXLOGID primary ISPF command and can specify or confirm ticket information during command confirmation. The matching profile for this resource can be generic, for example the CKR.CKXLOG.** profile.

To require that a user fills in the ticket ID and description, define a profile for resource CKR.CKXLOG.ID.PROMPT. Users with at least READ access to the matching profile always see a command confirmation panel when commands are generated, irrespective of the value that is specified in SETUP CONFIRM (SE.4 or SE.D.4). The matching profile for this resource can also be generic, for example the CKR.CKXLOG.** profile.

It is expected that most organizations will define a discrete profile with UACC(NONE) and will not require all users to specify or confirm the ticket ID and description for every generated command.

Please note that the original edition of this function on zSecure V2.3.1 did not require the CKR.CKXLOG.** generic profile (which caused an incompatibility if you had a back-stop profile CKR.**). If you were already using this function, but did not define the CKR.CKXLOG.** profile yet, you must do so in order to continue using this function when upgrading to zSecure V2.4.0 or when applying the more recent update to zSecure V2.3.1 (APAR OA58254 / PTF UJ00783).

Algorithm to compute checksum

The default algorithm to compute checksums changed. Previously, when a CKFREEZE file was produced with the CHECK= parameter specified, zSecure Collect used a simple checksum and the CRC algorithm to compute the values of the CKECKSUM and CRC fields in the MEMBER newlist type, respectively. zSecure Collect V2.4.0 selects the best available algorithm based on the hardware. It chooses between SHA3-512, SHA2-512, and the old version. To ensure using the old mechanism, set a new zSecure Collect CHECK_ALGORITHM parameter to OLD; see also Migration considerations.

Checksum password in AU.L.0 in mixed case

The AU.L.0 ISPF panel in the zSecure Library Audit function allows you to specify a password that is used in calculating the anti-tamper digest values. In previous versions of zSecure, the password that you entered in the panel was changed to uppercase before it was passed to the generated JCL. Since zSecure V2.4.1, the password value in the generated JCL is passed in mixed case; it is not changed to uppercase anymore. To keep your anti-tamper digest values consistent with the ones computed with old invocations of AU.L.0, consider entering passwords in the AU.L.0 panel in uppercase. The calculated values then remain consistent.

MEMBER report type: [ANTI_TAMPER_DIGEST, CRC] and [FINGERPIRNT, CHECKSUM] fields

The default headers of the CRC and CHECKSUM fields in the MEMBER newlist types changed to Anti-tamper digest and Fingerprint, respectively.

The default length of the [ANTI_TAMPER_DIGEST, CRC] and [FINGERPRINT, CHECKSUM] fields in the MEMBER newlist types changed from 8 to 128. If you built your own reports that display those fields, consider printing, for example, only the first 8 characters as in sortlist crc(8) checksum(8).

Preparing for rule-based compliance evaluation

To define variables for rule-based compliance evaluation (AU.R), the DEFINE statements are now required to be included in the C2RG@IDF customization member (instead of ACPCNFG). For more information, see section Definitions of variables in the C2RG@IDF customization member in the zSecure (Admin and) Audit User Reference Manual for your product.

STIG members renamed

SCKRCARL member CKAIUNTD was renamed to C2RIUNTD.

SCKRCARL member CKAGTC40 was renamed to C2RGTC40.

Sensitivity type renamed

Predefined sensitivity type SetGRSCNLxx was renamed to SetGRSRNLxx

CKGRACF

If a profile is not already between quotation marks, CKGRACF adds quotation marks around each DATASET profile within a RACF command within a CMD command before queuing or execution. A TSO prefix is never added.

RACF newlist: ENCRYPT field

The default output length of the ENCRYPT field in the RACF newlist type, present on the KERB segment of USER and GENERAL profiles, has changed from 36 to 63 to facilitate displaying new values added in z/OS V2.4.

Show differences

In order to make it easier to use Show differences, an allocation (ALLOC statement) with FUNCTION=BASE that has no VERSION specified, will now automatically be set to VERSION=BASE. This can affect how CKFREEZE files are matched with security databases.

C2E* members

The C2E* members of the old integration with QRadar SIEM have been removed. Use the newer CKQ* implementation instead.

Migration considerations

Audit Libraries application (zSecure option AU.L)

When the algorithm that zSecure Collect uses to compute checksums changes, the Audit Libraries application (main menu option AU.L) cannot do a meaningful comparison and reports all checksummed data sets as modified. To migrate to a new algorithm, use the CHECKSUM_ALG_CHANGE option (see OPTION in the zSecure CARLa Command Reference). It enables you to specify the length of the time interval in which zSecure assumes equality of checksums that zSecure Collect computed with different algorithms. This option can also be enabled from the AU.L.2 and AU.L.4 functions by providing the length of the time interval in the Period during which a checksum algorithm change is tolerated field. Consider creating two CKFREEZE files, with the OLD and new SHA algorithms, and use the latter as a migration point.

If you do not want to migrate to the new algorithm, you can decide to use the OLD algorithm in zSecure Collect. See also Algorithm to compute checksum.

Limitations and known problems

Limitations and problems that arise after publication are documented in technotes. Therefore, regularly scan for updates on IBM Security zSecure at IBM's Search support and downloads site. A general documentation technote lists all updates to the documentation of 2.4.0 since availability.

You might also want to scan the following recommended fixes. Some of these fixes introduce new functions and features.