Creating a `Major Version Update`

The Major Version Update Process

A Major Version Update involves transitioning to a new STIG Benchmark, which introduces a new Rule ID index. This process is more complex than a Release Update due to the need for aligning old requirements (Rule IDs) with the new ones.

For example, when transitioning from RedHat Enterprise Linux 8 v1R12 to Red Hat Enterprise Linux 9 V1R1, the alignment of InSpec tests to the new requirements must be fuzzy matched. This involves using common identifiers such as SRG ID, CCIs, and, if necessary, the title and descriptions.

This is crucial when a single requirement from the old benchmark is split into multiple requirements in the new benchmark, although this is usually a rare occurrence.

We use a similar process in our MITRE Vulcan to align 'Related Controls' in your Vulcan project to existing published STIG documents. However, the Delta tool currently requires manual intervention, and improvements are needed to automate this process.

The good news is that these improvements are within reach. We can leverage the existing work from Vulcan and hopefully soon incorporate these improvements into the SAF Delta tool as a direct function.

Once the 'old controls' and 'new controls' are aligned across 'Rule IDs', you can migrate the InSpec / Ruby code into their respective places.

Then, you follow the same setup, CI/CD organization, and control update process as in the Release Update process and hopfully finding that the actual InSpec code from the previous benchmark is very close to the needed InSpec code for the same 'requirement' in the new Benchmark.