pg 10

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

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

@@ -1,7 +1,7 @@
 ---
 order: 10
 next: 11.md
-title: What Is `Done` for a Control?
+title: 10. What Is `Done` for a Control?
 author: Aaron Lippold
 ---
 
@@ -33,35 +33,34 @@ Understanding when a security control is truly "done" is crucial for security au
 
 You and your team might be wondering what 'done' means for a security control in your profile. Here are a few things to consider:
 
-1. The security automation content and its tests are essentially a refactoring of the 'validation' and 'remediation' guidance already established by the benchmark.
+1. The security automation content and its tests are essentially an alternative definition of the 'validation' and 'remediation' guidance already established by the benchmark.
 2. The security automation content tests should fully capture the spirit - or intention - of the guidance, including its caveats, notes, discussion, and 'validation' and 'remediation' content.
-3. The tests can - and usually do - capture known 'corner cases and security best practices' that are sometimes indirectly or not directly addressed by the benchmark but implied by the spirit of the security requirement being addressed.
+3. The tests can - and usually do - capture known corner cases and security best practices which are sometimes only indirectly addressed by the benchmark but implied by the spirit of the security requirement being addressed.
 4. These tests, like all human-written code, may not be perfect. They will need updates and will evolve as our knowledge of the system and benchmark grows. We use the profile in production and real-world environments. In other words, don't let the pursuit of perfection hinder progress.
 
 The 'is it done' litmus test is not solely determined by a perfect InSpec control or describe and expect blocks. It also heavily relies on you, the security automation engineer. Your experience, understanding of the platform you're working on, and the processes that you and your team have collectively agreed upon are all vital components.
 
-Trust your established expected test outcomes, the guidance document, and the CI/CD testing framework. They will help you know that, to the best of your ability, you have captured the spirit of the testing required by the Benchmark.
+Trust your established expected test outcomes, the guidance document, and the CI/CD testing framework. They will help you know that, to the best of your ability, you have captured all requirements and the spirit of the testing specified by the benchmark.
 
 ## The MITRE SAF Testing Framework
 
 Our framework provides a comprehensive approach to testing controls. We call this the "SAF Yardstick":
 
 We consider a control effectively tested when:
 
-1. All aspects of the 'validation' - also known as 'check text' - have been addressed.
-2. Any aspects of the 'remediation' - also known as 'fix text' - that are part of the 'validation' process have been captured.
+1. All aspects of the 'validation' - also known as 'check text' - have been addressed.  This is usually straightforward.
+2. Any aspects of the 'remediation' - also known as 'fix text' - that are part of the 'validation' process have been captured.  Sometimes guidance authors mix the type of information between the 'check' and 'fix' text areas, so we need to comprehensively read all of the guidance to ensure that we've extracted all of the 'validation' content wherever it might be.
 3. Any documented conditions that are Not Applicable, as outlined in the 'discussion', 'check', or 'fix' text, have been addressed.
-4. Any documented conditions that have Not Been Reviewed, as outlined in the 'discussion', 'check', or 'fix' text, have been addressed.
-5. The conditions for Not Applicable and Not Reviewed are early in the control to ensure the control is as efficient as possible.
+4. Any documented conditions that require manual review, as outlined in the 'discussion', 'check', or 'fix' text, have been addressed such that the control is marked as Not Reviewed on execution of the profile.
+5. The conditions for Not Applicable and Not Reviewed are assessed early in the control to ensure the control is as efficient as possible.
 6. The control uses the `only_if` block vs 'if/else' logic when possible to ensure that the control is as clear, direct, and maintainable as possible from a coding perspective.
 7. The control has been tested on both 'vanilla' and 'hardened' instances, ensuring that:
-    1. The test communicates effectively and fails as expected on the 'vanilla' testing target.
-    2. The test communicates effectively and passes on the 'hardened' testing target.
-    3. The test communicates effectively and fails on a misconfigured 'vanilla' testing target.
-    4. The test communicates effectively and fails on a misconfigured 'hardened' testing target.
-    5. The test communicates effectively and clearly articulates the Not Applicable condition for both 'vanilla' and 'hardened' testing targets.
-    6. The test communicates effectively and clearly articulates the Not Reviewed condition for both the 'vanilla' and 'hardened' testing targets.
-    7. The tests have been constructed in a way that they do not produce Profile Errors when looping, using conditional logic, or when system conditions - such as missing files, directories, or services - are not in the expected locations.
+    1. The test communicates effectively and passes as expected on both the 'vanilla' and `hardened` testing targets which were correctly configured.
+    2. The test communicates effectively and fails as expected on both the `vanilla` and `hardened` testing targets which were misconfigured.
+    3. The test communicates effectively and fails as expected on a misconfigured `vanilla` target, but then passes as expected on a properly configured `hardened` target.
+    4. The test communicates effectively and clearly articulates the Not Applicable condition for both 'vanilla' and 'hardened' testing targets.
+    5. The test communicates effectively and clearly articulates the Not Reviewed condition for both the 'vanilla' and 'hardened' testing targets.
+    6. The tests have been constructed in a way that they do not produce Profile Errors when looping, using conditional logic, or when system conditions - such as missing files, directories, or services - are not in the expected locations.
 
 ## Best Practices for Test Implementation
 
@@ -111,10 +110,142 @@ For example:
 
 Let's practice implementing a basic control:
 
