Trying to make sure I understand z/Secure and "simulated fields selection".

I am using access monitor records (monthly rollup) from the AM.1 screen to check activity on class DATASET profile SYS1.RACF.**, selecting "simulated fields selection" and then selecting "UACC".

Does this run all the access monitor records found within the monthly rollup for that resource and check them against the current RACF DB and report if UACC would be used to grant access? Inferring, if no RACF DB changes have been made, then UACC was not used at the time of the access recoreds were created.

The documentation makes it sound like that is the case.

------------------------------
Peter Ten Eyck
------------------------------

Hi Peter,

Yes, you are spot on with your analysis.

When you use option AM.1 and select simulated field "UACC", the collected historic access events from your monthly roll up ACCESS data set are simulated running today against the RACF input source that you allocated in setup files (option SE.1) of your zSecure session. When that query comes up empty, that indeed means that nobody got access to SYS1.RACF.** data sets trough the defined UACC, provided that no changes are made to the dataset profile(s) that protect(s) these SYS1.RACF.** data sets. 

------------------------------
Tom Zeehandelaar
z/OS Security Enablement Specialist - zSecure developer
IBM
Delft
+31643351728
------------------------------

Hi Peter
When you enter SYS1.RACF.** on the selection screen from AM.1, you select all profiles that MATCH that pattern, i.e., you could see SYS1.RACF.PRIM* and SYS1.RACF.BACKUP profiles listed.  If you only want the single generic profile, you could add quotes around the pattern, like 'SYS1.RACF.**'

The Simulated field selections use the RACF database to explain why an access event occurred.  As you know, ACCESS records show the INTENT, ALLOWED ACCESS, RESOURCE NAME and PROFILE, but not the permit (or privilege) that was used.  To help you understand which permit, or UACC for that matter, the current RACF database (the one selected from SE.1) is used to figure out why access was (or could have been) granted.  If no permit can explain the access, no GLOBAL profile present and INTENT <= UACC, then SIM_VIA would implicate UACC as the reason for successful access.

If your intent is to remove access via UACC, you would add PERMITs in your database, run AM.1 with your updated database, spot remaining SIM_VIA=UACC cases, add more permits (or connect remaining users to appropriate groups), and try again.

If you wanted to explain why a user has inappropriate access (to your RACF database), look at the SIM_VIA reason, using the current RACF database, or a backup at the time of the successful access event.  Look at all the possible SIM_VIA values in the help panel (or pdf documentation).

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

May intent is to verify that read access to SYS1.RACF.** was not allowed via UACC READ.

I am thinking, by using access monitor records (monthly rollup) from the AM.1 screen to check activity on class DATASET profile SYS1.RACF.**, selecting "simulated fields selection" and then selecting "UACC"... this will show that the past month access of that resourece did not use UACC to grant access.

@Rob, I am not sure I fully understand your post. ​

------------------------------
Peter Ten Eyck
------------------------------

Original Message:
Sent: Tue November 08, 2022 03:01 AM
From: Rob van Hoboken
Subject: z/Secure and "simulated fields selection"

Hi Peter
When you enter SYS1.RACF.** on the selection screen from AM.1, you select all profiles that MATCH that pattern, i.e., you could see SYS1.RACF.PRIM* and SYS1.RACF.BACKUP profiles listed.  If you only want the single generic profile, you could add quotes around the pattern, like 'SYS1.RACF.**'

The Simulated field selections use the RACF database to explain why an access event occurred.  As you know, ACCESS records show the INTENT, ALLOWED ACCESS, RESOURCE NAME and PROFILE, but not the permit (or privilege) that was used.  To help you understand which permit, or UACC for that matter, the current RACF database (the one selected from SE.1) is used to figure out why access was (or could have been) granted.  If no permit can explain the access, no GLOBAL profile present and INTENT <= UACC, then SIM_VIA would implicate UACC as the reason for successful access.

If your intent is to remove access via UACC, you would add PERMITs in your database, run AM.1 with your updated database, spot remaining SIM_VIA=UACC cases, add more permits (or connect remaining users to appropriate groups), and try again.

If you wanted to explain why a user has inappropriate access (to your RACF database), look at the SIM_VIA reason, using the current RACF database, or a backup at the time of the successful access event.  Look at all the possible SIM_VIA values in the help panel (or pdf documentation).

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

