S02 - PWS - ATCH - A to K - Remote Patient Monitoring Home Telehealth FY 22 09082021.pdf

INDEX: RPM HT ATTACHMENTS

ATTACHMENT DOCUMENT NAME Version & Date

A Topology Creation Modification and Maintenance SOP

1.0 12/10/20

B Configuration Management Plan Template

NA

C eMASS Authorization Requirements SOP Guide

1.18 12/11/20

D CRISP Mandatory Compliance Responsibility

Memorandum

2/15/2015 MFR

E VA Windows Server Baseline 2.0 2/25/2019

F Red Hat Enterprise Linux Secure Configuration

Baseline

2.3 7/29/20

G RPM-HT Growth Plan Template

NA

H ECC Tools on Performance Monitoring

NA

I Minimum Technical Requirements for Platforms and Peripherals

NA

K VA Home Telehealth Date/Time and

Measurement Business Rules

3.0

L RPM-HT VistA Integration Test Plan

2.3a 6/1/20

M RPM-HT HL7 Functions Overview

11.9 3/4/21

N Cerner CareAware RPM Specifications

9/09/2021

O ATC Submission Process 4.0 9/28/20

P CCOW Overview 2.1 6/30/11

Q Final Task Order and Invoice Processes

NA

R RPM-HT Invoice Processing Business Rules

NA

S RMA Tracking File Processes NA T RMA Form NA

Index i 37C79121R0008

U RPM HT Product Detail Form

NA – excel sheet

V Patient Census Reporting 4.0 9/08/2021

W IHTA User Manual QIR Reports

6.0 9/2020

X Design Worksheet – Monitoring

NA

Y Signed Performance Monitoring Requirements &

ATO

9/12/19 - MFR

Z Assessment, Authorization & Continuous Monitoring of VA Information Systems

2/3/14

AA Definitions NA

BB QASP 1.0

CC Past Performance

Questionnaire

NA

DD Proposal Adequacy Checklist NA EE Small Business Participation

Subcontracting Plan

NA

FF Deliverables and Submittals Table

NA

Attachment A

Topology Creation, Modification and Maintenance Standard Operating Procedure (SOP) December 10, 2020 | Version 1.0

Revision History Date Version Description Author

December 10, 2020 1.0 Initial Version Katherine Vollmer

Table of Contents Revision History

Topology Creation, Modification and Maintenance SOP

Introduction

Context

Topology Creation

Topology Modification / Maintenance

Exceptions

APPENDIX A – EXAMPLES – Generic Topology Components

APPENDIX B – EXAMPLES – Small System Topology

APPENDIX C – EXAMPLES – Medium System Topology

APPENDIX D – EXAMPLES – Large System Topology

Topology Creation, Modification and Maintenance

SOP

Introduction The Topology / Architecture Diagram provides an architectural and logical view of a system/application/interface. The diagram contains information on Accreditation Boundary, External Connections, Servers, Ports, Protocols, and Interconnections.

Context Based upon requirements, the following list has been created to establish the bare minimum requirements for a successful topology:

• Identify the accreditation boundary.

• Identify all environments (Dev, Pre-Production, Production) currently within the accreditation boundary.

o Include environments within the legend.

• Interconnections, ports, protocols, and services need to be defined.

• A legend for the topology diagram should be included.

o Include all icons and color schemes.

o Depict the accreditation boundary.

• All items within the Hardware (HW) and Software (SW) lists must be within the accreditation boundary.

o The opposite is exact, as well. All items within the accreditation boundary must be in the Hardware and Software lists.

• All servers must have a hostname or IP address listed.

