Appendix 4 OCC Change Management Plan.pdf

Information Technology Services Customer Experience & Relationship Management

Technology Change Management & Governance

Enterprise Configuration Management Plan

Version 4.0 May 26, 2020

Version History

Version Date Description Author

0.1 02/02/2009 Initiation Raida Y. Douglas

1.0 03/09/2009 Modified to include NI GSS references Raida Y. Douglas

1.1 7/26/2013 Initial version Anthony Braddy

1.2 8/13/2013 P&G Manager Review Version Anthony Braddy

1.3 8/28/2013 Finalized Plan for P&G Advisory Panel Review Anthony Braddy

1.4 9/03/2013 Final Version for Program Level Approval Anthony Braddy

2.0 9/04/2013 Final formatting for signatures Jorgefelix Siverio

2.01 12/12/2013 Revised based on Procedure changes from Q4 FY ’13 to Q1 FY ‘14 Anthony Braddy

2.02 04/03/2014 Updated based procedure changes and the CI model changes from Q1 FY14. Henry Onyeador

2.03 09/05/2014 Updated based on requirements made by PM Matthew Johnston

2.04 10/26/2014 Included FY ’15 – Q1 Document Change Requests Anthony Braddy

2.05 03/20/2015 Included information for Document CIs and the introduction of ServiceNow as the ISCI Matthew Johnston

3.0 06/17/2016

Removed references to CMDB and replaced with Information Systems Component Inventory to more accurately reflect current processes and align to the IT Governance Policy

Tia Crutchfield, Bill LaCosta

3.5 1/25/2017

• Added guidance for System and CI owners on capturing and managing required ISCI information and recommended CI attributes

• Added updated CI Model to Appendix A that provides further guidance on controlled attributes to be managed by CI owners

• Updated Roles and Responsibilities section for CI Owner

• Made updates throughout to clarify information provided

Bill LaCosta, Tia Crutchfield

3.6 3/01/2018

• Replaced references to ‘RFC(s)’ with ‘CR(s)’to support the release of ECCS 3.0

• Updated link to access ‘ASD Information Systems Component Inventory Directory’ (Appendix B: Division Level ISCI Directories)

Bill LaCosta, Tia Crutchfield, Jon Gee

3.7 04/15/2019 • Replace referneces to prior ITS organizational structure Tia Crutchfield

• Updates to reflect organizational realignment

4.0 5/26/2020

• Added change request (CR) guidance for external or cloud hosted services (section 1.2) with supporting cloud service CM matrix diagram (Figure 1)

Kai Richardson, Rodney Jamison, & Tia Crutchfield

Table of Contents

1. Introduction & Overview

1.1 Purpose

1.2 Scope

1.3 Constraints and Assumptions

1.4 Goals and Objectives

1.5 Governance

1.6 Roles & Responsibilities

1.7 Document and Process Review

2. Process Definition

2.1 High Level Process Summary & Workflow

2.1.1 Configuration Planning

2.1.2 Configuration Identification

2.1.2.1 Information System Component Inventory

2.1.3 Configuration Control

2.1.3.1 Control Mechanisms

2.1.4 Configuration Status Accounting & Verification

2.1.4.1 Status Accounting

2.1.4.2 Verification & Auditing

2.2 Process Activities and Sub-Activities

2.3 Supporting Process Activities

Information System Component Inventory (ISCI)

3. Acceptance / Approval

Appendix A: Change Control Configuration Item Model & Attributes List

Appendix B: Division-Level ISCI Directories

Appendix C: Glossary

Tables and Figures Table 1 - Roles and Responsibilities Table 2 – Configuration Planning

Technology Change Management & Governance Enterprise Configuration Management Plan

1. Introduction & Overview

1.1 Purpose

The purpose of the Information Technology Services (ITS) Enterprise Configuration Management (CM) Plan is to establish Configuration Management processes, which are guided by industry best practices and underpinned by the Information Technology Services Information Technology (IT) Governance Policies (PSP 100-01-P13). All ITS personnel must employ the processes set forth in this document, ensuring that all Enterprise Configuration Management activities are executed in a uniform, standardized and auditable manner.

The purpose of (CM) is to:

• Identify, record, verify, control, audit, and report, Configuration Items (CIs), including versions, baselines, selected components, and their attributes and relationships

• Account for and manage CIs throughout their service lifecycle by ensuring that only authorized components are used and only authorized changes are made

• Protect the integrity of CIs through the service lifecycle

• Establish, audit and maintain accurate and complete Information System Component Inventories

(ISCIs) for ITS use

1.2 Scope

In Scope: The scope of the ITS Enterprise CM Plan includes the establishment of CM best practices for providing high-quality, cost efficient and responsive IT operations through the use of streamlined integrated processes. This plan describes the methods used at OCC to create and maintain an environment where all IT services and infrastructure components, including relevant documentation, are under CM control. This plan also establishes CM as the source of information to contribute to efficient planning, release and implementation of changes to Configuration Items (CIs).

The National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53, Revision 4, Security and Privacy Controls for Federal Information Systems and Organizations, requires that CM be performed for each FISMA system owned by a Federal Agency.

The ITS Enterprise CM Plan establishes the methodology for executing enterprise CM activities to include:

Configuration Identification, Configuration Control, Status Accounting, Verification, and Audit & Reporting.

