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.  Access Monitor - Permission Usage

    Posted Tue August 08, 2023 12:45 PM

    The AM.3 screens in ISPF shows based on the AM data when the last time a permission was used.      Looking at the data dictionary it seems the RESOURCE name is a field for that record type.

    We are running some of the TRUSTED reports and noticed some of the TRUSTED datasets are using for example the "SYS1.**" profile.    Using AM.3 I see permissions for "SYS1.**" are being used.     I was curious if I could copy the Carla from AM.3 and list the actual resource that was being authorized to "SYS1. **"      I want to see what dataset is hitting the "SYS1.**" profile along with the permission in the profile it is using.

    Or is there a better way of doing this?

    Thanks



    ------------------------------
    Linnea Sullivan
    ------------------------------


  • 2.  RE: Access Monitor - Permission Usage

    Posted Tue August 08, 2023 04:28 PM
    Edited by Guus Bonnes Tue August 08, 2023 04:36 PM

    The RESOURCE in AM.3 is not really useful. For that SYS1.** profile, it might be a long repeated list of all matching resources. But in fact, the resource field is almost always empty :-(    I did not check what we document for that field, and I don't immediately remember what the design was.

    It's probably easier to use the ACCESS newlist, as used for AM.1. I played a bit with the summary statement, and applied a select on SIM_VIA (ID_USER or ID_GROUP). The profile shown (ACCESS_PROFILE) is the historic profile, but you could also replace by SIM_PROFILE to get the one in the current database.

    newlist type=access nodetailinherit required                             
     define tot_count("Occurrence",10,udec$abbr) sum(access_count_big)       
     define avg_reclen avg(record_length)                                    
     define first_tod_sum(,"First occurrence") min(last_datetime)            
     define last_tod_sum(,"Last occurrence") max(last_datetime)              
     define poesep(1,":",hdr$blank) boolean    where exists(utoken_poeclass) 
    select sim_via=(ID_USER, ID_GROUP), REQ_STATUS_ACCESS=NO,                                     
           resource=SYS1.LINKLIB                                             
     dsummary   class(nd)  tot_count class,                                  
               first_tod_sum last_tod_sum,                                   
             * access_profile(nd) tot_count(noprop),                         
               access_profile(246),                                          
             * resource(nd) tot_count(noprop) resource(246),                 
             * intent_raw(nd) rectype(nd) access_result(nd),                 
               tot_count(noprop) intent(8),                                  
               rectype,                                                      
               req_status_access(6,hb),                                      
               access_result(5,"AccRC",dec),                                 
             * tot_count(noprop,nosortlist),                                 
               userid userid:name jobname,                                   
             * tot_count(noprop,nosortlist) sim_via,                         
             * tot_count(noprop,nosortlist) sim_via_groups                   

    Which gives me at the detail level report:

    An alternative selection might be:

    select sim_via=(ID_USER, ID_GROUP), req_status_access=no,   
           access_profile='SYS1.**'                             

    Hope this helps.



    ------------------------------
    Guus Bonnes
    ------------------------------



  • 3.  RE: Access Monitor - Permission Usage

    Posted Wed August 09, 2023 02:26 PM

    Guus, this is great.  Is there a way to run in batch but put all the data for each resource/userid on an individual record.  I'd like to load this in Excel and other usage.

    Also, what does the "REQ_STATUS_ACCESS=NO" statement do?

    Thank you,



    ------------------------------
    Brent Brimacomb
    ------------------------------



  • 4.  RE: Access Monitor - Permission Usage

    Posted Thu August 24, 2023 04:23 AM
    Edited by Rob van Hoboken Thu August 24, 2023 04:46 AM

    Guus used the DSUMMARY command to Display the summary results.  On a 3270 this allows a drill down into (lower) summary levels, so different summary keys are shown on different screens.  If you run the same command in batch, or add the DISPLAYTOLIST option, the summary keys are on different lines.  Summary levels are separated by * in the SUMMARY command.  The fields with (ND) are used to sort (order) the output of a summary level, or to disable sorting on the a COUNT column.

    If you want a printable report with all summary keys on the same line, you must use the SUMMARY command and reorder the field names in the summary command, removing the * between them.  Within each summary level of the SUMMARY command, there can only be non-repeated fields, or one (1) repeated field.  SIM_VIA_GROUPS  lists all groups that could have allowed access, so it is a repeat field and cannot be specified in the same summary level/line as access_profile or userid.  If you were only interested in one of those group names, you could show only the first value of the repeated field  by adding (firstonly) after the fieldname.

    newlist type=access dd=report ll=800 header=tsvt
     define tot_count("Occurrence",10,udec$abbr) sum(access_count_big)       
     define avg_reclen avg(record_length)                                    
     define first_tod_sum(,"First occurrence") min(last_datetime)            
     define last_tod_sum(,"Last occurrence") max(last_datetime)              
     define poesep(1,":",hdr$blank) boolean    where exists(utoken_poeclass) 
    select sim_via=(ID_USER, ID_GROUP), REQ_STATUS_ACCESS=NO,                                     
           resource=SYS1.LINKLIB                                             
     summary   class,                                  
               first_tod_sum last_tod_sum count,                                   
             access_profile(0),                                          
             resource(0),                 
             intent,                                
               rectype,                                                      
               req_status_access(6,hb),                                      
               access_result(5,"AccRC",dec),                                 
               userid userid:name jobname,                                   
               sim_via,                         
               sim_via_groups(firstonly) 

    You need a data set with a high LRECL value, I'm guessing about 800.  And I haven't tried this for syntax failures.  Now, if you want to export this for use in Excel, you want separators.  Personally, I prefer to use the TAB character between field values, so I use header=tsvt, but you could opt for comma separated by changing this into header=csvt

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



  • 5.  RE: Access Monitor - Permission Usage

    Posted Wed August 09, 2023 03:28 PM

    Guus, this is something I could use, but need to load it into Excel.   Is there a way to keep the counts but keep all the data on a single row/record for each access?

    One other question:  What does the statement "REQ_STATUS_ACCESS=NO" do for it.

    Thank you!

    Brent Brimacomb



    ------------------------------
    Brent Brimacomb
    ------------------------------



  • 6.  RE: Access Monitor - Permission Usage

    Posted Wed August 23, 2023 04:05 AM

    Hi Brent,

    The SELECT statements select the records that are relevant for the report.

    The select clause "REQ_STATUS_ACCESS=NO" limits the selection to those records that have NO as the value for that field.

    The documentation for the field is here: https://www.ibm.com/docs/en/szs/2.5.0?topic=records-access-field-descriptions#select_list_fields_access_field_descs__REQ_STATUS_ACCESS

    As I read it, this means that the report is about "real" direct access attempts while excluding queries as to what the access level of a user to a particular resource is.

    HTH,



    ------------------------------
    Jeroen Tiggelman
    IBM - Software Development and Level 3 Support Manager IBM Security zSecure Suite
    Delft
    ------------------------------



  • 7.  RE: Access Monitor - Permission Usage

    Posted Thu August 24, 2023 04:36 AM
    Edited by Rob van Hoboken Thu August 24, 2023 04:46 AM

    Like Jeroen said, this option removes confusing events from the report.  You may have noticed that RACF administrators show up in ACCESS reports, apparently accessing numerous data sets and resources with INTENT=ALTER.  This would happen each time the admin issues a LISTDSD or RLIST command for the data set or resource, because the RACF command output includes a field your access.  To fill in the your access value, the RACF command executes a RACHECK with STATUS=ACCESS.  This would show up in the report alleging the administrator attempted to delete the data set. 

    Note, some menu applications rely on the result of the access check to configure the options presented to users, so do not suppress these events when doing a database cleanup.

    ACCESS events with REQ_STATUS_ACCESS=YES could also point to users skillfully exploring your system, while staying under the (SMF) radar.

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