updating more screenshots, removing the step numbers in 5-7 since the…

…y dont make much sense for a doc with headers like this

Signed-off-by: Will <will@dower.dev>

src/courses/guidance/05.md

@@ -18,7 +18,7 @@ DISA has already published a RHEL9 STIG, so we will be able to compare our conte
 
 ### 5.1.2 Logging In
 
-1. Access the Vulcan training instance using the link above.
+Access the Vulcan training instance using the link above.
 
 ![Vulcan Login Page](../../assets/img/login_screen.png)
 
@@ -34,23 +34,21 @@ Vulcan categorizes security guidance content into **Projects**. Each project can
 
 We need a new Project as a workspace to write our STIG-ready content.
 
-2. In the top navbar, you'll see the Start a New Project button. 
+In the top navbar, you'll see the Start a New Project button. 
 
 ![Vulcan Navbar](../../assets/img/Vulcan_Menu.png)
 
 Click it and begin to fill out the details for our project. You can make the Title and Description of your project whatever you want, but be sure to set the Visibility of the project to "discoverable," because you'll want your colleagues to be able to peer review your work later.
 
 ![Vulcan New Project Screen](../../assets/img/start_new_project_filled_out.png)
 
-3. When you are finished, click Create Project. You'll be taken to the Project view for the workspace you just created, which is currently empty. We should fix that.
-
-
+When you are finished, click Create Project. You'll be taken to the Project view for the workspace you just created, which is currently empty. We should fix that.
 
 ### 5.1.4 Role-Based Access Control
 
 Before we create a Component, though, let's configure Role-Based Access Control (RBAC).
 
-5. Click the Members tab in the Project view to control access. Projects enforce RBAC to ensure that each author in a Vulcan instance can be restricted to only the content they need to be able to edit.
+Click the Members tab in the Project view to control access. Projects enforce RBAC to ensure that each author in a Vulcan instance can be restricted to only the content they need to be able to edit.
 
 In a new Project, you'll be the only member at first. You can add a new member with a Role of:
 

src/courses/guidance/06.md

@@ -22,7 +22,7 @@ Let's take a look at the options we have for a foundation.
 
 You'll see options in the top navbar of Vulcan for "SRGs" and "STIGs." These links lead to the lists of security guidance documents already saved to Vulcan. We can use any of these as a template for our own content.
 
-1. At the top of the page, click the "SRGs" button.
+At the top of the page, click the "SRGs" button.
 
 ![Vulcan Navbar](../../assets/img/Vulcan_Menu.png)
 
@@ -74,9 +74,7 @@ Vulcan allows you to import Components as well as creating them brand-new. You a
 
 ## 6.3 Examining the Component
 
-Let's crack open what we just created.
-
-6. Click the "Open Component" button.
+Let's crack open what we just created. Click the "Open Component" button.
 
 ![An Open Component](../../assets/img/open_component.png)
 
@@ -90,7 +88,7 @@ On the right-hand side of the Vulcan window, if we don't have a requirement sele
 
 ![Component Metadata](../../assets/img/component_metadata.png)
 
-6. On the left side of the page, scroll down to the section titled "All Controls". These are all of the requirements in the SRG we selected earlier.
+On the left side of the page, scroll down to the section titled "All Controls". These are all of the requirements in the SRG we selected earlier.
 
 The left-hand side of the Vulcan window shows us the list of each requirement in the Component, and can be filtered by keyword, control status (which we will discuss in the next section) or review status. Note that each control is labeled with the STIG ID prefix that you gave this Component earlier. You can click on the requirement IDs in this view to see their contents.
 

src/courses/guidance/07.md

@@ -14,7 +14,7 @@ Let's practice.
 
 ## 7.2 The Editing Window
 
-1. Click the "Edit Component Controls" button at the top of your Vulcan window on the left hand side.
+Click the "Edit Component Controls" button at the top of your Vulcan window on the left hand side.
 
 ![Edit Component Controls Button](@/../../../assets/img/edit_controls.png)
 
@@ -26,7 +26,7 @@ STIGs are technically comprised of a set of *requirements,* but each requirement
 Many organizations tend to conflate these terms.
 :::
 
-2. Now let's select a requirement. On the left-hand side of the Vulcan Component view you will see a list of every single requirement Let's start with RHEL-09-000130. (Normally, we'd start with number 1, but for this exercise we're picking a simple example.)
+Now let's select a requirement. On the left-hand side of the Vulcan Component view you will see a list of every single requirement Let's start with RHEL-09-000004. (Normally, we'd start with number 1, but for this exercise we're picking a simple example.)
 
 ![Selecting a Requirement](@/../../../assets/img/selecting_controls.png)
 
@@ -35,7 +35,7 @@ You'll see a view of the requirement's text fields, like the vulnerability discu
 ![An Unedited Requirement](@/../../../assets/img/selected_control.png)
 
 Note how all of these text fields are:
-- Pre-populated with the underlying SRG data for the general requirement (in this case SRG-OS-000366-GPOS-00153)
+- Pre-populated with the underlying SRG data for the general requirement (in this case SRG-OS-000021-GPOS-00005)
 - Grayed-out and uneditable at present.
 
 We can't edit these text fields yet because we haven't yet told Vulcan if this requirement is even applicable to our Component. Let's fix that.
