ESM Information › ESM Security Exit Analysis

ESM Security Exit Analysis

Use the ESM Security File Analysis function (7.2) to analyze the security files used by executing ESM on your system.

This function is ESM-specific about the types and numbers of security files used. For example:

• CA ACF2 installations can specify security data sets with a specific startup DDSN Group
• RACF installations can specify a single security file in the master scheduler JCL, multiple pairs of primary/backup data sets via the data set name table, or a single primary/backup pair via master console operator WTOR replies at startup.

When you execute the 7.2 ESM Security File Analysis function take note of:

• The ESM initialization date. This should be the same date as the IPL date. If they differ, this infers that the ESM was stopped and restarted after the IPL. Verify through console change log requests why this was done; if no loggings were recorded, find out the reason behind the stop and restart and verify operational procedures. If CA Auditor is not able to ascertain the ESM initialization date, N/A appears.
• Whether the ESM has been restarted. With some ESMs, CA Auditor is able to identify if the ESM was stopped and restarted. If it has it specifies YES. If it cannot it specifies NO or N/A.
• Whether the ESM was automatically started via standard means. Normally the ESM is automatically started. This is an accepted best practice. If the ESM is started manually, the timing of the ESM initialization vary from IPL to IPL. Audit the ESM invocation for each IPL because the ESM could be started in different manner for each.
• The security files. Take note of the different types of files. For example, CA Top Secret can utilize a separate Audit/Tracking data file which the other ESM products do not have. For each file, use the ACCESS line command to validate security controls protecting the file.

Determine how the security files are specified to the ESM. For:

• CA ACF2, if the ACF2 address space started with the S ACF2 command what overrides are present on the command? If automatically started within the CAISECxx/CAIACFxx members is a DDSN group specified? Are hardcoded security file definitions included within the actual ACF2 procedure.
• If running CA Top Secret, all files generally must be specified via DD statements within the TSS procedure. Verify the procedure library containing the TSS procedure and ensure that it is properly controlled.
• If running RACF, the primary and backup files can be specified via:
  • Master JCL’s SYSRACF DD statement
  • Console operator WTOR’s if the installation allows the operator to specify the primary/backup file name during RACF startup, or preferably via the data set name table.

  If the operator is allowed to specify the file names at RACF initialization time, ensure that a regular audit is performed for each startup of RACF to ensure that the operator specifies the proper security file names. If a data set name table is used, locate the:

  • Library containing the loadable data set name table module
  • Loadable data set name range table
  • Source code for each.

  The data set name range table is required when a data set name table is used. This defines which set of primary/backup data sets contain a specific security record based on key range. Improper modification of this table could cause RACF to look to an incorrect security file when attempting to locate a security record.