Idea Details

Security - Prevent ICH408I in (SQL)-READWRITE/READONLY SAF calls

Last activity 05-09-2019 02:55 AM
FRANK TERNEST's profile image
10-25-2018 08:27 AM

The idea was originally created by MarcelvanEk on Jun 6, 2014

In OPS/MVS security SAF calls we frequently make use of the possibility to do hi-level checks on GLOBAL and SQL READWRITE/READONLY authorization, to prevent security rules from fireing frequently for authorized staff (such as the automation group)

Now these result in ICH408I if tested negative, but since that is actually an OK result, we'd rather not see those on opslog/syslog., so please provide an option/parm to prevent these if possible.

ICH408I USER(****** ) GROUP(BIUSERS1) NAME(xxxxxxx.            )
   ******.GLOBAL.READWRITE CL(class)                           
   INSUFFICIENT ACCESS AUTHORITY                                  
   ACCESS INTENT(UPDATE )  ACCESS ALLOWED(NONE   )                
  ICH408I USER(****** ) GROUP(BIUSERS1) NAME(xxxxxxx.            )
   ******.GLOBAL.READONLY CL(class)                           
   INSUFFICIENT ACCESS AUTHORITY                                  
   ACCESS INTENT(READ )  ACCESS ALLOWED(NONE   )                         

ICH408I USER(xxxxxxx ) GROUP(BIUSERS1) NAME(xxxxxxx         )  
   xxxxxxx.GLOBAL.SQLREADWRITE CL(class)                          
   INSUFFICIENT ACCESS AUTHORITY                                    
   ACCESS INTENT(UPDATE )  ACCESS ALLOWED(NONE   )

ICH408I USER(xxxxxxx ) GROUP(BIUSERS1) NAME(xxxxxxx         )  
   xxxxxxx.GLOBAL.SQLREADONLY CL(class)                          
   INSUFFICIENT ACCESS AUTHORITY                                    
   ACCESS INTENT(READ )  ACCESS ALLOWED(NONE   )       

 

The suggested solution of David Jones is working very fine if you don't like ICH messages, nor SMF records type 80 at all for security violations/warnings or SMF records type 80 with Audit settings (ALL(READ)). So not only the GLOBAL.SQLREADONLY/SQLREADWRITE/READONLY/READWRITE profiles are no longer logged, but all events, both in internal as in external security.

Now we finally obtained a solution for the broken link in SECURITYLOG for RACF and TSS, we want to use it, but not for these 4 profiles, that expose dangers to the system integrity.
We tried out some scenario's where we blocked the access for an user on one of the subsequent ADDRESS SQL operations, but using the SQLREADWRITE he passed without any problems.

A possible solution is to pass the profiles to internal security using security rules and OPSECURE. In OPSECURE you have the possibility to set the SECURITYLOG to off for a specific event, preventing ICH-messages and SMF-records 80.


But on the other hand the only profiles that can be fully handled with external security are OPSGLOBAL and SQL.
So we are missing something for external security and the solution is NOT putting SECURITYLOG to OFF.


Comments

05-09-2019 02:55 AM

Thanks David,

 

we are running since a while with access NONE for the 4 profiles in external security (and the profiles are not defined in internal security). So even OPSMVS and OPSOSF doesn't have access to the resources.
Until now we detected only one problem (with the exception of the ICH408I messages). The problem is described in the case 01306280 and is due to the  OP411002 REXX, where the access to the resources GLOBAL.SQLREADWRITE and GLOBAL.SQLREADONLY is checked. The result is that we don't see anything when we want to use the option BROWSE in the SSM Monitor Display (using option panel 0.1).

Kind Regards,

Frank

05-07-2019 07:45 AM

CA OPS/MVS engineering team discussed this idea during ideation review meeting and has accepted it as a valid enhancement request. User story added to OPS/MVS backlog.  Idea status changed from Under Review to Wish-Listed