risk management handbook (rmh) chapter 5: … configuration management plan ... figure 4:...

Centers for Medicare & Medicaid Services Information Security and Privacy Group

Risk Management Handbook (RMH) Chapter 5: Configuration Management

Version 1.1

May 03, 2018

Centers for Medicare & Medicaid Services

Risk Management Handbook (RMH) Chapter 5: Configuration Management ii Version 1.1 May 03, 2018

Record of Changes

The “Record of Changes” table below is used to capture changes when updating the document. All columns are mandatory.

Version Number Date Chapter Section Author/Owner

Name Description of Change

1.0 1/11/2018 All ISPG Initial Publication 1.1 05/03/2018 Sections 1.5 and 3 ISPG Alignment of CMS Defined

Parameters with recently published Acceptable Risk

Safeguards (ARS) Version 3.1; Inserted HIPAA Security Rule

Integration section 1.5; Removal of Non-Mandatory Controls

Centers for Medicare & Medicaid Services Effective Date/Approval

Risk Management Handbook (RMH) Chapter 5: Configuration Management iii Version 1.1

Effective Date/Approval This policy becomes effective on the date that CMS’s Chief Information Officer (CIO) signs it and remains in effect until it is rescinded, modified, or superseded by another policy.

Signature: /S/ Date of Issuance: 1/11/2018

George Hoffmann Acting Chief Information Officer and Acting Director, Office of Information Technology (OIT)

Standard Owner’s Review Certification This document shall be reviewed in accordance with the established review schedule located on the CMS website.

Signature: /S/ Date of Annual Review: 1/9/2018

Emery Csulak CMS Chief Information Security Officer and Senior Official for Privacy

https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/CIO-Directives-and-Policies/index.html

Centers for Medicare & Medicaid Services Table of Contents

Risk Management Handbook (RMH) Chapter 5: Configuration Management iv Version 1.1

Table of Contents Effective Date/Approval ................................................................................................... iii

Table of Contents .............................................................................................................. iv

1. Purpose .......................................................................................................................... 7

1.1 Authority ..........................................................................................................................7 1.2 Scope ................................................................................................................................7 1.3 Handbook Structure ..........................................................................................................8 1.4 Background ......................................................................................................................8

1.4.1 Basic Configuration Management ......................................................................10 1.5 HIPAA Security Rule Integration ..................................................................................11 1.6 Policy (CM-1) ................................................................................................................13 1.7 Standards ........................................................................................................................15 1.8 Guidelines .......................................................................................................................15

2. Roles and Responsibilities ......................................................................................... 16

3. Procedures .................................................................................................................. 18

3.1 Baseline Configuration (CM-2) .....................................................................................18 3.1.1 Reviews and Updates (CM-2(1)) ........................................................................19 3.1.2 Automation Support for Accuracy/Currency (CM-2(2)) ....................................20 3.1.3 Retention of Previous Configurations (CM-2(3)) ...............................................21 3.1.4 Configure Systems, Components, or Devices for High-Risk Areas (CM-2(7)) .22

3.2 Configuration Change Control (CM-3) ..........................................................................24 3.2.1 Automated Document/Notification/Prohibition of Changes (CM-3(1)) ............26 3.2.2 Test/Validate/Document Changes (CM-3(2)) ....................................................28

3.3 Security Impact Analysis (CM-4) ..................................................................................29 3.3.1 Separate Test Environments (CM-4(1)) .............................................................34

3.4 Access Restrictions for Change (CM-5) ........................................................................34 3.4.1 Automated Access Enforcement/Auditing (CM-5(1)) .......................................35 3.4.2 Review System Changes (CM-5(2)) ...................................................................36 3.4.3 Signed Components (CM-5(3)) ..........................................................................37

3.5 Configuration Settings (CM-6) ......................................................................................37 3.5.1 Automated Central Management\Application\Verification (CM-6(1)) ..............41 3.5.2 Respond to Unauthorized Changes (CM-6(2)) ...................................................42

3.6 Least Functionality (CM-7) ............................................................................................43 3.6.1 Periodic Review (CM-7(1)) ................................................................................44 3.6.2 Prevent Program Execution (CM-7(2)) ..............................................................46 3.6.3 Authorized Software/Whitelisting (CM-7(5)) ....................................................48

3.7 Information System Component Inventory (CM-8) .......................................................49 3.7.1 Updates During Installations/Removals (CM-8(1)) ...........................................52


Risk Management Handbook (RMH) Chapter 5: Configuration Management v Version 1.1

3.7.2 Automated Maintenance (CM-8(2)) ...................................................................52 3.7.3 Automated Unauthorized Component Detection (CM-8(3)) ..............................53 3.7.4 Accountability Information (CM-8(4)) ...............................................................54 3.7.5 No Duplicate Accounting of Components (CM-8(5)) ........................................55

3.8 Configuration Management Plan (CM-9) ......................................................................56 3.9 Software Usage Restrictions (CM-10) ...........................................................................56 3.10 User-Installed Software (CM-11) ...................................................................................58

Appendix A. Acronyms ................................................................................................... 60

Appendix B. Glossary of Terms ..................................................................................... 62

Appendix C. Applicable Laws and Guidance ............................................................... 68

Appendix D. ARS Standards – Configuration Management (CM) ............................ 73

Appendix E. Control/Policy Cross Reference Table .................................................... 89

Appendix F. Security Impact Assessment Template .................................................... 92

Appendix G. Points of Contact ....................................................................................... 93

Appendix H. Feedback and Questions........................................................................... 94

Appendix I. Events As Triggers Of Change .................................................................. 95

Tables

Table 1: CMS Defined Parameters – Control CM-2(1) ................................................................ 19



Table 4: CMS Defined Parameters – Control CM-3 .................................................................... 24


Table 7: CMS Defined Parameters - Control CM-5(2) ................................................................ 36

Table 8: CMS Defined Parameters - Control CM-5(3) ................................................................ 37

Table 10: CMS Defined Parameters - Control CM-6 ................................................................... 38

Table 11: CMS Defined Parameters - Control CM-6(1) .............................................................. 41



Table 14: CMS Defined Parameters – Control CM-7(1) .............................................................. 45


Risk Management Handbook (RMH) Chapter 5: Configuration Management vi Version 1.1

Table 15: CMS Defined Parameters – Control CM-7(2) .............................................................. 46





Table 22: CMS Defined Parameters – Control CM-11 ................................................................ 58

Figures

Figure 1: Risk Management Framework (RMF) 10

Figure 2: Configuration Management Phases 11

Figure 4: Application Change Checklist 30

Figure 5: Network Change Checklist 31

Figure 6: Environmental Change Checklist 31

Figure 7: Risk Assessment Template 32

Figure 8: Security Control Change Template 33

Centers for Medicare & Medicaid Services Purpose

Risk Management Handbook (RMH) Chapter 5: Configuration Management 7 Version 1.1 May 03, 2018

1. Purpose The Centers for Medicare & Medicaid Services (CMS) RMH Chapter 5 Configuration Management is written in compliance with the CMS Information Systems Security and Privacy Policy (IS2P2) and the CMS Information Security Acceptable Risk Safeguards (ARS). The intent of this document is to describe standard operating procedures that facilitate the implementation of security controls associated with the Configuration Management (CM) family of controls taken from the National Institute of Standards and Technology (NIST) Special Publication 800-53 Security and Privacy Controls for Federal Information Systems and Organizations and tailored to the CMS environment in the CMS ARS.

1.1 Authority The Federal Information Security Modernization Act (FISMA) of 2014 designated NIST as authority to provide guidance to federal agencies for implementing information security and privacy requirements for federal information systems. In addition, CMS must comply with the Privacy Act of 1974 (“Privacy Act”), Health Insurance Portability and Accountability Act of 1996 (HIPAA), and the E-Government Act of 2002. The Health and Human Services’ (HHS) Office for Civil Rights (OCR) is responsible for enforcement of the HIPAA Privacy Rule. In addition, the CMS IS2P2 defines the framework under which CMS protects and controls access to CMS information and information systems in compliance with the federal laws. Per the Department of Health and Human Services (HHS) Information Systems Security and Privacy Policy (IS2P), the CMS Chief Information Officer (CIO) designates the CMS Chief Information Security Officer (CISO) as the CMS authority for implementing the CMS-wide information security program. HHS policy also designates the Senior Official for Privacy (SOP) as the CMS authority for implementing the CMS-wide privacy program. Through this Policy, the CIO/SOP delegate authority and responsibility to specific organizations and officials within CMS to develop and administer defined aspects of the CMS Information Security and Privacy Program. All CMS stakeholders must comply with and support this handbook to ensure compliance with federal requirements and programmatic policies, standards, procedures, and to facilitate the implementation of information security and privacy controls.

1.2 Scope This handbook documents procedures that facilitate the implementation of the security controls and standards defined in the CMS IS2P21 and the CMS ARS2 for the Configuration Management (CM) family of security controls. This RMH provides authoritative guidance on all matters related to Configuration Management. This handbook is for use by CMS employees and contractors that support the development, operations, maintenance, and disposal of CMS information systems.

1 For more information on CMS IS2P2 go to https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-

Information-Technology/InformationSecurity/Downloads/IS2P2.pdf 2 For more information on CMS ARS go to https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-

Information-Technology/InformationSecurity/Information-Security-Library.html

https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Downloads/IS2P2.pdf


https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Information-Security-Library.html



Risk Management Handbook (RMH) Chapter 5: Configuration Management 8 Version 1.1

This handbook does not supersede any other applicable law, higher-level agency directive, or existing labor management agreement in place.

1.3 Handbook Structure This handbook is structured to align with the NIST-SP 800-53 Security and Privacy Controls for Federal Information Systems and Organizations catalogue of controls, the CMS IS2P2, and the CMS ARS. Each procedure is related to a specific NIST security control and additional sections have been included in this document to increase traceability and to satisfy audit requirements. This document is organized by sections and appendices as follows:

• Purpose • Authority

• Scope

• Handbook Structure

• Background

• Policy

• Standards

• Guidelines

• Roles and Responsibilities

• Procedures • Appendices

• Appendix A. Acronyms

• Appendix B. Glossary of Terms

• Appendix C. Applicable Laws and Guidance

• Appendix D. ARS Standards – Change Management (CM)

• Appendix E. Control/Policy Cross Reference Table

• Appendix F. Security Impact Assessment Tables

• Appendix G. Points of Contact

• Appendix H. Feedback and Questions

• Appendix I. Events as Triggers of Change

1.4 Background NIST 800-53 states under the CM control family that an organization develops, disseminates, and must periodically review and update its configuration management documentation. This includes a formal, documented, change management policy that addresses purpose, scope, roles,



responsibilities, management commitment, coordination among organizational entities, and compliance; and formal, documented procedures to facilitate the implementation of the configuration management policy and associated configuration management controls. This RMH Chapter 5: Configuration Management provides procedures to assist with the implementation of the CM family of controls to ensure change management for FISMA systems within the CMS enterprise environment and on any systems storing, processing, or transmitting CMS information on behalf of CMS. This control family addresses the establishment of policy and procedures for the effective implementation of selected security and privacy controls and control enhancements in the CM family. Policy and procedures reflect applicable federal laws, executive orders, directives, regulations, policies, standards, and guidance. For purposes of change management, the CMS Office of the Chief Information Officer (OCIO) has instituted policy to guide projects and development of systems by requiring appropriately scaled formal methods, to include chartered Change Control Boards (CCBs), point of contact (POC) lists, and formal processes and procedures such as those outlined in this RMH. Effective configuration management of information systems requires the integration of the management of secure configurations into the organizational configuration management process or processes. The Configuration Management (CM) process exists within a six step Risk Management Framework (RMF). This framework emphasizes:

(i) building information security capabilities into federal information systems through the application of state-of-the-practice management, operational, and technical security controls;

(ii) maintaining awareness of the security state of information systems on an ongoing basis through enhanced monitoring processes; and

(iii) providing essential information to senior leaders to facilitate decisions regarding the acceptance of risk to organizational operations and assets, individuals, other organizations, and the Nation arising from the operation and use of information systems.

The RMF has the following characteristics:

• promotes the concept of near real-time risk management and ongoing information system authorization through the implementation of robust continuous monitoring processes;

