Appendix C - EBS CM SIG.pdf

Defense Logistics Agency (DLA)

J62 Configuration Management

SUPPLEMENTAL IMPLEMENTATION GUIDE (SIG)

for

Enterprise Business System (EBS)

Version 8.0

Enterprise Business System Supplemental Implementation Guide

Page | 2 SIG Template, Version 3.3

The effective date of the Supplemental Implementation Guide (SIG) is the date that all required approval signatures have been obtained as indicated below.

Approved By:

Bradley Lantz, Portfolio Manager

EBS, J62E

Defense Logistics Agency

Manikyamohan Pinisetti, PEO Chief Engineer Office of the Chief Engineer, J62L Defense Logistics Agency

Page | 3

DOCUMENT CHANGE/VERSION CONTROL

Date Version Number Description of Change Name of Person Making

Change 7/31/15 1.0 Initial Document Creation Huyen Mai

9/30/15 1.1 Update Kim Pisall

9/9/16 2.0 Update to address new J62 SIG template Kevin Lance

12/15/17 2.1 Update to revised J62 SIG template;

removed EBS ‘L2’ Process references

Elizabeth DiDonato

4/22/19 3.0 Update to revised J62 SIG Template Elizabeth DiDonato

6/1/20 4.0 Updated to reflect changes to the EBS Portfolio Management (PfM) Processes

Elizabeth DiDonato

6/17/21 5.0 Updated to incorporate changes from SIG Template v3.1

Elizabeth DiDonato

3/11/22 6.0 Updated to incorporate J62EC and CCWG changes associated with Change Requests traceability

Elizabeth DiDonato

4/06/23 7.0 Updated to show increased traceability and reporting through Configuration Status Accounts Report (CSAR). Incorporated updates from SIG Template v3.2.

Elizabeth DiDonato

2/2/24 8.0 Updates from annual review and SIG Template v3.3 included.

Elizabeth DiDonato

Page | 4

Table of Contents

INTRODUCTION AND PURPOSE

APPLICATIONS COVERED BY THIS SIG

REFERENCES

ORGANIZATIONAL INFORMATION

FUNCTIONAL STAKEHOLDER FORUMS/BOARDS

CONTRACTOR MANAGEMENT

CONFIGURATION/CHANGE MANAGEMENT TOOLS

CYBER SECURITY

Risk Management Framework (RMF) Vulnerability Identification, Assessment, and Patch Management Security Logging

CONFIGURATION ITEMS (CIs) Baselines Version Control Naming Conventions CM-Related Documentation and Records Interface Management

SOFTWARE DEVELOPMENT LIFECYCLE

CHANGE REQUEST PROCESS

Submission, Authorization, and Identification Change Request Technical Reviews and Approval Change Traceability

EMERGENCY CHANGES

SYSTEM SPECIFICATIONS

SECURITY IMPACT ANALYSIS

TESTING

Test Planning Test Results

ENVIRONMENTS

Access Approval, Control, and Segregation of Duties (SoD) Library Control

RELEASE MANAGEMENT

INCIDENT MANAGEMENT

ACCESS AND CHANGE MONITORING

POST IMPLEMENTATION CHANGE REVIEW

CM VALIDATION, AUDIT, AND REPORTING

Page | 5

INTRODUCTION AND PURPOSE

A Supplemental Implementation Guide (SIG) is a program-level supplement to the Defense Logistics Agency (DLA) Enterprise Configuration Management Plan (ECMP). It also supports DLA’s Cybersecurity policy and is an audit evidentiary item.

This SIG documents the J62 Program Management Office’s (PMO’s) current, lower-level Configuration and Change Management (CM) processes, procedures and information that support but are not defined in the ECMP. It is stored in the Document Automation and Content Services (DACS)-CM repository.

DLA ECMP + PMO SIG = PMO’s CM PLAN

This SIG will be reviewed annually and updated, as needed, to maintain focus on the PMO’s existing procedures and environments. The SIG remains in effect for three years unless the results of the PMO’s annual review indicate that significant changes are needed to ensure that included information is up-to-date and relevant. If so, the SIG will be revised as soon as possible during the current calendar year.

APPLICATIONS COVERED BY THIS SIG

This SIG applies to the Enterprise Business System (EBS) application. EBS is the DLA single Enterprise Resource Planning (ERP) solution used to automate, integrate, and enhance the DLA Supply Chain capability. EBS is a robust Commercial-Off-The-Shelf (COTS)-based ERP enterprise system that is secure, flexible, integrated, and inter-connected. Its primary mission is financial reporting, supply chain management, and logistics support; it is the DLA core financial system. The DLA EBS uses COTS products to provide an ERP solution approach to manage all DLA supply chains. EBS is in sustainment status and enhancement changes are made, as required.

REFERENCES

(a) DLA Instruction (DLAI) 8250.01, Enterprise Configuration Management, March 16, 2023

(b) DLA Enterprise Configuration Management Plan (ECMP), version 6.4, May

(c) DLA Enterprise Configuration Management Standard Operating Procedure (SOP) 8250.01-01, Change and Configuration Management, August 2023

(d) Configuration Control Steering Group (CCSG) Charter, version 6, November 13, 2023

