DEC Training - Guidance Course (#263)

* typos, adding details, updating control in section 7 to use a more intuitive example Signed-off-by: Will <[email protected]> * fixing navbar to show all resource pages, combining and updating resource pages, adding the STIG vendor process guide as a downloadable PDF Signed-off-by: Will <[email protected]> * updating the screenshots to use the right component (updating examples to be based off of most recent GPOS SRG Signed-off-by: Will <[email protected]> * updating more screenshots, removing the step numbers in 5-7 since they dont make much sense for a doc with headers like this Signed-off-by: Will <[email protected]> * updating images to use correct SRG version, fleshing out some sections, typos/copyediting Signed-off-by: Will <[email protected]> * section 7 too long, decided it needed to be its own section -- TODO: decide if we want more content re: adding requirements Signed-off-by: Will <[email protected]> * updating diff viewer section Signed-off-by: Will <[email protected]> * flow editing for STIGs Signed-off-by: Will <[email protected]> * typos Signed-off-by: Will <[email protected]> --------- Signed-off-by: Will <[email protected]>
mitre · Dec 2, 2024 · c9db76a · c9db76a
1 parent 7e6a5b6
commit c9db76a
Show file tree

Hide file tree

Showing 63 changed files with 395 additions and 311 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/src/.vuepress/navbar.ts b/src/.vuepress/navbar.ts
@@ -16,7 +16,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/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.
 

diff --git a/src/courses/guidance/03.md b/src/courses/guidance/03.md
@@ -8,6 +8,10 @@ headerDepth: 3
 
 ## 3.1 Security Technical Implementation Guides
 
+For the purposes of this class, we will be focusing in on one particular security baseline called a STIG. While MITRE SAF(c)'s Vulcan application is intended to be useful for creatign many types of security documentation, it was originally created with the STIG-writing process in mind.
+
+## 3.2.1 What is a STIG?
+
 A **Security Technical Implementation Guide (STIG)** is a set of requirements imposed by the US Department of Defense and implementation instructions for those requirements that are specific to a paticular software component. The components can be any piece of technology that needs a secure configuration -- operating systems, webservers, application runtimes, routers, and so on.
 
 STIGs are published by the Defense Information Systems Agency (DISA), but they're usually written by software vendors, which naturally have the most domain knowledge about how to secure their products. DISA then peer reviews the vendor's draft content to ensure it meets its rigorous standards. We'll describe the process for working with DISA to formally publish a STIG later on.
@@ -18,7 +22,7 @@ STIGs are also expected to stay up-to-date alongside the software component they
 Have you ever been required to configure an application or system to STIG-standard before?
 :::
 
-## 3.2 Security Requirements Guides
+## 3.2.2 What is a Security Requirements Guide?
 
 STIGs are created based off of high-level, general guidance documents called **Security Requirements Guides (SRGs)**, also published by DISA. SRGs describe DOD-selected security requirements for entire categories of software components, and all STIG requirements are essentially sets of instructions for how to get a particular component to comply with a general SRG (or even a set of SRGs, for complex systems). STIGs are instructions for security that can be followed even by people who are not experts in the technology in question.
 
@@ -28,13 +32,13 @@ STIGs can include hundreds of individual requirements depending on the complexit
 We need a way to track and manage all of these easily!
 :::
 
-### 3.2.1 SRGs and STIGs - Example
+### 3.2.3 SRGs and STIGs - Example
 
 For example, there is an SRG that covers operating systems in general (the aptly-named "General Purpose Operating System Security Requirements Guide"). That piece of guidance is full of requirements for an operating system -- *any* operating system -- to be considered reasonably secure. There is a requirement in that SRG (SRG ID: SRG-OS-000021-GPOS-00005) which states that "The operating system must enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period."
 
 This requirement is saying that an attacker shouldn't be able to brute force a user's password by throwing a high number of guesses at the system. Simple enough, right?
 
-However, this guidance isn't particularly useful unless we know how to **implement it** on a particular operating system. That's where the STIG comes in. The STIG for, say, Red Hat 8 ("Red Hat Enterprise Linux 8 STIG") has its own requirement for limiting consecutive logon attempts (Rule ID: SV-230334r627750_rule) that cites the relevant SRG IDs that it satisfies. That STIG rule tells us *exactly how to configure Red Hat to satisfy this requirement*, down to which configuration files we need to edit.
+However, this guidance isn't particularly useful unless we know how to **implement it** on a particular operating system. That's where the STIG comes in. The STIG for, say, Red Hat 9 ("Red Hat Enterprise Linux 9 STIG") has its own requirement for limiting consecutive logon attempts (Rule ID: SV-258055r926152_rule) that cites the relevant SRG IDs that it satisfies. That STIG rule tells us *exactly how to configure Red Hat to satisfy this requirement*, down to which configuration files we need to edit.
 
 You can think of the process of STIG authorship as *distilling* the high-level, general requirements of an SRG into a checklist that anybody can follow to lock down their component.
 
@@ -44,6 +48,8 @@ STIGs are ideally created by a team of subject matter experts on a particular pi
 
 ## 3.3 Where Do All The Requirements Come From, Anyway?
 
+A STIG is a tailored SRG. But where do the SRG requirements come from? There exists a hierarchy of policies and directives that sit "upstream" of a STIG document. Let's walk through them from top to bottom.
+
 Published directives from the DOD's Chief Information Officer (DOD CIO) describe the overall Risk Management Framework for DOD Systems (DOD RMF). The DOD RMF requires all information systems across the DOD to be categorized according to how much risk they represent to the organization if compromised. It also requires system owners to select controls from the National Institute of Standards and Technology's (NIST) security control families.
 
 ::: note NIST Control Families 
@@ -60,4 +66,4 @@ As described before, an SRG can then be tailored into STIGs that give security g
 
 ### 3.3.1 Now For The Good News
 
-The good news is that you, the STIG content author, don't have to worry about SRGs or control selections all that much; the whole point of all the good work that DISA has done is that most of these mappings have been done for you. You are responsible for the last leg of the journey -- you know your requirements from the SRG, and now you need to figure out how to implement them as a configuration baseline.
+The good news is that you, the STIG content author, don't have to worry about SRGs or control selections all that much; the whole point of all the good work that DISA has done is that most of these mappings have been done for you. You are responsible for the last leg of the journey -- you know your requirements from the SRG, and now you need to figure out how to implement them as a configuration baseline for your particular piece of software.
diff --git a/src/courses/guidance/05.md b/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,21 +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 emtpy. 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:
 
@@ -64,6 +64,9 @@ Write and approve changes to a Control.
 ::: details Admin
 Full control of a Project or Component. Lock Controls, revert controls, and manage members. You'll note that the Project's creator is automatically an admin.
 :::
+
+![Members View](../../assets/img/members_view.png)
+
 ::: tip Adding Colleagues
 If you have any colleagues taking the class with you, you may want to add them as a reviewer now (note that you can only add members to a project if they have registered to the Vulcan instance already).
 :::

diff --git a/src/courses/guidance/06.md b/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)
 
@@ -86,10 +84,18 @@ The page should look something like this:
 
 ![Inside the Component](../../assets/img/component_view.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 right-hand side of the Vulcan window, if we don't have a requirement selected, we can see metadata about the overall Component, including an edit history.
 
+![Component Metadata](../../assets/img/component_metadata.png)
+
+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.
 
-When first created, a new Component's requirements will all be exact copies of the SRG or other underlying document we used as a foundation. Our job is to edit these controls to make them *specific*, *actionable* implementation guidance.
+When first created, a new Component's requirements will be an exact one-to-one copy of the requirements in the SRG or other underlying document we used as a foundation. Our job is to edit these controls to make them *specific*, *actionable* implementation guidance.
+
+::: warning Will I always have a single SRG requirement map to a single STIG-Ready requirement?
+Not necessarily. During your work on this document, you may realize that a single configuration action that you can take on the system will cover multiple upstream SRG requirements.
+
+Vulcan's 'Also Satisfies' feature can be used to cover this case. For starters, though, the Component simply generates a one-to-one set of requirements from the SRG.
+:::