Overview of configuration options

Configuration options include top-level options, benchmark options, and Center for Internet Security (CIS)-specific options.

Find and set configuration options

You can find the configuration options in the Reference on Puppet Forge. Locate the CIS Benchmark or the DISA STIG standard that you want to enforce, and then view the associated controls and configuration options.

The Reference section lists only the controls that are automatically enforced by the module. To help prevent operational issues, the module does not automatically enforce all available controls for your selected CIS Benchmark or STIG standard. To enforce a control that is not enforced automatically, run the associated tasks or plans that govern that control. For more information, see Run tasks and plans.

When you use Hiera to specify configuration options, the configuration looks different from the configuration for other Puppet products. The reason is that the config variable receives a hash, and the key values in the hash control the SCE variables in the configuration.

CIS controls

Each CIS Benchmark has a list of associated controls, and additional information is provided for each control. The control description starts with a config ID and name, for example: 

5.4.1 - Ensure password creation requirements are configured
The anatomy of a CIS control is as follows:
  • Parameters: Configuration options for a control, along with the data type and default value.
  • Supported Levels: The supported levels for a CIS control.
  • Supported Profiles: The applicability of the control. For example, a control with a profile of server is applicable to server components.
  • Hiera Configuration Example: Snippet of Hiera that can be used to configure a control.
  • Alternate Config IDs: The alternate config IDs for a control. Any of these config IDs, along with the full control name, can be used as a key in the control_config hash.
  • Resource: The name of the Puppet resource that enforces the control.

Guidelines for specifying CIS config IDs

You can specify CIS controls in the control_config hash by referencing the full control name, the control number, the normalized control name, or the normalized control number. You cannot mix and match these forms and must pick a single config ID form to use for your config. Full control names and control numbers are copied verbatim from the benchmarks and are case-sensitive. Normalized control names have lowercase letters and contain only alphanumeric characters and underscores. Normalized control numbers are always prefixed with a c and contain only numeric characters separated by underscores.

Example of alternate config IDs:

  • Full control name: (L1) Ensure 'Enforce password history' is set to '24 or more password(s)'
  • Control number: 1.1.1
  • Normalized control name: ensure_enforce_password_history_is_set_to_24_or_more_passwords
  • Normalized number: c1_1_1

DISA STIG controls

You can view DISA STIG controls in the Reference on Puppet Forge. Each DISA STIG control is identified by its vulnerability ID, for example: V-204486. To learn about the purpose of a STIG control, go to the STIG Viewer and search for the operating system associated with the control, and then the control.

For example, if your nodes are running on RHEL 7, you can find relevant information in the Red Hat Enterprise Linux 7 Security Technical Implementation Guide. That webpage also describes Control V-204486.

The anatomy of a DISA STIG control is as follows:

  • Parameters: Configuration options, along with data types and default values.

  • Supported Levels: The level of required protection, specified in terms of Mission Assurance Category levels (MACs):

    • mac-1 specifies protection for a critically important system. The loss of availability or integrity of MAC 1 systems is considered unacceptable.

    • mac-2 specifies protection for a system that handles support for deployed or contingency forces. The loss of a MAC 2 system can be tolerated only briefly.

    • mac-3 specifies protection for a system that handles information required for day-to-day operations. The loss of a MAC 3 system can be tolerated without largely impacting mission or operational readiness.

  • Supported Profiles: The supported profiles for the control, such as public, classified, or sensitive.

  • Hiera Configuration Example: Hiera code snippet that can be used to configure the control.

  • Resource: The name of the Puppet resource that enforces the control.

Top-level configuration options

In Hiera, the top-level configuration options are found directly under the sce_linux (previously cem_linux) namespace. If you must customize SCE to meet your organization's requirements, you can specify values for the top-level configuration options.