Hi Peter, a key point that may help is to be clear about your goal "verify that access to SYS1.RACF.** -was- not allowed via UACC READ".  AM records do not know whether the access at the time -was- via a UACC. The subsequent zSecure analysis of those AM records and your current database (or whatever database you feed in )  can determine if -that- RACF database would allow access via a UACC.   So the question that zSecure is answerering is -that- RACF database does not (or does) allow access via a UACC.     Your statement that the RACF database has not changed in any way is what then allows you to assert "that historic access -was- not via a UACC".  

And yes I believe we are all saying the same thing, just slightly different words. (isn't English "fun"?)

------------------------------
Simon Dodge
------------------------------

Original Message:
Sent: Tue November 08, 2022 08:18 AM
From: Peter Ten Eyck
Subject: z/Secure and "simulated fields selection"

May intent is to verify that read access to SYS1.RACF.** was not allowed via UACC READ.

I am thinking, by using access monitor records (monthly rollup) from the AM.1 screen to check activity on class DATASET profile SYS1.RACF.**, selecting "simulated fields selection" and then selecting "UACC"... this will show that the past month access of that resourece did not use UACC to grant access.

@Rob, I am not sure I fully understand your post. ​

------------------------------
Peter Ten Eyck
------------------------------


Original Message:
Sent: Tue November 08, 2022 03:01 AM
From: Rob van Hoboken
Subject: z/Secure and "simulated fields selection"

Hi Peter
When you enter SYS1.RACF.** on the selection screen from AM.1, you select all profiles that MATCH that pattern, i.e., you could see SYS1.RACF.PRIM* and SYS1.RACF.BACKUP profiles listed.  If you only want the single generic profile, you could add quotes around the pattern, like 'SYS1.RACF.**'

The Simulated field selections use the RACF database to explain why an access event occurred.  As you know, ACCESS records show the INTENT, ALLOWED ACCESS, RESOURCE NAME and PROFILE, but not the permit (or privilege) that was used.  To help you understand which permit, or UACC for that matter, the current RACF database (the one selected from SE.1) is used to figure out why access was (or could have been) granted.  If no permit can explain the access, no GLOBAL profile present and INTENT <= UACC, then SIM_VIA would implicate UACC as the reason for successful access.

If your intent is to remove access via UACC, you would add PERMITs in your database, run AM.1 with your updated database, spot remaining SIM_VIA=UACC cases, add more permits (or connect remaining users to appropriate groups), and try again.

If you wanted to explain why a user has inappropriate access (to your RACF database), look at the SIM_VIA reason, using the current RACF database, or a backup at the time of the successful access event.  Look at all the possible SIM_VIA values in the help panel (or pdf documentation).

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

Rob,

Reading your post again, more closely ;)... I am thinking you are agreeing with Tom.

When I run I access monitor records (monthly rollup) from the AM.1 screen to check activity on class DATASET profile SYS1.RACF.**, selecting "simulated fields selection" and then selecting "UACC" and the results are empty, that does indeed mean that UACC was not used to grant access.

Note: RACF DB not changed.

------------------------------
Peter Ten Eyck
------------------------------

Original Message:
Sent: Tue November 08, 2022 03:01 AM
From: Rob van Hoboken
Subject: z/Secure and "simulated fields selection"

Hi Peter
When you enter SYS1.RACF.** on the selection screen from AM.1, you select all profiles that MATCH that pattern, i.e., you could see SYS1.RACF.PRIM* and SYS1.RACF.BACKUP profiles listed.  If you only want the single generic profile, you could add quotes around the pattern, like 'SYS1.RACF.**'

The Simulated field selections use the RACF database to explain why an access event occurred.  As you know, ACCESS records show the INTENT, ALLOWED ACCESS, RESOURCE NAME and PROFILE, but not the permit (or privilege) that was used.  To help you understand which permit, or UACC for that matter, the current RACF database (the one selected from SE.1) is used to figure out why access was (or could have been) granted.  If no permit can explain the access, no GLOBAL profile present and INTENT <= UACC, then SIM_VIA would implicate UACC as the reason for successful access.

If your intent is to remove access via UACC, you would add PERMITs in your database, run AM.1 with your updated database, spot remaining SIM_VIA=UACC cases, add more permits (or connect remaining users to appropriate groups), and try again.

If you wanted to explain why a user has inappropriate access (to your RACF database), look at the SIM_VIA reason, using the current RACF database, or a backup at the time of the successful access event.  Look at all the possible SIM_VIA values in the help panel (or pdf documentation).

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

> selecting "UACC" and the results are empty, that does indeed mean that UACC was not used to grant access.

That is right.  Now, if you look at the VIA field in the other successful ACCESS events, you will see why those were allowed.  You can speed up the analysis by selecting "3.Summary by simulated authorization used" in the output/run options, this will show you the different reasons used.

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

