What's new for zSecure V2.3.1

zSecure™ V2.3.1 enhances mainframe security intelligence and automated compliance auditing.

For information about installation considerations like system requirements, incompatibility warning, and known limitations, see Release notes for V2.3.1.

IBM Security zSecure V2.3.1 (announcement) includes the following new features and enhancements:

• Compliance Framework:
  • Assertions:
    • In cases where automation is fundamentally impossible, you can assert, that is, confirm, that a requirement is met. For example: assert that the ACP audit logs are reviewed on a regular basis.
    • In cases that can be automated, you can configure details about your system to perform automatic analysis. For example, to specify the names of installation data sets that are to be used in automatic compliance verification.
    • You can override results that zSecure produces.
    • Assertions are stored in ASSERT data sets; they can be created automatically. Allocated ASSERT data sets are used during compliance evaluation and history or configuration reporting.
    • Assertions can be entered in the UI, as a line command, and through CARLa ASSERT and OVERRIDE statements.
    • ISPF UI enhancements:
      • The rule-based compliance auditing option (AU.R) is now a menu.
      • Evaluate (AU.R.E) enables you to select standard and results of evaluation based on new selection criteria, for example, based on an assertion end date.
      • Subsets (AU.R.S) enable you to create or run subsets of a complete standard and enter configuration options.
      • Configure (AU.R.C) enables you to specify details that are required for Standard (new STANDARD newlist). For example, resource names for cases where automation is impossible. V2.3.1 includes several configuration members that are relevant for the Standard or selected rules (STANDARD, CONFIGS, CONFIGW, and CONFIGX).
      • History (AU.R.H) provides you with an overview of all assertions, based on input from the allocated ASSERT data sets using the ASSERT newlist. Line commands enable you to re-specify (and retract) existing assertions or overrides.
      • If you develop your own rule(s), you can use test rule (AU.R.T); it combines all functions for a specified rule member.
  • Compliance Monitoring: Setup fields and preamble CARLa statements:
    • ASSERT data sets allocated using TYPE=ASSERT are used for input. You can use multiple specifications. If you use the DSNPREF keyword, the prefix specification can also be used to specify an output data set.
    • ASSERT data sets allocated using TYPE=OUTPUT can be used as target of a SAVE statement. For new data sets, you can control size and attributes of the data set through keywords. You can use new keyword POSTPONE to delay allocating the output data until it is actually needed.
    • New newlist type STANDARD provides a static view of the definition of standard, including current assertions. It enables you to quickly manage configuration setting and tests that are not automated and need an assertion. It shares many fields with the COMPLIANCE newlist.
    • New newlist type ASSERT provides reports about previous assertions, showing overviews of who, when, and what of assertions and enables you to re-assert (including retraction) of an existing assertion
  • Compliance testing and reporting is updated to STIG level 6.36 and includes many new compliance rules. In cases that cannot be automated, you can use assertions.
  • STIGPLUS was renamed to zSecure Extra and now also has reports or rules about CF-structures and GDPR-related reports or rules.
  • Names of MQ objects have been changed to object in qmgr qmgr.
  • In CARLa SIMULATE syntax, you can use sensitivities that end in an underscore (intended for IBM use, to allow specification of not (yet) automated resources) and you can use a pattern for the resource name.
• Pervasive Encryption:
  • The ICSF_SYMKEY (UI option RE.K.S) report ws updated to include the number of migrated data sets and backup copies that use the KeyLabel.
  • To support zFS file system encryption, newlists SYSTEM and MOUNT now include several new fields. You can find example output in AU.S (or RE.O.S) and RE.U.M.
  • Db2 use of key labels for tables and table spaces: encryption at the data set level.
  • Coupling Facility Encryption: Reporting (RE.K.C) by CKRCARLA provides a sysplex view. XCF can maintain the last key-change dates (requires OA54283).
  For details, see the announcement: IBM z/OS Version 2.3 - Engine for digital transformation.
• zERT - z Encryption Readiness Technology:
  Support for SMF 119-12 connection encryption summary records: populates 76 existing fields the same as 119-11 for zERTcommon, TLS, SSH, IPsec, and DN sections and there are several new fields.
• Near Real-Time (NRT) QRadar and other SIEM support without logstreams and INMEM:
  • This new functionality enables SIEM NRT feed for sites that do not have SMF logstream implemented. It shares SMF intercept exits with C2POLICE. A new option is available in CKQRADAR parameter member CKQSPECL.
  • The new address space (CKQEXSMF) must be running before starting CKQRADAR. It uses similar buffering technique as C2POLICE, with the maximum of 32 GB. Data is retrieved from the start of CKQEXSMF and the restart point is maintained per retrieving JOBNAME.
  • Full event audit trail in ArcSight CEF format. The CKQCEF procedure is similar to CKQRADAR:
    • Dedicated data conversion and configuration files; member names start with CKQCEF.
    • The preferred method is to use either INMEM or CKQEXSMF for near real-time data but the use of batch process and manual data transfer (sample job CKQCEFJD) is possible.
    • The new started task CKQCEF for near real-time supports TCP or UDP for data transfer.
  • Improved support in CKRCARLA for NRT SIEM and zSecure Alert:
    • Restart process and Operator Command response was improved and now supports all input sources, including the new CKQEXSMF.
    • Recovery for failing TCP/UDP connection for a limited number of retry attempts. Connect failures are remembered per destination.
  • TCP connection to QRadar can be encrypted using AT/TLS.
  • The SYSLOGTOFILE option no longer applies globally but per newlist.
  • Support of CDP as SMF input source was discontinued.
