Merge branch 'main' into mapperCreationCourse

mitre · Dec 2, 2024 · dbcf0e0 · dbcf0e0
2 parents 1882b69 + 7c3d4e1
commit dbcf0e0
Show file tree

Hide file tree

Showing 84 changed files with 883 additions and 883 deletions.
diff --git a/README.md b/README.md
@@ -33,7 +33,7 @@ We extend our special thanks to the author of this VuePress theme - A New Hope,
 
 ## Requirements
 
-- Node v18+
+- Node v18.18+
 
 ## Running 
 

diff --git a/package-lock.json b/package-lock.json
diff --git a/package.json b/package.json
@@ -16,12 +16,12 @@
   },
   "devDependencies": {
     "@vuepress/bundler-vite": "2.0.0-rc.18",
-    "@vuepress/plugin-markdown-image": "2.0.0-rc.60",
-    "@vuepress/plugin-markdown-tab": "2.0.0-rc.60",
+    "@vuepress/plugin-markdown-image": "2.0.0-rc.61",
+    "@vuepress/plugin-markdown-tab": "2.0.0-rc.61",
     "cypress": "^13.16.0",
     "cypress-each": "^1.14.0",
     "flowchart.ts": "^3.0.1",
-    "mermaid": "^11.4.0",
+    "mermaid": "^11.4.1",
     "start-server-and-test": "^2.0.8",
     "vue": "^3.5.13",
     "vuepress": "2.0.0-rc.18",

diff --git a/src/.vuepress/navbar.ts b/src/.vuepress/navbar.ts
@@ -17,7 +17,7 @@ export default navbar([
     icon: "book",
     children: [
       { text: "Class Resources", link: "/resources/README.md"},
-      { text: "Codespace Resources", link: "/resources/02.md"},
+      { text: "Training Lab Environments", link: "/resources/02.md"},
       { text: "Training Development Docs", link: "/resources/03.md"},
     ]},
   { text: "Installation", icon: "note", link: "/installation/" }

diff --git a/src/assets/downloads/U_Vendor_STIG_Process_Guide_V4R1_20220815.pdf b/src/assets/downloads/U_Vendor_STIG_Process_Guide_V4R1_20220815.pdf
diff --git a/src/assets/img/RHEL-09-000005.png b/src/assets/img/RHEL-09-000005.png
diff --git a/src/assets/img/RHEL-09-000006.png b/src/assets/img/RHEL-09-000006.png
diff --git a/src/assets/img/add_questions_modal.png b/src/assets/img/add_questions_modal.png
diff --git a/src/assets/img/already_satisfied.png b/src/assets/img/already_satisfied.png
diff --git a/src/assets/img/also_satisfies.png b/src/assets/img/also_satisfies.png
diff --git a/src/assets/img/approve_the_control.png b/src/assets/img/approve_the_control.png
diff --git a/src/assets/img/assigning_status.png b/src/assets/img/assigning_status.png
diff --git a/src/assets/img/before_and_after.png b/src/assets/img/before_and_after.png
diff --git a/src/assets/img/check_and_fix_updated.png b/src/assets/img/check_and_fix_updated.png
diff --git a/src/assets/img/component_metadata.png b/src/assets/img/component_metadata.png
diff --git a/src/assets/img/component_view.png b/src/assets/img/component_view.png
diff --git a/src/assets/img/control_body.png b/src/assets/img/control_body.png
diff --git a/src/assets/img/copying_existing_content.png b/src/assets/img/copying_existing_content.png
diff --git a/src/assets/img/create_component.png b/src/assets/img/create_component.png
diff --git a/src/assets/img/created_component.png b/src/assets/img/created_component.png
diff --git a/src/assets/img/describe_block.png b/src/assets/img/describe_block.png
diff --git a/src/assets/img/diff.png b/src/assets/img/diff.png
diff --git a/src/assets/img/duplicate.png b/src/assets/img/duplicate.png
diff --git a/src/assets/img/editing_duplicate.png b/src/assets/img/editing_duplicate.png
diff --git a/src/assets/img/export_buttons.png b/src/assets/img/export_buttons.png
diff --git a/src/assets/img/filling_out_request_for_review.png b/src/assets/img/filling_out_request_for_review.png
diff --git a/src/assets/img/inherently_met_control.png b/src/assets/img/inherently_met_control.png
diff --git a/src/assets/img/inherently_met_control_picking_status.png b/src/assets/img/inherently_met_control_picking_status.png
diff --git a/src/assets/img/inspec_full.png b/src/assets/img/inspec_full.png
diff --git a/src/assets/img/justification.png b/src/assets/img/justification.png
diff --git a/src/assets/img/many_reqs.png b/src/assets/img/many_reqs.png
diff --git a/src/assets/img/members_view.png b/src/assets/img/members_view.png
diff --git a/src/assets/img/open_component.png b/src/assets/img/open_component.png
diff --git a/src/assets/img/r_and_c.png b/src/assets/img/r_and_c.png
diff --git a/src/assets/img/related_rules.png b/src/assets/img/related_rules.png
diff --git a/src/assets/img/review_status.png b/src/assets/img/review_status.png
diff --git a/src/assets/img/review_status_filter.png b/src/assets/img/review_status_filter.png
diff --git a/src/assets/img/revision_history.png b/src/assets/img/revision_history.png
diff --git a/src/assets/img/satisfies.png b/src/assets/img/satisfies.png
diff --git a/src/assets/img/saving_requirement.png b/src/assets/img/saving_requirement.png
diff --git a/src/assets/img/selected_control.png b/src/assets/img/selected_control.png
diff --git a/src/assets/img/selecting_also_satisfies.png b/src/assets/img/selecting_also_satisfies.png
diff --git a/src/assets/img/selecting_controls.png b/src/assets/img/selecting_controls.png
diff --git a/src/assets/img/srgcontents.png b/src/assets/img/srgcontents.png
diff --git a/src/assets/img/start_new_project_filled_out.png b/src/assets/img/start_new_project_filled_out.png
diff --git a/src/assets/img/stig_search.png b/src/assets/img/stig_search.png
diff --git a/src/assets/img/stig_view.png b/src/assets/img/stig_view.png
diff --git a/src/assets/img/updated_project_view.png b/src/assets/img/updated_project_view.png
diff --git a/src/assets/img/view_related_rules.png b/src/assets/img/view_related_rules.png
diff --git a/src/courses/advanced/Appendix A - Writing Plural Resources.md b/src/courses/advanced/Appendix A - Writing Plural Resources.md
@@ -5,7 +5,7 @@ author: Aaron Lippold
 headerDepth: 3
 ---
 
-## 10. Plural Resources
+## Plural Resources
 
 You  might have noticed that many InSpec resources have a "plural" version. For example, `user` has a `users` counterpart, and `package` has `packages`.
 
@@ -30,7 +30,7 @@ This test queries **all** users to confirm that the only one with a uid of zero
 
 Plural InSpec resources are created by leveraging Ruby's FilterTable module to capture system data. Let's dig into how FilterTable works so that you can write your own plural resources.
 
-### 10.1. Using FilterTable to write a Plural Resource
+### Using FilterTable to write a Plural Resource
 
 FilterTable is intended to help you author plural resources with **stucture data**. You declare a number of columns of data, attach them to a FilterTable object, and then write methods that the FilterTable can call to populate those columns. You can also define custom matchers that make sense for whatever data you are modeling (to go alongside the standard InSpec matchers like `be_in`,`include`, and `cmp`). You wind up with a queryable structure:
 
@@ -47,11 +47,11 @@ inspec> etc_hosts.entries
 
 ```
 
-#### 10.1.1. May I have multiple FilterTable installations on a class?
+#### May I have multiple FilterTable installations on a class?
 
 In theory, yes - that would be used to implement different data fetching / caching strategies.  It is a very advanced usage, and no core resources currently do this, as far as we know.
 
-### 10.2. FilterTable Hands-On
+### FilterTable Hands-On
 
 Let's take a look at the structure of a resource that leverages FilterTable. We will write a dummy resource that models a small group of students. Our resource will describe each student's name, grade, and the toys they have. Usually, a resource will include some methods that reach out the system under test to populate the FilterTable with real system data, but for now we're just going to hard-code in some dummy data.
 
@@ -99,23 +99,23 @@ end
 ```
 Now we've got a nice blob of code in a resource file. Let's load this resource in the InSpec shell and see what we can do with it.
 
-#### 10.2.1. Run the InSpec shell with a custom resource
+#### Run the InSpec shell with a custom resource
 
 Invoking the InSpec shell with `inspec shell` will give you access to all the core InSpec resources by default, but InSpec does not automatically know about your locally defined resources unless you point them out. If you're testing a local resource, use the `--depends` flag and pass in the profile directory that your resource lives in.
 
 ```
 inspec shell --depends /path/to/profile/root/
 ```
 
-#### 10.2.2. Fetching Data
+#### Fetching Data
 
 FilterTables organize their data into columns. Your resource will declare a number of columns using the `register_column` method.
 
 Once you declare the columns that you want in your FilterTable (`name`, `grade`, and `toys` in our example), you need to insert some data into them using  the `install_filter_methods_on_resource` method. That method takes two args -- `self` and a data structure that is an array of hashes. The array of hashes will be matched up to the columns you defined using the hashes' keys. For our example we hard-coded this data structure, which is returned by the `fetch_data` method.
 
 As we mentioned earlier, a real InSpec resource will include methods that will populate the resource with real system data. Take a look at the [Firewalld resource](https://github.com/inspec/inspec/blob/63a5fd26a6925b1570ee80e2953d259b58c3012e/lib/inspec/resources/firewalld.rb) for an example of a resource that does this -- note the resource is ultimately invoking a shell command (`firewall-ctl`) to populate its FilterTable. There are plenty of other InSpec resources using FilterTable that you can find in the source code if you are interested in more examples.
 
-#### 10.2.3. Custom Matcher Examples
+#### Custom Matcher Examples
 
 After we define our FilterTable's columns, we can also define custom matchers just like we do in singluar resources using `register_custom_matcher`. That function takes a block as an argument that defines a boolean expression that tells InSpec when that matcher should return `true`. Note that the matcher's logic can get pretty complicated -- that's why we're shoving all of it into a resource so we can avoid having to write complicated tests.
 
@@ -167,7 +167,7 @@ Test Summary: 1 successful, 0 failures, 0 skipped
 
 ```
 
-#### 10.2.4. Custom Property
+#### Custom Property
 
 We can also declare custom properties for our resource, using whatever logic we like, just like we did for our custom matchers. Properties can be referred to with `its` syntax in an InSpec test. 
 
@@ -209,7 +209,7 @@ Test Summary: 0 successful, 1 failure, 0 skipped
 
 ```
 
-#### 10.2.5. Suggested activity
+#### Suggested activity
 
 To get a better feel for how FilterTable works, we suggest you add a few extra features to the sample given above.
 
@@ -219,11 +219,11 @@ To get a better feel for how FilterTable works, we suggest you add a few extra f
 
 Then write some tests to see how your new matchers and properties work.
 
-### 10.3. Predefined Methods for FilterTable
+### Predefined Methods for FilterTable
 
 When you create a new FilterTable, these methods are installed automatically: `where`, `entries`, `raw_data`, `count`, and `exist?`. Each is very useful both for writing tests in and of themselves and for creating custom matchers and properties inside the resource code.
 
-#### 10.3.1 The `where` method
+#### The `where` method
 
 You may have already noticed that a bunch of our example tests are using the `where` method on the FilterTable object. This method returns a new FilterTable object created from the rows of the original table that match the query provided to `where`. If you have experience with relational databases, think of it like the `WHERE` clause in a SQL query. This method is extremely flexible; we give some examples below.
 
@@ -255,7 +255,7 @@ You may have already noticed that a bunch of our example tests are using the `wh
 
 ```
 
-##### 10.3.1.1. `where` method with blocks
+##### `where` method with blocks
 
 You can also call the `where` method with a block. The block is executed row-wise. If it returns truthy, the row is included in the results. Each field declared with the `register_custom_property` configuration method is available as a data accessor.
 
@@ -272,7 +272,7 @@ You can also call the `where` method with a block. The block is executed row-wis
   end
 ```
 
-##### 10.3.1.2. Chaining `where` calls and Tables without re-fetching raw data
+##### Chaining `where` calls and Tables without re-fetching raw data
 
 The first time `where` is called, the data fetcher method is called.  `where` performs filtration on the raw data table.  It then constructs a new `FilterTable::Table`, directly passing in the filtered raw data; this is then the return value from `where`.
 
@@ -285,7 +285,7 @@ The first time `where` is called, the data fetcher method is called.  `where` pe
 
 Some other methods return a Table object, and they may be chained without a re-fetch as well.
 
-#### 10.3.2. The `entries` method
+#### The `entries` method
 
 The other `register_filter_method` call enables a pre-defined method, `entries`.  `entries` is much simpler than `where` - in fact, its behavior is unrelated.  It returns an encapsulated version of the raw data - a plain array, containing Structs as row-entries.  Each struct has an attribute for each time you called `register_column`.
 
@@ -319,7 +319,7 @@ If you call `entries` without chaining it after `where`, calling entries will tr
   end
 ```
 
-#### 10.3.3. The `exist?` matcher
+#### The `exist?` matcher
 
 This `register_custom_matcher` call:
 ```ruby
@@ -342,7 +342,7 @@ As when you are implementing matchers on a singular resource, the only thing tha
   end
 ```
 
-#### 10.3.4. The `count` property
+#### The `count` property
 
 This `register_custom_property` call:
 ```ruby
@@ -363,7 +363,7 @@ causes a new method to be defined on both the resource class and the Table class
   end
 ```
 
-#### 10.3.5. The `raw_data` method
+#### The `raw_data` method
 
 Unlike `entries`, which wraps each row in a Struct and omits undeclared fields, `raw_data` simply returns the actual raw data array-of-hashes.  It is not `dup`'d. People _definitely_ use this out in the wild, even though it returns a rougher data structure.
 
@@ -377,7 +377,7 @@ Unlike `entries`, which wraps each row in a Struct and omits undeclared fields,
   end
 ```
 
-### 10.4 FilterTable Examples
+### FilterTable Examples
 
 FilterTable is a very flexible and powerful class that works well when designing plural resources. As always, if you need to write a plural resource, we encourage you to examine existing resources in the InSpec source code to see how other developers have implemented it. Some good examples include:
  - [FirewallD](https://github.com/inspec/inspec/blob/63a5fd26a6925b1570ee80e2953d259b58c3012e/lib/inspec/resources/firewalld.rb)

diff --git a/src/courses/advanced/Appendix B - Resource Examples.md b/src/courses/advanced/Appendix B - Resource Examples.md
@@ -7,8 +7,9 @@ headerDepth: 3
 
 As an example we will go through a few custom resources that were built and approved.
 
-### 14.1. IPv6 resource
-#### 14.1.1. docs/resources/ip6tables.md.erb
+### The IPv6 resource
+
+#### docs/resources/ip6tables.md.erb
 ```ruby
 ---
 title: About the ip6tables Resource
@@ -86,7 +87,7 @@ The `have_rule` matcher tests the named rule against the information in the `ip6
     it { should have_rule('RULE') }
 ```
 
-#### 14.1.2. lib/inspec/resources.rb
+#### lib/inspec/resources.rb
 ```ruby
 require "inspec/resources/iis_site"
 require "inspec/resources/inetd_conf"
@@ -97,7 +98,7 @@ require "inspec/resources/kernel_module"
 require "inspec/resources/kernel_parameter"
 ```
 
-#### 14.1.3. lib/inspec/resources/ip6tables.rb
+#### lib/inspec/resources/ip6tables.rb
 ```ruby
 require "inspec/resources/command"
 
@@ -184,7 +185,7 @@ end
 While submitting PR it may be possible to extend existing test elements from current resources to perform integration and unit testing such is seen in this example, the ipv6 resource extends the testing for [iptables](https://www.inspec.io/docs/reference/resources/iptables/) resource
 :::
 
-#### 14.1.4. test/integration/default/controls/ip6tables_spec.rb
+#### test/integration/default/controls/ip6tables_spec.rb
 ```ruby
 case os[:family]
 when 'ubuntu', 'fedora', 'debian', 'suse'
@@ -211,7 +212,7 @@ when  'redhat', 'centos'
 end
 ```
 
-#### 14.1.5. test/unit/resources/ip6tables_test.rb
+#### test/unit/resources/ip6tables_test.rb
 ```ruby
 require "helper"
 require "inspec/resource"
@@ -247,8 +248,8 @@ describe "Inspec::Resources::Ip6tables" do
 end
 ```
 
-### 14.2. NGINX resource
-#### 14.2.1. docs/resources/nginx.md.erb
+### The NGINX resource
+#### docs/resources/nginx.md.erb
 ```ruby
 ---
 title: The Nginx Resource
@@ -324,7 +325,7 @@ where
     end
 ```
 
-#### 14.2.2. lib/inspec/resource.rb
+#### lib/inspec/resource.rb
 ```ruby
 require 'resources/mysql'
 require 'resources/mysql_conf'
@@ -335,7 +336,7 @@ require 'resources/npm'
 require 'resources/ntp_conf'
 ```
 
-#### 14.2.3. lib/resources/nginx.rb
+#### lib/resources/nginx.rb
 ```ruby
 # encoding: utf-8
 # author: Aaron Lippold, [email protected]
@@ -436,7 +437,7 @@ module Inspec::Resources
 end
 ```
 
-#### 14.2.4. test/unit/resources/nginx_test.rb
+#### test/unit/resources/nginx_test.rb
 ```ruby
 # encoding: utf-8
 # author: Aaron Lippold, [email protected]
@@ -534,10 +535,11 @@ describe 'Inspec::Resources::Nginx' do
 end
 ```
 
-### 14.3. Additional examples
-#### 14.3.1. PAM resource currently open PR
+### Additional examples
+
+#### PAM resource currently open PR
 - [PAM Resource](https://github.com/simp/inspec-profile-disa_stig-el7/blob/master/libraries/pam.rb)
 - [PAM PR](https://github.com/inspec/inspec/pull/3993)
 
-#### 14.3.2. Customizing an already existing resource (windows registry)
+#### Customizing an already existing resource (windows registry)
 - [https://github.com/mitre/microsoft-windows-2012r2-memberserver-stig-baseline/blob/master/libraries/windows_registry.rb](https://github.com/mitre/microsoft-windows-2012r2-memberserver-stig-baseline/blob/master/libraries/windows_registry.rb)
diff --git a/src/courses/advanced/Appendix E - More Resource Examples.md b/src/courses/advanced/Appendix E - More Resource Examples.md
@@ -5,7 +5,7 @@ author: Aaron Lippold
 headerDepth: 3
 ---
 
-### 11.1. File
+### The File Resource
 ```ruby
 # copyright: 2015, Vulcano Security GmbH
 
@@ -371,7 +371,7 @@ module Inspec::Resources
 end
 ```
 
-### 11.3. etc_hosts
+### The etc_hosts Resource
 ```ruby
 require "inspec/utils/parser"
 require "inspec/utils/file_reader"

diff --git a/src/courses/guidance/02.md b/src/courses/guidance/02.md
@@ -30,7 +30,13 @@ This class content will be giving heavy focus to STIGs, since Vulcan was origina
 
 ### 2.1.1 Organizational Policy vs. Baselines
 
-Many organizations that use popular secrity guidance documents as their baselines have their own specific organizational security policies which conflict with that baseline. For example, let's say that the STIG for the Red Hat 8 operating system specifies that users should have, at minimum, 15 characters in their passwords, but your company's security policy requires a minimum of 20.
+Many organizations that use popular secrity guidance documents as their baselines have their own specific organizational security policies which conflict with that baseline. For example, consider the following requirement in the STIG for the Red Hat 9 operating system:
+
+```
+SV-258055 - RHEL 9 must automatically lock the root account until the root account is released by an administrator when three unsuccessful logon attempts occur during a 15-minute time period.
+```
+
+Let's say that the organization that you work for wants to enforce STIG requirements on its systems, but it also has its own internal security policy that is even more stringent than the STIG -- the root account should lock after _two_ unsuccessful logon attempts in _10_ minutes. This is a common situation in the wild, where your system might fall under multiple overlapping (or conflicting!) requirements.
 
 Consequently, many government agencies use baseline security guidance as foundations to create their own tailored content for in-house use. In addition to Vulcan's usual workflow for creating new baselines, you can use it to ingest a published baseline document and conduct this tailoring process to create security guidance tailored to your organization.
 
@@ -50,7 +56,7 @@ Your first question when planning for securing your software component should al
 
 ### 2.2.1 What Do I Do If There Isn't Already Published Guidance Documentation Available For It?
 
-Similarly, if you need to secure a software component that *does not* have a published guidance document already, your best strategy is to find the next-closest guidance document and use it to inform the content you create. You can think of the process of writing security guidance as an open-book test; you should feel free to borrow the best ideas other from other baselines!
+If you need to secure a software component that *does not* have a published guidance document already, your best strategy is to find the next-closest guidance document and use it to inform the content you create. You can think of the process of writing security guidance as an open-book test; you should feel free to borrow the best ideas other from other baselines!
 
 In the case of STIGs, DISA's official guidance (as per their [FAQ](https://public.cyber.mil/stigs/faqs/#toggle-id-11)) states to check for a STIG for an earlier version of the same software and modify it as necessary.