(e) EBS Configuration Control Working Group (CCWG) Charter, version 7.0, September 2022

(f) ECM Acronyms and Glossary

(g) Federal Information System Controls Audit Manual (FISCAM), February 2009

(h) National Institute of Standards and Technology (NIST) Special Publication 800-

53, Security and Privacy Controls for Federal Information Systems and Organizations, version 5.0, September 2020

Page | 6

(i) DLA Standard Operating Procedure (SOP) 8510-01-01, DLA Risk Management Framework (RMF), March 2022

(j) EBS Development Lifecycle (EDLC) Desk Guide, version 2.0, March 2023

(k) EBS PfM CCWG Desk Guide, version 7.0, April 2023

(l) EBS PfM Migration Process Desk Guide, version 2.0, March 2022

(m) EBS PfM Release Management Desk Guide, version 3.0, June 2023

(n) EBS PfM System Change Option via SCC4 Desk Guide, version 3.1, June

(o) EBS PfM Configuration Items (CI) Naming Convention Desk Guide, version

3.2, August 2022

(p) EBS PfM Interface Agreements Process Desk Guide, version 6.0, December

(q) EBS PfM Patch Management Desk Guide, version 1.0, January 2023

(r) EBS Capability Support Plan (CSP), version 2.2, August 2023

(s) EBS Information System Contingency Plan (ISCP) NS2 Hosted Continuity of

Operations Planning (COOP), version 2.0, February 2023

(t) EAGLE Enterprise Change Request Tool (ECRT) Manual, version 4.2, February 2022

(u) EBS Resource and Prioritization Board (ERPB) Charter, version 3.1, April 2022

(v) EBS Records Management Desk Guide, version 4.1, June 2023

(w) Department of Defense Instruction (DoDI) 5000.75 Change 2, Business

Systems Requirements and Acquisition, January 24, 2020

(x) DLA Cybersecurity Auditing Implementation Guide, version 3.0, January 2021

(y) EBS Audit Log SIG, version 2.2, July 2023

(z) EBS Access Control Plan, version 5.0, February 2023

(aa) SE Assessment Internal Control Process Desk Guide, version 6.0, January

(bb) EBS CCWG Agenda Development and Post Migration Desk Guide, version

6.0, March 2023

(cc) EBS PfM Test and Evaluation Master Plan (TEMP), version 3.3, August 2023

(dd) EBS Change Advisory Board Desk Guide, version 2.0, December 2023

(ee) EBS Production Environment Maintenance Window Desk Guide, version 1.0, January 2024

(ff) EBS PfM BCM Job Aid, version 1.1, December 2023

ORGANIZATIONAL INFORMATION

DLA Information Operations (J6) is the DLA knowledge broker, providing comprehensive and best practice Information Technology (IT) support to the Department of Defense (DoD)/DLA Logistics Business Community.

Within J6, the Program Executive Officer (PEO) (J62) oversees Enterprise Applications and provides central coordination with Agency acquisition leadership and functional owners. J62 is responsible for development and delivery of new DLA application solutions and sustainment of application operational capabilities.

Within J62, the EBS PfM Directorate (J62E) is the organization having the responsibility for overseeing and maintaining EBS production applications and providing management of activities that plan, design, build, test, and deliver EBS enhancement capabilities. The

Page | 7 responsibility of each division is described in the EBS Capability Support Plan (CSP), Governance Structure and Responsibilities section.

FUNCTIONAL STAKEHOLDER FORUMS/BOARDS

All new requirements are managed by the IT Business Management (ITBM) process.

Requirement reviews are conducted to identify if high priority customer requirements are already being fulfilled by another product. In addition, program enhancement and refinement efforts are determined through the DLA established change management process. These modifications are reviewed and approved by senior leadership to ensure they meet the guidelines of Process Excellence (PE) and business prioritization before they are captured as enhancements to EBS functionality.

CONTRACTOR MANAGEMENT

Contractors and Government staff work in integrated teams based on the organizational structure described in Section 4.0. PMO government oversight occurs at every stage of the life cycle. EBS Contractor Support is described in Table 1.

Contractor Company Name Contractor Role(s) Electrosoft Program Management Support Accenture, Electrosoft Production Support (i.e., CCWG) IndraSoft Incorporated Production Support (DLA Internet Bid Board System

(DIBBS))

Advantaged Solutions, Inc. (ASI) Cloud Service Provider KPMG G-Invoicing Comprehensive Integration

Table 1: Contractor Support

CONFIGURATION/CHANGE MANAGEMENT TOOLS

This section of the document describes the program-level CM tools used by the EBS Portfolio in support of the DLA J6 ECMP. The key EBS CM Tools, their roles, and hosting location is described in Table 2.

Tool Name Role of Tool Hosting Location

DACS-CM

Repository for Enterprise CM documents to include CCWG Charter, SIG, and CCWG meeting minutes

DLA

SharePoint Online (SPO)

Repository used for CM documents, EBS PfM Desk Guides and EBS Enterprise Architecture products (Staging), and Software Design Descriptions (SDDs)

DLA

IBM Rational ClearQuest/ ClearCase (Workbench)

Repository for Design, Development and Test documentation; Software Change

