08-88 Event In TSSUTIL For ACID In WARN Mode But Not FAIL Mode

Products

• Top Secret

Issue/Introduction

An ACID was changed from FAIL mode to WARN mode in Top Secret. That's the only change. After this, the TSSUTIL report is showing the following for the ACID:

 mm/dd/yy  hh:mm:ss ssss  acid   jobname  STC       WARN      IEESB605  READ     NONE      *08*-00000088       
                     RESOURCE  TYPE & NAME :   IBMFAC    IARRSM.EXEMPT.ASLR.CNMEUNIX

What is happening that has triggered these violations that didn't exist before being in WARN mode?

Resolution

The security check for this resource (IBMFAC(IARRSM.EXEMPT.ASLR.CNMEUNIX) ) is issued with LOG=NOFAIL. If LOG=NOFAIL is specified on the security call and the ACID is in WARN mode, violations will show up in TSSUTIL. In FAIL mode, no violations will be shown. This is not a bug, but the way it works with LOG=NOFAIL. Once the ACID is put in FAIL mode, the events in the TSSUTIL report should no longer be there.

The LOG=NOFAIL parameter in a RACROUTE macro specifies that the external security product (Top Secret in this case) should not record an attempt on the SMF data set (and/or Top Secret Audit File) if an authorization check fails. However, if the check succeeds, the attempt is recorded based on the resource profile's settings. This parameter is often used to suppress audit messages for routine checks that are expected to fail, preventing false-positive security violation alerts. 

Key Details of LOG=NOFAIL:
* Failed Attempts: No audit record is created.
* Successful Attempts: Recorded as if LOG=ASIS were specified (following the resource profile or system defaults).
* Purpose: Commonly used for internal system checks where a failure is not a security incident, such as checking for multiple resource classes where one is expected to be absent.

In FAIL mode, this check fails, which is why you don't see the TSSUTIL event when the ACID is in FAIL mode. 

In WARN mode, violations are logged and warning messages are issued, but access is not denied. Since access is not denied, this is considered a successful event (check succeeds), which is why the event shows in TSSUTIL.