Execution of this plan denotes compliance with the policies of the Enterprise Configuration Management program and also enables the organization to realize a number of operational efficiencies:

• Facilitate service outage root cause analysis to reduce mean time to repair (MTTR)

• Identify the components that make up ITS Services so that service level objectives can be defined

• Minimize operational risk through improved change impact analysis

• Implement changes with the lowest acceptable risks

• Address auditors' increased interest in configuration management and recurring audit findings

• Ensure compliance with governance and internal security policies

• Facilitate orderly management of system information and system changes for such beneficial purposes as to revise capability; improve performance, reliability, or maintainability; extend life;

reduce cost; reduce risk and liability; or correct defects

Enterprise CM forms the basis for Enterprise Change Management of all change requests (CRs). CRs are required for changes to CIs including, but not limited to, the addition, modification, or removal of hardware, http://share/sites/CIO/ITPP/itPSP/Policy%20Library/Information%20Technology%20(IT)%20Governance%20Policies%20V3.0.pdf http://share/sites/CIO/ITPP/itPSP/Policy%20Library/Information%20Technology%20(IT)%20Governance%20Policies%20V3.0.pdf http://dx.doi.org/10.6028/NIST.SP.800-53r4 software, configuration baselines, services, products, and platform frameworks owned and operated by ITS. To see a list of configuration items that the Change Management scope encompasses, please refer to the Change Control CI Model.

In addition, for externally hosted or cloud managed services owned or leased by the OCC:

• A change request (CR) should be submitted when the vendor or OCC generates proposed changes to functionality based on the following criteria:

o Changes to the user experience &/or OCC resource requirements (e.g. changes that alter the navigation of ServiceNow modules) o Changes to the integration of a service within the OCC computing environment (e.g. PIV or proposed technical changes to external systems that impact OCC CIs comprising the interface(s) with the OCC infrastructure) o Changes to the data model based on the cloud service model (IaaS, PaaS, SaaS)

• A CR should be submitted for proposed technical changes to the external or cloud hosted services that impact CIs comprising the interface(s) with the OCC infrastructure.

o Examples:

Changes to the an application middle-tier that is hosted on the OCC network Changes that establish or impact the Lightweight Directory Access Protocol (LDAP) connectivity* Changes to interfaces that allow connectivity to the OCC network

The OCC ITS Technical Contact/Project Manager shall be the owner of the Change Request and responsible for ensuring compliance with these policies. The following illustration provides additional context with respect to the Cloud Service Model:

Figure 1 – Cloud Service Configuration Management Matrix http://share/sites/CIO3/pg/SitePages/CM/default.aspx http://share/sites/CIO3/pg/SitePages/CM/default.aspx

The allowance of a Standard “Information-Only” CR applies only to changes to existing OCC cloud services. A Normal CR is required for implementation of any new external or cloud hosted service.

Out of Scope: While Enterprise CM forms the basis for Enterprise Change Management of all change requests to CIs in all environments, there are notable combination exceptions. They are:

• DEV Domain/Research and Development (R&D) Environment

• DEV Domain/Development Environment

• COC Domain/Research and Development (R&D) Environment

• COC Domain/Development Environment

The aforementioned environments are considered out of scope for all Enterprise governance activities. For definitions of environments and domains, see the Technology Change Management & Governance (TCM&G) Glossary.

In addition to the environments listed above, the following information system objects are also out of scope:

• Digital Certificates

• Service Account Passwords

1.3 Constraints and Assumptions

The following high-level constraints and assumptions apply to the Enterprise CM Program.

Constraints

• The Enterprise CM Program is subject to human resource constraints which may affect the services provided at the project-level.

• Although key performance indicators (KPI) and performance metrics are identified for the Enterprise

CM Program, not all metrics can be generated at the current time. As of the publication of this document, the tools supporting the Enterprise CM Plan are not automated and inherit all inefficiencies inherent in a manual data collection and update process. The current Information System Component Inventory (ISCI) solution cannot effectively manage CI data and relationships.

Assumptions

• Updates to the ISCI that are governed by change control are made by the CI Owner via the CR process.

• Selected ITS stakeholder sub-organizations will assign CI owners to assist with ISCI updates, reconciliation and ensuring the validity of CI data.

1.4 Goals and Objectives

The goals of the Enterprise Configuration Management process are to ensure that selected components of IT Enterprise Services, Platforms, and Products are identified, baselined, and maintained, and that changes to them are controlled. An additional goal of Enterprise CM is to protect and maintain consistency of a CI’s performance as measured against the functional and/or non-functional requirements of the CI. Making sure http://share/sites/CIO3/pg/SitePages/Glossary.aspx?Letter=A http://share/sites/CIO3/pg/SitePages/Glossary.aspx?Letter=A that a CI continues to operate as it is expected is a core goal of CM. It also ensures that releases into controlled environments and operational use are done on the basis of formal approvals. CM provides a CI model by recording the relationships among primary CI categories.

1.5 Governance

The TCM&G Program Manager directs Enterprise CM process activities, ensuring adherence to all policies.

The decisions related to CM are made by the TCM&G Program Manager in conjunction with the Customer Experience and Relationship Management (CERM) ECCB Program Management, with input from Senior Management and other ITS members. The CM Team supports the TCM&G Program Manager by ensuring process compliance and escalating deviations from the processes, as needed. Please refer to the Configuration Management Policies in the IT Governance Policy document for more details.