DLA

Page | 8

Tool Name Role of Tool Hosting Location

Management and Version Control;

Release Management

Design Time Repository (DTR) and NetWeaver Developer Infrastructure

(NWDI)

Used for source code configuration management; allows developers to look back at old versions of source code, compare versions, and (if needed) bring back a previous version

DLA

Business Capability Management (BCM)

Used to capture/track change requests and requirements management

DLA

Enterprise Change Request Tool (ECRT)

Used to manage Job Role Changes DLA

DLA ServiceNow

(SNOW)

Used by the DLA Admins to log and track break/fix and user service requests

DLA

SAP NS2 ServiceNow Used by SAP NS2 technicians to log and track service/change request; it is utilized to tack all system transports released into production environment

NS2

CyberSWAT Remedy Used to support the Plans of Action and Milestones (POAM) Management and Asset Management workflows in EBS

DLA

DLA Portfolio and Architecture Tool Suite

(DPATS)

Official Repository for EBS Enterprise Architecture Products

DLA

Computer Associates (CA) Harvest Software Change Manager

Used for Non-Systems, Applications and Products (SAP) (i.e., DLA Internet Bid Board System (DIBBS) Unix and JDA source code) and version control change management process; and planning

DLA

SAP Version Management

Used for Systems, Applications and Products (SAP) version control change management process and version comparison

DLA

Code Dependency/Conflict Check Utility

Used by developers and Release Management to check code before submitting for release to production

DLA

Enterprise Git Hub DIBBS web site and UI5 application source code version control change management process and version comparison

DLA

Jira Tool for managing Agile project execution

DLA

Table 2: CM Tools

Page | 9

CYBER SECURITY

Risk Management Framework (RMF)

The Enterprise Mission Assurance Support Service (eMASS) is DoD’s automated authorization workflow tool and DLA’s automated tool for supporting the implementation of the RMF.

eMASS facilitates robust, measurable cyber security program management through the following capabilities:

• Security-process management and reporting based on compliance with Security Controls

• Standardized information exchange to facilitate dynamic connection decisions

• Workflow automation

• Simplified management of the entire authorization process from security authorization package submission through completion

• Asset/device management supporting Continuous Monitoring with automated

Security Control assessment and opening/closing of POAM items

• Traceable Systems-security engineering across the entire System development lifecycle

• Facilitate regulatory and cyber security management reporting requirements

(e.g., The Privacy Act of 1974, 5 U.S.C. § 552a; Federal Information Security Management Act (FISMA) of 2002, 44 U.S.C. § 3541; Section 208, E- Government Act of 2002 (P.L. 107-347); OMB Memoranda 03-22, 05-08, 06- 16, 07-16; OMB Circular A-130)

The Program Manager/System Manager (PM/SM) and Information System Security Manager (ISSM) ensure that assessment results, POAM items, and applicable supporting artifacts for security controls are documented within eMASS. The applicable POAMs are created by the EBS Subject Matter Experts (SMEs) in eMASS for the RMF package. They provide the POAM’s content, milestones, dates, etc. POAMs are reviewed at least every 90 days.

EBS SMEs review existing artifacts and, when necessary, provide additional documentation to support compliance. These documents are then reviewed by the J611BA ISSM team and other appropriate SMEs before they are uploaded into eMASS.

The assessment of the security controls is performed by the J611BA ISSM team and validated by the J611A Security Control Assessor (SCA) Representative team. The assessments and validations of security controls are performed monthly in accordance with the DLA Continuous Monitoring Schedule.

EBS adheres to the DLA RMF SOP process and has been granted an Authority to Operate (ATO) for the EBS system, which expires December 8, 2026. The authorization decision is stored and maintained in eMASS as a registered Information System (IS) Major Application with System Identification 12.

Page | 10

Vulnerability Identification, Assessment, and Patch Management

When a patch or patch-set level has been determined to be required for installation at the application component level, it is:

1. Acquired in accordance with DoD and vendor download process protocol.

2. Reviewed by the technical support team for the component to confirm that it is correct.

3. Installed in the appropriate Development environment for the affected component and development tested. Purposed patches are drafted in the Release for Testing (RFT) excel template (noting what patches are to be applied to which servers) initiating patch traceability workflow. RFT patches are installed to the appropriate Development environment systems/components and deployment results are analyzed.

4. Migrated to the corresponding component system:

a. Test environment-- tested upon successful completion of Development environment testing.

b. Staging environment-- where all applicable baseline Security Technical

Implementation Guides (STIGs) are applied and tested for vulnerabilities (which cannot be remediated prior to moving to Production; must have associated POAM approved by ISSM).

5. Upon successful testing and evaluation at the Staging level, schedule DLA Change Advisory Board (CAB) with hosting Service Provider for patching change review prior to actual migration, implementation, and validation.

Vulnerability Identification, Assessment, and Patch Management is managed by EBS Technical Support (J62EC). The EBS test, stage, and production environments are hosted by SAP NS2 Managed Cloud Delivery (MCD) Support. EBS follows the Enterprise approach and has no additional supplemental information to add.

For more information, reference the EBS PfM Patch Management Desk Guide.