• encourages the use of automation to provide senior leaders the necessary information to make cost-effective, risk-based decisions with regards to the organizational information systems supporting their core missions and business functions;

• integrates information security into the enterprise architecture and system development life cycle;

• provides emphasis on the selection, implementation, assessment, and monitoring of security controls, and the authorization of information systems;



• links risk management processes at the information system level to risk management processes at the organization level through a risk executive (function); and

• establishes responsibility and accountability for security controls deployed within organization information systems and inherited by those systems (i.e., common controls).

The RMF changes the traditional focus of CM as a static, procedural activity to a more dynamic approach that provides the capability to effectively manage information system-related security risks in highly diverse environments of complex and sophisticated cyber threats, ever-increasing system vulnerabilities, and rapidly changing missions. The six steps of the RMF are illustrated in Figure 1 below.

Figure 1: Risk Management Framework (RMF)

1.4.1 Basic Configuration Management 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. The four phases of CM are illustrated in Figure 2 below.

Figure 2: Configuration Management Phases

1.5 HIPAA Security Rule Integration The HIPAA Security Rule is designed to be flexible, scalable, and technology-neutral, which enables it to accommodate integration with more detailed frameworks such as FISMA. Though both regulations are governed by different federal agencies, to serve separate purposes, there is an overlap between the two. In essence, by following FISMA requirements compliance with the HIPAA Security Rule can be achieved without any additional methodology. HIPAA provides guidance to address the provisions required for the security of health-related information,

Identifying and Implementing Configurations

Baseline Configuration (CM-2) Configuration Settings (CM-6) Information System Component Inventory (CM-8)

Planning

Configuration Management Plan (CM-9)

Controlling Configuration

Changes

Configuration Change Control (CM-3) Security Impact Analysis – Configuration Changes (CM-4)

Monitoring

Periodic Review (CM-7(1)) Security Impact Analysis – Moderating Significant Change (CM-4)



whereas FISMA presents instructions for the security of the information and the information systems which support these activities. For instance, the following table is a crosswalk of what controls found in this RMH map to specific sections and requirements found in HIPAA:

Configuration Management (CM) Control HIPAA Section

Baseline Configuration (CM-2) §164.308(a)(4); §164.308(a)(7)(i); §164.308(a)(7)(ii); §164.308(a)(1)(ii)(D); §164.312(b)

Configuration Change Control (CM-3) §164.308(a)(8); §164.308(a)(7)(i); §164.308(a)(7)(ii)

Security Impact Analysis (CM-4) §164.308(a)(8); §164.308(a)(8); §164.308(a)(7)(i); §164.308(a)(7)(ii)

Access Restrictions for Change (CM-5) §164.308(a)(8); §164.308(a)(7)(i); §164.308(a)(7)(ii)

Configuration Settings (CM-6) §164.308(a)(8); §164.308(a)(7)(i); §164.308(a)(7)(ii)

Least Functionality (CM-7) §164.308(a)(3); §164.308(a)(8); §164.308(a)(7)(i); §164.308(a)(7)(ii); §164.308(a)(4); §164.310(a)(2)(iii); §164.310(b); §164.310(c); §164.312(a)(1); §164.312(a)(2)(i); §164.312(a)(2)(ii); §164.312(a)(2)(iv)

Information System Component Inventory (CM-8)

§164.308(a)(1)(ii)(D); §164.308(a)(5)(ii)(B); §164.308(a)(5)(ii)(C); §164.310(a)(1); §164.310(a)(2)(ii), §164.310(a)(2)(iii), §164.310(b), §164.310(c); §164.310(d)(1); §164.310(d)(2)(iii); §164.312(b); §164.314(b)(2)(i); §164.308(a)(1)(ii)(A); §164.310(a)(2)(ii); §164.310(d); §164.308(a)(1)(ii)(A); §164.308(a)(7)(ii)(E ); §164.310(a)(2)(ii); §164.310(a)(2)(iii); §164.310(a)(2)(iv); §164.310(d)(1); §164.310(d)(2)



Configuration Management Plan (CM-9) §164.308(a)(8); §164.308(a)(7)(i); §164.308(a)(7)(ii)

Software Usage Restrictions (CM-10) §164.308(a)(1)(ii)(D); §164.308(a)(3)(ii)(A); §164.308(a)(5)(ii)(C),;§164.312(a)(2)(i); §164.312(b); §164.312(d); §164.312(e)

User-Installed Software (CM-11) §164.308(a)(1)(ii)(D); §164.308(a)(3)(ii)(A); §164.308(a)(5)(ii)(C),;§164.312(a)(2)(i); §164.312(b); §164.312(d); §164.312(e)

1.6 Policy (CM-1) An information security policy is a set of high-level statements intended to protect information across an organization. Contract personnel must follow HHS/CMS policies as outlined in the HHS IS2P and the CMS IS2P2. The CMS Authorizing Official (AO) must approve all deviations from HHS or CMS policy in writing. The CMS IS2P2 defines the framework and policy under which CMS protects and controls access to CMS information and information systems in compliance with HHS policy and federal law. The policy contained within the CMS IS2P2 and the procedures contained within this document satisfy the requirements for control CM-1 that requires CMS to create a policy and associated procedure related to configuration management. Specifically, the CMS IS2P2 outlines the following policies for the CM family of controls:

• CM-1 The CMS Change Control Board (CCB) Chair must coordinate with the CMS CISO and the Program to document configuration management processes and procedures to define configuration items at the system and component level (e.g., hardware, software, workstation); monitor configurations; and track and approve changes prior to implementation, including but not limited to flaw remediation, security patches, and emergency changes (e.g., unscheduled changes such as mitigating newly discovered security vulnerabilities, system crashes, replacement of critical hardware components). Baseline configurations and inventories of information systems (including hardware, software, firmware, and documentation) must be established and maintained throughout the respective system life cycles, and security configuration settings for information products employed in information systems must be established and enforced. In coordination with the CMS CCB Chair, the Program must:



• CM-1.1 Develop and maintain an effective implementation of selected information security and privacy controls and control enhancements in the Configuration Management family of controls in the ARS to:

• CM-1.1.1 Ensure configuration management procedures are consistent with applicable federal laws, executive orders, mandates, directives, regulations, and HHS and CMS policies and standards

• CM-1.1.2 Ensure scheduled changes to networks or systems are authorized prior to implementation and are not permitted outside of the configuration management process

• CM-1.1.3 Monitor system configurations and changes to ensure configuration management processes and procedures are followed

• CM-1.1.4 Evaluate the configuration management process periodically, as specified in the ARS, as part of the required FISMA reporting process to verify adequacy and effectiveness

Through the Program the CMS CISO, in coordination with the CMS CCB Chair, defines and develops policies to ensure CMS Business Owner/ISOs:

• CM-1.1.5 Implement and enforce configuration management controls for all CMS systems and networks

• CM-1.1.6 Develop, document, and maintain a current baseline configuration of each system and the system’s constituent components

• CM-1.1.7 Develop, document, and maintain an inventory of the components, both hardware and software, that includes relevant ownership information

• CM-1.1.8 Test, validate, and document proposed changes prior to implementation to assess the impact to the information security and privacy of data

• CM-1.1.9 Ensure systems categorized as “Moderate” or “High” under FIPS 199: • Retain older versions of baseline configurations as deemed necessary to

support rollback • Maintain a baseline configuration for development and test environments

to ensure development and test environments are managed separately from the operational environment

Through the program, the CMS CISO must ensure:

• CM-1.1.10 Current (up-to-date) anti-virus (AV) and host-based intrusion detection system (HIDS) applications are included, as appropriate, on systems connected to the CMS network

• CM-1.1.11 AV software is configured to automatically perform periodic virus scanning

• CM-1.1.12 HIDS software is configured to automatically scan all inbound and outbound network traffic

The CMS CCB Chair must ensure: • CM-1.1.13 All systems and system components adhere to HHS’ defined security

configuration standards.



• CM-1.1.14 Appropriate CCBs are created and managed for the review and approval of changes.

• CM-1.1.15 Configuration management includes a representative from the system as a member of the CCB. Participation on the CCB is at the Security Control Assessor’s discretion. If the ISSO or Security Control Assessor acts as a voting member of the CCB, they must be a federal employee.

• CM-1.1.16 Personnel with configuration management responsibilities are informed of CMS configuration management processes.

• CM-1.1.17 Change documentation is maintained for no less than 12 months after a change is made.

• CM-1.2 Provide methods, procedures, and standards within the RMH that facilitate implementation, assurance, and effectiveness tracking for the Configuration Management family of controls

• CM-1.3 For systems categorized as “High” under FIPS 199, ensure detection of unauthorized information security and privacy relevant configuration changes is incorporated into the incident response capability to ensure events are tracked, monitored, corrected, and available for historical purposes

CMS IS2P2 defines the framework and policy under which CMS protects and controls access to CMS information and information systems in compliance with HHS policy and federal law. The “Procedures” section of this handbook outlines the specific processes for meeting the CM security control requirements as required by the CMS IS2P2 and the CMS ARS. These procedures have been tailored based on the current CMS implementation.

1.7 Standards Standards consist of specific security control implementation requirements that enforce and support the information security policy. The CMS ARS defines CMS specific standards for each of the required NIST SP 800-53 security controls in compliance with HHS policy and the CMS IS2P2. The CMS ARS standards for the CM family of controls are outlined in Appendix D. HHS directs all Operational Divisions (OpDivs) to begin using the security configuration baselines established by the new United States Government Configuration Baselines (USGCB) and the NIST National Checklist Program (NCP). The NCP is defined by NIST Special Publication (SP) 800-70 Rev 2, “National Checklist Program for IT Products – Guidelines for Checklist Users and Developers”. Section 3.5 “Configuration Settings” below provides detailed procedures for implementing secure baselines in accordance with the USGCB and the NCP.

1.8 Guidelines Guidelines provide direction and best practices that help support the standards or serve as a reference when no standard exists. Guidelines provide guidance and best practices relative to a particular topic. Guidelines may accompany, interpret, or provide guidance for implementing CIO policies, or may provide guidance to various CMS IT Life Cycle activities. Guidelines are

Centers for Medicare & Medicaid Services Roles and Responsibilities


recommended best practices but are not required to comply with policy. A guideline aims to streamline particular processes according to a set routine or sound practice. The list below contains some examples of guidelines for the CM family:

• CMS Expedited Life Cycle (XLC) Framework

• CMS Technical Reference Architecture, Volume IV – Development and Application Services v1.0 Centers for Medicare and Medicaid Services, June 28, 2016

• Software Engineering Institute (SEI®) CMMI®

• Institute of Electrical and Electronics Engineers (IEEE) standard 729-1983 for CM

• American National Standards Institute/Electronic Industries Alliance (ANSI/EIA) 649 – National Consensus Standard for CM

• Information Technology Infrastructure Library (ITIL) Framework

• International Organization for Standardization/ International Electrotechnical Commission (ISO/IEC) 12207 Standard for Software Life Cycle Processes

2. Roles and Responsibilities A comprehensive list of information security and privacy roles and responsibilities for CMS stakeholders is contained in Section 3 Roles and Responsibilities of the CMS IS2P2. The following roles from the CMS IS2P2 are specific to the procedures contained within this handbook.

CMS Privacy Subject Matter Expert (SME) CM-4

CMS Chief Information Officer (CIO) CM-6

CMS Chief Information Security Officer (CISO)

CM-4(1); CM-6; CM-8

CMS Information System Security Officer (ISSO)

CM-2; CM-3; CM-3(1); CM-3(2); CM-4; CM-4(2); CM-5(2); CM-5(5); CM-6; CM-7;

CM-7(1); CM-7(4); CM-7(5); CM-8; CM-8(1); CM-8(2); CM-8(3); CM-8(4); CM-8(5);

CM-10; CM-10(1); CM-11

CMS Change Control Board Chair CM-2; CM-2(1); CM-2(3); CM-3; CM-3(1); CM-3(2); CM-4; CM-4(1); CM-5; CM-5(2)

CMS Cyber Risk Advisor (CRA) CM-3(1); CM-4; CM-6; CM-7(1); CM-10(1)

CMS Information Security and Privacy Group (ISPG)

CM-6(2); CM-7(2); CM-10

Centers for Medicare & Medicaid Services Roles and Responsibilities