1.6 Roles & Responsibilities

Table 1 - Roles and Responsibilities

Role Responsibility CERM Program Management Director

• Program Sponsor, provides guidance, resources and coordination with other senior ITS management

• Approves policies TCM&G Program Manager

• Defines and owns CM policies, plans, procedures and processes

• Directs Enterprise CM activities in conformance with program policies

• Ensures Enterprise CM processes are implemented as required

• Conducts Enterprise Configuration Management meetings

• Coordinates all activities necessary to identify, control, track, and audit all CIs at the enterprise level

• Ensures overall objectives of CM are in agreement with Project Level

Managers Enterprise Configuration Manager(s)

• Assists the TCM&G Program Manager with defining the Enterprise CM processes in response to ITS requirements

• Executes Enterprise CM process improvement initiatives

• Maintains the Enterprise CM plan and processes

• Participates in Enterprise CM meetings and other meetings where there is process integration, responding to questions and filling in information gaps where applicable

• Provides guidance and assists Change Owners with the documentation required for executing changes

• Assists CI owners with maintaining ISCI data used for reporting

• Assists in identifying CIs

• Performs CI impact assessments for all CRs of Major and Minor (and selected Admin) change complexity

• Assists in conducting configuration audits

• Helps project teams create project-level configuration documentation

CI Owner • Works with Enterprise Change Managers to document baselines

• Assists Project Level Managers with identifying and tracking CI relationships, where possible

• Follows project-level CM plans, and procedures

• Provides day-to-day project-level CM support to Project-Level managers and occasional support to Enterprise Configuration Managers http://share/sites/CIO/pg/TeamDocs/IT_Governance_Policy.docx

• Responsible for the integrity and accuracy of CI components within the ISCI (See 2.1.2.1 Information System Component Inventory for further guidance)

Project Level Manager (Change Owner)

• Ensures that required resources, supporting information, and documentation are available to execute their CRs throughout the lifecycle

• Attends Enterprise Change/Configuration Management meetings to represent and articulate the scope, impact and risks associated with their CRs

• Tailors Project Level CM documents. Publishes Project Level SDLC/IDLC artifacts

Technical Subject Matter Expert (SME)

• Attends the Enterprise Change Control Board (ECCB) meetings to evaluate CRs based on their area of expertise, including CI impacts

• Proactively assists ITS staff members in identifying and mitigating any technical impacts of CRs prior to the ECCB

Enterprise Change Control Board (ECCB) Members

• See Enterprise Change Control Board (ECCB) Charter for details of how ECCB members are engaged in the Enterprise Configuration Management process

1.7 Document and Process Review

The Enterprise CM process, as outlined in this document, is reviewed by the TCM&G Program Manager and the CM Team on a quarterly basis. All modifications to this plan must obtain sign-off by the TCM&G Program Manager and the ITS SLT before going into effect.

http://share/sites/CIO3/pg/PublicDocs/Enterprise_Change_Control_Board_Charter.pdf

2. Process Definition

2.1 High Level Process Summary & Workflow

The CM process addresses five key activities that together provide a logical model of the infrastructure by planning, identifying, controlling, maintaining, and verifying the versions of CIs in existence.

2.1.1 Configuration Planning

The CM planning activity consists of defining and articulating the strategy, policy, and scope of the CM plan for all of OCC. This process is required when the CM plan is initiated or when new business requirements result in changes to the CM policy or scope. The product of the CM planning activity is the (new or updated) CM plan, including associated procedures.

2.1.2 Configuration Identification

The CM Configuration Identification process consists of the identification, and labeling of the services, configuration structures and CIs, including a CI’s respective technical owner and relationships to OCC infrastructure. The CM Configuration Identification sub-process is required when a CI is identified through one of the inputs (i.e. Change Management Audits). Once identified, CIs become the manageable unit planned for release into a configuration-controlled environment. CIs consist of services, platforms, products and related baseline documentation.

2.1.2.1 Information System Component Inventory

An information system component is a discrete identifiable IT asset that represents a building block of an information system. An accurate component inventory is essential to record the components that compose the information system. The component inventory helps to improve the security of the information system by providing a comprehensive view of the components that need to be managed and secured. All information system components are tracked from acquisition to retirement as part of the organization’s SDLC process.

Per CM-8 in the OCC’s Master Security Control Catalog (MSCC), the OCC is required to develop and document an inventory of information system components. ITS divisions may meet this requirement by implementing division-level ISCIs. Division-level ISCIs must meet the requirements of CM-8 and be documented with an ISCI directory. At a minimum, ISCI directories will describe:

1. The specific systems (e.g., AMR-ASI, ServiceNow CMBD, SharePoint) in which information system component information is stored

2. The information system components (e.g., applications, databases, interfaces, operating systems, servers, routers) that are stored in the division-level ISCI

3. The attributes of each information system component that will be stored in the division-level ISCI and information about whether an attribute is required or optional

4. Who in the division is responsible for updating information in the division-level ISCI

5. The frequency at which information in the division-level ISCI is updated

The Technology Change Management & Governance Program Office may review ISCI directories and require changes, if necessary.

When necessary, data from a division-level ISCI, including updates, will be provided to other ISCIs. To the extent possible, data exchanges between ISCIs should be automated.

