Risk Management Handbook Chapter 5: Configuration Management (CM)

Introduction

This Handbook outlines procedures to help CMS staff and contractors implement the Configuration Management family of controls taken from the National Institute of Standards and Technology (NIST) Special Publication 800-53 and tailored to the CMS environment in the CMS Acceptable Risk Safeguards (ARS). For more guidance on how to implement CMS policies and standards across many cybersecurity topics, see the CMS Security and Privacy Handbooks. 

Configuration management has been applied to a broad range of information systems. Some basic terms associated with the configuration management discipline are briefly explained below.

A Baseline Configuration is a set of specifications for a system that has been formally reviewed and agreed on at a given point in time, and which can be changed only through change control procedures. The baseline configuration is used as a basis for future builds, releases, and/or changes.

A Configuration Management Plan (CM Plan) is a comprehensive description of the roles, responsibilities, policies, and procedures that apply when managing the configuration of products and systems. The basic parts of a CM Plan include:

• Configuration Control Board (CCB) – establishment of and charter for a group of qualified people with responsibility for the process of controlling and approving changes throughout the development and operation lifecycle of products and systems; may also be referred to as a change control board;
• Configuration Item Identification – methodology for selecting and naming configuration items that need to be placed under CM;
• Configuration Change Control – process for managing updates to the baseline configurations for the configuration items; and
• Configuration Monitoring – process for assessing or testing the level of compliance with the established baseline configuration and mechanisms for reporting on the configuration status of items places under CM.

This guideline is associated with the application of security-focused configuration management practices as they apply to information systems. The configuration of an information system is a representation of the system’s components, how each component is configured, and how the components are connected or arranged to implement the information system. The possible conditions in which an information system or system component can be arranged affect the security posture of the information system. The activities involved in managing the configuration of an information system include development of a configuration management plan, establishment of a configuration control board, development of a methodology for configuration item identification, establishment of the baseline configuration, development of a configuration change control process, and development of a process for configuration monitoring and reporting.

Configuration management of information systems involves a set of activities that can be organized into four major phases – Planning, Identifying and Implementing Configurations, Monitoring, and Controlling Configuration Changes. It is through these phases that CM not only supports security for an information system and its components, but also supports the management of organizational risk.

Configuration Management controls

Baseline Configuration (CM-2)

This control requires CMS to develop, document, and maintain under configuration control a current baseline configuration for each information system. Baseline configurations are documented, formally 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 (e.g., standard software packages installed on workstations, notebook computers, servers, network components, or mobile devices; current version numbers and patch information on operating systems and applications; and configuration settings/parameters), network topology, and the logical placement of those components within the system architecture.

The following steps detail the CMS specific process for initializing and maintaining an information system configuration baseline.

To develop and document initial configurations:

• Step 1:  The system owner with the support of the Change Control Board (CCB) identifies the configuration settings for their information system, device, appliance, or application using configuration settings standards in section 3.5 as part of the CMS-SDLC.
• Step 2: The System Developer and Maintainer documents the configuration settings chosen during Step 1 in the CMS Intake Form as part of the CMS-SDLC.

In order to maintain the configuration baseline, the Business Owner ensures the following is completed:

• Step 3:  The ISSO’s organization determines that the system requires a change. (See SA-3 and CM-9).
• Step 4:  The ISSO’s organization (or their designated System Maintainer) develops a high-level plan for how to accomplish the change (see SA-3, and SA-10).
• Step 5:  The ISSO’s organization (or their designated System Maintainer) reviews the Privacy Impact Assessment (PIA) and conducts a Security Impact Analysis (SIA, see CM-4 Security Impact Analysis) to identify the privacy and security impacts of their plan (see CM-4 and SA-3).
• Step 6:  The ISSO’s organization (or their designated System Maintainer) develops any applicable design requirements to mitigate the identified security impacts (see SA-3, SA-8, and SA-17).
• Step 7:  The ISSO’s organization (or their designated System Maintainer) develops testing requirements to ensure that the security impacts are verified as successfully mitigated (see CA-2 and SA-11).
• Step 8:  The ISSO’s organization (or their designated System Maintainer) builds out the system changes.
• Step 9:  The ISSO’s organization (or their designated System Maintainer) test, independently as required by CA-2(1) and CA-7(1)), the system changes using the security tests developed in step 5 (see AC-5.Std.5, CA-2, CM-3(2), CM-4(1), and SA-11).
• Step 10:  The ISSO’s organization (or their designated System Maintainer) develops and implements any Plans of Action and Milestones (POA&Ms) necessary to correct identified failures from testing (see CA-5).
• Step 11:  The ISSO applies either for a new Authorization To Operate (ATO), or for an ATO update (see CA-6).

Reviews and Updates (CM-2(1))

This enhancement requires CMS to review and update the baseline configuration of its information systems at a regularly defined frequency, when special circumstances arise, or when and information system component is installed or upgraded.  By defining and maintaining a baseline configuration for its information systems, CMS is supporting the cybersecurity concepts of least privilege and least functionality. In addition, the establishment of configuration baselines helps the organization recognize abnormal behavior as a sign of attack.

The table below outlines the CMS organizationally defined parameters (ODPs) for review and update of the baseline configuration for an information system.

To implement the CMS controls for reviewing and updating configuration baseline, the Information System Security Officer (ISSO) must first assign a security category in accordance with FIPS 199.

This procedure is outlined in RMH Chapter 12: Security & Privacy Planning, under control PL-2.  The category will assist the CCB with identifying adequate security controls and ensuring they are integrated into the configuration baseline of the information system. 

The CCB will review information system baseline configurations every 365 days for systems categorized “High” and every 1,095 days for systems categorized as “Moderate”. Other triggers outside of scheduled times for configuration baseline review are:

• Critical security patches to the system/component
• Upgrades to the system
• Emergency changes
• Major system changes or upgrades
• Information system component installations
• Updates to the governing standards

In addition, system developer and maintainers will have to update the documentation regarding the baseline configuration after an approval of changes. Updates must follow the same process stated above in CM-2.

Automation Support for Accuracy / Currency (CM-2(2))

CMS provides automation support whenever possible to information systems’ configuration baselines.  Automation support examples include hardware asset management systems, software asset management systems, and centralized configuration management software.  CMS uses automation of information gathering to support the continuous monitoring program and inventory systems.  Automation support captures the types of hardware and software on the network and the operating system or firmware on each device.

The goal is to keep track of what the configuration is on each system and to have the ability to go to an information system and collect configuration information automatically.  The automation keeps the data on systems configuration up-to-date, accurate, and available when it is needed.  With a current list of configurations, CMS can feed it into other processes that look for deviations from the baseline and configurations that are not up to organizational standards. It is worth noting the difference between a deviation and a waiver. A waiver is required when there is a departure from CMS or HSS policy and must be approved by the AO. A deviation is when the system will differ from established configuration standards and the reason why the deviation is occurring must be documented.

The following details the CMS specific process for incorporating automation to an information system.

• Step 1:  The system developer and maintainer configures the system architecture to allow automated hardware and software mechanisms provided by Continuous Diagnostics and Mitigation (CDM) to scan the system.
• Step 2: The system developer and maintainer configures the access controls, as needed, to allow automation support to have access to the information that it needs.
• Step 3: CMS Cybersecurity Integration Center (CCIC) runs automated mechanisms to gather hardware and software configurations as part of the Continuous Monitoring Program whose point of contact information is in Appendix G.

Retention of Previous Configurations (CM-2(3))

Retaining documentation of configuration information is the first step to the restoration in times of need. CMS will maintain at least one backup of the configuration for systems, system components, and information system services. The configuration information needed is used to restore a device, service, or software to a previous state. Related to CM-2(2), section 3.1.2 of this document, the automated gathering of configuration information can be used to collect the data. This backup should also be maintained, given that the configuration will change over time. The approval of changes in the configuration from the CCB should also be added to the configuration documentation to retain as a new version.

