Disable the capability to set the safeguarded copy expiration date

Thanks for your view on this.

Within ABN AMRO we had an audit and the auditors are pretty clear about this. If the experation date of a SGC can be changed (whether by one or by dual control or whatever), it is not immuttable anymore. So there needs to be some way to make them completely immutable. With a backdoor or whatsoever, we will never get a positive advise from our audit department.

therefor we request to implement this idea. Or if IBM has another way of accomplishing this, it is fine for us as well.

We understand your restated requirement to be that no improper or malicious human action should be able to cause the release of a safeguarded copy. But you also agree that copies cannot exist forever, and that there must be an exception process to handle situations that arise due to (for example) the finite nature of storage. Unfortunately, any exception process would need to be initiated by a human, or by automation according to rules configured by a human. In the end, no matter what the mechanism, there is a trusted human in control, and the potential for that trust to be abused. A key response to "zero trust" challenge is to require multiple approvals such that no single user can accomplish a malicious act on their own. GDPS has implemented dual control as a mitigation here, but you believe that can be defeated by a single RACF superuser. Given that, isn't your real requirement to be able to secure your RACF database? The potential harm from unrestricted RACF access to any resource is arguably a far greater business risk than premature expiration of a Safeguarded copy. Also, note that the DS8K has the capability today to set a guaranteed minimum number of captures which will be enforced by the storage system either from the user expiring them or by setting the volumes write inhibit if there is a volume/pool out of space situation. This setting can only be changed by IBM support so the client themselves cannot do this.

Given that the DS8K disk subsystem capacity is limited, what is the auditor's specific criteria of immutability?

The feedback from our Auditors is that if you can delete a Safeguarded copy immediately by changing die expiration date it is not really an immutable copy.

Yes dual control is helping by mitigating deleting in the normal proces/way of working. e.g. prevent people for making mistakes. But if the z/OS - RACF environment has been compromised (somebody has been able to get superuser credentials) having Dual Control defined in the same security environment does not prevent against malicious actions I think.

the GDPS LCP Mgr feature provides role based security (RBS), field level security in profiles, and dual control. why isn't dual control sufficient?