• zSecure CARLa enhancements:
  • Enhancements in data classification: SIMULATE can now also simulate programs and honors generic specifications in the data set name or resource name portion.
  • If the data set has multiple sensitivity types, CARLa now triggers all STIG controls for that data set and fills the SENSDSN newlist fields PRIV_SENSTYPE, PRIV_ACCESS, PRIV_PRIO, and PRIV_CONCERN.
  • SIMULATE SENSTIVE PROCLIB and LINKLIST are now always on; UI option prompts are eliminated.
  • The AU.S - MVS Extended - SENSITIVE displays SEN%ALL for sensitive data sets now show both the main categorization and all sensitivities if the data set is known to the system. The latter might be blank if the data is unavailable. In many cases, a low priority audit concern is also present.
  • New CSM_OWNER newlist (common storage vulnerabilities) reports on the owner or creator per allocated block (jobname etc.). RE.O.C combines CSM (reports on whole contiguous areas) and CSM_OWNER.
  • KDFAES support in Verify Password:
    A new process is provided to test passwords and phrases for being trivial or occurring in a dictionary. This new function is available for the ACTIVE RACF database only. Reporting can be done using a new report in AU.S - RACF user or using CARLa in a batch job.
  • Serialization in CKFCOLL and CKRCARLA has been enhanced to prevent additional concurrent access scenarios or data set not available messages.
  • Automatic fallback to primary RACF data set when the backup becomes unavailable. If this is used, the event is flagged with messages (CKR2158 and CKR2159).
  • Added SMF support for record types 42-6 (encryption and compression information), 80 (RACF records), 82-4x (ICSF key lifecycle events), 119-4 and IP_STACK updates for zERT.
  • New DB2_ACCESS newlist helps to automate DB2 compliance; writing compliance controls for DB2 authorization.
• ISPF User Interface (UI) changes:
  • SORT and FIND arguments need not to be typed in; prefix is enough, or putting the cursor on the column header and pressing Enter.
  • Add LEVEL to EV selections.
  • Add APPLDATA to RA.R selection.
  • Display hashing algorithm that is used for signing certificates.
  • AU.S password age reporting. Password and pass phrase age reports now use new CARLa fields PASSDATE_EFFECTIVE and PHRDATE_EFFECTIVE; field is empty if user does not have a password or phrase.
• Improved ACF2 support:
  • AA.L (logonid) now also supports OMVS information and reports with site-defined fields (or extra ACF2-defined fields).
  • AA.S (infostorage) now also supports SAFDEF overrides. SAFDEFs from all SYSIDs are displayed from the info storage database. SAFELIST / PROTLIST display for CICS is now also supported.
  • RE.U (UNIX resource) displays ACF2 logonids with UNIX uid or gid on file ownership.
  • CICS_REGION: collect incore MUSASS-level generic SAFDEFs for CICS region resource types and current ACF2/CICS validation and typecode settings set by CICSKEY statements, C-CIC records, and ACFM local overrides.
• zSecure Access Monitor:
  • SIM_VIA improvements:
    zSecure now recognizes events where RACF does not use a profile, but instead uses the RTOKEN to directly grant access. These events are reported as QUALOWN. AM.3 (RACF_ACCESS) no longer includes these events. For console commands, z/OS uses ID *BYPASS* when calling RACF; zSecure now sets return code to 4 and sets SIM_VIA to NOTHING.
    For RACDEF events, the zSecure simulation code often assigned blank; zSecure now uses SIM_VIA=CLAUTH or SIM_VIA=QUALOWN if HLQ matches.
  • For some event types, RACF does not provide ACCESS_ALLOWED. zSecure reports previously showed the value NONE; if not available, zSecure now shows <missing>.
  • You must update your production members to effectuate the updates in the following samples:
    • C2PECDTE: OtherMonth: Optional month indicator (format YYMM) indicating the month to be consolidated.
    • C2PAMP: ConsolidateMember is now set to C2PAMCVT.
  • Data Collector STC code is shared between C2PACMON, C2POLICE, and CKQEXSMF. The startup code was enhanced to recover from incorrect control block information that was caused by a previous incomplete or failed shutdown. The data collection code was improved to reduce buffer-lock situations and a new DEBUG BUFLOCK function might help to determine the cause for these buffer-lock events. Use of CPOOL services was improved to reduce possible no-cell-available situations.
• zSecure Alert:
  New skeleton member C2PXFMSG in C2PCUST can be used to format/override the C2PXSUB1 and C2PXHDR1 values for specific alert destinations and C2PXDEF1 in C2PCUST, intended for installation specific CARLa in the Pre-Processing and Reporting phases. C2PSGLOB is no longer used for COMPAREOPT. Alert now supports DEBUG BUFFER(DETAIL) to show the number of the SMF records that were collected.
• zSecure Server:
  Processing of ZSECNODE=* or ZSECSYS=* has been made more consistent and endless client WAITs are now terminated after four occurrences, and CKN192 messages are timed more accurately.
• zSecure Command Verifier:
  In some scenarios, the Command Audit Trail was shown for a discrete profile, even if the terminal user requested a generic profile. The code was improved to locate the requested best fitting profile.
• zSecure RACF-Offline:
  RACF commands in RACF-Offline no longer trigger Alerts in zSecure Alerts, error messages when using a non-APF STEPLIB are eliminated, and default DIGTCERTs are installed when and empty RACF database is used.
• zSecure Visual:
  Easy selection on authentication method MFA, password users, and revoke or inactive status. Also, switch password fallback from Action and Properties menus.
• JES3:
  JES3 Spool data sets are recognized if dynamically allocated and JES3 INISH deck data set name retrieved even if already freed.