Each division is responsible for providing their list of Enterprise Services, Products and Platforms, and supporting attributes which will be used to govern changes within change management framework. This http://share/sites/CIO/ITPP/itPSP/Policy%20Library/Master%20Security%20Control%20Catalog.pdf allows the CM team to identify which attributes to be reviewed during audits to ensure those attributes are being updated with each change to any service, product or platform stored in their ISCI.

Note: In the absence of an approved division level CI attribute catalog, the Change Control Model in Appendix A will be used to govern changes.

See appendix B for a list of division-level ISCI directories.

2.1.3 Configuration Control

Configuration control is a set of activities and approval stages required to change a CI attribute. Configuration control provides oversight to ensure that a CI is changed through the Change Management (ChM) process. Configuration control ensures that there are adequate control mechanisms over CIs while maintaining a record of changes to CIs, versions, location and ownership. No CI or CI attribute should be added, modified, replaced or removed without an appropriate system level controlling documentation or procedure being followed. Change owners and their teams are solely responsible for making updates to all affected CI attributes as those CIs complete the Change Management. The Enterprise CM team may audit affected CIs detailed in completed CRs to determine if the related CI information system components and attributes have been updated in their respective ISCIs. Please see the Change Control CI Model in Appendix A for guidance on the recommended CI specific attributes to be captured by each system team and which of those attributes (where applicable) require a CR to be updated. Please note the model in Appendix A serves only as a guide to Change Management of CIs and their related information system components. It is not expected that every attribute listed in the model will be applicable to every CI shown in the model.

2.1.3.1 Control Mechanisms

Configuration control typically involves specific roles performing a series of steps in an iterative, incremental, and sometimes parallel manner. The ECCB is the final authority on configuration change control. The ECCB functions as the body assigned to review changes and to assist Change Management in the assessment and prioritization of changes. The ECCB convenes regularly to review changes that meet the criteria for approval and that meet the submission deadlines as defined in the Change Management Plan.

2.1.4 Configuration Status Accounting & Verification

2.1.4.1 Status Accounting

The configuration status accounting and reporting process ensures all configuration data and documentation is recorded as each asset or CI progresses through its lifecycle. It provides the status of the configuration of a service and its environment as the configuration evolves through the service lifecycle. Status accounting provides the means by which the current state of the OCC infrastructure can be judged and the history of the CI lifecycle can be traced.

Typical (sample) reports might include:

• A list of product configuration information included in a specific configuration baseline

• A list of configuration items and their configuration baselines

• Details of the current revision status and change history

• Status reports on changes and deviations

• Report on unauthorized usage of hardware and software

• Variations from ISCI to physical audit reports

2.1.4.2 Verification & Auditing

The verification and audit process performs the inspection between the recorded data in the ISCI and the actual physical condition of the assets in the field. Verification is the process of comparing a work product with its parent specification or a standard for the purpose of detecting errors. Verification answers the question “Was the product built correctly?” Configuration audits provide the framework and the detailed requirements necessary to verify the development effort has successfully achieved all of the requirements specified in the configuration baselines.

The appropriate CM POC’s participate in program and design reviews and conducts baseline audits in accordance with a defined audit procedure. Baseline audits are conducted on server hardware, application software, and network components on an annual basis with more frequent audits based on the change and release activity of the environment. Specific milestone requirements for conducting specifically defined audits are supported.

These audits help ensure:

• Changes to CIs are properly documented in the ISCI and all supporting documentation

• All CIs identified for specified baselines are present and no extraneous CIs exist in the baseline

• CIs are acquired into the product baseline according to the documented standards and procedures

• Unlicensed or unapproved products, services, or platforms are not installed or in use in the environment infrastructure

• Conformity between the documented baselines (e.g., agreements, interface control documents) and the actual business environment to which they refer

• Verification of the physical existence of CIs in the organization and, and verification that the functional and operational characteristics of CIs detailed in the ISCI match the physical infrastructure

• The release and configuration documentation is present before deploying a release

In addition, configuration audits check that CRs have been properly authorized by Change Management and that implemented changes are authorized. Configuration audits should be considered at the following times:

Before a release or installation to ensure that the environment is as expected Following recovery from disasters and after a ‘return to normal’ state (this audit should be included in contingency plans) At minimum on an annual basis with more frequent audits based on the change and release activity of the environment In response to the detection of any unauthorized CIs

Automated audit tools enable regular checks to be made at regular intervals, e.g. weekly. For example, desktop audit tools compare the build of an individual’s desktop to the master build that was installed. If exceptions are found, some organizations return the build to its original state. A rolling program of configuration audits can help use resources more effectively. If there is a high incidence of unauthorized CIs detected, the frequency of configuration audits should be increased for those parts of the IT infrastructure.

2.2 Process Activities and Sub-Activities

Table 2 – Configuration Planning

Activity # 1 Configuration Planning

Sub-activities Key Process Points

• Project-Level Managers initiate the CM process by completing the Project-

Level CM Plan. Project-level CM Plans define the specific configuration management activities within the context of the overarching configuration management strategy

Reference: NIST Special Publication 800-53 (Rev. 4) - CM-9

Roles Enterprise Configuration Manager, Project-Level Manager, CI Owner

Timing When the project has been approved to be executed at the project level