PMs develop an acquisition strategy for Milestone Decision Authority (MDA) approval that matches the acquisition pathway processes, reviews, documents, and metrics to the character and risk of the capability being acquired. EBS tailors the Defense Business Systems (DBS) Acquisition from the Adaptive Acquisition Framework (AAF) to acquire information systems that support DoD business operations. This pathway applies to defense business capabilities and their supporting business systems, including those with “as-a-service” SAP NS2 Secure HANA Cloud (SHC) solutions to include financial and financial data, feeder, contracting, logistics, planning and budgeting, installations management, human resources management, training, and readiness systems. DoDI

5000.75 establishes policies and provides procedures for the DBS acquisition pathway.

EBS Technical and Compliance Teams review Software Metrics, Test Results, and Authority to Proceed (ATP) reviews to ensure application(s) changes do not introduce vulnerabilities.

McAfee Host Based Security System (HBSS) is used to provide host-based protection.

HBSS provides virus protection and host-based firewall. J61 Assured Compliance Assessment Solution (ACAS) Team performs weekly and ad hoc scans, upon request, to detect vulnerability status and provide scan results to the EBS PMO and J611BA

Page | 11

ISSM. ACAS consists of a suite of products to include the Security Center, Nessus Scanner, and the Nessus Network Monitor provided by the Defense Information Systems Agency (DISA) to DLA. DISA’s Cyber Development (CD) provides program management for the Enterprise ACAS, as well as help desk support and training.

WebInspect scans are completed on external facing sites at least annually and performed by the J614CC Web Application VM Team. Results are provided to the EBS PMO to address and remediate the findings and to the J611BA ISSM team for awareness and to assist the PMO with applicable POAM(s), if warranted.

The J611BA ISSM team reviews planned automated Operation System (OS) and manual Application STIG packages providing necessary feedback to the various SMEs and tracks the corrective action(s) prior to package approval to be implemented in the Production environment. POAM(s) are submitted for findings that are unable to be resolved within the specified timeframe per DoD/DLA guidelines. The J611BA ISSM team receives POAMs from the SMEs. POAMs are tracked via the time schedule in the RMF SOP determined by the severity of the POAM. If findings cannot be mitigated, the J611BA ISSM team works with the SMEs to gather technical information for the J611BA ISSM to submit an Authorizing Official (AO) Risk Acceptance (AORA) package for AO acceptance. The AORA is reviewed annually. If AORA is still required, a new AORA must be submitted.

The J62EC Compliance team reviews and updates the EBS Information Systems Asset List at least monthly to ensure the EBS PMO is tracking all information systems that fall under the EBS Program. The EBS asset list is updated by the SAP NS2 Hardware List that is delivered to EBS on a quarterly basis or whenever a change is made to the Hardware List. If no Hardware List is provided in any given month, no changes have been made to EBS assets. The EBS Asset List is stored and managed using the CyberSWAT tool.

Security Logging

The DLA Auditing Implementation Guide was developed for the purpose of implementing auditing and logging on Enterprise DLA Information systems. All user or account usage anomalies or unusual activity resulting in incidents involving J6 employees or Contractors are escalated to the DLA Computer Emergency Response Team (CERT) Incident Response for investigation, as defined in the EBS Access Control Plan, Enclosure 3, Section 7 – Auditing and Monitoring. The EBS Audit Security Log Configuration Status Accounting Reports (CSAR) are reviewed and discussed during the weekly CCWG meeting.

CONFIGURATION ITEMS (CIs)

Configuration identification is applied to all software and hardware, as applicable, per the ECMP. EBS hardware components are managed by Amazon Web Services (AWS).

EBS Technical Support (J62EC) manages and tracks a complete inventory through CyberSWAT. This inventory is updated according to the hardware listing of the EBS environment provided by SAP NS2 on a monthly cadence. The EBS CCWG monitors and maintains the integrity of the EBS CIs as they evolve, throughout the System Life

Page | 12

Cycle, in accordance with the EBS PfM processes and desk guides. Refer to the list of main system components under NS2 configuration control listed in Table 3, CI List.

EBS Configuration Items SAP Components/SAP COTS Applications CRM – Customer Relationship Management (eSales and TREX) ECC - ERP Central Component which includes:

• CO – Controlling

• CS – Customer Services

• FI – Finance

• HCM – Human Capital Management

• MM – Materials Management

• PM – Plant Maintenance

• PP – Production Planning

• PS – Project System (IS-PS and IS-Oil)

• QM – Quality Management

SD – Sales and Distribution PLM – Product Life Cycle Management (PDMI and cFolders) RM – Records/Case Management SCM – Supply Chain Management for DLA Energy (including Advance Planning Optimization (APO) with Demand Planning (DP), Supply Network Planning (SNP), and Global Planning To Promise (GATP) options) with special SAP technologies liveCache/MaxDB and Optimizer SRM – Supplier Relationship Management with Procurement for Public Sector and DocBuilder

SAP HANA

GOTS Applications DIBBS (DLA Internet Bid Board System) Application Support Services SAP Solution Manager Archiving Services OpenText

SAP ILM

