Table of Contents

• Overview
• Module Description
• Upgrading
• Reporting
  • What compliance_markup affects
• Usage
  • Report Format
  • Options
    • report_types
    • site_data
    • client_report
    • server_report
    • server_report_dir
    • server_report_dir
    • catalog_to_compliance_map
• Reference
  • Example 1 - Standard Usage
  • Example 2 - Custom Compliance Map
• Enforcement
  • v5 Backend Configuration
  • Configuring profiles to enforce
  • Debugging the Hiera Backend
• Limitations
• Development
  • Acceptance tests
• Packaging

Overview

This module adds a function compliance_markup::compliance_map() to the Puppet language. The compliance_markup::compliance_map() function provides the ability for users to compare their in-scope class parameters against a set of compliant parameters, either in Hiera or at the global scope. Users may also provide custom inline policy documentation and mapping documentation.

The goal of this module is to make it easier for users to both detect, and report on, deviations from a given policy inside their Puppet codebase.

See REFERENCE.md for more information.

Module Description

This module provides the function compliance_markup::compliance_map() and a compliance_markup class for including the functionality into your stack at the global level.

A utility for converting your old compliance_markup::compliance_map() Hiera data has also been included in the utils directory.

Upgrading

A utility script, compliance_map_migrate has been included in the utils directory of the module to upgrade your old compliance data to newer formats.

At minimum, you must pass to the script a compliance profile to migrate, the version of the API it was compatible with, and the version you wish to migrate it to. For instance, to upgrade a compliance map from API 0.0.1 to 1.0.0:

ruby compliance_map_migrate -i /etc/puppetlabs/code/environments/simp/hieradata/compliance_profiles/nist_800_53_rev4.yaml -s 0.0.1 -d 1.0.0

Please validate that the migrated YAML files work as expected prior to deploying them into production.

Reporting

What compliance_markup affects

By default, the compliance_markup::compliance_map() function creates a set of reports, one per node, on your Puppet Server at /opt/puppetlabs/server/data/puppetserver/simp/compliance_reports/<fqdn>.

You may optionally enable the creation of a File resource on each of your clients if you wish to have changes in this data automatically exported into PuppetDB.

Usage

The compliance_markup::compliance_map() function provides a mechanism for mapping compliance data to settings in Puppet and should be globally activated by including the compliance_markup class.

It is primarily designed for use in classes to validate that parameters are properly set but may also be used to perform a full compliance report against multiple profiles across your code base at compile time.

When the compliance_markup class is included, the parameters in all in-scope classes and defined types will be evaluated against top level parameters, lookup() values, or Hiera data, in that order.

The variable space against which the parameters will be evaluated must be structured as the following hash:

  compliance_map :
    <compliance_profile> :
      <class_name>::<parameter> :
        'identifiers' :
        - 'ID String'
        'value'      : 'Compliant Value'
        'notes'      : 'Optional Notes'

For instance, if you were mapping to NIST 800-53 in the SSH class, you would use something like the following:

  compliance_map :
    nist_800_53 :
      ssh::permit_root_login :
        'identifiers' :
        - 'CCE-1234'
        'value'      : false

Alternatively, you may use the compliance_markup::compliance_map() function to add compliance data to your modules outside of a parameter mapping. This is useful if you have more advanced logic that is required to meet a particular internal requirement.

NOTE: The parser does not know what line number and, possibly, what file the function is being called from based on the version of the Puppet parser being used.

The following parameters may be used to add your own compliance data:

:compliance_profile => 'A String, or Array, that denotes the compliance
                        profile(s) to which you are mapping.'
:identifiers        => 'An array of identifiers for the policy to which you
                        are mapping.'
:notes              => 'An *optional* String that allows for arbitrary notes to
                        include in the compliance report'

Report Format

The compliance report is formatted as follows (YAML Representation):

---
# The API version of the report
version: "1.0.1"
fqdn: "my.system.fqdn"
hostname: "my"
ipaddress: "1.2.3.4"
puppetserver_info: "my.puppet.server"
compliance_profiles:
  profile_name:
    summary:
      compliant: 80
      non_compliant: 20
      percent_compliant: 80
      documented_missing_resources: 2
      documented_missing_parameters: 1

    compliant:
      "Class[ClassName]":
        parameters:
          param1:
            identifiers:
              - ID 1
              - ID 2
            compliant_value: 'foo'
            system_value: 'foo'

    non_compliant:
      "Class[BadClass]":
        parameters:
          bad_param:
            identifiers:
              - ID 3
              - ID 4
            compliant_value: 'bar'
            system_value: 'baz'

    documented_missing_resources:
      - missing_class_one
      - missing_class_two

    documented_missing_parameters:
      - "classname::param2"

    custom_entries
      "Class[CustomClass]":
        location: "file.pp:123"
        identifiers:
          - My ID

