How it works: Capturing and validating security definitions during the development process

6.2 Applies to 6.2.

To conform to a zero trust strategy, it is vital that from a security perspective you must not only understand the model of security in your enterprise, but also be able to maintain it. CICS security definition capture (SDC) can capture the security definitions that would have been required if resource security and command security were turned on during the development process. It can run in a development region with minimal CICS security.

The required security definitions can then be reviewed and flowed through the development process to be implemented in production on a region with full CICS security. You can further incorporate the whole process into a CI/CD pipeline as part of your enterprise's DevSecOps strategy.

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.

What is DevSecOps, and how is SDC related?

DevSecOps stands for development, security, and operations. It's a methodology that extends DevOps. DevSecOps automates the integration of security at every phase of the software development lifecycle, from initial design through integration, testing, and deployment, to software delivery.

CICS security definition capture enables you to identify required security definitions and implement them earlier within the development process. If your enterprise is adopting a DevOps (or DevSecOps) approach, you can incorporate SDC into your CI/CD (continuous integration/continuous delivery) pipeline to align with the DevSecOps strategy.

Why capture security definitions using SDC?

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.

When writing new applications or changing applications, it is necessary to identify the security definitions required for promoting the application into a production environment.

One way of doing this is to identify all of the definitions before starting development, implement them on a test system, and then develop and test the application. Testing might identify changes to the security definitions, which will then need to be implemented before further work can be done. This can result in a lengthened software development lifecycle and hence inefficient product delivery.

With CICS security definition capture, development can take place on an isolated test system with minimal security. When the developer changes the application or a tester runs the automation tests, CICS identifies the required security definitions. This can then be implemented on a preproduction test system and the application further tested with all security correctly configured first time. This process minimizes the chances of definitions being incorrect or even worse, over permissive.

If security definition capture is incorporated into a CI/CD pipeline as part of the DevSecOps approach, the whole process can be automated so that the required security definitions can be captured, reviewed, and implemented on a continuous basis.

Manually capturing security definitions using SDC

Although automating the process of capturing and validating security definitions renders added value, you can still simplify your zero trust maintenance by manually capturing required security definitions using SDC before reviewing and promoting them.

The following diagram shows the process of generating RACF definitions to implement resource security based on the output from CICS security definition capture, where RACF can be replaced by any other supported ESM.
Figure 1. Flow of capturing security definitions using SDC
Flow chart explains how to invoke SDC during testing to capture required security definitions in the development process: Code compilation, invoking SDC on, manual testing when SDC is on, invoking SDC off, security definition review by security administrators, generation of ESM (e.g. RACF) definitions per security definition for security administrators to update ESM definitions, and the finally, code delivery
The flow is as follows:
  1. The application is written or changed, compiled, and then passes basic unit testing.
  2. Prior to testing, the developer starts SDC for the developers’ test entry point. SDC provides two interfaces: the CXSD transaction and the HTTP REST interface. This is done on a region with SEC=YES, but all other security definitions are optional.
    • For 3270 applications, the developer signs on and invokes CXSD ON. This captures security definitions required by the 3270 terminal based on its usage.
    • For the other applications, the developer sends an HTTP POST request to the TCPIPSERVICE installed in the CICS region, as shown in the following diagram. The user ID used for requests to the TCPIPSERVICE must be the same as that used for testing.
      Figure 2. Starting SDC through the HTTP interface
      A diagram that shows how SDC can be started by sending an HTTP POST request to the TCPIPSERVICE installed in CICS from the developer's client
  3. The developer runs through the test paths. The test environment might be a single region or a collection of regions (TOR, AORs, FORs, and so on). These tests exclude specific tests that are to test security failures.
  4. The developer stops SDC:
    • For 3270 applications, the developer invokes CXSD OFF.
    • For the other applications, the developer sends an HTTP DELETE request to the TCPIPSERVICE installed in the CICS region.
  5. When SDC stops, CICS automatically submits a job to produce the security metadata that contains required security definitions. The output is sent to either the developer or a security administrator depending on the configuration. The remaining steps assume the output goes to the developer.
  6. The developer reviews this security metadata to verify whether it meets the expectation.
  7. The developer then submits this file, or a copy of the information, to the security administrator. Developers must include the roles who need to access the application. Such roles need to replace the user ID(s) that are used in the testing.
  8. The security administrator reviews the information and creates the RACF commands to update the database.
  9. The application code can then be delivered.

After this process, it is expected that there will be preproduction testing with security on. This will test out the new security definitions including any error paths that will result in security failures.

The definitions and the application can then be moved to production.

For more information about runing SDC, see Capturing security definitions during development using security definition capture.

Moving towards a DevSecOps process

Further value can be obtained by automating some of this process.

For example, you can the use Galasa SDV Manager to automate the testing, starting and stopping of SDC, and the generation of the security metadata as part of your CI/CD pipeline. Other DevSecOps tools like Ansible® and GitHub can be used to automate the comparison and validation of security definitions.

The following diagram shows one example:
Figure 3. Automating the starting and stopping of SDC to identify security definitions in a DevSecOps process
Flow chart explains how to automatically invoke SDC to identify security definitions in the development process: Code compilation, automated testing, automatically switching SDC, security definition review, and generation of RACF definitions per security definition

As a prerequisite to this example, a full automated regression test suite run is performed with SDC on, submitting a job for each test class. This creates security metadata for each test class, acting as the security baseline to detect differences from.

Each time a developer makes a request to change the application or test code, the pipeline compiles the code and then runs automated regression tests against the code changes, generating updated security metadata files. These files can be compared against the baseline files to identify differences. The security administrator can then review these differences and make the security changes

CICS provides an example implementation of a full CI pipeline called security definition validation (SDV). It utilizes SDC within its automated testing stage and initiates an approval process. When changes to security are identified, the approval process must complete before code is delivered. For more information about the example, see Introducing Security Definition Validation to your CICS TS Application CI pipeline.