6.3. Operational Security¶
This chapter contains SIMP security concepts that are related to the operational security controls in NIST 800-53.
6.3.1. Configuration Management¶
This section describes the management of various configurations within SIMP.
22.214.171.124. Baseline Configurations¶
SIMP baselines include configuration settings and Puppet modules. Currently,
baselines are maintained for both Red Hat/CentOS 6.x, and Red Hat/CentOS 7.x.
Each configuration item that is managed by a Puppet module has an RPM installed
on the Puppet Master in the form of
pupmod-name-x.x.x-x. This process
allows for one main SIMP baseline to be maintained and modules to be upgraded
easily. An overall SIMP RPM is also installed on the Puppet Master, which
denotes the version number of SIMP that is installed.
[CM-2, CM-2 (2), CM-2 (3), CM-6]
SIMP installs a minimal set of RPM packages, which can be found in the kickstart files on the ISO. RPMs, services, and IPTables rules all use a whitelist stance for allowing access or installation. [CM-2 (5)]
- Additional RPMs must be installed by each implementation.
- Services must be declared explicitly or they will be disabled by Puppet
- IPTables rules must allow a service explicitly.
126.96.36.199. Managing Configuration Changes¶
Configuration change approvals are managed by each implementation; SIMP only
provides the mechanisms to apply changes on clients. A combination of Puppet,
rsync, and YUM is used to apply those changes across any number of
target Puppet clients. All changes made are audited with
auditd or are
logged to via
[CM-3a., CM-3 (3)]
Linux systems are made up of hundreds of configuration files that can contain numerous of settings. SIMP does not make an attempt to manage all of the settings in every file. Instead, critical operating system files or files that need to be controlled centrally are managed. Implementations can manage additional files if they are deemed necessary. [CM-6]
188.8.131.52. Security Verification and Flaw Remediation¶
SIMP cannot detect flaws automatically; each implementation is responsible for tracking flaws. However, SIMP provides a way for flaws to be fixed across all clients. One or all of the following can help automate flaw remediation [CM-6, SI-2, SI-2 (1), SI-2 (4)]:
- Apply a configuration change to files that are managed by Puppet.
- Use this mechanism to deliver a file to a client. This can be used with or without Puppet to synchronize files.
- Update packages nightly with YUM. Placing an updated package in YUM and running a YUM update manually, or allowing time for the cron job to run, will ensure packages on all clients are updated. Otherwise, a cron job will perform a daily update of packages with YUM.
- Allow users to execute specific commands across large numbers of nodes in an auditable, distributed, and scalable, fashion.
The extent of security verification that is performed currently is based on changes to files that Puppet or the Advanced Intrusion Detection Environment (AIDE) provides. There are also Security Content Automation Protocol (SCAP) profiles available from the SCAP-Security-Guide project that check security configuration settings. [SI-6]
184.108.40.206. Malicious Code Protection¶
For most environments, SIMP will use ClamAV to protect against malicious code.
Rsync is used to push out new definitions, which should be updated by the local
administrator regularly. SIMP also comes with a
mcafee::uvscan module that
manages an installation of uvscan, if it is preferred. The module can configure
.dat file updates to occur over
Both the ClamAV and McAfee modules provide a method to run a scan via cron on a customer scheduled basis. [SI-3]
SIMP also comes with the
chkrootkit tool to check for rootkits. The tool
runs as a cron job and places its output into syslog.
220.127.116.11. Software and Information Integrity¶
Unauthorized changes to a local client can be detected by Puppet or AIDE (for any file managed by Puppet). In the event that a managed file is changed locally, Puppet will revert the file back to its original state. It is important to note that this is a function of Puppet and is intended to be more of a configuration management feature rather than a security feature. If a Puppet client has been compromised, the Puppet Master may not have the ability to retake control over that client. However, the Puppet Master can configure all other nodes to deny traffic from the compromised node if they are configured by the administrator to do so. There are additional configuration files that are checked by AIDE, which is triggered by a cron job. AIDE logs any detected file changes in syslog. Each implementation may add additional files that are managed by Puppet or watched by AIDE. The AIDE baseline database is updated periodically to handle the installation and updating of system RPMs and reduce false positives. [SI-7, SI-7 (1), SI-7 (2), SI-7 (3)]
6.3.2. Remote Maintenance¶
Remote maintenance can be performed on SIMP using SSH. Local
maintenance can be performed at the console or via serial port (if available).
SSH sessions are tracked and logged using the security features built into
SIMP. Console access requires someone to have access to the physical (or
virtual) console along with the
root password. Auditing of those actions
also occurs in accordance with the configured audit policy. It is up to the
implementer to decide how to distribute authentication information for remote
[MA-4, MA-4 (1), MA-6]
6.3.3. Incident Response¶
While Puppet is not intended to be a security product primarily, its features help provide security functionality such as dynamic reconfigurations and wide-scale consistent mitigation application. If an implementation chooses, they can leverage Puppet’s ability to reconfigure systems as part of incident response.
SIMP also delivers an MCollective infrastructure which can be used to rapidly query for system state or apply hotfixes in a scalable manner. [IR-1]
6.3.4. Contingency Planning¶
SIMP does not provide any direct support for contingency planning. Some of the mechanisms provided by SIMP might be used to support an implementation’s contingency plan.