In Hiera, the top-level options are prefixed with sce_linux:. The following list describes the options:

  • benchmark - Enum['cis','stig'] - the compliance framework to use. SCE for Linux supports only cis and stig. Default: cis.
  • config - Optional[Hash] - the location for all non-top-level configuration options. Default: undef.
  • allow_on_kubernetes_node - Boolean - If sce_linux detects that it is running on a Kubernetes cluster node or host, SCE does not enforce controls, and it logs a warning. In this way, SCE helps to prevent the accidental enforcement of incorrect compliance settings that can render Kubernetes non-functional. Default: false.
  • manage_gnome - Boolean - When set to true, controls are enforced to secure a GNOME desktop environment. When set to false, the controls are not enforced. Default: false.
  • disable_package_gpgcheck – Boolean – When set to true, GNU Privacy Guard (GPG) checks of downloaded packages are disabled. Disabling GPG checks can be helpful in rare cases if you enable more stringent system encryption standards, such as the Federal Information Processing Standards (FIPS). These tighter standards can introduce stricter criteria than are normally applied to GPG package signatures. If GPG and more stringent criteria are applied simultaneously, package downloads can fail. Specify disable_package_gpgcheck=true only when necessary because this setting can make your infrastructure less secure. Default: false.
  • regenerate_grub2_config - Boolean - Some configurations in SCE for Linux modify the Grub2 bootloader configuration. To regenerate the Grub2 configuration after applying a change, set this parameter to true. If you do not set this parameter to true, you must manually regenerate the Grub2 configuration. Default: false.
  • set_grub2_password - Boolean - Set the password for the Grub2 bootloader. If you set this value to true, you must also set the grub2_superuser and grub2_superuser_password parameters, or configure the specific bootloader password control by using the control_configs option. Default: false.
  • grub2_superuser - Optional[String[1]] - The superuser for the Grub2 bootloader if you set the set_grub2_password parameter to true. Default: Undef.
  • grub2_superuser_password - Optional[Sensitive[String]] - The superuser password for the Grub2 bootloader if you set the set_grub2_password parameter to true. This value is sensitive in terms of security and should be stored in a Sensitive data type. Default: Undef.

Hiera example

The following example configures SCE for Linux to regenerate the Grub2 bootloader config on a node using the CIS benchmark:

Copy 
sce_linux::benchmark: 'cis'
sce_linux::allow_on_kubernetes_node: false
sce_linux::regenerate_grub2_config: true
sce_linux::config:
...

Benchmark configuration options

Each Center for Internet Security (CIS) Benchmark and each Security Technical Implementation Guide (STIG) is associated with a set of configuration options. You can use Hiera to specify values for the benchmark configuration options.

The benchmark configuration options are available as key-value pairs within the sce_linux::config: hash. The following options are available:

  • only: - Optional[Array[String]] — takes an array of control class names (manifests/benchmarks/<benchmark>/controls/*.pp). Classes specified here are included in the catalog. This option takes precedence over ignore:. Default: undef.

  • ignore: - Optional[Array[String]] — takes an array of control class names (manifests/benchmarks/<benchmark>/controls/*.pp). The classes specified here are not included in the catalog. If only: and ignore: are specified, only is applied first, followed by ignore. Default: undef.

  • control_configs - Optional[Hash] — where all rule-specific configurations live. Default: undef.

CIS-specific configuration options

To meet your organization's requirements, you can specify CIS-specific configuration options, such as settings related to firewalls and log files. Use Hiera to specify these options.

The CIS-specific configuration options are available as key-value pairs within the sce_linux::config: hash:

  • profile: - Optional[Enum['server', 'workstation']] — the name of the benchmark profile. The only value supported by SCE is server. Default: server.

  • level: - Optional[Enum['1', '2']] — the name of the profile level. Default: 1.

  • firewall_type: - Optional[Enum['iptables', 'firewalld', 'unmanaged']] — the preferred firewall provider. If set to unmanaged, SCE will not enforce firewall-related rules. Default: firewalld.

  • enable_systemd_journal - Optional[Boolean] - Whether to enable the systemd-journal logging service. The default value is false. If this option is enabled, the systemd-journal-remote package will be installed and the systemd-journal-upload.service service will be enabled. However, several configuration parameters are required to ensure that the systemd-journal-upload.service functions correctly:

    Copy 
    sce_linux::config:
    control_configs:
    'ensure_systemd_journal_remote_is_configured':
    address: '<IP address or FQDN of the remote host>'
    server_key_file: '<path to the server key file>'
    server_certificate_file: '<path to the server certificate file>'
    trusted_certificate_file: '<path to the trusted certificate file>'