Datavard Outboard Nearline Solution Data Services HANA Rapid Deployment Solution (RDS) aka HANA SideCar Database (Oracle and SQL Server) Integration Services IBM WebSphere MQ SAP Data Services SAP Gateway Open Data Protocol (OData) Services SAP Landscape Transformation (SLT) SAP PO (Process Orchestration) Presentation Services Adobe Smartforms/Document Services SAP Enterprise Portal (Internal and External) Web Services Apache Tomcat MS Internet Information Services (IIS)

Page | 13

EBS Configuration Items WebLogic Associated Utility Software Document Builder Workbench (IBM Rational ClearQuest/ClearCase) Microsoft Internet Information Services (IIS) MQ Series OpenText Enterprise Content Server (ECS) OpenText Systems Applications Products Graphical User Interface (SAPGUI) Oracle WebLogic

Table 3: CI List

Baselines

EBS baselines are established upon the completion of a CM request, in accordance with EBS PfM desk guides, based on deliverables requested. These baselines are essential to maintaining traceability of changes to the Program’s Cis throughout the Program’s life cycle. EBS currently manages baselines for Business System Category (BCAT) programs via Test Results, Software Metrics, ATP review requirements and, for non- BCAT Projects, using the Release Plans. Established baseline asset tracking is officially maintained in CyberSWAT (under Business Resiliency; Business and or IT Asset Catalog).

Version Control

Version control is applied to CIs listed in Section 9.0. Code version control for SAP objects is managed via the SAP ABAP Workbench tool. An appropriate editor, within the tool, controls and maintains the version numbering for each type of SAP object. Code version control for DIBBS objects is managed via Enterprise GitHub.

Naming Conventions

The EBS Configuration Items Naming Convention Desk Guide prescribes the naming convention for CIs listed in Section 9.0. These naming conventions ensure proper traceability between tools, starting with the Change Request through implementation.

CM-Related Documentation and Records

EBS CM-related documentation and records are maintained in accordance with the ECMP Tenets and Configuration Management Documentation. The key EBS CM-related Documents and Records are described in Table 4 below.

CM-Related Document or Record Name Document or Record Storage Location

CCWG Charter DACS-CM

CCWG Meeting Agenda DACS-CM

CCWG Meeting Minutes DACS-CM

Page | 14

CM-Related Document or Record Name Document or Record Storage Location

EBS SIG DACS-CM

Systems Engineering Technical Reviews DACS-CM

Change Request Records BCM

Request for Job Role Changes ECRT

Change Request Requirements BCM

Release Plans (Schedule) BCM

Sprint Schedules JIRA

Test Plans/Cases Workbench ClearQuest

Incident Tickets NS2 Service Now

EDLC Desk Guide SPO

Defects/Enhancements Workbench ClearQuest

Existing Functional Specifications Workbench ClearQuest/ClearCase

Existing Technical Specifications/New Software Design Descriptions (SDDs)

Workbench ClearQuest/ClearCase/

SPO

Existing Configuration Rationales/Customizing Steps Workbench ClearQuest/ ClearCase

Test Results Workbench ClearQuest

EBS Enterprise Architecture Products DPATS

EBS PfM CCWG Desk Guide SPO EBS PfM Migration Desk Guide SPO EBS PfM Release Management Desk Guide SPO EBS PfM Patch Management Desk Guide SPO EBS PfM Change Advisory Board Desk Guide SPO RMF SOP eMASS

Table 4: Key CM Documents and Records

Interface Management

Identification of and information about EBS interfaces and specific aspects of the system resource flow is maintained in EBS’s System View (SV-6) Enterprise Architecture product, and maintained in the DLA Enterprise Architecture repository, DPATS. The process for establishing and maintaining EBS interface agreements is documented in the EBS Interface Agreements Process Desk Guide.

SOFTWARE DEVELOPMENT LIFECYCLE

EBS is in the Capability Support Phase (referred to as Production Support within DLA) of the Business Capability Acquisition Cycle (BCAC), DoDI 5000.75 life cycle; however, the

Page | 15 refinement of EBS through process and technical improvements is critical to the Agency’s mission. Any EBS modernization effort determined to be a BCAT III level acquisition program follows a tailored approach to BCAC’s Business System Acquisition, Testing and Deployment phase requirements. EBS primarily uses the EBS PfM processes/desk guides to satisfy life cycle requirements.

Please refer to the EBS PfM Desk Guides (referenced in Table 4), which outlines each phase of the EDLC.

CHANGE REQUEST PROCESS

Submission, Authorization, and Identification

Changes to the system are handled through ECRT and ITBM BCM. Incident (Tickets) are managed through DLA ITSM SNOW and SAP NS2 SNOW. A unique identifier is automatically assigned by the tool, as defined in the ECRT Manual Record Number Assignment section. The CCWG Charter, Section 9.0, further outlines the Decision- Making Process for the review of Change Requests.

Change Request Technical Reviews and Approval

Detailed reviews and automated documented approvals occur before moving from requirements to development, development to testing, and testing to production release to comply with the Enterprise CM Policies and Procedures. Change requests in EBS are governed by the EBS EDLC Desk Guide. When EBS or its sub-components require system change, service update/upgrade, or new implementation, the change is first approved, and a proper change and configuration management workflow is selected.

Once approved, a non-migration DLA Production (DLAP) record is created in Workbench ClearQuest.

