The documentation for ICSF and securing access to keys is hard to follow. There is a lot of it, but is not easily consumed.

There are two orthogonal aspects of ICSF security

• Giving permission for a userid to use CSFKGUP utility, the ICSF ISPF panels, or the ICSF API. For example they can use list, but not define.
• Give permissions to groups of keys. You can define keys with names like DSENCR* have more controls that ANYONE*

There are different levels of granularity for ICSF security.

• The default is no security – you need to define profiles to protect ICSF resources
• There is on|off security. If you have any security you can do anything
• Then there is granular security. You can control down to the operation type.

This blog post is about setting up security for ICSF before you start defining keys.

ICSF security for commands and APIs

The approach to security for ICSF seems to be every one has access unless you take action to define security!

The CSFKGUP utility.

There is a master switch – if this profile exists then do more checks. If this profile does not exist any userid can use CSFKGUP commands to maintain keys. You need to set up Optional SAF checking for KGUP.

RDEFINE XFACILIT CSF.KGUP.VERB.AUTHORITY.CHECK UACC(NONE) 
SETR RACLIST(XFACILIT) REFRESH                              

RDEFINE CSFSERV CSFKGUP      UACC(NONE)  WARNING 
PERMIT  CSFKGUP CLASS(CSFSERV) id(IBMUSER) ACCESS(READ) 
SETR RACLIST(CSFSERV ) REFRESH 
/* 

With the above security setup anyone with read access to the CSFKGUP in class(CSFSERV) gets access to all of the CSFKGUP commands (not just read operations).

This is another master switch, to check the keys security. Its presence or absence controls its use. I had security set up for a key, and with warning mode, which allows the request, and gives a warning message on the console.

RDEFINE XFACILIT CSF.KGUP.CSFKEYS.AUTHORITY.CHECK UACC(NONE)
SETR RACLIST(XFACILIT) REFRESH

Now when I try to delete key SECKEY2 I got

ICH408I USER(IBMUSER ) GROUP(SYS1 ) ...
  SECKEY2 CL(CSFKEYS )
  WARNING: INSUFFICIENT AUTHORITY - TEMPORARY ACCESS ALLOWED
  FROM SEC* (G)
  ACCESS INTENT(CONTROL) ACCESS ALLOWED(NONE )

and when I defined a key SECKEY2

ICH408I USER(COLIN   ) GROUP(SYS1    ) NAME(###################
  SECKEY2 CL(CSFKEYS )                                         
  WARNING: INSUFFICIENT AUTHORITY - TEMPORARY ACCESS ALLOWED   
  ACCESS INTENT(CONTROL)  ACCESS ALLOWED(NONE   )              

If there is no matching CSFKEYS profile, the userid will be allowed access. When I defined a key ZZZKEY, it worked because there was no matching security profile.

You should define a minimum of

RDEFINE CSFKEYS   C*      AUDIT(ALL) 
PERMIT  *    CLASS(CSFKEYS) ID(COLIN  ) ACCESS(READ) 
SETR RACLIST(CSFKEYS ) REFRESH 

ISPF ICSF access

You can control which userids can manage ICSF using the ISPF interface. Behind the ISPF interface is code which issues ICSF APIs. You can protect the API calls.

You need to define a resource like

RDEFINE CSFSERV CSFKDSL .... 

and give the userid read access to it.

Function	The resources needed
List the contents of a PKDS or CKDS	CSFKDSL – list CSFKDMR – read meta data CSFKRR2 – read record
Define an AES Key	CSFKRR2 – read record CSFKGN – key generate CSFKGN2 – key generate 2 CSFKRC2 -record create 2 CSFKRD – delete record
List the contents of a CKDS element	CSFBRCK
List the contents of a PKDS element	CSFBRPK
Delete a CKDS record	CSFBRCK – control access

The functions and the SAF resource names are defined here.

To define a symmetric cipher key, I needed CONTROL access to the CLASS(CSFKEYS) profile for the key.