IBM Security Z Security

Expand all | Collapse all

CKFREEZE with SIEM Adapters

  • 1.  CKFREEZE with SIEM Adapters

    Posted Fri February 05, 2021 03:30 PM
    Edited by Phillip Allison Fri February 05, 2021 11:35 PM


    We recently began the implementation of zSecure SIEM Adapters to emit SMF80 records to QRADAR.  At this stage of our implementation, we have some questions related to CKFREEZE.  Has anyone addressed these before? If so I'd be interested to hear how.


    • To provide enrichment of the SMF 80s, we've noticed the overhead of running CKFCOLL with a FULL SIZE CKFREEZE.   We are not sure about what would be best, running a daily FULL with SHARED=YES on one image in a syslex and a daily partial for the other images.  It seems there would be duplication of VTOC/VVDS data if using SHARED=YES & run the same way on all other images in the same plex.
      • It's not clear what level of data capture is needed within images of a sysplex sharing 100% of the data
      • What frequency should a fresh CKFREEZE be generated (daily versus weekly), what are the risks of enriching SMF80s produced on a Friday with stale CKFREEZE from a prior Sunday?
      • What level of CKFREEZE capture is minimally needed when using the SIEM adapters for SMF80s?
    • Concerns over RACF enqueues when running CKFCOLL – can this run against the RACF backup database or an unloaded version.



    Thank You,


    Phil Allison

  • 2.  RE: CKFREEZE with SIEM Adapters

    Posted Mon February 08, 2021 06:22 AM
    Edited by Rob van Hoboken Mon February 08, 2021 06:24 AM
    Hi Phil
    If you only plan to process SMF 80 in your CKQRADAR process (or CKQCLEEF based batch jobs), the need for a full CKFREEZE is reduced. 
    With Adapters for SIEM in mind, CKFREEZE info is used for:
    1. identifying critical  (or sensitive) data sets and resources, such that the SENSTYPE for data sets and resources can be included in the LEEF records (using the sens= field), helping QRadar users find the events that merit more attention.
    2. finding the right RACF profile for data set activity, because some SMF records contain a VSAM component name, not the cluster, and also zSecure wants to be sure the data sets are not protected by a discrete DATASET profile,
    3. finding the UNIX_PATHNAME for Unix file names, SMF 80 contains the UNIX_FILENAME and inode, but not the full path name.
    However, if you process only SMF 80, the profile has already been found (by RACF) so we do not depend on reason 2.  That means, you could get away with running CKFCOLL using VTOC=N,VVDS=N (or alternatively SHARED=N) in addition to options MCD=N,BCD=N,DMS=N,ABR=N,TMC=N,RMM=N,VMF=N that are generally useful in the context of the SIEM Adapters.
    Switching off the VTOC collection causes CKRCARLA to complain bitterly about incomplete CKFREEZE, with messages CKR2226.  You should add a command at the beginning of your CKQSPEC(L) member to ignore this message (if you decided to use an incomplete file)
    SUPPRESS MSG=(2226)
    However, if you add other SMF record types in future, for each type you should consider if you would need the finding RACF profile function or the automatic SENSTYPE calculation, and if so, remove some CKFCOLL options.

    CKFCOLL does not allocate or read the RACF database.  It does not ENQ the RACF database. 
    Now, the CKRCARLA program running in CKQRADAR does read RACF profiles, from active primary, active backup/duplex or a zSecure maintained UNLOAD data set.  With only the Adapters for SIEM enabled, you cannot generate a zSecure UNLOAD, so you're stuck with the active data sets.  For your peace of mind, you can code an ALLOC TYPE=RACF BACKUP in your CKQSPEC(L) member.

    Rob van Hoboken