site_data:
  completely: random user input

Options

The compliance_markup class may take a number of options which must be passed as a Hash.

report_types

Default: [ 'non_compliant', 'unknown_parameters', 'custom_entries' ]

A String, or Array that denotes which types of reports should be generated.

Valid Types:

• full: The full report, with all other types included.
• non_compliant: Items that differ from the reference will be reported.
• compliant: Compliant items will be reported.
• unknown_resources: Reference resources without a system value will be reported.
• unknown_parameters: Reference parameters without a system value will be reported.
• custom_entries: Any one-off custom calls to compliance_markup::compliance_map will be reported.

site_data

Default: None

A valid Hash that will be converted as passed and emitted into your node compliance report.

This can be used to add site-specific or other information to the report that may be useful for post-processing.

client_report

Default: false

A Boolean which, if set, will place a copy of the report on the client itself. This will ensure that PuppetDB will have a copy of the report for later processing.

server_report

Default: true

A Boolean which, if set, will store a copy of the report on the Server.

server_report_dir

Default: Puppet[:vardir]/simp/compliance_reports

An Absolute Path that specifies the location on

server_report_dir

Default: Puppet[:vardir]/simp/compliance_reports

An Absolute Path that specifies the location on the server where the reports should be stored.

A directory will be created for each FQDN that has a report.

catalog_to_compliance_map

Default: false

A Boolean which, if set, will dump a compatible compliance_map of all resources and defines that are in the current catalog.

This will be written to server_report_dir/<client_fqdn> as catalog_compliance_map. Old versions will be overwritten.

NOTE: This is an experimental feature and subject to change without notice.

Reference

The full module reference can be found in the module docs and in the local docs/ directory.

Example 1 - Standard Usage

Manifest

class foo (
  $var_one => 'one',
  $var_two => 'two'
) {
  notify { 'Sample Class': }
}

$compliance_profile = 'my_policy'

include '::foo'
include '::compliance_markup'

Hiera.yaml

:backends:
  - 'yaml'
:yaml:
  :datadir: '/path/to/your/hieradata'
:hierarchy:
  "global"

Hieradata

---
# In file /path/to/your/hieradata/global.yaml
compliance_map :
  my_policy :
    foo::var_one :
      'identifiers' :
      - 'POLICY_SECTION_ID'
      'value' : 'one'

Example 2 - Custom Compliance Map

if $::circumstance {
  compliance_markup::compliance_map('my_policy','POLICY_SECTION_ID','Note about this section')
  ...code that applies POLICY_SECTION_ID...
}

Enforcement

This module also contains a Hiera backend that can be used to enforce compliance profile settings on any module when it is included. It uses the compliance_markup::enforcement Array to determine the profiles to use, and which profiles take priority.

Only a Hiera v5 backend is provided. Because of this, the Hiera backend is only available on versions of Puppet 4.10 or above.

v5 Backend Configuration

---
version: 5
hierarchy:
  - name: SIMP Compliance Engine
    lookup_key: compliance_markup::enforcement
    # All options are optional
    options:
      # Ignore all default data dirs and use these instead
      data_dirs:
        - /fully/qualified/data_dir
  - name: Common
    path: default.yaml
defaults:
  data_hash: yaml_data
  datadir: "/etc/puppetlabs/code/environments/production/hieradata"

Configuring profiles to enforce

To enforce disa stig + nist, with disa stig compliance settings taking priority, add the following to your hiera data files. This will work like any hiera setting, so you can set enforcement based on any factor, including host, hostgroup, kernel or specfic os version.

---
compliance_markup::enforcement: [ 'disa_stig', 'nist_800_53_rev4' ]

Configuring enforcement tolerance

Certain checks have a built-in safety mechanism built in called 'enforcement tolerance' this allows the user to define what level of risk they wish to enfoce and based on their tolerance level.

The default enforcement tolerance is 40. This will allow enforcement of any checks that can not cause any access restrictions or breakages to a system. If you wish to enforce checks that are more dangerous or less dangerous, you can override this default value but using:

---
compliance_markup::enforcement_tolerance_level: 40

Valid levels are:

• 20: Remediation works fine on all systems, changes will be made.
• 40: Remediation works, minor issues may arise in special cases
• 60: May cause login or access issues on system
• 80: Breaking remediation changes will be enforced

Debugging the Hiera Backend

The Hiera backend exposes a debug interface to users via lookup. These can be used to query the library for data or metrics.

Limitations

Depending on the version of Puppet being used, the compliance_markup::compliance_map() function may not be able to precisely determine where the function has been called and a best guess may be provided.