Reference/Tools SDLC Configuration Management Plan Template, SDLC Tailoring Plan, ISCI

Outputs Project-Level Configuration Management Plan

Table 3 – Configuration Identification

Activity # 2 Configuration Identification

Sub-activities Key Process Points Baselines

• A configuration baseline captures and records an approved snapshot of an infrastructure CI and its components

• Although the state may be updated later, the baseline remains unchanged and available as a reference of the original state and as a comparison against the current position

• Enterprise configuration control assumes the responsibility at the higher level

• Project teams enforce configuration control at the lower level

• A component baseline is established for each CI

• If a change to a CI affects other CIs, the baseline is controlled at the enterprise level

• If a change to a component only affects a particular project-level CI, the baseline is controlled locally in the business unit and changes are recorded in the ISCI. Any changes to the component baseline (e.g., updating router parameters) must, at a minimum, adhere to “standard change” procedures for https://web.nvd.nist.gov/view/800-53/Rev4/control?controlName=CM-9

Activity # 2 Configuration Identification that organization. Typically, these changes do not require ECCB approval, but the changes must align with Enterprise policies and be updated in the ISCI

Baseline Establishment

• Configuration baselines for established CIs are brought under configuration and change control and used as departure points for the formal control of configurations. Configuration benchmarks, plus approved deviations to those benchmarks, constitute the currently approved configuration baseline

• Related hardware and software configuration items are grouped into system or service baselines. Each configuration item is treated as an independent entity in the CM tool. Each product component is uniquely identified in the baseline.

The unique identifier is used to track and report the status of configuration items

• A documentation and data information baseline is established at the Program Level and is subject to configuration control and data management processes identified in this CM plan. Changes to the baseline are controlled according to the Enterprise CM Plan

Baseline Version Identification

• Several baselines in different stages in the life of a configuration item can exist at the same time

• Since more than one version of a baseline may be “live” at the same time, a unique version number is assigned to each rather than referring to them by status (e.g., live, next, old, archived)

• Release & Deployment Management outlines the policy and procedures for maintaining control of CI baselines in the test and production environments

Reference: NIST Special Publication 800-53 (Rev. 4) - CM-2

Roles Enterprise Configuration Manager, Project-Level Manager, CI Owner, TCM&G Program Office Manager, Technical SMEs, ECCS Members

Timing When the project is ready for ECCB review

Reference/Tools TCM&G Glossary, Impact Assessment, SDLC Tailoring Profile, ECCS, ISCI

Outputs CR(s), ISCI Updates https://web.nvd.nist.gov/view/800-53/Rev4/control?controlName=CM-2

Table 4 – Configuration Control

Activity #3 Configuration Control

Sub-activities Key Process Points Information System Component Inventory

• Information system components must be tracked in an ISCI. Division-level

ISCIs are allowed.

• Division-level ISCIs must be documented with an ISCI directory. See Appendix B Division-Level ISCI Directories for the latest division-level directories.

• Every system component is included within the authorization boundary of an information system and should be documented and tracked in an inventory which reflects the association with the information system under which it is managed, for example, a component associated with an information system is included in that information system component inventory. A component may support information systems that are not within the same authorization boundary (such as a server that supports several Web applications or virtual machines)

• It is recommended that Configuration Item owners update their component attributes as they are changed in order to maintain an accurate and up to date ISCI. Examples of recommended attributes to update include, but are not limited to, organizational unique identifiers, information system association (depending on network configuration, whether the inventory management tool installation is at the organizational level or system level, etc.), system/component owner, administrator, or user, configuration item association, or type of component.

• Please reference Appendix A - Change Control Configuration Item Model & Attributes List which identifies attributes that require a CR when they are being updated/changed. System owners are not required to maintain the attributes detailed in the Change Control Model in their ISCIs, however, where they are maintained, it is recommended that CI Owners update their identified CI specific attributes in their respective ISCI as an integral part of authorized CI component installations, changes, and decommissioning.

• Change owners and their teams are solely responsible for making updates to all affected CI component attributes they’ve identified in their component inventory directories as those CIs complete the Change Management lifecycle. The Enterprise CM team will then audit affected CIs listed in completed CRs to determine if those CI component attributes have been updated.

Activity #3 Configuration Control

On-going Configuration Control Processes

• Registering all new CIs and new versions in the division-specified ISCI

• Updating CRs with related CIs, status, and implementation details

Configuration Control Gates and Activities

• Service request through the Service Desk and Incident and Problem Management processes

• Configuration Status Accounting that monitors the evolution of CIs throughout their life-cycle

• Configuration Audits & Reviews ensure conformance to the CM procedures and propose improvements to the process

• CRs go through the CM processes to ensure changes are coordinated:

o When a CR is submitted to modify the approved baseline, it is presented to the ECCB to assess the impact of the change to the infrastructure o The ECCB evaluates the impact of the proposed change and recommends approval. If approved, the ECCB agrees on the implementation date o After the change is tested and implemented, the new baseline is updated in the ISCI o The Release Manager facilitates the Post Implementation Review

(PIR)

o The CI Owner updates the division identified attributes of the CI in their

ISCI

Reference: NIST Special Publication 800-53 (Rev. 4) - CM-3

Roles CI Owner, Change Owner, Enterprise Configuration Manager, Project-Level Manager, TCM&G Program Manager, Technical SMEs, ECCS Members

