Auditing CICS
How it works: Auditing in CICS summarizes the checks that auditors might make on CICS® configuration, operations, authorization, and connections. This section tells you how to carry out those checks.
Compliance data collection
The type 1154 record provides compliance evidence data. A different subtype is assigned to each participating z/OS® component or product. On receiving an ENF86 signal from the z/OSMF Compliance REST API, participating components and products collect and write compliance data to their associated SMF 1154 subtype records. Each 1154 subtype record includes the SMF extended header, as defined by the IFASMFH macro, and the SMF1154 common area, as defined by the IFAR1154 macro. The remainder of the subtype data in each SMF1154 subtype record is unique to each participating component or product.
Auditing CICS configuration with IBM Health Checker for z/OS
IBM® Health Checker for z/OS is a z/OS component that helps to simplify and automate the identification of potential configuration problems before they impact availability or cause outages. CICS leverages IBM Health Checker for z/OS to provide health checks that define best practices for CICS configuration. You can use these checks to audit that CICS configuration conforms to best practices.
Identifying changes to resources (resource signatures)
The resource signature is the combination of the definition signature and the installation signature . It can be used to audit and manage resources by capturing when the resource is defined, installed, and last changed.
Classifying CICS regions with region tagging
CICS region tags allow you to classify regions based on the assigned APPLID, region user ID, and job name for the region. You can then use these region tag definitions to aid with auditing, running CICS health checks, or providing categorization information for operators. Region tagging is optional for use in CICS.
Auditing installed resource
Messages about resource installation are written to a number of destinations, depending on how the resources are installed.
Auditing SPI commands
Configuration defines the initial state of a CICS region but it can be changed by system programming interface (SPI) commands. RACF® SMF type 80 records can be used to audit the commands that are issued by an operator but they do not identify what options were used on these commands and what was changed as a result.
Auditing sign-on and sign-off
A user signs onto a CICS region through interfaces, such as a 3270 terminal, the CICS Client Management Interface (CMCI) or the (stabilized) CICSPlex® SM Web User Interface (WUI). RACF can log all sign-on and sign-off activity to SMF, including any invalid or unsuccessful sign-on attempts. You can use this information as an audit trail, to identify possible attempts to breach security, and to help with capacity planning. Recording the successful sign-on and sign-off activities establishes an audit trail of the access to particular systems by the terminal user population. This may also be useful for systems capacity planning, and generally constitutes a very modest portion of the information recorded to SMF.
Auditing bind time security (LU6.2)
You can configure CICS to audit bind time security by setting the system initialization parameter XAPPC=YES and the BINDSECURITY(YES) option on the CONNECTION resource definition that defines the remote system.
Auditing authorization
When a user requires access to a protected CICS resource and RACF denies the requested access, CICS provides messages.
Auditing RACF
Auditing RACF is checking that RACF meets the installation's needs for access control and accountability. RACF provides functions for you to specify the information that it records and tools to help you format and analyze the logged security events. For information about the auditing capabilities that RACF provides, see z/OS Security Server RACF Auditor's Guide .