The retention of configuration information is in support of CMS as one of its goals to maintain availability of systems. A previous configuration could be used to replace current settings and processes to a former state. This former state should be an approved configuration that may increase risk, but maintain availability. For example, if there were a system that did not apply a critical security patch correctly causing a system failure, then restoring the previous configuration would restore the system to a functioning state (available) without the security protection of the patch (increased risk).

The configuration information can also be used when settings change with unintended consequences during system upgrades or replacements. The previous configuration can be restored using what is called a rollback procedure, which would implement the settings for a former state that is known to function properly.

The table below outlines the CMS organizationally defined parameter (ODP) for CM Retention of Previous Configurations.

The following details the CMS specific process for retaining configuration information of an information system:

The system developer and maintainer will determine the needs of the system to restore it back to a previous state. The information gathered can be a combination of settings, version numbers of software/firmware/hardware, access controls, connection information, or schematics. The importance of gathering the correct information is to ensure that the system will work using the previous configuration as stored. This previous configuration information must also be available in case of emergencies and must therefore be stored apart from the system itself to remain available if the system is offline. Additionally, configuration changes that are approved by the CCB must be added to the configuration baseline to ensure the up-to-date configurations are used for restoration. A minimum of one previous configuration is required for this control.

Because the retention process will be slightly different for every information system, the system developer and maintainer must document their process in their Configuration Management Plan (CMP).

Configure Systems, Components, or Devices for High-Risk Areas (CM-2(7))

This control guides CMS to create configurations and/or procedures for systems (laptops, iPhones, etc.) that are traveling to high-risk areas.  This control is for official travel, because unofficial/personal travel should not involve the transportation of Government Furnished Equipment (GFEs).  CMS employees traveling to high-risk areas should not travel with their permanently issued GFE but instead use an assigned loaner laptop from the designated laptop team.  The designation of high-risk countries can be found on the State Department’s website Travel to High-Risk Areas  Upon returning, CMS employees and contractors return their mobile devices to the SOC for a check of signs of physical tampering.  HHS guidance can be found here: https://intranet.hhs.gov/it/cybersecurity/policies/memo-gfe.html. Further guidance can be obtained from the HHS Office of Security and Strategic Information and from the Broadcast on Foreign Travel: Updated Foreign Travel Security Awareness Guidance (6/12/2017).

The table below outlines the CMS organizationally defined parameters (ODPs) for CM-2(7) Configure Systems, Components, or Devices for High-Risk Areas.

The following details the CMS specific process for handling systems components or devices for travel to a high-risk area.

• Step 1:  CMS Users traveling to foreign countries for official business notify the Office of Security and Strategic Information (OSSI) at least 30 days in advance of travel to arrange for a security briefing by email at international@cms.hhs.gov and follow the HHS Foreign Travel Checklist that is available here: https://intranet.hhs.gov/security/ossi-counterintelligence/foreign-travel-list.html
• Step 2: CMS Users traveling to foreign countries for official business notify the CMS International Team least 10 days in advance of travel to arrange for a security briefing by email at international@cms.hhs.gov
• Step 3: CMS Users notifies the Service Desk at least 10 days in advance of their travel in order to arrange for their travel laptop to conduct business on while abroad using the email cms_it_service_desk@cms.hhs.gov
• Step 4: CMS International Team checks the country against the Department of State travel advisories to determine the risk to the traveling CMS User here: https://travel.state.gov/content/passports/en/alertswarnings.html.  Then uses that information to decide the security awareness briefing that the User will receive.
• Step 5: CMS International Team notifies the Infrastructure & User Services Group about the connection of the GFE that the user will have while overseas.
• Step 6: CMS Deskside Support protects the travel computer using the FIPS 140-2 compliant encryption using the current full-disk encryption solution. (e.g. Checkpoint Endpoint Encryption)
• Step 7: The CMS International Team debriefs the User when they return.
• Step 8: CMS User returns the travel computer to CMS Deskside Support within two days of returning from travel before connecting it to the CMS network or system and does not attempt to transfer data when returning.

Configuration Change Control (CM-3)

Configuration change control implements the change control process for the information system, system component, or information system service. Management will determine which changes to the system need to be part of the change control process. There will also be employees assigned to the CCB to review and approve changes to the system, component or service. The CCB will take security considerations as part of the decision making process. Changes that are approved will need to be documented as a part of the process.  The documentation should include the decisions on the changes as well as the changes that are to be made.  The CCB should periodically audit and review the activities related to the changes that have been made to the applicable system, component or service. It should also meet often enough to accommodate the changes that are proposed.

The reason that change control is enacted is to reduce the impact of changes to the CIA of the data processed by the system.  The CCB can approve or disapprove of changes for a particular system so that there is no single person making changes to the system.  CMS wants to prevent or minimize risks that can occur as a result of unauthorized or uncoordinated changes.  This helps to separate the duties involved and adds an extra layer of security.  The documentation of changes can help to troubleshoot issues when systems malfunction and to audit the system for compliance to CMS rules and regulations. CMS uses configuration change control to maintain availability through changes that have to be tested and system integrity through audits and approvals for system changes.

The table below outlines the CMS organizationally defined parameters (ODPs) for CM Configuration Change Control.

The following, which is ensured by the Business Owner, details the CMS specific process for controlling changes to a CMS information system’s configuration.

• Step 1:  The Information System Security Officer (ISSO), System Owner (or designee) and the project manager writes a configuration management plan that includes the parts of the system (called configuration items or CIs) which are to be controlled under configuration management procedures.
• Step 2: The project/program manager further describes the process of how decisions are made in the CCB for guidance after members are assigned. This is documented in a Change Management Plan in alignment with the CMS-SDLC
• Step 3: The ISSO, System Owner (or designee) and the project manager create a CCB by assigning members and write a charter and operating procedures for the CCB. The CCB must have at least the system developer, Privacy Officer, ISSO (contractor/federal), maintainer, and a member of the information system support staff assigned.
• Step 4: The CCB coordinates and oversees configuration control activities. They review change requests (CRs) and should meet often enough to appropriately handle the reviews in a timely manner throughout the life cycle from requirements analysis to disposition.  The reviews should produce an approval or disapproval that is recorded via the method in Section 4 of the relevant Change Management Plan.  The decision should take into account a Security Impact Analysis (SIA), as outlined in CM-4, from the ISSO.  They should monitor the status of proposed changes ensuring that only approved changes are applied. 
• Step 5: The system developer and maintainer implements approved changes once passed by the CCB. The CCB must maintain a record of configuration-controlled changes to the information system for a minimum of three (3) years after the change.
• Step 6: The project/program manager updates the configuration information inside of the System Design Document to reflect the changes approved in the CR.
• Step 7: The CCB audits implemented changes before the changes are added to the configuration baseline by verifying that the changes fulfill the requirements or requesting the update of documented requirements in response to the CR so it accurately reflect the changes.
• Step 7: The CCB tracks the progress of the implementation of the change by confirming the updates to the configuration documentation in the System Design Document as CRs are approved.
• Step 8: The CCB checks the configuration of the system periodically for discrepancies against the documented configuration baseline. The configuration audit will determine either whether the configuration of the system is compliant with the approved baseline, at which point they will notify the ISSO to initiate a POA&M.

Automated Document / Notification / Prohibition of Changes (CM-3(1))

Automation in the change management process can help to document changes and ensure the proper workflow. CMS uses automated means to document system changes for submission to the CCB. The automated process should cover several things. CMS wants the automated system to notify the authorizing personnel, who were designated to approve changes, whenever changes are proposed. The change request can be automated giving highlight rules to change requests for different statuses such as: awaiting approval, not approved, or overdue (defined in the SSPP). When the approvals come through, this system should alert the stakeholders that the change is approved.

Changing systems are a frequent occurrence. Automating the documentation, along with notification or prohibition of changes, saves CMS resources. Automating these processes can also increase the traceability of changes for many systems at once. This helps to keep accounts of all records linked to each applicable system and to review who approved specific changes and reasons for change.