Timing Throughout the project lifecycle

Reference/Tools TCM&G Glossary, Impact Assessment, SDLC Tailoring Profile, ECCS, ISCI, , TCM&G CM Plan Template, NIST Special Publication (SP) 800-53, Revision 4 CM-9 - CM Plan, NIST Special Publication 800-53 (Rev. 4) - CM-3, Special Publication (SP) 800-53, Revision 4 CM-8

Outputs CR(s), ISCI Updates

Table 5 – Status Accounting https://web.nvd.nist.gov/view/800-53/Rev4/control?controlName=CM-3 https://web.nvd.nist.gov/view/800-53/Rev4/control?controlName=CM-9 https://web.nvd.nist.gov/view/800-53/Rev4/control?controlName=CM-9 https://web.nvd.nist.gov/view/800-53/Rev4/control?controlName=CM-3 https://web.nvd.nist.gov/view/800-53/Rev4/control?controlName=CM-8 https://web.nvd.nist.gov/view/800-53/Rev4/control?controlName=CM-8

Activity #4 Status Accounting

Sub-activities Key Process Points

• Recording and reporting the status of CI changes from initiation to final approval and implementation

• Record and report the results of configuration audits to include the status and final disposition of identified discrepancies and action items

• The stages that different types of CIs go through must be properly documented and the status of each CI must be tracked

• Recording the current approved configuration documentation and configuration attributes associated with each CI

Roles Enterprise Configuration Manager, Project-Level Manager, CI Owner, TCM&G Program Office Manager, Technical SMEs, ECCS Members

Timing Throughout the project lifecycle

Reference/Tools TCM&G Glossary, Impact Assessment, SDLC Tailoring Profile, ECCS, ISCI

Outputs CR(s), ISCI Updates

Table 6 – Verification & Auditing

Activity #5 Verification & Auditing

Sub-activities Key Process Points Physical Configuration Audits (PCAs)

• The appropriate OCC resources analyzes and notes any discrepancies between the configuration status information and the physical components of the service

• The appropriate OCC resources compares the data in the CM tool with the physical configuration of the deployed infrastructure components to verify that the CI “as-built” conforms to the technical documentation related to the CI(s)

• The physical configuration audit is scheduled to run concurrent with the functional configuration audit if scheduling permits

Functional Configuration Audit (FCA)

Activity #5 Verification & Auditing

• The appropriate OCC resources validates that the CI adheres to the performance and functional characteristics specified in the requirements and design documentation and that all operation and support documents are complete

• Functional audits are performed for application software, COTs, and customized products that deliver a functional requirement

• The CM team enlists participation from system testers to perform functional audits

Baseline Configuration Audit (BCA)

• The CM baseline audits are led by the Enterprise CM team

• The audits are planned in advance to secure the appropriate resources to participate in the audit

• The CM team assesses the integrity of the baselines by performing the following activities o Verifying that all selected configurations are recorded in the ISCI tool o Verifying the correctness and completeness of all CIs by validating that the CIs match their documented descriptions. The team verifies that each change to a baseline was implemented through the documented Enterprise Change Management process o Reviewing the CM libraries for evidence of security controls and interfaces that control access to configuration information in the ISCI on a need-to-know-basis. The auditor verifies the integration with the change management process that ensures updates to CI records are not allowed without corresponding approved CRs.

o Submitting an audit report to the system owner at the conclusion of the audit o Generating an action items list that identifies discrepancies and a plan of action to correct the issues o Analyzing inefficiencies and problems identified in the CM process and executing a plan to resolve them

Configuration Audit Frequency

• Configuration audits should be considered at the following times o Before and after changes to the IT infrastructure o Before a release or installation to ensure that the environment is as expected o Following recovery from disasters and after a ‘return to normal’ (this audit should be included in contingency plans) o At minimum on an annual basis with more frequent audits based on the change and release activity of the environment in response to the

Activity #5 Verification & Auditing detection of any unauthorized CIs

Roles TCM&G Program Office Manager, Enterprise Configuration Manager, Project-Level Manager, CI Owner

Timing At agreed upon intervals that do not interfere with product development

Reference/Tools CM Audit Checklists, CM Report(s)

Outputs CM Audit Report(s)

2.3 Supporting Process Activities

The Enterprise Configuration Management Process is responsible for maintaining the integrity of information pertaining to the configuration of Configuration Items (CIs) and their relationships to one another, depicting the makeup of OCC ITS Services and Applications. CM manages CIs throughout their lifecycle. Other supporting processes are:

Enterprise Change Management (ChM) – ChM is the process responsible for controlling the lifecycle of all changes made to ITS’ hardware, software, documentation, and services. The primary objective of ChM is to enable beneficial changes to be made with minimum disruption.

Enterprise Release & Deployment Management (RDM) – RDM is the process responsible for managing the design, build, test, deployment planning and actual deployment of the release. RDM works with ChM to ensure risk is minimized and that the release has been approved prior to being deployed. Together, both processes coordinate the parallel activities performed by multiple teams to ensure that activities are done in an orderly fashion.

Enterprise Test Management (TM) – TM is the process responsible for validation and testing of new or changed software, hardware and the business services ITS provides.

Validation and testing ensures that the IT Service matches the design specification and will meet the needs of the business.