CMS Cybersecurity Integration Center (CCIC)

CM-2(2); CM-7(4); CM-7(5); CM-8

CMS IT Service Desk CM-2(7)

CMS Office of Information Technology (OIT)

CM-5; CM-6: CM-6(1); CM-7(2)

CMS Business Owner (BO) CM-2(1); CM-2(3); CM-3; CM-3(1); CM-3(6); CM-5; CM-5(5); CM-6(1); CM-6(2);

CM-7; CM-8; CM-8(1); CM-8(2); CM-8(3); CM-8(4); CM-10(1); CM-11

CMS Federal Employee and Contractors CM-2(1); CM-2(6); CM-2(7); CM-3; CM-10

CMS Data Guardian CM-3(1); CM-4

Centers for Medicare & Medicaid Services Procedures


3. Procedures Procedures provide detailed instructions on how to implement specific security controls and meet the criteria defined in standards. This section contains the applicable procedures that facilitate the implementation of the CM family security controls as required by the CMS IS2P2 and the CMS ARS. To increase traceability, each procedure is mapped to the associated NIST controls using the control number from the CMS IS2P2. Appendix E Control/Policy Cross Reference Table shows the relationship between the NIST SP 800-53 CM Controls, CMS ARS CM Controls, CMS IS2P2 Policy, and HHS IS2P Policy.

3.1 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 Expedited Life Cycle (XLC) Planning phase.

• Step 2: The System Developer and Maintainer documents the configuration settings chosen during Step 1 in the System Design Document (SDD)3 during the Design phase of the XLC.

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. (Concept Phase, 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 (Concept, Planning Phase, see SA-3, and SA-10).

3 CMS maintains a System Design Document (SDD) template here: https://www.cms.gov/Research-Statistics-Data-

and-Systems/CMS-Information-Technology/XLC/Downloads/SystemDesignDocument.docx

https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/Downloads/SystemDesignDocument.docx

https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/Downloads/SystemDesignDocument.docx



• 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 (Planning, Requirements Analysis Phase, 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 (Requirements Analysis Phase, 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 (Requirements Analysis, Design Phase, see CA-2 and SA-11).

• Step 8: The ISSO’s organization (or their designated System Maintainer) builds out the system changes (Development Phase).

• 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. (Test Phase, 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 (Development, Test Phase, see CA-5).

• Step 11: The ISSO applies either for a new Authorization To Operate (ATO), or for an ATO update. (Implementation Phase, see CA-6).

3.1.1 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 imformation systems, CMS is supporting the cybersecurtiy 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.

Table 1: CMS Defined Parameters – Control CM-2(1)

Control Control Requirement CMS Parameter CM-2(1) The organization reviews and

updates the baseline configuration of the information system: a. [Assignment: organization-

defined frequency];

The organization reviews and updates the baseline configuration of the information system: a. At least every 180 days for High

systems or 365 days for Moderate systems;



b. When required due to [Assignment organization-defined circumstances];and

b. When configuration settings change due to critical security patches (as defined by the federal government, CMS, or vendor), upgrades and emergency changes (e.g., unscheduled changes, system crashes, replacement of critical hardware components), major system changes/upgrades;

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.

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

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


Control Control Requirement CMS Parameter CM-2(3) The organization retains

[Assignment: organization-defined previous versions of baseline

The organization retains older versions of baseline configurations of the information system as deemed



configurations of the information system] to support rollback.

necessary, by the ISSO, to support rollback.

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

3.1.4 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 Areas45. 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 Information6 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.


Control Control Requirement CMS Parameter CM-2(7) The organization: The organization:

4 The Department of State’s website of information on travel to high-risk areas is here:

https://travel.state.gov/content/passports/en/go/TraveltoHighRiskAreas.html 5 The Department of State keeps an updated list of travel alerts and warnings as the basis of the list of “high-risk”

countries which can be found here: https://travel.state.gov/content/passports/en/alertswarnings.html 6 The OSSI webpage is found here: https://intranet.hhs.gov/security/ossi/index.html Note: Must be connected to the

HHS/CMS network for the link to work.

https://intranet.hhs.gov/it/cybersecurity/policies/memo-gfe.html

https://travel.state.gov/content/passports/en/go/TraveltoHighRiskAreas.html

https://travel.state.gov/content/passports/en/alertswarnings.html

https://intranet.hhs.gov/security/ossi/index.html



a. Issues [Assignment: organization-defined information systems, system components, or devices] with [Assignment: organization-defined configurations] to individuals traveling to locations that the organization deems to be of significant risk; and

b. Applies [Assignment: organization-defined security safeguards] to the devices when the individuals return.

a. Issues dedicated information systems, system components, or devices with stringent configurations (e.g., FIPS 140-2 for encryption) to individuals traveling to locations that the organization deems to be of significant risk; and

b. Applies security safeguards to the

devices (i.e., detailed inspection of the device for physical tampering, purging or reimaging the hard disk drive/removable media) when the individuals return.

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 [email protected] 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 [email protected]

• 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 [email protected]

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

mailto:[email protected]

https://intranet.hhs.gov/security/ossi-counterintelligence/foreign-travel-list.html

https://intranet.hhs.gov/security/ossi-counterintelligence/foreign-travel-list.html



https://travel.state.gov/content/passports/en/alertswarnings.html



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

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

Table 4: CMS Defined Parameters – Control CM-3

Control Control Requirement CMS Parameter CM-3 The organization:

c. Retains records of configuration-controlled changes to the information system for [Assignment: organization-defined time period];

g. Coordinates and provides oversight for configuration change control activities through [Assignment: organization-defined configuration change control element (e.g.,

The organization: c. Retains records of configuration-

controlled changes to the information system for a minimum of three (3) years after the change;

g. Coordinates and provides oversight for configuration change control activities through change request forms which must be approved by an organizational and/or CMS change control board that convenes



committee, board)] that convenes [Selection (one or more): [Assignment: organization-defined frequency]; [Assignment: organization-defined configuration change conditions]].

frequently enough to accommodate proposed change requests, and other appropriate organization officials including, but not limited to, the System Developer/Maintainer and information system support staff.

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. The template is available here: https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/Downloads/ConfigMgmtPlan.docx .

• 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 Plan7 in conjunction with the Project Management Plan during the Planning phase of the XLC.

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

7 The template for the XLC Change Management Plan can be found here: https://www.cms.gov/Research-Statistics-

Data-and-Systems/CMS-Information-Technology/XLC/Downloads/ChangeManagementPlan.docx 8 A copy of the Change Management Plan can be accessed here: https://www.cms.gov/Research-Statistics-Data-

and-Systems/CMS-Information-Technology/XLC/Downloads/ChangeManagementPlan.docx

https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/Downloads/ConfigMgmtPlan.docx


https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/Downloads/ChangeManagementPlan.docx






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

3.2.1 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 SSP). 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.


Control Control Requirement CMS Parameter CM-3(1) The organization employs

automated mechanisms to: b. Notify [Assignment: organized-

defined approval authorities] of proposed changes to the information system and request change approval;

c. Highlight proposed changes to the information system that have not been approved or disapproved by [Assignment:

The organization employs automated mechanisms to: b. Notify designated approval

authorities (defined in the SSP) of proposed changes to the information system;

d. Highlight proposed changes that

have been waiting an approval decision, or have not been approved, for longer than change



organization-defined time period];

f. Notify [Assignment: organization-defined personnel] when approved changes to the information system are completed.

management procedure (defined in the SSP) requires;

g. Notify stakeholders when approved changes are completed. A list of potential stakeholders include, but is not limited to the following:

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 XLC Planning phase using the template found in Configuration Management CM-3 of this document. 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.

o Stakeholders to be notified upon implementation of changes (at a minimum): 1. Change Control Board (CCB) Chair 2. CRO Chief Risk Officer (CRO) 3. Cyber Risk Advisor (CRA) 4. Business Owner(BO) 5. Program Manager 6. Data Guardian (DG) 7. Information System Owner (ISO) 8. 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 SSP for handling changes, to determine highlighting rules for CRs that have not been addressed or have not been approved within the designated period.

3.2.2 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 to be outlined in the Test Plan9 in section 5 in the environment from section 10 during the Development phase of the XLC 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.

9 To retrieve a copy of the Test Plan template, go to this link: https://www.cms.gov/Research-Statistics-Data-and-

Systems/CMS-Information-Technology/XLC/Downloads/TestPlan.docx

https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/Downloads/TestPlan.docx

https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/Downloads/TestPlan.docx



3.3 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 (via the TRB review process of the XLC) 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.10 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. Develop a high-level architecture overview that shows how the change will be implemented. If the change has already occurred (unscheduled/unauthorized), 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 type of change and if the change(s) is categorized as an application, network, or environmental change(s) (multiple categorizations are possible). The following checklists may assist with that identification:

Figure 3: Application Change Checklist

10 NIST SP 800-137 http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-137.pdf

http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-137.pdf



Figure 4: Network Change Checklist

Figure 5: Environmental Change Checklist

• 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. The following is a template to help document this procedure:

What are the business requirements driving the change?

Please provide a description of the proposed change(s), including ALL additions, deletions, and modifications.



Is the Technical Lead and/or Project Lead aware of any potential security-related issues or challenges associated with this change? If so, briefly describe them or provide an attachment describing them.

Figure 6: Risk Assessment Template

The following is a list of controls that may be impacted by the proposed change: AC: Will change(s) to system effect how the system limits: (i) information system access to authorized users, processes acting on behalf of authorized users or devices (including other information systems); and (ii) the types of transactions and functions that authorized users are permitted to exercise. If so, describe. AT: Will change(s) affect required system training to ensure that personnel are adequately trained to carry out their assigned information security-related duties and responsibilities? If so, describe. AU: Will change(s) affect how system audit requirements to (i) create, protect, and retain information system audit records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful, unauthorized, or inappropriate information system activity; and (ii) ensure that the actions of individual information system users can be uniquely traced to those users so they can be held accountable for their actions. If so, describe. CM: Will change(s) to the system impact the (i) baseline configuration and inventory of organizational information systems; (ii) establishment and enforcement of security configuration settings; and (iii) ability to monitor and control changes to the baseline configurations and to the constituent components of the systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycle. If so, describe. IA: Will change(s) to the system impact how it (i) identifies users, processes acting on behalf of users, or devices; and (ii) authenticates (or verifies) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems. If so, describe. MA: Will change(s) to the system impact how (i) periodic and timely maintenance is performed; and (ii) provide effective controls on the tools, techniques, mechanisms, and personnel used to conduct information system maintenance. If so, describe. MP: Will change(s) to the system impact how (i) information contained in the systems in printed form or on digital media is protected; (ii) access to information in printed form or on digital media removed from the systems is limited to authorized users; and (iii) how digital media is sanitized or destroyed before disposal or release for reuse. If so, describe. PE: Will change(s) to the system/system environment change how (i) physical access to information systems, equipment, and the respective operating environments is limited to authorized individuals; (ii) the physical plant and support infrastructure for information systems is protected; (iii) supporting utilities for information systems is provided; (iv) and (v) appropriate environmental controls in facilities are provided. If so, describe.



SC: Will change(s) to the system effect how: (i) communications (i.e., information transmitted or received by organizational information systems) are monitored, controlled, and protected at the external boundaries and key internal boundaries of the information systems; and (ii) architectural designs, software development techniques, and systems engineering principles that promote effective information security are implemented. If so, describe. SI: Will change(s) to the system effect how (i) system flaws are identified, reported, and corrected in a timely manner; (ii) malicious code protection is employed; (iii) system events are monitored and detected; (iv) the correct operation of security functions is verified; and (v) information is checked for accuracy, completeness, validity, and authenticity. If so, describe.

Figure 7: Security Control Change Template

• 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. Also, reference Appendix I for examples of significant changes and change management.

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.

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

3.4 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 planning phase of the XLC including:

o Administrative controls – Such as procedures, processes and standards to be used in configuration management

o Role-based Access Controls – Such as those on files and storage related to change documentation

o Discretionary Access Controls – Such as those approving the appropriate personnel to approve changes to the system

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

3.4.1 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. These development activities should be planned starting with the XLC Concept phase.

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

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

Table 6: CMS Defined Parameters - Control CM-5(2)

Control Control Requirement CMS Parameter CM-5(2) The organization reviews

information system changes [Assignment: organization-defined frequency] and [Assignment: organization-defined circumstances] to determine whether unauthorized changes have occurred.

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.

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

3.5 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 Guidance11 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 Baseline12 (USGCB) will be applied to the applicable systems. For those systems not covered under USGCB, the National Checklist Program13 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.

Table 8: CMS Defined Parameters - Control CM-6

Control Control Requirement CMS Parameter

CM-6 The organization: a. 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;

b. Identifies, documents, and approves any deviations from established configuration settings for [Assignment:

The organization: a. 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;

c. Identifies, documents, and approves any deviations from established configuration

11 The HHS Minimum Security Configurations Standard Guidance us available on OMB Max at:

https://community.max.gov/display/HHS/HHS+CyberSecurity+Policy+Collaboration+Page 12 For more information on the U.S. Government Configuration Baseline, visit the website:

https://usgcb.nist.gov/index.html 13 To access the National Checklist Program Repository of all publicly released checklists from NIST go to:

https://web.nvd.nist.gov/view/ncp/repository

https://community.max.gov/display/HHS/HHS+CyberSecurity+Policy+Collaboration+Page

https://usgcb.nist.gov/index.html

https://web.nvd.nist.gov/view/ncp/repository



Control Control Requirement CMS Parameter organization-defined information system components] based on [Assignment: organization-defined operational requirements];

settings for individual components within the information system based on explicit operational requirements (defined in the system security plan [SSP]);

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:

1 HHS Minimum Security Configuration Standards Guidance 2 USGCB14 3 NIST NCP – Tier IV, then III, II, I in descending order 4 Technical Reference Architecture Volume IV – Development and Application Services 5 DISA Security Technical Implementation Guide (STIG) 6 NSA STIG 7 Lacking a Federal government-authored checklist, using an industry group or vendor checklist (Such as Center for Internet Security (CIS) benchmarks15) 8 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).

14 Information about the U.S. Government Configuration Baselines and downloadable content can be found here:

https://usgcb.nist.gov/ 15 For a list of the latest Center for Internet Security benchmarks visit this site:

https://benchmarks.cisecurity.org/downloads/latest/

https://usgcb.nist.gov/

https://benchmarks.cisecurity.org/downloads/latest/



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

o If USGCB does not apply, then they use the CIS benchmarks as guides to create the most restrictive mode consistent with operational requirements.

o 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 (SCAP16) 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 tool17 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:

o Are not intended to be implemented since the standard(original baseline) setting would interfere with business operations

o Are cost prohibitive o Are technically infeasible o Have an impact to operations o Cause a loss of functionality

• Step 2: The ISSO reviews the collected deviation(s) 18documented 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 30 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

16 For more information on Security Content Automation Protocol or SCAP visit: https://scap.nist.gov/ 17 The details on the SCAP validation program for tools can be found here: https://scap.nist.gov/validation/index.html 18 CMS can implement more restrictions but not less than HHS departmental guidance in most information systems.

The current HHS deviations for Windows baselines are listed in this document: https://intranet.hhs.gov/it/cybersecurity/docs/policies_guides/FDCC/hhs_fdcc_deviations_11052008.pdf

https://scap.nist.gov/

https://scap.nist.gov/validation/index.html

https://intranet.hhs.gov/it/cybersecurity/docs/policies_guides/FDCC/hhs_fdcc_deviations_11052008.pdf



be considered for the information system in Section 2 Weaknesses with the following information at a minimum:

o Allocated Control = CM-6 o Finding Description o Weakness Description o 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:

o Overview of the Risk Acceptance Request o Business Justification for the Risk Acceptance o Justification for Request o 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.

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



automated mechanisms to centrally manage, apply, and verify

The organization employs automated mechanisms to centrally manage, apply, and verify configuration



Control Control Requirement CMS Parameter configuration settings for [Assignment: organization-defined information system components].

settings for information system components as defined in the HHS Minimum Security Configuration Standards for Departmental Operating Systems and Applications.

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.

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



[Assignment: organization-defined security safeguards] to respond to unauthorized changes to [Assignment: organization-defined configuration settings].

The organization responds to unauthorized changes to information system and components (e.g., authorization, auditing, processing types, baselines) and data (e.g., system



Control Control Requirement CMS Parameter libraries, log files, executables) in the following ways:

a. Alert responsible actors (person, organization);

b. Restore to approved configuration; and

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

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





CM-7 The organization: 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].

The organization: b. 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.

c. [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 follow the procedures in RMH Chapter 15: System and Services Acquisition section 3.6.2 for the system or refers to the system’s System Design Document section 7 and 9 to be completed in the Design phase of the XLC.

• 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. This is done during the Development phase of the XLC.

• 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 through the Development to the Disposition phase of the XLC 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.

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


Control Control Requirement CMS Parameter CM-7(1) The organization:

a. Reviews the information system [Assignment: organization-defined frequency] to identify unnecessary and/or non-secure functions, ports, protocols, and services; and

b. Disables [Assignment: organization-defined functions, ports, protocols, and services within the information system deemed to be unnecessary and/or non-secure].

The organization: a. Reviews the information system no

less often than once every thirty (30) days to identify and eliminate unnecessary functions, ports, protocols, and/or services;

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

c. 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 XLC Disposition. 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 starting with the Development phase of the XLC.

3.6.2 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:

1. Licensed for use 2. Configured for use at CMS 3. 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.


Control Control Requirement CMS Parameter CM-7(2) 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.

http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/testing.html


http://intranet.cms.gov/Component/OIS/Systems-and-Services/enterprise-software-licensing/index.html




http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/requests.html

http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/requests.html

http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/process.html




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

3.6.3 Authorized Software/Whitelisting (CM-7(5)) The authorized software whitelisting 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 a whitelist instead of a blacklist 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 a whitelist 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/Whitelisting.



a. Identifies [Assignment: organization-defined software programs authorized to execute on the information system];

c. Reviews and updates the list of authorized software programs [Assignment: organization-defined frequency].

The organization: a. Identifies defined software programs

(defined in the applicable security plan) authorized to execute on the information system;

c. Reviews and updates the list of authorized software programs no less often than every seventy-two (72) hours; and

d. [Added] Receives automated updates from a trusted source.

The following steps detail the CMS specific process for Authorizing Software or Whitelisting: Note: If no blacklisting solution is in place, then a whitelisting 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 whitelisting 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 whitelisting 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 whitelisting 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 whitelisting tool.

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



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

b. Reviews and updates the information system component inventory [Assignment: organization-defined frequency].

The organization:

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

4. Includes: - 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);

- Manufacturer/model information; - 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; - Ownership; - Operational status; - Primary and secondary administrators;

and b. - Primary user.Reviews and updates the

information system component



Control Control Requirement CMS Parameter 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)

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

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

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

