33. DRAFT - Template-System Level Configuration Management Plan.doc

Program Office Information System Name Configuration Management Plan Month YYYY

PROGRAM OFFICE INFORMATION SYSTEM NAME

version number

Configuration Management Plan for

[eMASS System Name]

[eMASS SYSTEM ACRONYM]

[System Version 1.5.0.0]

June 2018 Use the month and year of the Authorizing Official (AO) signature in the placeholder above.

Contact Information / Approvals System Owner:

Signature and date:

Information System Security Manager:

Signature and date:

Information System Security Officer:

Signature and date:

Document Revision and History Page

This document will be reviewed at a minimum annually.

OF CHANGE

SECTION/

PARAGRAPH

PAGE

Revamping of Contingency Planning Controls Table

Re-organization

Addition of CCI tables

Acronym List Updated Global

Pg. 1-2

Global

Global

Pg. 1-2 Global

Pg. 1-2

Global

Global

Pg. 1-2

Removal of CCIs that are addressed within the T1 and T2 SOR

Table of Contents

1GENERAL INFORMATION

1CONFIGURATION MANAGEMENT PLAN

1PURPOSE

2SCOPE

2HOW TO USE THIS GUIDE

INTRODUCTION

31.1 Configuration Management Controls

31.2 Scope

41.3 Purpose

51.4 Applicable Provisions and Directives

SYSTEM OVERVIEW

72.1 System Architecture

82.2 Information System Component Inventory [CM-8]

92.3 No Duplicate Accounting of Components [CM-8(5)]

92.4 Automated Unauthorized Component Detection [CM-8(3)]

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

CONFIGURATION PROGRAM

123.1 Configuration Change Control [CM-3; CM-9]

123.2 Configuration Control Board (CCB)

153.3 Change Request

153.4 Initial Request Evaluation

163.5 CCB Courses of Action

163.6 Unscheduled Changes

163.7 Test Validate and Document Changes [CM-3 (2); CM-9]

173.8 Security Impact Analysis [CM-4]

183.9 Configuration Status Accounting

183.10 Access Restrictions for Change [CM-5; CM-9]

193.11 Configuration Settings [CM-6]

203.12 Configuration Audits

203.13 Least Functionality [CM-7]

213.14 Periodic Review [CM-7(1)]

213.15 Prevent Program Execution [CM-7(2)]

223.16 Unauthorized Software Blacklisting [CM-7(4)]

223.17 Information System Component Inventory [CM-8]

233.18 CM Plan Maintenance

24APPENDIX A: ACRONYM LIST

25APPENDIX B: CCB CHARTER

26APPENDIX C: CHANGE REQUEST FORM TEMPLATE

LisT of Tables 3Table 1-1: Summary of NIST SP 800-53: Configuration Management Plan Controls

15Table 3‑1: Configuration Management Roles and Responsibilities

GENERAL INFORMATION

Configuration Management (CM) is the ongoing process of identifying and managing changes to deliverables and other work products. It is a systems development discipline that promotes the proper identification of the configuration, control of changes, and records the change implementation status of the physical and functional characteristics of an Information Technology (IT) system. Configuration Management identifies what is required, designed, and produced. It also provides for the evaluation of changes including effects on technical and operational performance. This leads to making the configuration visible and understood by all the parties involved with the system.

Configuration management covers three basic essential interdependent activities:

1) Configuration Identification – Configuration identification is for the formal step of identifying the configuration of an item (i.e., name, location, version), and documenting its functional and physical characteristics.

2) Configuration Control – Configuration control is the exercising of established procedures to classify, approve or disapprove, implement, and confirm changes to the agreed upon specifications and baselines.

3) Configuration Management Status Accounting – Configuration accounting is the formal recording and reporting of data relating to configuration identification, approval status of proposed changes, and implementation status of approved changes during all phases of the project.

Configuration Management is therefore the means through which integrity and continuity of the system’s design, and decisions made regarding technical performance, producibility, operability, and supportability are recorded, communicated, and controlled.