Enterprise Problem Management (PbM) – PbM is the process for managing the lifecycle of all problems that are affecting ITS Services, Documentation, Hardware, or Software. PbM identifies the root cause of problems and the primary objectives are to make sure services are stable, timely, accurate, that problems do not recur and to minimize the impact of incidents that cannot be prevented.

Enterprise Quality Management (QM) – The QM process monitors all ITS TCM&G governed processes, and provides ITS with objective information pertaining to the quality of its systems and services. QM achieves this by performing quality assurance reviews on all processes used to develop and maintain ITS systems and services.

System Development Lifecycle Management (SDLC) – SDLC is the methodology that establishes defined, repeatable processes for new system development and existing system enhancement, maintenance, and disposition projects that improves communications. Additionally, the SDLC promotes consistency across projects, ultimately helping ensure that ITS systems development projects meet customer expectations for quality, cost and schedule.

Information System Component Inventory (ISCI) ITS uses multiple Information System Component Inventory (ISCI) tools to maintain accountability and data integrity of the configuration items (CIs) throughout the service lifecycle. The ISCI tools house CI component data in accordance to CI class and managed by the CI Owners, who are responsible for maintaining the changes of CIs and any related components and documentation.

Appendix A: Change Control Configuration Item Model & Attributes List

Legend

Computers

Mass Storage Devices

CI Super-Class

CI Sub-Class

Any change to a Change Controlled Attribute requires an RFC

Change Control Model

- Associated Domain(s) - CI Name - Status

- Relationships/dependencies - Associated Environment(s)

Change Control Attributes

Hardware (Physical or Virtual) Software

Hardware Attributes

• IP Address

• Model

• Ports/Protocols

• Type (Physical or Virtual)

• DNS Name

• LocationNetwork Devices

Telecommunication Devices

Telecommunication Software

Operating Systems

Databases

Applications

Software Attributes

• Business Rules

• Firmware

• GPO Technical Controls

• Ports/Protocols

• Runtime Services

• Stored Procedures

• Version

• URL

Enterprise Services/Platforms/Products

Please note this model serves only as a guide to Change Management of CIs and their related information system components. It is not expected that every attribute listed in the model will be applicable to every CI shown in the model. For the very latest version of the Enterprise Change Control CI Model and the associated attributes, please go to: Change Control CI Model http://share/sites/CIO3/pg/TeamDocs/draft_CI_Model_20161020.vsdx

Appendix B: Division-Level ISCI Directories

Platform Management’s Infrastructure and Operations (I&O) and Application Services Delivery (ASD) have division-level ISCIs. Follow the links below to view their ISCI directories.

I&O Information System Component Inventory Directory

ASD Information System Component Inventory Directory

NOTE: Vendors will not have access to the links above.

http://share/sites/CIO/IO/IODocs/IO%20Documents/Component%20Inventory%20Directory.docx http://share/sites/OMCFO/OPMO/Published%20Links%20to%20ASD%20Content/ASD%20Operations/ASD%20ISCI%20Directory.aspx

Appendix C: Glossary Technology Change Management & Governance (TCM&G) Glossary

Note: Vendors will not have access to the link above.

http://share/sites/CIO3/pg/SitePages/Glossary/default.aspx

Information Technology Services

Enterprise Change Control Board (ECCB) Charter

Version 11

March 10, 2020

Enterprise Change Control Board Charter ii

VERSION AUTHOR CHANGES IN THIS VERSION DATE

1.0 L. Dickstein Initial Release 03/21/2007

2.0 L. Dickstein Second release 11/02/2007

2.1 ALON, Inc. 1st modification – added assessment

criteria 04/30/2008

2.2 ALON, Inc. 2nd modification – added PIR and

changed the voting structure 06/30/2008

2.3 ALON, Inc. Incorporated OCC comments from 2nd

review 07/09/2008

3.0 ALON, Inc.

Modified to remove references to TiCAB and to incorporate comments from the peer review

08/19/2008

4.0 Greg Algorri Modified approved definition changes.

Removed items covered in CM Plan 12/17/2009

5.0 Rob

Cimperman

Revised version that includes all “Future State” decisions made based on P&G direction and SLT2 feedback

1/24/2012

6.0 Rob

Cimperman

Incorporated Mike Zuckerman’s feedback on review of final version. 1/27/2012

6.1 Rob

Cimperman

Added Customer Support as a voting member for RFC Planning decisions, and updated quorum description accordingly.

8/13/2012

7 Rob Cimperman

Modified the voting procedures to clarify virtual/in-person rules, and make references agnostic as to the target environment name.

8/16/2012

7.1 Rob

Cimperman

Based on ITCS Review, modified areas including references to MRs, removed SLA as a reason for an emergency, and clarified that the ITS Manager to approve an emergency should be the owner of the CIs involved.

8/16/2012

7.2 Rob

Cimperman

Based on additional feedback from ITCS, made several modifications. 9/13/2012

7.3 Rob

Cimperman

Corrected an inconsistency in Section 8 where tied votes were mentioned. There will be no ties with unanimous voting.

9/26/2012

7.4 Eboni Staton

Added references to “production” back in the document in 15 places where it was removed between v7.2 and v7.3

11/19/2012

7.5 Eboni Staton

Removed all references to “production environment” and the risk based approach to change management.

2/25/2013 iii