The table below outlines the CMS organizationally defined parameters (ODPs) for CM Automated Document/Notification/Prohibition of Changes.

The following steps, which are ensured by the Business Owner, outline the process for automating the processes of documenting, notifying, and prohibiting actions during the change control process.

• Step 1:  The Information System Security Officer (ISSO), Information System Owner (ISO) and Project Manager develops configuration processes and procedures that include automated mechanisms, documenting them in the Configuration Management Plan during the proper CMS-SDLC phase. The automated mechanism(s) should be able to prohibit changes to the information system until a change is approved, store all approved Change Requests (CRs), and then notify the stakeholders when approved changes are complete.
  • Stakeholders to be notified upon implementation of changes (at a minimum):
    • Change Control Board (CCB) Chair
    • CRO Chief Risk Officer (CRO)
    • Cyber Risk Advisor (CRA)
    • Business Owner(BO)
    • Program Manager
    • Data Guardian (DG)
    • Information System Owner (ISO)
    • Information System Administrator

* For the stakeholders mentioned in Table 5 and Step 1 above, the CCB must be notified of system changes. However, each system requires its own group of stakeholders to make up the CCB and there is no expectation for each role listed in Table 5 to receive notifications for every single system change. This is especially true for the Data Guardian who should only receive notification when significant changes are implemented.

• Step 2: The ISSO, ISO, and Project Manager develop, as part of the Configuration Management Plan, an automated method of requesting approval from the authorized submitter to the appropriate CCB members to be listed in section 4.2 Roles and Responsibilities.
• Step 3: The ISSO, ISO, and Project Manager develop the method of automated notification of changes that have requested approval to determine who gets notification at the time of proposal and how they are notified.
• Step 4: The ISSO, ISO, and Project Manager reference the SSPP for handling changes, to determine highlighting rules for CRs that have not been addressed or have not been approved within the designated period.

Test / Validate / Document Changes (CM-3(2))

Systems can implement this control by creating an environment to test changes prior to implementation in the operational environment. The testing environment should be separate from the operational environment when possible. The test environment should mirror the operational environment to the  maximum extent possible, but CMS realizes deviations will have to be made so long as they are properly documented. Teams performing testing should document the process and procedures associated with the test to include a detailed outcome.

The purpose of testing changes to the system prior to implementation is to reduce the chance that outages will occur during implementation.  The separation of testing from implementation in the operational environment is meant to give network/system administrators an opportunity to see if proposed changes will adversely affect the operational systems.  CMS has the goal of reducing the chances that the operational environment will fail as a result of changes to the environment.  Implementing this control will reduce breaks in operational environments and enable stakeholders making subsequent changes to reference the documentation created. 

The following details the CMS specific process for testing, validating, and documenting changes to an information system.

• Step 1: The System Developer and Maintainer designs and develops the tests for the information system, as required by the CMS-SDLC, to be referenced for testing during changes.
• Step 2: The Change Manager collects CRs and makes sure that they are documented in the automated tool as outlined in the Configuration Management Plan.
• Step 3: The System Developer and Maintainer with the system/network administrator test the system changes as outlined in the documented CR and approved by the CCB.  The test may be conducted on the test environment or operational system while off-line or during a maintenance window using the tests outlined in the test plan.

Security Impact Analysis (CM-4)

Organizational personnel with information security responsibilities (e.g., Information System Administrators, Information System Security Officers, Information System Security Managers, and Information System Security Engineers) conduct security impact analyses. Security impact analysis may include, for example, reviewing security plans to understand security control requirements and reviewing system design documentation to understand control implementation and how specific changes might affect the controls. Security impact analyses may also include assessments of risk to better understand the impact of the changes and to determine if additional security controls are required. Security impact analyses are scaled in accordance with the security categories of the information systems.

The analysis of the security impact of a change occurs when changes are analyzed and evaluated for adverse impact on security, preferably before they are approved and implemented, but also in the case of emergency/unscheduled changes. These analyses are important to CMS because they prevent unnecessary risk to the enterprise.

Changes (in both the change management process and if a significant change will be made that impacts the ATO) should not be accepted without first studying the risks posed by these changes by conducting a security impact analysis. Before the changes are implemented and tested, a security impact analysis (and/or assessment) is performed to ensure that the changes have been sufficiently analyzed and documented, and to determine if there are any unanticipated effects of the change on existing security controls.

Change Management

Information system changes should not be undertaken prior to assessing the security impact of such changes. If the results of the security impact analysis indicate that the proposed or actual changes can affect, or have affected, the security state of the system; then corrective actions must be initiated and appropriate documents are revised and updated (e.g., the system security plan, security assessment report, and plan of action and milestones, etc.).

The business owner, or common control provider(s) should consult with their ISSO and/or CRA, and participate in the TRB review process prior to implementing any security-related changes to the information system, or its environment of operation.

Significant Change

Many events can trigger change—even events that may not result in an actual system “change”. Significant changes require a formal reauthorization of the system. If a formal reauthorization action is required, the business owner should target only the specific security controls affected by the changes and reuse previous assessment results wherever possible. Most routine changes to an information system or its environment of operation can be handled by the business owner’s continuous monitoring program.

NIST states that a Significant Change to an information system may include (for example): (i) installation of a new or upgraded operating system, middleware component, or application; (ii) modifications to system ports, protocols, or services; (iii) installation of a new or upgraded hardware platform; (iv) modifications to cryptographic modules or services; or (v) modifications to security controls. Examples of significant changes to the environment of operation may include for example: (i) moving to a new facility; (ii) adding new core missions or business functions; (iii) acquiring specific and credible threat information that the organization is being targeted by a threat source; or (iv) establishing new/modified laws, directives, policies, or regulations.

The following steps detail the CMS specific process to conduct a security impact analysis:

• Step 1: After receiving the Change Request (CR) submission from the CCB, the ISSO will determine the scope of the change by analyzing the CR form. They will develop a high-level architecture overview that shows how the change will be implemented. If the change has already occurred (unscheduled/unauthorized), the ISSO will request follow-up documentation/information and review it or use whatever information is available (e.g., audit records, interview staff who made the change, etc.) to gain insight into the change.
• Step 2: The ISSO will identify the scope and the categorization of the change.  See Appendix D for the SIA Template.
• Step 3: The ISSO will identify any vulnerabilities (via vulnerability scans, documentation comparison etc.) in the proposed change and analyze the categorizations of change and identify the security controls that are impact by the change (both system specific, hybrid, and inherited controls)
• Step 4: The ISSO, in consultation with the CRA, conducts a risk assessment of any discovered vulnerabilities (impact and likelihood) and change(s) to security control implementation that has been affected by the change(s). A risk assessment is needed to identify the likelihood of a threat exercising the vulnerability and the impact of such an event.
• Step 5: The ISSO, in consultation with the CRA, assess impact of proposed change on functionality of the system or CI and assess impact of proposed change on existing security controls. For example, the change may involve installation of software that alters the existing baseline configuration, or the change itself may cause or require changes to the existing baseline configuration. The change may also affect other systems or system components that depend on the function or component being changed, temporarily or permanently. For example, if a database that is used to support auditing controls is being upgraded to the latest version, auditing functionality within the system may be halted while the upgrade is being implemented.
• Step 6: The ISSO, in consultation with the CRA, conducts a Privacy Impact Assessment to ensure that a change to the system that affects PII/PHI is accounted for and proper action can be taken if necessary
• Step 7: The ISSO, in consultation with the CRA, determine whether the change is part of the change management process or if the change is significant enough that the system authorization is in question. Read the above introduction paragraphs for guidance to help make this determination.

If change management:

• Step 8: The ISSO and the CRA will document findings, attach them to the change request, and submit them to the Change Control Board (CCB). If the change is occurring on a contractor system, the contractor’s internal CCB will be responsible for approving changes.
• Step 9: Assess whether the changes made to the system impact the PIA and whether the PIA needs to be updated. Include this assessment in the findings submitted to the CCB.
• Step 10: If change is occurring on a contractor system, CMS has the ability to request that the contractor conduct an SIA.