CONFIGURATION MANAGEMENT PLAN

A Configuration Management Plan (CMP) is developed to define, document, control, implement, account for, and audit changes to the various components of an IT system. The CMP:

· Provides information on the requirements and procedures necessary for CM activities

· Establishes the methodology for configuration identification and control of releases and changes to configuration items (CI)

· Describes the process for maintaining status accounting and verifying the completeness and correctness of CIs throughout the system lifecycle

A CMP must identify and describe the overall policies and methods for the CM activities to be used during a system’s life cycle.

PURPOSE

This CMP Development Guide provides the framework to identify and describe the overall policies and methods for CM activities to be used during a system’s life cycle. The final CMP product should be delivered in electronically searchable format using an approved documentation presentation. It must be able to stand on its own with all elements explained and acronyms spelled out for reader/reviewers who may not be familiar with the system.

SCOPE

This CMP is a tool used to establish the overall approach for the Configuration Management requirement for the applicable infrastructure system. The CMP will be a dynamic document, and will be updated as work on the system proceeds and the necessity arises.

HOW TO USE THIS GUIDE

The instructions in Sections 1.0 – 3.18 of this document must be adhered to in developing Configuration Management Plans (CMP) for DHA infrastructure systems. This document was developed to ensure that CMPs created using its guidance comply with governing mandates, to include the DHA Risk Management Framework (RMF) requirements.

The structure of the CMP outline provided in Sections 1.0 – 3.18 follows industry standards and best practices for configuration management plans, ensuring the minimum content requirements will be included in the completed artifact. The completed CMP should be structured to allow for discrete sections to cover specific CM activities, all of which are accounted for in the provided CMP outline.

To enhance the utility of the CMP, additional sections/sub-sections may be added, however the content for Sections 1.0 – 3.18 cannot be omitted from the final site CMP. Instructional content is identified by Red text throughout the CMP outline and must be included in the CMP.

1 INTRODUCTION

Example Text: Configuration Management (CM) is the implementation and execution of processes and procedures that ensure the systematic and orderly control of a system and its components throughout its life cycle. CM ensures system integrity by controlling changes to the components of a system.

Configuration Management can be applied at many levels of a system, from subsystem to system and networks of systems. At the system level, configuration management of Department of Defense (DoD) systems requires a focus on secure configurations.

1.1 Configuration Management Controls

The Security Control table identifies controls applicable to Information System (IS) Name ACRONYM.

NOTE: The following Configuration Management Plan controls below are from NIST SP 800-53, Rev. 4. This table will assist you in identifying controls that are applicable to your system. Do not delete any rows in the Table 1-1 below.

If any controls are identified as “Not applicable”, please state “Not applicable” in the section within this document. Do not delete any section within this document.

Delete this notational text box before submitting to DHA CSD for approval.

Select one and delete the other; then change to black font

Table 1-1: Summary of NIST SP 800-53: Configuration Management Plan Controls

1.2 Scope

The Configuration Management Plan describes a tiered approach and organizational framework for implementing and providing oversight of CM processes and controls. Detailed operational processes are to be defined and documented in specific tier level plans, such as CCB Charters.

1.3 Purpose

Configuration Management Policy, Procedures, and Plan [CM-1, CM-9] This Configuration Management Plan (CMP) describes how configuration management will be conducted for the (Program Office/Contractor Name Abbreviation Information System (IS)). This document is intended to be used for the management and control of (Program Office/Contractor Name Abbreviation IS) configurations to enable security and facilitate the management of risk. This CMP is to be used by (Program Office/Contractor Name Abbreviation IS) program personnel as a reference in defining and implementing the operational CM plans and processes by documenting:

1) Formally documented CM roles, responsibilities, and procedures, management commitment, coordination among organizational entities, and compliance

2) A configuration control board that implements procedures to ensure a security review and approval of all proposed DoD information system changes, to include interconnections to other DoD information systems;