Hash values for Puppet parameters in compliance data will always be deep merged. Configurable merge behavior may be implemented in a future release.

Development

Patches are welcome to the code on the SIMP Project Github account. If you provide code, you are guaranteeing that you own the rights for the code or you have been given rights to contribute the code.

Acceptance tests

To run the tests for this module perform the following actions after installing bundler:

bundle update
bundle exec rake spec
bundle exec rake beaker:suites

Packaging

Running rake pkg:rpm[...] will develop an RPM that is designed to be integrated into a SIMP environment. This module is not restricted to, or dependent on, the SIMP environment in any way.

Reference

Table of Contents

Classes

• compliance_markup: The compliance markup helper class

Defined types

• compliance_markup::map: A wrapper to ensure that the mapper is called during the appropriate

Functions

• compliance_markup::compliance_map: Provides a mechanism for mapping compliance data to settings in Puppet
• compliance_markup::enforcement: Hiera entry point for the SIMP Compliance Engine To activate this hiera backend, add the following to your hiera.yaml: ```yaml --- versio
• compliance_markup::loaded_maps: Returns the compliance data keys from the loaded compliance maps

Classes

compliance_markup

This class should be included after all other classes in your site so that the mapper can properly analyze the standing catalog.

Parameters

The following parameters are available in the compliance_markup class:

• compliance_map
• validate_profiles
• report_types
• report_format
• report_on_client
• report_on_server
• server_report_dir
• custom_report_data
• options

compliance_map

Data type: Hash

The compliance Hash to which to map

• This defaults to Data In Modules

validate_profiles

Data type: Optional[Array[String[1]]]

Compliance profiles that you wish to validate against

Default value: undef

report_types

Data type:

Array[
    Enum[
      'full',
      'non_compliant',
      'compliant',
      'unknown_resources',
      'unknown_parameters',
      'custom_entries'
    ]
  ]

The types of entries that you want to report on

• full => Include all report types*

• non_compliant => Report on non-compliant parameters*

• unknown_parameters => Report on parameters that are mapped but not included in the catalog*

• custom_entries => Report custom calls to compliance_markup::compliance_map() from the codebase

• compliant => Report on compliant parameters

• unknown_resources => Report on classes that are mapped but not included in the catalog

• This is ignored if options is specified

Default value: ['non_compliant', 'unknown_parameters', 'custom_entries']

report_format

Data type: Enum['json','yaml']

The output format for the report

Default value: 'json'

report_on_client

Data type: Boolean

Save a copy of the report on the client as a File resource

• This will make the report show up in PuppetDB but may also expose unwanted vulnerability information

Default value: false

report_on_server

Data type: Boolean

Save a copy of the report on the puppet server

Default value: true

server_report_dir

Data type: Optional[Stdlib::Absolutepath]

The path where the server should store reports

• If you change this, you must make sure that the puppet server can write to the location.
• By default, this is written to Puppet[:vardir] as the Puppet server sees it: /opt/puppetlabs/server/data/puppetserver/simp/compliance_reports

Default value: undef

custom_report_data

Data type: Optional[Hash]

A hash that will be included in the compliance report under the heading site_data

• This can be used for adding anything to the compliance report. The hash is simply processed with to_yaml

Default value: undef

options

Data type: Optional[Hash]

The options to pass directly to the compliance_markup::compliance_map validation function

• If specified, various other options may be ignored

Default value: undef

Defined types

compliance_markup::map

phase of the catalog compile.

Defines appear to be run after all classes

Parameters

The following parameters are available in the compliance_markup::map defined type:

• options

options

Data type: Hash

The options hash is passed directly to the compliance_markup::compliance_map() function

Default value: {}

Functions

compliance_markup::compliance_map

Type: Ruby 4.x API

It should be used once, after all of your classes have been included and is designed for use in classes to validate that parameters are properly set.

The easiest method for doing this is to add it as the last line of site.pp.

When called, the parameters of all classes will be evaluated against global scope variables followed by data from lookup().

The variable space against which the class parameters will be evaluated must be structured as the following hash:

compliance_map : <compliance_profile> : <class_name>:: : 'identifiers' :

      - 'ID String'
    'value'      : 'Compliant Value'

For instance, if you were mapping to NIST 800-53 in the SSH class, you could use something like the following in Hiera:

compliance_map : nist_800_53 : ssh::permit_root_login : 'identifiers' :

      - 'CCE-1234'
    'value'      : false

'value' items have some special properties. Hashes and Arrays will be matched using '==' in Ruby.

Everything else will be converted to a String and can be provided a Ruby regular expression of the following format: 're:REGEX' where 'REGEX' does not include the starting and trailing slashes.

Example: 'value' : 're:oo'

Matches: 'foo' and 'boo' but not 'bar'

You may also add compliance data directly to your modules outside of a parameter mapping. This is useful if you have more advanced logic that is required to meet a particular internal requirement.

NOTE: The parser does not know what line number and, possibly, what file the function is being called from based on the version of the Puppet parser being used.

Global Options

If a Hash is passed as the only argument, then this will configure the global report settings.

The following options are supported:

:report_types

Default: [ 'non_compliant', 'unknown_parameters', 'custom_entries' ]

A String, or Array that denotes which types of reports should be generated.

Valid Types: full => The full report, with all other types included. non_compliant => Items that differ from the reference will be reported. compliant => Compliant items will be reported. unknown_resources => Reference resources without a system value will be reported. unknown_parameters => Reference parameters without a system value will be reported. custom_entries => Any one-off custom calls to compliance_map will be reported.

:site_data

Default: None

A valid Hash that will be converted as passed and emitted into your node compliance report.

This can be used to add site-specific or other information to the report that may be useful for post-processing.

:format

Default: 'json'

A String that indicates what output style to use. Valid values are 'json' and 'yaml'.

:client_report

Default: false

A Boolean which, if set, will place a copy of the report on the
client itself. This will ensure that PuppetDB will have a copy of the
report for later processing.

:server_report

Default: true

A Boolean which, if set, will store a copy of the
report on the Server.

:server_report_dir

Default: Puppet[:vardir]/simp/compliance_reports

An Absolute Path that specifies the location on
the *server* where the reports should be stored.

A directory will be created for each FQDN that
has a report.

:default_map

Default: None

The default map that should be used if no others can be found. This
will probably never be manually set during normal usage via the
compliance_markup module

:catalog_to_compliance_map

Default: false

A Boolean which, if set, will dump a compatible compliance_map of
*all* resources and defines that are in the current catalog.

This will be written to ``server_report_dir`` prefaced by the unique catalog ID.

NOTE: This is an experimental feature and subject to change without notice

Example:

Only non-compilant entries and only store them on the client and the

server

compliance_map({ :report_types => [ 'non_compliant', 'unknown_parameters', 'custom_entries' ], :client_report => true, :server_report => true })

Custom Content

The following optional ordered parameters may be used to add your own compliance data at any location:

:compliance_profile => 'A String, or Array, that denotes the compliance profile(s) to which you are mapping.' :identifier => 'A unique identifier String or Array for the policy to which you are mapping.' :notes => 'An optional String that allows for arbitrary notes to include in the compliance report'

Example: if $circumstance { compliance_map('nist_800_53','CCE-1234','Note about this section') ...code that applies CCE-1234... }

Puppet::Functions.create_function(:'compliance_markup::compliance_map') do

compliance_markup::compliance_map(Hash $map_data)

The compliance_markup::compliance_map function.

Returns: Nil

map_data

Data type: Hash

The full Hash of mapping data

compliance_markup::compliance_map(Variant[String[1], Array[String[1]]] $compliance_profile, Variant[String[1], Array[String[1]]] $identifiers, Optional[String[1]] $notes)

The compliance_markup::compliance_map function.

Returns: Nil

compliance_profile

Data type: Variant[String[1], Array[String[1]]]

Denotes the compliance profile(s) to which you are mapping

identifiers

Data type: Variant[String[1], Array[String[1]]]

A unique identifier for the policy to which you are mapping

notes

Data type: Optional[String[1]]

Allows for arbitrary notes to include in the compliance report

compliance_markup::enforcement

Type: Ruby 4.x API

Hiera entry point for the SIMP Compliance Engine

To activate this hiera backend, add the following to your hiera.yaml:

---
version: 5
hierarchy:
  - name: SIMP Compliance Engine
    lookup_key: compliance_markup::enforcement
    # All options are optional
    options:
      # Ignore all default data dirs and use these instead
      data_dirs:
        - /fully/qualified/data_dir
      # Add all items from these paths to the data sources
      # Stacks on both `data_dirs` and the inbuilt paths
      aux_paths:
        - /fully/qualified/path

Then, tell it what profile(s) to enforce by adding the following to your Hiera configuration for your target node(s):

---
# Enforce your custom company profile, then the STIG, then the NIST 800-53 Rev 4
compliance_markup::enforcement:
  - 'your_company_profile'
  - 'disa_stig'
  - 'nist_800_53:rev4'

compliance_markup::enforcement(String $key, Hash $options, Puppet::LookupContext $context)

Hiera entry point for the SIMP Compliance Engine

To activate this hiera backend, add the following to your hiera.yaml:

---
version: 5
hierarchy:
  - name: SIMP Compliance Engine
    lookup_key: compliance_markup::enforcement
    # All options are optional
    options:
      # Ignore all default data dirs and use these instead
      data_dirs:
        - /fully/qualified/data_dir
      # Add all items from these paths to the data sources
      # Stacks on both `data_dirs` and the inbuilt paths
      aux_paths:
        - /fully/qualified/path

Then, tell it what profile(s) to enforce by adding the following to your Hiera configuration for your target node(s):

---
# Enforce your custom company profile, then the STIG, then the NIST 800-53 Rev 4
compliance_markup::enforcement:
  - 'your_company_profile'
  - 'disa_stig'
  - 'nist_800_53:rev4'

Returns: Any The discovered value or Undef if not found

key

Data type: String

The key to look up in the backend

options

Data type: Hash

Required by Hiera

context

Data type: Puppet::LookupContext

The context in which the Hiera backend is being called

compliance_markup::loaded_maps

Type: Ruby 4.x API

Returns the compliance data keys from the loaded compliance maps

compliance_markup::loaded_maps()

Returns the compliance data keys from the loaded compliance maps

Returns: Nil

• Wed Feb 14 2024 Steven Pritchard steve@sicura.us - 3.8.1

• Remove use of legacy facts for Puppet 8 compatibility

• Mon Oct 23 2023 Steven Pritchard steve@sicura.us - 3.8.0

• [puppetsync] Add EL9 support

• Wed Oct 11 2023 Steven Pritchard steve@sicura.us - 3.7.0

• [puppetsync] Updates for Puppet 8
  • These updates may include the following:
    • Update Gemfile
    • Add support for Puppet 8
    • Drop support for Puppet 6
    • Update module dependencies

• Tue Sep 05 2023 Steven Pritchard steve@sicura.us - 3.6.0

• Updates for Puppet 8
  • Fixes for Ruby 3
  • Add explicit support for Puppet 8
• Drop support for Puppet 6
• Add support for stdlib 9

• Wed Aug 23 2023 Steven Pritchard steve@sicura.us - 3.5.0

• Add AlmaLinux 8 support

• Mon Jul 17 2023 Chris Tessmer chris.tessmer@onyxpoint.com - 3.4.0

• Add RockyLinux 8 support

• Tue Mar 14 2023 Garrett Adams garrett@sicure.us - 3.3.1

• Change enforcement tolerance to be nil if not specified, by default. nil will ignore any remediation/disabled checks.

• Thu Feb 16 2023 Garrett Adams garrett@sicure.us - 3.3.0

• Add tolerance as hiera lookup. Confine checks that can be enforced based on the tolerance setting.

• Fri Jun 03 2022 Mike Riddle mike@sicure.us - 3.2.3

• Updated reporting to account for escaping knockout prefixes

• Fri May 20 2022 Trevor Vaughan trevor@sicura.us - 3.2.2

• Allow for escaping knockout prefixes in strings to preserve leading -- entries

• Wed Mar 02 2022 Mike Riddle mike@sicura.us - 3.2.2

• Updated confines to allow for negative matches using the '--' prefix

• Sun Feb 13 2022 Trevor Vaughan trevor@sicura.us - 3.2.1

• Added support for Amazon Linux 2

• Tue Jun 15 2021 Chris Tessmer chris.tessmer@onyxpoint.com - 3.2.0

• Removed support for Puppet 5
• Ensured support for Puppet 7 in requirements and stdlib

• Mon Jun 14 2021 Steven Pritchard steven.pritchard@onyxpoint.com - 3.2.0

• Add compliance_markup::debug::profiles and compliance_markup::debug::compliance_data keys

• Wed May 19 2021 Trevor Vaughan tvaughan@onyxpoint.com - 3.1.6

• Ensure that the same context scope is called throughout the compliance_mapper enforcement

• Wed Apr 21 2021 Trevor Vaughan tvaughan@onyxpoint.com - 3.1.5-0

• Ensure that using a string for 'compliance_markup::enforcement' will not cause the server to hang
• Fix data recursion issues

• Wed Apr 21 2021 Steven Pritchard steven.pritchard@onyxpoint.com - 3.1.5-0

• Fix and document compliance_markup::debug::dump and compliance_markup::debug::hiera_backend_compile_time keys
• Bump puppetlabs-stdlib dependency to allow version 7

• Wed Feb 24 2021 Steven Pritchard steven.pritchard@onyxpoint.com - 3.1.4-0

• Refactor list_puppet_params to avoid excessive looping
• Disable caching (SIMP-9623)

• Mon Nov 02 2020 Andy Adrian andy.adrian@onyxpoint.com - 3.1.4-0

• Remove unused and broken telemetry functionality
• Updated the REFERENCE.md
• Removed EL 6 from support due to EOL
• Added puppet 7 testing

• Mon Nov 02 2020 Steven Pritchard steven.pritchard@onyxpoint.com - 3.1.3-0

• Add missing nil check when merging controls, identifiers, and oval-ids
• Add warn and debug in outer begin block to avoid silent failures

• Mon Oct 05 2020 Andy Adrian andy.adrian@onyxpoint.com - 3.1.2-0

• Change order of import on compliance_markup::compliance_map so Hiera has precedence.
• This means that users may now override all settings from the underlying compliance maps across all modules to fit their environment specifics.

• Wed Sep 16 2020 Steven Pritchard steven.pritchard@onyxpoint.com - 3.1.1-0

• Add tests for profile merging
• Deduplicate profile, control, ce, and check names in enforcement tests to avoid cross-contamination of test data
• Remove useless loops in list_puppet_params function
• Fix calls to deep_merge!
• Fix logic for merging oval-ids, controls, and identifiers
• Add begin/rescue blocks around merges to avoid problems with incorrect data

• Fri Sep 11 2020 Steven Pritchard steven.pritchard@onyxpoint.com - 3.1.1-0

• Add controls, identifiers, and oval-ids
• Work around rspec failure
• Apply confinement before merging values
• Ignore undefined ces when correlating checks and profiles

• Mon Jun 22 2020 Steven Pritchard steven.pritchard@onyxpoint.com - 3.1.0-0

• Deep merge hash values in the Hiera backend
• Reduce the amount of data passed around in the Hiera backend

• Fri May 29 2020 Steven Pritchard steven.pritchard@onyxpoint.com - 3.1.0-0

• Support confinement in profiles, controls, and ces (as well as checks)
• Add rspec tests for compliance_markup::enforcement

• Mon Apr 13 2020 Trevor Vaughan tvaughan@onyxpoint.com - 3.1.0-0

• Add EL8 support
• Ensure that the Hiera backend recurses as little as possible to improve performance.
• Remove all support for v1 data since it was experimental and removed in 3.0.0
• Removed the deprecated (experimental) Hiera v3 backend
• Removed the deprecated Puppet 3 function

• Fri Apr 10 2020 Steven Pritchard steven.pritchard@onyxpoint.com - 3.1.0-0

• Support arrays of potential matches in confinement blocks
• Support structured facts in confinement

• Wed Aug 21 2019 Trevor Vaughan tvaughan@onyxpoint.com - 3.0.2-0

• Update confinement logic to ensure that all possibilities are collected
• Add debugging logs to enforcement logic
• Raise errors on malformed data
• Increase supported simp/simplib version to < 5

• Mon Aug 12 2019 Robert Vincent pillarsdotnet@gmail.com - 3.0.2-0

• Support puppetlabs/stdlib 6.x.

• Fri Aug 09 2019 Dylan Cochran dylan.cochran@onyxpoint.com - 3.0.1-0

• Add confinement on modules and facts to SIMP Compliance Engine.

• Wed Aug 07 2019 Trevor Vaughan tvaughan@onyxpoint.com - 3.0.0-0

• Converted the compliance_map function to a Puppet 4 function called compliance_markup::compliance_map()
• The old puppet 3 function is deprecated and will be removed in the 3.1.0-0 release of this module
• Make the 'timestamp' in the client-side report optional to prevent puppet from triggering file resource changes every time
• Remove the experimental v1 data since it is no longer used
• Remove partial v2 data sets
• Add v2 data for the non-SIMP yum module

• Fri Jun 28 2019 Trevor Vaughan tvaughan@onyxpoint.com - 2.5.0-0

• Fix compliance markup validation for Defined Types

• Tue Jun 25 2019 Trevor Vaughan tvaughan@onyxpoint.com - 2.4.5-0

• Fix call to Hiera.warn in the compliance mapper

• Mon Jun 24 2019 Trevor Vaughan tvaughan@onyxpoint.com - 2.4.4-0

• Revert change from dir to File.dirname(FILE) in compliance_map.rb due to discovered incompatibility with some puppetserver configurations.
• Add log statement if invalid JSON or YAML files are found when loading.
• Remove management of simp::sssd::client::ldap_domain from the mappings since use of LDAP is not guaranteed.

• Tue Jun 11 2019 Trevor Vaughan tvaughan@onyxpoint.com - 2.4.3-0

• Fix Puppet 6 support in the compliance_map function
• Dropped Puppet 4 support
• Fixed bug in the compliance report functionality that did not correctly record the percent compliant in each report summary

• Tue Mar 12 2019 Trevor Vaughan tvaughan@onyxpoint.com - 2.4.2-0

• Fix bug in Array merging

• Thu Mar 07 2019 Liz Nemsick lnemsick.simp@gmail.com - 2.4.2-0

• Update the upper bound of stdlib to < 6.0.0

• Tue Mar 05 2019 Steven Pritchard steven.pritchard@onyxpoint.com - 2.4.2-0

• Compliance_map_migrate improvements
  • Merge values from multiple input files.
  • Make 'check_header' consistent with other v2 data.
  • Reorder output to match other v2 data.
  • Fix controls, oval-ids, and identifiers output.
  • Normalize identifier strings.
  • Add option to supply confinement.
  • Use a strange YAML incantation to avoid anchors in the output.
  • Add option to append a string to the checks key.
  • Add additional helper scripts for v1 to v2 migration.

• Fri Nov 02 2018 Steven Pritchard steven.pritchard@onyxpoint.com - 2.4.1-0

• Fix the following keys:
  • simp::mountpoints::tmp::secure
  • simp::root_user::manage_group
  • simp::root_user::manage_perms
  • simp::root_user::manage_user
  • ssh::server::conf::pki

• Wed Oct 31 2018 Steven Pritchard steven.pritchard@onyxpoint.com - 2.4.1-0

• Fix the output of utils/compliance_map_migrate

• Fri Oct 19 2018 Liz Nemsick lnemsick.simp@gmail.com - 2.4.1-0

• Fixed the following incorrect parameter types
  • simp::yum::schedule::minute
  • simp::yum::schedule::hour

• Thu Sep 20 2018 Dylan Cochran dylan.cochran@onyxpoint.com - 2.4.0-0

• Open-Source SCE version 2.0
  • Add bugfix for environments that are just Strings vs Environment objects.
  • Add compliance_markup::loaded_maps() function to return all of the loaded compliance data from the puppetserver for debugging
  • Add compliance_markup::telemetry() function to return filenames used to load compliance data
  • Add compliance_markup::debug::dump hiera parameter that dumps the cached result hash for hiera debugging.
  • Remove pupmod::ca_crl_pull_interval from nist_800_53_rev4.json's since the parameter is deprecated.
  • refactor loader to look in:
    • "/SIMP/compliance_profiles"
    • "/simp/compliance_profiles" and for backwards compatbility:
    • "/lib/puppetx/compliance"

• Fri Aug 24 2018 Trevor Vaughan tvaughan@onyxpoint.com - 2.3.4-0

• Change 'sudosh' to 'tlog' to support the switch to supported session logging software
• Added support for Puppet 5 and OEL
• DISA STIG changes:
  • Added selinux::login_resources
  • Added gdm::settings
  • Added gdm::banner
  • Added gdm::simp_banner
  • Added gdm::dconf_hash
  • Added gnome::dconf_hash

• Thu Jun 28 2018 Liz Nemsick lnemsick.simp@gmail.com - 2.3.4-0

• DISA STIG changes:
  • Updated for pupmod-simp-auditd 8.0.0. This enforces the 'stig' audit profile, instead of the 'simp' audit profile.

• Mon Jun 11 2018 Nick Miller nick.miller@onyxpoint.com - 2.3.4-0

• DISA STIG changes:
  • Added auditd::config::audit_profiles::simp::audit_crontab_cmd
  • Added auditd::config::audit_profiles::simp::audit_pam_timestamp_check_cmd
  • Added auditd::config::audit_profiles::simp::audit_passwd_cmds
  • Added auditd::config::audit_profiles::simp::audit_postfix_cmds
  • Added auditd::config::audit_profiles::simp::audit_priv_cmds
  • Added auditd::config::audit_profiles::simp::audit_ssh_keysign_cmd

• Wed Jun 06 2018 Chris Tessmer chris.tessmer@onyxpoint.com - 2.3.4-0

• DISA STIG changes:
  • Added auditd::config::audit_profiles::simp::audit_session_files
  • Added auditd::config::audit_profiles::simp::audit_session_files_tag

• Wed Jun 06 2018 Liz Nemsick lnemsick.simp@gmail.com - 2.3.4-0

• DISA STIG changes:
  • Added auditd::action_mail_acct entries
  • Added auditd::config::audit_profiles::simp::audit_sudoers
  • Added auditd::config::audit_profiles::simp::audit_selinux_cmds
  • Added auditd::failure_mode
  • Corrected auditd::enable identifiers

• Fri May 18 2018 Jeanne Greulich jeanne.greulich@onyxpoint.com - 2.3.4-0

• Added postfix main.cf settings to el7 DISA STIG.

• Wed May 16 2018 Liz Nemsick lnemsick.simp@gmail.com - 2.3.4-0

• Added aide::aliases entries for DISA STIG
• Replaced OBE simp::yum::enable_auto_updates entries with simp::yum::schedule::enable in all profiles
• Added and updated simp::yum::schedules entries for DISA STIG
• Added simp::sysctl entries to the DISA STIG profiles for net.ipv4.conf.default.accept_source_route, net.ipv4.conf.default.send_redirects, and net.ipv6.conf.all.accept_source_route.

• Fri May 04 2018 Jeanne Greulich jeanne.greulich@onyxpoint.com - 2.3.4-0

• Added and updated ssh::server::conf entries for DISA STIG

• Mon Apr 30 2018 Trevor Vaughan tvaughan@onyxpoint.com - 2.3.4-0

• Added 'svckill::mode' to be 'enforcing' in STIG and 800-53 modes

• Fri Apr 27 2018 Liz Nemsick lnemsick.simp@gmail.com - 2.3.4-0

• Fixed the inappropriate value of useradd::useradd::inactive in the DISA STIG profiles. It is now set to 0.

• Fri Mar 30 2018 Trevor Vaughan tvaughan@onyxpoint.com - 2.3.4-0

• Update PAM settings in the disa_stig profile
• Fixed issues with the compliance_map logic that were causing false results to be added to the 'documented_missing_parameters' and 'documented_missing_resources' lists

• Tue Mar 06 2018 Liz Nemsick lnemsick.simp@gmail.com - 2.3.3-0

• Updated TMOUT setting in /etc/profile.d/simp.sh to match EL7 STIG setting (Reference: RHEL-07-040160)
• Added missing audispd program to simp_rsyslog::default_logs
• Added missing ' IPT:' message start to simp_ryslog::default_logs. This is required for iptables violation messages because some versions of rsyslog add a space separating the message timestamp/id and the message.

• Wed Dec 13 2017 Nick Markowski nicholas.markowski@onyxpoint.com - 2.3.3-0

• Further aligned the EL7 disa_stig profile with scap-security-guide 0.1.33-5
  • Added oval-ids to map puppet parameters to openscap tests and SIMP remediations. Note this mapping is NOT complete.
• See simp/doc for a policy evaluation response report for CentOS 7
  • Includes remedies and justifications to address failures in the openscap scan

• Wed Nov 15 2017 Trevor Vaughan tvaughan@onyxpoint.com - 2.3.3-0

• Aligned the EL7 disa_stig profile with the latest SSG content
• Fixed several parameters with incorrect data types

• Mon Oct 03 2017 Dylan Cochran dylan.cochran@onyxpoint.com - 2.3.2-0

• Fix discrepancies between NIST and DISA compliance profiles

• Fri Sep 22 2017 Dylan Cochran dylan.cochran@onyxpoint.com - 2.3.1-0

• Refactor report generator to use a shared file format parser/compiler.
• Add vendored 'profiles-in-modules' support

• Tue Sep 19 2017 Liz Nemsick lnemsick.simp@gmail.com - 2.3.1-0

• Remove test link to allow module to be published to PuppetForge

• Tue Sep 05 2017 Lucas Yamanishi lucas.yamanishi@onyxpoint.com - 2.3.0-0

• Converted compliance profiles to JSON. This allows non-string values and faster deserialization.
• Provided scripts in 'utils/' to convert the compliance profiles from YAML to JSON and vice versa.

• Mon Jun 16 2017 Dylan Cochran dylan.cochran@onyxpoint.com - 2.2.0-0

• Added a compliance enforcement hierav3 and hierav5 backend.

• Sat Jun 10 2017 Trevor Vaughan tvaughan@onyxpoint.com - 2.1.0-0

  • Documented the report format in the README
  • Added the defaut SIMP compliance profiles to the module data
  • Enhanced the lookup mapper function to take an optional default map
  • Passed the internal data as the default map
  • Added client metadata to the compliance report for easier analysis
  • Fixed several minor processing bugs
  • Added the documented, but missing, regular expression match capability
  • Confine puppet version in metadata.json

• Tue Feb 28 2017 Nick Miller nick.miller@onyxpoint.com - 2.0.1-0

  • travis.yml and gemfile updates

• Fri Oct 28 2016 Trevor Vaughan tvaughan@onyxpoint.com - 2.0.0-0

  • New map format
  • New output format
    • Added compliant values
    • Added missed parameters
    • Added missing class references
    • Added server-side storage
  • Added a conversion utility in the 'utils' directory

• Wed Sep 28 2016 Chris Tessmer ctessmer@onyxpoint.com - 1.0.1-0

  • Move GitHub org from onyxpoint to simp

• Sun Jul 03 2016 Chris Tessmer ctessmer@onyxpoint.com - 1.0.0-0

  • Move Forge org from onyxpoint to simp
  • Provide Ruby 1.8.7 compatibility
  • Ensure that a report is written on every run.
  • Updated to properly handle the hash references

• Mon Dec 07 2015 Trevor Vaughan tvaughan@onyxpoint.com - 0.0.1-0

  • Initial Release