Many ACIDs have NOVOLCHK, NOSUBCHK, and NODSNCHK. These need to be removed to satisfy an audit requirement. Is the best way to do this:
1. Removing these attributes from all ID's.
2. Permit MODE(WARN) to the ACIDs.
3. Run a TSSUTIL report to report on all warnings on a daily basis.
or is there a better way of doing this cleanup?
Release : 16.0
Component : CA Top Secret for z/OS
The bypass attributes should generate OK+B events to the audit file each time it is used to allow access to something. If you have the audit file data for the past few months, you can run TSSUTIL and include EVENT(AUDTB) on the REPORT statement to get just the OK+B events to see what those acids are accessing. Then determine if the acids should have access to those resources before permitting.
For NODSNCHK, instead of WARN mode, you can use the following permit to give all access to all datasets and audit (OK+A events) when this permit is used to allow access:
TSS ADD(dept) DSN(*****) (if not already done)
TSS PERMIT(acid) DSN(*****) ACCESS(ALL) ACTION(AUDIT)
Note: If there was a permit on the acid, say, for DSN(SYS1.DUMMY) ACC(READ), since 'SYS1.DUMMY' is longer than '******', the acid would only have read access to SYS1.DUMMY datasets. In order to replace the NOVOLCHK with other TSS commands you could use the following:
For NOVOLCHK, instead of WARN mode, you can use the following permit to give all access to all volumes and audit when this permit is used to allow access:
TSS ADD(dept) VOLUME(*ALL*(G)) (if not already done)
TSS PER(acid) VOLUME(*ALL*(G)) ACC(ALL) ACTION(AUDIT)
There isn’t a generic rule to give the access that NOSUBCHK allows. You would have to permit the acid to each individual acid. (TSS PER(nosubacid) ACID(acid2) where ‘nosubacid’ is the acid you are removing NOSUBCHK from and ‘acid2’ is the acid that ‘nosubacid’ should be cross authorized to submit jobs.) If the cross authorization check fails, it is denied in all modes, so using WARN mode will not help here.