How it works: CICS security discovery
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.
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.
-
- 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.
-
- 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.
-
- 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.
-
- 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.