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.  Support of Custom Alerts

    Posted 6 days ago

    We have some concerns around producing our own custom alerts. 

    Firstly these will need support and the the alert process is perhaps more complex than mere CARla queries. We have seen that many custom alerts are modified versions of standard alerts. However, any maintenance applied to the base alert would likely also need to be applied to the custom alert based on it. This can be tricky.

    Secondly, we wonder if there is any store where proven custom alerts can be made public; thus avoiding re-inventing something someone else has done. 

    What do others think?

    Lennie



    ------------------------------
    Lennie Dymoke-Bradshaw
    ------------------------------


  • 2.  RE: Support of Custom Alerts

    Posted 2 days ago

    Hi Lennie,

    I understand your first point.  Perhaps someone on here with experience in this area can give some suggestions.  I don't think there is a place to store alerts that people create.  We have looked at this concept for other things but it is very difficult, especially from the legal side.  I'd be interested to hear what others think as well.



    ------------------------------
    Michael Zagorski
    Program Director - IBM Z Security
    IBM
    ------------------------------

    Original Message


  • 3.  RE: Support of Custom Alerts

    Posted yesterday

    I'm looking at this to add additional details to an alert.

     

    Example  Service Account,  who's the owner of the account is something we would like to be included.

    Same for TSO accounts,   since here TSO is a separate account from the Users Account as its deemed a Privileged account

    We keep this data in CSDATA for each account.

     

    As we get more into dataset/resource ownership same thing there.  Pulling the owner from CSDATA

    Also, Application it associated with.

     

    Basically augmenting existing alerts to make it easier for our SOC to reach out to the correct owner or management as appropriate.

     

     

     

     

    Thank you,

     

    Mainframe Security Engineering can not accept work request via eMail or Webex,  you must submit a MyIT request for Security Changes.

     

    Sandra Carroll

    ETS Technical Lead,
    Mainframe Security Engineering (MFSE)

    Enterprise Technology Services; Application Hosting
    Mainframe_Security_Engineering@navyfederal.org
    w 614-600-7053  


      

     

     




    Original Message


  • 4.  RE: Support of Custom Alerts

    Posted 11 hours ago
    Edited by Rob van Hoboken 11 hours ago

    Hi Sandra

    zSecure can use indirect reference or lookup to find CSDATA values.  This is described here.  There are two flavors of lookup:

    ID lookup This is used if you have a field containing a user ID or a group name, you could find the value of a CSDATA field $DEPT for the user causing an alert by adding 

    user:$DEPT

    to the alert skeleton.  This type of lookup does not work for fields containing DATASET or general resource profiles.

    Object property lookup zSecure associates a security object to events.  For SMF records describing data set access, that would be the DATASET profile protecting the data set.  For SMF records logging a RACF command, it would be the profile that was changed by the RACF command.  For RACINIT, it would be the user that logs on.

    For NEWLIST TYPE=RACF or RACF_ACCESS, the current profile is the security object.  You can display attributes of the security profile by using the implicit lookup for the attribute:

    newlist type=racf
      select class=user segment=omvs uid=0
      sortlist key("Userid",8) :special :operations :tmsize :tlsize :name :$DEPT

    This sample selects OMVS segments for the super users, and prints the special, operations and name attributes from the base segment, the maxsize and lastsize from the TSO segment, by implicit lookup.   If you have a CSDATA field $DEPT, it would be retrieved too.

    Similarly, you could add information about data sets to SMF reports, that's what most alerts are based on:

    newlist type=smf
      select event=access class=dataset
      sortlist date(7) time(4) dataset intent :uacc :$dept

    You may also combine the two lookup types to find the $DEPT of the subject and the object:

    newlist type=smf
      select event=access class=dataset
      sortlist date(7) time(4) user user:$DEPT("User dept") dataset intent :uacc :$DEPT("Application dept") :owner:$DEPT("RACF Owner's dept")

    If all this works, it is up to you to create installation defined alert skeletons, by copying the individual alerts that you need, assigning a new alert number starting with 4000, and modifying the skeleton to add more fields to the message.  Take guidance from the way user:name was shown in the alert emails, similarly you could add your $DEPT values.

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



  • 5.  RE: Support of Custom Alerts

    Posted 11 hours ago
    Edited by Rob van Hoboken 11 hours ago

    Hey Lennie

    Over the years, new alerts have been added and the corresponding members created in SCKRSLIB, however, after the big restructuring of skeletons, there have not been terribly many changes to existing alerts.  In other words, the effort to keep new installation defined alerts up to date with maintenance on the originals may be manageable. 

    I would suggest you create a PDS with the version of the IBM issued alert, at the time when the installation decided to clone it into an installation alert.  Call this your base version.  When maintenance is applied, use ISPF 3.12 to compare this base set PDS with the members in SCKRSLIB.  If you find differences, apply the same change to you installation alerts and update your base member.

    There was a time when a useful change log was kept in each member containing readable code, you could see the date when a change was made to the member and a suggestion of the type of change.  Right now, I'm noticing changes without corresponding change log, so ... stick with the ISPF 3.12 method. 
    ------------------------------
    Rob van Hoboken
    ------------------------------



Related Content