3) A testing process that verifies proposed configuration changes prior to implementation in the operational environment ; and

4) A verification process that provides additional assurance that the CM process is working effectively and that the changes outside of the CM process are technically or procedurally not permitted.

CM-1 – Configuration Management Policy And Procedures

If not applicable, enter the following:

This CCI is not applicable.

CM-9 – Configuration Management Plan

If not applicable, enter the following:

This CCI is not applicable.

The organization being assessed develops, documents, and annually maintains procedures to facilitate the implementation of the configuration management policy and associated configuration management controls. All updates and review occurrences must be documented.

The organization disseminates a configuration management policy to all stakeholders in the configuration management process to facilitate implementation.

1.4 Applicable Provisions and Directives

Example Text: The CMP is developed in accordance with Federal, Department of Defense (DoD), and Defense Health Agency (DHA) guidance:

STANDARD References:

· DoD Instruction 8500.01, “Cybersecurity”, 14 March 2014

· (DoD) Instruction 8510.01, “Risk Management Framework (RMF) for DoD Information Technology (IT)”, 12 March 2014 Incorporating Change 2, 28 July 2017

· DoDI 8551.01. “Ports Protocols and Services Management” 28 May 2014

· NIST SP 800-53 “Security and Privacy Controls for Federal Information Systems and Organizations”, Rev 4, April 2013

· NIST SP 800-128, "Guide for Security Focused Configuration Management of Information Systems", August 2011

2 SYSTEM OVERVIEW

Provide an overview of the system. Ensure this description is consistent with other Artifacts that contain a system overview description. (Use System description from SP)

2.1 System Architecture

Hardware and Software Baseline [CM-2, CM-2(1), CM-2(3), CM-8, CM-8(1)] The organization documents a current baseline configuration of the information system and maintains updates under configuration control. Baseline Document reviews must be conducted annually, upon any baseline configuration change, component installation, component upgrades, and component removals or as events or circumstances dictate. Previous versions of the baseline configurations of the information system and components are retained for a minimum of 3 months to support rollback.

CM-2 – Baseline Configuration

If not applicable, enter the following:

This CCI is not applicable.

CM-2 (1) – Baseline Configuration | Reviews And Updates

If not applicable, enter the following:

This CCI is not applicable.

CM-2(3) – Baseline Configuration | Retention Of Previous Configurations

If not applicable, enter the following:

This CCI is not applicable.

CM-8 – Information System Component Inventory

If not applicable, enter the following:

This CCI is not applicable.

CM-8(1) – Information System Component Inventory | Updates During Installations / Removals

If not applicable, enter the following:

This CCI is not applicable.

2.2 Information System Component Inventory [CM-8]

The organization develops and documents an inventory of information system components that includes all components within the authorization boundary of the information system; at a necessary granularity level for tracking and reporting.

A current and comprehensive baseline inventory of all hardware and software (HW/SW) (to include manufacturer, type, model, physical location, network topology or architecture, version, and installation manuals and procedures) is maintained by the CCB as part of the Authorization Package. A backup copy of the inventory is stored in a fire-rated container or otherwise not collocated with the original.

CM-8 – Information System Component Inventory

If not applicable, enter the following:

This CCI is not applicable.

2.3 No Duplicate Accounting of Components [CM-8(5)]

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

CM-8(5) – Information System Component Inventory | No Duplicate Accounting Of Components

If not applicable, enter the following:

This CCI is not applicable.

2.4 Automated Unauthorized Component Detection [CM-8(3)]

The organization continuously employs automated mechanisms to detect the presence of unauthorized hardware, software, and firmware components within the information system and defines personnel and roles to be notified of such findings.

The organization takes action to disable network access by such components, isolates the components, notifies organization-defined personnel and documents all related activity.

CM-8(3) – Information System Component Inventory | Automated Unauthorized Component Detection

If not applicable, enter the following:

This CCI is not applicable.

2.5 Configure Systems, Components, or Devices for High Risk Areas [CM-2(7)] The organization defines and documents, in the configuration management policy, the security configurations to be implemented on information systems, system components, or devices when they are located in areas of significant risk or to individuals traveling to locations the organization deems to be of significant risk.

The organization defines and applies security safeguards to devices when individuals return from areas of significant risk.

CM-2(7) – Baseline Configuration | Configure Systems, Components, Or Devices For High-Risk Areas

If not applicable, enter the following:

This CCI is not applicable.

3 CONFIGURATION PROGRAM

3.1 Configuration Change Control [CM-3; CM-9]

Configuration control is the process of requesting, evaluating, approving or disapproving proposed changes, and implementing approved changes to the system or subsystem baselines. Configuration control extends throughout the system life cycle.

3.2 Configuration Control Board (CCB)

The Configuration Control Board (CCB) is responsible for maintaining configuration control over Configuration Items (CI’s) in the product baselines. In addition, they are responsible for administering the process by which requests for change to products under control is submitted, reviewed, and approved or disapproved.

The CCB plays an important role as gate keeper in deciding which changes may be acted upon and introduced into an information system. The CCB deliberately considers the potential effect of proposed change on the functionality and secure state of the information system and risk to the mission if the change is implemented or not implemented. By reviewing each proposed and implemented modification, the CCB ensures that there is a disciplined, systematic, and secure approach for introducing change. Having a clearly defined process or framework for the evaluation and approval of change requests (CR), including predefined evaluation criteria, helps to ensure that each proposed and implemented change is evaluated in a consistent and repeatable manner balancing security, business, and technical viewpoints.

The CCB defines within their CCB Charter, the frequency and conditions for configuration change control review and will maintain and review an audit trail of each proposed and decided configuration controlled change.

The CCB determines the types of changes to the information system (configuration items) that are configuration controlled, throughout the system development life cycle and the time period in which records of the changes are retained.

CM-3 – Configuration Change Control

If not applicable, enter the following:

This CCI is not applicable.

CM-9 – Configuration Management Plan

If not applicable, enter the following:

This CCI is not applicable.

· Submit additional input and information

· Provide information regarding hardware/software changes and impacts to the system

· Review the change process to ensure that the modified configuration maintains its authorization status

· Review and evaluate proposed changes to ensure that the proposed changes are in accordance with DoD security policy and guidance as well as applicable federal laws, directives, policies, regulations, standards, and guidance.

· Notify the AO of significant changes that may impact the IA posture of the system

· Review the change process to ensure that the modified configuration maintains its authorization status

· Review and evaluate proposed changes to ensure that the proposed changes are in accordance with DoD security policy and guidance as well as applicable federal laws, directives, policies, regulations, standards, and guidance.

· Notify the ISSO of significant changes that may impact the IA posture of the system

· Assist the CCB members in determining the impact of proposed changes as a subject matter expert where appropriate

Table 3‑1: Configuration Management Roles and Responsibilities

3.3 Change Request

The proposed changes are initiated in a change request (CR). CR’s may be initiated by any member of the program team. A CR documents pertinent information including, the configuration item name, configuration baseline version, requested change, justification for the change, impact of the proposed change, who is requesting the change, etc. Additional information may be gathered by members of the program team or CCB to effectively evaluate the CR. A sample Change Request Form is provided in Appendix (x). CR’s are tracked by a unique ID to ensure accountability, control, traceability to implementation, and auditability.

3.4 Initial Request Evaluation

The evaluation of a change is an important activity of the change request process to validate justification for the change and assess the impact of the proposed change to the system, affected configuration items schedule and budget. The scope and degree of formality for the evaluation process depends on the impact of the change.

The first step is to determine if the change requires configuration control. Some types of changes may be exempt from configuration control or pre-approved as defined by the CCB. If the change is exempt or pre-approved it is noted on the change request and the change is made without further analysis or approval; however, system documentation may still require updating (e.g. the Security Plan, the baseline configuration, component inventory, etc.)