3.7.3 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:

1. Prevent access to the component 2. Effectively disconnect the component from the network 3. Isolate the component 4. Notify responsible party as specified by the SSP

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.



a. Employs automated mechanisms [Assignment: organization-defined frequency] to detect the presence of unauthorized hardware, software, and firmware components within the information system; and

The organization: a. Employs automated

mechanisms no less than weekly to detect the presence of unauthorized hardware, software, and firmware components within the information system; and



Control Control Requirement CMS Parameter b. 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]].

b. 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.)

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





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.

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



3.8 Configuration Management Plan (CM-9) The XLC incorporates a configuration management plan into the planning process, written during the Planning phase. 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 the configuration management plan using the template found here: https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/Downloads/ConfigMgmtPlan.docx . This will be done during the Planning phase of the XLC.

• Step 2: The Program/Project Manager documents roles and responsibilities in the template for the plan in section 4.2 Roles & Responsibilities.

• Step 3: The Program/Project Manager defines the processes and procedures involved with configuration management in the template for the plan in sections 5 Configuration Management Administration and 4.1 Methods and Tools. This includes section 5.1 to define the process for identifying CIs.

• Step 4: The Program/Project Manager lists CIs for the information system in the System Design Document in section 4.2 for hardware configuration items and 4.3 for software configuration items.

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

3.9 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 includes19:

o Approved purchase record o Certified receipt or invoice o Validated HHS Form 393 (Purchase/Service/Stock Requisition Form) o CMS credit card invoice o Vendor proof of license purchase certificate o Vendor end-user authorization form for volume licensing o Vendor-provided notice of software purchase o End-user license agreement o Enterprise Software Licensing20

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

19 The CMS list of proof of purchase artifacts and “Above Core Software Request” process can be found here:

http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/process.html 20 The list of licensed software for the CMS Enterprise can be found here:




http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/Documents/Tested-Software-List.pdf

http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/Documents/Tested-Software-List.pdf





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

3.10 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 SSP 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 SSP. 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.

Table 18: CMS Defined Parameters – Control CM-11


a. Establishes [Assignment: organization-defined policies] governing the installation of software by users; b. Enforces software installation policies through [Assignment:

The organization: a. Prohibits the installation of software by users on all GFE; b. Enforces software installation policies through organization-defined methods (defined in the SSP); and



organization-defined methods]; and c. Monitors policy compliance at [Assignment: organization-defined frequency].

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 whitelist) 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 whitelist) 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. CDM standards can be gathered from the point of contact in Appendix G.

• 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 whitelist) and prevent all other user installations of software.

Centers for Medicare & Medicaid Services Acronyms


Appendix A. Acronyms

Selected acronyms used in this document are defined below.

Acronyms Terms

ARS Acceptable Risk Safeguards

BO Business Owner

CCB Change Control Board

CCIC CMS Cybersecurity Integration Center

CDM Continuous Diagnostics and Mitigation

CFACTS CMS FISMA Controls Tracking System

CIO Chief Information Officer

CIS Center for Internet Security

CISO Chief Information Security Officer

CM Configuration Management

CMMI Capability Maturity Model Integration

CRA Cyber Risk Advisor

CRO Chief Risk Officer

CSP Cloud Service Provider

DAA Designated Approval Authorities

DHS Department of Homeland Security

FISMA Federal Information Security Management Act (2002) or Federal Information Security Modernization Act (2014)

FMAT Forensics and Malware Analysis Team

GFE Government Furnished Equipment

HHS U.S. Department of Health and Human Services

HIDS Host-Based Intrusion Detection

IEEE Institute of Electrical and Electronics Engineers

IS Information Security

IS2P Information Systems Security and Privacy (HHS)

IS2P2 Information Systems Security and Privacy Policy (CMS)

ISCM Information Security Continuous Monitoring

ISO Information System Owner

ISO/IEC International Organization for Standardization/International Electrotechnical Commission

ISPG Information Security and Privacy Group

Centers for Medicare & Medicaid Services Acronyms


Acronyms Terms

ISSO Information Systems Security Officer

ITIL Information Technology Infrastructure Library

MAC Media Access Control

NCP National Checklist Program

NIST National Institute of Standards and Technology

NSA National Security Agency

OCIO Office of the Chief Information Officer

ODP Organizationally Defined Parameter

OIT Office of Information Technology

OMB Office of Management and Budget

OS Operating System

OSS Open Source Software

PIA Privacy Impact Analysis

POA&M Plans of Action and Milestones

POC Point of Contact

RMH Risk Management Handbook

SCAP Security Content Automation Protocol

SDD System Design Document

SEI Software Engineering Institute

SIA Security Impact Analysis

SO System Owner

SOC Security Operations Center

SOP Senior Official for Privacy

SSP System Security Plan

STIG Security Technical Implementation Guide

USGCB U.S. Government Configuration Baseline

XLC Expedited Life Cycle

Centers for Medicare & Medicaid Services Glossary of Terms


Appendix B. Glossary of Terms

Selected terms and definitions in this document are defined below (e.g. Breach and a brief definition of its meaning).

Terms Definitions

Acceptable Risk Safeguards

CMS Information Security Acceptable Risk Safeguards (ARS), formerly CMS Minimum Security Requirements (CMSR), https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Information-Security-Library.html.

Authorizing Official Official with the authority to formally assume responsibility for operating an information system at an acceptable level of risk to agency operations (including mission, functions, image, or reputation), agency assets, or individuals.

Centers for Medicare & Medicaid Services

CMS covers 100 million people through Medicare, Medicaid, the Children's Health Insurance Program, and the Health Insurance Marketplace.