If a significant change:

• Step 9: The ISSO and the CRA will meet with the Business Owner and the Technical Review Board (TRB) to determine if a re-authorization is necessary. If re-authorization is necessary, the ATO package must receive proper approval before implementation.
• Step 10: The ISSO and the CRA will document findings, attach them to the change request, and submit to the Change Control Board (CCB).
• Step 11: Assess whether the changes made to the system impact the PIA and whether the PIA needs to be updated. Include this assessment in the findings submitted to the CCB or TRB.

Separate Test Environments (CM-4(1))

Separate test environments are used at CMS to host an instance of the operational environment.  They should mirror one another in order to create an accurate response to changes as they are made for testing.  The environment will be kept separate, physically and/or logically, so that changes in one do not affect the other.  Changes will then be analyzed for flaws, weaknesses, incompatibility and intentional/unintentional harm that results from implementation.  CCB approved changes should be made in this test environment first, then the production/operational environment. Test environments need to mirror production to the maximum extent possible, but CMS realizes that deviations may have to be made so long as they are properly documented.

Separating the testing environment from the production environment benefits CMS by allowing a chance to see the changes requested for a system enacted before the changes affect end users. Test environments give a chance to observe possible harm or disrupted functionality without applying the changes to production. It can reduce the risks of change overall, since the production data and operational environment are not harmed when the test environment is adversely affected.

The following steps detail the CMS-specific process to ensure that separate environments have been incorporated into testing:

• Step 1:  The System/Network Administrator creates and maintains a test environment that is similar to the operational environment but either physically or logically separate from it.
• Step 2: The System/Network Administrator uses the test environment to enact approved changes from the CCB then observe and document the effects of those changes before those approved changes are enacted on the operational system.

Access Restrictions for Change (CM-5)

The changes to a system can be sensitive.  CMS calls for restrictions on the access to the system both physically and logically.  The access controls to limit change privileges can be implemented through discretionary access controls such as deciding who is on the CCB. Supplemental discretionary access or role-based access controls can be enacted on files using Access Control Lists (ACLs). There can also be physical access restrictions such as those requiring a key to get into datacenter facilities. All together, these access restrictions should be developed, documented, approved and enforced throughout the system life cycle.

Restricting the ability to enact change to a system maintains the overall stability to the system.  CMS limits production and operational privileges to make sure that there are controlled inputs to the change control process. Without limitations on change requests for a system, the process may become overwhelmed or inefficient based on unnecessary change requests. 

CMS enacts this control, which is ensured by the Business Owner, by utilizing the following steps:

• Step 1: The Office of Information Technology (OIT) defines and approves access restrictions associated with change to the system during the initial phase of the CMS-SDLC including:
  • Administrative controls – Such as procedures, processes and standards to be used in configuration management
  • Role-based Access Controls – Such as those on files and storage related to change documentation
  • Discretionary Access Controls – Such as those approving the appropriate personnel to approve changes to the system
  • Physical Access Controls – Such as those restricting access to the computer equipment where the change requests and automation systems are kept
• Step 2: The System Owner includes the defined access restrictions in the baseline configuration for the information system, to be included as a configuration item for the system.
• Step 3: The ISSO develops physical access controls if there is no description of them available for the information system.
• Step 4: The ISSO documents physical and logical access controls in CFACTS under the Controls tab in the Authorization Package. Select Allocated Control CM-5 and list the reference or documented physical controls in the Shared Implementation Details field of the Implementation section.
• Step 5: The ISSO reviews proposed changes to the physical and logical controls and the BO approves the changes.
• Step 6: Unapproved physical access changes must be filed as a Risk Acceptance Request documented in CFACTS or returned to the developer for modification of the plans and resubmission to the ISSO.

Automated Access Enforcement / Auditing (CM-5(1))

A system under this control will have automation in its access enforcement and auditing.  The automation means that the system will check to see if the user or service is authorized to access resources as well as use some form of authentication.  During this enforcement of access controls, the system should also log actions for auditing those enforcement actions later. 

The access enforcement for a system is important to maintain its security.  Automating the enforcement is the most efficient method of maintaining access controls.  These controls keep the unauthorized users out.  They contribute to the safety of the system through authentication and confidentiality. The confidentiality of the system makes it so that users only see parts of the system they are authorized to see.  Authentication ensures that CMS knows the user or service that is attempting to access a resource.  Finally, the creation of access control records will allow CMS personnel to evaluate working controls and detect misuse of the system through audits.

The following steps detail the CMS specific process for automatically controlling access and auditing:

• Step 1:  The System Developer and Maintainer creates the system with the functionality to audit against access restrictions specifically on changes to the hardware, software, and firmware components of the information system.
• Step 2:  The System Developer and Maintainer creates the functionality to record and document enforcement actions in relation to the access of data and/or functionality that is restricted in Step 1.
• Step 3: For cloud-based services, the Cloud Service Provider (CSP) should be enforcing Steps 1 and 2 using automated mechanisms, to be in place before the service is in operation.

Review System Changes (CM-5(2))

The review of system changes should be carried out once per week by the CCB.  This process should also allow for ad-hoc reviews for checking configurations against the baseline when unauthorized changes have been indicated or there is a dramatic unforeseen shift in performance.

Review is a useful tool utilized by CMS to determine which changes may have been made without permission, or without following the configuration management procedure.  Discovering an unauthorized change could mean that there are more unauthorized changes present within the system. Reviewing the system changes is an easy way to check for procedural mistakes or intentionally unauthorized system changes. CMS maintains records of access to ensure that configuration change control is implemented and to support after-the-fact actions should CMS discover any unauthorized changes. Access restrictions for change also include software libraries. Access restrictions include, for example, physical and logical access controls (see AC-3 and PE-3), workflow automation, media libraries, abstract layers (e.g., changes implemented into third-party interfaces rather than directly into information systems), and change windows (e.g., changes occur only during specified times, making unauthorized changes easy to discover). Related controls: AC-3, AC-6, PE-3, AU-6 and AU-7.

The table below outlines the CMS organizationally defined parameters for CM Review System Changes.

The following steps detail the CMS specific process for reviewing system changes:

• Step 1:  The CCB meets to review system changes each week to determine if unauthorized changes were made by checking current configuration baselines against the current configuration of the system to check for CIs that were modified without a corresponding approved CR.
• Step 2: When the CCB learns of unauthorized changes taking place or unexpected levels of system performance, they should check the configuration baselines of their systems against the actual configuration of the system to determine whether changes have been made on the system.
• Step 3: The CCB reports any unauthorized changes to the ISSO within 24 hours of the finding.

Signed Components (CM-5(3))

Signed components are parts of code that are used to create a digital signature and packaged together, code and signature. The digital signature is created from certificate assigned to the author of the code by a trusted certification authority.

CMS uses signed firmware and software components to know who the authors of the code are. The digital signature scheme and the Public Key Infrastructure together provide a way to institute non-repudiation for firmware and software updates.

The table below outlines the CMS organizationally defined parameters for CM Signed Components.

The following details the CMS specific process for signing components:

Code that is taken from third party providers must have a signature from the author. At CMS, the system administrators apply the correct configuration that automatically stops firmware and software components from being installed without a digital signature.  These settings are in use as part of CMS’ configuration baselines for systems.  In Windows-based systems, this is performed through Active Directory group policy objects.  The group policy is applied to the target computer object and results in the computer being configured to restrict software and firmware installations without digital signatures.  The certificate for the software should be from a trusted certificate authority and the certificate should not be trusted if it is self-signed. A trusted certificate authority is designated as such by DHS, HHS, and CMS.

Configuration Settings (CM-6)

HHS has outlined guidance for use when configuring information system components for operation.  Configuration standards vary depending upon the technical characteristics of the information system (e.g. operating systems, databases, firmware, etc.)  The Minimum Security Configurations Standard Guidance issued by the Department of Health and Human Services shall be applied to all applicable systems. If an HHS-defined configuration standard baseline is not available than the U.S. Government Configuration Baseline (USGCB) will be applied to the applicable systems.  For those systems not covered under USGCB, the National Checklist Program can be followed for configuration guidance.

