Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User Course - December Training Updates #252

Closed
wants to merge 8 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions src/courses/user/03.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ The main pillars are
- Plan
- Harden
- Validate
- Normailze
- Normalize
- Visualize

The SAF helps teams plan what guidance will help them keep their software secure. It also provide libraries and tools for automatically hardening and validating software based on that guidance, normalize other security data, and visualize all the information to properly inform teams of risk and vulnerabilities.
Expand All @@ -23,7 +23,7 @@ The SAF helps teams plan what guidance will help them keep their software secure
::: details 2. Is SAF a tool? Why or why not?
Nope!

SAF, the Security Automation Framework, is a Framework and uses a COLLECTION of tools, techniques, applications, and libraries to streamline security automation. Since teams operate in different environments with different components, not everyone's security journey will look the same.
SAF, the Security Automation Framework, is a Framework that uses a COLLECTION of tools, techniques, applications, and libraries to streamline security automation. Since teams operate in different environments with different components, not everyone's security journey will look the same.


Some notable tools within the Security Automation Framework are Vulcan, the SAF CLI, and Heimdall.
Expand Down
16 changes: 10 additions & 6 deletions src/courses/user/04.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,25 +7,29 @@ headerDepth: 3
---

## 4. Start with Planning
The SAF's main pillars are Plan, Harden, Validate, Normalize, and Visualize. First, it is necessary to plan what components will be in your system and identify the security guidance available for those components.
The SAF's main pillars are Plan, Harden, Validate, Normalize, and Visualize. First, it is necessary to plan which components are/will be in your system and identify the security guidance available for those components.

![The Plan Capability](../../assets/img/SAF_Capabilities_Plan.png)

### 4.1 Identify your stack of components for the system
Your software system is composed of multiple components. i.e., Cloud Services, Virtualization Platforms, Operating Systems, Databases, Application Logic, and Web Servers.

The first step of any assessment is identifying the components for the system you are assessing.
The first step of any assessment is identifying the components of the system you are assessing.
<!-- [[Graphic of Stack with Redhat 7, NGINX]] -->

### 4.2 What is the guidance?
There could be Security Technical Implementation Guides (STIGs), Security Requirements Guides (SRGs), Center for Internet Security (CIS) Benchmarks, or vendor guidance written for the components in your software stack. Being aware of these can help inform which profile to use. Additionally, note here any specific requirements for your organization that might differ from the specific published guidance. This will inform how to tailor the profiles later on.
There could be Security Technical Implementation Guides (STIGs), Security Requirements Guides (SRGs), Center for Internet Security (CIS) Benchmarks, or vendor guidance written for the components in your software stack. Being aware of these can help inform which profile to use.

::: tip Note
Outline any specific requirements for your organization that might differ from the specific published guidance. This will inform how to tailor the profiles later on.
:::

### 4.3. Content libraries for software components

As you saw in the previous section's [SAF Site scavenger hunt](./03), the SAF website hosts links, informaiton, and tools to ease the security process. To get a better idea of what may be in your software stack and what kind of content is available for automated testing, you can peruse the SAF's hardening and validation content libraries when you are making a plan.
As you saw in the previous section's [SAF Site scavenger hunt](./03), the SAF website hosts links, information, and tools to ease the security process. To get a better idea of what may be in your software stack and what kind of content is available for automated testing, you can peruse the SAF's hardening and validation content libraries when you are making a plan.

