14. Understanding Major Version Updates

Aaron LippoldJanuary 5, 2024About 3 min

Learning Objectives

Understand what constitutes a Major Version Update and why they occur
Master the requirement alignment process using multiple identification methods
Learn to use available tools for version transition
Develop strategies for efficient code migration
Implement best practices for version control and testing

What is a Major Version Update?

A Major Version Update occurs when transitioning to a new STIG Benchmark version that introduces a completely new Rule ID index. Unlike minor Release Updates, this process requires careful mapping between old and new requirements.

Key Concepts

Requirement Alignment

Create a spreadsheet to track your requirement mappings during the alignment process.

When moving between major versions (e.g., RHEL 8 v1R12 to RHEL 9 V1R1), we need to align existing tests with new requirements using:

SRG IDs (Security Requirements Guide IDs)
CCIs (Control Correlation Identifiers)
Titles and descriptions when necessary

The Alignment Process

Initial Analysis
- Compare old and new benchmark requirements
- Identify matching controls using common identifiers
- Note any split or merged requirements
Using Available Tools
- MITRE Vulcan assists in alignment process
- Current Delta tool requires manual verification
- Future automation improvements are in development
Code Migration
- Transfer InSpec/Ruby code to new requirement locations
- Verify control mappings
- Update test code as needed

Practical Example

Consider this alignment scenario where we are updating from RHEL8 to RHEL9.

The requirements are the same: the /var/log/messages file must be owned by root. However, despite being the same, each requirement has its own id. Consequently, we need to use alternative means to realize that these requirements are aligned.

Attributes to consider:

The title is almost the same aside from the operating system version.
The description is almost exactly the same aside from inconsequential differences.
- Whitespace
- Version number
- Capitalization
Other alignment IDs are the same.
- SRG ID / gtitle: SRG-OS-000206-GPOS-00084
- CCI: CCI-001314
- NIST: SI-11 b
Check and fix text
- Fix text is the same
- Check text specifies a different method to do the assessment, but they're functionally equivalent

RHEL8

control 'SV-230246' do
  title 'The RHEL 8 /var/log/messages file must be owned by root.'
  desc "Only authorized personnel should be aware of errors and the details of
the errors. Error messages are an indicator of an organization's operational
state or can identify the RHEL 8 system or platform. Additionally, Personally
Identifiable Information (PII) and operational information must not be revealed
through error messages to unauthorized personnel or their designated
representatives.

    The structure and content of error messages must be carefully considered by
the organization and development team. The extent to which the information
system is able to identify and handle error conditions is guided by
organizational policy and operational requirements."
  desc 'check', 'Verify that the /var/log/messages file is owned by root with the following
command:

    $ sudo stat -c "%U" /var/log/messages

    root

    If "root" is not returned as a result, this is a finding.'
  desc 'fix', 'Change the owner of the file /var/log/messages to root by running the
following command:

    $ sudo chown root /var/log/messages'
  impact 0.5
  ref 'DPMS Target Red Hat Enterprise Linux 8'
  tag severity: 'medium'
  tag gtitle: 'SRG-OS-000206-GPOS-00084'
  tag gid: 'V-230246'
  tag rid: 'SV-230246r627750_rule'
  tag stig_id: 'RHEL-08-010220'
  tag fix_id: 'F-32890r567485_fix'
  tag cci: ['CCI-001314']
  tag nist: ['SI-11 b']
  tag 'host'

  only_if('This control is Not Applicable to containers', impact: 0.0) {
    !virtualization.system.eql?('docker')
  }

  describe.one do
    describe file('/var/log/messages') do
      it { should be_owned_by 'root' }
    end
    describe file('/var/log/messages') do
      it { should_not exist }
    end
  end
end

RHEL9

control 'SV-257916' do
  title 'RHEL 9 /var/log/messages file must be owned by root.'
  desc "Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the RHEL 9 system or platform. Additionally, personally identifiable information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives.

The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements."
  desc 'check', 'Verify the "/var/log/messages" file is owned by root with the following command:

$ ls -la /var/log/messages

rw-------. 1 root root 564223 July 11 11:34 /var/log/messages

If "/var/log/messages" does not have an owner of "root", this is a finding.'
  desc 'fix', 'Change the owner of the "/var/log/messages" file to "root" by running the following command:

$ sudo chown root /var/log/messages'
  impact 0.5
  ref 'DPMS Target Red Hat Enterprise Linux 9'
  tag severity: 'medium'
  tag gtitle: 'SRG-OS-000206-GPOS-00084'
  tag gid: 'V-257916'
  tag rid: 'SV-257916r925735_rule'
  tag stig_id: 'RHEL-09-232180'
  tag fix_id: 'F-61581r925734_fix'
  tag cci: ['CCI-001314']
  tag nist: ['SI-11 b']
  tag 'host'

  only_if('This control is Not Applicable to containers', impact: 0.0) {
    !virtualization.system.eql?('docker')
  }

  describe.one do
    describe file('/var/log/messages') do
      it { should be_owned_by 'root' }
    end
    describe file('/var/log/messages') do
      it { should_not exist }
    end
  end
end

Different yet the same

Even though the check text changed, it doesn't mean that the InSpec code needs to as well! We are still correctly assessing that the /var/log/messages file is owned by root if it exists.

Best Practices

Document all requirement mappings
Verify control alignments thoroughly
Test extensively after migration

What's Next

After alignment is complete, follow the standard Release Update process for:

Setting up CI/CD
Organizing controls
Updating and testing requirements

Summary

Major Version Updates require careful attention to requirement alignment and code migration. While tools like Vulcan help, some manual verification is still needed. Future improvements will streamline this process.