This InSpec profile can help programs automate security compliance checks of Debian 11 (bullseye) systems against Department of Defense (DoD) STIG-style guidance.
- Profile Version:
0.1.0 - Derived from: Canonical Ubuntu 20.04 LTS STIG baseline v2.4 (Canonical Ubuntu 20.04 LTS STIG)
This profile uses the InSpec open-source compliance validation language to support automation of the required compliance, security and policy testing for Assessment and Authorization (A&A) and Authority to Operate (ATO) decisions and Continuous Authority to Operate (cATO) processes.
- Why This Profile Is an Overlay
- Benchmark Information
- Getting Started
- Running the Profile
- Using Heimdall for Viewing Test Results
- FIPS 140 on Debian
- Authors
- NOTICE
DISA publishes no STIG for Debian. Debian is, however, the upstream distribution from which Ubuntu is built, and Canonical publishes DISA STIGs for Ubuntu LTS releases — so the Ubuntu STIG is the closest published guidance that exists for a Debian system.
This profile is therefore an InSpec overlay of the Canonical Ubuntu 20.04 LTS STIG baseline maintained by the MITRE SAF team. It runs the full upstream control set against Debian 11 and overrides, in controls/overlay.rb, only the checks where Debian genuinely differs from Ubuntu — different packaging conventions, different file locations, or requirements with no Debian equivalent. Ubuntu 20.04 was chosen for Debian 11 because its component set (OpenSSL 1.1.1, matching systemd/PAM era) is the closest STIG-covered match to bullseye.
The DISA RME and DISA SD Office, along with their vendor partners, create and maintain a set of Security Technical Implementation Guides for applications, computer systems and networks connected to the Department of Defense (DoD). These guidelines are the primary security standards used by the DoD agencies.
Requirements associated with the Canonical Ubuntu 20.04 LTS STIG — and, through this overlay, with this profile — are derived from the Security Requirements Guides and align to the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 Security Controls, DoD Control Correlation Identifier and related standards. Each control in this profile inherits the upstream control's compliance metadata (STIG IDs, SRG IDs, CCIs, NIST tags), so downstream tooling sees the same mappings it would from the Ubuntu profile.
For maximum flexibility/accessibility, cinc-auditor, the open-source packaged binary version of Chef InSpec, should be used, compiled by the CINC (CINC Is Not Chef) project in coordination with Chef using Chef's always-open-source InSpec source code. For more information see CINC Home.
It is intended and recommended that CINC-auditor and this profile be executed from a "runner" host (such as a DevOps orchestration server, an administrative management system, or a developer's workstation/laptop) against the target. This can be any Unix/Linux/MacOS or Windows runner host, with access to the Internet.
Tip
For the best security of the runner, always install on the runner the latest version of CINC-auditor and any other supporting language components.
To install CINC-auditor on a UNIX/Linux/MacOS platform use the following command:
curl -L https://omnitruck.cinc.sh/install.sh | sudo bash -s -- -P cinc-auditorTo install CINC-auditor on a Windows platform (Powershell) use the following command:
. { iwr -useb https://omnitruck.cinc.sh/install.ps1 } | iex; install -project cinc-auditorTo confirm successful install of cinc-auditor:
cinc-auditor -v
Latest versions and other installation options are available at the CINC Auditor site.
-
The latest
releasedversion of the profile is intended for use in A&A testing, as well as providing formal results to Authorizing Officials and Identity and Access Management (IAM)s. Please use thereleasedversions of the profile in these types of workflows. -
The
mainbranch is a development branch that will become the next release of the profile. Themainbranch is intended for use in developing and testing merge requests for the next release of the profile, and is not intended to be used for formal and ongoing testing on systems.
This profile is container-aware: controls that cannot apply inside a container (kernel parameters, bootloader, auditd, GUI, and similar host-only subsystems) detect the container environment and mark themselves Not Applicable automatically. This behavior is inherited from the upstream Ubuntu baseline and preserved in every overlay override, so the same profile can scan hosts, VMs, and container images.
This profile uses InSpec Inputs to provide flexibility during testing. Inputs allow for customizing the behavior of Chef InSpec profiles.
InSpec Inputs are defined in the inspec.yml file. The inputs configured in this file are profile definitions and defaults for the profile and shouldn't be modified. InSpec provides several methods for customizing profile behaviors at run-time that do not require modifying the inspec.yml file itself (see Using Customized Inputs).
| Input | Type | Default | Description |
|---|---|---|---|
sudo_accounts |
Array | ["debian"] |
Users expected to be in the sudo group. The upstream default is Ubuntu's cloud-image ubuntu user, which does not exist on Debian; this overlay substitutes Debian's cloud-image debian user. Override with your real administrative accounts. |
All inputs declared by the upstream Canonical Ubuntu 20.04 LTS STIG baseline remain available and keep their upstream defaults — set any of them at run time exactly as you would when running the Ubuntu profile. See the upstream inspec.yml for the full list.
Customized inputs may be used at the CLI by providing an input file or a flag at execution time.
-
Using the
--inputflagExample:
[inspec or cinc-auditor] exec <my-profile.tar.gz> --input sudo_accounts='["admin1","admin2"]' -
Using the
--input-fileflag.Example:
[inspec or cinc-auditor] exec <my-profile.tar.gz> --input-file=<my_inputs_file.yml>
Tip
For additional information about input file examples reference the MITRE SAF Training
Chef InSpec Resources:
The Gemfile provided contains all the necessary ruby dependencies for checking the profile controls. Install them by invoking the bundler command (must be in the same directory where the Gemfile is located):
bundle installLinting and validating controls:
bundle exec rake inspec:check # Validate the InSpec Profile
bundle exec rake lint # Run RuboCop Linter
bundle exec rake pre_commit_checks # Pre-commit checks (lint + check)This option is best used when network connectivity is available and policies permit access to the hosting repository.
# Using `ssh` transport
bundle exec [inspec or cinc-auditor] exec https://github.com/mitre/debian-11-stig-baseline/archive/main.tar.gz --input-file=<your_inputs_file.yml> -t ssh://<hostname>:<port> --sudo --reporter=cli json:<your_results_file.json>If your runner is not always expected to have direct access to the profile's hosted location, use the following steps to create an archive bundle of this overlay and all of its dependent tests:
Git is required to clone the InSpec profile using the instructions below. Git can be downloaded from the Git Web Site.
When the "runner" host uses this profile overlay for the first time, follow these steps:
mkdir profiles
cd profiles
git clone https://github.com/mitre/debian-11-stig-baseline.git
bundle exec [inspec or cinc-auditor] archive debian-11-stig-baseline
# Using `ssh` transport
bundle exec [inspec or cinc-auditor] exec <name of generated archive> --input-file=<your_inputs_file.yml> -t ssh://<hostname>:<port> --sudo --reporter=cli json:<your_results_file.json>For every successive run, follow these steps to always have the latest version of this profile baseline:
cd debian-11-stig-baseline
git pull
cd ..
bundle exec [inspec or cinc-auditor] archive debian-11-stig-baseline --overwriteThe JSON results output file can be loaded into Heimdall-Lite or Heimdall-Server for a user-interactive, graphical view of the profile scan results.
Heimdall-Lite is a browser only viewer that allows you to easily view your results directly and locally rendered in your browser. Heimdall-Server is configured with a data-services backend allowing for data persistency to a database (PostgreSQL). For more detail on feature capabilities see Heimdall Features.
Heimdall can export your results into a DISA Checklist (CKL) file for easily uploading into eMass using the Heimdall Export function.
Depending on your environment restrictions, the SAF CLI can be used to run a local docker instance of Heimdall-Lite via the saf view:heimdall command.
Additionally both Heimdall applications can be deployed via docker, kubernetes, or the installation packages.
Several controls in the upstream Ubuntu STIG concern FIPS 140 cryptography (SV-238216, SV-238217, SV-238325, SV-255912, SV-238363). It is possible to run the original Ubuntu profile checks against Debian and receive results, but note that even if the correct packages are present, Debian has no validated FIPS modules.
On Ubuntu Pro or RHEL, "FIPS mode" means that the system is using a stack of CMVP-validated cryptographic modules — NIST certificates naming the exact binary builds of OpenSSL, the kernel crypto API, and so on. FIPS 140 validation attaches to module builds and their certificates — not to algorithm names. So even though Debian is capable of running the kernel in FIPS mode and using appropriate algorithms for things like SSH libraries, Debian still has no CMVP-validated modules.
Therefore, even though Debian can technically be configured to pass the literal text of Ubuntu's STIG requirement for FIPS, it can't comply with its actual intent. The profile author has modified the FIPS-mode kernel check (SV-238363) in this overlay profile to fail by default accordingly.
- SV-238216, SV-238217, SV-238325, SV-255912 verify approved-algorithm configuration (SSH MACs/ciphers/kex lists, SHA512 password hashing). These are real, distinct security properties a Debian system does or does not have, and they pass or fail on their own merits. They run exactly as upstream wrote them — this section is the note about their limitation.
- SV-238363 ("must implement NIST FIPS-validated cryptography") checks the
fips=1kernel posture and then fails unconditionally with a message pointing here. This is intentional: on Ubuntu,fips_enabled=1implies the validated Pro stack; on Debian it does not, and passing the upstream check would misrepresent an uncertified platform as compliant. Expect a permanent CAT I finding on every Debian scan. Deployments operating under a hard FIPS 140 mandate need a documented waiver/risk acceptance for it — or a platform that ships validated modules.
If the test runner has a documented waiver for the FIPS requirements for a Debian deployment, they can write a local overlay for their specific environment to mark the FIPS requirements as Not Applicable. See the MITRE SAF instructions for overlays.
MITRE Security Automation Framework Team
© 2018-2025 The MITRE Corporation.
Approved for Public Release; Distribution Unlimited. Case Number 18-3678.
MITRE hereby grants express written permission to use, reproduce, distribute, modify, and otherwise leverage this software to the extent permitted by the licensed terms provided in the LICENSE.md file included with this project.
This software was produced for the U. S. Government under Contract Number HHSM-500-2012-00008I, and is subject to Federal Acquisition Regulation Clause 52.227-14, Rights in Data-General.
No other use other than that granted to the U. S. Government, or to those acting on behalf of the U. S. Government under that Clause is authorized without the express written permission of The MITRE Corporation.
For further information, please contact The MITRE Corporation, Contracts Management Office, 7515 Colshire Drive, McLean, VA 22102-7539, (703) 983-6000.