Attachment_14_-_Infrastructure_Configuration_Management_Plan_(ICMP).pdf

Office of Information Technology

Infrastructure Configuration

Management Plan (ICMP)

Version 1.6

Last Updated Date: 13 August, 2015

IO-GDE-01-01

Infrastructure CM Plan

Revision History

Version Date Author Sections Changed

Description/Comments

1.0 09/03/2010 ITIOD/SSD

Configuration Management

N/A Initial Draft

1.1 01/07/2013 CCRM IPT All Updates per IPT recommendations

1.2 02/07/2013 CCRM IPT All Updated to reflect IPT document walkthrough recommendations

1.3 03/12/2013 CCRM iCAP Project Team

All Changed name of document to clarify the scope of the document; Made updates throughout to be consistent with the ICMP Process document and SOP.

1.4 03/28/2013 CCRM iCAP Project Team

Throughout Incorporated comments/feedback from GCB

1.5 10/07/2014 CCM Security Project Team

Throughout Replaced Business Change Management with Change Management, TEM with IEM, and CCRM iCAP with CCM project.

1.6 8/13/2015 ITIOD Throughout Updated to align with current process, needs and requirements

Version 1.6 i 13 August, 2015

Contents

1. INTRODUCTION

1.1 Background

1.2 Related Documents

1.3 Scope

2. ROLES AND RESPONSIBILITIES

3. PROCESSES AND PROCEDURES

3.1 Configuration Management Planning

3.2 Configuration Identification

3.2.1 CM Framework Identification

3.2.2 Configuration Item Identification

3.3 Configuration Control

3.4 Configuration Status Accounting and Reporting

3.5 Configuration Verification and Audit

4. CONFIGURATION ITEMS

4.1 Configuration Item Types

4.2 Baseline Configurations

5. CM PLAN PROTECTION

APPROVALS

ACRONYMS

GLOSSARY OF TERMS

REFERENCES

List of Tables Table 1. CM Roles and Responsibilities

Table 2. Infrastructure Baseline Configuration Categories

Table 3. Glossary of Acronyms

Table 4. Glossary of Terms

Version 1.6 ii 13 August, 2015

1. Introduction This document, the Infrastructure Configuration Management Plan (ICMP), describes the current practice of configuration management (CM) for the Pension Benefit Guaranty Corporation (PBGC) Information Technology (IT) infrastructure. The ICMP was developed by the PBGC IT Infrastructure Operations Department (ITIOD) in accordance with agency standards and requirements to:

• Support regulatory requirements and demonstrated compliance with laws and regulations

• Describe CM support for operational capabilities

The Draft PBGC CM Standard, based on National Institute of Standards and Technology (NIST) Special Publication 800-53, Revision 4, CM-9, states the requirement that PBGC will document and implement “a Configuration Management Plan for information systems that:

• Addresses roles, responsibilities, and configuration management processes and procedures;

• Establishes a process for identifying configuration items throughout the system development life cycle and for managing the configuration of the configuration items;

• Defines the configuration items for the information system and places the configuration items under configuration management; and

• Protects the configuration management plan from unauthorized disclosure and modification”

This document focuses primarily on the management of configuration items in production environments.

It is organized to directly address the above requirements in sections named as listed below:

• Roles and Responsibilities

• Processes and Procedures

• Configuration Items (CI)

• CM Plan Protection

1.1 Background

PBGC CM policy is described in the reference PBGC Information Security Policy Information Management Directive (IM) 05-2 as “derived from, and embodied by, the PBGC Information Security Standards and Information Security Controls Matrix, based on NIST SP 800-53.” In particular, the following PBGC CM policies are defined under the "Configuration Management (CM Control Family):

a. PBGC (typically owners or collaborators) shall develop and maintain information system security and component inventories, including hardware, software, and firmware.

b. Information systems shall conform to established baseline configurations.

c. Appropriate change control processes shall be established and followed to ensure that PBGC information system configuration changes are controlled properly, documented, and that documentation is retained and reviewed.”

1.2 Related Documents

The ICMP describes the approach by which ITIOD establishes, manages, controls and monitors the configuration of the ITISGSS and its components. Details of how this is done are presented in various process and procedure documents which are listed by name in the references section at the end of this document.

Version 1.6 1 13 August, 2015

1.3 Scope