Added new change types and release complexity, References to CI Model

7.6 Kai

Richardson Added Policy Exception Request policy. 10/30/2013

7.7 Kai

Richardson

Updated to explicitly include release authorization 12/12/2013

7.8 Kai

Richardson

Updated RFC definitions and link to new P&G Glossary. Removed reference to approval of Policy Exceptions

3/10/2015

8.0 Kai

Richardson

Revised Emergency RFC definition.

Updated to reflect ECCB meeting changes and combining with ERG.

Defined CI Ownership and CI Owner Responsibilities.

11/05/2015

9.0 Kai

Richardson

Integrated ERG into the ECCB charter, including scope, processes, etc.

Removed references to CMDB

6/14/2016

9.1 Kai

Richardson

New change request framework and definitions 11/30/2017

10 Kai Richardson

New IPPT change authorization framework 3/2/2018

10.1 Kai

Richardson

Updated approval definitions to include ECCB Chair. Updated to reflect ITS realignment.

4/15/2019

11 Kai Richardson

Updated to reflect ITS realignment and process changes under CERM.

Removed appendices to new ECCB procedure. Changed P&G to TCM&G.

1/15/2020 iv

TABLE OF CONTENTS

INTRODUCTION

AUTHORITY/SCOPE

MEMBERSHIP

INTRODUCTION

The Enterprise Change Control Board (ECCB) represents the interests of the OCC and Information Technology Services (ITS) by using a structured process for managing changes to ITS platforms, products, and enterprise services in alignment with the ITS Operational Plan. The ECCB, guided by the IT Governance Policies, focuses on change control of hardware, software, and document Configuration Items (CIs). It does this by assessing the complexity, scope, schedule, priority, and risk of proposed changes.

Change control helps ensure that new or altered CIs perform as expected by managing the full lifecycle of the change. Proposed alterations to CIs are requested by submitting a formal change request to change, remove, or add a new CI. Change requests must be entered into the Enterprise Change Control System (ECCS) as soon as the work is known.

The ECCB is part of the enterprise change and quality-control framework within ITS. It consists of voting members representing key ITS services, as well as non-voting subject-matter experts (SMEs) from the relevant Integrated Product and Platform Teams (IPPTs).

The ECCB ensures adherence to the ITS Service Delivery Framework (SDF). The SDF seeks to strengthen process integration between ITS delivery partners to improve and accelerate the delivery of IT services to customers. The SDF’s goals are to:

• Improve organizational work request execution, while enhancing customer business intelligence;

• Improve the integration of security requirements across the service management lifecycle to reduce customer deployment risk and disruption;

• Improve business intelligence reporting and transparency by capturing the status of ITS work request across the lifecycle.

The ECCB strives to reduce the risk of changes to CIs being unsuccessfully deployed to their target environment(s) by validating compliance with approved change and release management policies and procedures; obtaining all necessary approvals; and evaluating deployment risks based on information provided in final test reports, version description documents, audit results, impact assessment revisions, release management plans, communication plans, and other Service Delivery Life Cycle documentation.

For definitions and acronyms related to the ECCB and ITS IT governance processes and procedures, please see the glossary.

http://share/sites/CIO/ITPP/itPSP/Policy%20Library/Information%20Technology%20(IT)%20Governance%20Policies%20V3.0.pdf http://share/sites/CIO3/pg/SitePages/Glossary/default.aspx

AUTHORITY/SCOPE

This charter establishes the ECCB as a voting board with authority to:

• Review proposed changes to configuration items (CIs) to evaluate proper implementation and validate the operational readiness1 of changes to existing services; new services; and technologies managed by ITS.

• Approve2, reject, or cancel planned changes to CIs. This authority includes oversight of all activities related to test readiness reviews, test status accounting, test analysis reports, and all other supporting activities related to releasing a new or modified CI.

• Provide release/deployment authorization for change requests (CRs).

• Review and provide release/deployment re-authorization for all CRs when it is determined there has been a modification to the scope that increases the risk of the CR prior to, or during, deployment.

• Resolve disagreements about the risk and/or impact assessment of a change request.

• Authorize conversion of Normal change requests to Standard change requests.

• Prioritize changes reflected in the Forward Schedule of Change (FSC) and ensure that any scheduling conflicts are resolved.

• With noted exceptions, recommend that deployments are scheduled according to the approved maintenance and release windows.

• Approve the establishment and/or modification of the yearly release calendar.

• Ensure adherence to the ITS Service Delivery Framework

• Establish and approve ECCB operating procedures, program definitions, and CR approval processes and requirements.

MEMBERSHIP

The membership of the ECCB consists of both voting and non-voting members. The voting membership of the ECCB includes ITS division representatives from the following ITS services:

Cyber Security Services Desktop & Service Desk Services Software Engineering Services Enterprise Infrastructure Services Enterprise Data Services Business Relationship Services

1 Operational Readiness Assessment ensures the operating environment is prepared to effectively support and accept the changes resulting from a change or project. The evaluation includes, but is not limited to, impacts on risk posture, security, infrastructure and organizational change management.

2 ECCB approval of a CR indicates that all ITS voting groups agree the change meets all change management requirements including those for documentation, coordination, testing, and communication, and is ready for deployment.

https://tableauprod.occ.treas.gov/#/views/TCMGDashboard/Forwar…