The purpose of creating common configuration settings is to streamline management and security implementations.  CMS configures systems with standardized settings and automates their implementation to save time and create a baseline of security that applies to all information systems, thereby, minimizing risk across the enterprise.

The table below outlines the CMS organizationally defined parameters for CM Configuration Changes.

The following steps detail the CMS specific process for documenting configuration changes:

• Step 1: The CMS System Developer and Maintainer uses the HHS approved configurations and creates the configuration for the applicable information system using HHS defined security configurations as the guidance in their creation. For USGCB (HHS Approved) Configuration, the appropriate operating system and/or applications is Microsoft Windows Supported Versions.
• Step 2: The System Developer and Maintainer using other OSes and applications develops configurations from guidelines in the following priority:
  • HHS Minimum Security Configuration Standards Guidance
  • USGCB
  • NIST NCP – Tier IV, then III, II, I in descending order
  • Technical Reference Architecture Volume IV – Development and Application Services
  • DISA Security Technical Implementation Guide (STIG)
  • NSA STIG
  • Lacking a Federal government-authored checklist, using an industry group or vendor checklist (Such as Center for Internet Security (CIS) benchmarks)
  • Collaboration within CMS to i) Establish baselines and communicate industry and vendor best practices; and ii) Ensure deployed configurations are supported for security updates
• Step 3:  The System Developer and Maintainer documents secure configuration settings for the information system using the procedures in Section 3.1.
• Step 4: The network is scanned regularly for compliance with the established baseline configuration.
• Step 5: The information systems that are out of compliance are re-configured with baseline settings by the System Developer and Maintainer, in collaboration with the Vulnerability Management Team.

The following steps are intended for use if the information system is cloud-based from a Cloud Service Provider (CSP).

• Step 6: The OIT creates a baseline configuration with the CSP for their IT products inside the information system using USGCB as a guide to create the most restrictive mode consistent with operational requirements.
  • If USGCB does not apply, then they use the CIS benchmarks as guides to create the most restrictive mode consistent with operational requirements.
  • If neither USGCB nor CIS applies, then they create their own benchmark of configuration settings.
• Step 7: The CMS ISSO and the System Developer and Maintainer creates Security Content Automation Protocol (SCAP) compatible security configuration checklists if there are no validated ones available. The list should be formatted so that it can be read by a validated SCAP tool and enable that tool to determine if the approved configuration is in place.

Deviations

The following steps are intended for creating deviations to established configuration settings.  If the settings established using a standard for baseline configurations have significant detrimental impacts on a system’s ability to perform CMS duties, then follow the steps below to file for a Risk Acceptance. It is worth noting the difference between a deviation and a waiver. A waiver is required when there is a departure from CMS or HHS policy and must be approved by the AO. A deviation is when the system will differ from established configuration standards and the reason why the deviation is occurring must be documented.

• Step 1: Starting from the established baseline, the System Developer and Maintainer documents all of the deviations from the baseline that either:
  • Are not intended to be implemented since the standard(original baseline) setting would interfere with business operations
  • Are cost prohibitive
  • Are technically infeasible
  • Have an impact to operations
  • Cause a loss of functionality
• Step 2: The ISSO reviews the collected deviation(s) documented in the previous step by working with the BO to determine if configurations would restrict the types of information used, adversely affect the boundaries or adversely affect the information shared with other systems.  Furthermore, the ISSO reviews the list for completeness to ensure it has all the information needed for the Risk Acceptance form. The ISSO selects deviations to be approved by the CISO and CRA through the Risk Acceptance form or otherwise returned to the System Developer and Maintainer within 90 days of receipt with an explanation as to why the deviation was rejected.  Then the System Developer and Maintainer can re-submit in the next review period. These actions  must be thoroughly documented in CFACTS. The process for documentation is explained in detail below.
• Step 3: The ISSO (or System Maintainer) logs into CFACTS and fills out and signs the Risk Acceptance form including all deviations from the baseline configuration that should be considered for the information system in Section 2 Weaknesses with the following information at a minimum:
  • Allocated Control = CM-6
  • Finding Description
  • Weakness Description
  • Effect on Business

The ISSO then fills out Section 3 Proposed Risk Acceptance with all of the information related to the risk(s) that will be accepted and how/if the risk will be mitigated to include:

•  
  • Overview of the Risk Acceptance Request
  • Business Justification for the Risk Acceptance
  • Justification for Request
  • Compensating Controls (if any)
• Step 4: The CISO, BO, and CIO approve deviations from the configuration baseline and authorizes, using the Risk Acceptance form Section 5, the new configuration to be used in the CMS environment. 
• Step 5: Every year, the ISSO reviews the deviations and exceptions in place on the system. He or she takes the accepted deviations and considers them collected, documented deviations to start over from Step 11 for re-certifying the configuration of the system.

Automated Central Management / Application / Verification (CM-6(1))

Automating the management of operating systems and applications gives CMS more control over the information systems in the CMS infrastructure and those processing CMS data.  Automation is implemented to create a point (or points) of central management for administrators to change, apply, verify, and enforce configuration baselines and mandatory configuration settings. CMS uses the HHS defined security configuration standards as the basis for the configurations of information systems, components and applications.  CMS Information systems are expected to allow access to automated methods of configuration management, change and verification.  

Using these policies and procedures for the CMS environment assures an even application of approved configurations across the network.  These configurations are applying the settings that will secure each system and application according to CMS’s business and regulatory needs, specifically to enforce the baseline and the mandatory configuration settings.  CMS is able to implement the settings and verify that they are correct using this control.  Verification is used to show compliance.  The combination of configuration and verification makes this control necessary for large enterprise environments such as CMS.

The table below outlines the CMS organizationally defined parameters for Automated Central Management\Application\Verification.

The following steps, which is ensured completed by the Business Owner, detail the CMS specific process for automation of central management:

• Step 1:  The System Developer and Maintainer configures the information system with the tools necessary to automate monitoring and configuring.
• Step 2: The ISSO contacts the CDM program (Appendix G) in order to find out how to connect their system to the central management mechanism.
• Step 3: The system is scanned regularly by the System Developer and Maintainer for compliance with approved configurations.
• Step 4: The configuration changes are applied by the System Developer and Maintainer using configuration management tools to information systems after they have been approved by the OIT.

Respond to Unauthorized Changes (CM-6(2))

It is the duty of CMS authorized personnel to respond to unauthorized changes to the information system, components or its data.  The response should include notifying the business owner and ISSO. Additionally, the configuration should be restored to an approved version and further system processing can be halted as necessary.

CMS prevents or rolls back these changes to ensure that they go through the process of change management and receive the appropriate approvals and security checks before implementation.  Unauthorized changes that have not undergone security vetting may introduce new vulnerabilities that have not been mitigated by existing security controls.  The potential for increase of risk leads CMS to respond to unauthorized changes as soon as possible.

The table below outlines the CMS organizationally defined parameters for CM-6(2) Respond to Unauthorized Changes.

The following steps detail the CMS specific process for responding to unauthorized changes:

• Step 1:  Unauthorized changes are automatically stopped, when possible, by halting system processing using management tools and permission restrictions.  Attempts to make unauthorized changes generate alerts that are documented in centralized audit files.
• Step 2: CDM informs the Incident Management Team in Information and Security Privacy Group (ISPG) when unauthorized changes occur if an unauthorized individual accesses the system that made the change. If an authorized individual made a valid change but did not follow the CM process, CDM contacts the individual and requests that they roll back the change and follow the appropriate CM procedures.
• Step 3: Incident Management Team coordinates the incident response and assists stakeholders in deciding whether to retrieve the information system or otherwise restore the settings to the approved baseline.

Least Functionality (CM-7)

