How it works: CICS security discovery

CICS security discovery helps you identify security definitions required for resource security. It does this by analyzing your existing external security manager (ESM) definitions and the usage pattern of resources in your production regions. You can then manage and refine your security definitions based on its recommendations. RACF is used as an example ESM in CICS documentation.

Why use CICS security discovery?

To conform with a zero trust strategy as well as various compliance regulations such as PCI-DSS, you need to protect your sensitive data. In CICS this means switching on resource security and command security in regions where sensitive data exists. For more information about zero trust, see How it works: Zero trust in CICS.

About the term: To avoid repeating the phrase resource security and command security, and because commands are just a type of resource, the following text refers to both by using the term resource security.

For regions that don’t currently have resource security, methods used prior to the security discovery feature of migrating to resource security in production can be difficult. Any errors will result in applications being unavailable for some or all users, or even worse allowing users access to data that they shouldn't have access to. Other approaches such as using SMF records or RACF warning mode for all definitions can generate a large amount of data that is difficult to process. Therefore, a process is required that allows system programmers, security administrators, and application owners to safely review definitions based on the usage pattern and produce definitions that are safe to implement in a production region.

An overview of the CICS security discovery process

The following diagram shows the process of using CICS security discovery to implement resource security.

Figure 1. Overview of the CICS security discovery process
Overview of security discovery process, with callout labels indicating each step, which is explained in the following text
The steps involved are as follows:
  1. Extract RACF definitions
    A security administrator runs a JCL job to extract the group and the transaction class definitions from RACF and converts them into input security metadata in a readable, ESM agnostic format on zFS.
  2. 6.2 Capture security discovery data (SDD)

    A system programmer switches security discovery on in production regions that are to be converted to resource security to capture usage data in those regions. Security discovery needs to be left on for an extended period of several weeks to capture most user usage. This should include periods such as the end-of-quarter and end-of-year processing.

    At the end of the capture period, the system programmer runs another JCL job to generate the usage data into SDD on zFS.

  3. Analyze security definitions in CICS Explorer® and export them for review

    The system programmer transfers the files through FTP from zFS and imports them into the CICS Explorer. The Security discovery perspective in CICS Explorer can be used to identify and refine groups of users (roles), transactions, and other resources, one resource type at a time.

    To simplify the task, the system programmer can use the transaction data in the security metadata and SDD to identify applications. They can then work on the data one application at a time.

    After updating the security definitions in CICS Explorer, the system programmer exports them into output security metadata.

    Multiple roles including the security administrator and application owner then need to review the output security metadata to ensure the security definitions are correct.

  4. Create RACF commands from reviewed security definitions
    The security administrator transfers the security metadata through FTP to zFS and runs a JCL job to convert it to RACF commands. These commands are used to create new classes. CICS regions can then have a staged migration with the new classes. RACF warning mode is recommended for the migration period so that any errors can be corrected without disrupting production usage.

The security discovery process can be integrated into the zero trust migration journey. For more information about each step, see Migrating to zero trust with CICS security discovery.