The scope of this plan includes the activities that constitute PBGC Infrastructure CM, the roles and responsibilities involved, the span of Infrastructure CI types that are managed, and the attributes and relationships of the Infrastructure CI types that are managed. The managed CIs comprise the collection of infrastructure CIs that constitute the PBGC Information Technology Infrastructure Services General Support System (ITISGSS) system, plus components of any other PBGC Federal Information Security Management Act (FISMA) systems to which ITIOD extends CM as an inheritable service as described in PBGC IT Service/Application Mapping Process (IO-PRO-12-01).

Version 1.6 2 13 August, 2015

2. ROLES AND RESPONSIBILITIES

Table 1 identifies the major CM roles and responsibilities established by this plan. More detailed information on roles and responsibilities may be found in the reference document, ITIOD Configuration Management Process, IO-PRO-01-01.

Table 1. CM Roles and Responsibilities

Role Description Change Manager The Change Manager approves requests for change and is assisted by the

CAB. The Change Management Process manages requests for new CIs and changes to existing CIs.

CI Type Owner The CI Type Owner is a specialist who has been authorized by the appropriate ISO to approve and confirm changes to CI types and their infrastructure baseline configurations, and who is considered to have the requisite specialized knowledge of a system and its components to make such decisions. The CI type owner

• Is responsible for concurrence or non-concurrence with CI type change decisions that move an RFC through the Change Management Process.

• Reviews and approves changes to managed infrastructure baseline configurations for the CI types

• Resolves infrastructure baseline configuration deficiencies that have been brought to his or her attention

• Is the owner of all CIs within the given CI type, with the exception of application CIs, whose ownership is described under that heading

• Keeps the Configuration Manager informed of all decisions.

• Coordinates as appropriate with other CI type owners when interfaces change CM Administrator The CM administrator controls the receipt, identification, and maintenance of all supported CI information in the CMS. To perform this role the CM administrator

• Ensures and confirms that configuration information in the CMDB is up-to-date once a change has been implemented.

• Ensures that changes that require modification of an infrastructure baseline configuration are identified

• Provides reports, including management reports, impact analysis reports and configuration status reports

• Processes and maintains the content of the CMDB

• Maintains a schedule for automated and physical audits

• Reports the status of CIs

Version 1.6 3 13 August, 2015

Role Description Configuration Manager The Configuration Manager is accountable for the design, development, implementation and enhancement of the CM process. The Configuration Manager

• Determines the scope and level of detail of CM according to stakeholder business requirements

• Defines the CM model and associated standards and conventions for CI identification

• Obtains necessary approvals of CM process changes through the appropriate governance board

• Ensures that the CM process is communicated effectively throughout the enterprise

• Develops and ensures compliance with identification and naming conventions

• Plans and implements the population of the CMS

• Coordinates audits

• Provides training on the CM process

• Provides oversight of the activities of CI type owners and Change

Manager to the extent that their activities are governed by the CM process.

Information System Owner

(ISO)

PBGC Information Security Policy, Directive IM 05-2, states that “Information System Owners (ISO) are agency employees who are each responsible for and associated with the procurement, development, integration, modification, operation, maintenance, and disposal of an information system. “ To perform this role with respect to CM, the ISO

• “Serves as the focal point for the information system. In that capacity, the information system owner serves both as an owner and as the central point of contact between the authorization process and the owners of components of the system” (NIST SP 800-39)

• “Decides who has access to the system (and with what types of privileges or access rights)” (PBGC IM 05-2)

• Authorizes access and changes directly or through delegation of authority to CI Type owners and Service / Application Owners.

Service / Application Owner

For application CIs, the Owner is the Service / Application Owner who has been delegated the responsibility to review and approve change requests and access requests to a service or application by the FISMA system’s ISO.

The assignment, and delegation of authority for this role are described in the reference document, IT Service/Application Mapping Process IO-PROD-12-

01. The Service / Application Owner is responsible for concurrence or non-concurrence with changes to a service or application, and for validation of the functionality of the application through the release and deployment process.

Version 1.6 4 13 August, 2015

3. PROCESSES AND PROCEDURES

This section describes the five standard CM activities as they are applied to the PBGC IT infrastructure.

The component activities of CM are planning, identification, control, status accounting, and verification and audit.

3.1 Configuration Management Planning

CM planning defines the purpose, scope, approach, and the organizational and technical context for CM and establishes the organizational expectations for CM. It defines the criteria for selection of CIs to be placed under configuration control, and establishes the goals and objectives for the processes that track and control changes to CIs. CM planning includes the development of CM processes, procedures and work instructions. The ICMP and its revisions are products of the CM planning activity. CM planning is a primary responsibility of the Configuration Manager.

