The daily edition.

Scope: Rocket Enterprise Developer / Enterprise Server 12.0, Eclipse (UNIX) documentation bundle. This article covers CICS security checks in an Enterprise Server region that uses an External Security Facility (ESF) security manager.

Two checks, two per-transaction switches

When a CICS transaction program runs, the checks the CICS subsystem makes are influenced by two settings in the CICS PCT entry for that transaction, as described in Enabling additional controls:

• Resource Level Security (RLS): controls whether access checks are made for the CICS resources named in EXEC CICS statements, such as files and queues.
• Command Security (Cmd): controls whether access checks are made when the program uses CICS System APIs, such as EXEC CICS INQUIRE.

The manual states that enabling these options in the CICS transaction definitions improves security. The practical implication is that the defaults depend on each definition: a transaction that was defined without RLS or Cmd is not checked on that dimension unless something else forces it.

That page also assumes ESF is configured and that a security manager using the MLDAP ESM Module or VSAM ESM Module is doing the resource access control. The checks are only meaningful when such a security manager is in place.

Forcing the checks region-wide

Rather than auditing every transaction definition, you can override the per-transaction settings with environment variables.

• ES_ESM_RESSEC (resource level security), documented in ES_ESM_RESSEC
  • ASIS: the RLS setting of the transaction is honored. Resource level checking happens only when the RLS checkbox is marked in the PCT definition.
  • ALWAYS: CICS always performs resource level security checking, irrespective of the RLS setting on the transaction definition.
• ES_ESM_CMDSEC (command security), documented in ES_ESM_CMDSEC (MSS Security)
  • ASIS: the CMDSEC option of the transaction's resource definition is honored. Command checking happens only when CMDSEC is set to YES on the definition.
  • ALWAYS: CICS always performs command security checking, irrespective of the CMDSEC setting.

A documentation nuance worth knowing: the consolidated Security and Auditing Environment Variables page lists ES_ESM_CMDSEC with a different form, ES_ESM_CMDSEC=YES. There, YES overrides the CMDSEC option and always calls the command security checking routine, which issues the appropriate call to the SAF interface. When it is not set, CICS honors the definition and calls the routine only when CMDSEC(YES) is specified. The two pages describe the same intent (force checking on, or leave it to the definition) but use different values, so confirm which form applies to your setup before relying on one.

ES_ESM_RESSEC=ALWAYS
ES_ESM_CMDSEC=ALWAYS

These two lines are the documented ALWAYS values from the two reference pages, shown together for illustration; I have not tested them in a region.

PLTPI programs have their own level

Startup programs run from the PLT initialization list are governed separately by ES_ESM_PLTPISEC, described on the Security and Auditing Environment Variables page:

• NONE: no security checking on PLT initialization programs.
• CMDSEC: command security checking only.
• RESSEC: resource security checking only.
• ALL: both command and resource security checking.

The default is ES_ESM_PLTPISEC=NONE. Forcing ES_ESM_RESSEC and ES_ESM_CMDSEC to ALWAYS is therefore not the same as securing startup programs; that level is a distinct setting whose default is no checking.

Related resource-name controls

Two further variables on that page shape what the security manager is asked. ES_ESM_SECPRFX (default NO) controls whether CICS prefixes resource names when making security queries. YES uses the CICS region user ID as the prefix, and a value of one to eight upper-case characters starting with a letter defines a custom prefix. The page notes it applies only to CICS classes. Rules written in the security manager need to match whichever prefix choice is active. The ES_CLASS_X* variables (for example ES_CLASS_XPCT, ES_CLASS_XFCT, ES_CLASS_XCMD) accept YES, NO or a class name. NO means security for that resource type is bypassed, so a forced RLS or Cmd check will not help for a class set to NO.

Takeaway

In Enterprise Server 12.0 (UNIX docs), CICS resource and command checks are per-transaction PCT options by default. ES_ESM_RESSEC=ALWAYS and the command-security override force the checks region-wide, ES_ESM_PLTPISEC separately governs PLTPI programs (default NONE), and none of it is effective unless an ESF security manager and the relevant resource classes are in place. See Enabling additional controls.