Chief Information Officer 1. Agency official responsible for:

• Providing advice and other assistance to the head of the executive agency and other senior management personnel of the agency to ensure that information technology is acquired and information resources are managed in a manner that is consistent with laws, Executive Orders, directives, policies, regulations, and priorities established by the head of the agency;

• Developing, maintaining, and facilitating the implementation of a sound and integrated information technology architecture for the agency; and

• Promoting the effective and efficient design and operation of all major information resources management processes for the agency, including improvements to work processes of the agency

Chief Information Security Officer

The incumbent in the position entitled Chief Information Security Officer.

The CISO must be an agency official (federal government employee) and must fulfill all of the responsibilities identified in the HHS IS2P Appendix A Section 11, OpDiv CISOs. The CISO carries out the CIO’s information security responsibilities under federal requirements in conjunction with the SOP.

CMS Cybersecurity Integration Center

The CCIC monitors, detects, and isolates information security and privacy incidents and breaches across the CMS enterprise IT environment. The CCIC provides continual situational awareness of the risks associated with CMS data and information systems throughout CMS. The CCIC also provides timely, accurate, and meaningful reporting across the technical, operational, and executive spectrum.



Terms Definitions

CMS FISMA Controls Tracking System

CFACTS is a CMS database that maintains current FISMA information (e.g., POCs, artifacts) to support organizational requirements and processes (e.g., communication, contingency planning, training, data calls).

CMS IT Service Desk For the purposes of configuration management, the CMS IT Service Desk is a sub-component of the CMS Office of Information Technology, whose responsibilities include but are not limited to the following:

• Act as the manager of GFEs to control their configuration and prevent unauthorized changes from take place

• Control the installation of software and ensure that the software used is used lawfully

Cyber Risk Advisor Act as Subject Matter Expert in all areas of the CMS Risk Management Framework (RMF).

Department of Health and Human Services

The United States Department of Health and Human Services (HHS), also known as the Health Department, is a cabinet-level department of the U.S. federal government with the goal of protecting the health of all Americans and providing essential human services. Its motto is “Improving the health, safety, and well-being of America”. Before the separate federal Department of Education was created in 1979, it was called the Department of Health, Education, and Welfare (HEW).

Deviation When the system differs in regards to established configuration standards

eXpedited Life Cycle The XLC provides the processes and practices of the CMS system development life cycle in accordance with the CMS Policy for Information Technology (IT) Investment Management & Governance. The CMS CISO maintains the RMH Volume 1 Chapter 1, Risk Management, in the XLC to document the CMS information system life cycle, in accordance with the RMF.

Government Furnished Equipment

Equipment in the possession of, or directly acquired by, the Government and subsequently furnished to the contractor for performance of a contract. Government-furnished equipment includes, but is not limited to, spares and tangible items that are functionally complete for its intended purpose, durable, nonexpendable, and needed for the performance of a contract. “Equipment” is not intended for sale, and does not ordinarily lose its identity or become a component part of another article when put into use. Equipment also does not include material, real property, special test equipment or special tooling. Government-furnished Equipment also includes contractor-acquired property if the contractor-acquired property is a deliverable under a cost contract when accepted by the Government for continued use under the contract.



Terms Definitions

Health Insurance Portability and Accountability Act of 1996

An act that amended the Internal Revenue Code of 1986 to improve portability and continuity of health insurance coverage in the group and individual markets; to combat waste, fraud, and abuse in health insurance and health care delivery; to promote the use of medical savings accounts; to improve access to long-term care services and coverage; to simplify the administration of health insurance; and for other purposes.

High Value Asset High Value Assets are those assets, Federal information systems, information, and data for which an unauthorized access, use, disclosure, disruption, modification, or destruction could cause a significant impact to the United States’ national security interests, foreign relations, economy, or to the public confidence, civil liberties, or public health and safety of the American people. HVAs may contain sensitive controls, instructions, data used in critical Federal operations, or unique collections of data (by size or content), or support an agency’s mission essential functions, making them of specific value to criminal, politically motivated, or state sponsored actor for either direct exploitation or to cause a loss of confidence in the U.S. Government.

Incident A violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices

Incident Management Team CMS IMT provides 24X7 incident management support for the enterprise. It is a single communication point for CMS leadership for security incidents and updates.

Information System Security Officer

Person responsible for ensuring the security of an information system throughout its life cycle, from design through disposal. Synonymous with System Security Officer (SSO).

Individual assigned responsibility by the Senior Agency Information Security Officer, authorizing official, management official, or Information System Owner for maintaining the appropriate operational security posture for an information system or program.

Information Systems Security and Privacy Policy

This Policy provides direction to all CMS employees, contractors, and any individual who receives authorization to access CMS information technology (IT) systems or systems maintained on behalf of CMS to assure the confidentiality, integrity, and availability of CMS information and systems. As the federal agency responsible for administering the Medicare, Medicaid, Children’s Health Insurance Program (CHIP), and Health Insurance Marketplace (HIM); CMS collects, creates, uses, discloses, maintains, and stores personal, healthcare, and other sensitive information subject to federal law, regulation, and guidance.

Information Technology The term information technology with respect to an executive agency means any equipment or interconnected system or subsystem of

https://policy.cio.gov/hva/definition/



Terms Definitions equipment, used in the automatic acquisition, storage, analysis, evaluation, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by the executive agency. Also, if the equipment is used by the executive agency directly or is used by a contractor under a contract with the executive agency that requires the use of that equipment; or of that equipment to a significant extent in the performance of a service or the furnishing of a product; includes computers, ancillary equipment (including imaging peripherals, input, output, and storage devices necessary for security and surveillance), peripheral equipment designed to be controlled by the central processing unit of a computer, software, firmware and similar procedures, services (including support services), and related resources; but does not include any equipment acquired by a federal contractor incidental to a federal contract.

Any equipment or interconnected system or subsystem of equipment that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by the executive agency. For purposes of the preceding sentence, equipment is used by an executive agency if the equipment is used by the executive agency directly or is used by a contractor under a contract with the executive agency which: (i) requires the use of such equipment; or (ii) requires the use, to a significant extent, of such equipment in the performance of a service or the furnishing of a product. The term information technology includes computers, ancillary equipment, software, firmware, and similar procedures, services (including support services), and related resources.

National Checklist Program This program, sponsored by NIST, collects lists of secure configurations for commonly used operating systems and software. The lists conform to varying tiers that denote their ability to be automated through SCAP with Tier 1 having no automation capability and Tier 4 as fully compatible with SCAP validated tools.

Office of Management and Budget

The Office of Management and Budget (OMB) designated the Department of Homeland Security (DHS) and the National Institute of Standards and Technology (NIST) as authorities to provide guidance to federal agencies for implementing information security and privacy laws and regulations, including FISMA, the Health Insurance Portability and Accountability Act of 1996 (HIPAA), and the Privacy Act of 1974 (“Privacy Act”). This Policy addresses CMS applicable information security and privacy requirements arising from federal legislation, mandates, directives, executive orders, and Department of Health and Human Services (HHS) policy by integrating NIST SP-800-53v4, Security and Privacy Controls for Federal Information Systems and Organizations, with the Department of Health and Human Services Information Systems Security and Privacy Policy (IS2P) and specific programmatic legislation and CMS regulations. Appendix C lists these authoritative references.



Terms Definitions

Organizationally Defined Parameter

Used in the NIST 800-53 document to allow customization of security controls. ODPs are used frequently when describing security controls that provide protections for security or privacy. The ODP prompts an organization to pick among choices provided in a list and/or create their own method of protecting the security and privacy of a system when implementing the security control.

Privacy Impact Analysis Analysis of how information is handled to: 1. Ensure handling conforms to applicable legal, regulatory, and policy requirements regarding privacy. 2. Determine the risks and effects of collecting, maintaining, and disseminating information in identifiable form in an electronic information system. 3. Examine and evaluate protections and alternative processes for handling information to mitigate potential privacy risks. (Source: OMB Memorandum 03-22, Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002, September 26, 2003.)

Protected Health Information

Individually identifiable health information that is:

• Transmitted by electronic media, • Maintained in electronic media, or • Transmitted or maintained in any other form or medium.

Note: PHI excludes individually identifiable health information in employment records held by a covered HIPAA entity in its role as employer.

Personal Identifiable Information

Any information about an individual including, but not limited to, education, financial transactions, medical history, and criminal or employment history, and information which can be used to distinguish or trace an individual’s identity, such as the name, social security number, date and place of birth, mother’s maiden name, biometric records, etc., including any other personal information, which is linked or linkable to an individual.

Information which can be used to distinguish or trace an individual’s identity, such as the name, social security number, biometric records, etc. alone, or when combined with other personal or identifying information which is linked or linkable to a specific individual, such as date and place of birth, mother’s maiden name, etc.

Risk The likelihood that a threat will exploit a vulnerability. For system may not have a backup power source; hence, it is vulnerable to a threat, such as thunderstorm, which creates a risk.

Risk Management Handbook

The Risk Management Handbook (RMH) compiles CMS standards, requirements, directives, practices, and procedures for protecting CMS information and information systems.

Rules of Behavior Guidelines describing permitted actions by users and the responsibilities when utilizing a computer system.



Terms Definitions The rules that have been established and implemented concerning use of, security in and acceptable level of risk for the system. Rules will clearly delineate responsibilities and expected behavior of all individuals with access to the system.

Rules should cover such matters as work at home, dial-in access, connection to the Internet, use of copyrighted works, unofficial use of federal government equipment, the assignment, and limitation of system privileges, and individual accountability.

Security Content Automation Protocol

SCAP is a suite of protocols and formats developed by NIST that enables security content, such as vulnerabilities or weaknesses, to be compiled in computer readable formats to enable automatic analysis and possible mitigation of security vulnerabilities.

Security Impact Analysis The analysis conducted by an organizational official to determine the extent to which changes to the information system will affect the security state of the system. These are conducted as part of the eXpedited Life Cycle (XLC) to ensure that security and privacy functional (and nonfunctional) requirements are identified and addressed during the development and testing of the system. The purpose of the SIA is to identify impacts of proposed system changes in order to develop additional security design requirements necessary to minimize the impact of proposed system changes.

Senior Official for Privacy The SOP must be an agency official (federal government employee) and must fulfill all of the responsibilities identified in the HHS IS2P Appendix A Section 15, OpDiv SOP. The SOP carries out the CIO’s privacy responsibilities under federal requirements in conjunction with the CISO.

Test An evaluation tool that uses quantifiable metrics to validate the operability of a system or system component in an operational environmental specified in an IT plan.

Test Plan A document that outlines the specific steps that will be performed for a particular test, including the required logistical items and expected outcome or response for each step.

Threat(s) The potential to cause unauthorized disclosure, changes, or destruction to an asset.

• Impact: potential breach in confidentiality, integrity, failure and unavailability of information

• Types: natural, environmental, and man-made

Virus A type of malicious software (Malware) that is propagated via a triggering mechanism (e.g., event time) with a mission (e.g., delete files, corrupt data, send data).

Vulnerabilities Any flaw or weakness that can be exploited and could result in a breach or a violation of a system’s security policy.

Centers for Medicare & Medicaid Services Applicable Laws and Guidance


Appendix C. Applicable Laws and Guidance

