pg 12-14 - update types

Signed-off-by: Amndeep Singh Mann <[email protected]>

src/courses/profile-dev-test/12.md

@@ -1,7 +1,7 @@
 ---
 order: 12
 next: 13.md
-title: Understanding Profile Patch Updates
+title: 12. Understanding Profile Patch Updates
 author: Aaron Lippold
 ---
 
@@ -43,7 +43,10 @@ A patch update is a minor modification to an InSpec profile that addresses speci
   - Control logic
   - `inspec.yml` inputs
   - Threshold values
-- Note: The InSpec version in `inspec.yml` is managed during release
+
+::: note Version number increments
+The version attribute in `inspec.yml` is managed during releases so you shouldn't change it in every merged branch, just when you cut a new release.
+:::
 
 ### 4. Testing Protocol
 

src/courses/profile-dev-test/13.md

@@ -1,7 +1,7 @@
 ---
 order: 13
 next: 14.md
-title: Understanding Release Updates in SAF
+title: 13. Understanding Release Updates
 author: Aaron Lippold
 ---
 
@@ -13,31 +13,33 @@ author: Aaron Lippold
 
 ## What is a Release Update?
 
-A Release Update is a structured process for updating Security Automation Framework (SAF) profiles to accommodate new benchmark versions. This process ensures consistent quality and maintains traceability of changes.
+A Release Update is a structured process for updating a profile to accommodate a new benchmark version. This process ensures consistent quality and maintains traceability of changes.
 
 ## Release Update Workflow
 
 ### Step 1: Branch Creation
 
-Create a new branch named `v#{x}R#{x+1}` from either:
+Create a new branch named `v{x}r{xx}` from either:
 
 - The main branch
-- Latest patch release branch
+- The tagged commit associated with the latest release
 
 ### Step 2: Generate Delta
 
-Run the `saf generate delta` workflow to update:
+Run the `saf generate delta` workflow to automatically update the InSpec profile as per the new guidance.  Items that get updated include:
 
 - Control metadata
 - inspec.yml configuration
 - README.md documentation
 - Other profile elements
 
-> Note: This process preserves existing `describe` blocks and Ruby code logic
+::: info Saved!
+This process preserves existing `describe` blocks and other Ruby code logic, but you will still need to review them to ensure that what they're assessing still lines up with what the requirement says we now need to be assessing.
+:::
 
 ### Step 3: Change Management
 
-Follow these best practices to organize your work:
+Follow these best practices to organize your work as you implement any new requirements and update any changed ones:
 
 #### 3.1 Control Tracking
 
@@ -56,13 +58,17 @@ Follow these best practices to organize your work:
    - [ ] Documentation current
 
 2. **Infrastructure Updates**
-   - Update hardening content:
+   - Update the version of the hardening content that is used to test the InSpec profile to match the version of the benchmark:
      - Ansible playbooks
      - Puppet modules
      - Chef cookbooks
      - Docker images
      - Vagrant boxes
 
+::: important Parallel workstreams
+You might be required to update the hardening content itself to match the new or adjusted requirements coming from the benchmark instead of just consuming the newest version.  However, updating the hardening and validation content lock-step is a straightforward process!
+:::
+
 3. **Metadata Management**
    - Update all version references
    - Verify control titles
@@ -71,7 +77,7 @@ Follow these best practices to organize your work:
 ## Tips for Success
 
 - Focus on controls with modified `check text` or `fix text`
-- Unchanged control text typically means no code changes needed
+- Unchanged control text typically means no code changes are needed
 - Use PR links to track changes in your tracking table
 - Maintain CI/CD pipeline health throughout updates
 

src/courses/profile-dev-test/14.md

@@ -1,13 +1,8 @@
 ---
 order: 14
 next: 15.md
-title: Understanding Major Version Updates
+title: 14. Understanding Major Version Updates
 author: Aaron Lippold
-difficulty: Advanced
-prerequisites: 
-  - Basic InSpec knowledge
-  - Understanding of STIG benchmarks
-  - Familiarity with Ruby
 ---
 
 ## Learning Objectives
@@ -26,7 +21,7 @@ A Major Version Update occurs when transitioning to a new STIG Benchmark version
 
 ### Requirement Alignment
 
-:::tip 💡 **Pro Tip**: Create a spreadsheet to track your requirement mappings during the alignment process.
+:::tip 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:
@@ -54,7 +49,126 @@ When moving between major versions (e.g., RHEL 8 v1R12 to RHEL 9 V1R1), we need
 
 ### Practical Example
 
-Consider this simplified alignment scenario:
+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
+
+::: code-tab
+@tab RHEL8
+```ruby
+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
+```
+@tab RHEL9
+```ruby
+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
+```
+:::
+
+::: tip 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