Merge pull request #270 from mitre/dec24-guidance

Guidance course updates

src/courses/guidance/02.md

@@ -30,7 +30,7 @@ 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, consider the following requirement in the STIG for the Red Hat 9 operating system:
+Many organizations that use popular security guidance documents as their baselines have their own specific organizational security policies that 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.
@@ -46,7 +46,7 @@ You can check out the [Beginner Security Automation Developer Class](https://mit
 
 ## 2.2 Finding Security Guidance Documentation Baselines
 
-Commonly-used security guidance is often available on the open Internet.
+Commonly used security guidance is often available on the open Internet.
 
 - CIS publishes its popular [Benchmarks](https://www.cisecurity.org/cis-benchmarks) for free with registration (in PDF form, other formats require a subscription to CIS's SecureSuite)
 - DISA publishes all STIGs (and all the rest of its security documentation materials) for free on the [DOD Cyber Exchange](https://public.cyber.mil/stigs/downloads/) public web page.
@@ -76,4 +76,4 @@ Therefore, the Planning capability of the SAF -- dealing with the selection and
 
 ![SAF Plan Capability](../../assets/img/SAFPlan.png)
 
-The Plan capability comes first in the list because every other capability needs to refer back to it!
+The Plan capability comes first in the list because every other capability needs to refer back to it!

src/courses/guidance/05.md

@@ -8,7 +8,7 @@ headerDepth: 3
 
 ## 5.1 Using Vulcan
 
-Let's walk though the process for building STIG-ready content from the beginning using the Vulcan application. We will use our [demonstration instance of Vulcan](https://vulcan-br-training.herokuapp.com/) that the MITRE SAF team created for this training class (please note that this instance will be regularly reset for each training course).
+Let's walk though the process for building STIG-ready content from the beginning using the Vulcan application. We will use our [demonstration instance of Vulcan](https://mitre-vulcan-staging.herokuapp.com/) that the MITRE SAF team created for this training class (please note that this instance may be regularly reset for each training course).
 
 ### 5.1.1 Our Use Case
 
@@ -74,4 +74,4 @@ If you have any colleagues taking the class with you, you may want to add them a
 Reviewers are able to approve requirements written by other members. Depending on how your team operates, you may want to have many authors with one final reviewer role, or you may want to have every member be a reviewer. It's up to you.
 
 Only the Admin role can bypass the peer review process to lock (finalize) their own requirements. Try not to dole out the Admin role too often; it's best practice to force all requirements to undergo peer review.
-:::
+:::

src/courses/guidance/12.md

@@ -28,6 +28,7 @@ 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 an XCCDF XML file
 - 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
@@ -90,4 +91,4 @@ Duplicating a Component automatically generates empty InSpec stubs inside the ne
 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.
 :::
 
-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.
+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.

src/courses/guidance/README.md

@@ -1,8 +1,8 @@
 ---
 order: 1
 next: 02.md
-title: Security Guidance Developer Class
-shortTitle: Security Guidance Development
+title: 1. Security Guidance Developer Class
+shortTitle: 1. Security Guidance Development
 author: Emily Rodriguez
 headerDepth: 3
 ---
@@ -17,12 +17,12 @@ By the end of this class, you should be able to achieve all of the following obj
 -	Create tailored security guidance using Vulcan.
 -	Classify security requirements as Applicable - Configurable, Applicable - Inherently Meets, Applicable - Does Not Meet, Not Applicable, or Not Yet Determined for a given software component.
 -   Export security guidance as InSpec stubs to assist in automated security validation.
-- Understand how STIG-ready content can be formally peer reviewed by DISA and published to the security community
+- Understand how STIG-ready content can be formally peer-reviewed by DISA and published to the security community
 - Create guidance with Vulcan to support Authority To Operate (ATO) efforts
 
 ## 1.2 The Road to Security Automation
 
-As you can see from the picture below, the process for developing automated security tests starts with requirements documents like SRGs, STIGs or CIS Benchmark that are written in regular, human language and then implemented as code. We need that code to record test results in a standardized format so that we can easily export our security data somewhere people can use it to make decisions (like the Heimdall visualization app).
+As you can see from the picture below, the process for developing automated security tests starts with requirements documents like SRGs, STIGs, or CIS Benchmarks that are written in regular, human language and then implemented as code. We need that code to record test results in a standardized format so that we can easily export our security data somewhere people can use it to make decisions (like the Heimdall visualization app).
 
 This challenge is what the [MITRE Security Automation Framework](https://saf.mitre.org) or MITRE SAF was developed to simplify -- to make the journey from a Requirement Document to an automated test profile and back again a little easier to navigate.