Appendix C provides references to both authoritative and guidance documentation supporting the “document.” Subsections are organized to “level of authority” (e.g., Statutes take precedence over Federal Directives and Policies). The number on each reference represents a mapping that uniquely identifies the reference within the main body of the document. The brackets [#] in the Roles and Responsibilities section are the actual brackets in the “Policy.” In this document, brackets serve as an example of how the brackets will appear in both sections of the document.

C.1 Statutes

1 Federal Information Security Modernization Act (FISMA) of 2014 https://www.congress.gov/bill/113th-congress/senate-bill/2521

2 Health Insurance Portability and Accountability Act of 1996 (HIPAA)

http://www.hhs.gov/hipaa/

3 IRS Publication 1075 (October 2014) https://www.irs.gov/pub/irs-pdf/p1075.pdf

4 The Privacy Act of 1974, as amended (5 U.S.C. 552a) http://www.cms.gov/Research-Statistics-Data-and-Systems/Computer-Data-and-Systems/Privacy/PrivacyActof1974.html

5

Health Information Technology for Economic and Clinical Health (HITECH) Act of 2009 https://www.healthit.gov/sites/default/files/hitech_act_excerpt_from_arra_with_index.pdf (Starts Pg. 6)

C.2 Federal Directives and Policies 1 Code: 5 U.S.C. §552a(e)(10)

http://www.gpo.gov/fdsys/granule/USCODE-2010-title5/USCODE-2010-title5-partI-chap5-subchapII-sec552a/content-detail.html

2 E-Government Act of 2002 (Pub. L. No. 107-347) § 208 https://www.gpo.gov/fdsys/pkg/PLAW-107publ347/content-detail.html

3 FedRAMP Rev. 4 Baseline

https://www.congress.gov/bill/113th-congress/senate-bill/2521

http://www.hhs.gov/hipaa/

https://www.irs.gov/pub/irs-pdf/p1075.pdf

http://www.cms.gov/Research-Statistics-Data-and-Systems/Computer-Data-and-Systems/Privacy/PrivacyActof1974.html

http://www.cms.gov/Research-Statistics-Data-and-Systems/Computer-Data-and-Systems/Privacy/PrivacyActof1974.html

https://www.healthit.gov/sites/default/files/hitech_act_excerpt_from_arra_with_index.pdf



https://www.gpo.gov/fdsys/pkg/PLAW-107publ347/content-detail.html



https://www.fedramp.gov/files/2015/03/FedRAMP-Control-Quick-Guide-Rev4-FINAL-01052015.pdf

C.3 OMB Policy and Memoranda 1 OMB Circular A-130 Management of Federal Information Resources

http://www.whitehouse.gov/omb/circulars_a130_a130trans4/

2 OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002 (OMB Memorandum M-03-22) https://obamawhitehouse.archives.gov/omb/memoranda_m03-22/

3 OMB M-16-03, Fiscal Year 2015-2016 Guidance on Federal Information Security and Privacy Management Requirements https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/memoranda/2016/m-16-03.pdf

4 OMB M-16-04, Cybersecurity Strategy and Implementation Plan (CSIP) for the Federal Civilian Government http://www.thecre.com/forum4/wp-content/uploads/2015/11/OMB-Cybersecurity-Implementation-Plan.pdf

C.4 NIST Guidance and Federal Information Processing Standards 1 NIST SP 800-37 Guide for Applying the risk Management Framework to Federal

Information Systems http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf

2 NIST SP 800-40 r3, Creating a Patch and Vulnerability Management Program http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-40r3.pdf

3 NIST SP 800-53-r4, Security and Privacy Controls for Federal Information Systems and Organizations http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf

4 NIST SP 800 53Ar4 Guide for Assessing the Security Controls in Federal Information Systems http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf



http://www.whitehouse.gov/omb/circulars_a130_a130trans4/

https://obamawhitehouse.archives.gov/omb/memoranda_m03-22/

https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/memoranda/2016/m-16-03.pdf

https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/memoranda/2016/m-16-03.pdf

http://www.thecre.com/forum4/wp-content/uploads/2015/11/OMB-Cybersecurity-Implementation-Plan.pdf

http://www.thecre.com/forum4/wp-content/uploads/2015/11/OMB-Cybersecurity-Implementation-Plan.pdf

http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-40r3.pdf


http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf



5 NIST SP 800-70 r3 National Checklist Program for IT Products — Guidelines for Check list Users and Developers http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-70r3.pdf

C.5 HHS Policy 1 HHS-OCIO-2014-0001 HHS Information System Security and Privacy Policy (HHS

IS2P) HHS Information Security and Privacy Policy (IS2P) – 2014 Edition. If you are having a problem obtaining a copy of this document, please email [email protected]

C.6 CMS Policy and Directives 1 CMS Information Systems Security and Privacy Policy (IS2P2)


2 Risk Management Manual Volume II Procedure 1.1 Accessing the CFACTS https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Downloads/RMH_VII_1-1_Accessing_CFACTS.pdf

C.7 Associated CMS Resources 1 HHS Departmental Security Policy and Standard Waiver Form

http://intranet.hhs.gov/it/cybersecurity/policies/index.html (Accessible via intranet only)

2 CMS Policy for Acceptable Use of CMS Desktop/Laptop and Other IT Resources https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/CIO-Directives-and-Policies/CIO-IT-Policy-Library-Items/Policy-CMS-Policy-for-the-Acceptable-Use-of-CMS-Desktop-Laptop-and-Other-IT-Resources.html

3 CMS Technical Reference Architecture – Volume 1 – Foundation 2017 Release 1 – Version 1.0, October 11, 2017

https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/CIO-Directives-and-Policies/CIO-IT-Policy-Library-Items/TRA-Volume-I-%E2%80%93-Foundation.html?DLPage=3&DLEntries=10&DLSort=0&DLSortDir=ascending




https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Downloads/RMH_VII_1-1_Accessing_CFACTS.pdf

https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Downloads/RMH_VII_1-1_Accessing_CFACTS.pdf

http://intranet.hhs.gov/it/cybersecurity/policies/index.html

https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/CIO-Directives-and-Policies/CIO-IT-Policy-Library-Items/Policy-CMS-Policy-for-the-Acceptable-Use-of-CMS-Desktop-Laptop-and-Other-IT-Resources.html









4 CMS Technical Reference Architecture – Volume 2 – Network Services 2017 Release 1 – Version 1.0, October 11, 2017 https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/CIO-Directives-and-Policies/CIO-IT-Policy-Library-Items/TRA-Volume-II-%E2%80%93-Network-Services.html?DLPage=3&DLEntries=10&DLSort=0&DLSortDir=ascending

5 CMS Technical Reference Architecture – Volume 3 – Infrastructure Services 2017 Release 1 – Version 1.0, October 11, 2017 https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/CIO-Directives-and-Policies/CIO-IT-Policy-Library-Items/TRA-Volume-III-Infrastructure-Services.html?DLPage=3&DLEntries=10&DLSort=0&DLSortDir=ascending

6 CMS Technical Reference Architecture – Volume 4 – Development and Application Services 2017 Release 1 – Version 1.0, October 11, 2017 https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/CIO-Directives-and-Policies/CIO-IT-Policy-Library-Items/TRA-Volume-IV-Development-and-Application-Services.html?DLPage=3&DLEntries=10&DLSort=0&DLSortDir=ascending

7 CMS Technical Reference Architecture – Volume 5 – Data Management 2017 Release 1 – Version 1.0, October 11, 2017 https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/CIO-Directives-and-Policies/CIO-IT-Policy-Library-Items/TRA-Volume-V-Data-Management.html?DLPage=3&DLEntries=10&DLSort=0&DLSortDir=ascending

8 CMS Expedited Life Cycle (XLC) https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/index.html

9 Technical Review Board Charter Version: 3.0 Last Modified: September 5, 2014 http://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/Downloads/TRBCharter.pdf

https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/CIO-Directives-and-Policies/CIO-IT-Policy-Library-Items/TRA-Volume-II-%E2%80%93-Network-Services.html?DLPage=3&DLEntries=10&DLSort=0&DLSortDir=ascending




https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/CIO-Directives-and-Policies/CIO-IT-Policy-Library-Items/TRA-Volume-III-Infrastructure-Services.html?DLPage=3&DLEntries=10&DLSort=0&DLSortDir=ascending




https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/CIO-Directives-and-Policies/CIO-IT-Policy-Library-Items/TRA-Volume-IV-Development-and-Application-Services.html?DLPage=3&DLEntries=10&DLSort=0&DLSortDir=ascending




https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/CIO-Directives-and-Policies/CIO-IT-Policy-Library-Items/TRA-Volume-V-Data-Management.html?DLPage=3&DLEntries=10&DLSort=0&DLSortDir=ascending




https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/index.html

https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/index.html

http://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/Downloads/TRBCharter.pdf

http://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/Downloads/TRBCharter.pdf



10 Centers for Medicare & Medicaid Services (CMS) Information Security (IS) Authorization To Operate Package Guide for more information on ATO Packages. Systems/CMS-Information-Technology/InformationSecurity/downloads/ATO Package_Guide.pdf

http://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/downloads/ATO_Package_Guide.pdf

http://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/downloads/ATO_Package_Guide.pdf

Centers for Medicare & Medicaid Services ARS Standards – Configuration Management (CM)


Appendix D. ARS Standards – Configuration Management (CM)

Control Number Baseline Control Name CMS Control Privacy Controls CSP/FedRAMP

Control CM-1 High,

Moderate, Low

Configuration Management Policy and Procedures

The organization: a. Develops, documents, and disseminates to applicable personnel: 1. A configuration management policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and 2. Procedures to facilitate the implementation of the configuration management policy and associated configuration management controls; and b. Reviews and updates (as necessary) the current: 1. Configuration management policy within every three (3) years; and 2. Configuration management procedures within every three (3) years.

CM-2 High, Moderate, Low

Baseline Configuration The organization develops, documents, and maintains under configuration control, a current baseline configuration of the information system.

CM-2(1) High, Moderate

Reviews and Updates The organization reviews and updates the baseline configuration of the information system: a. At least every 180 days for High systems or 365 days for Moderate systems; b. When configuration settings change due to critical security patches (as defined by the federal government, CMS, or vendor), upgrades and emergency changes (e.g., unscheduled changes, system crashes, replacement of critical hardware

CSP.1 - For CSPs, the organization reviews and updates the baseline configuration of the information system: (a) At least every 365 days; (b) When required due to a significant change; and (c) As an integral




Control components), major system changes/upgrades; c. As an integral part of: 1. information system component installations; 2. upgrades; and 3. updates to applicable governing standards (implemented within timeline defined in (a) above); and d. Supporting baseline configuration documentation reflects ongoing implementation of operational configuration baseline updates, either directly or by policy.

part of information system component installations and upgrades.


Automation Support for Accuracy/Currency

The organization employs automated mechanisms to maintain an up-to-date, complete, accurate, and readily available baseline configuration of the information system.


Retention of Previous Configurations

The organization retains older versions of baseline configurations of the information system as deemed necessary to support rollback.


Development and Test Environments

The organization maintains a baseline configuration for information system development and test environments that is managed separately from the operational baseline configuration.


Configure Systems, Components, or Devices for High-Risk Areas

The organization: a. Issues dedicated information systems, system components, or devices with stringent configurations (e.g., FIPS 140-2 for




Control encryption) to individuals traveling to locations that the organization deems to be of significant risk; and b. Applies security safeguards to the devices (i.e., detailed inspection of the device for physical tampering, purging or reimaging the hard disk drive/removable media) when the individuals return.

CM-3 High, Moderate

Configuration Change Control

The organization: a. Determines the types of changes to the information system that are configuration-controlled; b. Reviews proposed configuration-controlled changes to the information system and approves or disapproves such changes with explicit consideration for security impact analyses; c. Documents configuration change decisions associated with the information system; d. Implements approved configuration-controlled changes to the information system; e. Retains records of configuration-controlled changes to the information system for a minimum of three (3) years after the change; f. Audits and reviews activities associated with configuration-controlled changes to the information system; and g. Coordinates and provides oversight for configuration change control activities through change request forms which must be approved by an organizational and/or CMS change control board that convenes frequently enough to accommodate

CSP.1 - For service providers, the organization coordinates and provides oversight for configuration change control activities through organization-defined configuration change control element (e.g., committee, board] that convenes organization-defined frequency; organization-defined configuration change conditions. CSP.2 - For service providers, the organization defines the configuration change control element and the frequency or conditions under which it is convened. The change control




Control proposed change requests, and other appropriate organization officials including, but not limited to, the System Developer/Maintainer and information system support staff.

element and frequency/conditions of use are approved and accepted by the JAB. CSP.3 - For service providers, the organization establishes a central means of communicating major changes to or developments in the information system or environment of operations that may affect its services to the federal government and associated service consumers (e.g., electronic bulletin board, web status page). The means of communication are approved and accepted by the JAB.


Automated Document/ Notification/Prohibition of Changes

The organization employs automated mechanisms to: a. Document proposed changes to the information system; b. Notify designated approval authorities (defined in the SSP) of proposed changes to the information system; c. Request change approval per the system configuration management documentation;




Control d. Highlight proposed changes that have been waiting an approval decision, or have not been approved, for longer than change management procedure (defined in the SSP) requires; e. Prohibit changes to the information system until approvals are received; f. Document all changes to the information system; and g. Notify stakeholders when approved changes are completed. A list of potential stakeholders must include, but is not limited to the following: a. Change Control Board (CCB); b. Chief Risk Officer (CRO); c. Cyber Risk Advisor (CRA); d. ISSO; e. Program Manager; f. Data Guardian; g. Information System Owner (ISO); and h. Information System Administrator.


Test/Validate/Document Changes

The organization tests, validates, and documents changes to the information system before implementing the changes on the operational system.


Cryptography Management

The organization ensures that all cryptographic mechanisms used to provide protection to sensitive information are under configuration management.




Control CM-4 High,

Moderate, Low

Security Impact Analysis

The organization analyzes changes to the information system to determine potential security and privacy impacts prior to change implementation. Activities associated with configuration changes to the information system are audited.


Separate Test Environments

The organization analyzes changes to the information system in a separate test environment before implementation in an operational environment, looking for security impacts due to flaws, weaknesses, incompatibility, or intentional malice.


Verification of Security Functions

The organization must ensure changes in information system security functions are verified: a. To be implemented per approved design; b. To integrate and operate as intended; and c. To produce expected results.

CM-5 High, Moderate

Access Restrictions for Change

The organization defines documents, approves, and enforces physical and logical access restrictions associated with changes to the information system. Records reflecting all such changes must be generated, reviewed, and retained.


Automated Access Enforcement/ Auditing

The information system enforces access restrictions and supports auditing of the enforcement actions.


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.


Signed Components The information system prevents the installation of network and server software and firmware components without




Control verification that the component has been digitally signed using a certificate that is recognized and approved by the organization.


Limit Production/ Operational Privileges

The organization: (a) Limits privileges to change information system components and system-related information within a production or operational environment; and (b) Reviews and reevaluates the privileges available to users authorized for privileged access no less frequently than once every three months.


Configuration Settings The organization: a. 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; b. Implements the configuration settings;

CSP.1 - For service providers, the organization establishes and documents mandatory configuration settings for information technology products employed within the information system using USGCB that reflect the most restrictive mode consistent with




Control c. 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 [SSP]); and d. Monitors and controls changes to the configuration settings in accordance with organizational policies and procedures.