Change requests for development changes in EBS are governed by the EBS EDLC Desk Guide. Once approved, a DLAP record is created in Workbench ClearQuest.

Development changes are defined as any software enhancement or modification that requires an application developer to design, build, test, and deploy a technical solution to meet a business need.

Change requests for sustainment or break fix changes in EBS are governed by the EBS CAB Desk Guide. A ticket is created in NS2 SNOW to document the details of the change and initiate the CAB review process before EBS Production implementation. A sustainment or break fix change is defined as any change that supports the continued operation and/or security of the EBS system.

The Technical Support team uses NS2 SNOW CM for mandated J6 internal tracking of all system transports released into the Production environment.

The EBS CCWG reviews Change Requests following J6 IT Approval and changes to the baseline are managed through the EBS PfM Processes. All changes that have been implemented are presented to the CCWG and any Unexpected Outcomes are reviewed and addressed.

Page | 16

Any changes originating from portfolios outside of EBS, but has potential to impact applications, interfaces, or infrastructure components inside of the EBS CCWG control, will follow guidance from the ECMP and provide situational awareness to the EBS

CCWG.

Any changes with potential impact to applications, interfaces, or infrastructure components outside of the EBS CCWG control is escalated in accordance with the escalation criteria/process.

Change Traceability

When a direct or non-transportable change has been identified, a non-migration DLAP is created for the change. Assignment of the non-migration DLAP to the associated change is used to support traceability from the development phase through production implementation. All subsequent DLAPs, SNOW tickets, and associated transports require references the DLAP.

The change is subject to CCWG tracking prior to entering the production environment and is verified by the CCWG within no more than 30 days after implementation completion to determine if the change is working properly. A successful verification of the change results in the non-migration DLAP closed out with verification status comments within the DLAP record.

EMERGENCY CHANGES

EBS manages emergency development changes using the standard EBS PfM Processes (referenced in Table 4) with the exception that these changes are expedited in accordance with the EBS PfM Release Management Desk Guide.

Emergency DLAPs are escalated through the appropriate channels for managerial approval via Workbench and then migrated at the time of approval. The EBS PfM Release Management Desk Guide documents how the DLAP should be coded for an emergency release and how the approval process works. After release, an emergency release is treated the same in accordance with the EBS PfM Release Management Desk Guide and is then included on the CCWG Agenda Change Requests/Request For Job Role Changes (RFJRCs)/Tickets Implemented and Unexpected Outcomes for a post implementation CCWG review.

The CCWG Agenda includes a Post-Migration and Implementation Tab used to validate implementation of Migrated Records through a Transport Record. J62EC is required to address any items with discrepancies (i.e., missing DLAP record) during the CCWG meeting. Any records requiring further investigation are tracked through closure.

Emergency sustainment changes are managed through the Emergency CAB Request workflow that is detailed in Enclosure 3 of the EBS CAB Desk Guide.

Emergency NS2 SNOW tickets are escalated through the appropriate channels for managerial approval via email and then implemented at the time of approval. The EBS CAB Desk Guide documents how the ticket should be submitted for an emergency change and how the approval process works.

Page | 17

SYSTEM SPECIFICATIONS

All artifacts generated throughout the Agile Process, in accordance with the EDLC will be reviewed, approved, and stored in the applicable repository as listed in Section 9.0.

At a minimum the below items should be included:

1. Test plans

2. Test Results

3. IA Scan Results

4. Design Specifications

SECURITY IMPACT ANALYSIS

Security impact analysis is conducted by the J611BA ISSM Team and SMEs to determine the extent to which changes to the EBS environment affect the security posture. Because the EBS system is typically in a constant state of change, it is important to understand the impact of existing security controls with proposed system changes.

The security impact analysis review is conducted to assess for adverse security effects for proposed changes to the environment. This review is conducted prior to approval of proposed changes and implementation. This also applies in the case of emergency/ unscheduled changes. The SMEs provide any configuration changes that could potentially affect security posture to the J611BA ISSM team for a collaborative review. A Security Impact Analysis checklist is documented detailing possible security risks and stored in eMASS as evidence.

TESTING

Test Planning

EBS Development Testing is performed by EBS Developers, in accordance with the EDLC Desk Guide. EBS Test Plans are developed by the Functional Analysts (FA) based on applicable testing (508, system, regression, partner and/or performance) and approved by the SME in accordance with the EDLC Desk Guide. Test Cases are retained in Workbench record.

Test Results

Development Testing is conducted in accordance with the EDLC Desk Guide, and results are documented in the approved document repository (see Table 4). Once Development Testing is completed, the Functional Analyst performs System Testing along with all other applicable testing (508, regression, partner and/or performance) as detailed in the EDLC Desk Guide.

For break/fix changes, screenshots are required showing test results and are uploaded to the ‘Attachments’ tab in Workbench. For Change Request changes, formal test plans are required and uploaded to the ‘Attachments’ tab in Workbench or linked to a formal test plan on the ‘Related Test Plan’ tab in Workbench.

Page | 18