• A connection to EHR (electronic health must be identified.

o Per guidance, a label of “Proposed EHR Connection” may be applied to this connection.

Topology Creation

1. Prior to the creation of a topology / architecture diagram, the HW/SW list must be populated with a bare minimum of information.

a. This list must include the following columns, fully populated: Component Type, Machine Name, IP Address, and Location.

• The Location column can also be utilized to designate the environment in which the system components reside, i.e. Production, Pre-Production, Development, etc.

b. The following columns are not currently required, but may assist further in creation:

Virtual Asset, and OS/iOS/FW Version.

c. The remaining columns are not required for a successful topology.

2. Once the essential information is obtained, the person creating the topology must discuss the current architecture of the system/application/interface with persons who have specialist knowledge of said system/interface/application. This includes System Stewards, System Owners, ISSOs, or SMEs.

a. Usually, the persons identified above can provide a base diagram or image for the topology.

• If this is not available, the creator must obtain sufficient detail to be able to create the diagram.

b. Essential details for the diagram should include the following:

• Boundaries o ATO boundaries, Locational Boundaries

• Interconnections o Both for devices within and outside of the ATO boundary

• Functional Groupings

• External Connections o All connections, including EHR

• Network Devices o Both for devices within and outside of the ATO boundary

• Users/Consumers for the system

3. After the essential information has been gathered, the topology can be created.

a. There are two main applications that can be utilized to create topologies: Microsoft Visio and Microsoft PowerPoint

4. When creating a topology, always create from left to right, as this is the direction that readers will examine/process your diagram.

5. Each topology can be broken down into constituent components:

a. Users / Customer

• Start the topology with your users / consumers on the left side of the diagram.

• This should include a sample of all the types of potential users of the application, such as:

o Personnel, Clients, Laptops, Workstations, Sites

b. Legend

• This section must include every icon, line, boundary and device.

c. Network / WAN

• This section typically will be depicted as a cloud icon, representing the VA WAN or Commercial Internet, as applicable.

d. Network Devices

• This section includes your Firewalls, Site-to-Site VPNs, Switches and/or Load Balancers, as applicable.

e. External Connections

• This should be a depiction of all the external connections, including EHR.

• These connections typically traverse a firewall or VPN and should be depicted as such.

f. Clearly Defined Boundaries

• Each boundary within the diagram should be clearly labeled and identifiable.

• In cases of cloud computing, it is helpful to have several boundaries depicted, including the Cloud Service Provider (CSP), if applicable, or Internet Service Provider (ISP), the system/application/interface, and the various Virtual Private Cloud (VPC) instances (if applicable).

• The ATO or Accreditation Boundary must be clearly labeled and identified. A typical color for this boundary is red.

g. Functional Groupings

• When depicting system components, it is helpful to group said components based upon functionality, such as “Application Servers” or “Database Servers”. This aids the reviewer in identifying the various components of the system and comparing them to the provided HW/SW list. In addition, functional groupings allow for clean diagrams and clear interconnections.

h. Hardware Depiction / Listings

• When depicting the hardware components of a system, it is not necessary to have one icon per item within the HW/SW list. If there are less than 30 servers within the boundary, then a one to one depiction can be utilized. Anything above 30 servers should either utilize a table or an embedded spreadsheet to identify all servers within the boundary.

o NOTE: Embedded spreadsheets do not transfer over when the Visio document is converted to PDF.

• There needs to be a one to one matching for all servers within the HW/SW list and the topology. This can either be via machine name or IP address, however the creator needs to ensure that the entered data matches the HW/SW list.

• When labeling the depicted hardware, it is helpful to identify the OS/iOS/FW Version utilized by that specific component.

i. Interconnections

• All communication channels between system components must be depicted.

• All interconnections must depict directionality, i.e. arrows indicating the direction of the data flow.

• Ports and protocols for the intra component communications must be listed.

j. Title / Time Stamp

• The diagram must have a clear title, listing the following information: system name, location and the date last updated.

o The location listing is situational, based upon what is being depicted.

• Every time that the diagram is updated, the date last updated must be changed to reflect the update.

k. Notes

• Any additional information that would be helpful to reviewers should be included in notes.

• The notes should be highlighted and clearly visible.

l. For examples of each component, please see Appendix A.

6. Once all of the components have been depicted, the diagram should be inspected and reviewed to ensure that there is a logical depiction of data flow.

a. I.e. there must be clear direction to your interconnections and a reviewer must be able to trace dataflow from a user to the application or from the application to the external connections.

Topology Modification / Maintenance

1. After the initial creation of the topology, all further actions fall under modifications.

Exceptions Due to the nature of VA systems, there will be exceptions to the given rules for topology submissions. The following are the currently recorded exceptions:

508 Compliancy – Color Blindness Per Section 508 of the Rehabilitation Act of 1973: “Section 508 requires that when Federal agencies develop, procure, maintain, or use electronic and information technology, Federal employees with disabilities have access to and use of information and data that is comparable to the access and use by Federal employees who are not individuals with disabilities, unless an undue burden would be imposed on the agency. Section 508 also requires that individuals with disabilities, who are members of the public seeking information or services from a Federal agency, have access to and use of information and data that is comparable to that provided to the public who are not individuals with disabilities, unless an undue burden would be imposed on the agency.”

In order to meet the standards of Section 508, certain changes must be made to the topology:

• All colors must be changed to high contrast color combinations. The four most common combinations are as follows:

o Green text on black backgrounds o Yellow text on black backgrounds o White text on black backgrounds o Black text on white backgrounds

• Once a color combination has been chosen, it must be implemented throughout the diagram.

• The legend for the diagram must be as detailed and descriptive as possible.

• Alternate Image Text must be utilized wherever possible.

• If a PDF is being provided, please utilize the accessibility tools provided with the Adobe

Acrobat Pro suite. This will allow for an accessibility report to be created, which will guide the user through making their diagram as 508 compliant as possible.

o If a report is utilized, please ensure that it is attached to the PDF when submitting for review.

For further information on Section 508 compliant, please utilize the following resources:

• The United States Access Board

• GSA Section 508 Government-wide IT Accessibility Program

• Adobe Acrobat Accessibility Checker

There are further resources that can be accessed with a quick search.

APPENDIX A – EXAMPLES – Generic Topology Components

Detailed Architecture Diagram/Topology:

Users / Consumers:

https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-section-508-standards/section-508-standards https://www.section508.gov/ https://helpx.adobe.com/acrobat/using/create-verify-pdf-accessibility.html

Legend:

Network / WAN:

Network Devices:

External Connections:

Clearly Defined Boundaries:

Functional Groupings:

Hardware Depiction / Listing:

Interconnections:

Title / Timestamp:

Notes:

APPENDIX B – EXAMPLES – Small System Topology

APPENDIX C – EXAMPLES – Medium System Topology

APPENDIX D – EXAMPLES – Large System Topology

Attachment B

Configuration Management Plan

<Information System Name> <Information System Name in RiskVision (GRC)>

<Month><Year>

Version <#.#>

Department of Veterans Affairs

<System Owner/Responsible Office> <System Owner Title>

This template contains a paragraph style called Instructional Text. Text using this paragraph style is designed to assist the reader in completing the document. Text in paragraphs added after this help text is automatically set to the appropriate body text level. For best results and to maintain formatting consistency, use the provided paragraph styles. Delete all instructional text before publishing or distributing the document Revision History.

This template conforms to the latest Section 508 guidelines. The user of the template is responsible to maintain Section 508 conformance for any artifact created from this template.

Configuration Management Plan i <Month> <Year>

Notes to the Author [This document is a template of a Configuration Management Plan document for an Information System. The template includes instructions to the author, boilerplate text, and fields that should be replaced with the values specific to the Information System.

• Italicized text enclosed in square brackets ([text]) provides instructions to the document author, or describes the intent, assumptions and context for content included in this document.

• Italicized text enclosed in angle brackets (<text>) indicates a field that should be replaced with information specific to a particular Information System.

• Text and tables in black are provided as boilerplate examples of wording and formats that may be used or modified as appropriate to a specific Information System. These are offered only as suggestions to assist in developing Information System documents;

they are not mandatory formats.

When using this template, the following steps are recommended:

1. Replace all text enclosed in angle brackets (e.g., <Information System Name>) with the correct field document values. These angle brackets appear in both the body of the document and in headers and footers.

2. Modify boilerplate text as appropriate for the specific Information System.

3. To add any new sections to the document, ensure that the appropriate header and body text styles are maintained. Styles used for the Section Headings are Heading 1, Heading 2 and Heading 3. Style used for boilerplate text is Body Text.

4. To update the Table of Contents, right-click on it and select “Update field” and choose the option - “Update entire table”. Check to ensure that the contents accurately reflect the document headings.

5. Before submission of the first draft of this document, delete this instruction section “Notes to the Author” and all instructions to the author throughout the entire document.

Configuration Management Plan ii <Month> <Year>

Version History [Use the table below to provide the version number, the author implementing the version, the date of the version, the name of the person approving the version, the date that particular version was approved, and a brief description of the reason for creating the revised version.]

[Be sure to copy the version history from your previous configuration management plan document]

Place latest revisions at top of table.

The Revision History pertains only to changes in the content of the document or any updates made after distribution. It does not apply to the formatting of the template.

Remove blank rows.

Configuration Management Plan iii <Month> <Year>

1. Executive Summary

2. Introduction

2.1. Purpose of The Configuration Management Plan

2.2. Scope of the Configuration Management Plan

2.3. Structure of the Configuration Management Plan

3. Configuration Management Activities

3.1 Roles and Responsibilities

3.2 Communication

3.3 System Configuration Baseline

3.4 ConfigurATION Control Process (CCP) ............. Error! Bookmark not defined.

3.5 Configuration Management Resources

Appendix A: Configuration Management Plan Approval

Appendix B: References

Appendix C: Key Terms

Appendix D: Suggested Configuration Items Data Elements

Appendix E: [Facility] Current Configuration Baseline Report

Appendix F: Configuration Items (CI) Showing System Boundaries

Appendix G: Change Order Approval Checklist

Appendix H: Change Order Implementation Plan Template

Appendix I: Business Case Justification

Appendix J: Change Management Back-Out Plan Template

Configuration Management Plan 1 <Month> <Year>

1. Executive Summary [Provide a high-level synopsis of the contents included in the Configuration Management Plan, acquired from the System Security Plan (SSP). Maintain a level consistency between documents that are related to the same system.] The Configuration Management Plan (CMP) is a security artifact that supports identification, control, and auditing of Office of Information and Technology (OIT) assets in an orderly and controlled manner. This artifact will also support the Authorizing Official with the information needed to maintain a robust continuous readiness and monitoring posture as the system moves through the lifecycle development process.

2. Introduction

2.1 Purpose of the Configuration Management Plan

[Provide the purpose of the Configuration Management Plan.] The overall objective of a CMP is to identify Configuration Management (CM) roles and responsibilities, resources, and formal processes and procedures to ensure that all proposed changes to a General Support System (GSS) / Major Application (MA) are evaluated and approved before implementation. This also includes the process used for controlling implementation, evaluation, and auditing of the CM processes and Configuration Items (CIs) to include maintaining a current baseline configuration of the system under Configuration Management Control. This CMP contains all the information pertinent to the <RiskVision (GRC) Name> system.

2.2 Scope of the Configuration Management Plan

The <RiskVision GRC Name> CMP document, along with the corresponding CM Standard Operating Procedure (SOP), defines the Information System’s structure and methods for:

• Identifying, defining, and base-lining CIs o Creating CI Records o Identifying relationships

• Controlling modifications and releases of CIs

• Reporting and recording status of CIs and any requested modifications

• Ensuring completeness, consistency, and correctness of CIs

• Controlling storage, handling, and delivery of the CIs

2.3 Structure of the Configuration Management Plan

[Summarize the structure of the Configuration Management Plan.] The intended audience of the CMP is system owners, Organizational Service Lines and divisions, facility chief information officers, system administrators, information security officers

Configuration Management Plan 2 <Month> <Year> and information owners, and Office of Information and Technology (OIT) staff within these identified areas responsible for the day-to-day maintenance of the configuration items.

This CMP, in conjunction with the Office of Information and Technology (OIT) Configuration and Change Management Process Documents, and Service, Delivery and Engineering (SDE) Change Management Policy and Standard Operating Procedures, identifies configuration management and change management roles and responsibilities and system relationships. In addition, the scope includes the automated tools and processes used to manage the information system baseline configuration.

3 Configuration Management Activities

3.1 Roles and Responsibilities

Instructions: Identify key personnel responsible for CM. Describe their responsibilities for activities such as configuration identification, configuration control, configuration auditing/reporting, etc. for software, hardware, and documentation. If appropriate, include an organizational chart depicting the independent reporting structure for the CM organization.

Include the distribution list for the CMP.

Table 1: Roles and Responsibilities

Name Role Responsibility

3.2 Communication

[Identify the methods used to share information regarding CM (e.g., upgrades, application changes, technical notices, and version control). This section should address items such as who has access to the information and how, when, and what type of information is shared.] Requests for Change (RFC)/Change Orders are entered into the appropriate Change Management System (VA) for review, approval, and implementation by the appropriate Servicing Divisions.

Change Control and Advisory Board reviews are required for changes that impose downtime for the system or service or pose a risk or affect multiple facilities or services. It is the responsibility of the implementation team to notify potentially affected customers and personnel required to provide support, e.g.,Organizational Servicing Divisions, Network Chief Information Officer (NCIO), Facility Chief Information Officer (FCIO), etc.

Configuration Management Plan 3 <Month> <Year>

3.3 System Configuration Baseline

Instructions: Describe the process for identifying and documenting the functional and physical characteristics of items that are to be placed under configuration control. Identify how CIs will be selected and the types of configuration documentation required for each CI. Also, identify how configuration identification information will be maintained and made readily available to all VA decision makers.

3.4 Configuration Control Process (CCP)

[Define the process that is required to ensure all changes to the GSS/MA are properly requested, evaluated, and authorized. The CCP should provide detailed, step-by-step procedures for establishing, processing, tracking, and documenting changes, including:] OIT and SDE have established process and procedures that dictate the configuration change control for all hardware and software configuration items. A VA tool is used for requesting, approving, implementing, monitoring, and tracking, auditing and closing change orders affecting configuration items under change and configuration control.

• Step 1: Establish System Configuration Baselines

• Step 2: Identify changes and complete Change Request

• Step 3: Submit Change Request

• Step 4: Evaluate Change Request

• Step 5: Perform Security and Operational Impact Analysis

• Step 6: Approve, Disapprove, Defer, or Refer Change Request

• Step 7: Schedule Approved Change

• Step 8: Release Approved Change

• Step 9: Implement Approved Change

• Step 10: Verify Implemented changes are successful and did not introduce additional issues/incidents into the environment.

• Step 11: Perform Configuration Status Accounting

• Step 12: Conduct Configuration Verification and Audit

See appendix B for OIT Configuration Management Process and SDE Change Management Standard Operation Procedure

3.5 Configuration Management Resources

[Describe facilities and tools used for CM activities.] The Change Management Systems (VA) is the automated mechanism that is used for tracking of proposed changes to configuration items. Change orders are entered into the system and work orders assigned to the appropriate groups for review, approval, implementation, configuration status accounting and configuration verification. Changes are time stamped to provide a timeline and reviewed per local process and procedures to ensure that changes are processed correctly and

Configuration Management Plan 4 <Month> <Year> are implemented to meet established requirements. Changes are not implemented without approval per OIT and SDE Change Management Policy and procedures.

Each area of the organization managing changes has a Change and Configuration Management Division that is responsible of ensuring that appropriate control is put in place to manage the configuration items per VA Handbook 6500 Configuration Management controls.

Configuration Management Plan 5 <Month> <Year>

APPENDIX A: CONFIGURATION MANAGEMENT PLAN APPROVAL

The undersigned acknowledge that they have reviewed the <Information System Name> Configuration Management Plan and agree with the information presented within this document. Changes to this Configuration Management Plan will be coordinated with, and approved by, the undersigned, or their designated representatives.

[List the individuals whose signatures are desired. Examples of such individuals are System Owner, Data Owner, Information System Manager, Security, Change and Configuration Manager(s) (if identified), and any appropriate stakeholders. Add additional lines for signature as necessary.]

Signature: Date:

Print Name:

Title:

Role:

Signature: Date:

Title:

Role:

Signature: Date:

Print Name:

Title:

Role:

Configuration Management Plan 6 <Month> <Year>

Appendix B: References [Insert the name, version number, description, and physical location of any documents referenced in this document. Add rows to the table as necessary.] The following table summarizes the documents referenced in this document.

Document Name

Description Location

<Document Name and Version Number>

<Document description>

<URL or Network path where document is located>

VA Directive

Managing Information Security Risk: VA Information Security Program http://www.va.gov/vapubs/landing2_relatedlinks.cfm

VA

Handbook

Risk Management Framework for VA Information Systems – Tier 3: VA Information Security Program http://www.va.gov/vapubs/landing2_relatedlinks.cfm

OIT

Configuration Management Process

OIT

Configuration Management ProPath defined process and supporting document https://vaww.sde.portal.va.gov/ sites/fo/committees/ccb/CMDB/ Definitive%20Document%20Storage/ oit_configuration_management_process_document.pdf

OIT Change Management Process Document

OIT Change Management ProPath defined process and supporting document https://vaww.sde.portal.va.gov/ sites/fo/committees/ccb/CMDB/ Definitive%20Document%20Storage/ oit_change_management_process_document.pdf http://www.va.gov/vapubs/landing2_relatedlinks.cfm http://www.va.gov/vapubs/landing2_relatedlinks.cfm https://vaww.sde.portal.va.gov/sites/fo/committees/ccb/CMDB/Definitive%20Document%20Storage/oit_configuration_management_process_document.pdf https://vaww.sde.portal.va.gov/sites/fo/committees/ccb/CMDB/Definitive%20Document%20Storage/oit_configuration_management_process_document.pdf https://vaww.sde.portal.va.gov/sites/fo/committees/ccb/CMDB/Definitive%20Document%20Storage/oit_configuration_management_process_document.pdf https://vaww.sde.portal.va.gov/sites/fo/committees/ccb/CMDB/Definitive%20Document%20Storage/oit_configuration_management_process_document.pdf https://vaww.sde.portal.va.gov/sites/fo/committees/ccb/CMDB/Definitive%20Document%20Storage/oit_configuration_management_process_document.pdf https://vaww.sde.portal.va.gov/sites/fo/committees/ccb/CMDB/Definitive%20Document%20Storage/oit_configuration_management_process_document.pdf https://vaww.sde.portal.va.gov/sites/fo/committees/ccb/CMDB/Definitive%20Document%20Storage/oit_configuration_management_process_document.pdf https://vaww.sde.portal.va.gov/sites/fo/committees/ccb/CMDB/Definitive%20Document%20Storage/oit_configuration_management_process_document.pdf

Configuration Management Plan 7 <Month> <Year>

Document Name

Description Location

SDE Change Management

SOP

SDE Change Management Standard Operation Procedure https://vaww.sde.portal.va.gov/ sites/fo/committees/ccb/CMDB/ Definitive%20Document%20Storage/ National%20ChM%20Process%20SOP.pdf

Master Test Plan

Master Test Plan Template http://vaww.oed.wss.va.gov/process/Library/master_test_plan_template.docx https://vaww.sde.portal.va.gov/sites/fo/committees/ccb/CMDB/Definitive%20Document%20Storage/oit_configuration_management_process_document.pdf https://vaww.sde.portal.va.gov/sites/fo/committees/ccb/CMDB/Definitive%20Document%20Storage/oit_configuration_management_process_document.pdf https://vaww.sde.portal.va.gov/sites/fo/committees/ccb/CMDB/Definitive%20Document%20Storage/oit_configuration_management_process_document.pdf https://vaww.sde.portal.va.gov/sites/fo/committees/ccb/CMDB/Definitive%20Document%20Storage/oit_configuration_management_process_document.pdf http://vaww.oed.wss.va.gov/process/Library/master_test_plan_template.docx

Configuration Management Plan 8 <Month> <Year>

Appendix C: Key Terms The following table provides definitions and explanations for terms and acronyms relevant to the content presented within this document.

Term Definition [Insert Term] <Provide definition of term and acronyms used in this document.>

ACL Access Control List

AO Authorizing Official

CAB Change Advisory Board

CCP Configuration Control Process

CI Configuration Item

CM Configuration Management

ChM Change Management

CMDB Configuration Management Database

CMP Configuration Management Plan

CMS Change Management System

COR Contracting Officer Representative

CP Contingency Plan

CTO Chief Technology Officer

DRP Disaster Recovery Plan

ESE Enterprise System Engineering

FCIO Facility, Chief Information Officer

FDCC Federal Desktop Core Configuration

GPO Group Policy Object

GRC RiskVision Tool

GSS General Support System

ISCPA Information System Contingency Plan Assessment

IT Information Technology

OIT Office of Information & Technology

LAN Local Area Network

MA Major Application

MDIA Medical Device Isolation Architecture

NCIO Network, Chief Information Officer

RCCB Region Change Control Board

Configuration Management Plan 9 <Month> <Year>

Term Definition RFC Request for Change

SCCM System Center Configuration Manager

SDE Service Delivery and Engineering

SLM Service Line Manager

SOP Standard Operating Procedure

SSP System Security Plan

TRM Technical Reference Model

VA Veterans Affairs

VISN Veterans Integrated Service Network

WAN Wide Area Network

WLAN Wireless Local Area Network

Configuration Management Plan 10 <Month> <Year>

Appendix D: Suggested Configuration Items Data Elements

Suggested standard data elements (Data Type and CI Type) and what type of data would be collected and how it would be used.

Field Name Data Type

CI Type Description

Resource Name Indexed Text

Hardware / Software / Service / Document

A unique name of the Configuration Item (CI). A name that represents the Resource and is easy to identify what it is; a key search field within the Configuration Management Database (CMDB).

DNS Name Indexed Text

Hardware The name of the CI as identified within your Domain Name Service (DNS); this helps with association of services or servers to a CI.

Status Lookup Table

Hardware / Software / Service / Document

The current status of the CI. For example: when first added to the CMDB, the CI may be in a status of Registered, then later it may be Accepted. This identifies how the record moves through the status/lifecycle; if a change is being performed on the CI the status would be changed to Change in Progress, thus identifying CI’s that are currently undergoing some form of a change.

Description Free Text Multiple Lines

Hardware / Software / Service / Document

A short description that will provide additional feedback to the end user when looking up the CI.

CI Type Lookup Table

Hardware / Software / Service / Document

This is the type that the CI belongs to. See list of suggested family types.

Asset Class Lookup Table

Hardware / Software / Service / Document

This is the classification of the configuration item;

it is related to the family, but is a more specific classification of an asset. This is the sub-type that the CI belongs to; it is used to group common types on configuration items. An example would be “Laptop”; the “Laptop” Class is within the hardware Type.

Comments Free Text Multiple Lines

Hardware / Software / Service / Document

Comments regarding the specific CI; notes that need to be part of the record history but are not within the Description of the CI.

COR Contact Table Lookup

Hardware / Software / Service

Contracting Officer Representative (COR) associated with this particular purchase or CI.

Configuration Management Plan 11 <Month> <Year>

Field Name Data Type

CI Type Description

Customer Name Contact Table Lookup

Hardware / Software / Service / Document

Name of the Customer point of contact for issues with the CI. This person or group is the primary focus point when issues or changes are related to the CI.

Customer Organization

Lookup Table

Hardware / Software / Service / Document

Name of the Organization that the customer belongs to. Provides reporting information about what CI’s are associated to a specific organization.

Deployed Date Date Hardware / Software / Service / Document

The date that a service, system, etc. was deployed to the production environment.

Financial Reference

Free Text Hardware / Software

A Purchase Order that was used to obtain the hardware or software. It is useful when looking up other information that may be found in related databases like the Asset Management system.

Function Lookup Table

Hardware The function or purpose that the hardware Configuration Item serves.

Host Name Free Text Hardware In some cases, like UNIX, there is a purpose to identify the host name; this is on the same as DNS Name.

License Count Numeric Software A number of copies that a particular license allows the owner to distribute. It can be used to determine if additional software licenses are needed or if there are too many licenses unused.

Type of Licenses

Lookup Table

Software The type of license that has been procured, perpetual or recurring.

License Key Maintained By

Contact table Lookup

Software Who maintains the Software License Key that is used to install the software?

Lifecycle Date Date Hardware / Software / Service

This is a date in the future derived from the install date and IT equipment life expectancy.

Location Lookup Table

Hardware / Software / Service / Document

The location where this particular CI is hosted or installed. More specific location fields may be needed, such as room, floor, and rack as part of the physical location.

Maintenance Organization

Lookup Table

Hardware / Software / Service

Name of the Organization that has Maintenance responsibility over the CI; normally found within the Operations and Maintenance (O&M) Plan.

Configuration Management Plan 12 <Month> <Year>

CI Type Description

Maintenance Vendor

Lookup Table

Hardware / Software / Service

The vendor that would support the Maintenance Organization with a Warranty or other type of maintenance agreement.

Manufacturer Lookup Table

Hardware / Software

Manufacturer of the CI being entered into the CMDB. Name used for reporting maintenance contracts or other data related to a specific manufacturer.

Model Lookup Table

Hardware / Software

The manufacturer’s model name for the device.

Relates to the manufacturer; used for reporting and for maintenance contracts.

Version Number Free Text Software / Document

Version Number of software or documents. This provides a baseline as to what version of software is installed/authorized in production or the version of a document that was approved and published. No version changes unless there is a change process for it.

Maintenance Window

Free Text Hardware / Software / Service

Maintenance windows are established based on Service Level Agreements (SLA’s) or other agreements for specific services that are available to the end user. The Maintenance windows that are associated with the CI’s should clearly state if they are recurring maintenance windows, the days of the week that they are available, and the hours of the day that they can be used. Example: Recurring - Monday – Friday 7 to 11 PM Contact (name or role of the person that should be contacted to validate/verify the maintenance window).

Operating System

Look Up Table

Hardware / Software

Identifies the Operating System (OS) running on the server, virtual machine, laptops or workstations. It is used for patching, SA assignment, reporting purposes, licensing, etc.

NOTE: If this information is available from other tools that can report this information and is not needed as part of internal reporting or linked to other fields that are not part of the external data source, then this field could be left out.

Published Date Date Document The date that a document was published for general consumption.

Configuration Management Plan 13 <Month> <Year>

CI Type Description

Region Lookup Table

Hardware / Software / Service / Document

OIT is broken out into different regional areas.

Most have their own processes and procedures or have equipment and software that is regionalized. If the CMDB holds cross-regional CI’s these should be identified for reporting purposes; otherwise, the Organizational field should provide the needed feedback.

Relationships Lookup Table

Hardware / Software / Service / Document

Field is a one-to-many relationship used to identify a relationship between 2 or more CI’s and the type of relationship that the CI has. This relationship could be with contacts, other hardware, software, services or document CI’s.

An example of types of relationships are listed below:

Changes Approved By Connects To Is Documented By Runs/Runs On

Renewal Date Date Hardware / Software

A renewal date is used to establish when a particular CI’s maintenance agreement will expire and would require renewal to continue with the service.

Cost of Maintenance Agreement

Numbers Hardware / Software

Recurring cost of maintenance agreements purchased under the contract.

Responsible Organization

Lookup Table

Hardware / Software / Service / Document

The Organization that has responsibility over the CI. It may be the same as maintenance or customer organization or a different one.

Responsible Owner

Contact Lookup Table

Hardware / Software / Service / Document

A primary point of contact who has been identified as the POC for the Responsible Organization.

Responsible Vendor

Lookup Table

Hardware / Software

The Responsible Vendor for a particular CI may be the same as Maintenance Vendor or may be a different vendor if maintenance is sub-contracted out by the Primary Responsible Vendor.

Secondary Contact

Contact Lookup Table

Hardware / Software / Service / Document

This would be an alternate Point of Contact that could be contacted in the absence of the Primary

POC,

Configuration Management Plan 14 <Month> <Year>

CI Type Description

Serial Number Alpha- Numeric Free Text

Hardware Serial Numbers are unique identification elements that are directly related to asset management; but by including it within your CMDB you could link to other databases that track their CI’s by Serial Number.

Service Line Lookup Table

Hardware / Software / Service / Document

Support is broken down by Service Lines within OIT Field Operations, providing a Service Line associated to the CI would expedite maintenance issues and provide reporting capabilities on the type and number of CI’s being maintained by a particular service line.

Service Line Team/Division

Lookup Table

Hardware / Software / Service / Document

As Service Lines are stood up, so are the Service Line Teams/Divisions that support the service line and have a more defined scope of their responsibilities. Capturing this type of information would provide you with the same information as Service Line would but allow you to break it down by the Service Line Team Division.

Source Supplier Lookup Table

Hardware Used for hardware support, this is the vendor that purchased the equipment from the manufacturer.

It is received obtained from the Purchase Order Contract.

Created By System Contact Field

Hardware / Software / Service / Document

This is an audit field; it captures the name of the person that created the record. This should be a system field and captured based on who was logged in during the creation of the record.

Created Date System Date Field

Hardware / Software / Service / Document

Initial date of creation of the Configuration Item Record.

Modified By System Contact Field

Hardware / Software / Service / Document

This is an audit field; the person who last edited the record would be listed. This should be a system field and captured based on who was logged in during the modification.

Modified Date System Date Field

Hardware / Software / Service / Document

Date the Configuration Item Record was last modified.

Configuration Management Plan 15 <Month> <Year>

Appendix E: [Facility] Current Configuration Baseline Report

The following table details the Hardware/Software and Services associated with the system under this CMP.

Facility Current Configuration Baseline

Configuration Management Plan 16 <Month> <Year>

Appendix F: Configuration Items (CI) Showing System Boundaries Example of diagram of related configuration items within their boundaries.

System Bounderies template.vsd

Configuration Management Plan 17 <Month> <Year>

Appendix G: Change Order Approval Checklist

Reviewer and Approver must be different (the person putting together the plan, and the person approving the plan)

Correct location entered?

Change Order description contains required information

What is being done?

The business case for doing it.

What is the impact of the change (what services will be impacted and what will the impact most likely be)?

What else may be impacted?

What will occur if we don’t do the change?

The implementation plan should be attached, never be pasted, into the description.

Were the customers/stakeholders notified as per the Change Advisory Board (CAB) process?

CAB notification in the ticket.

Facility OIT response or ignore entered as a log comment.

Is the implementation plan attached?

Is the Notification and Escalation section complete?

Does the implementation plan provide sufficient detail so that a peer who is unfamiliar with the particular facility where the implementation is taking place could execute the plan?

Does the implementation plan include a test plan that contains checkpoints for verification, coordination, or implementing back-out?

Are verification steps (Test Plan) included?

Do the verification steps ensure the customers are functioning and not just the item modified is working?

Is the back-out plan attached?

Is the notification plan included?

Are verification steps included?

Do the verification steps ensure the customers are functioning, the services impacted are operational, and not just the item modified is working?

Is the need by date realistic?

Is there an implementation date/time prior to the need by date?

If everything is accurate and all documentation attached, change Status to Approved and/or escalate to next level CCB if this is a significant change/downtime required.

Change Order Approval Checklist.do

Configuration Management Plan 18 <Month> <Year>

Appendix H: Change Order Implementation Plan

Local facility Notification and Escalation Contacts Name/Role Business After-hours John Doe, FCIO 333-345-6789 333-987-6543

VISN/Service Line Notification and Escalation Contacts Name/Role Business After-hours

Any pre-implementation work that will be required Enter required pre-implementation work here

Step-by-step guidance for what needs to be done including time estimates, escalation and coordination points Enter step-by-step guidance here

Identification of areas that might cause problems Enter Identification of areas that might cause problems here

Configuration Management Plan 19 <Month> <Year>

Identification of roll-back points and/or criteria for initiating the Back-out plan Enter Identification of roll-back points and/or criteria for initiating the Back-out plan here

Test/validation steps for the verification phase – include validation that customers are functioning and not just the item modified (See Master Test Plan Template) Enter Test/validation steps for the verification phase

Change Order Implementation Plan T

Configuration Management Plan 20 <Month> <Year>

Appendix I: Business Case Justification

1. Please provide a detailed description of this change.

2. List the requirements needed for the change (i.e., servers, switches, software, etc.).

3. Describe the effect the change may have upon the end user, business operation, and infrastructure, if known.

4. Describe the impact on and the availability to other services that run on the same infrastructure (or on software development projects).

5. Describe the effect of not implementing the change.

6. Estimate the IT, business, and other resources required to implement the change, including the likely costs, the number and availability of people required, the elapsed time, and any new infrastructure elements required.

7. Estimate any additional ongoing resources required if the change is implemented.

8. Document downtime procedures.

Document communication procedures (i.e., who needs to be notified in the event of scheduled/unscheduled downtime and how to notify this person).

Business Case Justification.docx

Configuration Management Plan 21 <Month> <Year>

Appendix J: Change Management Back-Out Plan

Change Order Affected Systems

Estimated time-frames for restoring service Enter estimates here

Any pre-implementation work that will be required Enter pre-implementation work here

Step-by-step guidance to restore service to the pre-change state Enter step-by-step guidance here

Chagne Management Back Plan Template.d

Configuration Management Plan 22 <Month> <Year>

Template Revision History

June 2015 1.1 Formatted to documentation standards, edited for Section 508 conformance, and remediated with Common Look Office tool

Process Management

March 2015 1.0 Initial Version HHS EPLC Team

Place latest revisions at top of table.

The Template Revision History pertains only to the format of the template. It does not apply to the content of the document or any changes or updates to the content of the document after distribution.

The Template Revision History can be removed at the discretion of the author of the document.

Remove blank rows.

Authorization Requirements Standard Operating Procedures Version 1.18

December 11, 2020

OFFICE OF

INFORMATION

SECURITY

Attachment C

O F F I C E O F I N F O R M A T I O N S E C U R I T Y

1 Purpose

2 Scope

3 Authorization Prerequisites and Registration

3.1 Application Prerequisites

3.2 Application Registration

3.3 System Boundary Guidance

4 Assessment and Authorization Requirements

4.1 Application hosted On-Premises/VA Network

4.1.1 Security Documentation

4.1.1.1 Configuration Management Plan (CMP)

4.1.1.2 Disaster Recovery Plan (DRP)

4.1.1.3 Incident Response Plan (IRP)

4.1.1.4 Information System Contingency Plan (ISCP)

4.1.1.5 Interconnection Security Agreement (ISA)/Memorandum of Understanding

(MOU)

4.1.1.6 Minor Application Self-Assessment

4.1.1.7 Privacy Threshold Analysis (PTA)/Privacy Impact Assessment (PIA)

4.1.1.8 Risk Assessment Report (RAR)

4.1.1.9 System Security Plan (SSP)

4.1.2 Technical Scans/Testing Requirements

4.1.2.1 Nessus Scan

4.1.2.2 Database Scan

4.1.2.3 Penetration Test/Application Assessment

4.1.2.4 Application Security Testing

4.1.2.5 Application Threat Modeling

4.1.2.6 Security Configuration Compliance Data (SCCD)

4.1.2.7 Control Assessment

4.2 Application hosted in Managed Service

4.2.1 Security Documentation

4.2.1.1 Configuration Management Plan (CMP)

4.2.1.2 Disaster Recovery Plan (DRP)

4.2.1.3 Incident Response Plan (IRP)

4.2.1.4 Information System Contingency Plan (ISCP)

4.2.1.5 Interconnection Security Agreement (ISA)/Memorandum of Understanding

(MOU)

4.2.1.6 Privacy Threshold Analysis (PTA)/Privacy Impact Assessment (PIA)

4.2.1.7 Risk Assessment Report (RAR)

4.2.1.8 System Security Plan (SSP)

4.2.2 Technical Scans/Testing Requirements

4.2.2.1 Nessus Scan

4.2.2.2 Database Scan

4.2.2.3 Penetration Test/Application Assessment

4.2.2.4 Application Security Testing

4.2.2.5 Application Threat Modeling

4.2.2.6 Security Configuration Compliance Data (SCCD)

4.2.2.7 Control Assessment

4.3 Application hosted in FedRAMP cloud (VAEC)

4.3.1 Security Documentation

4.3.1.1 Configuration Management Plan (CMP)

4.3.1.2 Disaster Recovery Plan (DRP)

4.3.1.3 Incident Response Plan (IRP)

4.3.1.4 Information System Contingency Plan (ISCP)

4.3.1.5 Interconnection Security Agreement (ISA)/Memorandum of Understanding

(MOU)

4.3.1.6 Privacy Threshold Analysis (PTA)/Privacy Impact Assessment (PIA)

4.3.1.7 Risk Assessment Report (RAR)

4.3.1.8 System Security Plan (SSP)

4.3.2 Technical Scans/Testing Requirements

4.3.2.1 Nessus Scan

4.3.2.2 Database Scan

4.3.2.3 Penetration Test/Application Assessment

4.3.2.4 Application Security Testing

4.3.2.5 Application Threat Modeling

4.3.2.6 Security Configuration Compliance Data (SCCD)

4.3.2.7 Control Assessment

4.4 Application hosted in FedRAMP cloud (Non-VAEC)

4.4.1 Security Documentation

4.4.1.1 Configuration Management Plan (CMP)

4.4.1.2 Disaster Recovery Plan (DRP)

4.4.1.3 Incident Response Plan (IRP)

4.4.1.4 Information System Contingency Plan (ISCP)

4.4.1.5 Interconnection Security Agreement (ISA)/Memorandum of Understanding

(MOU)

4.4.1.6 Privacy Threshold Analysis (PTA)/Privacy Impact Assessment (PIA)

4.4.1.7 Risk Assessment Report (RAR)

4.4.1.8 System Security Plan (SSP)

4.4.2 Technical Scans/Testing Requirements

4.4.2.1 Nessus Scan

4.4.2.2 Database Scan

4.4.2.3 Penetration Test/Application Assessment

4.4.2.4 Application Security Testing

4.4.2.5 Application Threat Modeling

4.4.2.6 Security Configuration Compliance Data (SCCD)

4.4.2.7 Control Assessment

4.5 Facility

4.5.1 Security Documentation

4.5.1.1 Configuration Management Plan (CMP)

4.5.1.2 Disaster Recovery Plan (DRP)

4.5.1.3 Incident Response Plan (IRP)

4.5.1.4 Interconnection Security Agreement (ISA)/Memorandum of Understanding

(MOU)

4.5.1.5 Privacy Threshold Analysis (PTA)/Privacy Impact Assessment (PIA)

4.5.1.6 Risk Assessment Report (RAR)

4.5.1.7 System Security Plan (SSP)

4.5.2 Technical Scans/Testing Requirements

4.5.2.1 Nessus Scan

4.5.2.2 Enterprise Discovery Scan (EDS)

4.5.2.3 Security Configuration Compliance Data (SCCD)

4.5.2.4 Control Assessment

4.6 Medical Devices

4.6.1 Security Documentation

4.6.1.1 Interconnection Security Agreement (ISA)/Memorandum of Understanding

(MOU)

4.6.1.2 Privacy Threshold Analysis (PTA)/Privacy Impact Assessment (PIA)

4.6.1.3 Risk Assessment Report (RAR)

4.6.1.4 System Security Plan (SSP)

4.6.2 Technical Scans/Testing Requirements

4.6.2.1 Nessus Scan

4.6.2.2 Control Assessment

4.7 Other Federal Agency (Non-eMASS Reciprocity)

4.8 Platform

4.8.1 Security Documentation

4.8.1.1 Information System Contingency Plan (ISCP)

4.8.1.2 Interconnection Security Agreement (ISA)/Memorandum of Understanding

(MOU)

4.8.1.3 Privacy Threshold Analysis (PTA)/Privacy Impact Assessment (PIA)

4.8.1.4 Risk Assessment Report (RAR)

4.8.1.5 System Security Plan (SSP)

4.8.2 Technical Scans/Testing Requirements

4.8.2.1 Control Assessment

5 Appendix A – Acronyms/Definitions

6 Appendix B – Quick Reference Guide – Security Documentation Requirements

7 Appendix C – Quick Reference Guide – Technical/Testing Requirements

8 Appendix D – Common Control Providers/System of Record (SOR)

8.1.1.1 VA T1SOR

8.1.1.2 IO SOR

8.1.1.3…