Business Rules for Configuration Management
CMS has established the following business rules for governing CM activities within the CMS environments.
BR-CM-1: Projects Must Produce a Configuration Management Plan
In compliance with the CMS CM Policy, CMS requires the development, tailoring, and use of configuration management plans that describe the CM roles, responsibilities, and activities to meet the needs of specific CMS projects.
Related CMS ARS Security Controls include: CM-09 - Configuration Management Plan.
Rationale:
A CM plan documents the roles, responsibilities, and activities that the project will conduct in order to ensure that all configuration items are baselined and managed accordingly. Having a plan ensures that all participants understand their roles in the process.
The CM plan can also provide guidance for how to conduct activities. For example, the CM plan could explain how software CI’s would be stored in the CMS GitHub, documents are stored in Confluence, and hardware assets are to be managed in Chef. In this instance the CMDB is collectively GIT, a Wiki, and a Chef repository. Each CI should be managed in an appropriate configuration management tool, collectively known as a Configuration Management Database (CMDB).
The CM Plan can be maintained in a standalone document, a set of wiki pages, or document management system. It should be easily accessible by team members to increase communication and promote transparency.
BR-CM-2: Projects Must Identify Items to Be Placed under Configuration Control
Projects must identify and baseline all items placed under CM control. CM items considered for baseline control must be important project artifacts that are subject to change during system development and operation, and include:
- Charters and policies
- Project schedules and budgets
- Business and technical requirements
- System, subsystem, and product interfaces
- Architectural, hardware and software designs
- Developed code
- Hardware infrastructure documentation
- Test artifacts
- Critical security items, including security settings
- Media assets (e.g., video, audio, and images)
- Software configuration settings
- Service dependencies
- Trouble Tickets or Issues
Related CMS ARS Security Controls include: CM-03 - Configuration Change Control.
Rationale:
Identifying CIs is the process of identifying important, durable assets needed for the lifecycle of a project and system. Temporary assets would not typically be identified as configuration items. For example, most logs are not configuration items. The contents of a database are not a configuration item. The database engine configuration, on the other hand, is a CI. A rule of thumb is to consider any item produced by a human as a CI. Accordingly, if it is the output of an automated process, it is generally not a CI. Thus, a source file is a CI, but an object file (i.e., build output) is not.
Once CIs are identified, they are ready to be managed. Management simply means tracking changes to the item and being able to readily know its state.
With the advent of “Infrastructure As Code,” the ability to manage IT infrastructure such as systems and devices has been greatly improved. In most cases, a CI can be represented a set of one or more files. Baselining these CIs becomes a simple application of version control.
BR-CM-3: Significant Changes to Configuration Items of a System or Component Managed by a CCB Requires the Approval of That CCB
Configuration Control Boards establish baselines on those items under CCB control. Once established, CCBs manage and control changes to the controlled items. CMS formally charters its CCBs with specific thresholds for their change approval authority.
BR-CM-4: Projects Must Maintain Accurate and Reliable CI Information
Projects are responsible for tracking the configuration status of the CI’s that were identified and baselined. This includes status of proposed changes and the implementation of approved changes. Projects must use persistent repositories, known collectively as a configuration management database (CMDB), for storing up-to-date and accurate configuration information. The repositories must include audit trails because projects must be prepared to provide status on CM activities to project staff, senior program management, CMS Security, and CMS auditors.
Related CMS ARS Security Controls include: CM-08- Information System Component Inventory.
Rationale:
Maintaining accurate and reliable information on CIs critical to managing assets. Modern configuration management software can be configured to provide such information on demand. However, it is responsibility of the project team to ensure that CIs and associated metadata (such as AWS or Git tags) are accurate and verifiable.
BR-CM-5: Projects Must Conduct Periodic Audits of CM Activities and Products
Conduct audits on CM activities to verify compliance to both the project-specific configuration management plan and the CMS Risk Management Handbook (RMH) Chapter 5: Configuration Management, processes, and procedures. Audits must identify discrepancies to project leadership.
Related CMS ARS Security Controls include: CM-05 - Access Restrictions for Change and
CM-06 - Configuration Settings.
Rationale:
Security CM audits must be conducted by authorized security audit personnel in accordance with the policies and procedures established in the CMS Risk Management Handbook. Frequency of audits needs to be defined as part of the Configuration Management Plan. Without audits to verify that the expected configuration matches the actual, it is possible for project assets to be unknowingly misidentified or unidentified. Conducting audits, reviewing, and addressing the results ensures that baseline information is accurate, enabling confidence in both business and technical decisions.
BR-CM-6: Projects Must Maintain Configuration Baselines
Project develops, documents, and maintains under configuration control, a current baseline configuration of the information system. Project must establish baseline configurations for information systems and system components, including communications and connectivity-related aspects of systems.
Related CMS ARS Security Controls include: CM-02 - Baseline Configuration and CM-03 - Configuration Change Control.
Rationale:
Baseline configurations are documented, reviewed, and agreed-upon sets of specifications for information systems or configuration items within those systems. Baseline configurations serve as a basis for future builds, releases, and/or changes to information systems. Baseline configurations include information about information system components. Baselines are typically specific to the configuration management system used to manage configuration items.
For example, in Git, a baseline is a tag or commit id since either of these can uniquely identify a set of software configuration items (i.e. source code, files, etc.)
One measure of successful baselining is the ability to reliably reproduce a system’s configuration, quickly and accurately, using only that information which is baselined. In other word, reproducibility depends only on CIs.
BR-CM-7: Follow the CMS ARS Hierarchy for Security Configuration
The CMS ARS Security Control CM-6 1 (b) provides the authoritative CMS hierarchy for applying security configuration guidelines. Apply this standard across all CMS systems and devices.
Related CMS ARS Security Controls include: CM-6 - Configuration Settings
Rationale.
The CMS ARS Security Control CM-6 1 (b) provides the authoritative CMS hierarchy for applying security configuration guidelines. This ensures that CMS systems and devices are hardened at a minimum according to the best available and applicable standards developed by Federal agencies and security organizations.