What is Security definition validation (SDV)?

SDV is an example implementation of a CI/CD pipeline that introduces CICS application security testing into its flow.

SDV automates and improves the efficiency of identifying required changes to security when changes are made to CICS applications. This is currently a slow, error prone, and manual process, often leading to application breakages when the application is first ran in an environment with security switched on, which is more common than not, pre-production!

SDV helps contribute towards larger Zero Trust or DevSecOps strategies by introducing security testing as far-left in the CICS application development lifecycle as possible, yet with no additional effort required on the application developer when they request code changes.

How does it work?

SDV is not a product or tool; rather, it is a concept to introduce a form of security testing into your existing CICS application CI/CD pipelines. This has been made a reality by utilising one of the new features introduced in CICS TS for z/OS 6.2, which assists in the migration to a Zero Trust security strategy, Security definition capture (SDC). This feature has been integrated into an example CI/CD pipeline, which has been implemented, then fully documented via the Security definition validation for CICS TS (SDV) site.

An SDV pipeline does all the same tasks as any existing CI/CD pipeline, however, if an application code change request results in a change to the security definitions required for that application to run an approval process is initiated, which must be approved by a Security Admin. The application code change request is blocked until the Security Admin approves.

The stages of an SDV pipeline are as follows:

1. A developer raises an application code change request in the Source Code Management tool.
2. CI/CD pipeline is triggered, running a build of the application with proposed changes.
3. Built application is deployed to test environment.
4. The automated test suite runs against the test environment, switching SDC on before each test run, and switching SDC off afterwards.
5. The pipeline gathers and stores the newly captured security metadata from the automated test run.
6. The newly gathered security metadata is compared against a 'baseline' of security metadata.
7. If differences are found, the pipeline creates a request to change the 'baseline' of security metadata. The security Admin is added as a reviewer to this request, blocking the application code change request until it is approved.
   
8. The Security Admin reviews the above security change request.
   • If it is rejected, this is considered a failure within the application code change request, blocking its delivery.
   • If it is approved, this is considered a pass within the application code change request, putting it in a mergeable state.
9. If in a mergeable state, both the application, and the security change requests are merged.
   

The example CI/CD pipeline uses a range of open-source and publicly available 3rd party tooling, however, all the tooling used within the example pipeline is interchangeable with alternative tooling, and all bespoke tools developed have been made available, open-source in the CICSdev SDV Samples repository to assist with porting the workflow to other technologies and tooling.

Why do it?

• To identify a developers desired changes to security before code is delivered, as far-left in the pipeline as possible, reducing costs.
• To identify redundant security definitions.
• To reduce the risk of outages by missing security definitions in production.
• To speed up the process of getting Security changes made to RACF (or other external security manager).
• To automate the process of requesting security changes. Only the approval and updating of the Security database is manual.
• To Stop unwanted security changes making it into the codebase.
• To introduce Security testing into the application lifecycle as early as possible, building towards a greater DevSecOps goal.

Watch

Read

Full details on how to implement and configure can be found on the Security definition validation for CICS TS (SDV) site.