3.2 Configuration Identification

Configuration identification is performed at two levels. First, it is concerned with the definition and establishment of a framework and model for performing CM. Second, it involves the identification of individual CIs within the model as they are created and placed under CM.

3.2.1 CM Framework Identification

A framework is first established within which CIs, and related standards and procedures can be created and maintained. This framework includes the CM model (section 4), baseline types (section 4.2), and other items defined in work instructions, such as naming conventions, methods for the allocation of identifiers and version numbers for CIs, and the labeling and creation of CIs in the Configuration Management Database (CMDB). The CM model comprises CI types that define the set of characteristic attributes and relationships for each type of CI that will be placed under configuration control. These activities are performed primarily by the Configuration Manager.

3.2.2 Configuration Item Identification

CI identification involves the identification and creation of representations of CIs that belong to the CI types defined within the CM model. CIs are represented by records in the CMDB that describe the attributes and relationships defined for the CI type to which they belong. This activity is performed either through manual or automated CI discovery processes. The addition of CIs is performed according to the processes listed in section 3.3. How this is done is described in the reference process, procedures and work instruction documents. The management of individual CIs is primarily the responsibility of CI Type Owners with support of the CM Administrator.

3.3 Configuration Control

Configuration control ensures that only authorized and identified CIs are accepted and recorded. It ensures that no CI type, CI, or baseline configuration is added, modified, replaced or removed without approval and without appropriate controlling documentation.

At PBGC, configuration control is implemented in accordance with the following documented PBGC processes:

• Change Management Process – Performs governance over any requested changes to CIs that support services provided by PBGC in infrastructure environments. It does this through the

Version 1.6 5 13 August, 2015 javascript:void(0);

review and approval of requests for change (RFC). This governance covers all changes to hardware, software (Commercial Off-The-Shelf (COTS) or PBGC-developed), and all documentation associated with these changes. This process is defined in the reference documents, ITIOD Change Management Process, IO-PRO-05-01, and Office of Information Technology (OIT) Change Advisory Board (CAB) Charter, IO-CHT-01-01.

• Release and Deployment Management Process – Controls build and test activities for implementation and delivery into production for CI changes that have been approved via the change management process. This process is defined in the reference document, ITIOD Release and Deployment Management Process, IO-PRO-10-01.

• Information Technology Solutions Life Cycle Management (ITSLCM) – Defines the life-cycle framework by which IT programs and projects identify, plan, implement, maintain and dispose of IT solutions.

Major infrastructure changes are controlled through the Change Management process by the Change Manager with guidance provided from the CAB as authorized by the CAB Charter. Changes are approved by the direct or delegated authority of the Information System Owner (ISO) who is accountable for the system being changed as described in IO-PRO-12-01.

All changes to defined and controlled infrastructure configurations baselines must be approved by the CI Type Owners who have been delegated that authority by the appropriate Information System Owner (ISO). The CM administrator must be notified of any changes that require modification of an infrastructure baseline configuration. The CIs that are identified to be changed are reported to the CM administrator to ensure that all changes are recorded in the CMDB.

3.4 Configuration Status Accounting and Reporting

Configuration status accounting and reporting is the process of recording and reporting the current and historical status of a CI throughout its system development life cycle.

CI status information includes the approved configuration of a CI, the status of proposed changes, and the implementation status of approved changes. Status accounting ensures that changes to CIs and their records are traceable and auditable. At PBGC, status changes are logged in the IT Service Management system in support of and as a result of decisions made in the Change Management processes through the processing of RFCs, as defined by reference in section 3.3.

Reports are most often generated and used to analyze the operational impact of a component failure or change and to document regulatory compliance.

3.5 Configuration Verification and Audit

Configuration verification and audit confirms, by means of a series of reviews and audits, that CIs exist, that they are compliant with applicable configuration standards, and that their information is correctly recorded and consistently documented in the Configuration Management System (CMS). The Configuration Manager is responsible for coordinating these audits.

Compliance is verified by conducting periodic audits at appropriate levels of granularity to check the status of CIs against infrastructure baseline configurations, e.g., by comparison of deployed configurations of devices against product baseline configurations to ensure that the CIs are in compliance with approved versions and configuration settings.

The degree of verification and audit process applied to a CI is defined by

• Whether the CI Type is defined in CM Model, i.e., whether it is in scope as a managed asset

Version 1.6 6 13 August, 2015

• Criticality, based on risk as a function of impact and likelihood, described in the PBGC risk framework, reference EP-PRO-03-01.