Significant changes may require multiple steps for review, evaluation, and recommendation. Small changes may combine steps to shorten and simplify the process. Best practices for configuration change control require that changes to the information system be vetted by at least one authorized individual who is independent of the requestor.

3.5 CCB Courses of Action

The CCB evaluates each CR. The requestor, technical personnel, or subject matter experts may be called on to explain their position on the request.

For each CR, the CCB has three courses of action:

· Approve. The proposed change is approved and may be scheduled for implementation. The CCB may determine the schedule or leave it to the Technical Manager to implement it when appropriate.

· Deny. The proposed change may not be implemented.

· Defer. The CCB does not make a decision at this point in time. It may determine a time period when it will consider the request again, or leave scheduling for further consideration.

3.6 Unscheduled Changes

Situations may arise that necessitate and unscheduled (emergency) change. It is incumbent upon information system owners to identify all sources of the change to make sure that changes requiring configuration control go through the configuration change control process. Unscheduled changes are reviewed/resolved by the CCB as soon as is practical after unscheduled changes are made.

3.7 Test Validate and Document Changes [CM-3 (2); CM-9]

Once the change has been analyzed and approved, it is tested. A comprehensive set of procedures exist to make sure that it is implemented and test all patches and upgrades prior to deployment.

The organization documents and implements a process to test changes to the information system before implementing the changes on the operational system and maintain an audit trail of testing activity.

The organization documents and validates all changes to the information system before the changes are implemented on the operational system.

The change is then implemented, verified and applicable updates are made to supporting documents, such as technical designs and baseline configurations, the new baseline becomes the current version, and the previous baseline is no longer valid, but is retained for historical purposes. If there are any issues with a production release, retention of previous versions allows for a rollback or restoration to a previous secure and functional version of the baseline configuration. Additionally, archiving previous baseline configurations is useful for incident response and traceability support during formal audits.

CM-3(2) – Configuration Change Control | Test / Validate / Document Changes

If not applicable, enter the following:

This CCI is not applicable.

CM-9 – Configuration Management Plan

If not applicable, enter the following:

This CCI is not applicable.

3.8 Security Impact Analysis [CM-4]

It is only when proposed changes are evaluated for their security impact that the configuration change control process yields benefits for the security posture of the information system. A security impact analysis is conducted by individuals or teams within the CCB that possess the technical knowledge of the information system.

The CCB records its analysis of changes to the information system to determine potential security impacts prior to change implementation.

CM-4 – Security Impact Analysis

If not applicable, enter the following:

This CCI is not applicable.

3.9 Configuration Status Accounting

Configuration Status Accounting (CSA) is the recording and reporting of information needed to manage CI’s effectively. CSA includes:

· A record of the approved configuration documentation and identification numbers

· The status of proposed changes, deviations, and waivers to configuration

· The implementation status of approved changes

· The configuration of all units of the CI in the operational inventory

· Results of audits

CSA documentation is the means through which actions affecting CI’s are recorded and reported to interested parties. CM Managers have the primary responsibility for managing, compiling, maintaining, and publishing CSA records and reports. The records and reports provide status information to program management that the changes between the system description and the system itself are being accounted for on a one-to-one relationship. The CM Manager determines the frequency of the distribution and recipients of the CSA reports.

3.10 Access Restrictions for Change [CM-5; CM-9]

The organization defines, documents, approves, and enforces both physical and logical access restrictions associated with changes to the information system.

The organization must document the plan implementations to protect the configuration management plan from unauthorized disclosure and modification, so that all changes to the CM Plan are approved. Measures must include marking, labeling, and handling to prevent improper disclosure.

CM-5 – Access Restrictions for Change

If not applicable, enter the following:

This CCI is not applicable.

CM-9 – Configuration Management Plan

If not applicable, enter the following:

This CCI is not applicable.

