Roy, I think in the case of discovering resources that are currently
not defined to TSS (but are otherwise
currently in use, with access being granted solely due to RC=04 from the auth check), the use of the AUDIT record would
not be effective. Reason: you have to know the name of the resource to add to the AUDIT record, and in this case the resnames are not known. To
discover the resnames being accessed, one must turn on DEFPROT, which requires a catch-all permission in the ALL record, with ACTION(AUDIT), so that you can log/discover what's been accessed without the DEFPROT causing a not-authorized condition.
There may be other alternatives -- and I'm the first to admit that I often latch on to what has worked for me without seeking those alternatives -- but using DEFPROT and the catch-all permission in the ALL record seems to be the most straightforward way to discover
all of the resnames in use that need to be owned/permitted. Another benefit with this method is that, once other permissions are deployed (that override the ALL record catch-all permission), the auditing stops for the users who have these new permissions once those new permissions take effect. In cases where the access volume is substantial, this benefit can be critical.
This is a good discussion!
------------------------------
Joe Denison
joe@tssadmin.comCA Top Secret z/OS Productivity Specialist
Access Solutions, Inc.
Kansas City, Missouri / USA
------------------------------
Original Message:
Sent: 05-03-2021 10:05 AM
From: ROY Young
Subject: Audit SAF RC=4 Events
Another suggestion would to add the resource to the AUDIT record instead of the ALL record to review the accesses.
------------------------------
Roy Young
Original Message:
Sent: 04-30-2021 11:27 AM
From: Joe Denison
Subject: Audit SAF RC=4 Events
I agree! In concept, implementing DEFPROT is a straightforward process: you place some discovery permissions in the ALL record, activate DEFPROT in the RDT, track access for a while, then assess the usage and place permissions based on observed access and deploy permissions (outside of the ALL record) to accommodate that access. The goal is that eventually all access is being granted via your newly-deployed permissions, and then eventually you can revoke the discovery permission from the ALL record as the final step where then you would truly have the DEFPROT in place.
But many factors can turn it into a very complex endeavor. Things like:
- If the resource names of the RESCLASS are already in use and some (but not all) have already been defined to TSS (in this case, placing your discovery permission in the ALL record would open up access to those resources already owned…additional permissions are needed to ensure those resources remain secure)
- the RESCLASS has an access level associated with it (the discovery permission needs to accommodate all access levels)
- The programs performing auth checks against this RESCLASS may utilize LOG=NONE or LOG=NOFAIL – if so, you won't get audited events from these auth checks. Very difficult case.
- High volume of current usage (extremely high volume can be difficult to assess/manage) – you'll want to have something in place to summarize this data to a manageable size.
- Determining where to place the permissions – if you have hundreds/thousands of users, you'll want some way to determine the best place to provision the access for them (i.e., what profiles do they have in common, and which of those profiles seems most appropriate for these new permissions?).
- Generating the permissions – you'll want something that can help you to convert the TSSUTIL data into TSS PERMIT commands so that you can deploy the access that you've observed. And, since you will likely want to deploy the permissions to profiles (vs. directly to the users), you'll want something to help you with identifying an appropriate profile acid as target of your permissions and to alter the destination of those permissions to that profile.
- Verifying readiness to complete the effort: you'll want some way of identifying if the temporary ALL record discovery permissions are no longer being used so that you can revoke them as the final step of your implementation. You'd likely want to verify that all previously observed access, should it occur again, would now be granted via (your newly deployed permissions) vs. being granted via the temporary discovery permission in the ALL record. This way you can be more assured that the risk of revoking the temp discovery permissions is minimized.
I have a more detailed demonstration of this process that includes solutions to the above items described, and I would be glad to show you – or anyone else who may be interested – via a zoom meeting or any online meeting tool of your choice.
------------------------------
Joe Denison
joe@tssadmin.com
CA Top Secret z/OS Productivity Specialist
Access Solutions, Inc.
Kansas City, Missouri / USA
Original Message:
Sent: 04-30-2021 09:46 AM
From: Horst Gfrerer
Subject: Audit SAF RC=4 Events
I think there is no easy way to audit SAF RC=4 events of a particular resource? Eg. if you want to DEFPROT a resource.