• Technical cost

• Feasibility

Discrepancies discovered during an audit will be reported to the CI type owner, whose role is defined in section 2, and the appropriate PBGC infrastructure team.

Version 1.6 7 13 August, 2015

4. CONFIGURATION ITEMS

This section defines the set of CI types and the types of infrastructure baseline configurations that are within the scope and control of PBGC infrastructure CM.

4.1 Configuration Item Types

The CI types that are tracked by the PBGC infrastructure CM process are listed below. This list establishes the scope of managed infrastructure CIs.

• FISMA System

• PBGC Developed Application

• COTS Application

• Workstation – Windows

• Laptop - Windows

• Mobile phone

• Database – MS SQL Server

• Database - Oracle

• Server - Windows

• Server – RHEL

• Server – Solaris

• Server – ESXi

• Storage Array

• Backup Device

• Network Attached Storage

• Printer – Multi-Function Device (MFD)

• Printer – non-MFD (networked)

• Video Conferencing

• Video Streaming

• Telephony Device

• Router

• Network Switch

• Network Load Balancer

• Firewall

• Virtual Private Network (VPN) Concentrator

• Storage Switch

• Network Tap

• Remote Access Device

• Security Device

• Network Management Device

• Environmental Monitoring Device

• Blade Device

• Uninterruptible Power Supply (UPS)

• Virtual Local Area Network (VLAN) / Internet Protocol (IP) Subnet

• IP Address

The degree of CM process that PBGC applies to managing a CI is based on the following factors:

• Criticality based on risk as a function of impact and likelihood, described in the PBGC risk framework, reference EP-PRO-03-01.

• Technical cost

• Feasibility

Version 1.6 8 13 August, 2015

Details regarding the identification of components under CM are provided in the reference process and work instruction documents.

A subset of the CI types will be managed in aggregate, i.e., the status of individual CIs will not be tracked, but their overall configurations and relationships as a class of devices will be maintained and tracked.

Items in this category include workstations and mobile devices. For example, differences among workstations due to the user-directed installation of software products will not be tracked, but all workstations will be managed for compliance against standard operating system level baselines.

Version 1.6 9 13 August, 2015

4.2 Baseline Configurations

The two categories of infrastructure baselines most relevant to PBGC IT infrastructure CM are listed in Table 2. They are based on the Information Technology Infrastructure Library (ITIL) and NIST definitions and recommendations. These baseline categories address the configuration of individual CIs and the relationships among CIs, respectively.

Table 2. Infrastructure Baseline Configuration Categories

Baseline Description

Component Baseline The documented description and selected configuration settings for a CI type or a subset of a CI type (e.g. operating system or application version) as approved for deployment.

System Baseline The documented description of approved relationships among CIs, e.g., a system topology report generated from the CMDB.

Infrastructure baseline configuration management activities are the shared responsibility of CI Type Owners and the Configuration Manager.

Version 1.6 10 13 August, 2015

5. CM PLAN PROTECTION

Copies of the current version of the ICMP are maintained as follows:

1. A copy of the ICMP is posted on the PBGC Policy and Process Library (PPL) and can only be modified by authorized personnel.

2. Requests for changes to this document shall be submitted to the Infrastructure Configuration Manager.

Version 1.6 11 13 August, 2015

ACRONYMS

Table 3 lists the acronyms used in this document and their expansions.

Table 3. Glossary of Acronyms

Acronym

Definition

CAB Change Advisory Board CI Configuration Item CM Configuration Management CMDB Configuration Management Database CMS Configuration Management System COTS Commercial Off-The-Shelf ICMP Infrastructure Configuration Management Plan FISMA Federal Information Security Management Act GCB Governance Coordination Board IEM IBM Endpoint Manager IM Information Management IP Internet Protocol ISO Information System Owner IT Information Technology ITIL Information Technology Infrastructure Library ITIOD Information Technology Infrastructure Operations Department ITISGSS IT Infrastructure Services General Support System ITSLCM Information Technology Solutions Life Cycle Management MFD Multi-Function Device NIST National Institute of Standards and Technology OCM Oracle Configuration Manager OGC Office Government Commerce OIT Office of Information Technology PBGC Pension Benefit Guaranty Corporation PDU Power Distribution Unit PPL Policy and Process Library RFC Request for Change SOP Standard Operating Procedures UCMDB Universal Configuration Management Database UK United Kingdom UPS Uninterruptible Power Supply VLAN Virtual Local Area Network VPN Virtual Private Network

