Sicura Enterprise Edition
  1. Introduction
  2. Licensing
  3. Installing Sicura Enterprise
  4. Server install from RPM
  5. Server install from ISO
  6. Upgrade Sicura Enterprise
  7. Server Installation via Control Repo
  8. Enable SIMP Compliance Engine
  9. Configure SIMP Compliance Engine
  10. Included Compliance Profiles
  11. Console install via Puppet
  12. Agent Install via Puppet
  13. Simp-downloader script Reference
  14. Coverage - CIS, Windows
  15. Coverage - CIS, Linux
  16. Coverage - CMMC, Windows
  17. Coverage - CMMC, Linux
  18. Coverage - DISA, Windows
  19. Coverage - DISA, Linux
  20. Coverage - NIST 800-171 r2, Windows
  21. Linux DISA Module Usage
  22. Windows CIS module usage
  23. Linux CIS Module Usage
  24. Linux SSG Module Usage

Linux CIS Module Usage


There are a few items that the user must configure to fully comply with the CIS benchmarks since there is no method for automatically determining the appropriate values.

Disk Partitioning

The SIMP ISO installation will appropriately configure the disk per the CIS requirements. Alternatively, the kickstart files provided as templates by the SIMP project can be used to kickstart a system.

If neither of these options are chosen, the user will need to set the partitions appropriately.

Package Management

CIS requires that package manager repositories are configured and that services such as rhnsd are disabled if they are not in use. SIMP will not manage these items since there are no reasonable defaults.

Package Updates

CIS requires that all security patches be applied to a system. SIMP makes no assumptions about the connectivity to a given set of repositories or the appropriateness of applying any given updates to your system.

That said, nightly updates are enabled via the simp::yum::schedule class and will update all packages to the latest version based on whatever repositories are present and configured on the system at that time.

High I/O Activities

Some checks that require scanning the entire filesystem (such as checking for incorrect permissions) would put a generally unacceptable load on the system in order to remediate at each run of Puppet. Users are encouraged to scan their systems regularly to find and address these kinds of issues.

If a suitable lightweight mechanism can be found to address this issue in the future, it will be added to the SIMP module space.

iptables OUTPUT DROP

The CIS benchmark requires users to set the default OUTPUT iptables chain to DROP by default.

This is not set by this module since it causes all outbound communication to cease and there is no method for determining what access should be reasonably allowed by default.

To bring your system into compliance, set the following via Hiera:

iptables::rules::default_drop::filter_output: true

Graphical Display

The CIS benchmark indicates that no X11 packages should be installed if you do not require an actual graphical system display. There is unfortunately, no good method to determine exactly which packages are part of a required installation and which are needed by other applications as part of their dependency chain. As such, users should start with the default SIMP installation (no GUI) and then use the simp-gnome and simp-gdm modules to add a GUI to their system as required.

In fact, a CIS-CAT scan may fail this check due to the requirement of X11 font libraries by Java which is needed by CIS-CAT itself.

Remote Rsyslog Configuration

Given that there is no way to know where and/or if a syslog server may be present on the network, there are no remote syslog servers configured by default.

To bring your system into compliance, set the following via Hiera:


To set failover log servers, set the following via Hiera:


Limit SSH Access

While SSH access is limited by default via PAM, the CIS benchmarks want the SSH user and group restrictions to be present in the SSH configuration directly. SIMP is unable to define a reasonable set of defaults for these items and made redundant by PAM.

To bring your system into compliance, set the following via Hiera:

  - group1
  - group2

  - user1
  - user2

Yum repo_gpgcheck Configuration

CIS requires that repo_gpgcheck=1 be present in /etc/yum.conf. This could have a negative impact on the functionality of both CentOS and RHEL yum repositories. Often times after applying this parameter several repos will begin to throw errors like the following in RHEL/Centos 7 systems:

https://[repo_location]/repodata/repomd.xml.asc: [Errno 14] HTTPS Error 404 - Not Found

And errors like the following in RHEL/Centos 8 systems:

Error: Failed to download metadata for repo '[reponame]': GPG verification is enabled, but GPG signature is not available. This may be an error or the repository does not support GPG verification: Status code: 404 for https://[repo_location]/repodata/repomd.xml.asc

To work around this issue, set the following via Hiera:

  repo_gpgcheck: false

This will cause a failure in the scans for the system, however, the repositories should begin working as expected again.