The principle of least functionality must considered when configuring a system.  This involves first documenting the essential capabilities of the system.  After that, the system can be configured to accommodate these capabilities while turning off non-essential functionality.  At CMS, we pay special attention to high-risk system services and additionally turn those off unless they are absolutely needed.

CMS integrates security principles into its system development and design.  This control addresses the principle that systems are granted only those functions that are needed in order for them to accomplish their tasks.  This includes system services, which traverse network boundaries that are considered high-risk.  This aims to reduce the “attack surface” of a system.  Attack surface refers to the points that an attacker might target when compromising a system.  Reducing functionality that goes beyond a system’s tasks leads to minimizing risk resulting in fewer attack vectors and leaving fewer options for attack.  CMS reduces the risk as much as possible for each system to prevent attacks.

The table below outlines the CMS organizationally defined parameters for CM least functionality.

The following process, which is ensured completed by the Business Owner, details the CMS procedure for least functionality:

• Step 1: To capture the functionality, the ISSO and the system developer and maintainer should refer to the Intake Form completed during the initial phase of the CMS-SDLC.
• Step 2: The System Developer and Maintainer logs into CFACTS to reference the network boundaries as shown in the CFACTS User Manual in section 4.4 Boundary Tab. They must also consider the system description, purpose, functionality, and architecture. This information can be used to turn off high-risk system services on the system or system components if they are not needed for system or application functionality.
• Step 3: The System Developer and Maintainer keeps a record of explicitly required system services, ports and network protocols, maintains it on an ongoing basis throughout the CMS-SDLC and communicates changes to the ISSO.
• Step 4: The ISSO enters the explicitly required system services, ports and network protocols into the System Security Plan in CFACTS using the Boundaries Details section and in the implementation details for control CM-7.

 Periodic Review (CM-7(1))

Review of ports, services, functions and protocols involves checking the system periodically.  The system checks will make comparisons of what is used and what is authorized for use.  CMS will then use that information to make a determination of which ports, services, functions and protocols should be disabled.  The system scans will identify the PPS, and then an analysis will have to be conducted to determine if they can be disabled.

Periodic review within CMS helps to protect the systems in its infrastructure.  The protection comes from reducing the attack surface as stated in “Least Functionality CM-7” to reduce the risk to the network.  Reviewing on a periodic basis allows CMS to check continually for weaknesses and baseline anomalies.  The change management process can introduce weaknesses into the environment, so it is important to evaluate systems on an ongoing basis to determine the consequences of changes, including unintentional or unforeseen consequences that affect the risk to that system.  CMS authorizes scanning systems on this basis since change management is also an ongoing process in itself.  This helps to keep checks coordinated with changes. 

The table below outlines the CMS organizationally defined parameters for CM periodic review.

The following process details the CMS procedure for periodic review:

• Step 1: The Continuous Diagnostics and Mitigation (CDM) team coordinates with the ISSO to monitor functions, ports, protocols, and services. The CDM sends periodic review information to the ISSO regarding their monitoring.
• Step 2: The CDM team automatically scans the information system for changes in functions, ports, protocols and/or services at least every 72 hours and more frequently as necessary.  The scans should include systems, appliances, devices, services and applications (such as databases). This is performed on an ongoing basis until the system is retired. Changes are documented and sent to the system ISSO.
• Step 3: The ISSO reviews the system every 30 days using the reports taken from the CDM program.  The reports are compared against the System Architecture and Architecture Design section inside of the System Design Document in CFACTS for its listing of necessary functions, ports, protocols and services.
• Step 4: The system developer and maintainer along with the ISSO work together to disable unnecessary functions, ports, protocols and services with advice from the CRA. This is performed on an ongoing basis as they are discovered.

Prevent Program Execution (CM-7(2))

This control is implemented to ensure that CMS is using the software it has acquired responsibly and legally.  To execute this control there must be methods in place to prevent executing software that is not:

• Licensed for use
• Configured for use at CMS
• Executed by an authorized user

Preventing these executions should be done automatically, and the users must not be permitted to execute the programs themselves.

These program preventions are a part of CMS’s security controls to ensure that security is built into the basic elements of systems through software. This is done to apply settings, which CMS knows are protecting the interests of the organization.  This is extended to licensing to make sure CMS is not exposed to risk by using software that is unlicensed.  Unlicensed software may violate the law or introduce new risks through its operation.   Risk from operation is also included in this control by restricting software to those that are authorized to use it. Unauthorized users may not be assigned the responsibility of using certain types of software and CMS uses separation of duties to spread out job responsibilities among groups of people to reduce risk and insider threats.

The table below outlines the CMS organizationally defined parameters for CM-7(2) prevent program execution.

This control is system specific, but the following is a good example of how to implement and document the control:

• Step 1: The administrators of the system create the baseline configuration for software on the computer image.
• Step 2:  System administrators configure the domain settings to disallow software installations for all Users without administrative privileges.
• Step 3: System administrators distribute computer images for all government issued computers using authorized and licensed software, and ensures that it is using approved configurations for the software included

For software that is not included in the computer image for the baseline configuration, use the following steps to allow execution in accordance with policies.

• Step 4: The user checks the website for the Office of Information Technology to find if the software that they are requesting has been tested by CMS for conflicts and/or malicious behavior using the “CMS Tested Software List” here: http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/testing.html

Note: Software that is supported under an enterprise license is a subset of the “CMS Tested Software List” from step 4; please refer to the OIT website for Enterprise Software Licensing here for more information: http://intranet.cms.gov/Component/OIS/Systems-and-Services/enterprise-software-licensing/index.html

• Step 5: If the software is not in the list, then submit the software for testing following the steps in the procedure on the OIT website:  http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/testing.html , if the software is on the list then skip to the next step
• Step 6: The user of the software must acquire the license for the software that they wish to use using the forms of proof provided by CMS Deskside support listed here: http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/requests.html
• Step 7: The user submits a new installation request following the procedure listed here: http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/process.html in which the Deskside support personnel will validate the license, authorize the user to use the software and provision the software in approved configurations

Users operate under restricted privileges per CM-7 - least privilege, which will logistically prevent program execution through system policies. For those users who may get software installed surreptitiously or have administrative privileges, the following steps will apply:

• Step 8: The operations team within ISPG monitors the network for software network behavior and/or traffic from unauthorized software, when possible, to discover, and create alerts to notify the CMS Security Operations Center (SOC) if unauthorized software use is logged.
• Step 9: The SOC reviews alerts daily to determine if unauthorized software is in use as part of their duty. When discovered, the SOC isolates the computer on the network if needed and uninstalls the unauthorized software.
• Step 10: The SOC utilizes automated methods of managing software and notifies the user when unauthorized software is detected and automatically removes the software before the next 48 hours.

Authorized Software / Allowlisting (CM-7(5))

The authorized software allowlisting control means that CMS would document the software that is allowed to run on CMS systems. The software name and its representation would be used to determine if a specific piece of software is on the list. Software on the list is allowed to execute and all other software is denied by default. As part of the implementation of this control, the list should be updated regularly and automatically from a trusted source.

Using an allowlist instead of a denylist is an option to consider for environments that are more restrictive. The list itself is known, and the system denies all other software. CMS can use an allowlist to lessen the uncertainty in a system through this prevention of executing the unknown. Decreasing the uncertainty in this case can also lead to decreasing the risk that malware or software outside of that needed for the operation of a system is executed.

The table below outlines the CMS organizationally defined parameters for CM Authorized Software/Allowlisting.

The following steps detail the CMS specific process for Authorizing Software or Allowlisting:

Note: If no Denylisting solution is in place, then an Allowlisting solution must be used.

