- Change Control Board (CCB) Chair;
- Chief Risk Officer (CRO);
- Cyber Risk Advisor (CRA);
- ISSO;
- Program Manager;
- Data Guardian;
- Information System Owner (ISO); and
- Information System Administrator.
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
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 organization reviews information system changes:
a. At least once a week; and
b. When unauthorized changes or unexpected levels of system performance are indicated.
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.
Control Control Requirement CMS Parameter CM-5(3) The information system prevents the installation of [Assignment: organization-defined software and firmware components] without verification that the component has been digitally signed using a certificate that is recognized and approved by the organization. The information system prevents the installation of network and server software and firmware components without verification that the component has been digitally signed using a certificate that is recognized and approved by the organization. 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.
- Establishes and documents configuration settings for information technology products employed within the information system using [Assignment: organization-defined security configuration checklists] that reflect the most restrictive mode consistent with operational requirements;
- Identifies, documents, and approves any deviations from established configuration settings for [Assignment: organization-defined information system components] based on [Assignment: organization-defined operational requirements];
- Establishes and documents configuration settings for information technology products employed within the information system using the latest security configuration baselines established by the HHS, U.S. Government Configuration Baselines (USGCB), and the National Checklist Program (NCP) defined by NIST SP 800-70 Rev. 2 (refer to Implementation Standard 1 for specifics) that reflect the most restrictive mode consistent with operational requirements;
- Identifies, documents, and approves any deviations from established configuration settings for individual components within the information system based on explicit operational requirements (defined in the system security plan [SSPP]);
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
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.
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
- 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)
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 organization employs automated mechanisms to centrally manage, apply, and verify configuration settings for [Assignment: organization-defined information system components].
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 organization responds to unauthorized changes to information system and components (e.g., authorization, auditing, processing types, baselines) and data (e.g., system libraries, log files, executables) in the following ways:
- Alert responsible actors (person, organization);
- Restore to approved configuration; and
- Halt system processing as warranted.
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.
b. Prohibits or restricts the use of the following functions, ports, protocols, and/or services: [Assignment: organization-defined prohibited or restricted functions, ports, protocols, and/or services].
- Prohibits or restricts the use of high-risk system services, ports, network protocols, and capabilities (e.g., Telnet, FTP, etc.) across network boundaries that are not explicitly required for system or application functionality.
- [Added] A list of specifically needed system services, ports, and network protocols must be maintained and documented in the applicable security plan; all others will be disabled.
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.
- Reviews the information system [Assignment: organization-defined frequency] to identify unnecessary and/or non-secure functions, ports, protocols, and services; and
- Disables [Assignment: organization-defined functions, ports, protocols, and services within the information system deemed to be unnecessary and/or non-secure].
- Reviews the information system no less often than once every thirty (30) days to identify and eliminate unnecessary functions, ports, protocols, and/or services;
- Performs automated reviews of the information system no less often than once every seventy-two (72) hours to identify changes in functions, ports, protocols, and/or services; and
- Disables functions, ports, protocols, and services within the information system deemed unnecessary and/or non-secure.
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.
The information system prevents program execution in accordance with [Selection (one or more): [Assignment: organization-defined policies regarding software program usage and restrictions]; rules authorizing the terms and conditions of software program usage].
The information system prevents program execution in accordance with policies regarding authorized software use which include, but are not limited to the following:
a. Software must be legally licensed;
b. Software must be provisioned in approved configurations; and
c. Users must be authorized for software program use.
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.
- Identifies [Assignment: organization-defined software programs authorized to execute on the information system];
- Reviews and updates the list of authorized software programs [Assignment: organization-defined frequency].
- Identifies defined software programs (defined in the applicable security plan) authorized to execute on the information system;
- Reviews and updates the list of authorized software programs no less often than every seventy-two (72) hours; and
- [Added] Receives automated updates from a trusted source.
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)
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.
- Develops and documents an inventory of information system components that:
4. Includes [Assignment: organization-defined information deemed necessary to achieve effective information system component accountability]; and
- Reviews and updates the information system component inventory [Assignment: organization-defined frequency].
a. Develops and documents an inventory of information system components that:
1. Accurately reflects the current information system;
2. Include all components within the authorization boundary of the information system;
3. Are at the level of granularity deemed necessary for tracking and reporting; and
- Each component’s unique identifier and/or serial number;
- Information system of which the component is a part;
- Type of information system component (e.g., server, desktop, application);
- Operating system type and version/service pack level;
- Presence of virtual machines;
- Application software version/license information;
- Physical location (e.g., building/room number);
- Logical location (e.g., IP address, position with the information system [IS] architecture);
- Media access control (MAC) address;
- Primary and secondary administrators; and
- - Primary user. Reviews and updates the information system component inventory no less frequently than every 180 days for High systems or 365 days for Moderate and Low systems, or per CM-8(1) and/or CM-8(2), as applicable.
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)
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.
- Employs automated mechanisms [Assignment: organization-defined frequency] to detect the presence of unauthorized hardware, software, and firmware components within the information system; and
- Takes the following actions when unauthorized components are detected: [Selection (one or more): disables network access by such components; isolates the components; notifies [Assignment: organization-defined personnel or roles]].
- Employs automated mechanisms no less than weekly to detect the presence of unauthorized hardware, software, and firmware components within the information system; and
- Takes the following actions when unauthorized components and/or provisioned configurations are detected:
1. Disable access to the identified component;
2. Disable the identified component’s network access;
3. Isolate the identified component; and
4. Notify the responsible actor (i.e., person/organization defined in security plan).
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.
Control Control Requirement CMS Parameter CM-8(4) The organization includes in the information system component inventory information, a means for identifying by [Selection (one or more): name; position; role], individuals responsible/accountable for administering those components. The organization includes in the information system component inventory information, a means for identifying by the System Developer/Maintainer or the Business Owner, the individuals responsible/accountable for administering those components. 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
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.
a. Establishes [Assignment: organization-defined policies] governing the installation of software by users;
b. Enforces software installation policies through [Assignment: organization-defined methods]; and
c. Monitors policy compliance at [Assignment: organization-defined frequency].
a. Prohibits the installation of software by users on all GFE;
b. Enforces software installation policies through organization-defined methods (defined in the SSPP); and
c. Monitors policy compliance at least monthly.
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.
- Stakeholders to be notified upon implementation of changes (at a minimum):