2. What is an InSpec Profile?

Aaron LippoldMay 22, 2022About 3 min

Check-In

Have you used InSpec before?

There is no right or wrong answer. If this is your first time using InSpec, welcome! If you have used it before, welcome back. If you want more information on the basics of Ruby (InSpec is built on Ruby), take a look at the Ruby materials linked on the home page.

Which goal of the MITRE Security Automation Framework (SAF) is supported by InSpec?

InSpec is used in the Validate pillar. InSpec is used to do security validation.

Note that InSpec is not the only validation solution, but the one preferred by the MITRE SAF team. You are not required to use InSpec to use the rest of MITRE SAF's approach to security.

Is your Codespace environment set up successfully?

This class will have hands-on activities. The class contents are written assuming that you are following along using the recommended development lab environment, which leverages GitHub Codespaces to give you a stable development VM. All you need is to login with a GitHub account (which you can make for free), and follow the directions in the README.md.

To setup your environment, run source ./build-lab.sh. This script will install all of the dependencies we will be using in this class, not the least of which is the executable InSpec binary itself. You can validate that everything is up and running properly by running ./test-lab.sh. If anything goes wrong or gets misconfigured, you can just run source ./build-lab.sh again.

What is an InSpec Profile?

An InSpec profile is a collection of automated tests. In real-world contexts, if we are testing a system for security, we are running tests based off of some security guidance documentation such as a Center for Internet Security (CIS) Benchmark or one of the Defense Information Security Agency (DISA) Security Technical Implementation Guide (STIGs). An InSpec profile provides an organized structure to articulate that set of requirements as code.

If you have gone through the MITRE SAF Guidance Class, you may recall that a security guidance document can often be expressed as a structured, machine-readable dataset. We like to think of the human-friendly security guidance documentation and the programmatic validation of that guidance via a testing tool such as InSpec as ultimately two different ways of formatting the same data about security requirements.

The Structure of an InSpec Profile

An InSpec profile has two required elements:

An inspec.yml file
A controls directory

and four (4) optional elements:

A libraries directory
A files directory
An inputs.yml file
A README.md file

You can learn all the details here: https://docs.chef.io/inspec/profiles/

We will be discussing the purpose and function of each of these elements during this class.

# Example profile structure
nginx
└── profile
    ├── README.md
    ├── inputs.yml
    ├── controls
    │   ├── V-2230.rb
    │   └── V-2232.rb
    ├── files
    │   └── services-and-ports.yml
    ├── inspec.yml
    └── libraries
        └── nginx_helper.rb

The Structure of an InSpec Control

Let's start off by taking a glance at what a quality InSpec control looks like when complete. This example is taken from the InSpec profile that the MITRE SAF team developed to assess a Red Hat Enterprise Linux 9 operating system against security guidance documentation coming from a STIG - it could just as well have come from an alternative authority such as a CIS Benchmark.

redhat-enterprise-linux-9-stig-baseline/controls/SV-257791.rb

control 'SV-257791' do
  title 'RHEL 9 /boot/grub2/grub.cfg file must be owned by root.'
  desc 'The " /boot/grub2/grub.cfg" file stores sensitive system configuration. Protection of this file is critical for system security.'
  desc 'check', 'Verify the ownership of the "/boot/grub2/grub.cfg" file with the following command:

$ sudo stat -c "%U %n" /boot/grub2/grub.cfg

root /boot/grub2/grub.cfg

If "/boot/grub2/grub.cfg" file does not have an owner of "root", this is a finding.'
  desc 'fix', 'Change the owner of the file /boot/grub2/grub.cfg to root by running the following command:

$ sudo chown root /boot/grub2/grub.cfg'
  impact 0.5
  ref 'DPMS Target Red Hat Enterprise Linux 9'
  tag check_id: 'C-61532r925358_chk'
  tag severity: 'medium'
  tag gid: 'V-257791'
  tag rid: 'SV-257791r925360_rule'
  tag stig_id: 'RHEL-09-212030'
  tag gtitle: 'SRG-OS-000480-GPOS-00227'
  tag fix_id: 'F-61456r925359_fix'
  tag 'documentable'
  tag cci: ['CCI-000366']
  tag nist: ['CM-6 b']
  tag 'host'

  only_if('Control not applicable within a container', impact: 0.0) {
    !virtualization.system.eql?('docker')
  }

  grubfile = input('grub_conf_path')

  describe file(grubfile) do
    it { should exist }
    it { should be_owned_by 'root' }
  end
end

An InSpec control includes specific keywords like control and describe that define and logically organize tests. It will likely also reference some InSpec Resources: pre-defined classes that model sometimes rather complex parts of software systems that we want to test. These resources expose easy to use APIs for a variety of different constructs. This control invokes the file resource, which allows test authors to ask questions about the attributes of a given file on the filesystem.

What happens when I run a profile?

InSpec controls can be run singularly, but are more commonly run in a group as an entire profile is executed against the system we want to evaluate. The tool can pass output to a variety of destinations - in simple cases, we will direct the output to the terminal's STDOUT, while if we want to save our results to a report, we can pass the report to a visualization tool such as Heimdall. We will discuss reporting and visualizing InSpec's output in more detail later.

READONLY

InSpec controls when written correctly should not make changes to your software system as you ought to only be validating that a security requirement is met. You should be utilizing a different technology to correct anything found to be non-compliant - these technologies are frequently labelled as "infrastructure as code".