Basic concepts

The basic concepts include an overview of CEM and the security standards that it enforces. You can also learn about Hiera, a key-value store that is used to configure CEM.

Compliance Enforcement Modules

CEM is software that automatically enforces security standards on IT infrastructures. After CEM is installed and configured, you can run Puppet Enterprise (PE) or open source Puppet on your specified nodes, and CEM automatically enforces security controls.

Hiera

To configure CEM, you can use the Hiera key-value store. Hiera stores configuration data in a hierarchical structure in key-value pairs. For an introduction, see About Hiera.

Center for Internet Security (CIS)

The Center for Internet Security, Inc., is a nonprofit organization that strives to protect IT infrastructures through collaboration and innovation. Contributors to the organization include security experts from government, business, and academia who develop and maintain internationally recognized security standards. For more information, see Center for Internet Security.

CIS Benchmarks

CIS develops and maintains CIS Benchmarks, which are configuration recommendations for product families. For example, if your nodes run on the Red Hat Enterprise Linux (RHEL) 8 operating system, you can enforce the CIS Red Hat Enterprise Linux 8 Benchmark v2.0.0, Level 1 or 2. For more information, see CIS Benchmarks.

CIS profiles and levels

Each CIS Benchmark has a profile, which consists of a level and an applicability.

The level refers to the degree of protection:
  • Level 1 is intended to be practical and prudent, providing a clear security benefit without inhibiting the use of the technology.
  • Level 2 extends the Level 1 profile to provide additional protection for systems in which security is paramount. Level 2 can affect a system’s performance and usability while promoting enhanced security.

The applicability refers to the affected system component. For example, if a benchmark has a profile of Level 1 – Server, the benchmark provides Level 1 (basic) security protections for servers.

CIS controls

Each CIS Benchmark consists of controls, which are also called recommendations or rules. Each control is a security safeguard. For example, a control might disable the use of Bluetooth communication technologies on the protected system because Bluetooth transmissions can be intercepted. Or a control might specify that passwords must consist of at least 14 characters to help prevent unauthorized access.

To learn about the CIS controls that are enforced by CEM, go to the CEM Linux Reference section on Puppet Forge and click a benchmark to see the list of enforced controls. The control description starts with its config ID and name, for example:
5.4.2 - Ensure lockout for failed password attempts is configured
The anatomy of a CIS control is as follows:
  • Parameters: Configuration options, along with data types and default values.
  • Supported Levels: The supported levels for the control, for example, Level 1 or 2.
  • Supported Profiles: The applicability of the control. For example, a control with a server profile is applicable to server components.
  • Hiera Configuration Example: Snippet of code that can be used to configure the control in Hiera.
  • Alternate Config IDs: The alternate config IDs for a control. If you configure the control in Hiera, you can use any of the listed config IDs. However, you cannot mix and match types within a configuration; you must use a single type of config ID.
  • Resource: The name of the Puppet resource that enforces the control.
To enforce a CIS control on a node, you add Hiera data to your control repository. A control repository is the location where CEM configuration data is stored. For example, to enforce a CIS Benchmark with a profile of Level 1 – Server and specify only one control (for file system integrity), you would enter the following values:
# control-repo/data/nodes/<node name>.yaml 
cem_linux::benchmark: 'cis'  
cem_linux::config:  

  profile: 'server'  
  level: '1'  

  only:  

     - 'ensure_filesystem_integrity_is_regularly_checked'

Security Technical Implementation Guides (STIGs)

The Security Technical Implementation Guides (STIGs) specify practices for configuring hardware and software to help prevent security vulnerabilities. Each STIG is a security standard for a vendor-specific component, such as RHEL 8. For details, see Security Technical Implementation Guides (STIGs).

Defense Information Systems Agency (DISA)

The Defense Information Systems Agency (DISA) is a unit within the US Department of Defense. DISA provides IT and communications support to individuals and institutes working for the Department of Defense. DISA maintains and updates hundreds of STIGs, known as DISA STIGs.

DISA STIGs

DISA STIGs are security standards. To learn about DISA STIG standards that you can enforce with CEM, go to the CEM Linux Reference on Puppet Forge and click a STIG standard to see the list of enforced controls. Each 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. For example, you can find control V-204486 in the Red Hat Enterprise Linux 7 Security Technical Implementation Guide.

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 a critically important system. The loss of availability or integrity of MAC 1 systems is considered unacceptable.
    • mac-2 specifies 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 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: Snippet of Hiera that can be used to configure the control.
  • Resource: The name of the Puppet resource that enforces the control.