diff --git a/README.md b/README.md index 8323946f8..2f98883d2 100644 --- 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 index d68b8f2e4..d0e67529f 100644 --- 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 new file mode 100644 index 000000000..c17a418a0 Binary files /dev/null and b/src/assets/downloads/U_Vendor_STIG_Process_Guide_V4R1_20220815.pdf differ diff --git a/src/assets/img/RHEL-09-000005.png b/src/assets/img/RHEL-09-000005.png new file mode 100644 index 000000000..86e38b022 Binary files /dev/null and b/src/assets/img/RHEL-09-000005.png differ diff --git a/src/assets/img/RHEL-09-000006.png b/src/assets/img/RHEL-09-000006.png new file mode 100644 index 000000000..c2dc90e03 Binary files /dev/null and b/src/assets/img/RHEL-09-000006.png differ diff --git a/src/assets/img/add_questions_modal.png b/src/assets/img/add_questions_modal.png new file mode 100644 index 000000000..2bf96e4c8 Binary files /dev/null and b/src/assets/img/add_questions_modal.png differ diff --git a/src/assets/img/already_satisfied.png b/src/assets/img/already_satisfied.png new file mode 100644 index 000000000..106529cb5 Binary files /dev/null and b/src/assets/img/already_satisfied.png differ diff --git a/src/assets/img/also_satisfies.png b/src/assets/img/also_satisfies.png new file mode 100644 index 000000000..619efb8f7 Binary files /dev/null and b/src/assets/img/also_satisfies.png differ diff --git a/src/assets/img/approve_the_control.png b/src/assets/img/approve_the_control.png new file mode 100644 index 000000000..6c17fc394 Binary files /dev/null and b/src/assets/img/approve_the_control.png differ diff --git a/src/assets/img/assigning_status.png b/src/assets/img/assigning_status.png index 9782123cd..1aa4959e8 100644 Binary files a/src/assets/img/assigning_status.png and b/src/assets/img/assigning_status.png differ diff --git a/src/assets/img/before_and_after.png b/src/assets/img/before_and_after.png index 70d0931ba..928ea7d73 100644 Binary files a/src/assets/img/before_and_after.png and b/src/assets/img/before_and_after.png differ diff --git a/src/assets/img/check_and_fix_updated.png b/src/assets/img/check_and_fix_updated.png index b332f3b1b..aa758a0e7 100644 Binary files a/src/assets/img/check_and_fix_updated.png and b/src/assets/img/check_and_fix_updated.png differ diff --git a/src/assets/img/component_metadata.png b/src/assets/img/component_metadata.png new file mode 100644 index 000000000..8435c1af4 Binary files /dev/null and b/src/assets/img/component_metadata.png differ diff --git a/src/assets/img/component_view.png b/src/assets/img/component_view.png index 4076ad099..bb766f9c2 100644 Binary files a/src/assets/img/component_view.png and b/src/assets/img/component_view.png differ diff --git a/src/assets/img/control_body.png b/src/assets/img/control_body.png index 596f6404f..26b86598d 100644 Binary files a/src/assets/img/control_body.png and b/src/assets/img/control_body.png differ diff --git a/src/assets/img/copying_existing_content.png b/src/assets/img/copying_existing_content.png index c2ee42a02..306d5280f 100644 Binary files a/src/assets/img/copying_existing_content.png and b/src/assets/img/copying_existing_content.png differ diff --git a/src/assets/img/create_component.png b/src/assets/img/create_component.png index 4ccae524d..627d9bebd 100644 Binary files a/src/assets/img/create_component.png and b/src/assets/img/create_component.png differ diff --git a/src/assets/img/created_component.png b/src/assets/img/created_component.png index ebaefd4bb..e10ec3766 100644 Binary files a/src/assets/img/created_component.png and b/src/assets/img/created_component.png differ diff --git a/src/assets/img/describe_block.png b/src/assets/img/describe_block.png index 142d151b3..a752c36d6 100644 Binary files a/src/assets/img/describe_block.png and b/src/assets/img/describe_block.png differ diff --git a/src/assets/img/diff.png b/src/assets/img/diff.png index 6425b08b3..a4fa23ba7 100644 Binary files a/src/assets/img/diff.png and b/src/assets/img/diff.png differ diff --git a/src/assets/img/duplicate.png b/src/assets/img/duplicate.png index 4eb9cddc4..b05447b99 100644 Binary files a/src/assets/img/duplicate.png and b/src/assets/img/duplicate.png differ diff --git a/src/assets/img/editing_duplicate.png b/src/assets/img/editing_duplicate.png index bd47cc640..36fa17847 100644 Binary files a/src/assets/img/editing_duplicate.png and b/src/assets/img/editing_duplicate.png differ diff --git a/src/assets/img/export_buttons.png b/src/assets/img/export_buttons.png index 4cbc86787..47ab7f3f3 100644 Binary files a/src/assets/img/export_buttons.png and b/src/assets/img/export_buttons.png differ diff --git a/src/assets/img/filling_out_request_for_review.png b/src/assets/img/filling_out_request_for_review.png index ae1c24080..394285804 100644 Binary files a/src/assets/img/filling_out_request_for_review.png and b/src/assets/img/filling_out_request_for_review.png differ diff --git a/src/assets/img/inherently_met_control.png b/src/assets/img/inherently_met_control.png index 461de4912..537a37907 100644 Binary files a/src/assets/img/inherently_met_control.png and b/src/assets/img/inherently_met_control.png differ diff --git a/src/assets/img/inherently_met_control_picking_status.png b/src/assets/img/inherently_met_control_picking_status.png index 193da7600..9a8f6b989 100644 Binary files a/src/assets/img/inherently_met_control_picking_status.png and b/src/assets/img/inherently_met_control_picking_status.png differ diff --git a/src/assets/img/inspec_full.png b/src/assets/img/inspec_full.png index 167a29323..6ceeaeb30 100644 Binary files a/src/assets/img/inspec_full.png and b/src/assets/img/inspec_full.png differ diff --git a/src/assets/img/justification.png b/src/assets/img/justification.png index 222332885..d045bda59 100644 Binary files a/src/assets/img/justification.png and b/src/assets/img/justification.png differ diff --git a/src/assets/img/many_reqs.png b/src/assets/img/many_reqs.png new file mode 100644 index 000000000..adb2ba52e Binary files /dev/null and b/src/assets/img/many_reqs.png differ diff --git a/src/assets/img/members_view.png b/src/assets/img/members_view.png new file mode 100644 index 000000000..95258ea06 Binary files /dev/null and b/src/assets/img/members_view.png differ diff --git a/src/assets/img/open_component.png b/src/assets/img/open_component.png index 172924d6d..b6f984167 100644 Binary files a/src/assets/img/open_component.png and b/src/assets/img/open_component.png differ diff --git a/src/assets/img/r_and_c.png b/src/assets/img/r_and_c.png index 8a2fdcc05..0d321c186 100644 Binary files a/src/assets/img/r_and_c.png and b/src/assets/img/r_and_c.png differ diff --git a/src/assets/img/related_rules.png b/src/assets/img/related_rules.png index 5ade82106..1e1f6346d 100644 Binary files a/src/assets/img/related_rules.png and b/src/assets/img/related_rules.png differ diff --git a/src/assets/img/review_status.png b/src/assets/img/review_status.png index 59cae2d7c..6bc732319 100644 Binary files a/src/assets/img/review_status.png and b/src/assets/img/review_status.png differ diff --git a/src/assets/img/review_status_filter.png b/src/assets/img/review_status_filter.png index 2cd4d7278..76cf1523c 100644 Binary files a/src/assets/img/review_status_filter.png and b/src/assets/img/review_status_filter.png differ diff --git a/src/assets/img/revision_history.png b/src/assets/img/revision_history.png index f6efa538f..8ee95c391 100644 Binary files a/src/assets/img/revision_history.png and b/src/assets/img/revision_history.png differ diff --git a/src/assets/img/satisfies.png b/src/assets/img/satisfies.png new file mode 100644 index 000000000..c97b8b20c Binary files /dev/null and b/src/assets/img/satisfies.png differ diff --git a/src/assets/img/saving_requirement.png b/src/assets/img/saving_requirement.png index e52bd02f7..719fc44bb 100644 Binary files a/src/assets/img/saving_requirement.png and b/src/assets/img/saving_requirement.png differ diff --git a/src/assets/img/selected_control.png b/src/assets/img/selected_control.png index 30d7b237a..0078ac41d 100644 Binary files a/src/assets/img/selected_control.png and b/src/assets/img/selected_control.png differ diff --git a/src/assets/img/selecting_also_satisfies.png b/src/assets/img/selecting_also_satisfies.png new file mode 100644 index 000000000..276504624 Binary files /dev/null and b/src/assets/img/selecting_also_satisfies.png differ diff --git a/src/assets/img/selecting_controls.png b/src/assets/img/selecting_controls.png index b473fc31a..78571e888 100644 Binary files a/src/assets/img/selecting_controls.png and b/src/assets/img/selecting_controls.png differ diff --git a/src/assets/img/srgcontents.png b/src/assets/img/srgcontents.png index 708f83f1a..98b6546d7 100644 Binary files a/src/assets/img/srgcontents.png and b/src/assets/img/srgcontents.png differ diff --git a/src/assets/img/start_new_project_filled_out.png b/src/assets/img/start_new_project_filled_out.png index 284b45da3..8175aedee 100644 Binary files a/src/assets/img/start_new_project_filled_out.png and b/src/assets/img/start_new_project_filled_out.png differ diff --git a/src/assets/img/stig_search.png b/src/assets/img/stig_search.png new file mode 100644 index 000000000..704c4aa3f Binary files /dev/null and b/src/assets/img/stig_search.png differ diff --git a/src/assets/img/stig_view.png b/src/assets/img/stig_view.png new file mode 100644 index 000000000..1c5506275 Binary files /dev/null and b/src/assets/img/stig_view.png differ diff --git a/src/assets/img/updated_project_view.png b/src/assets/img/updated_project_view.png index 0cc47138d..02c1a216f 100644 Binary files a/src/assets/img/updated_project_view.png and b/src/assets/img/updated_project_view.png differ diff --git a/src/assets/img/view_related_rules.png b/src/assets/img/view_related_rules.png index e66af2e81..62358581e 100644 Binary files a/src/assets/img/view_related_rules.png and b/src/assets/img/view_related_rules.png differ diff --git a/src/courses/guidance/02.md b/src/courses/guidance/02.md index 25b7d1b05..7dce64b7b 100644 --- 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 index e643e827c..839ed1ef4 100644 --- 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 index 8dfe41d66..1e8bd99b8 100644 --- 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,7 +34,7 @@ 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) @@ -42,13 +42,13 @@ Click it and begin to fill out the details for our project. You can make the Tit ![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 index e5b8415a0..98ba4144a 100644 --- 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. \ No newline at end of file +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. +::: diff --git a/src/courses/guidance/07.md b/src/courses/guidance/07.md index 2fc8c0be1..1d4c12d62 100644 --- a/src/courses/guidance/07.md +++ b/src/courses/guidance/07.md @@ -8,11 +8,13 @@ headerDepth: 3 ## 7.1 Editing Components -For your Component, you'll need to decide what requirements are appliable to your specific Component (hint: not all of them will be). Of the applicable requirements, you'll need to tailor them to give specific implementation guidance. +For your Component, you'll need to decide what requirements are applicable to your specific piece of software (hint: not all of them will be). Of the applicable requirements, you'll need to tailor them to give specific implementation guidance. + +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) @@ -20,9 +22,11 @@ For your Component, you'll need to decide what requirements are appliable to you You may note that Vulcan refers to the STIG requirements as "controls." A **security control** is an action taken by an organization *in order to meet a security requirement.* STIGs are technically comprised of a set of *requirements,* but each requirement's main focus is describing a control to meet that requirement (i.e. the Check and Fix content). + +Many organizations tend to conflate these terms. ::: -2. Now let's select a requirement. Let's start with RHEL-09-000003. (Normally, we'd start with number 1, but for this exercise we'll pick a simple requirement.) +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) @@ -31,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-000004-GPOS-00004) +- 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. @@ -48,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 @@ -76,7 +82,7 @@ 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 @@ -84,29 +90,32 @@ flowchart TB ``` ### 7.3.2 Our First Requirement Status -3. Let's pick a status for RHEL-09-000003. 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-000003](@/../../../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. @@ -115,9 +124,9 @@ Before we do that, let's investigate a the Status field a bit more. ### 7.3.3 Another Requirement Status -5. Let's skip ahead 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) +![RHEL-09-000044](@/../../../assets/img/inherently_met_control.png) Our title here is "The operating system must obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals." @@ -129,10 +138,10 @@ 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) +![RHEL-09-000044](@/../../../assets/img/inherently_met_control_picking_status.png) ::: Notice that this time, several of the fields in the Vulcan editing window changed. @@ -211,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.** @@ -246,4 +255,4 @@ Having the ability to granularly revert edits -- and even just track what change ::: [^Statuses]: Definitions from Table 4-1 in DISA's Vendor STIG Process Guide. See Resources. -[^VendorSTIGProcessGuide]: Sections 4.1.15 through 4.1.17 of the "Vendor STIG Process", Version 4 Release 1. \ No newline at end of file +[^VendorSTIGProcessGuide]: Sections 4.1.15 through 4.1.17 of the "Vendor STIG Process", Version 4 Release 1. See [Resources](../../resources/README.md). \ No newline at end of file diff --git a/src/courses/guidance/08.md b/src/courses/guidance/08.md index 09853f658..d74157f63 100644 --- a/src/courses/guidance/08.md +++ b/src/courses/guidance/08.md @@ -119,7 +119,7 @@ Remember that STIG writing is an open-book test. We encourage authors to go back Luckily, Vulcan has access to every STIG and SRG you have uploaded to the instance for cross-referencing. -1. Click on the RHEL-09-000003 requirement again and click on the "View Related Rules" button on the right-hand side. +Click on the RHEL-09-000004 requirement again and click on the "View Related Rules" button on the right-hand side. ![Related Rules Button](@/../../../assets/img/view_related_rules.png) @@ -129,26 +129,32 @@ You'll see a view of every requirement Vulcan can find in its content library th You can filter and search through this library for keywords if you like, or even restrict the results to only show content your team has written inside this Vulcan instance's Components. For now, though, we are likely interested only in the published STIGs. -2. Let's take a look at some of these RHEL7 STIG requirements. They seem promising. We can even copy them directly into the Check and Fix fields on our RHEL9 STIG requirement if we want to! Let's do that now. +Let's take a look at some of these RHEL8 STIG requirements. They seem promising. We can even copy them directly into the Check and Fix fields on our RHEL9 STIG requirement if we want to! Let's do that now. ![Copying Existing Content](@/../../../assets/img/copying_existing_content.png) ::: warning -The real, published RHEL9 STIG is uploaded to this Vulcan instance. For the purposes of this exercise, though, we will use an earlier version of RHEL. +The real, published RHEL9 STIG is uploaded to the Vulcan instance we use to teach these classes. If you use the View Related Content feature, Vulcan will show you the "real" answer! For the purposes of this exercise, though, we will use an earlier version of RHEL. ::: Great! Now we have a Check and Fix field that actually have content. Note also that this content is already following STIG syntax; the commands are very direct, and the line on what counts as a finding is clearly drawn. ![Updated Check and Fix Text](@/../../../assets/img/check_and_fix_updated.png) -3. Save the requirement. +Save the requirement. ::: warning Is It Always This Easy? Prior STIGs are always an excellent *starting point,* but new STIG content does require research and testing to ensure that guidance from the prior STIGs is still accurate for our current Component. ::: + +Note that the check text and the fix text that we have copied into our requirement show all the signs of good STIG writing form. They are very specific instructions -- the Check text tells the reader exactly what attribute to look for and in what file, and uses the key phrase _this is a finding_ to tell us explicitly what counts as a misconfiguration. The Fix text, meanwhile, tells us exactly which file to modify and exactly what content to add to a file. + ::: note The Original SRG content -If you scroll down in the requirement window, you can expand out the original SRG content that this STIG requirement was sourced from. This can be useful to reference if you want to make sure your Check and Fix are still addressing the SRG requirement. +If you scroll down in the requirement window, you can expand out the original SRG content from which this STIG requirement was sourced. This can be useful to reference if you want to make sure your Check and Fix are still addressing the SRG requirement. ![Original SRG content](@/../../../assets/img/srgcontents.png) ::: -[^VendorSTIGProcessGuide]: Sections 4.1.11 and 4.1.13 of the "Vendor STIG Process", Version 4 Release 1. \ No newline at end of file + +We have now completed the tailoring of this requirement from the SRG to the STIG level. Feel free to select a few more requirements from the list and conduct the tailoring process again. This might give you a better idea of what sorts of requirements you can run into when undergoing an SRG tailoring process. + +[^VendorSTIGProcessGuide]: Sections 4.1.11 and 4.1.13 of the "Vendor STIG Process", Version 4 Release 1. See [Resources](../../resources/README.md). \ No newline at end of file diff --git a/src/courses/guidance/09.md b/src/courses/guidance/09.md index 8ef9c477b..276349687 100644 --- a/src/courses/guidance/09.md +++ b/src/courses/guidance/09.md @@ -10,15 +10,13 @@ headerDepth: 3 Now that we have written up some Check and Fix text, it's time to use one of Vulcan's other features -- the InSpec code pane. -We've already used Vulcan to generate a document that has most of the metadata in place that we would need to properly label an automated validation test. Now we can go the last mile or so to a complete security test. - ### 9.1.1 The InSpec Control Body -1. Click on the InSpec Control Body tab in the requirement window. +Click on the InSpec Control Body tab in the requirement window. ![InSpec Control Body](@/../../../assets/img/control_body.png) -You'll see a code editing window directly in Vulcan. What we can do now is write in the test code we want to use for testing the check we just wrote. +You'll see a code editing window directly in Vulcan. At present there isn't much to see inside of it. We should fix that. ::: warning Wait, what if I have no idea how to write InSpec code?! Great news, we have an in-depth [training class](@/../../../courses/beginner/README.md) on how to do this ([two of them](@/../../../courses/advanced/README.md), actually). @@ -26,30 +24,15 @@ Great news, we have an in-depth [training class](@/../../../courses/beginner/REA But if you don't have the time for those, don't sweat it; we just want you to know that this is something you can do with Vulcan. ::: -2. For demonstration purposes, we'll copy in the code from the actual MITRE SAF RHEL7 STIG InSpec profile[^rhel7_profile]. +Let's add in a few lines of InSpec code. You can write your own, or borrow from the below. -That code is as follows: ``` ruby -audit_command = '/etc/passwd' - -if virtualization.system.eql?('docker') - impact 0.0 - describe 'Control not applicable - audit config must be done on the host' do - skip 'Control not applicable - audit config must be done on the host' - end -else - describe 'Command' do - it "#{audit_command} is audited properly" do - audit_rule = auditd.file(audit_command) - expect(audit_rule).to exist - expect(audit_rule.key).to cmp 'identity' - expect(audit_rule.permissions.flatten).to include('w', 'a') - end - end +describe parse_config_file('/etc/security/faillock.conf') do + its('fail_interval') { should cmp <= 900 } end ``` -3. Go ahead and copy that code block and paste it into the editing window. +Go ahead and copy that code block and paste it into the editing window. ![InSpec Control](@/../../../assets/img/describe_block.png) @@ -57,9 +40,9 @@ end If you have taken the SAF User class, you have used `inspec exec` to run code that looks like the above against a target system. ::: -4. Save the requirement. +Save the requirement. -5. Now check the "InSpec Control (Read-Only)" tab. It has used the contents of the other two tabs to assemble a completed InSpec control from your requirement, including the complete context of your STIG control as metadata tags in the test. +Now check the "InSpec Control (Read-Only)" tab. It has used the contents of the other two tabs to assemble a completed InSpec control from your requirement, including the complete context of your STIG control as metadata tags in the test. ![InSpec Control](@/../../../assets/img/inspec_full.png) @@ -75,10 +58,12 @@ You can think of this process as recording the pedigree of your tests into the c Furthermore, another reason we added the InSpec control editing window is because in most cases, you are writing security guidance because you want to write security validation code! Recall that the whole point of Vulcan is to help us define the security posture target so that we can automate reaching it! +If you've taken any other SAF classes, you may have noticed that a well-formed validation test's code will include tagging that aligns each individual test back to the baseline security document that required us to run it. The MITRE SAF tests in the validation library, in fact, include the exact text of the baseline document as tags and descriptions inside each test control. Therefore, Vulcan was built to automatically begin drafting an automated test as soon as we fill out our requirement details. + ::: note Do I need to use InSpec for my ATO process? DOD does not and will not require teams to use any one particlar security validation tool. MITRE SAF favors InSpec because it favors our use cases nicely, but there are many different security tools on the market, some of which are better suited to particular tasks. -::: -[^rhel7_profile]: See the full profile code [here](https://github.com/mitre/redhat-enterprise-linux-7-stig-baseline). Or see many more examples of InSpec profiles at https://saf.mitre.org/libs/validate. \ No newline at end of file +In all cases, any test tool is better than no test tool. +::: \ No newline at end of file diff --git a/src/courses/guidance/10.md b/src/courses/guidance/10.md index c02c83927..649aa75c4 100644 --- a/src/courses/guidance/10.md +++ b/src/courses/guidance/10.md @@ -1,48 +1,86 @@ --- order: 10 next: 11.md -title: 10. Peer Review +title: 10. Combining Requirements author: Will Dower headerDepth: 3 --- -## 10.1 Peer Review +## 10.1 Combining and Adding Requirements -With that, we've done two full requirements -- one "Applicable - Configurable" and one "Applicable - Inherently Meets." There are only 189 or so more requirements to go! +Remember how we said earlier that SRG requirements do not always have one-to-one equivalents in STIG documents? So far, we have noted that STIG requirements are distilled down from a more general SRG requirement. However, STIG authors often learn during the authorship process that a single STIG check will cover more than one SRG requirement, or that a single SRG requirement is better covered by several STIG checks. Therefore, in Vulcan, we sometimes need to indicate that one requirement in our security guidance covers multiple SRG controls, and sometimes we need to create a brand new requirement entirely. -In a real project of this size, you will be part of a team of authors each taking a subset of these requirements to complete. However, in a project of any size, you will also be peer reviewing the content your colleagues write to ensure quality standards are met. +## 10.2 Checking the Answer Key -## 10.2 Marking Requirements For Review +Let's use the RHEL9 STIG -- the _real_ RHEL9 STIG -- as an example. The RHEL9 STIG document is conveniently loaded into the training instance of Vulcan for us to examine. Check out the STIG option on the top navbar. -Let's flag our completed RHEL-09-000003 requirement as Ready for Review. +![Vulcan's STIG View](@/../../../assets/img/stig_view.png) -1. Click on the "Review Status" button at the top of the requirement window. +You can filter for RHEL and select the published RHEL9 STIG for easy viewing. (If you are running your own Vulcan locally, your instance admin user is able to upload the raw XCCDF document for the STIG on the same tab.) -![Review Status](@/../../../assets/img/review_status.png) +![Searching for STIGs](@/../../../assets/img/stig_search.png) -Note that we, as the primary author, are *not able to approve our own requirement;* the option is grayed out. All we can do is mark the requirement for review (or, as an admin, we can simply lock the control against further edits). +On the side of the page we see a search bar we can use to find individual components. We, the instructors, already know a good example for what we're talking about, so let's go ahead and search for the real STIG identifier `RHEL-09-211020`. -2. Let's add a comment and click the radio button to designate this requirement as Ready for Review. +![RHEL-09-211020](@/../../../assets/img/satisfies.png) -![Requesting Review](@/../../../assets/img/filling_out_request_for_review.png) +::: note Wait, why does the real STIG use different IDs for each requirement? +Recall that the IDs for our requirements were automatically generated sequentially from the SRG. We noted that a real, published STIG will have DISA use its own formula to apply STIG IDs. Our numbers and theirs will not match one-to-one and that is not a problem for the purposes of this class. +::: -3. Click "Submit Review" when done. +`RHEL-09-211020` states that "RHEL 9 must display the Standard Mandatory DOD Notice and Consent Banner before granting local or remote access to the system via a command line user logon." If you've ever logged into a government computer (or even most corporate ones) you've probably seen a disclaimer like this that warns you that the organization owns this computer and you shouldn't put anything on it that you don't want to show up in a log aggregator. -Note that the "Reviews & Comments" section on the right hand side of the Component view has updated. +The vulnerability discussion text states that this requirement _also_ satisfies several other SRG requirements. -![Review Comments](@/../../../assets/img/r_and_c.png) +On our search bar, we can also switch to searching by SRG ID. Let's search for one of the SRG IDs we have already implemented in this class -- recall that our very own `RHEL-09-000004` requirement maps back to the upstream `SRG-OS-000021-GPOS-00005`. Let's search for that ID and see what the actual STIG authors for RHEL9 did for this one. -Note also that the control is locked from further editing now. We can reverse this using the Review Status menu if we want. +![Many STIG requirements to one SRG requirement](@/../../../assets/img/many_reqs.png) -## 10.3 Approving Requirements +We can see a whole bunch of STIG requirements that cover this SRG control. If we take a look at each in turn we'll see that each of them is a unique check for a different system setting in RHEL9 that, when taken in aggregate, satisfy `SRG-OS-000021-GPOS-00005`. -If you want to conduct a peer review on another author's requirements, you can do so by filtering the requirements using the filter bar on the left side of the Component view. +::: note So how do I know which requirements are appropriate to combine or split apart? +There are no hard and fast rules for when we need to do this. It's up to you as the security guidance author to decide what makes a more logically organized document. -![Filter by Review Status](@/../../../assets/img/review_status_filter.png) +However, a good rule of thumb is that you should mark a STIG requirement as satisfying multiple SRG requirements when the STIG requirement's Check Text test would be necessary to run in order to satisfy a different SRG requirement. Similarly, if your Check Text procedure in one STIG requirement involves testing multiple discrete settings of a system, then you may wish to split them into multiple STIG requirements. +::: +::: warning Does that mean I can make just a few giant requirements in my security guidance to cover all the upstream SRG requirements? +No. We are _not_ saying that you should combine all of your requirements together without putting some thought into it. -If you enter a control that has been marked for review, and you are at least the role of Reviewer on the project, you will be able to: -- Approve: Lock the requirement for further editing; it is considered complete. -- Request Changes: unlock the requirement for further edits +Remember that people other than you and your team will need to understand the requirements you write. When in doubt, don't combine requirements. It's better to have requirements that are too specific than not enough. +::: -![Approving a Requirement](@/../../../assets/img/review_status_filter.png) +## 10.3 Combining Requirements +Now that we have poked around the real STIG for a while, let's discuss how to combine requirements in Vulcan. + +## 10.3.1 The 'Also Satisfies' Feature + +Head back to your Component and make sure you are in editing mode. Let's take a look at requirement `RHEL-09-000005`. + +![RHEL-09-000005](@/../../../assets/img/RHEL-09-000005.png) + +Looks familiar, right? This requirement is based off of the same SRG ID as the real STIG's banner text requirement. + +Next, look at requirement `RHEL-09-000006`. + +![RHEL-09-000006](@/../../../assets/img/RHEL-09-000006.png) + +This requirement also deals with the banner message. The only difference between this requirement and the previous one is that `RHEL-09-000005` is asking that the banner be displayed _whenever someone accesses the system_ and `RHEL-09-000006` asking that the banner is displayed _until the user takes some action on the system_. + +Both of these behaviors are in fact controlled by the same banner text file. In other words, we _cannot reasonably test requirement `RHEL-09-000005` without also testing requirement `RHEL-09-000006`_. This means that requirement `RHEL-09-000005` also satisfies `RHEL-09-000006`. Let's mark this in Vulcan. + +Ensure the component is in edit mode and set the Status to "Applicable - Configurable". In the top right of the editing window for requirement `RHEL-09-000005` you will see a button labeled 'Also Satisfies': + +![Also Satisfies](@/../../../assets/img/also_satisfies.png) + +Select it and let's pick `RHEL-09-000006` in the search bar. + +![Selecting the other satisfied requirement](@/../../../assets/img/selecting_also_satisfies.png) + +If we head over to view `RHEL-09-000006`, we see that it is not editable, because we indicated that another requirement already satisfies it. We also see a little indicator of this relationship next to each requirement in the list on the left-hand side. + +![Already Satisfied](@/../../../assets/img/already_satisfied.png) + +::: warning +The requirement _must_ have its status set to "Applicable - Configurable" for the "Also Satisfies" add button to appear. The feature does not make sense in the context of any other status. +::: \ No newline at end of file diff --git a/src/courses/guidance/11.md b/src/courses/guidance/11.md index d5af231a9..f70021b5e 100644 --- a/src/courses/guidance/11.md +++ b/src/courses/guidance/11.md @@ -1,106 +1,58 @@ --- order: 11 next: 12.md -title: 11. Exporting Your Content +title: 11. Peer Review author: Will Dower headerDepth: 3 --- -## 11.1 Exporting Your Content +## 11.1 Peer Review -At this point, we have tailored two requirements from the original SRG into STIG-ready content, and discussed how to peer review them. +With that, we've adjudicated two full requirements -- one "Applicable - Configurable" and one "Applicable - Inherently Meets." There are only 195 or so more requirements to go! -Let's discuss what we can do with our components after we finish the requirement writing and reviewing. +In a real project of this size, you will be part of a team of authors each taking a subset of these requirements to complete. However, in a project of any size, you will also be peer reviewing the content your colleagues write to ensure quality standards are met. Until a requirement has undergone peer review in Vulcan, it is not considered fully complete. Once peer review has been done for a requirement, that requirement will enter the locked state, and it will no longer be editable. -## 11.2 Exporting the Guidance Document +::: note Do I have to peer review to use Vulcan? +Technically, a project admin can circumvent peer review by locking requirements without going through the process we are about to describe. It is not best practice to have a single author be the only "pair of eyes" on a large batch of requirements. -We have a few ways of exporting the content from Vulcan once it is written. - -1. Use the "Projects" link in the Vulcan navbar to return to the projects list page. Then click on your RHEL9 project to return to your project view. - -![Updated Project](@/../../../assets/img/updated_project_view.png) - -Notice on the right-hand side that the overall project summary now reflects that we made edits. - -2. You'll see a number of buttons alongside the bottom of the Component we have been editing. - -![Export Buttons](@/../../../assets/img/export_buttons.png) - -From left to right, those buttons will: - -- Lock all Component controls from further editing -- Export the Component's InSpec code as a .zip of an InSpec profile -- Export the Component as a comma-separated values file (CSV) -- Release the Component -- note that this option is not enabled unless all controls have been locked from further editing -- Duplicate the Component -- this creates a copy of the Component within the same Project; useful for creating a new release of the same Component without having to change the original -- Remove the Component -- Careful with this one! -- Open the Component -- Takes us to the editing screen - -### 11.2.1 Notes on Releasing - -A component can only be released if every requirement is locked. Requirements are only locked from further editing when they have undergone peer review. Therefore, releasing a component should only happen when all authorship is complete. - -::: tip Importing a Released Component -Once a Component is released, it can be imported into a different Vulcan project as a building block. - -One of our purposes with Vulcan is to avoid duplicating effort wherever possible; if the guidannce is already written, we want to be able to access it! +We strongly suggest that you write requirements as part of a team and undergo at least a simple peer review workflow. It helps keep all authors on the same page, and you'd be surprised how many mistakes even a quick peer review can catch and how many discussions it will start. ::: -### 11.2.2 Notes on Exporting +## 11.2 Marking Requirements For Review -Unlike formal release, the Component does not need to be locked to be exported (in any format). You are not required to keep your editing workflow inside Vulcan (though we do, of course, recommend keeping your workflow inside Vulcan where you can). +Let's practice peer reviewing requirements and flag our completed RHEL-09-000004 requirement as Ready for Review. -::: note -This means, for example, that we can export our InSpec profile regularly to test our code against test systems throughout the authorship process. -::: - -## 11.3 Diff Viewer - -We have spent quite a bit of time discussing how to use Vulcan to make initial authorship easier. However, Vulcan also has features intended to make the maintenace of your guidance documentation easier. - -This is why we have a Duplicate Component button available on the Component card, for example. - -### 11.3.1 Creating a Different Component +Click on the "Review Status" button at the top of the requirement window. You will see the Review modal appear. -We will not be releasing the Component in this class because that would require us to at least have made a Status Determination for each requirement. We can, however, create a Duplicate of the component. Let's do that now. +![Review Status](@/../../../assets/img/review_status.png) -::: note Why are we duplicating the Component? -In a complex system with many software components, it may make sense to create multiple Components in one project, all of which have a shared source SRG. +Note that you, as the primary author, are *not able to approve your own requirement;* the option is grayed out. All we can do is mark the requirement for review (or, as an admin, we can simply lock the control against further edits -- ignore this option for now). -For this example, we are duplicating the Component to mimic the release process. -::: - -3. Click the "Duplicate the Component" button on your Component for RHEL9. You will see a pop-up that is similar to the one you saw when creating the first Component from an SRG. - -![Duplicating a Component](@/../../../assets/img/duplicate.png) +Let's add a comment and click the radio button to designate this requirement as Ready for Review. -This time, we want to mark this Component as Version 1, Release 2. +![Requesting Review](@/../../../assets/img/filling_out_request_for_review.png) -4. Since we have created a new Component, we should change something inside it. +Click "Submit Review" when done. -Let's open up the component and edit another one of the controls. Any will do. +Note that the "Reviews & Comments" section on the right hand side of the Component view has updated. -![Editig the Duplicate](@/../../../assets/img/editing_duplicate.png) +![Review Comments](@/../../../assets/img/r_and_c.png) -5. Save the edit, just like you would in the first release. +Note also that the control is locked from further editing now. We can reverse this using the Review Status menu if we want by removing the review request, which will unlock the requirement for editing. -6. Go back to the Project page for RHEL9 and click the Diff Viewer tab. You'll get a menu asking you which two Components you want to compare. +## 11.3 Approving Requirements -![Diff Viewer](@/../../../assets/img/diff_empty.png) +If you want to conduct a peer review on another author's requirements, you can do so by filtering the requirements using the filter bar on the left side of the Component view. -7. Let's pick our two different releases of our RHEL9 component. We get a side-by side comparison view of our components, highlighting changes. +![Filter by Review Status](@/../../../assets/img/review_status_filter.png) -![Diff Viewer - Comparison](@/../../../assets/img/diff.png) - -::: note -Duplicating a Component automatically generates empty InSpec stubs inside the new component, which is why the Diff viewer believes that every requirement has a change. -::: -::: tip How do I use this? -The Diff Viewer enables you to do several things. +If you enter a control that has been marked for review, and you are at least the role of Reviewer on the project, you will be able to: +- Approve: Lock the requirement for further editing; it is considered complete. +- Request Changes: unlock the requirement for further edits -For one, you can compare releases to tell at a glance what has changed in a piece of guidance, which traditionally would require tracking everything in a changelog manually. +![Approving a Requirement](@/../../../assets/img/approve_the_control.png) -For another, we can easily compare the Components we make with published STIGs. +::: tip +Remember earlier when we added more members to our project? If you are taking the SAF Guidance class as part of a group, ask another class attendee to review your requirement, and you can review theirs. ::: -At this point, we have gone over most of the processes you would use in Vulcan to develop your own security guidance content. To close us off, let's review the process for foally publishing a STIG. \ No newline at end of file diff --git a/src/courses/guidance/12.md b/src/courses/guidance/12.md index d272ecf05..96c7b22ad 100644 --- a/src/courses/guidance/12.md +++ b/src/courses/guidance/12.md @@ -1,74 +1,93 @@ --- order: 12 next: 13.md -title: 12. Publishing a STIG +title: 12. Exporting Your Content author: Will Dower headerDepth: 3 --- -## 12.1 Notes on Formally Publishing a STIG +## 12.1 Exporting Your Content -![The STIG Process](../../assets/img/VendorSTIGProcess.png) +At this point, we have tailored two requirements from the original SRG into STIG-ready content, marked one as also satisfying another requirement, and peer reviewed them. Let's imagine that our team has completed the process of tailoring each SRG requirement into a STIG requirment, and that each requirement has been peer reviewed. Perhaps we have even already created some automation for these requirements. In other words, we have a complete security guidance document! -Most of this section is informed by DISA's own published guidance for the Vendor STIG Process, as well as the experiences of external teams and Vulcan stakeholders who have undergone the STIG creation process. +Let's discuss what we can do with our components after we finish the requirement writing and reviewing. -We recommend that you review the official Vendor STIG Process guide (see Resources for a copy) if you want to undergo the process. +## 12.2 Exporting the Guidance Document -::: tip Using Vulcan for Aritifact Management -DISA will require you to provide your draft content for review in Excel format. +We have a few ways of exporting the content from Vulcan once it is written. -That is to say, DISA's process is completely separate to Vulcan, and they will not need access to it. +Use the "Projects" link in the Vulcan navbar to return to the projects list page. Then click on your RHEL9 project to return to your project view. -Luckily, Vulcan can both export STIG-ready content to Excel format for DISA to ingest, and load reviewed content from DISA as a separate Component for easy comparison. -::: +![Updated Project](@/../../../assets/img/updated_project_view.png) + +On the right-hand side, the overall project summary now reflects that we made edits. You'll see a number of buttons alongside the bottom of the Component we have been editing. + +![Export Buttons](@/../../../assets/img/export_buttons.png) + +From left to right, those buttons will: + +- Lock all Component controls from further editing +- Export the Component's InSpec code as an archive of an InSpec profile +- Export the Component as a comma-separated values file (CSV) +- Release the Component -- note that this option is not enabled unless all controls have been locked from further editing +- Duplicate the Component -- this creates a copy of the Component within the same Project; useful for creating a new release of the same Component without having to change the original +- Remove the Component -- Careful with this one! +- Open the Component -- Takes us to the editing screen -## 12.2 Starting the Process +### 12.2.1 Notes on Releasing -First and foremost - reach out early! +A component can only be released if every requirement is locked. Requirements are only locked from further editing when they have undergone peer review, or when someone with administrator permissions locks a requirement regardless of review status. Note that even admins cannot lock a requirement unless it at least has a status determination (i.e. it is set to a status other than "Not Yet Determined," so we cannot lock our RHEL9 component just yet). Therefore, releasing a component should only happen when all authorship is complete. -DISA created the Vendor STIG Process to ensure that the content produced by the vendor community is up to DOD standard. As such, DISA prefers to meet with the STIG-ready content team before the content is written to discuss the characteristics of the software component the team is trying to write guidance for. +::: tip Importing a Released Component +Once a Component is released, it can be imported into a different Vulcan project as a building block. -DISA will also provide guidance on which SRG (or set of SRGs) should be selected as a foundation. +One of our purposes with Vulcan is to avoid duplicating effort wherever possible; if the guidance is already written, we want to be able to access it! +::: + +### 12.2.2 Notes on Exporting + +Unlike a formal release, the Component does not need to be locked to be exported (in any format). You are not required to keep your editing workflow inside Vulcan (though we do, of course, recommend keeping your workflow inside Vulcan where you can). -::: note Do I need to be the actual vendor to publish my content? -Not necessarily. DISA certainly expects that most people who look to formally publish STIG content will be the vendor that created a particular software component, but this is not required. +::: note +This means, for example, that we can export our InSpec profile regularly to test our code against test systems throughout the authorship process. -If you expect that the content you have created for a component for one project would be: - a) useful to the wider security community, or - b) useful to you personally on a later project -then reach out to DISA to formally publish it. +We can also export the InSpec profile for a Component even if we haven't written a single line of InSpec code for it. Recall that Vulcan can automatically use our security documentation to create metadata for automated tests. Exporting the profile will give you a "skeleton" profile that has files for each requirement with the metadata tags applied correctly; this alone can be a huge time saver! ::: -### 12.2.1 Writing Style +## 12.3 Diff Viewer -Remember that STIGs need to be very precise about the language used in their requirements. See the discussions in [Section 8](@/../08.md) of this class for details on the correct syntax and writing style notes for the Check and Fix fields. +We have spent quite a bit of time discussing how to use Vulcan to make initial authorship easier. However, Vulcan also has features intended to make the maintenace of your guidance documentation easier. -## 12.3 Stages of STIG Development +This is why we have a Duplicate Component button available on the Component card, for example. -DISA's documentation on the STIG process[^VendorSTIGProcessGuide] breaks it down into four development stages after the initial SRG selection, punctuated by frequent updates to and review by the agency. After the external author team finishes STIG development, there are a few more internal reviews at DISA before the final decision is made to publish. +### 12.3.1 Creating a Different Component -### 12.3.1 Stage 1 STIG Development (The First Ten Requirements) +We will not be releasing the Component in this class because that would require us to at least have made a Status Determination for each requirement. We can, however, create a Duplicate of the component. Let's do that now. -The author team will first fill out a total of 10 of the requirements in the STIG document, where the 10 requirements are a mix of all statuses (Applicable – Configurable, Applicable – Inherently Meets, Applicable – Does Not Meet, and Not Applicable). +::: note Why are we duplicating the Component? +In a complex system with many software components, it may make sense to create multiple Components in one project, all of which have a shared source SRG. -### 12.3.2 Stage 2 STIG Development +For this example, we are duplicating the Component to mimic the release process. +::: -If this initial round of requirements are written satisfactorily, the author team can continue work on the STIG content for 30 days before the next work-in-progress review from DISA. The agency may give further feedback on areas to improve at this point before continuing. +Click the "Duplicate the Component" button on your Component for RHEL9. You will see a pop-up that is similar to the one you saw when creating the first Component from an SRG. -### 12.3.3 Stage 3 STIG Development +![Duplicating a Component](@/../../../assets/img/duplicate.png) -The author team can continue writing STIG content for another 30 days (a total of 60 days after the initial decision to proceed) before the next round of work-in-progress review from DISA. The agency may give further feedback on areas to improve at this point before continuing. +This time, we want to mark this Component as Version 1, Release 2, to represent the next release of STIG-ready content for the same software. Since we have created a new Component, we should change something inside it. Let's open up the component and edit another one of the controls. Any will do. -### 12.3.4 Stage 4 STIG Development +![Editing the Duplicate](@/../../../assets/img/editing_duplicate.png) -After another 30 days (90 days total from the initial decision to proceed) the author team should submit a completed initial draft of the STIG to DISA for a full validation of the content. +Save the edit, just like you would in the first release. Go back to the Project page and click the Diff Viewer tab. You'll get a menu asking you which two Components you want to compare. -### 12.3.5 STIG Validation +Let's pick our two different releases of our RHEL9 component (make sure you pick your own project's RHEL9 component if you are using the training class instance of Vulcan). We get a side-by side comparison view of our components, highlighting changes. -Once the full draft is submitted, DISA will validate the contents of the STIG Check and Fix instructions by implementing them against a test system (the author team, if they work for the vendor of a not-yet-released product, may need to work to ensure that DISA can access a test system). +![Diff Viewer - Comparison](@/../../../assets/img/diff.png) -### 12.3.6 Review and Approval +Duplicating a Component automatically generates empty InSpec stubs inside the new component, but a new-from-scratch Component does not automatically generate InSpec code. This is why the Diff viewer shows no InSpec code in the V1R1 version of the document, and why it believes that _every_ requirement has a change. Note also that we are actually comparing the InSpec code for each requirement so that we can take advantage of the style of comparison used by code editors. -At this point, DISA personnel write up a formal reports to the DISA Authorizing Offical and confirm one last time that the STIG conforms to the style guide. Content that passes this final review is now officially a STIG and can be published to the DOD Cyber Exchange. +::: tip How do I use this? +The Diff Viewer's main use is for comparing completed released components. You can compare releases to tell at a glance what has changed in a piece of guidance, which traditionally would require tracking everything in a changelog manually. +::: -[^VendorSTIGProcessGuide]: Section 3 of the "Vendor STIG Process", Version 4 Release 1. See Resources. \ No newline at end of file +At this point, we have gone over most of the processes you would use in Vulcan to develop your own security guidance content. To close, let's review the process for formally publishing a STIG. \ No newline at end of file diff --git a/src/courses/guidance/13.md b/src/courses/guidance/13.md index 584fa0875..3ceefd6cd 100644 --- a/src/courses/guidance/13.md +++ b/src/courses/guidance/13.md @@ -1,20 +1,74 @@ --- order: 13 -title: 13. Next Steps +next: 14.md +title: 13. Publishing a STIG author: Will Dower headerDepth: 3 --- -## 13.1 Next Steps +## 13.1 Notes on Formally Publishing a STIG -### 13.1.1 Take the Class Survey -Take our question [survey](https://forms.office.com/g/JPUWUVjXes) to give feedback to fuel class improvement. +![The STIG Process](../../assets/img/VendorSTIGProcess.png) -### 13.1.2 Take other SAF training like the Security Automation Developer Classes or the SAF User Class -This class is one of a set of security automation content offered by the MITRE SAF(c) team. If you found this content interesting and you want to learn more about more technical topics like writing complete InSpec profiles of your own, we encourage you to check out the [Beginner](../beginner/) and [Advanced](../advanced/) Security Automation Developer Class (shown in the table of contents on the left). If you have not taken the User Class and want to put the SAF in action, take a look at the [SAF User Class](../user/). +Most of this section is informed by DISA's own published guidance for the Vendor STIG Process, as well as the experiences of external teams and Vulcan stakeholders who have undergone the STIG creation process. -### 13.1.3 Check Out the Rest of MITRE SAF(c)'s Content -MITRE SAF(c) is a large collection of tools and techniques for security automation in addition to those discussed in this class. You can find utilities and libraries to support any step of the software development lifecycle by browsing our offerings at [saf.mitre.org](https://saf.mitre.org). Note that everything offered by MITRE SAF(c) is open-source and available to use free of charge. You can also reference all of the resources listed from the class on the [Resources Page](../../resources/README.md) +We recommend that you review the official Vendor STIG Process guide[^VendorSTIGProcessGuide] if you want to undergo the process. -### 13.1.4 Contact Us -The MITRE SAF(c) team can be contacted at [saf@groups.mitre.org](mailto:saf@groups.mitre.org). We support U.S. government sponsors in developing new tools for the Framework and in implementing the existing ones in DevSecOps pipelines. If you have a question about how you can use any of the content you saw in this class in your own environment, we'd be happy to help. +::: tip Using Vulcan for Aritifact Management +DISA will require you to provide your draft content for review in Excel format. + +That is to say, DISA's process is completely separate to Vulcan, and they will not need access to it. + +Luckily, Vulcan can both export STIG-ready content to Excel format for DISA to ingest, and load reviewed content from DISA as a separate Component for easy comparison. +::: + +## 13.2 Starting the Process + +First and foremost - reach out early! + +DISA created the Vendor STIG Process to ensure that the content produced by the vendor community is up to DOD standard. As such, DISA prefers to meet with the STIG-ready content team before the content is written to discuss the characteristics of the software component the team is trying to write guidance for. + +DISA will also provide guidance on which SRG (or set of SRGs) should be selected as a foundation. + +::: note Do I need to be the actual vendor to publish my content? +Not necessarily. DISA certainly expects that most people who look to formally publish STIG content will be the vendor that created a particular software component, but this is not required. + +If you expect that the content you have created for a component for one project would be: + a) useful to the wider security community, or + b) useful to you personally on a later project +then reach out to DISA to formally publish it. +::: + +### 13.2.1 Writing Style + +Remember that STIGs need to be very precise about the language used in their requirements. See the discussions in [Section 8](@/../08.md) of this class for details on the correct syntax and writing style notes for the Check and Fix fields. + +## 13.3 Stages of STIG Development + +DISA's documentation on the STIG process[^VendorSTIGProcessGuide] breaks it down into four development stages after the initial SRG selection, punctuated by frequent updates to and review by the agency. After the external author team finishes STIG development, there are a few more internal reviews at DISA before the final decision is made to publish. + +### 13.3.1 Stage 1 STIG Development (The First Ten Requirements) + +The author team will first fill out a total of 10 of the requirements in the STIG document, where the 10 requirements are a mix of all statuses (Applicable – Configurable, Applicable – Inherently Meets, Applicable – Does Not Meet, and Not Applicable). + +### 13.3.2 Stage 2 STIG Development + +If this initial round of requirements are written satisfactorily, the author team can continue work on the STIG content for 30 days before the next work-in-progress review from DISA. The agency may give further feedback on areas to improve at this point before continuing. + +### 13.3.3 Stage 3 STIG Development + +The author team can continue writing STIG content for another 30 days (a total of 60 days after the initial decision to proceed) before the next round of work-in-progress review from DISA. The agency may give further feedback on areas to improve at this point before continuing. + +### 13.3.4 Stage 4 STIG Development + +After another 30 days (90 days total from the initial decision to proceed) the author team should submit a completed initial draft of the STIG to DISA for a full validation of the content. + +### 13.3.5 STIG Validation + +Once the full draft is submitted, DISA will validate the contents of the STIG Check and Fix instructions by implementing them against a test system (the author team, if they work for the vendor of a not-yet-released product, may need to work to ensure that DISA can access a test system). + +### 13.3.6 Review and Approval + +At this point, DISA personnel write up a formal reports to the DISA Authorizing Offical and confirm one last time that the STIG conforms to the style guide. Content that passes this final review is now officially a STIG and can be published to the [DOD Cyber Exchange](https://public.cyber.mil). + +[^VendorSTIGProcessGuide]: See [Resources](../../resources/README.md) for each topic in this section. \ No newline at end of file diff --git a/src/courses/guidance/14.md b/src/courses/guidance/14.md new file mode 100644 index 000000000..f3f095132 --- /dev/null +++ b/src/courses/guidance/14.md @@ -0,0 +1,20 @@ +--- +order: 14 +title: 14. Next Steps +author: Will Dower +headerDepth: 3 +--- + +## 14.1 Next Steps + +### 14.1.1 Take the Class Survey +Take our question [survey](https://forms.office.com/g/JPUWUVjXes) to give feedback to fuel class improvement. + +### 14.1.2 Take other SAF training like the Security Automation Developer Classes or the SAF User Class +This class is one of a set of security automation content offered by the MITRE SAF(c) team. If you found this content interesting and you want to learn more about more technical topics like writing complete InSpec profiles of your own, we encourage you to check out the [Beginner](../beginner/) and [Advanced](../advanced/) Security Automation Developer Class (shown in the table of contents on the left). If you have not taken the User Class and want to put the SAF in action, take a look at the [SAF User Class](../user/). + +### 14.1.3 Check Out the Rest of MITRE SAF(c)'s Content +MITRE SAF(c) is a large collection of tools and techniques for security automation in addition to those discussed in this class. You can find utilities and libraries to support any step of the software development lifecycle by browsing our offerings at [saf.mitre.org](https://saf.mitre.org). Note that everything offered by MITRE SAF(c) is open-source and available to use free of charge. You can also reference all of the resources listed from the class on the [Resources Page](../../resources/README.md) + +### 14.1.4 Contact Us +The MITRE SAF(c) team can be contacted at [saf@groups.mitre.org](mailto:saf@groups.mitre.org). We support U.S. government sponsors in developing new tools for the Framework and in implementing the existing ones in DevSecOps pipelines. If you have a question about how you can use any of the content you saw in this class in your own environment, we'd be happy to help. diff --git a/src/resources/02.md b/src/resources/02.md index 4885c0853..bcf7a64e3 100644 --- a/src/resources/02.md +++ b/src/resources/02.md @@ -1,12 +1,71 @@ --- index: true icon: page -title: Codespaces Resources -author: Emily Rodriguez +title: Training Lab Environments +author: Will Dower headerDepth: 3 --- -## Using Codespaces on GitHub for the Development Lab +# Using Codespaces for a Lab Environment + +You can follow along with each exercise given in these training classes by creating a GitHub Codespace from one of the MITRE SAF team's GitHub repositories. + +## What is GitHub Codespaces? + +[Codespaces](https://github.com/features/codespaces) is GitHub's built-in cloud-based development environment service. Creating a Codespace creates a new virtual machine in GitHub's cloud that is prepopulated with that repository's code. The user can then access a Virtual Studio window in their browser that points to this virtual machine. + +Overall, Codespaces allow for a user to make a few clicks on a repository's page and get a simple way to view and edit code, with no local dependencies required, since all the compute is happening in GitHub's cloud. + +## Why Codespaces? + +Using a Codespace means that we, the instructors, can know for certain what capabilities and tools are available to the students in their development environments. It allows us to standardize the lab experience. If you're formally taking our classes, we will be using this method to do the exercises. If you are taking the classes as a self-taught experience, we still recommend you create a Codespace and follow along. + +## How do I launch a Codespace for my lab environment? + +You'll need to create a fork of the [SAF training lab environment repository](https://github.com/mitre/saf-training-lab-environment). That repository contains all the install scripts and sample code you will need for the User, Beginner, and Advanced classes. + +### Instructions + +1. Log into github.com. If you do not have one already, you'll need to create a [GitHub account](https://github.com/signup). You need to do this so that you can create your "own" copy of the lab environment repository by forking it. +2. Access the [lab environment repository](https://github.com/mitre/saf-training-lab-environment). +3. Click the **fork** button: +![Forking a Repo](../assets/img/fork.png) +You'll be taken to the fork creation screen. Make sure you select the option to create the fork under your own profile, and not under an organizational account (if you are part of one). +![Fork Menu](../assets/img/creating_the_fork.png) +4. You'll be taken to the new webpage for your fork. Note that it is a complete copy of the original MITRE-managed codebase, but you are now the owner.\ +![My Fork](../assets/img/my_fork.png) +5. Click the Code button to bring up the Codespaces modal (by default you might see a set of options for downloading the code _locally_, make sure you select the "codespace" tab on this modal). +![Code Button](../assets/img/codespaces_button.png) +![Codespaces Modal](../assets/img/codespaces_modal.png) +6. Click the '+' to create a new codespace on the main branch of your forked repository. Note that if you leave your Codespace tab and return to this page, you will find a link to any existing virtual machines. +You can click on the ellipses next to the '+' if you want to customize the VM running the Codespace, but none of the class exercises require anything more than a very basic 2-core machine. +![Create a Codespace](../assets/img/create_codespace.png) +You will immediately be taken to a new tab, which will load a Virtual Studio Code window pointing to your shiny new VM running in GitHub's cloud. +![Your Editing Window](../assets/img/vs_code.png) +7. The MITRE SAF team has included a script in this repository (`build-lab.sh`) that you can use to easily install all the tools we will be using for the classes. It installs: +- InSpec +- Ansible +- The SAF CLI +- Helpful extensions for VSCode to handle Ruby code (and therefore InSpec code) +- A UBI8 and a NGINX container for practicing running Ansible and InSpec + +Once you have launched your codespace and your browser connects to it, run: + +```sh +source ./build-lab.sh +``` + +to execute the install script. + +You can always re-run this script if one of your dependencies runs into a problem (for instance, if your containers go down because the Codespace automatically turned off to save resources). You could also run `source ./test-lab.sh` to do a quick spot check that InSpec, the SAF CLI, and your containers are present. + +### Your Lab Environment After the Class + +We suggest you fork the lab environment because it gives you ownership over the code you will write for these classes. If you use the `git` utility to commit your changes inside the Codespace, you will be committing to your own fork, which you own. Feel free to play around with the tools we will introduce you to inside your codespace; it's yours. + +NOTE that Codespaces are eventually turned off by GitHub if you do not use them for long enough -- if you ever want to refer back to what you did in these classes, be sure to not just commit your code with `git commit`, but push it back to the upstream repository with `git push`! + +## FAQs ::: details 1. My Codespace is stopped! What do I do? This is normal. Your codespace will timeout after some period of inactivity. When you restart, it will be in the same state as you left it. Just click the "Restart codespace" button. diff --git a/src/resources/04.md b/src/resources/04.md deleted file mode 100644 index c71725669..000000000 --- a/src/resources/04.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -index: true -icon: page -title: Vulcan Resources -author: Will Dower -headerDepth: 3 ---- - -# Vulcan Resources - -## Docs -1. [Vulcan full documentation](https://saf.mitre.org/docs/vulcan-install) -2. [Vulcan GitHub](https://github.com/mitre/vulcan) -- Feel free to leave us a feature request! -3. [Vulcan Project roadmap](https://github.com/orgs/mitre/projects/7) - -## STIG resources -1. [Vendor STIG Process Guide](../assets/downloads/U_Vendor_STIG_Process_Guide_V4R1_20220815.pdf) -2. DISA's [Vendor STIG Intent Form](https://dl.dod.cyber.mil/wp-content/uploads/stigs/pdf/U_Vendor_STIG_Intent_Form.pdf). Used to formally start the Vendor STIG process. -3. VMWare's [STIG Program Overview](https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/docs/vmware-stig-program-overview.pdf). A good primer on terms and process for STIGs. - - - diff --git a/src/resources/05.md b/src/resources/05.md deleted file mode 100644 index 527e4f96a..000000000 --- a/src/resources/05.md +++ /dev/null @@ -1,69 +0,0 @@ ---- -index: true -icon: page -title: Lab Environments -author: Will Dower -headerDepth: 3 ---- - -# Using Codespaces for a Lab Environment - -You can follow along with each exercise given in these training classes by creating a GitHub Codespace from one of the MITRE SAF team's GitHub repositories. - -## What is GitHub Codespaces? - -[Codespaces](https://github.com/features/codespaces) is GitHub's built-in cloud-based development environment service. Creating a Codespace creates a new virtual machine in GitHub's cloud that is prepopulated with that repository's code. The user can then access a Virtual Studio window in their browser that points to this virtual machine. - -Overall, Codespaces allow for a user to make a few clicks on a repository's page and get a simple way to view and edit code, with no local dependencies required, since all the compute is happening in GitHub's cloud. - -## Why Codespaces? - -Using a Codespace means that we, the instructors, can know for certain what capabilities and tools are available to the students in their development environments. It allows us to standardize the lab experience. If you're formally taking our classes, we will be using this method to do the exercises. If you are taking the classes as a self-taught experience, we still recommend you create a Codespace and follow along. - -## How do I launch a Codespace for my lab environment? - -You'll need to create a fork of the [SAF training lab environment repository](https://github.com/mitre/saf-training-lab-environment). That repository contains all the install scripts and sample code you will need for the User, Beginner, and Advanced classes. - -### Instructions - -1. Log into github.com. If you do not have one already, you'll need to create a [GitHub account](https://github.com/signup). You need to do this so that you can create your "own" copy of the lab environment repository by forking it. -2. Access the [lab environment repository](https://github.com/mitre/saf-training-lab-environment). -3. Click the **fork** button: -![Forking a Repo](../assets/img/fork.png) -You'll be taken to the fork creation screen. Make sure you select the option to create the fork under your own profile, and not under an organizational account (if you are part of one). -![Fork Menu](../assets/img/creating_the_fork.png) -4. You'll be taken to the new webpage for your fork. Note that it is a complete copy of the original MITRE-managed codebase, but you are now the owner.\ -![My Fork](../assets/img/my_fork.png) -5. Click the Code button to bring up the Codespaces modal (by default you might see a set of options for downloading the code _locally_, make sure you select the "codespace" tab on this modal). -![Code Button](../assets/img/codespaces_button.png) -![Codespaces Modal](../assets/img/codespaces_modal.png) -6. Click the '+' to create a new codespace on the main branch of your forked repository. Note that if you leave your Codespace tab and return to this page, you will find a link to any existing virtual machines. -You can click on the ellipses next to the '+' if you want to customize the VM running the Codespace, but none of the class exercises require anything more than a very basic 2-core machine. -![Create a Codespace](../assets/img/create_codespace.png) -You will immediately be taken to a new tab, which will load a Virtual Studio Code window pointing to your shiny new VM running in GitHub's cloud. -![Your Editing Window](../assets/img/vs_code.png) -7. The MITRE SAF team has included a script in this repository (`build-lab.sh`) that you can use to easily install all the tools we will be using for the classes. It installs: -- InSpec -- Ansible -- The SAF CLI -- Helpful extensions for VSCode to handle Ruby code (and therefore InSpec code) -- A UBI8 and a NGINX container for practicing running Ansible and InSpec - -Once you have launched your codespace and your browser connects to it, run: - -```sh -source ./build-lab.sh -``` - -to execute the install script. - -You can always re-run this script if one of your dependencies runs into a problem (for instance, if your containers go down because the Codespace automatically turned off to save resources). You could also run `source ./test-lab.sh` to do a quick spot check that InSpec, the SAF CLI, and your containers are present. - - -### Your Lab Environment After the Class - -We suggest you fork the lab environment because it gives you ownership over the code you will write for these classes. If you use the `git` utility to commit your changes inside the Codespace, you will be committing to your own fork, which you own. Feel free to play around with the tools we will introduce you to inside your codespace; it's yours. - -NOTE that Codespaces are eventually turned off by GitHub if you do not use them for long enough -- if you ever want to refer back to what you did in these classes, be sure to not just commit your code with `git commit`, but push it back to the upstream repository with `git push`! - - diff --git a/src/resources/README.md b/src/resources/README.md index c95a09cc8..10918cb2a 100644 --- a/src/resources/README.md +++ b/src/resources/README.md @@ -23,7 +23,19 @@ headerDepth: 3 - [SAF CLI](https://github.com/mitre/saf) - [Heimdall Lite](https://mitre.github.io/heimdall-lite/#) - [Heimdall Lite Github Repo](https://github.com/mitre/heimdall-lite) -- [Heimdall Server (with backend database, compare and trending)](https://github.com/mitre/heimdall) +- [Heimdall Server (with backend database, compare and trending)](https://github.com/mitre/heimdall) + +## Vulcan Resources + +### Docs +1. [Vulcan full documentation](https://saf.mitre.org/docs/vulcan-install) +2. [Vulcan GitHub](https://github.com/mitre/vulcan) -- Feel free to leave us a feature request! +3. [Vulcan Project roadmap](https://github.com/orgs/mitre/projects/7) + +### STIG resources +1. [Vendor STIG Process Guide](../assets/downloads/U_Vendor_STIG_Process_Guide_V4R1_20220815.pdf) +2. DISA's [Vendor STIG Intent Form](https://dl.dod.cyber.mil/wp-content/uploads/stigs/pdf/U_Vendor_STIG_Intent_Form.pdf). Used to formally start the Vendor STIG process. +3. VMWare's [STIG Program Overview](https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/docs/vmware-stig-program-overview.pdf). A good primer on terms and process for STIGs. ## Code Background & Primers