diff --git a/src/courses/profile-dev-test/24.md b/src/courses/profile-dev-test/24.md index 60abdd1a6..55cf4a2c5 100644 --- a/src/courses/profile-dev-test/24.md +++ b/src/courses/profile-dev-test/24.md @@ -2,7 +2,6 @@ order: 24 next: 25.md title: 24. Tips, Tricks, and Troubleshooting -shortTitle: Tips & Troubleshooting author: Aaron Lippold --- diff --git a/src/courses/profile-dev-test/25.md b/src/courses/profile-dev-test/25.md new file mode 100644 index 000000000..d04297ed4 --- /dev/null +++ b/src/courses/profile-dev-test/25.md @@ -0,0 +1,30 @@ +--- +order: 25 +next: 26.md +title: 25. Background & Definitions +author: Aaron Lippold +--- + +## Background and Definitions + +### Background + +#### Evolution of STIGs and Security Benchmarks + +The Department of Defense (DOD) has continually updated its databases that track rules and Security Technical Implementation Guides (STIGs) that house those rules. + +Initially, the system was known as the Vulnerability Management System (VMS). + +In the STIGs, you might come across data elements that are remnants from these iterations. These include `Group Title` (gid or gtitle), `Vulnerability ID` (VulnID), `Rule ID` (rule_id), `STIG ID` (stig_id), and others. + +A significant change was the shift from using `STIG ID` to `Rule ID` in many security scanning tools. This change occurred because the Vulnerability Management System used the STIG_ID as the primary index for the requirements in each Benchmark in VMS. + +When DISA updated the Vendor STIG Processes and replaced the VMS, they decided to migrate the primary ID from the STIG ID to the Rule ID, tracking changes in the Rules as described above. + +Examples of tools that still use either fully or in part the 'STIG ID' instead of the 'Rule ID' as a primary index are: the DISA STIG Viewer, Nessus Audit Scans, and Open SCAP client. + +While these elements might seem confusing, understanding their historical context is essential. + +In our modern profiles, some data from the XCCDF Benchmarks still exist in the document but are not used or rendered in the modern InSpec Profiles. However, in some of the older profiles, you may see many of these data elements as `tags` in the profile. The intention was to ensure easy and lossless conversion between the XCCDF Benchmark and OHDF Profile. + +It was later realized that since the structure of these data elements was 'static', they could be easily reintroduced when converting back to an XCCDF Benchmark. Therefore, rendering them in the profile was deemed unnecessary. diff --git a/src/courses/profile-dev-test/26.md b/src/courses/profile-dev-test/26.md index 48ee12ecc..3cf3cca0f 100644 --- a/src/courses/profile-dev-test/26.md +++ b/src/courses/profile-dev-test/26.md @@ -1,30 +1,22 @@ --- order: 26 -next: 27.md -title: Background & Definitions +title: 26. Terms & Definitions author: Aaron Lippold --- -## Background and Definitions - -### Background - -#### Evolution of STIGs and Security Benchmarks - -The Department of Defense (DOD) has continually updated its databases that track rules and Security Technical Implementation Guides (STIGs) that house those rules. - -Initially, the system was known as the Vulnerability Management System (VMS). - -In the STIGs, you might come across data elements that are remnants from these iterations. These include `Group Title` (gid or gtitle), `Vulnerability ID` (VulnID), `Rule ID` (rule_id), `STIG ID` (stig_id), and others. - -A significant change was the shift from using `STIG ID` to `Rule ID` in many security scanning tools. This change occurred because the Vulnerability Management System used the STIG_ID as the primary index for the requirements in each Benchmark in VMS. - -However, when DISA updated the Vendor STIG Processes and replaced the VMS, they decided to migrate the primary ID from the STIG ID to the Rule ID, tracking changes in the Rules as described above. - -Examples of tools that still use either fully or in part the 'STIG ID' vs the 'Rule ID' as a primary index are: the DISA STIG Viewer, Nessus Audit Scans, and Open SCAP client. - -While these elements might seem confusing, understanding their historical context is essential. - -In our modern profiles, some data from the XCCDF Benchmarks still exist in the document but are not used or rendered in the modern InSpec Profiles. However, in some of the older profiles, you may see many of these data elements as `tags` in the profile. The intention was to ensure easy and lossless conversion between XCCDF Benchmark and HDF Profile. - -It was later realized that since the structure of these data elements was 'static', they could be easily reintroduced when converting back to an XCCDF Benchmark. Therefore, rendering them in the profile was deemed unnecessary. +## Terms & Definitions + +- **Baseline**: This refers to a set of relevant security controls, such as NIST 800-53 controls or Center for Internet Security Controls. These controls offer high-level security best practices, grouped into common areas of concern. +- **Benchmark**: This is a set of security controls tailored to a specific type of application or product. These controls are typically categorized into 'high', 'medium', and 'low' levels based on Confidentiality, Integrity, and Availability (C.I.A). +- **[Common Correlation Identifier](https://public.cyber.mil/stigs/cci/) (CCI)**: The Control Correlation Identifier (CCI) provides a standard identifier and description for each of the singular, actionable statements that comprise an IA control or IA best practice. For example: 'CCI-000366'. +- **Group Title (gtitle)**: This is essentially the SRG ID but is a holdover data value from the old Vulnerability Management System. For example: 'SRG-OS-000480-GPOS-00227'. +- **Major Version Update**: These are updates that occur when a software vendor releases a new major version of their product's STIG, e.g., Red Hat releasing version 9 of Red Hat Enterprise Linux or Microsoft releasing a new major version of Windows. +- **Patch Update**: These are regular updates that address missing corner cases of testing for one or more benchmark requirements, or improvements to the InSpec code for a requirement. These updates result in a new patch release of the benchmark, e.g., `v1.12.4` to `v1.12.5`. +- **Profile**: This is a set of tests representing a STIG or a CIS Benchmark. These tests automate the validation of a system against that STIG or CIS Benchmark. +- **Release Update**: These are updates that occur when the STIG Benchmark owner releases an updated version of the STIG, e.g., Red Hat Enterprise Linux V1R12 to V1R13. +- **Rule ID (rid)**: The Rule ID has two parts separated by the `r` in the string - ('SV-230221) and (r858734_rule)'. The first part remains unique within the major version of a Benchmark document, while the latter part of the string is updated each time the 'Rule' is updated 'release to release' of the Benchmark. For example: 'SV-230221r858734_rule'. +- **Security Requirements Guide (SRG)**: SRG documents provide generalized security guidance in XCCDF format that applies to a 'class' of software products such as 'web server', 'operating systems', 'application servers' or 'databases'. You can find an archive of these at the DISA STIG [Document Library](https://public.cyber.mil/stigs/downloads/). +- **Security Technical Implementation Guide (STIG)**: This is a set of specific technical actions required to establish a certain security posture for a software product. It is based on a desired Security Requirements Guide that applies to the product's software class and function, such as operating system, web server, database, etc. You can find an archive of these at the DISA STIG [Document Library](https://public.cyber.mil/stigs/downloads/). +- **SRG_ID**: This is the unique identifier of the SRG requirement. These indexes, like the STIG Rule IDs, also show their parent-child relationship. For example: 'SRG-OS-000480-GPOS-00227'. +- **STIG ID (stig_id)**: Many testing tools and testing results tools use this ID - vs the Rule ID - to display each of the individual results of a Benchmark validation run. For example: 'RHEL-08-010000'. Examples include: DISA STIG Viewer, Nessus Audit Scans and the Open SCAP client. +- **XCCDF Benchmark (XCCDF or XCCDF Benchmark)**: XCCDF (Extensible Configuration Checklist Description Format) is a standard developed by NIST and DOD to provide a machine-readable XML format for creating security guidance documents and security technical implementation guides. You can find an archive of these at the DISA STIG [Document Library](https://public.cyber.mil/stigs/downloads/). diff --git a/src/courses/profile-dev-test/27.md b/src/courses/profile-dev-test/27.md deleted file mode 100644 index 496c4d319..000000000 --- a/src/courses/profile-dev-test/27.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -order: 27 -title: Terms & Definitions -author: Aaron Lippold ---- - -## Terms & Definitions - -- **Baseline**: This refers to a set of relevant security controls, such as NIST 800-53 controls or Center for Internet Security Controls. These controls offer high-level security best practices, grouped into common areas of concern. -- **Benchmark**: This is a set of security controls tailored to a specific type of application or product. These controls are typically categorized into 'high', 'medium', and 'low' levels based on Confidentiality, Integrity, and Availability (C.I.A). -- **[Common Correlation Identifier](https://public.cyber.mil/stigs/cci/) (CCI)**: The Control Correlation Identifier (CCI) provides a standard identifier and description for each of the singular, actionable statements that comprise an IA control or IA best practice. For example: 'CCI-000366'. -- **Group Title (gtitle)**: This is essentially the SRG ID but is a holdover data value from the old Vulnerability Management System. For example: 'SRG-OS-000480-GPOS-00227'. -- **Major Version Update**: These are updates that occur when a software vendor releases a new major version of their product's STIG, e.g., RedHat releasing version 9 of Red Hat Enterprise Linux or Microsoft releasing a new major version of Windows. -- **Patch Update**: These are regular updates that address missing corner cases of testing for one or more benchmark requirements, or improvements to the InSpec code for a requirement. These updates result in a new patch release of the benchmark, e.g., `v1.12.4` to `v1.12.5`. -- **Profile**: This is a set of tests representing a STIG or a CIS Benchmark. These tests automate the validation of a system against that STIG or CIS Benchmark. -- **Release Update**: These are updates that occur when the STIG Benchmark owner releases an updated version of the STIG, e.g., Red Hat Enterprise Linux V1R12 to V1R13. -- **Rule ID (rid)**: The Rule ID has two parts separated by the `r` in the string - ('SV-230221) and (r858734_rule)'. The first part remains unique within the major version of a Benchmark document, while the latter part of the string is updated each time the 'Rule' is updated 'release to release' of the Benchmark. For example: 'SV-230221r858734_rule'. -- **Security Requirements Guide (SRG)**: SRG documents provide generalized security guidance in XCCDF format that applies to a 'class' of software products such as 'web server', 'operating systems', 'application servers' or 'databases'. You can find an archive of these at the DISA STIG [Document Library](https://public.cyber.mil/stigs/downloads/). -- **Security Technical Implementation Guide (STIG)**: This is a set of specific technical actions required to establish a certain security posture for a software product. It is based on a desired Security Requirements Guide that applies to the product's software class and function, such as operating system, web server, database, etc. You can find an archive of these at the DISA STIG [Document Library](https://public.cyber.mil/stigs/downloads/). -- **SRG_ID**: This is the unique identifier of the SRG requirement. These indexes, like the STIG Rule IDs, also show their parent-child relationship. For example: 'SRG-OS-000480-GPOS-00227'. -- **STIG ID (stig_id)**: Many testing tools and testing results tools use this ID - vs the Rule ID - to display each of the individual results of a Benchmark validation run. For example: 'RHEL-08-010000'. Examples include: DISA STIG Viewer, Nessus Audit Scans and the Open SCAP client. -- **XCCDF Benchmark (XCCDF or XCCDF Benchmark)**: XCCDF (Extensible Configuration Checklist Description Format) is a standard developed by NIST and DOD to provide a machine-readable XML format for creating security guidance documents and security technical implementation guides. You can find an archive of these at the DISA STIG [Document Library](https://public.cyber.mil/stigs/downloads/). diff --git a/src/courses/profile-dev-test/kitchen-workflow-dark.svg b/src/courses/profile-dev-test/kitchen-workflow-dark.svg deleted file mode 100644 index 7a552a96f..000000000 --- a/src/courses/profile-dev-test/kitchen-workflow-dark.svg +++ /dev/null @@ -1,481 +0,0 @@ -1
Setup
Setup
Checkout Repo
Checkout Repo
Install Tools
Install Tools
Setup Runner
Setup Runner
Configure
Configure
Setup Vanilla Instance
Setup Vanilla Instance
Setup Hardened Instance
Setup Hardened Instance
Run Test Suite
Run Test Suite
Run Tests on Vanilla
Run Tests on Vanilla
Run Tests on Hardened
Run Tests on Hardened
Record Results
Record Results
Save Tests in Pipeline
Save Tests in Pipeline
Upload Tests to Heimdall Server
Upload Tests to Heimdall Server
Validate Aginst Threshold
Validate Aginst Threshold
Validate the 'vanilla' threshold
Validate the 'vanilla' threshold
Validate the 'hardened' threshold
Validate the 'hardened' threshold
Pass/Fail the Run
Pass/Fail the Run
Threshold Met
Threshold Met1
Threshold Not Met
Threshold Not MetTest Kitchen Workflow - - - - - - - - - - - - 1 - - - - - - - - - - -
-
- Setup -
-
- - - - Setup - - - - - - - - - - - - - - - - - - -
-
- Checkout Repo -
-
- - - - Checkout Repo - - - - - - - - - - - - - - - - - - -
-
- Install Tools -
-
- - - - Install Tools - - - - - - - - - - - - - - - - - - -
-
- Setup Runner -
-
- - - - Setup Runner - - - - - - - - -
-
- Configure -
-
- - - - Configure - - - - - - - - - - - - - - - - - - -
-
- Setup Vanilla Instance -
-
- - - - Setup Vanilla Instance - - - - - - - - - - - - - - - - - - -
-
- Setup Hardened Instance -
-
- - - - Setup Hardened Instance - - - - - - - - -
-
- Run Test Suite -
-
- - - - Run Test Suite - - - - - - - - - - - - - - - - - - -
-
- Run Tests on Vanilla -
-
- - - - Run Tests on Vanilla - - - - - - - - - - - - - - - - - - -
-
- Run Tests on Hardened -
-
- - - - Run Tests on Hardened - - - - - - - - -
-
- Record Results -
-
- - - - Record Results - - - - - - - - - - - - - - - - - - -
-
- Save Tests in Pipeline -
-
- - - - Save Tests in Pipeline - - - - - - - - - - - - - - - - - - -
-
- Upload Tests to Heimdall Server -
-
- - - - Upload Tests to Heimdall Server - - - - - - - - -
-
- Validate Aginst Threshold -
-
- - - - Validate Aginst Threshold - - - - - - - - - - - - - - - - - - -
-
- Validate the 'vanilla' threshold -
-
- - - - Validate the 'vanilla' threshold - - - - - - - - - - - - - - - - - - -
-
- Validate the 'hardened' threshold -
-
- - - - Validate the 'hardened' threshold - - - - - - - - -
-
- Pass/Fail the Run -
-
- - - - Pass/Fail the Run - - - - - - - - - - - - - - - - - - -
-
- Threshold Met -
-
- - - - Threshold Met - - - - - - - - - - - - - - - - 1 - - - - -
-
- Threshold Not Met -
-
- - - - Threshold Not Met - - - - - - Test Kitchen Workflow - - - \ No newline at end of file