CA Top Secret

Expand all | Collapse all

Audit SAF RC=4 Events

  • 1.  Audit SAF RC=4 Events

    Posted 13 days ago
    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.



  • 2.  RE: Audit SAF RC=4 Events

    Posted 13 days ago

    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:

    1. 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)
    2. the RESCLASS has an access level associated with it (the discovery permission needs to accommodate all access levels)
    3. 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.
    4. 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.
    5. 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?).
    6. 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.
    7. 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
    ------------------------------



  • 3.  RE: Audit SAF RC=4 Events

    Posted 13 days ago
    Hello Joe,  thank you for your extensive comment!

    i have done such things in the past and i found the ca-cleanup tool very helpful, because it records also all log none, nofail checks.
    One issue i have found that some permissions cannot be refreshed. e.g. cryptoz.
    o in a 24/7 environment i have needed a few ipls to get it done. Starting with  cryptoz(*all*) permissions, because this ownership does no harm and  is activated by task start at ipl.

    I´d like to have a feature like action(audit) but for log(none) events     action(lognoneaudit)  action(lognofailaudit) or  sg. like this.

    One Problem is i cannot put into audit record eg cryptoz(*all*) . i have to know all prefixes that may occur...)

    T.



  • 4.  RE: Audit SAF RC=4 Events

    Broadcom Employee
    Posted 10 days ago
    Your idea sounds fantastic. Please submit your idea in Ideation in the Communities Forum, so it can be considered for a future release.

    To request enhancement requests, please submit your idea to Ideation https://community.broadcom.com/ideation/allideas, so it can be voted on by the community. The more votes the greater the chance it will be included in the product.
    Regards,
    Joseph Porto - Broadcom Level 1 Support



  • 5.  RE: Audit SAF RC=4 Events

    Broadcom Employee
    Posted 10 days ago
    Another suggestion would to add the resource to the AUDIT record instead of the ALL record to review the accesses.

    ------------------------------
    Roy Young
    ------------------------------



  • 6.  RE: Audit SAF RC=4 Events

    Posted 10 days ago
    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.com
    CA Top Secret z/OS Productivity Specialist
    Access Solutions, Inc.
    Kansas City, Missouri / USA
    ------------------------------



  • 7.  RE: Audit SAF RC=4 Events

    Posted 10 days ago
    I suggest a DEFPROT Warn Mode DPRWARN. If this is set  an application sees the saf return code 4 unchanged. but it is reported in tssutil as warn violation.
    but if log none,nofail is not accounted here its not the full picture....


  • 8.  RE: Audit SAF RC=4 Events

    Broadcom Employee
    Posted 9 days ago
    Joe,

    You are 100% correct regarding RC 4 and the AUDIT record.

    Regarding the logging and tracking of  RACROUTEs with LOG=NONE question, Compliance Event Manager is an real time, advanced reporting and notification add on to Top Secret does have the ability to track and report RACROUTEs with LOG=NONE. Its considered a separate chargeable product.

    More details about it can be found here:
    https://techdocs.broadcom.com/us/en/ca-mainframe-software/security/ca-compliance-event-manager/6-0.html

    Regards,
    Joseph Porto - Broadcom Level 1 Support




  • 9.  RE: Audit SAF RC=4 Events

    Posted 2 days ago
    One gotcha in audit record is that i need at least 2 char

    tss add(audit) jesjobs(X) is not accepted,     Jesjobs(X2) is honored

    lets say i want to audit program(Bxxxx) , i have to add BA,BB,BC etc.