operational requirements. CSP.2 - For service providers, the organization must use the Center for Internet Security guidelines (Level 1) to establish configuration settings or establish own configuration settings if USGCB is not available. Configuration settings are approved and accepted by the JAB. CSP.3 - For service providers, the organization ensures that checklists for configuration settings are SCAP validated or SCAP compatible (if validated checklists are not available).

CM-6(1) High, Moderate, Low

Automated Central Management/ Application/ Verification

The organization employs automated mechanisms to centrally manage, apply, and verify configuration settings for information system components as defined by HHS minimum-security configuration standards.

CM-6(2) High, Moderate, Low

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:




Control a. Alert responsible actors (person, organization); b. Restore to approved configuration; and c. Halt system processing as warranted.


Least Functionality The organization: a. Configures the information system to provide only essential capabilities; and b. 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. c. 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.

CSP.1 - For service providers, this Standard replaces the above Control. The organization configures the information system to provide only essential capabilities and specifically prohibits or restricts the use of the following functions, ports, protocols, and/or services: USGCB-defined list of prohibited or restricted functions, ports, protocols, and/or services. CSP.2 - For service providers, the organization must use the Center for Internet Security guidelines (Level 1) to establish list of prohibited or restricted functions, ports, protocols, and/or services or establishes its own list of prohibited or




Control restricted functions, ports, protocols, and/or services if USGCB is not available. The list of prohibited or restricted functions, ports, protocols, and/or services are approved and accepted by the JAB.


Periodic Review The organization: (a) Reviews the information system no less often than once every thirty (30) days to identify and eliminate unnecessary functions, ports, protocols, and/or services; (b) 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 (c) Disables functions, ports, protocols, and services within the information system deemed to be unnecessary and/or non-secure.

CSP.1 - For service providers, this Standard replaces the previous Implementation Standards for this control. The organization reviews the information system no less often than quarterly to identify and eliminate unnecessary functions, ports, protocols, and/or services.


Prevent Program Execution

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.




Control CM-7(4) High,

Moderate Unauthorized Software/Blacklisting

If software whitelisting is not implemented, the organization: a. Identifies defined software programs (defined in the applicable security plan) not authorized to execute on the information system; b. Employs an allow-all, deny-by-exception policy to prohibit the execution of unauthorized software programs on the information system; c. Reviews and updates the list of unauthorized software programs no less often than every seventy-two (72) hours; and d. Receives automated updates from a trusted source.


Authorized Software/ Whitelisting

If software blacklisting is not implemented, the organization: a. Identifies defined software programs (defined in the applicable security plan) authorized to execute on the information system; b. Employs a deny-all, permit-by-exception policy to allow the execution of authorized software programs on the information system; c. Reviews and updates the list of authorized software programs no less often than every seventy-two (72) hours; and d. Receives automated updates from a trusted source.

CSP.1 - Automated authorized software/whitelisting tool results must be searchable by the CCIC: (a) Information is provided to the CCIC in a format compliant with CMS and CDM requirements; (b) Authorized software/whitelisting (and blacklisting) information sources include systems, appliances, devices, services, and applications (including databases);




Control (c) Authorized software/whitelisting information sources that do not support the exchange of information with the CCIC must be documented in the applicable risk assessment and security plan; and (d) CCIC directed unauthorized software/whitelisting information collection rules/requests (e.g., sources, queries, data calls) must be implemented/provided within the timeframe specified in the request. CSP.2 - As required by CMS, raw security information/results from automated authorized software/whitelisting tools must be provided unaltered to the CCIC.


Information System Component Inventory

The organization: a. Develops and documents an inventory of information system components that: 1. Accurately reflects the current information system;

CSP.1 - For service providers, the organization develops, documents, and maintains an




Control 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 4. Include: - 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); - Manufacturer/model information; - 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 IS architecture); - Media access control (MAC) address; - Ownership; - Operational status; - Primary and secondary administrators; and - Primary user. b. 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.

inventory of information system components that includes organization-defined information deemed necessary to achieve effective property accountability. CSP.2 - For service providers, the organization defines information deemed necessary to achieve effective property accountability. Property accountability information are approved and accepted by the JAB.


Updates During Installations/ Removals

The organization updates the inventory of information system components as an




Control integral part of component installations, removals, and information system updates.


Automated Maintenance

The organization employs automated mechanisms to help maintain an up-to-date, complete, accurate, and readily available inventory of information system components.


Automated Unauthorized Component Detection

The organization: a. Employs automated mechanisms no less than weekly to detect the presence of unauthorized hardware, software, and firmware components within the information system; and b. 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).

CSP.1 - For service providers, this Standard replaces the above Enhancement. The organization: (a) Employs automated mechanisms to scan continuously, using automated mechanisms with a maximum five-minute delay in detection to detect the addition of unauthorized components/devices into the information system; and (b) Disables network access by such components/devices or notifies designated organizational officials.


Accountability Information

The organization includes in the information system component inventory information, a means for identifying by position and role, and individuals responsible/accountable for administering those components.





Moderate No Duplicate Accounting of Components

The organization verifies that all components within the authorization boundary of the information system are not duplicated in other information system inventories.

CM-9 High, Moderate

Configuration Management Plan

The organization develops, documents, and implements a configuration management plan for the information system that: a. Addresses roles, responsibilities, and configuration management processes and procedures; b. Establishes a process for identifying and managing configuration items throughout the system development life cycle; c. Defines the configuration items for the information system; d. Places the configuration items under configuration management; and e. Protects the configuration management plan from unauthorized disclosure and modification.


Software Usage Restrictions

The organization: a. Uses software and associated documentation in accordance with contract agreements and copyright laws; b. Tracks the use of software and associated documentation protected by quantity licenses to control copying and distribution; and c. 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.





Moderate Open Source Software The organization

establishes the following policy regarding open source software: a. Open source software must be legally licensed; b. Open source software must be approved for use by CMS IT; c. The following CMS offices must be informed of open source usage: 1. CMS Information System Security Officer (ISSO); 2. CMS Chief Risk Officer (CRO); and 3. Cyber Risk Advisor (CRA).


User-Installed Software The organization:

a. Prohibits the installation of software by users on all GFE;

b. Enforces software installation policies through organization-defined methods (defined in the SSP); and c. Monitors policy compliance at least monthly.

Centers for Medicare & Medicaid Services Control/Policy Cross Reference Table


Appendix E. Control/Policy Cross Reference Table

NIST SP 800-53 CM Control CMS ARS CM Control CMS IS2P2 Policy HHS IS2P Policy

CM-1 Configuration Management Policy and Procedures

CM-1 Configuration Management Policy and Procedures

CM-1, CM-1.1.1, CM-1.1.4, CM-1.1.13, CM-1.1.16, CM-1.2

CM-1 Configuration Management

CM-2 Baseline Configuration CM-2 Baseline Configuration CM-1, CM-1.1, CM-1.1.5, CM-1.1.6, CM-1.1.10, CM-1.1.13

CM-2 Baseline Configuration

CM-2(1) Reviews and Updates CM-2(1) Reviews and Updates CM-1.1, CM-1.1.1, CM-1.1.6, CM-1.1.8, CM-1.1.10

CM-2 c.e.1 Reviews and Updates

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

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

CM-1.1.2, CM-1.1.3, CM-1.1.6, CM-1.1.10, CM-1.1.13

CM-2 c.e.2 Automation Support for Accuracy/ Currency

CM-2(3) Retention of Previous Configurations

CM-2(3) Retention of Previous Configurations

CM-1.1.6, CM-1.1.9, CM-1.1.17 CM-2 c.e.3 Retention of Previous Configurations

CM-2(6) Development and Test Environments

CM-2(6) Development and Test Environments

CM-1.1.6, CM-1.1.9, CM-1.1.13 Not Selected

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

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

CM-1.1, CM-1.1.1, CM-1.1.2, CM-1.1.3, CM-1.1.5, CM-1.1.13

CM-2 c.e.7 Configure Systems, Components, or Devices for High-Risk Areas

CM-3 Configuration Change Control


CM-1, CM-1.1.1, CM-1.1.2, CM-1.1.3, CM-1.1.5, CM-1.1.8, CM-1.1.13, CM-1.1.14, CM-1.1.15, CM-1.1.17, CM-1.3


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

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

CM-1, CM-1.1.2, CM-1.1.3, CM-1.1.5, CM-1.1.8, CM-1.3

CM-3 c.e.1 Automated Document/ Notification/ Prohibition of Changes

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

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

CM-1, CM-1.1.3, CM-1.1.8, CM-1.1.13, CM-1.1.17

CM-3 c.e.2 Test/ Validate/ Document Changes

CM-3(6) Cryptography Management

CM-3(6) Cryptography Management

CM-1.1.5, CM-1.1.8 Not Selected

CM-4 Security Impact Analysis CM-4 Security Impact Analysis CM-1.1, CM-1.1.8 CM-4 Security Impact Analysis




CM-4(1) Separate Test Environments

CM-4(1) Separate Test Environments

CM-1.1.8 CM-4 c.e.1 Separate Test Environments

CM-4(2) Verification of Security Functions

CM-4(2) Verification of Security Functions

CM-1, CM-1.1, CM-1.1.3, CM-1.1.13 Not Selected

CM-5 Access Restrictions for Change

CM-5 Access Restrictions for Change

CM-1.1.2, CM-1.1.5, CM-1.1.13, CM-1.3 CM-5 Access Restrictions for Change

CM-5(1) Automated Access Enforcement/ Auditing

CM-5(1) Automated Access Enforcement/ Auditing

CM-1, CM-1.1.2, CM-1.1.3, CM-1.1.5, CM-1.3 CM-5 c.e.1 Automated Access Enforcement/ Auditing

CM-5(2) Review System Changes

CM-5(2) Review System Changes

CM-1, CM-1.1.2, CM-1.1.3, CM-1.1.5, CM-1.3 CM-5 c.e.2 Review System Changes