3.11 Configuration Settings [CM-6]

The organization documents and implements the use of DoD STIGS for the deployment of acquired IA-enabled products and the establishment of their configuration settings.

The organization identifies, documents, and approves any deviations from the established configuration settings for information system components based on organization-defined operational requirements.

The organization documents, monitors and controls changes to the configuration settings.

CM-6 – Configuration Settings

If not applicable, enter the following:

This CCI is not applicable.

3.12 Configuration Audits

Configuration audits validate that the design and the final product conform to approved functional requirements, as defined in applicable specifications and drawings, and that the changes have been incorporated.

3.13 Least Functionality [CM-7]

The organization is compliant/non-compliant with the DoD defined information system prohibited or restricted functions, ports, protocols, and/or services.

The organization configures the information system to provide only those documented essential capabilities.

CM-7 – Least Functionality

If not applicable, enter the following:

This CCI is not applicable.

CM-7(1) –Least Functionality | Periodic Review

If not applicable, enter the following:

This CCI is not applicable.

3.14 Periodic Review [CM-7(1)]

The organization documents and implements a process to review the information system every 30 days to identify unnecessary and non-secure functions, ports, protocols, and services.

CM-7(1) –Least Functionality | Periodic Review

If not applicable, enter the following:

This CCI is not applicable.

3.15 Prevent Program Execution [CM-7(2)]

The organization documents its compliance with DoDI 8551 and only allows DoD approved network capable software programs to be used within the information system.

The organization configures the information system to prevent the execution of programs not authorized in accordance with DoDI 8551.

CM-7(2) –Least Functionality | Prevent Program Execution

If not applicable, enter the following:

This CCI is not applicable.

3.16 Unauthorized Software Blacklisting [CM-7(4)]

The organization defines and identifies the software programs not authorized to execute on the information system; and documents a review of the identified list on a monthly basis.

CM-7(4) –Least Functionality | Unauthorized Software Blacklisting

If not applicable, enter the following:

This CCI is not applicable.

3.17 Information System Component Inventory [CM-8]

The organization develops and documents an inventory of information system components that includes all components within the authorization boundary of the information system; at a necessary granularity level for tracking and reporting.

CM-8 –Information System Component Inventory

If not applicable, enter the following:

This CCI is not applicable.

3.18 CM Plan Maintenance

Configuration Mangers review configuration management policies and processes, at least annually, to ensure that all CM processes are up to date and comply with pertinent DoD policies. All changes will be incorporated as a document revision. Updates to this document are recorded on the Version History section of this document.

APPENDIX A: ACRONYM LIST

Acronyms used specifically in this Artifact are to be listed in this appendix.

CM

Configuration Management

IS

Information System

APPENDIX B: CCB CHARTER

INSERT YOUR CCB CHARTER HERE

APPENDIX C: CHANGE REQUEST FORM TEMPLATE

The following is a sample template for a Configuration Management Change Request artifact that can be used within a SecCM program. Organizations are encouraged to adapt it to suit their needs. Please be as concise as possible.

CONFIGURATION CHANGE REQUEST FORM

Date Prepared: MMM/DD/YYYY Title of Change Request:

Change Initiator/Project Manager:

Change Description:

Change Justification:

Urgency of Change: Scheduled/Urgent/Unscheduled IS Components/CIs to be Changed:

Other IS Components, CIs, or Systems to Be Affected by Change:

Personnel involved with the Change:

Expected Security Impact of Change:

Expected Functional Impact of Change:

Expected Impact of Not Doing Change:

Potential Interface/Integration Issues:

Required Changes to Existing Applications:

Project work plan including change implementation date, deliverables, and back-out plan:

Funding Required to Implement Change:

The Configuration Management Change Request has been Approved/Disapproved. The CM Change Request has been rejected due to enter justification.

Authorized Signature(s):

Title:

Date:

Add appropriate classification marking

FOR OFFICIAL USE ONLY