The test results are peer reviewed. If the test results do not produce the desired result as described in the Product Backlog acceptance criteria, the test fails, and the code must be modified and retested. Additionally, the stakeholders participate in User Acceptance Testing (UAT) and capture sign-off in BCM. EBS test cases are developed based off requirements detailed in the FS or Configuration Rationale. Test results are documented in the Workbench record by the FA, as described in the EDLC Desk Guide.

ENVIRONMENTS

The EBS ISCP provides an accurate representation of the DLA specific processes and procedures required to recover systems within Production and Production Support environments. This document further identifies the criticality of the system as it relates to the Agency’s mission and that the recovery strategies identified will provide the ability to recover the system’s functionality in the most expedient and cost-beneficial method in keeping with its level of criticality. Table 5 lists the (Cloud) Hosting Environments.

Environment Hosting Location Hosting Provider

Development

Primary: AWS DoD West Region (Boardman, OR) – AZ 1a

Failover: AWS DoD West Region (Boardman, OR) – AZ 1b

AWS NS2 Cloud

Test

Primary: AWS DoD West Region (Boardman, OR) – AZ 1a

Failover: AWS DoD West Region (Boardman, OR) – AZ 1b

AWS NS2 Cloud

Staging

Primary: AWS DoD West Region (Boardman, OR) – AZ 1a

Failover: AWS DoD West Region (Boardman, OR) – AZ 1b

AWS NS2 Cloud

System

Primary: AWS DoD West Region (Boardman, OR) – AZ 1a

Failover: AWS DoD West Region (Boardman, OR) – AZ 1b

AWS NS2 Cloud

Production

Primary: AWS DoD West Region (Boardman, OR) – AZ 1a

Failover: AWS DoD West Region (Boardman, OR) – AZ 1b

AWS NS2 Cloud

Continuity of Operations (COOP)

AWS DoD East Region (Ashburn, VA)

AWS NS2 Cloud

Table 5: (Cloud) Hosting Environments

Page | 19

Access Approval, Control, and Segregation of Duties (SoD)

All tools used for CM follow Cyber Security Policies and Procedures for access control to ensure legitimate need and lowest level privilege guidance is followed.

EBS uses the Account Management and Provisioning System (AMPS) to manage control access and define roles within EBS in accordance with the EBS PfM Release Management Desk Guide. ECRT is used to ensure job role changes. Auto-provisioning is completed through AMPS and manual-provisioning is completed through the Manual DD2875 Workflow.

SoD is used to prevent situations where one person can perform multiple roles and circumvent CM controls. One such SoD violation is the ability to develop code or make changes and then be able to import that code or change to the production environment.

To appropriately restrict and segregate those duties, the ability to import transports was removed from Basis users and restricted to the Release Management team. Access Control Policies and Procedures ensure that EBS transport capabilities are only assigned to Release management. EBS implemented controls through job roles to only allow DLA Basis and Development users access to create transports in development environments. Release Management users complete the process by migrating transports into system test and then production environments after formal release authorization from the system Change Authority. A comprehensive review of access for users with multiple roles within the SAP development and production instances of EBS is accomplished annually.

The Data Owner approves requests for access to systems/data under their purview ensuring all requirements for system access are met, including validating the user’s need to know of the information contained in the system and the job role (as needed for the user to perform their job functions). The Data Owner reviews access/job roles to ensure SoD principles are adhered to, identifying sensitive and privileged transactions and roles. The Data Owner is responsible for all risks that are identified in the role and corresponding mitigation strategy to all risks need to be determined. High risks may be referred to the Access Control Advisory Board (ACAB). Data Owners reach out to the J62FG Governance, Risk and Compliance (GRC) team to ensure SoD principles are implemented.

Library Control

All system software resides on the development and non-production environments until it meets the requirements outlined in any software changes that were formally submitted, tested, and approved and are ready for promotion into production. EBS has the following libraries controlled using the designated tools noted in Section 9.0:

• Development Environment (includes Development and Unit Test): The appropriate CM tool (SAP or Harvest) is used to migrate code to the System Test Environment. The approval for System Test is performed as described in the EDLC Desk Guide

• System Test Environment (includes User Acceptance Test): The Application Control and Support Services SAP Release Management (RM) team (DLA Basis) is responsible for preparing the migration package and transport of

Page | 20 migration package for all SAP Transports to all production environments as described in the EBS PfM Release Management Desk Guide

• Production Environment: The NS2 Application Managed Services team (Cloud) receives the migrated package into all production environments. A Return Code email is sent to the Release Management team if there are any Production Migration issues; a completion email is sent when migrations to production have completed

RELEASE MANAGEMENT

Changes moved into the Production environment are done in accordance with the EBS PfM Release Management Desk Guide. SAP Release Management sets the Workbench state of the transport(s) to “Completed” after each transport has been migrated.

“Completed” Change Requests/RFJRCs/Tickets are reviewed at the weekly CCWG meeting.

Release Management migrates from System Test to Staging during regression test;

however, for final cutover to production, those changes are coordinated by the Basis Team (packaging, staging for the Service Provider and coordinating error resolution post-production migration).