CM-5(3) Signed Components CM-5(3) Signed Components CM-1.1.5 CM-5 c.e.3 Signed Components

CM-5(5) Limit Production/ Operational Privileges

CM-5(5) Limit Production/ Operational Privileges

CM-1.1.2 Not Selected

CM-6 Configuration Settings CM-6 Configuration Settings CM-1, CM-1.1, CM-1.1.2, CM-1.1.3, CM-1.1.8, CM-1.1.11, CM-1.1.12, CM-1.1.13, CM-1.3

CM-6 Configuration Settings

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

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

CM-1.1.3, CM-1.1.5, CM-1.3 CM-6 c.e.1 Automated Central Management/ Application/ Verification

CM-6(2) Respond to Unauthorized Changes

CM-6(2) Respond to Unauthorized Changes

CM-1, CM-1.1.2, CM-1.1.3, CM-1.1.5, CM-1.3 CM-6 c.e.2 Respond to Unauthorized Changes

CM-7 Least Functionality CM-7 Least Functionality CM-1.1.5, CM-1.1.13, CM-1.3 CM-7 Least Functionality

CM-7(1) Periodic Review CM-7(1) Periodic Review CM-1.1.5, CM-1.1.13, CM-1.3 CM-7 c.e.1 Periodic Review

CM-7(2) Prevent Program Execution

CM-7(2) Prevent Program Execution

CM-1, CM-1.1.5, CM-1.3 CM-7 c.e.2 Prevent Program Execution

CM-7(4) Unauthorized Software/Blacklisting

CM-7(4) Unauthorized Software/Blacklisting

CM-1.1.5, CM-1.3 CM-7 c.e.4 Unauthorized Software/ Blacklisting

CM-7(5) Authorized Software/ Whitelisting

CM-7(5) Authorized Software/ Whitelisting

CM-1.1.5, CM-1.1.7, CM-1.1.10, CM-1.3 CM-7 c.e.5 Authorized Software/ Whitelisting




CM-8 Information System Component Inventory

CM-8 Information System Component Inventory

CM-1, CM-1.1.7 CM-8 Information System Component Inventory

CM-8(1) Updates During Installations/ Removals

CM-8(1) Updates During Installations/ Removals

CM-1.1.7 CM-8 c.e.1 Updates During Installations/ Removals

CM-8(2) Automated Maintenance CM-8(2) Automated Maintenance CM-1, CM-1.1, CM-1.1.2, CM-1.1.7 CM-8 c.e.2 Automated Maintenance

CM-8(3) Automated Unauthorized Component Detection

CM-8(3) Automated Unauthorized Component Detection

CM-1.1.3, CM-1.1.5, CM-1.1.11, CM-1.1.12, CM-1.3

CM-8 c.e.3 Automated Unauthorized Component Detection

CM-8(4) Accountability Information

CM-8(4) Accountability Information

CM-1.1.7 CM-8 c.e.4 Accountability Information

CM-8(5) No Duplicate Accounting of Components

CM-8(5) No Duplicate Accounting of Components

CM-1.1.7 CM-8 c.e.5 No Duplicate Accounting of Components

CM-9 Configuration Management Plan


CM-1, CM-1.1, CM-1.1.3, CM-1.1.5, CM-1.1.13


CM-10 Software Usage Restrictions

CM-10 Software Usage Restrictions

CM-1.3 CM-10 Software Usage Restrictions

CM-10(1) Open Source Software CM-10(1) Open Source Software Not Selected

CM-11 User-Installed Software CM-11 User-Installed Software CM-1.1.3, CM-1.1.5, CM-1.3 CM-11 User-Installed Software

Centers for Medicare & Medicaid Services Security Impact Assessment Template


Appendix F. Security Impact Assessment Template

The RMH Chapter 5 Configuration Management Appendix F. – Security Impact Assessment Template is available on the CMS Information Security and Privacy Library located at: https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Information-Security-Library.html



Centers for Medicare & Medicaid Services Points of Contact


Appendix G. Points of Contact

CMS IT Service Desk Name Email Phone

CMS IT Service Desk

[email protected] (410) 786-2580 (800) 562-1963

Incident Management Team Name Email Phone

Incident Management Team

[email protected]

Continuous Diagnostics and Mitigation (Continuous Monitoring Program) CMS Information Security and Privacy Group (ISPG)

Name Email Phone CDM Team Lead [email protected]



Centers for Medicare & Medicaid Services Feedback and Questions


Appendix H. Feedback and Questions

Information security is a dynamic field and as such policies, standards, and procedures must continually evolve and update. Feedback from the user community is invaluable and ensures that high quality documents are produced and that those documents add value to the CMS community. Should you have any recommendations for improvements to this document, please email the CISO mailbox at [email protected]. Your feedback will be evaluated for incorporation into future releases of the document. Questions about any of the material included within this document may also be sent to the CISO mailbox.


Centers for Medicare & Medicaid Services Events As Triggers Of Change


Appendix I. Events As Triggers Of Change

Events Actions

Trigger Type of Event Nature of

Event Type of Change Notes

Policy/Standards New Revision of ARS

No addition or change to existing controls

Minor Change

Likely not necessary to perform a full system authorization. However, new and modified control implementations must be tested as part of the Configuration (Change) Management processes.

Time No ATO exists ATO has Expired for system

System is Non-

Compliant Get a full system ATO. No system should be operating without an ATO.

Time No ATO exists ATO does not exist for system

System is Non-

Compliant Get a full system ATO. No system should be operating without an ATO.

Environment System boundary ATO Expired for host GSS

System is Non-

Compliant GSS get a full system ATO. Supported systems are not in compliance

Environment System boundary No ATO for host GSS

System is Non-

Compliant GSS get a full system ATO. Supported systems are not in compliance

Change Security Classification

Security Category lowered

Possible Significant Change

Likely not necessary to perform a full authorization—unless security control implementations are modified. New and modified control implementations must be tested as part of the Configuration (Change) Management processes



Change Mission/Business requirements

New Mission added


Likely not necessary to perform a full authorization. However, pay particular attention to changes in user roles and/or data types. New and modified control implementations must be tested as part of the Configuration (Change) Management processes

Change Mission/Business requirements

Cessation of mission or function.


Likely not necessary to perform a full authorization—unless security control implementations are modified. New and modified control implementations must be tested as part of the Configuration (Change) Management processes

Change Equipment Upgrades Laptops/desktops


If the equipment is updated with similar vendor and models, then minimal testing may be needed. However, if the equipment is new models or vendors, with different configurations and settings, then it is considered a significant change. Equipment will need to be hardened, and at minimum, have vulnerability and configuration scans performed on them

Change Equipment Upgrades

Communications Equipment Possible Significant Change

If the equipment is updated with similar vendor and models, then minimal testing may be needed. However, if they are new models or vendors, with different configurations and settings, then it is considered a significant change. Equipment will need to be hardened, and at minimum, have vulnerability and configuration scans performed on them



Change Equipment Upgrades Other Equipment Possible Significant Change

If the equipment is updated with similar vendor and models, then minimal testing may be needed. However, if they are new models or vendors, with different configurations and settings, then it is considered a significant change. Equipment will need to be hardened, and at minimum, have vulnerability and configuration scans performed on them

Change Major system Updates New OS release Possible Significant Change

If the software is updated with similar vendor and versions, then minimal testing may be needed. However, if they are significantly different versions (i.e.., not an “incremental version update”) or different vendors, with different configurations and settings, then it is considered a significant change. Affected systems will need to be hardened and, at minimum, have vulnerability and configuration scans performed on them.

Change Major system Updates

New Anti-Malware Product Possible Significant Change

If the software is updated with similar vendor and versions, then minimal testing may be needed. However, if they are significantly different versions (i.e.., not an “incremental version update”) or different vendors, with different configurations and settings, then it is considered a significant change. Affected systems will need to be hardened and, at minimum, have vulnerability and configuration scans performed on them.



Change Patch Updates Software Possible Significant Change

Software patch updates that cause the baseline configuration, or security controls implementations, to change will need a re-authorization. All Software upgrades need to be tested pre-launch to prevent any issues. Affected systems will need to be hardened and, at minimum, have vulnerability and configuration scans performed on them

Change Patch Updates Servers Possible Significant Change

Software patch updates that cause the baseline configuration, or security controls implementations, to change will need a re-authorization. All Software upgrades need to be tested pre-launch to prevent any issues. Affected systems will need to be hardened and, at minimum, have vulnerability and configuration scans performed on them

Change System boundary Changed Interconnections Possible Significant Change

ISA update(s) required. New and modified control implementations must be tested as part of the Configuration (Change) Management processes

Change System boundary Architecture or Topological Change Possible Significant Change

This is likely a significant change because it changes the overall system design. New and modified control implementations must be tested as part of the Configuration (Change) Management processes.

Change System boundary Change to Logical Access Points Possible Significant Change Vulnerability scan is required

Environ.

Core Mission/Business functions Changes Significant Change Significant Change. Full ATO needed.



Environ. Laws, Regulations, Directives New or Changed Possible Significant Change

Determine if the requirements of new or changed laws, regulations, and directives affect the security state of the system. New and modified control implementations must be tested as part of the Configuration (Change) Management processes

Policy/Standards

Issue or Update Other NIST Documents New or Changed Possible Significant Change

If new documentation changes the need for security controls or baseline configuration then a re-authorization is necessary. New and modified control implementations must be tested as part of the Configuration (Change) Management processes

Risk Vulnerability (New or Existing) Attacks Developed Risk Level Evaluated

Risk Assessment update, additional work as required. New and modified control implementations must be tested as part of the Configuration (Change) Management processes

Risk Vulnerability (New or Existing)

Attacks Succeed Elsewhere Risk Level Evaluated

Risk Assessment update, additional work as required. New and modified control implementations must be tested as part of the Configuration (Change) Management processes

Risk Vulnerability (New or Existing)

Found (No Attacks Known) Risk Identified

Add to Risk Assessment. New and modified control implementations must be tested as part of the Configuration (Change) Management processes

Change Security Classification

Security Category Raised Significant Change

Add and modify security and privacy controls as appropriate. New and modified control implementations must be tested as part of the Configuration (Change) Management processes. Obtain a new/updated ATO

Change Mission/Business Requirements

Change of Status Regarding Mission Essential Functions Significant Change

New and modified control implementations must be tested as part of the Configuration (Change) Management processes. Obtain a new/updated ATO



Change Equipment Upgrades

New (Different) Servers Significant Change


Change Major System Updates New (Different) OS Significant Change


Change Security Components

Cryptographic Modules Significant Change


Change Security components

Identification and Authentication Significant Change


Change Security Components Security Controls Significant Change


Change System boundary New processing location(s) Significant Change

A new processing location will need to go thru an re-authorization to ensure the system is secure from any issues or attacks

Change System boundary New User Population Significant Change

New and modified control implementations must be tested as part of the Configuration (Change) Management processes. Obtain a new/updated ATO.

Change System boundary Protocol Change Significant Change Vulnerability scan is required



Environment System boundary

Change or Addition of Hosting Infrastructure or Site Significant Change

Full authorization of the GSS is required. New and modified control implementations (for applicable applications) must be tested as part of the Configuration (Change) Management processes. Application obtains a new/updated ATO

Environment

Core Mission/Business Functions

New Mission or Business Function added Significant Change


Environment

Core Mission/Business functions

Cessation of mission or function. Significant Change


NIST New Revision of ARS

Affects Existing Controls or Adds New Controls Significant Change


Time No ATO Exists New System Implementation Standard Operating Procedure

A&A and ATO required before commencement of operations

Time Current ATO Exist System ATO Expires in X months Standard Operating Procedure

If system has had annual assessments performed by independent assessors, those results can be used for the evaluation. Test any untested control implementations. Obtain a new/updated ATO

Time Current ATO Exist Host GSS ATO Expires in X months Standard Operating Procedure

If annual assessments have been performed by an independent assessor, and GSS ATO is maintained, then no action is needed for application re-authorization



Change Patch Updates Anti-Malware Standard Operating Procedure Vulnerability scan is required

Environment Target of Threat

Specific and Credible Information Target of Risk

Incident Response, POA&Ms, and compensating controls required

Risk Vulnerability (New or Existing) CMS Attacked Target of Risk

Incident Response, POA&Ms, and compensating controls required.