About cookies on this site Our websites require some cookies to function properly (required). In addition, other cookies may be used with your consent to analyze site usage, improve the user experience and for advertising. For more information, please review your options. By visiting our website, you agree to our processing of information as described in IBM’sprivacy statement. To provide a smooth navigation, your cookie preferences will be shared across the IBM web domains listed here.
Thank you for submitting your idea for zSecure. We appreciate you taking time to help improve the product. At this time, we have not received requested information to clarify the request from the submitter and are no longer considering it. If you can provide the requested details in the future, we can reopen and better evaluate the request.
Hi Raymond,
I'm trying to understand more of a context here. For me the scenario you explained looks more like auditing facility inside RACF. if yes can you please open this RFE towards RACF: This is idea portal for IBM Z Security and Compliance Center.
When a breach occurs on z/OS, the person or team responsible for detecting and remediating the source of the breach needs to know:
Which ID was used to initiate the event
How entry to the system was obtained
Misuse of an existing service that already had access
Compromise of a user login account
When a Surrogate ID is used to perform the breach (usu. with escalation of privilege), the originating ID must be identified. If the breach is still in progress, time is of the essence and the research must be done quickly. If Surrogate to Surrogate access exists and the SMF data does not identify the initial submitter, the researcher must follow the submit chain which could cross multiple sysplex environments, subsystems, and privileged and non-privileged IDs.