Original Message:
Sent: Tue November 08, 2022 08:52 AM
From: Peter Ten Eyck
Subject: z/Secure and "simulated fields selection"

Rob,

Reading your post again, more closely ;)... I am thinking you are agreeing with Tom.

When I run I access monitor records (monthly rollup) from the AM.1 screen to check activity on class DATASET profile SYS1.RACF.**, selecting "simulated fields selection" and then selecting "UACC" and the results are empty, that does indeed mean that UACC was not used to grant access.

Note: RACF DB not changed.

------------------------------
Peter Ten Eyck
------------------------------


Original Message:
Sent: Tue November 08, 2022 03:01 AM
From: Rob van Hoboken
Subject: z/Secure and "simulated fields selection"

Hi Peter
When you enter SYS1.RACF.** on the selection screen from AM.1, you select all profiles that MATCH that pattern, i.e., you could see SYS1.RACF.PRIM* and SYS1.RACF.BACKUP profiles listed.  If you only want the single generic profile, you could add quotes around the pattern, like 'SYS1.RACF.**'

The Simulated field selections use the RACF database to explain why an access event occurred.  As you know, ACCESS records show the INTENT, ALLOWED ACCESS, RESOURCE NAME and PROFILE, but not the permit (or privilege) that was used.  To help you understand which permit, or UACC for that matter, the current RACF database (the one selected from SE.1) is used to figure out why access was (or could have been) granted.  If no permit can explain the access, no GLOBAL profile present and INTENT <= UACC, then SIM_VIA would implicate UACC as the reason for successful access.

If your intent is to remove access via UACC, you would add PERMITs in your database, run AM.1 with your updated database, spot remaining SIM_VIA=UACC cases, add more permits (or connect remaining users to appropriate groups), and try again.

If you wanted to explain why a user has inappropriate access (to your RACF database), look at the SIM_VIA reason, using the current RACF database, or a backup at the time of the successful access event.  Look at all the possible SIM_VIA values in the help panel (or pdf documentation).

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

Thanks for the help.

------------------------------
Peter Ten Eyck
------------------------------

Original Message:
Sent: Tue November 08, 2022 08:59 AM
From: Rob van Hoboken
Subject: z/Secure and "simulated fields selection"

> selecting "UACC" and the results are empty, that does indeed mean that UACC was not used to grant access.

That is right.  Now, if you look at the VIA field in the other successful ACCESS events, you will see why those were allowed.  You can speed up the analysis by selecting "3.Summary by simulated authorization used" in the output/run options, this will show you the different reasons used.

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


Original Message:
Sent: Tue November 08, 2022 08:52 AM
From: Peter Ten Eyck
Subject: z/Secure and "simulated fields selection"

Rob,

Reading your post again, more closely ;)... I am thinking you are agreeing with Tom.

When I run I access monitor records (monthly rollup) from the AM.1 screen to check activity on class DATASET profile SYS1.RACF.**, selecting "simulated fields selection" and then selecting "UACC" and the results are empty, that does indeed mean that UACC was not used to grant access.

Note: RACF DB not changed.

------------------------------
Peter Ten Eyck


Original Message:
Sent: Tue November 08, 2022 03:01 AM
From: Rob van Hoboken
Subject: z/Secure and "simulated fields selection"

Hi Peter
When you enter SYS1.RACF.** on the selection screen from AM.1, you select all profiles that MATCH that pattern, i.e., you could see SYS1.RACF.PRIM* and SYS1.RACF.BACKUP profiles listed.  If you only want the single generic profile, you could add quotes around the pattern, like 'SYS1.RACF.**'

The Simulated field selections use the RACF database to explain why an access event occurred.  As you know, ACCESS records show the INTENT, ALLOWED ACCESS, RESOURCE NAME and PROFILE, but not the permit (or privilege) that was used.  To help you understand which permit, or UACC for that matter, the current RACF database (the one selected from SE.1) is used to figure out why access was (or could have been) granted.  If no permit can explain the access, no GLOBAL profile present and INTENT <= UACC, then SIM_VIA would implicate UACC as the reason for successful access.

If your intent is to remove access via UACC, you would add PERMITs in your database, run AM.1 with your updated database, spot remaining SIM_VIA=UACC cases, add more permits (or connect remaining users to appropriate groups), and try again.

If you wanted to explain why a user has inappropriate access (to your RACF database), look at the SIM_VIA reason, using the current RACF database, or a backup at the time of the successful access event.  Look at all the possible SIM_VIA values in the help panel (or pdf documentation).

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