-1. Create a basic control test
-2. Add passing and failing scenarios
-3. Implement clear communication
-4. Test edge cases
+::: code-tabs#ruby
+
+@tab Create a basic control test
+```ruby
+control 'SV-257844' do
+  title 'RHEL 9 must use a separate file system for /tmp.'
+  desc 'The "/tmp" partition is used as temporary storage by many programs. Placing "/tmp" in its own partition enables the setting of more restrictive mount options, which can help protect programs that use it.'
+  desc 'check', 'Verify that a separate file system/partition has been created for "/tmp" with the following command:
+
+$ mount | grep /tmp
+
+tmpfs /tmp tmpfs noatime,mode=1777 0 0
+
+If a separate entry for "/tmp" is not in use, this is a finding.'
+  desc 'fix', 'Migrate the "/tmp" path onto a separate file system.'
+  impact 0.5
+  ref 'DPMS Target Red Hat Enterprise Linux 9'
+  tag severity: 'medium'
+  tag gtitle: 'SRG-OS-000480-GPOS-00227'
+  tag gid: 'V-257844'
+  tag rid: 'SV-257844r925519_rule'
+  tag stig_id: 'RHEL-09-231015'
+  tag fix_id: 'F-61509r925518_fix'
+  tag cci: ['CCI-000366']
+  tag nist: ['CM-6 b']
+  tag 'host'
+end
+```
+@tab Add passing and failing scenarios
+```ruby
+control 'SV-257844' do
+  title 'RHEL 9 must use a separate file system for /tmp.'
+  desc 'The "/tmp" partition is used as temporary storage by many programs. Placing "/tmp" in its own partition enables the setting of more restrictive mount options, which can help protect programs that use it.'
+  desc 'check', 'Verify that a separate file system/partition has been created for "/tmp" with the following command:
+
+$ mount | grep /tmp
+
+tmpfs /tmp tmpfs noatime,mode=1777 0 0
+
+If a separate entry for "/tmp" is not in use, this is a finding.'
+  desc 'fix', 'Migrate the "/tmp" path onto a separate file system.'
+  impact 0.5
+  ref 'DPMS Target Red Hat Enterprise Linux 9'
+  tag severity: 'medium'
+  tag gtitle: 'SRG-OS-000480-GPOS-00227'
+  tag gid: 'V-257844'
+  tag rid: 'SV-257844r925519_rule'
+  tag stig_id: 'RHEL-09-231015'
+  tag fix_id: 'F-61509r925518_fix'
+  tag cci: ['CCI-000366']
+  tag nist: ['CM-6 b']
+  tag 'host'
+
+  tmp = mount('/tmp')
+  is_mounted = tmp.mounted?
+  describe is_mounted do
+    it { should cmp true }
+  end
+
+  describe etc_fstab.where { mount_point == '/tmp' } do
+    it { should exist }
+  end
+end
+```
+@tab Implement clear communication
+```ruby
+control 'SV-257844' do
+  title 'RHEL 9 must use a separate file system for /tmp.'
+  desc 'The "/tmp" partition is used as temporary storage by many programs. Placing "/tmp" in its own partition enables the setting of more restrictive mount options, which can help protect programs that use it.'
+  desc 'check', 'Verify that a separate file system/partition has been created for "/tmp" with the following command:
+
+$ mount | grep /tmp
+
+tmpfs /tmp tmpfs noatime,mode=1777 0 0
+
+If a separate entry for "/tmp" is not in use, this is a finding.'
+  desc 'fix', 'Migrate the "/tmp" path onto a separate file system.'
+  impact 0.5
+  ref 'DPMS Target Red Hat Enterprise Linux 9'
+  tag severity: 'medium'
+  tag gtitle: 'SRG-OS-000480-GPOS-00227'
+  tag gid: 'V-257844'
+  tag rid: 'SV-257844r925519_rule'
+  tag stig_id: 'RHEL-09-231015'
+  tag fix_id: 'F-61509r925518_fix'
+  tag cci: ['CCI-000366']
+  tag nist: ['CM-6 b']
+  tag 'host'
+
+  describe mount('/tmp') do
+    it { should be_mounted }
+  end
+
+  describe etc_fstab.where { mount_point == '/tmp' } do
+    it { should exist }
+  end
+end
+```
+@tab Test edge cases
+```ruby
+control 'SV-257844' do
+  title 'RHEL 9 must use a separate file system for /tmp.'
+  desc 'The "/tmp" partition is used as temporary storage by many programs. Placing "/tmp" in its own partition enables the setting of more restrictive mount options, which can help protect programs that use it.'
+  desc 'check', 'Verify that a separate file system/partition has been created for "/tmp" with the following command:
+
+$ mount | grep /tmp
+
+tmpfs /tmp tmpfs noatime,mode=1777 0 0
+
+If a separate entry for "/tmp" is not in use, this is a finding.'
+  desc 'fix', 'Migrate the "/tmp" path onto a separate file system.'
+  impact 0.5
+  ref 'DPMS Target Red Hat Enterprise Linux 9'
+  tag severity: 'medium'
+  tag gtitle: 'SRG-OS-000480-GPOS-00227'
+  tag gid: 'V-257844'
+  tag rid: 'SV-257844r925519_rule'
+  tag stig_id: 'RHEL-09-231015'
+  tag fix_id: 'F-61509r925518_fix'
+  tag cci: ['CCI-000366']
+  tag nist: ['CM-6 b']
+  tag 'host'
+
+  only_if('This control is Not Applicable to containers', impact: 0.0) {
+    !virtualization.system.eql?('docker')
+  }
+
+  describe mount('/tmp') do
+    it { should be_mounted }
+  end
+
+  describe etc_fstab.where { mount_point == '/tmp' } do
+    it { should exist }
+  end
+end
+```
 
 ## Key Takeaways
 
@@ -132,9 +263,9 @@ You might use a Spreadsheet or CSV file, a Markdown or RST Table, or even a 'che
 
 All these methods are acceptable. The important thing is to **choose one method and use it consistently.**
 
-When working with multiple team members, it's crucial to have an effective way to communicate progress, understand who is working on which parts of the security guide, and know what 'still needs work' without constant direct communication.
+When working with multiple team members, it's crucial to have an effective way to communicate progress, understand who is working on which parts of the security guide, and know what still needs work without constant direct communication.
 
