IBM Security Z Security

Expand all | Collapse all

zSecure Alerts & Command Logger

  • 1.  zSecure Alerts & Command Logger

    Posted Thu January 07, 2021 08:23 AM

    While using zSecure Alert, I noticed that some of the built-in alert IDs based around SMF events for RACF Commands (for example, #1119​ / Non-expiring password enabled) do not have Command Logger information build-in the alert body text.

    Thinking about attempting to have this information, I believe I'd have to create and modify my own custom alerts based on "newlist type=CKXLOG, with similar criteria to these alerts parsing the "command" string to have the "ticket_id" and "ticket_desc" fields available.

    Before opening any RFEs, am I on the right track with my thinking here? And, is there any way to potentially tie the "SMF" event to the "CKXLOG" data?

    The thought is that we'd want the Command Logger information if it exists, so we have an idea of "why" someone issued a command that triggered an active alert.

    Adam Klinger

  • 2.  RE: zSecure Alerts & Command Logger

    Posted Mon January 11, 2021 06:05 AM
    Edited by Rob van Hoboken Mon January 11, 2021 06:06 AM
    Hi Adam
    There is currently no mechanism to read CKXLOG records into zSecure Alert or into zSecure Adapters for SIEM.  Furthermore, functions and fields designed to process fields from RACF commands in TYPE=SMF do not work for CKXLOG records, making it harder to create reports, alerts or SIEM messages for these records.  And finally, there is no correlation between SMF records and CKXLOG records.
    CKXLOG was designed in response to a request from a customer to get quick access to ticket information, without having to trawl through months (or years) of SMF, from multiple LPARs.
    Please discuss your requirements using an RFE.

    Rob van Hoboken

  • 3.  RE: zSecure Alerts & Command Logger

    Posted Wed January 13, 2021 09:09 AM
    Thanks Rob for the response, if there is no current support then that saves me the hassle of attempting!

    I'd most be interested in cross-referencing the related CKXLOG record to find the potential "why" on a command was issued, but in lieu of that support someone can always log into the applicable system and use zSecure's CR.2 to query it.

    Adam Klinger