The majority of changes released to production are processed through the Release Management Team via Workbench. The Release Management Team determines release order based on the order the changes were released to system test and in accordance with approval documentation. However, for major releases (upgrades, etc.), the Basis Team manages releases using the order that changes move into the Staging environment. There is no dependency on the Workbench for those types of production releases. The only dependency is that the migrations must move into Staging. If changes are moved to Staging, then they go to production in order of priority:

• GOLD – 1st

• SILVER – 2nd

• BRONZE – 3rd

INCIDENT MANAGEMENT

Incidents Reports/Tickets are initiated in SAP NS2 SNOW (Cloud Operating Environment). Ticket/Incident accounting information is maintained in Workbench ClearQuest DevOps software for the lower environments by the Project Teams. Once the solution has been vetted and ready to move into production for implementation, the Incidents Reports/Tickets are initiated in SAP NS2 SNOW and tracked through completion in accordance with the EDLC and CAB Desk Guides. Related details are captured in Workbench DLAPs and with SAP NS2 SNOW for SAP NS2 Applications Managed Services activities.

ACCESS AND CHANGE MONITORING

PMs monitor access and changes to the EBS system as described in the EBS PfM Migration Desk Guide and the EBS PfM Release Management Desk Guide. The PM creates and manages the Release Plan as described in the EDLC Desk Guide.

Page | 21

The Enterprise Release Management team ensures the requested transports were successfully migrated into EBS. However, the corrective action for errors in DLAP or Transport record is sent via email to the Analyst, Developers or Technical Lead for resolution until migration is successfully completed. The frequency of changes is on demand for migrations to Test and Development. Documented evidence of the baseline configuration audit is performed over approved baseline prior to the system logging function being disabled. This provides proof that each change identified can be reconciled to applicable CM Evidentiary Matter which demonstrates that any unrecognized changes were appropriately followed up on in a timely manner, and that any required actions were taken for items that are potentially unauthorized changes to the production environment.

The EBS CCWG meets weekly and is initially involved when the Change Requests and Tickets go to “In Process” state; the Release Plan is also discussed. The status of the Change Requests/Tickets are tracked in Workbench ClearQuest during its life cycle.

Other Significant Changes are also discussed at the discretion of EBS PMO.

The EBS CCWG reviews Implemented Change Requests/RFJRCs/Tickets, along with any Unexpected Outcomes. In addition, the EBS CCWG conducts a Post Migration Implementation Review of the previous week’s CCWG Implemented Change Requests/RFJRCs/ Tickets and provides traceability to corresponding Transport Records.

POST IMPLEMENTATION CHANGE REVIEW

The EBS CCWG reviews changes implemented in Production and unexpected outcomes associated with changes in accordance with the CCWG PfM Process. Any required updates to manage incidents and address modifications that do require code changes follow the EDLC Desk Guide. The PMO conducts a post-implementation review and results are documented and stored in the project folder on SPO.

The CCWG reviews any comments made to the non-migration DLAP with any status updates to the change, as well as coordinates with Functional Analysts and Technicians to validate that the change has been implemented and produces the expected outcome.

The Functional Analysts and Technicians close the non-migration DLAP with comments on verification status once the expected outcome has been verified.

CM VALIDATION, AUDIT, AND REPORTING

Status information for projects in BCM is maintained by the Project Managers.

Configuration status records of all CIs that have been placed under project-level, or higher configuration control are prepared and maintained for the life of the project. They include, as applicable, the current version/revision/release of each CI, a record of changes to the CI since being placed under project-level or higher configuration control, and the status of problem/change reports affecting the CI. The CCWG conducts a weekly review of newly approved projects placed in Work in Progress state, as well as Implemented DLAPs associated with projects for the weekly performance period.

Results are documented on the CCWG Minutes.

Page | 22

Configuration Status Accounting Reports (CSARs) are reviewed at weekly CCWG Meetings in accordance with the CCWG Agenda Development and Post Migration Desk Guide. Any anomalies discussed and open/pending actions are tracked to closure.

Following is a sample set of CSARs reviewed at the CCWG:

• Weekly EBS Audit Security Log Review

• BASIS SCC4 Weekly Log Report

• Weekly DLA-ERP ASE DB Missing Backups

• PL1-231 Change Documents Review Checklist Summary

The Physical Configuration Audit (PCA) review occurs post project implementation in accordance with the EDLC Desk Guide, Complete Post-Production Review step. The EBS Application Development, Program & Project Management, and Technical Environment & Application teams assemble and make available to the PCA team, at the time of the audit, all data describing the deliverable CIs, as well as the Environment Testing (ET)/Initial Operational Capability (IOC) Test Reports. This includes test scenarios, test cases, test evaluation and EBS PfM Test and Evaluation Master Plan (TEMP). The results are checked for completeness and accuracy; and, verified against the test reports. Deviations are documented. Completion dates for all deviations are clearly established and documented as well. Upon completion and written acceptance of the PCA by the System CCWG, the Product Baseline is established. Reviewed results are recorded on the Project Post-Implementation Review sheet. The Record Manager maintains records and artifacts in accordance with the EBS Records Management File Plan in DACS-RM for a period no less than one (1) year after system life cycle decommissioning. Records and Artifacts are inspected quarterly to ensure system changes are completely documented, approved, archived, and uniquely identified to allow for traceability to associated system change in accordance with the DLA ECMP.