DOCSEARCHbyAlgolia
Submit Docs

Security Automation Framework (SAF) Training

website·Indexed 30 days ago

https://mitre.github.io/saf-training

Training documentation for the Security Automation Framework (SAF), featuring courses for users, beginner developers, and delta process developers. Content covers InSpec profile development, Vulcan project components, Test Kitchen workflows, manual attestations, and running InSpec in air-gapped environments.

Tokens
55K
Snippets
214
Records
387
Agent score
68%

What's inside SAF

  1. Overview of Heimdall for security data visualization

    Heimdall is a free tool designed to normalize and visualize security data from various disparate sources and tools, including InSpec. While it is the preferred tool for the MITRE SAF team, other dashboarding solutions like the ELK Stack or Splunk can also be used to aggregate security data. Heimdall supports an expanding list of commercial and open-source security tools via its Normalize capability.

  2. Overview of InSpec Profile Development Toolchain

    Developing and testing InSpec validation profiles requires a coordinated suite of tools to ensure security compliance and automated testing. The primary toolchain includes:

    • InSpec: The core compliance testing framework used to write and execute security checks (e.g., inspec exec).
    • Test Kitchen: An integration testing framework used to automate the validation of InSpec profiles (e.g., kitchen test). It is used both locally and within GitHub Actions CI/CD pipelines.
    • Docker/Podman: Container runtimes used to create isolated, consistent test environments.
    • Platform One (P1): The DoD's DevSecOps platform, providing hardened containers (Iron Bank images) for secure development and testing.
    • AWS: Used for testing profiles in cloud environments (typically utilizing Free Tier resources).
    • Ruby: The underlying language for InSpec and Test Kitchen.

  3. Overview of the MITRE Security Automation Framework (SAF)

    The MITRE Security Automation Framework (SAF) is designed to automate security validation and visualization. It streamlines the process of converting human-readable requirement documents (such as SRGs, STIGs, or CIS Benchmarks) into automated test profiles (code). These tests record results in a standardized format, allowing security data to be exported to visualization platforms like the Heimdall app for informed decision-making.

  4. Overview of InSpec for compliance validation

    InSpec is an open-source, cross-platform (Windows, Linux, Mac) compliance validation framework used to define machine-readable security requirements. It is agnostic to other DevOps tools and integrates with various configuration management tools to automate security testing.

  5. Overview of InSpec for security validation

    InSpec is an open-source, cross-platform framework used to define machine-readable compliance and security requirements. It allows developers to transform security policy (such as SRGs, STIGs, or CIS Benchmarks) into automated security testing. InSpec is agnostic to other DevOps tools and integrates with various configuration management tools.

  6. Overview of the MITRE SAF Delta process

    The MITRE SAF Delta process is used to maintain InSpec profiles (collections of automated tests) when the underlying security guidance documentation changes. It allows developers to update an existing InSpec profile from an old guidance document to a newer one, or create a new baseline profile from older revisions of the same baseline, ensuring that automated tests do not become obsolete.

  7. Overview of the Security Automation Framework (SAF)

    The Security Automation Framework (SAF) is a framework consisting of a collection of tools, techniques, applications, and libraries designed to streamline security automation. It is not a single tool, but a system that allows teams to adapt their security journey based on their specific environments.

    The SAF is built around five main pillars:

    • Plan: Determine which guidance will help keep software secure.
    • Harden: Use libraries and tools to automatically secure software.
    • Validate: Automatically verify software security based on guidance.
    • Normalize: Standardize security data from various sources.
    • Visualize: Present information to inform teams of risks and vulnerabilities.

  8. Overview of MITRE Security Automation Framework (SAF) training

    The MITRE Security Automation Framework training provides guidance on using InSpec to transform security policies into automated security testing. Key learning objectives include:

    • Understanding InSpec profile architecture and deployment options.
    • Using the InSpec CLI to create components, modules, and unit tests.
    • Developing InSpec profiles to automate security policy testing.
    • Executing profiles against application stack components.
    • Generating normalized, portable security test reports for CI/CD pipelines.
    • Analyzing security posture by delivering InSpec results to the Heimdall visualization app.

  9. Overview of Test Kitchen for infrastructure testing

    Test Kitchen is a testing framework used to validate infrastructure code across various platforms and configurations. It provides an isolated environment (a 'laboratory') to experiment with system configurations without impacting production environments.

  10. Understand Security Technical Implementation Guides (STIGs)

    A Security Technical Implementation Guide (STIG) is a set of software-specific requirements and implementation instructions imposed by the US Department of Defense (DOD) to ensure a technology component (e.g., operating systems, webservers, routers) is securely configured. STIGs are published by the Defense Information Systems Agency (DISA), typically authored by software vendors, and peer-reviewed by DISA. They are designed to be followed by individuals who may not be experts in the specific technology.

  11. Understand the Delta process for updating control metadata

    The Delta process updates InSpec profiles by replacing 'control metadata' with content from a supplied XCCDF guidance document for controls that map from one baseline to another. Crucially, the Delta process does not modify the underlying Ruby/InSpec code within the control; it only updates the metadata.

  12. Understand 'Not Reviewed' control status in Heimdall

    In the Heimdall visualization tool, controls are displayed in four statuses: Passed, Failed, Not Applicable, and Not Reviewed. A status of Not Reviewed often indicates that the control requires a manual review because it cannot be tested automatically by security tools.