The SIMP Compliance Engine (SCE) is a new component released in SIMP Enterprise Edition that automates the enforcement of compliance profiles across your infrastructure. Each compliance profile contains a checklist of the settings (or groups of settings) that should be applied to nodes within your infrastructure. SIMP EE supports both pre-configured and custom compliance profiles.
The compliance engine converts the generic checklist into a set of specifically mapped settings and feeds it into the underlying configuration management system. Currently we support generating class parameters and variables for Puppet via a custom Hiera backend.
Installing SCE is required for SIMP EE to function. The Windows platform was built in tandem with SCE and cannot apply compliance settings without it. Enforcing a compliance profile is not required for the Linux platform in SIMP 6 to change compliance settings, but it should be noted this will be required for SIMP 7.
Platform | SIMP Version | Enforcing Required? |
---|---|---|
Linux | 6 | N |
Windows | 6 | Y |
Linux | 7 | Y |
Windows | 7 | Y |
For Puppet versions after 4.10, including all versions of Puppet 5, we recommend using Hiera version 5 and configuring SCE in an environment layer hiera.yaml
. If you are using the version 5 Hiera backend ensure that the version 3 gem is no longer installed immediately after configuring your system to use version 5. This can prevent potential conflicts between the two libraries.
If you have an existing hiera.yaml
, you will need to copy the last two lines of this example into your hiera.yaml
to add SCE to your hierarchy. Edit /etc/puppetlabs/code/environments/production/hiera.yaml
.
---
version: 5
defaults:
datadir: "data"
data_hash: "yaml_data"
hierarchy:
- name: "SIMP Compliance Engine"
lookup_key: "compliance_markup::enforcement"
To apply a compliance profile to a node, add a new setting to the node’s Hiera data specifying the compliance profile to apply:
---
compliance_markup::enforcement: [ 'disa_stig' ]
You can also specify a list of compliance profiles to apply, in order from highest priority to lowest. Each profile will be compiled separately and values in the highest priority profile will be returned by SCE. This can allow you to create a small custom profile based on a built-in profile with changes only to settings you wish to customize..
For example, to apply SOX and PCI compliance settings, and to force SOX settings to always override PCI settings, add the following to Hiera:
---
compliance_markup::enforcement:
- sox
- pci_dss_v3.1
Creating a new custom profile involves placing a YAML file in a /SIMP/compliance_profiles
directory in the root of your Puppet environment. This YAML file is made up of one or more of the following SCE elements:
Name | Description |
---|---|
Compliance Profile | A checklist of the Checks, CEs, and Controls to add (or remove) from the profile. |
Check | An individual configuration or check setting such as a Puppet class parameter, Bolt task, or SCAP content |
Configuration Element (CE) | A general configuration setting such as a DISA STIG control or CIS control where there is an explicit defined setting that must be enforced. |
Control | A high level compliance requirement, for example NIST AU-2, that describes a policy for audit logging that must be adhered to. |
Most SIMP users will only have to worry about creating Checks and Compliance Profiles. The following sample compliance profile will create a new check to enforce widget_spinner::audit_logging
to be set to true
:
---
version: 2.0.0
profiles:
custom_profile:
controls:
custom_profile: true
checks:
widget_spinner_audit_logging:
type: 'puppet-class-parameter'
controls:
custom_profile: 0
nist_800_53:rev4:AU-2: 0
settings:
parameter: 'widget_spinner::audit_logging'
value: true
The custom profile is optional if you installed one of the built-in profiles that is using nist_800_53:rev4:AU-2
as a control. SCE automatically maps loaded checks and CEs to controls when they are specified in a profile. This allows for profiles to remain relatively stable while underlying Puppet modules or components change during normal operation.