• Step 1:  The ISSO, working with the System/Network Administrator and the System Developer and Maintainer, identifies and defines the software programs that are authorized for use on the information system. Then lists them in the applicable part of CFACTS. The list can be held under the “Controls” tab, in the “Allocated Controls” section for control CM-7(5) as part of the “Shared Implementation Details” subsection.
• Step 2: The System Developer and Maintainer configures an automated software Allowlisting tool for their applicable information systems so they only allow execution of software that has previously been approved for install/use listed in Step 1.
• Step 3: The ISSO automatically updates and reviews the list of software from Step 1 no less often than every 72 hours from a trusted source such as, but not limited to:
  •  
    • CMS internal processes
    • Other agencies within the federal government
    • The vendor of the Allowlisting product
    • Industry specialists
    • CMS systems, appliances, devices, services and applications (to include databases)
• Step 4: The System Developer and Maintainer configures the tool to provide results that are searchable by the CCIC.  These results must also be available in a raw, unaltered format by request of the CCIC.  Tools that are unable to exchange information with the CCIC must have this lack of ability noted in the applicable risk assessment.  CCIC directed requests for allowlisting information must be provided by the timeframe listed within the request.

For cloud-based systems that run software

• Step 5:  The System Developer and Maintainer configures the cloud-based system or service to only allow authorized software to execute following the steps above with or without an automated Allowlisting tool.

Information System Component Inventory (CM-8)

Information system components are parts of the CMS network used to process, store or transmit CMS information.  The components must each have an identifier that should be received from the property office in the form of an asset tag, which should be linked in an inventory system with the name of the asset, location, asset identification, owner, and description of use. More information can be added as needed, but those fields are the minimum.  Then the component inventory should be linked to the CDM tools so monitoring can be linked to specific components.

CMS takes an inventory of information system’s components as a fundamental part of protecting the infrastructure.  Inventories contain items that need to be checked for secure configurations, and they provide a logical baseline so that components found outside of the inventory can be scrutinized and unauthorized components removed, disabled or authorized.  Unauthorized components could be indicative of a security risk and should be investigated. This control also adds to the accountability of the system. Each component is a part of the system and the same security protections should apply to all components.  

The table below outlines the CMS organizationally defined parameters for CM Information System Component Inventory.

The following steps, which is ensured completed by the Business Owner, detail the CMS specific process for information system component inventory:

• Step 1: The ISSO develops and documents an inventory of information system components. For this, they or a designee gathers the following information to be checked off and documented from each FISMA information technology item, including all components within the authorization boundary:
  • Unique ID (or serial number) such as the asset tag number
  • Information system that the component is a part of
  • Are controls inherited?
  • High Value Asset?
  • Information system component type
  • Manufacturer & model
  • Operating system type and version number
  • Virtual machine presence
  • Application\software license & version information (when applicable)
  • Physical location
  • Logical location
  • Media access control (MAC) address
  • Responsible party (Owner)
  • Operational status
  • Primary & secondary administrator(s)
  • Primary user(s)
• Step 2: The ISSO checks the details listed in the asset management tool and determine if the information gathered is enough to track and report on the component and then add fields as necessary.  
• Step 3: The ISSO reviews for accuracy and missing information and update the information system component inventory every 180 days for systems rated as “High” and every 365 days for systems rated as “Moderate” or “Low” from the system categorization in RMH Chapter 12 Section 3.1.2. T
• Step 4: System Developer and Maintainer configures the inventory system(s) to provide updates in a format compliant with CMS and federal standards to the CCIC at least once every 72 hours.  These results must also be available in a raw, unaltered format by request of the CCIC.  Tools that are unable to exchange information with the CCIC must have this lack of ability noted in the applicable risk assessment.  CCIC directed requests for component information must be provided by the timeframe within the request.
• Step 5: The Network/System Administrator provides timely, as defined by the CISO, responses to informational requests about component status and posture information.

Updates During Installations / Removals (CM-8(1))

The purpose of this control is to ensure that the component inventory is up-to-date in times of change. The CMS system inventory should be updated in cases of: information system component installs, removals, and updates.

Updates during installations and removals to the inventory system is necessary to keep current information. The result of an upgrade, installation or removal can involve different components altogether. If the system inventory is not current, then the assumptions based on the inventory will not be accurate. It can have far-reaching impact beyond the current system and should involve updates as part of the procedure. Furthermore, updating the inventory supports accountability controls and breach response efforts.

The following, which is ensured completed by the Business Owner, lists the security safeguards implemented by CMS for Updates During Installations/Removals component inventory:

• Step 1: The ISSO inputs new information system components into the inventory when they are installed to include the information input for systems in Section 3.7 Step 1 above.
• Step 2: The ISSO updates the inventory when an information system component is removed from the system. The component is taken out of inventory.
• Step 3: The ISSO updates the inventory when an information system is updated, changing information that is listed in the inventory such as that in Section 3.7 Step 1.

Automated Maintenance (CM-8(2))

The CMS inventory system should be able to gather information and update records automatically.  The inventory system makes the database complete, accounting for inventory from purchase to disposition.  It is accurate, automated where possible and checked for accuracy. It is also meant to be readily available.  The system should be fault tolerant to ensure that the information on inventory is there when needed.

CMS uses automated inventory maintenance to show what information system components are available at any given time.  Knowing what inventory is supposed to be in the environment compared to what components are seen on the network, CMS can make determinations about components and their suitability.  If the component is in inventory and not detected through CDM for a time specified by CMS, then it may need to be flagged as a potentially compromised component. On the other hand, if a component is not in inventory and detected on the network, then it should be flagged as an unauthorized component until verified. These examples show some issues with risk by using inventory anomalies in CMS’ assessments of risk.

The following, which is ensured completed by the Business Owner, lists the security safeguards implemented by CMS for automated information system component inventory:

• Step 1: The ISSO develops methods to maintain the inventory of the information system including all components. The methods should include automation where possible and it should be available for review.
• Step 2: The ISSO compares the inventory system to physical inventory to evaluate accuracy and completeness, every 365 days for low/moderate systems and every 180 days for high systems.

Automated Unauthorized Component Detection (CM-8(3))

The detection of components is utilized at CMS to determine whether a component is authorized or not.  By using an inventory of components that are authorized to be on the network, CMS can utilize a mechanism to compare a discovered component with the inventory.  The scans must be done on a weekly basis, more frequently as needed.  The mechanism for discovery should be automatic and detect hardware, software and firmware components within the information system.  When a component is found to be unauthorized then the automated mechanism should take measures to do the following:

• Prevent access to the component
• Effectively disconnect the component from the network
• Isolate the component
• Notify responsible party as specified by the SSPP

CMS intends to automate where possible to stop malicious attacks as they occur.  Stopping the communication with an unauthorized component as soon as possible is the goal of this control.  The automated responses helps CMS address threats in a timely manner since utilizing technology is consistently faster than a manual process would be able to address.  In order to review and take action against unauthorized components quickly, automation is the ideal solution. 

The table below outlines the CMS organizationally defined parameters for CM automated unauthorized component detection.

The following steps detail the process for automated unauthorized component detection:

• Step 1: The ISSO, working with the Business Owner, monitors the network to determine if unauthorized components are connected. The scan should be done at least weekly then as necessary for components that match the inventory in the automated inventory record.
• Step 2: The ISSO forwards unauthorized components to the Incident Management Team (IMT.)

Accountability Information (CM-8(4))

Information system components are accounted for in the CMS inventory.  This listing has accountability information attached to it that may be referenced when a component is compromised. The information contains the role(s) or individual(s) responsible and/or accountable for the information system components.

The information listed about CMS system components is designed as a reference for security personnel.  The accountability information is used when, for example, the component needs to be replaced, is the source of a breach or a compromise, or needs to be relocated.  A control for accountability information provides CMS with the contact information needed during incident response and times of change. The risk associated with those situations is assigned appropriately to the responsible person who can delegate the associated work.

The table below outlines the CMS organizationally defined parameters for accountability information.

The following process, ensured is completed by the Business Owner, details the CMS procedure for keeping accountability information:

• Step 1: The ISSO develops methods to identify the individual(s), to include position and role, responsible and accountable for administering information system components.
• Step 2: The ISSO documents and maintains the information of individual(s) responsible for administering the information system components.

No Duplicate Accounting of Components (CM-8(5))