::: details Go to saf.mitre.org
Go to the [SAF site](saf.mitre.org) to peruse the hardening and validation libraries. As the security community develops more automation content, we update this site as a landing page for all of the content. The site will look like this:
Go to the [SAF site](https://saf.mitre.org) to peruse the hardening and validation libraries. As the security community develops more automation content, we update this site as a landing page for all of the content. The site will look like this:
![The SAF Homepage](../../assets/img/SAF_Home.png)
:::

Expand All @@ -42,4 +46,4 @@ Navigate to the [Validate page](https://saf.mitre.org/#/validate) to find librar
### 4.4. What if there is no content for a software component?
- First, reach out to the SAF team at [[email protected]](mailto:[email protected]) to find out if there is a profile in development or otherwise available but not listed that could meet your needs.
- Second, if there is still no profile available, identify the security guidance to which the profile should comply and reach out to find out how to best create that profile. We help teams do this and provide training courses on that as well!
- Third, if there is no guidance available for your particular component, talk with us about developing the guidance using [MITRE's Vulcan application](https://vulcan.mitre.org/). Reference the [training class](../guidance) on security guidance development.
- Third, if there is no guidance available for your particular component, talk with us about developing the guidance using [MITRE's Vulcan application](https://vulcan.mitre.org/). Reference the [training class](../guidance) on security guidance development.
8 changes: 4 additions & 4 deletions src/courses/user/05.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,7 +23,7 @@ When using this mindset in software development, this kind of development can be
::: details A note on Test Driven Development (TDD)
The idea of using Test Driven Development (in other words, having the code driven by tests and therefore, the requirements) helps the humans confirm that the software does exactly what it is supposed to do - not more and not less.

This process starts with a FAILING test. Then, the minimal amount of change required is done to fix the code so that the test passes. Once the test passes, the code can be refactored to be cleaner, more readable, etc. This is a cycle, and returns to the top to create a new failing test. As development continues, all tests should be run to confirm that all tests still pass! These tests can be put in an automated suite to validate the code set whenever there are changes overall.
This process starts with a FAILING test. Then, the minimal amount of change required is done to fix the code so that the test passes. Once the test passes, the code can be refactored to be cleaner, more readable, etc. This is a cycle and returns to the top to create a new failing test. As development continues, all tests should be run to confirm that all tests still pass! These tests can be put in an automated suite to validate the code set whenever there are changes overall.

The SAF team values this methodology and helps teams implement security compliance tests using InSpec so they can understand the state of the system and the goal state of a secured system, using automated tests to get this information easier, quicker, and more often.
![Test-Driven Development](../../assets/img/TestDrivenDevelopment.png)
Expand All @@ -32,11 +32,11 @@ The SAF team values this methodology and helps teams implement security complian
## 5.1 What is InSpec?
"Chef [InSpec](https://www.chef.io/downloads/tools/inspec) is an infrastructure security and compliance testing framework with a human- and machine-readable language for comparing actual versus desired system state."

The SAF uses InSpec profiles to test software components against a security baseline. These automated tests produce data showing what security controls passed or failed, or were skipped or not reviewed and gives the reason and more information to fix it if not passing.
The SAF uses InSpec profiles to test software components against a security baseline. These automated tests produce data showing what security controls passed or failed, or were skipped or not reviewed, and give the reason and more information to fix it if not passing.

::: note What is an InSpec profile?
The term __InSpec profile__ refers a collection of security tests written in InSpec (the programming language).
To learn more, look at the Beginner Developer's section on [What is an InSpec Profile](../beginner/02.md/#what-is-an-inspec-profile) and test your understanding in [this comprehension check](../beginner/02.md/#check-in).
The term __InSpec profile__ refers to a collection of security tests written in InSpec (the programming language).
To learn more, look at the Beginner Developer's section on [What is an InSpec Profile](../beginner/02.md#what-is-an-inspec-profile) and test your understanding in [this comprehension check](../beginner/02.md#check-in).
:::

## 5.2 Examples of InSpec profiles
Expand Down
12 changes: 6 additions & 6 deletions src/courses/user/README.md
Original file line number Diff line number Diff line change
@@ -1,8 +1,8 @@
---
order: 1
next: 02.md
title: SAF User Class
shortTitle: SAF User Class
title: 1. SAF User Class
shortTitle: 1. SAF User Class
author: Aaron Lippold
headerDepth: 3
---
Expand All @@ -19,7 +19,7 @@ How is software secured and maintained in your context? Think about your situati

1. What is your role in the security process of your organization?
2. How frequently and for how much time does the software get assessed?
3. What is the biggest challenge for maintaining and assessing software security?
3. What is the biggest challenge in maintaining and assessing software security?
4. What changes would improve software assessment in your context?
5. What do you want to learn from this training?

Expand All @@ -28,16 +28,16 @@ By the end of the SAF User Class, you should be able to achieve all of the follo
- Identify and locate security guidance for a software component.
- Understand the capabilities available in the main pillars of the MITRE Security Automation Framework - Plan, Harden, Validate, Normalize, Visualize.
- Define and run an InSpec profile to validate a component against security guidance.
- Visualize InSpec results and third party security tool data.
- Visualize InSpec results and third-party security tool data.
- Automatically export checklist results from a security assessment.

### 1.3.1 The Lab Environment

This class will use GitHub Codespaces for a consistent environment for all students. See instructions for setting up your own lab environment [here](../../resources/05.md).
This class will use GitHub Codespaces to create a consistent environment for all students. See instructions for setting up your own lab environment [here](../../resources/05.md).

## 1.4 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.

Expand Down
Loading