What is Security definition validation?
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 run in an environment with security switched on, which is more common than not, pre-production!
SDV helps contribute towards larger Zero Trust and 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.
What are the concepts?
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 and documented across this site via manuals and videos.
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:
- A developer raises an application code change request in the Source Code Management (SCM) tool.
- The application's CI/CD pipeline is triggered, running a build of the application with proposed changes.
- Built application is deployed to test environment.
- The application's automated test suite runs against the test environment. The test runner is adapted to switch SDC on for each CICS TS region under test before each test run, then switches SDC off after.
It additionally gathers and stores the captured Security definitions as security metadata against the test run.
Our example pipeline uses open-source automated test framework, Galasa, and the SDV Manager has been contributed to perform the above tasks. - The pipeline gathers and stores the newly captured security metadata from the automated test run.
- The newly gathered security metadata is compared against a 'baseline' of security metadata, previously captured during an automated test suite run on the default branch.
- If differences are found , the pipeline will create a request to change the 'baseline' of security metadata, to deliver these differences.
The security Admin is added as a reviewer to this request, blocking the application code change request until it is approved.
Our example pipeline uses an Ansible playbook to drive the above post-test steps, which is available open-source in the CICSdev SDV Samples repository - The Security Admin adds their review to 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. - If in a mergeable state, both the application, and the security change requests are merged.
Our example pipeline uses a GitHub App to synchronise events between the Application and Security change requests, which is available open-source in the CICSdev SDV Samples repository
The above stages use an application code change as an example, however this pipeline would also be applicable for test code change requests.
The example CI/CD pipeline uses a range of open-source and publicly available 3rd party tooling, and has additionally required the development of the bespoke tools listed above, 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 allowing you to see exactly how the tools provide their function, which can be adapted to suit your requirements.
You would implement SDV to...
- Identify a developers desired changes to security before code is delivered, as far-left in the pipeline as possible, reducing costs.
- Identify redundant security definitions.
- To reduce the risk of outages by missing security definitions in production.
- Speed up the process of getting Security changes made to RACF (or other external security manager).
- Automate the process of requesting security changes. Only the approval and updating of the Security database is manual.
- Stop unwanted security changes making it into the codebase.
- Introduce Security testing into the application lifecycle as early as possible, building towards a greater DevSecOps goal.
Demo
Introduction
This How-to guide will walk you through all the steps taken to implement SDV in the example CI/CD pipeline.
The example pipeline uses a particular set of technologies and tools, this guide will be opinionated towards the use and configuration of these. You are free to reuse these steps and tools, however, the majority of the steps provided are transferable to any alternative tools you may use within your pipelines. Any tools created for the example pipeline are open-source, allowing you download, view, and edit the code as you wish, to integrate it into your own tooling.