8.3. Operational Security

This chapter contains SIMP security concepts that are related to the operational security controls in NIST 800-53.

8.3.1. Configuration Management

This section describes the management of various configurations within SIMP. Baseline Configurations

SIMP baselines include configuration settings and Puppet modules. Currently supported baselines can be found in SIMP Community Edition (CE) 6.6.0.

Each configuration item that is managed by a Puppet module has an RPM installed on the Puppet Server 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 Server, which denotes the version number of SIMP that is installed. [CM-2 : BASELINE CONFIGURATION, CM-2 (2) : AUTOMATION SUPPORT FOR ACCURACY / CURRENCY, CM-2 (3) : RETENTION OF PREVIOUS CONFIGURATIONS, CM-6 : CONFIGURATION SETTINGS]

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) : AUTHORIZED SOFTWARE]

  • 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. 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 syslog. [CM-3a., CM-3 (3) : AUTOMATED CHANGE IMPLEMENTATION]

Linux systems are made up of hundreds of configuration files that can contain numerous 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 : CONFIGURATION SETTINGS] 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 : CONFIGURATION SETTINGS, SI-2 : FLAW REMEDIATION, SI-2 (1) : CENTRAL MANAGEMENT, SI-2 (4) : AUTOMATED PATCH MANAGEMENT TOOLS]:

  • Puppet:

    • Apply a configuration change to files that are managed by Puppet.

  • rsync:

    • Use this mechanism to deliver a file to a client. This can be used with or without Puppet to synchronize files.

  • YUM:

    • 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.

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 : SECURITY FUNCTION VERIFICATION] 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 rsync.

Both the ClamAV and McAfee modules provide a method to run a scan via cron on a customer scheduled basis. [SI-3 : MALICIOUS CODE PROTECTION]

SIMP also comes with the chkrootkit tool to check for rootkits. The tool runs as a cron job and places its output into syslog. [SI-3 : MALICIOUS CODE PROTECTION] 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 Server may not have the ability to retake control over that client. However, the Puppet Server 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 : SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY, SI-7 (1) : INTEGRITY CHECKS, SI-7 (2) : AUTOMATED NOTIFICATIONS OF INTEGRITY VIOLATIONS, SI-7 (3) : CENTRALLY-MANAGED INTEGRITY TOOLS]

8.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 maintenance. [MA-4 : NONLOCAL MAINTENANCE, MA-4 (1) : AUDITING AND REVIEW, MA-6 : TIMELY MAINTENANCE]

8.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. [IR-1 : INCIDENT RESPONSE POLICY AND PROCEDURES]

8.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.

8.3.5. System Backup and Recovery

SIMP does not directly support any particular backup and recovery product. Solutions vary widely, and should be determined as part of an implementation’s broader contingency plan. SIMP provides mechanisms that might be used to support backup and recovery procedures.

Administrators seeking FOSS software to implement backup and recovery solutions may be interested in products such as Bacula, BackupPC, duplicity, and scat.