IBM Security Z Security

Security for Z

Join this online user group to communicate across Z Security product users and IBM experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

  • 1.  CKFREEZE with SIEM Adapters

    Posted 02/05/21 03:30 PM
    Edited by Phillip Allison 02/05/21 11:35 PM

    Hello,

    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 02/08/21 06:22 AM
    Edited by Rob van Hoboken 02/08/21 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
    ------------------------------


  • 3.  RE: CKFREEZE with SIEM Adapters

    Posted 01/22/26 02:30 PM

    This 'thread' and your 'reply' was so very helpful.  I have recently come to support zSecure at a client site and ran into a situation whereby the CKFREEZE regularly scheduled batch job was taking an inordinate abount of time looking thru Disk's that were recently decommissioned but still online.  With 60sec intervals before moving to the next Disk, it took a long time until the CKQRADAR STC woke up and tried to allocate the CKFREEZE daily file.  The GRS ENQ ensued and Operations ended up cancelling the CKFREEZE batch job. 

    Q: What guidelines or suggestions can be made to alleviate a situation like this again.  Do we automate and STOP CKQRADAR STC to run the batch CKFREEZE jobs?  Can we manipulate the runtime parameters used to reduce or alleviate these common ENQ's to the CKFREEZE file between the 24x7 CKQRADAR STC and the once-a-day batch scheduled CKFREEZE jobs?  Just looking for a general recommendation. 

    Many, many thanks for all your observations and review on this TechXchange community.  Very helpful. 

    Lynn Gilson  



    ------------------------------
    Lynn Gilson
    ------------------------------

    Original Message


  • 4.  RE: CKFREEZE with SIEM Adapters

    Posted 01/26/26 05:34 AM
    Edited by Rob van Hoboken 01/26/26 05:47 AM

    Hi Lynn

    First of all, please check that your customer has a recent version of zSecure installed (in this case, the CKFCOLL module).  I remember reading about fixes that make CKFCOLL more tolerant of devices that are unceremoniously decommissioned, though I cannot find the fix text quickly.  If their installed version is 3.1 or 3.2, ask IBM Support for help.

    Second, how to coordinate the maintenance of CKFREEZE information with its consumers.  The CKFREEZE data set should be refreshed on a daily basis, and during this process the data set is in limbo.  To prevent consumers from reading a partially filled (or even empty) CKFREEZE, CKRCARLA has a SERIALIZATION option.  This option makes the ALLOCATE command wait until the input data set is no longer being updated, though this obviously stalls the start-up of (reporting) tasks. Removing this SERIALIZATION option will cause nasty return codes for incomplete records or missing information, or even ABENDs, when CKFREEZE is being updated at the same time that CKRCARLA is reading it.

    Tasks like C2POLICE, CKQRADAR and CKQCEF have an hourly cycle, where CKFREEZE and the security database are read again at the start of each cycle.  If you can write a message to SYSLOG indicating the start of the reporting part of each cycle, your workload scheduling team could use this as a trigger to start their CKFCOLL job, provided this job ends in less than 60 minutes.  In fact, C2POLICE schedules its own C2PCOLL task to fill its own CKFREEZE data set, in a way that does not impact its reporting cycle. (**)

    Alternatively, you can experiment with actively synchronizing the start of CKQRADAR and CKQCEF cycles by issuing a MODIFY taskname,RESTART to these tasks.  This operator command tells the task to finish its SMF collection, write the last records, and start a new cycle.  Within a minute or so, the new cycle will start and you can refresh your CKFREEZE more or less safely.  See https://www.ibm.com/docs/en/szs/3.1.0?topic=siem-operation-ckqradar-ckqcef-started-task.

    The safest bet is to use a small CKFREEZE data set for these automated tasks, using CKFCOLL directives that limit the amount of information and thereby the size.  The optimal directives depend on the SMF record types that you need in your LEEF or CEF data stream.

    (**) If only IBM provided a mechanism or guidance to make this smallish CKFREEZE available for tasks like CKQCARLA and CKQCEF, with the synchronization concerns mentioned.  That would be an Idea.

    ------------------------------
    Rob van Hoboken
    ------------------------------

    Original Message


  • 5.  RE: CKFREEZE with SIEM Adapters

    Posted 01/27/26 12:14 PM

    Thank you very much for this review.  I've ordered zSecure for RACF 320 and will also order zSecure for ACF2 320 and will review all the components previously installed for this customer as we go thru the update install.  As they say, 'the devil (or angel) is in the details' and the details you describe are oh so important when supporting and exploiting all the wondeful features you and your team have developed for this critical security product.  Thanks again!  Best regards!   



    ------------------------------
    Lynn Gilson
    ------------------------------

    Original Message


Related Content