-The tracking method will also be influenced by the PR process you and your team select - either 'Macro' or 'Micro' - as discussed in the [Micro vs Macro](https://mitre.github.io/saf-training/courses/profile-dev-test/07.html#micro-vs-massive-pull-requests-prs) section.
+The tracking method will also be influenced by the PR process you and your team select - either 'Macro' or 'Micro' - as discussed in the [Micro vs Macro](./07.md) section.
 
 ## Example Tracking Table
 
@@ -162,10 +293,10 @@ The MITRE SAF team has found the following best practices effective for organizi
 
 1. **Group Similar Controls:** When working on a security guidance document, group the controls you are working on using the guidance indexes - such as the SRG ID in STIGs, and requirement major version in CIS Benchmarks. This allows for efficient reuse of repeated patterns of control implementation.
 
-2. **Tags, Status Columns & State:** As a team, decide on the method for tracking work progress and agree on the terminology for concepts such as 'reviewed', 'tested', and 'done'/'completed'. Refer to the [`Tracking Table`](#simple-tracking-table) example above to understand how both 'technical' and 'business' requirements are tracked and reported for each requirement in the profile.
+2. **Tags, Status Columns, and State:** As a team, decide on the method for tracking work progress and agree on the terminology for concepts such as 'reviewed', 'tested', and 'done'/'completed'. Refer to the [`Tracking Table`](#simple-tracking-table) example above to understand how both 'technical' and 'business' requirements are tracked and reported for each requirement in the profile.
 
-3. **Assign Priority & Agree on an In/Out Approach:** Every benchmark will have easy, medium, and complex requirements and tests that need implementation. You will need to review every control in the Profile, but choosing an 'easy first, hard last' or 'hard first, easy last' approach can help your team make efficient progress quickly and avoid continuous 'context switching' between straightforward and complicated testing.
+3. **Assign Priority, and Agree on an In/Out Approach:** Every benchmark will have easy, medium, and complex requirements and tests that need implementation. You will need to review every control in the Profile, but choosing an 'easy first, hard last' or 'hard first, easy last' approach can help your team make efficient progress quickly and avoid continuous 'context switching' between straightforward and complicated testing.
 
-4. **Always Strive to Have a Full Test Suite:** Ensuring the fidelity of testing is crucial. This principle applies to both the 'vanilla' and 'hardened' contexts, as well as to the 'primary deployment platforms' that your profile supports. These platforms might include Virtual Machines, Cloud Instances, and Container Deployments. Your goal should be to have both 'hardened' and 'vanilla' baselines for each deployment target. This strategy allows for easy provisioning of each platform. It also facilitates easy testing of your control on each platform as you progress from one control to another. This practice ensures that you are crafting the best possible tests for each target platform and configuration.
+4. **Always Strive to Have a Full Test Suite:** Ensuring the fidelity of testing is crucial. This principle applies to both the 'vanilla' and 'hardened' contexts, as well as to the primary deployment platforms that your profile supports. These platforms might include Virtual Machines, Cloud Instances, and Container Deployments. Your goal should be to have both 'hardened' and 'vanilla' baselines for each deployment target. This strategy allows for easy provisioning of each platform. It also facilitates easy testing of your control on each platform as you progress from one control to another. This practice ensures that you are crafting the best possible tests for each target platform and configuration.
 
 5. **Try to Test Locally First, with the Pipeline Second:** One of the key patterns highlighted in this guidance is the combination of local and CI/CD-based testing. We advocate for both approaches for a specific reason. When you are working on multiple controls, it's more efficient to test each control on each platform locally. This method is quicker than waiting for the CI/CD pipeline to create a new deployment of the test and target platforms each time. Once you have configured your targets and platforms locally with Test Kitchen, you can be confident in their stability. You should prioritize these local targets for initial testing. After testing them and when you are ready to proceed to the next control, push those updates to the CI/CD pipeline. This step verifies that your controls still function in a clean environment. This approach promotes a more efficient workflow process and eliminates the need for continuous 'push and wait' for the pipeline.