This control is used in CMS to ensure components are not duplicated in inventories.  The inventory that lists all components shall not have more than one of the same instance of a component.

CMS avoids duplicate accounting in inventory systems because it creates a source of confusion for responsibility and remediation.  Systems can be large and complex, involving many different components that interact with each other as well as other interconnected systems.  Assigning a component to a single system inventory streamlines accounting and reduces the time and effort to discern applicable parties responsible for that component. It also leads to straightforward remediation of vulnerabilities when discovered since the component is linked to a single system.

The following steps detail the CMS specific process for verifying that the accounting for information system components are not duplicated:

• Step 1:  The ISSO documents the system components inside of CFACTS using the Authorization Package for the system inside of the “Boundary” tab under the “Hardware” and “Software” sections.
• Step 2: The ISSO sorts hardware and then software by unique attributes to check if all components have different unique attributes from one another whenever entering in new system components.
• Step 3: If there is no duplication of component attributes then no further action is needed. If the ISSO identifies a duplication of unique attributes for a component then proceed to the next step.
• Step 4: The ISSO removes the duplicate component attribute from the system.

Configuration Management Plan (CM-9)

The CMS-SDLC incorporates a configuration management plan into the planning process. The plan is designed to document the process and procedures for configuration management.  The plan shall cover certain areas in order to fulfill this security control.  Listed in the document are roles of stakeholders, their responsibilities, processes and procedures.  The document shall also outline current configuration items.  Specifically, one of the processes covered shall be how to identify a configuration item.  The plan shall be protected, after it is finalized, from modification or unauthorized disclosure as are the configuration baselines.

Configuration management plans define people, processes and procedures.  The plans establish the technical and administrative direction and surveillance for the management of configuration items.  CMS uses this plan to separate responsibility and add traceability to protect the integrity of systems.  Changes are documented and explicitly approved or rejected, so there is accountability regarding the approver, and changes that were made on the system without approval.  Implementing the plan properly helps CMS pinpoint issues related to changes, leading to quicker resolutions and rollbacks to repair them.

The following steps detail the CMS specific process for developing, documenting and implementing a configuration management plan:

• Step 1:  The CMS Program/Project Manager completes a configuration management plan.
• Step 2: The Program/Project Manager documents roles and responsibilities for the plan in a Roles & Responsibilities section.
• Step 3: The Program/Project Manager defines the processes and procedures involved with configuration management. Configuration Management Administration and Methods and Tools sections should be included.
• Step 4: The Program/Project Manager lists CIs for the information system in a System Design Document.
• Step 5: The Program/Project Manager protects the document from unauthorized disclosure or modification by using access control methods for storage locations to restrict access to authorized personnel only.

Software Usage Restrictions (CM-10)

CMS will establish and enforce procedures for identifying and removing inappropriate software.  Contractors and Government employees are expected to use software and associated documentation according to applicable law and contractual agreements.  CMS is responsible for the prevention, monitoring, and removal of unauthorized software.  Installed software and documentation will be monitored as needed to determine if its use is allowed by the license or contract. Additionally, peer-to-peer file sharing technology is not expected to be used except as approved by the CIO, but such traffic will be inspected to determine if sensitive or protected content was being shared.

Software usage restriction assists in safeguarding against the sharing of copyrighted material and/or the use of software in a manner that would violate CMS agreements.  CMS tracks the use of software and associated documentation protected by quantity licenses to control copying and distribution.  CMS also controls and documents the use of peer-to-peer file sharing technology to ensure that this capability is not used for the unauthorized distribution, display, performance, or reproduction of copyrighted work.  This reduces CMS liability by preventing potential copyright violations.  

The following steps detail the CMS specific process for the implementation of the CM-10 control and/or requirement:

• Step 1: System/Network Administrator ensures that the software has been previously tested according to the CMS testing procedure found here: http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/testing.html. A list of previously tested software is available here: http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/Documents/Tested-Software-List.pdf
• Step 2: The System/Network Administrator reviews the installation request for the software proof of purchase, unless it was custom developed in-house, which includes:
  • Approved purchase record
  • Certified receipt or invoice
  • Validated HHS Form 393 (Purchase/Service/Stock Requisition Form)
  • CMS credit card invoice
  • Vendor proof of license purchase certificate
  • Vendor end-user authorization form for volume licensing
  • Vendor-provided notice of software purchase
  • End-user license agreement
  • Enterprise Software Licensing
• Step 3: The System/Network Administrator installs the software and documents that the instance of software and license are used for the information system so that the total number of licenses, the proof of license and installations are denoted.  The documentation is used by the System/Network Administrator to prevent copying per the CMS Policy for Acceptable Use of CMS Desktop/Laptop and Other IT Resources section 4.1 and/or violating license agreements.
• Step 4: CMS ISSO and respective component support staff from ISPG CDM performs routine scans of CMS networks to compare the current approved users and their installed software to the list of approved CMS “Core” and “Above Core” software.
• Step 5: CMS ISSO communicates, via e-mail, a list of approved users to the component support staff Asset Management Team that do not comply with CMS Software Policy.
• Step 6: CMS Asset Management Team notifies, via e-mail, those users and their managers that were identified as having unauthorized software on their information systems, and provide a date to remove the software or their respective access will be revoked.
• Step 5: Users that are notified of unauthorized software on their information system, must remove the inappropriate software within twenty-four (24) hours after completion of a Service Request (SR). In the event an exception is needed based on job role and function, an SR is submitted to the ISSO with appropriate justification for further 508 compliance testing and approval. 

User-Installed Software (CM-11)

Allowing CMS personnel to install software on agency information systems and system resources exposes the organization to unnecessary risk.  GFEs will be configured to prevent installation of software when unprivileged users attempt it.  Privileged users will be allowed to install software by following established procedures.  The proper methods should be outlined within the SSPP of the information system under the control allocation for CM-11 – Shared Implementation Details.  Users of the information system will have to follow the policy as stated in the SSPP.  CMS will take action at least once per month after implementation to monitor adherence to the policy. 

CMS wants to mitigate potential problems that may arise when users install programs.  Some examples of problems that can be introduced are using two different versions of the same software that can cause system conflicts, introducing malware, and installing unlicensed software that could be discovered during audit or unauthorized programs that could be used to gather information from CMS’s network.  This control is designed to protect network resources from unauthorized actions from software by restricting the number of people who have the ability to install it.  This will minimize the risk of losing functionality in programs, damaging CMS infrastructure from malicious programs, harming CMS’s reputation through sensitive data loss, or exposing CMS to liability from unlicensed software.  Monitoring the system for these installations allows us to adhere to information security continuous monitoring (ISCM) requirements as per the CMS IS2P2 section 4.1.2 Risk Management Framework.

The table below outlines the CMS organizationally defined parameters for user-installed software.

The following steps detail the CMS specific process for the implementation of the CM-11 control and/or requirement:

• Step 1: CMS image management team installs privilege management software on all GFE configuration baselines to prevent the installation of software by users in accordance with software installation rules.
• Step 2: For GFEs, the Deskside Support Team configures them to restrict the permissions of users and prevent user-initiated installations. For all other CMS equipment, the business owner and the ISSO is responsible for restricting the permissions of users and preventing user-initiated installations.
• Step 3: For GFEs, the Deskside Support Team configures it with the security category of High to accept installation of a list of applications (i.e. a Allowlist) and prevents all other user installations of software. For all other CMS equipment, the business owner and the ISSO is responsible for configuring the equipment with the security category of High to accept installation of a list of applications (i.e. a Allowlist) and prevent all other user installations of software.
• Step 4: The System Developer and Maintainer configures the system with methods and data gathering mechanisms that collect information at least once per month about the installed software that confirms its authorized use. It must be compliant with CDM. 
• Step 5: The System Developer and Maintainer configures the methods and data gathering mechanisms from Step 4 to comply with CDM.
• Step 6: The System Developer and Maintainer configures systems with the security category of High to accept installation of a list of applications (i.e. a Allowlist) and prevent all other user installations of software.