Version 1.6 13 13 August, 2015

GLOSSARY OF TERMS

Table 4 lists terms used in this document with definitions.

Table 4. Glossary of Terms

Term Definition Asset Any IT resource or capability where ownership and financial value can be tracked and access can be controlled. Resources can be viewed as a subset of assets, also including reserves such as money. A capability refers to intangible assets such as a facility/location or potential for an indicated use or deployment. Assets typically include elements of infrastructure and applications, but also include knowledge, people/custody, information, management, organizations and processes.

Baseline Configuration A documented, formally reviewed and agreed-upon set 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.

Maintaining baseline configurations requires creating new baselines as organizational information systems change over time. Baseline configurations of information systems reflect the current enterprise architecture. (NIST Special Publication 800-53, Rev 4)

Change Control The systematic proposal, justification, implementation, test/evaluation, review, and disposition of changes to the system, including upgrades and modifications. Configuration change control is applied to include changes to components of the information system, changes to the configuration settings for information technology products, emergency/unscheduled changes, and changes to remediate flaws. (NIST Special Publication 800- 128)

Configuration Item An identifiable part of a system (e.g., hardware, software, firmware, documentation, or a combination thereof) that is a discrete target of configuration control processes. (NIST Special Publication 800-128)

Configuration Management

A collection of activities focused on establishing and maintaining the integrity of products and systems, through control of the processes for initializing, changing, and monitoring the configurations of those products and systems. (NIST Special Publication 800-128)

General Support Systems

An interconnected set of information resources under the same direct management control that shares common functionality. A general support system normally includes hardware, software, information, data, applications, communications, facilities, and people. Examples can be local area networks, backbones, networks.

Version 1.6 14 13 August, 2015

REFERENCES

The following documents are referenced in the ICMP:

PBGC

1. PBGC Information Security Policy, Directive IM 05-2, OIT, March 2012

2. Draft PBGC Configuration Management Standard, SE-STD-01-34, June 2015

3. Office of Information Technology (OIT) IT Governance Coordination Board (GCB) Lifecycle

Process Standard Operating Procedures (SOP), EP-PRO-0101, Version 7.0, July 2012

4. Office of Information Technology (OIT) Configuration Management Process, IO-PRO-01-01, Version 1.4, October 2014

5. Office of Information Technology (OIT) Configuration Management Standard Operating

Procedures (SOP), IO-PRC-01-01, Version 1.4, October 2014

6. Information Technology Infrastructure Operations Department (ITIOD) Change Management

Process, IO-PRO-05-01, June 2014

7. Information Technology Infrastructure Operations Department (ITIOD) Release and Deployment

Management Process, IO-PRO-10-01, Version 1.1, July 2014

8. Office of Information Technology (OIT) Change Advisory Board (CAB) Charter, IO-CHT-01-01, February 2013

9. PBGC IT Solutions Life Cycle Management (ITSLCM) Framework, April 2015

10. Office of Information Technology (OIT) IT Service/Application Mapping Process, Version 1.0, June 2015

11. Office of Information Technology Oracle Configuration Manager (OCM) Configuration

Management Standard Operating Procedure (SOP), Version 1.9, March 2013,

12. Standard Operating Procedure for CiscoWorks Baseline Reporting, IOD-SOP-02, Version 3.1, May 2014

13. Standard Operating Procedure (SOP) for BigFix (IBM Endpoint Manager (IEM)) Administration, IOD-SOP-07, Version 0.6, July 2013

14. Standard Operating Procedure for Universal Configuration Management Database (UCMDB), IOD-SOP-06, Version 1.1, June 2013

15. PBGC System Privilege Standard, SE-STD-01-04, May 2014

16. IT Risk Management Process and Procedures, EP-PRO-03-01, Version 8, April 2015

NIST

17. Security and Privacy Controls for Federal Information Systems and Organizations, NIST Special Publication 800-53 Revision 4, April 2013

18. Guide for Security-Focused Configuration Management of Information Systems, NIST Special Publication 800-128, August 2011

19. Managing Information Security Risk, NIST Special Publication 800-39, March 2011

20. Guide for Developing Security Plans for Federal Information Systems, NIST Special Publication

800-18, Revision 1, February 2006

21. Risk Management Guide for Information Technology Systems, NIST Special Publication 800-30, august

Industry Guidance

22. Service Transition, Information Technology Infrastructure Library (ITIL®), United Kingdom (UK) Office of Government Commerce (OGC), 2007

Version 1.6 15 13 August, 2015