@@ -52,6 +52,8 @@ The process of tailoring SRG requirements into specific STIG controls first requ
 
 - **Not Applicable**: The requirement addresses a capability or use case that the product does not support.
 
+(Note that these definitions come straight from DISA's "Vendor STIG Process" document, so what we call "Components" they call "products.")
+
 If you select any status other than "Applicable - Configurable" for a requirement, you'll need to fill out a few fields explaining why you did so. We'll take a look at a requirement like that in a moment.
 
 ### 7.3.1 Picking a Status
@@ -80,37 +82,40 @@ flowchart TB
     id4 --> id5(Yes)
     id4 --> id6(No)
     id5 --> in
-    id6 --> id7[Is the requirement something that my Component does inherently,\nand this cannot be changed by changing the configuration?]
+    id6 --> id7[Is the requirement something that my Component does inherently, and this cannot be changed by changing the configuration?]
     id7 --> id8(Yes)
     id7 --> id9(No)
     id8 --> im
     id9 --> ac
 ```
 
 ### 7.3.2 Our First Requirement Status
-3. Let's pick a status for RHEL-09-000130. We will do this by reading the SRG requirement and determining if it applies to this particular component, and if so, if it is an innate feature of the system or not.
 
-The requirement's title is *"The operating system must audit all account creations."*
+Let's pick a status for RHEL-09-000004. We will do this by reading the SRG requirement and determining if it applies to this particular component, and if so, if it is an innate feature of the system or not.
+
+The requirement's title is *"The operating system must enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period."*
 
 ::: details Based on the title, do you think this requirement applies to RHEL9 or not? If it applies, does RHEL9 need to be configured/can it be configured to do it?
-This requirement does apply. RHEL9, like any other operating system, must have a functioning auditing system; no inherent aspect of RHEL would change this.
+This requirement does apply. RHEL9, like any other operating system, must be able to lock down an account to stop someone from simply brute-forcing the password.
 
-RHEL9, like all operating systems, has a built in auditing capability. The auditing capability is configurable (i.e. it is possible to have the system configured to *either* meet or not meet this requirement).
+RHEL9, luckily, has a built-in capability to do this. RHEL's `authselect` utility can turn on the faillock feature. Note that this requirement is considered configurable (i.e. it is possible to have the system configured to *either* meet or not meet this requirement).
 :::
 ::: tip How do we know all this about the system?
-If you are not familiar with the RHEL9 auditing system, don't worry; it's just an example we're using for the class. We promise we will not quiz you on how the `auditd` service works.
+If you are not familiar with the RHEL9 auditing system, don't worry; it's just an example we're using for the class. We promise we will not quiz you on how the `authselect` utility works.
 
 If you have to develop STIG content for a project, it will concern a Component that you are familiar with enough to answer these questions (or are at least in a position to research).
 :::
 ::: details Based on your decision, what status should we give this component?
-We would consider this requirement **Applicable - Configurable.** The system is capable of complying with the SRG requirement, but only if properly configured.
+We would consider this requirement **Applicable - Configurable.** The system is capable of complying with the SRG requirement, but _only if properly configured_.
 :::
 
-4. Based on our decision, let's edit the status field in the Component editing screen.
+Based on our decision, let's edit the status field in the Component editing screen.
 ::: details Changing status
-![Updating the Status on RHEL-09-000130](@/../../../assets/img/assigning_status.png)
+![Updating the Status on RHEL-09-000004](@/../../../assets/img/assigning_status.png)
+
+In the wild, it may be the case that most SRG requirements wind up being to Configurable - Applicable to your Component, and only a handful may be either Not Applicable, Inherently Met or Inherently Not Met. Or vice versa; many applications writing up guidance based on the ASD STIG realize that most of those requirements are not applicable to their simple web apps.
 
-Hint: Most SRG requirements wind up being applicable to Components. A handful may be either Not Applicable, Inherently Met or Inherently Not Met. We still have to check.
+We still have to check each one to be sure!
 :::
 
 Note that once we select the status, the text fields become editable. Now we can tailor the general guidance from the SRG into specific guidance.
@@ -119,7 +124,7 @@ Before we do that, let's investigate a the Status field a bit more.
 
 ### 7.3.3 Another Requirement Status
 
-5. Let's double back and pick an example with a different status. On the sidebar, click on RHEL-09-000045.
+Let's double back and pick an example with a different status. On the sidebar, click on RHEL-09-000045.
 
 ![RHEL-09-000045](@/../../../assets/img/inherently_met_control.png)
 
@@ -133,7 +138,7 @@ However, you may know that RHEL (and all Linux OSes) obscure user passwords when
 As such, the status should be **Applicable - Inherently Meets.**
 :::
 
-6. Let's once again update the status of our requirement to match what we picked.
+Let's once again update the status of our requirement to match what we picked.
 
 ::: details Updating Status
 ![RHEL-09-000045](@/../../../assets/img/inherently_met_control_picking_status.png)
@@ -215,7 +220,7 @@ For example, an author may add their references for a control's Check or Fix tex
 
 We will not complete the Artifact field in RHEL-09-000045 because digging around in the RHEL9 source code is beyond the scope of this course.
 
-7. However, let's be sure to enter in a Status Justification:
+However, let's be sure to enter in a Status Justification:
 
 **RHEL9 automatically obfuscates user passwords in the graphical user interface and at the command line interface.**