SOW - TO 2 CYBER TRIDENT TO 2 SOW - 29 Apr 2020 Updated.pdf

SOW-2020-011-02

STATEMENT OF WORK

for the

Cyber Training, Readiness, Integration, Delivery and Enterprise Technology (Cyber TRIDENT)

Task Order Two (2) – Persistent Cyber Training Environment (PCTE) Integration Factory

U.S. Army Program Executive Office for Simulation, Training, and Instrumentation (PEO STRI)

12211 Science Drive Orlando, FL 32826-3276

Revision Number Date Log of Changes Made and Description of

Reason Changes Approved By

Table of Contents

1. SCOPE

1.1 Introduction

1.2 Goals and Objectives

2. APPLICABLE DOCUMENTS

3. REQUIREMENTS

3.1 Program Management

3.1.1 Monthly Report

3.1.2 Associate Contractor Agreements (ACAs)

3.1.3 Schedule

3.1.4 Reserved

3.1.5 Reserved

3.1.6 Risk Management

3.1.7 Program Management Reviews (PMRs)

3.1.8 Facilities

3.1.9 Material Acquisition - Computer Hardware, Enterprise Software Solutions

(CHESS) Program

3.2 Development Operations (DEVOPS) Process

3.2.1 Capability Development, Integration, Delivery and Sustainment

3.2.2 Integration Factory

3.2.3 Integration

3.2.3.1 Third Party Onboarding and Orchestration

3.2.3.2 CI/CD Pipeline

3.2.3.3 Agile Systems Engineering

3.2.3.4 Agile Ceremonies

3.2.3.5 Requirements

3.2.3.6 Architecture

3.2.3.7 Test

3.2.3.8 Configuration Management (CM)

3.2.3.9 Release Management

3.2.4 Metrics

3.3 Operations

3.3.1 Event and Exercise Support

3.3.2 End User Outreach

3.3.3 Baseline Management

3.4 Cybersecurity

3.4.1 Security Engineering

3.4.2 Risk Management Framework (RMF)

3.4.3 OPSEC Clauses/COMSEC/Declassification

3.4.3.1 Requirements for OPSEC Training:

3.4.3.2 Anti-Terrorist Training (AT Level 1)

3.4.3.3 Active Shooter Training

3.4.3.4 Access to Government Information Systems

3.4.3.5 Professional Training and Certification

3.4.3.6 Personal Identifiable Information (PII)

3.4.3.7 Security and Access Controls

3.4.3.7.1 General Security

3.4.3.7.2 Security Clearances

3.4.3.7.3 Access and General Protection/Security Policy and Procedures

3.4.3.7.4 Handling or Access to Classified Information

3.4.3.7.5 Disclosure of Information

3.4.3.7.6 Effective Use of Controls

3.4.3.7.7 System Security Plan (SSP)

3.5 Training

3.5.1 Training Packages and Delivery

3.6 Test

3.6.1 CI/CD Testing

3.6.2 Developmental Testing

3.6.3 Operational Testing

3.6.4 Defect Management and Resolution

4. ADDITIONAL CONTRACTOR REQUIREMENTS

4.1 Interaction and/or Disclosure with Foreign Country/Foreign National

Personnel

4.2 The Enterprise-Wide Contractor Manpower Reporting Application

(eCMRA)

Statement of Work

SOW-2020-011-02

Cyber Training, Readiness, Integration, Delivery and Enterprise Technology (Cyber TRIDENT) Task Order Two (2)

1. SCOPE

This Statement of Work (SOW) defines the scope of the Project Manager Cyber Test and Training (PM CT2) Product Manager Cyber Resiliency and Training (PdM CRT) Cyber Training, Readiness, Integration, Delivery and Enterprise Technology (Cyber TRIDENT) Task Order Two (2). The Cyber TRIDENT Indefinite Delivery/Indefinite Quantity (IDIQ) is utilized by Department of Defense (DoD) organizations and other non-DoD agencies that have related cyber training needs. The Cyber TRIDENT IDIQ provides the management, integration, maintenance, and evolution for the PCTE platform, and provides total system/subsystem acquisition life cycle support for the PCTE system baseline.

This Task Order Two (2) SOW defines the detailed requirements that PdM CRT requires to have performed under the Cyber TRIDENT IDIQ contract in support of the PCTE Integration Factory.

PM CT2 defines the Integration Factory the PCTE platform under Cyber TRIDENT Task Order Two (2) to include:

• Agile Event Execution

• 3rd Party Integration and Orchestration

• Development Operations (DevOps) Tools and Support

• Agile Reporting and Metrics

• User Feedback/Prioritization

• Release Planning

• Continuous Integration / Continuous Delivery (CI/CD) Pipeline

• Configuration Management

• Training Packages

1.1 Introduction

Task Order Two (2) will provide the necessary contractor support for the Integration Factory of the PCTE capabilities. This covers the integration activities across all PCTE capabilities development to include the conduct of agile events and ceremonies, release planning and management, configuration management, the incorporation and prioritization of user feedback, training package development and delivery, and the overall management of the CI/CD pipeline.

1.2 Goals and Objectives

The objective of Cyber TRIDENT Task Order Two (2) is to provide the Integration Factory for the evolving PCTE capabilities. Cyber TRIDENT Task Order Two (2) will specifically support the integration activities required to support the evolving PCTE capabilities utilizing an agile methodology for the development, testing, training and fielding efforts in compliance with all Army and DoD regulations and policies. The Task Order Two (2) Integration Factory will support PCTE in realizing their agile vision to provide a standardized platform with ecosystem of capabilities to shape, execute and reuse multiple training environments/scenarios.

2. APPLICABLE DOCUMENTS

The applicable documents listed in the Base SOW are applicable to Task Order 2. Reference Section 2 of the Base SOW for full list.

3. REQUIREMENTS

The contractor shall provide an Integration Factory support of the PCTE capabilities. The contractor shall deliver platform capabilities for integration, to include performing testing prior to fielding the platform. This will require such activities that include agile event execution, 3rd party integration and orchestration, DevOps tools and support, agile reporting and metrics, user feedback prioritization, release planning, CI/CD Pipeline management, configuration management, training packages and testing support to ensure compliance with contract requirements and timely delivery of required products. The contractor shall provide engineering, materials, equipment, testing, technical and operations support for the PCTE as described in this Task Order Two (2) SOW.

3.1 Program Management

The contractor shall provide the overall management and administrative effort necessary to ensure that the requirements of this Task Order Two (2) are accomplished. The contractor shall track Task Order (TO) progress, deliverables, and financials utilizing metrics specified by the Government.

3.1.1 Monthly Report

The contractor shall submit a Contractor’s Progress and Status Report that provides information to include but not limited to schedules, accomplishments, metrics, risks, issues, problems, and deficiencies related to this TO’s activities. The monthly report shall include, but not be limited to, status on the below requirements:

• Financial Data

• Agile Event Execution

• 3rd Party Integration and Orchestration

• Development Operations Tools and Support

• Agile Reporting and Metrics

• User Feedback/Prioritization

• Release Planning

• Continuous Integration/Continuous Development Pipeline

• Configuration Management

• Training Packages

• Testing Results

• Status of Risk Management Issues and Resolutions

CDRL Number CDRL Name CDRL A201 Contractor’s Progress and Status Report, DI-MGMT-81928

3.1.2 Associate Contractor Agreements (ACAs)

The contractor shall implement ACAs with other PCTE and third-party contractors as required for exchanging data, accessing and using third party software and equipment, receiving technical support, working interface and integration issues, and DoD Cyber user event planning and execution. The contractor shall ensure that ACAs are maintained to achieve development of the platform and maintain PCTE interoperability and event planning and execution, as applicable.

ACAs shall provide for and permit the complete and unbiased exchange of technical information and data relating to PCTE integration, development and deployment. Agreements shall be structured so that all Cyber TRIDENT and PCTE contractors are obligated to protect proprietary data and classified information from all unauthorized use or disclosure. ACAs shall be submitted to the Government for review prior to execution.

3.1.3 Schedule

The contractor shall plan, execute and deliver contributions within the Government agile scrum processes. The contractor shall align the schedule to trace to the Agile ceremonies and Industry best practices such as sprint duration, release planning, and other appropriate Agile planning processes. The contractor shall deliver in accordance with the government led monthly sprint periods resulting in incremental capability improvement/incorporation leading to six (6)-month formal releases.

3.1.4 Reserved.

3.1.5 Reserved.

3.1.6 Risk Management

The contractor shall promptly notify the Government of contract performance risks, issues, problems, and deficiencies and shall embed risk management as part of the Agile software development process. In accordance with the contractor’s risk management plan, implement risk detection and identification, assignment of risk categories, risk mitigation planning, mitigation plan implementation, corrective action, tracking of compliance, reporting of status and planning for risk abatement. The contractor shall promptly provide and execute corrective actions plans, in consultation with the Government. The contractor shall include in each Contractor’s Progress and Status Report the status of all outstanding contract performance risks, issues, problems, and deficiencies, as well as corrective actions with respect thereto.

3.1.7 Program Management Reviews (PMRs)

The contractor shall host Program TO Reviews quarterly (per year) to inform the Government of TO risks and issues. The contractor shall conduct Technical Interchange Meetings (TIMs) and In Progress Reviews (IPRs) as directed by the Government. The reviews shall provide a forum for IPT members to clarify the following areas of this TO to include but not limited to:

• Cybersecurity Management and Compliance

• IT Support

• Facilities

• Development RCS, Production RCS

• Logistics

The meetings shall be conducted at the contractor’s facility. PMR shall cover TO program risks and issues that can affect the entire Cyber TRIDENT portfolio, including parallel TOs/DOs-specific issues and risks as appropriate. The contractor shall post agendas and meeting minutes to established web portals or SharePoint sites.

CDRL A202 Report, Record of Meeting/Minutes, DI-ADMN-81505

3.1.8 Facilities

The contractor shall conduct the Government interactions to include the Agile ceremonies such as daily standups, sprint preplanning, and other associated meetings at the contractor’s facility which shall be located no more than ten (10) miles from PEO STRI.

3.1.9 Material Acquisition - Computer Hardware, Enterprise Software Solutions (CHESS) Program The contractor shall procure hardware, software, and licensing to support the TO 2 Integration Factory activities. TO 1 shall track, inventory, and maintain detailed information on procurements made under TO 2. The contractor shall comply with the Army’s CHESS program when making procurements. Under Program Executive Office Enterprise Information Systems (PEO EIS), CHESS is the mandatory source for commercial Information Technology (IT) purchases. CHESS contracts provide IT products and services that comply with U. S. Army Network Enterprise Technology Command (NETCOM), Army and DoD policy and standards.

Purchasers of commercial hardware and software must satisfy IT requirements by utilizing CHESS contracts and DoD Enterprise Software Initiative agreements first, regardless of dollar value. Any purchase made outside of CHESS contracts requires a waiver. A complete list of CHESS contracts and the on-line waiver process can be found at:

https://protectus.mimecast.com/s/yDPLCR6K3OIrGJ7iqywOR?domain=chess.army.mil https://protectus.mimecast.com/s/yDPLCR6K3OIrGJ7iqywOR?domain=chess.army.mil

3.2 Development Operations (DEVOPS) Process

3.2.1 Capability Development, Integration, Delivery and Sustainment

The contractor shall develop and execute the holistic Government led DevOps process for developing, integrating, testing, deploying, and sustaining the PCTE platform. The DevOps process shall cover the stages and feedback loop depicted in Figure 1, the DevOps Infinity. The DevOps process shall also include CMF feedback at each stage of the DevOps Infinity. The DevOps process shall create a culture that emphasizes the collaboration of PCTE vendors, operations, quality assurance, and cyber security teams throughout the PCTE platform lifecycle.

The DevOps processes shall allow teams to work together to optimize both the productivity of PCTE vendors and reliability of operations. The DevOps process shall allow teams to communicate frequently, increase efficiencies, and improve the quality of services provided to the CMF.

Figure 1 DevOps Infinity

The DevOps process shall encompass an Agile System Engineering process which includes but is not limited to concept development, requirements engineering, system architecture, system design and development, system integration, test/test engineering and evaluation, security engineering, and operations and maintenance. The Agile Systems Engineering process shall include Agile ceremonies to develop, refine, and prioritize requirements as well as plan and monitor the development, testing, integration, and deployment of the PCTE platform. The Agile Systems Engineering process shall include traditional Government ceremonies such as but not limited to Systems Requirement Review (SRR), Preliminary Design Review (PDR), Critical Design Review (CDR), Integration, Verification and Validation (IV&V), and Test Readiness Review (TRR). The Agile Systems Engineering process shall include a Configuration Management (CM) process to maintain the integrity of the components, services, products, assets, and content throughout the PCTE life cycle. The Agile System Engineering process shall include a process for releasing software to the CMF. The DevOps process shall include a feedback loop from the CMF that includes but is not limited to new features, enhancements, and bugs. The DevOps process shall also include a feedback loop from Technical Operations Staff that includes but is not limited to system performance issues, artifacts regarding bugs, recommendations for improving system performance, and recommendations for improving deployments.

To execute the DevOps process, the contractor shall provide an integration factory which includes but is not limited to a collaborative meeting space, development environment (i.e.

Remote, Compute, and Storage), and tools. The contractor shall onboard PCTE vendors to the development environment which includes but is not limited to account creation, access to infrastructure, access to tools, installing/configuring 3rd party hardware and software, and installing content. The development environment shall include CI/CD pipelines that automate the staged build, test, integration, release, and deployment of all PCTE vendor software and content.

3.2.2 Integration Factory

The contractor shall perform integration factory activities to include recommending improvements to the current integration factory development environment to increase the quality of the software and release frequency. The contractor shall maintain and enhance the current implementation of the development environment documented in the PCTE PDK. The development environment shall be remotely accessible to all PCTE team members at any time except for during maintenance windows. The development environment shall be remotely accessible from anywhere. The development environment shall include but not limited to the following zones: development, testing, quality assurance, staging, and production. The contractor shall be able to automate the creation of new zones when directed by the Government.

The zones shall provide sandboxes for the PCTE vendors that protect their intellectual property (IP). The contractor shall be able to automate the creation new sandboxes when onboarding new vendors, supporting canary releases, supporting operational tests, or whenever directed by the Government. The contractor shall automate the creation of the development environment, maintain it, and evolve it as directed by the Government. The development environment shall allow for the creation of CI/CD pipelines that automate the staged build, test, and integration of all PCTE vendor software and content described in section 3.2.3.2. The development environment shall be integrated with the integration factory tooling to support CI/CD activities.

The contractor shall document the development environment design using the integration factory tooling and in the PCTE PDK as directed by the Government. The contractor shall maintain and enhance the development environment as directed by Government.

The contractor shall recommend improvements to the current integration factory tooling to increase the quality of the software and release frequency. The contractor shall maintain and enhance the current integration factory tooling documented in the PCTE PDK as directed by the Government. The integration factory shall include but not be limited to the following tools:

• Requirements management tools

• Collaborative wiki

• Chat

• Video and audio teleconferencing tools

• Software version control tool

• Configuration management tools

• Software Artifact Repository

• Automation server

• License management tools

• Test case management tools

• Static code analysis tools

• Testing Tools (Supports the type of testing described in section 3.2.3.7)

• Security Tools (Supports security activities described in section 3.4)

The contractor shall develop a Continuity of Operations Plan (COOP) and implementation ensuring that critical integration factory functions continue when the development environment and/or tooling experiences issues. The contractor shall develop and implement a data backup and recovery plan in the event of a storage failure.

CDRL B201

Platform Development Kit (PDK), DI-MISC-80711A

3.2.3 Integration

The contractor shall manage, execute, and integrate products developed by current and future PCTE training capability vendors into a unified system of systems. The contractor shall integrate third party vendor contributions into an overall PCTE integration package to include documentation. The contractor shall package the comprehensive PCTE system in a manner that is rapidly deployable to PCTE RCS nodes to enable iterative assessment by CMF operators. The contractor shall manage, execute and support the acceptance modification and test of future capabilities into the PCTE platform. As a result of the PM’s release schedule and strategic vision, the contractor shall establish an integration schedule, strategy and environment that provides an online, interactive, and collaborative environment, which is protected with access control. The Government and contractor/subcontractor team members shall be able to exchange information and collaborate in a distributed environment. The contractor shall provide an integration schedule and strategy that addresses integrating all the work efforts identified as ready to be integrated into the PCTE production system. The contractor shall monitor the development process and work to ensure each vendor is aware of the scheduled updates into the existing system(s). The contractor shall manage the integration process and identify any issues or potential problems any vendors will have with other existing assets and identify what will be used as the baseline to build upon and which resources will be reused as part of the legacy assets.

The contractor shall provide documentation which describes each vendor will interface with the development system using Agile methodology. The contractor shall ensure each vendor provides updates to the documentation for each component of the system. The integration environment, shall be based on processes and standards construct that supports data and requirements management, stores collaborative artifacts, software, tools, PDK, and architecture products. The contractor's integration and testing processes shall ensure that new provided capabilities, handover packages, change sets, and bug fixes are fully implemented and satisfy their requirements and respective Use Cases without impacting existing capability prior to integration into the main PCTE baseline.

CDRL B202 System Integration Plan, DI-MISC-80711A

3.2.3.1 Third Party Onboarding and Orchestration

The contractor shall manage, execute and host as well as participate in third party vendors interaction and handover meetings. The contractor shall work with other industry partners and users of the system to identify and develop capabilities that support cross-developer interactions, and service-specific uses of system. The contractor shall monitor the system capabilities that are developed/integrated by third party vendors, and keep the Government informed on the progress of such efforts. The contractor shall provide the architectural, and engineering support required to support the third-party vendors in product deliveries. The contractor shall analyze proposed handovers for impact on the baseline configuration and provide recommendations for inclusion.

With Government concurrence, the contractor shall accept, modify, integrate, and test handover packages, new capabilities, change sets, and PTR/Discrepancy Report (DR) fixes from vendors following established processes. These capabilities shall become part of the formally managed software baseline

3.2.3.2 CI/CD Pipeline

The contractor shall leverage the integration factory tooling to design, implement, and support the execution of Continuous Integration (CI) pipelines for all PCTE vendor software and content in accordance with the contractor’s Agile system engineering process. The contractor shall implement CI pipelines that automate the staged build, test, and integration of PCTE vendor software and content. The contactor shall implement CI pipelines with the required stages to automate functional and nonfunctional gates to progress software and content across but not limited to Development, Test, Quality Assurance, Security, Scalability. The contractor shall implement CI pipelines that automate the promotion of software and content between stages via human in the loop or when automated testing passes.

The contractor shall extend the CI pipelines to form Continuous Delivery (CD) pipelines to deploy the software and content as well as release it in production. The contractor shall implement CD pipelines that rapidly and safely deploy and test software as well as content in a production-like environment and releases the software and content in production. The contractor shall implement stages in the pipelines that allow software and content to go through automated testing in a production-like environment. The contractor shall implement CD pipelines that allow the organization to make the decision on whether to release the software and content in production when the software passes automated testing. Using the CD pipelines, the contractor shall release new features to the CMF and ensure those releases are stable. The contractor shall continually monitor the PCTE platform’s health and security once the updates are deployed.

After deploying to production, if issues are encountered, the contractor shall execute automated procedures for rolling back to a healthy PCTE platform state.

The contractor shall provide the PCTE vendors a visualization of the execution status of their CI/CD pipelines. The contractor shall provide the Government a visualization of the execution status of all CI/CD pipelines. The contractor shall automate the reporting of issues that are discovered during the execution of each CI/CD pipeline to the PCTE vendors and Government.

The contractor shall maintain and resolve issues with visualization of CI/CD pipelines and automated issue reporting.

The contractor shall maintain and resolve issues with the CI/CD pipelines. The contractor shall collaborate with PCTE vendors to resolve vendor software and content issues that are discovered during the execution of all CI/CD pipelines as directed by the Government. The contractor shall Analyze production system performance and errors and collaborate with PCTE vendors to mitigate problems in the system design stage.

The contractor shall recommend improvements to the current CI/CD pipelines to increase the quality of the software and release frequency. The contractor shall maintain and enhance the current implementation of the CI/CD pipelines documented in the PCTE Platform Development Kit (PDK).

3.2.3.3 Agile Systems Engineering

The contractor shall manage, execute, and apply agile methodologies based on industry best practices for all PCTE development efforts. The contractor shall work with the Government, vendors, sub-contractors in identifying the necessary and sufficient fundamental concepts for the process to be agile. The contractor shall ensure all work is defined and planned using the agile sprint methodology, using a defined product backlog, sprint review and planning cycle with the goal of having a shippable product at the end of each sprint. The contractor's agile process shall achieve results through continuous iterative development of capability enhancements for the PCTE platform. The contractor shall provide a prompt response to emerging needs, demonstrated reliability, on reoccurring release cycles. The contractor shall plan, schedule, and execute all agile ceremonies, including sprint planning and review sessions, daily sprint standups, sprint retrospectives and sprint demonstrations. The contractor shall provide the requisite technical and programmatic support to complete the required tasks for each vendor associated with the PCTE engineering and management. These tasks shall encompass the efforts associated with the development, dissemination, engineering, management, and maintenance of the PCTE architecture, components, and documentation. These tasks shall also include the work efforts associated with the engineering, management, and tracking of PCTE fielded products, PCTE services and platform. The contractor shall identify an agile means of developing, integrating, testing and releasing the PCTE platform consisting of various contributions through an agile methodology facilitating CMF user feedback.

3.2.3.4 Agile Ceremonies

The contractor shall plan, schedule, lead, and facilitate all Agile ceremonies. The contractor shall recommend improvements to existing Agile process and ceremonies documented in the PCTE PDK to improve velocity, increase transparency of vendor progress, reduce meetings, and make best use of the participants time. The contractor shall recommend new agile methodologies or processes to increase efficiencies. The contractor shall execute the agile ceremonies in the collaborative environment described in section 3.2.2. The contractor shall execute the Agile ceremonies across all PCTE vendors and provide the Government with regular visibility into the status of PCTE platform development. The contractor shall manage the Product Backlog, as directed by the Government Product Owner. Product Backlog management includes but is not limited to creating, refining, removing and Prioritizing requirements. The contractor shall maintain configuration management over the Product Backlog and ensure that the state of the Product Backlog aligns with actual development such as but not limited to video and audio teleconferencing tools, requirements management tool, collaborative wiki, and chat. The contractor shall recommend agile metrics to provide the Government visibility into the status of the PCTE platform development and vendor performance. The contractor shall leverage the integration factory to capture and report agile metrics such as but not limited to burn down, burn up, velocity.

3.2.3.5 Requirements

The contractor shall manage, execute, and provide overarching support for the capabilities needed to support the PCTE program requirements for development, test, integration, interoperability, support, and delivery of software, data, and documentation to the Government.

The contractor shall evolve the PCTE architecture over time to address new requirements and to keep pace with the advancing technical environment through the system engineering process.

The contractor shall provide updates to the Platform Development Kit as well as update the Government on the capability enhancements to ensure new requirements for PCTE is continuously being developed and integrated into the baseline resulting in multiple version releases each year. The contractor shall record, maintain, analyze customer requirements, and user feedback, needed to continuously ensure maximum utilization of the system throughout the development.

3.2.3.6 Architecture

The contractor shall develop and execute governance processes, ceremonies, and use the integration factory tooling to develop PCTE system requirements and architecture in accordance with the contractor’s Agile system engineering process. The contractor shall develop processes, ceremonies, and use the integration factory tooling to govern the PCTE architecture including but not limited to implementing a system of controls over the creation and monitoring of all architectural components and activities, implementing a system to ensure compliance with internal and external standards, developing practices that ensure accountability to a clearly identified stakeholder community, both inside and outside the organization. The governance processes and ceremonies shall ensure that all updates to the PCTE Architecture are approved by the Government prior to implementation. The governance processes and ceremonies shall ensure the PCTE Architecture is highly cohesive, loosely coupled, and have severable components to have an open systems architecture capable of procuring at the component level. When developing the PCTE architecture, the contractor shall consider the entire lifecycle of the system including but not limited to development, maintenance and deployment. The governance processes and ceremonies shall ensure architecture is designed for extensibility, scalability, maintainability, availability, usability and security using an approach that is based on open system standards, products and patterns. The contractor shall define and record the PCTE operational concept for the system, architectural design of the system (identifying the components of the system, their interfaces, and a concept of execution among them), and the traceability between the system components and system requirements. The contractor shall research and evaluate the existing PCTE architecture documented in the PCTE PDK and recommend and implement modifications which enable the Government’s ability to continually integrate new vendor products. The contractor shall ensure the analysis and results of the governance processes and ceremonies are documented using the integration factory tooling and in the PCTE PDK as directed by Government. The contractor shall maintain and update the PCTE PDK which includes the PCTE architecture, platform integration points, and Government Owned Application Programming Interfaces (APIs). The contractor shall leverage and improve the existing PCTE Architecture Working Group (AWG) to implement governance processes.

The contractor shall use the Agile ceremonies to document and prioritize PCTE system requirements as directed by the Government Product Owner. The contractor is encouraged to suggest revisions to Government requirements where such revisions would result in cost or schedule reduction or performance improvements. The contractor shall evaluate the PCTE cybersecurity requirements to assess any impacts on developed capability and provide potential solutions, if applicable. In addition, the contractor shall determine if existing open source products are capable of meeting any operational capabilities, perform a detailed product reuse evaluation, and document the results of the analysis. The contractor shall conduct architecture evaluations, including stakeholders external to the contractor’s organization, for each iteration of PCTE. The contractor shall use the Enterprise Initiatives and technologies to evolve the PCTE architecture based on changes to technology, threat, and tactics, techniques and procedures.

The contractor shall support the PCTE PM Office as DoD Enterprise Initiatives are assessed to understand and define the impact to PCTE. The contractor, along with the Government staff, shall introduce stewardship and management of the Enterprise Initiatives policies and process.

The contractor shall use the Enterprise Initiative process to evolve changes based on technology, threat, and tactics, techniques and procedures. Enterprise Initiatives bring value to the organization as more lines of business participate thus ensuring the collaboration and participation across the entire enterprise drives system and component development. The contractor shall use Enterprise Initiatives as a means of incorporating new/updates to system components through analysis and registration, developing "rules of engagement" for collaboration, defining quality expectations and rules, monitoring and managing quality of the system, and changes to needs of the users through offerings and research.

3.2.3.7 Test

The contractor shall support the continuum of PCTE platform testing across the agile development lifecycle in accordance with Section 3.6.

3.2.3.8 Configuration Management (CM)

The contractor shall initially sustain and mature the current CM methodology to establish and maintain the integrity of the components, services, products, and assets throughout the PCTE life cycle. CM shall be implemented throughout the entire period of execution for all components, services, products, and assets of the PCTE system. CM shall be a proactive activity within the

PCTE system. CM shall identify, track, and document configuration items, control the configuration items and changes to them, and record and report status, and change activities to these configuration items. CM shall function as a multidimensional version of a typical CM process (multi-phased, multi-program, multi-tiered, multi-instantiated, and multi-baseline), binding the PCTE products and activities. CM shall support parallel development, distribution, and build releases. CM shall address use by all developers, products, and vendors.

The contractor’s CM efforts shall:

a) Identify the configuration items, components, and related work products that will be placed under configuration management

b) Establish and maintain a configuration management and change management system for controlling work products

c) Create or release baselines for internal use and for delivery to the customer

d) Track change requests for the configuration items

e) Control changes in the content of configuration items

f) Establish and maintain records describing configuration items, and

g) Perform configuration audits to maintain the integrity of the configuration baselines.

The PCTE CM shall synchronize with all of CM activities for products and product support within the PCTE system and provide an overarching CM method for all assets, artifacts, and processes. The contractor shall document the software handover process for all other PCTE vendors and shall utilize the CM infrastructure to manage these products. The contractor shall ensure a complete audit trail of decisions and design modifications made to systems, hardware, and/or software being developed, managed, or maintained are tracked and reported.

CDRL Number CDRL Name CDRL B203 Software Version Description (SVD), DI-IPSC-81442A

3.2.3.9 Release Management

The contractor shall manage the release management process by planning, scheduling, and controlling of an entire software build through every stage and environment involved, including test and deployment of software releases onto the production plane of the RCS. The contractor shall collaborate with each vendor and the Government by holding a Release Management Review (RMR) to include personnel responsible for the organization's infrastructure and architecture. The contractor shall ensure each vendor contribution meets the criteria governing the overall release effort. The contractor shall manage each release through the following steps:

1) Schedule release

2) Manage environment configurations

3) Identify production readiness

4) Support delivery teams

5) Govern the release

6) Report to the Government.

3.2.4 Metrics

The contractor shall develop, manage, execute and report on the metrics to inform the Government by enabling data driven decision making. The contractor shall leverage industry standard metrics to include Agile software development metrics to inform the Government. The contractor shall document these findings and provide the metrics as feedback to the Government to structure and effectively inform the development to result in an operationally effective platform needed to meet the desired end state and ensure all resources as noted in the PCTE Platform Development Kit in event plane, control plane databases, and logging/metrics data are collected as part of the performance metrics of the PCTE Platform.

3.3 Operations

In support of PCTE integration and development, the contractor shall support platform operations to ensure the latest capabilities have been disseminated and integrated, the user community is prepared to utilize them, and feedback/usage patterns are provided to the development team

3.3.1 Event and Exercise Support

The contractor shall participate alongside the Government in the coordination and management of user interviews, audits, and surveys in order to regularly capture user feedback. All feedback shall be made available to the government, and feedback that pertains to platform improvements shall be utilized to inform platform and infrastructure development and integration.

3.3.2 End User Outreach

The contractor shall engage end users of the platform as part of the DevOps process. The contractor shall use a collaborated approach to design and maintain a persistent interface that provide information about PCTE and enables end users to communicate information as needed throughout all phases of the DevOps process.

Customer initiatives may include, but are not limited to, the following:

• Working groups

• Existing capability focus groups / user juries

• Communication of new and upcoming features in PCTE

• Online asynchronous mechanism for submitting user feedback

• Publication of newsletters

• Publication and maintenance of glossaries

• Publication of Frequently Asked Questions (FAQ)

• Publication of best practices of event design within PCTE.

CDRL B205 Consolidated User Feedback Report, DI-MISC-80711A

3.3.3 Baseline Management

The contractor shall track, install, and document the PCTE baseline for management and administration by TO 1. The contractor shall ensure compatibility and interoperability needed to maintain high availability, performance, and security of the system as well as reusability of content generated for the platform. Additionally, the contractor shall track, install, and document the software baselines for PCTE applications deployed within the RCS nodes and virtual zones within each node in order to maintain a secure and up-to-date platform that serves the security and training needs of the end-users of each RCS node. The contractor shall maintain legacy baselines in order to maintain compatibility of the platform and to serve training needs of end users but shall ensure systems run a release version of PCTE.

The contractor shall manage the implementation of processes and procedures for testing, distribution, and incorporation installation of software updates and patches to the RCS nodes in a variety of security enclaves that include, but are not limited to, Unclassified, Secret and Top Secret/ Sensitive Compartmented Information (TS/SCI). Activities shall include physical delivery and software updates.

CDRL B204 Configuration Management Plan, DI-SESS-81875

3.4 Cybersecurity

The contractor shall implement a comprehensive methodology with respect to cybersecurity and CPCTE. The contractor shall implement cybersecurity at a number of classification levels and environments to include Closed, Restricted Networks (CRNs), Open Secret Internet Protocol (IP) Router (SIPRNET), Open Non-Classified IP Router (NIPRNET), and Top Secret/Sensitive Compartmented Information (SCI).

1. The contractor shall leverage the National Information Assurance Partnership (NIAP) and the Common Criteria Evaluation and Validation Scheme (CCEVS) to ensure Defense Information Systems Agency (DISA) approved software and hardware are utilized within the PCTE construct and PCTE supported components, services, and assets.

2. The contractor shall also ensure that the common components and services developed and maintained within Cyber TRIDENT are implemented in accordance with DISA STIG compliance. The contractor shall complete the DISA STIGs implementation for the IT technology developed and provide completed STIG checklists to document compliance.

3. The contractor shall develop and maintain a Cybersecurity/RMF process to guide management and design actions, document RMF decisions and certification efforts, specify and track RMF requirements, identify possible Cybersecurity solutions, synchronize RMF with CM activities, and maintain operational systems security.

4. The contractor shall support and participate in third party security assessments for the

PCTE accreditation, supporting infrastructure, and platform applications for security vulnerabilities and weaknesses. The contractor shall implement protective measures to address identified vulnerabilities and weaknesses.

5. The contractor shall continually evaluate the security of the system, both physical and logical, identifying exposures and providing protective options for reducing security risk.

The contractor shall deliver integration factory software releases to the system in a configuration that will pass a certification and will not negatively impact the existing accreditation.

6. The contractor shall implement protective measures to provide Information Security.

When Classified or Controlled information is introduced into the PCTE, the contractor shall adhere to the provisions within AR 380-5 regarding the classification, transmission, transportation, and safeguarding of this information. Cryptography shall be Federal Information Processing Standards (FIPS) 140-2 compliant. There shall be a mechanism established to ensure encrypted data can be recovered in the event the primary encryption system fails.

7. The contractor shall integrate protective mechanisms into the system and applications to provide identification and authentication, access control, accountability, availability, confidentiality, privacy, data integrity, and non-repudiation.

8. The contractor shall test and certify that application software is designed to function in a properly secured operating system environment and is free of elements that might be detrimental to the secure operation of the resource operating system, as described in National Institute of Standards and Technology Special Publication (NIST SP) 800-37.

9. The contractor shall use Government approved assessment tools to perform cyber security testing to document, verify, and validate each applicable operating system security configuration.

10. The contractor shall document the unincorporated security controls defined in the applicable STIG and unincorporated IA and Vulnerability Alerts (IAVA’s) in the Plan of Action and Milestones (POA&M) document.

3.4.1 Security Engineering

The contractor shall provide a process that emphasizes the collaboration of PCTE Vendors, Operations Team as well as Cyber Security Teams. The DevOps process shall emphasize cyber security teams collaborating with all teams to secure the PCTE platform throughout the lifecycle of the system. When engineering security solutions for the PCTE platform, the contractor shall assess the impact to the Authority to Operate (ATO). When engineering security solutions, the contractor shall consider the existing security solutions described in the PCTE PDK for efficiency and reuse potential.

The contractor shall implement and integrate a holistic approach to Information Security (IS) and data security that protects against unauthorized (accidental or intentional) disclosure, modification, or destruction.

1. The IS security shall consider the following:

a. All hardware and software functions, characteristics, and features

b. Operational procedures

c. Accountability procedures

d. Access controls, remote computers, and terminal facilities

e. Management constraints

2. The contractor shall provide an adequate level of protection for the IS and data contained in the IS. An adequate system ensures a security approach commensurate with the risk and magnitude of harm resulting from the loss, misuse, or unauthorized access to or modification of information.

3. The contractor shall maintain a centralized auditing function and consolidate audit activity as required by DODI 8500.2. The auditing function shall be centralized and have the functionality to view the events using a graphical user interface, sort and filter events, and generate reports. The centralized auditing function shall have the functionality to export events to a file for a specified period of time, while preserving the integrity of the file. The centralized auditing function shall have the functionality to import events from its own exported file format for a specified period of time, so that the file is viewable using the graphical user interface.

4. The contractor shall provide/perform backup and restore functions of IS operating systems, audit logs and software. The backup and restore functions shall be an enterprise-type backup management system that has the functionality to perform back up operations as needed for connected components from one central location and has the functionality to restore to its previous state in case of catastrophic failures.

5. The contractor shall provide/perform anti-virus protection functions for the IS. The Anti-virus shall be a DoD approved centralized software management system that has the functionality to update the anti-virus software and perform scans weekly.

6. The IS security and Cybersecurity approach shall include controls that are part of the day-to-day operations of the system, and are compliant with AR 25-2, DoDI 8500.01, DoDI 8510.01, CNSSI 1253, NIST SP 800-53, NIST SP 800-53A and DoDI 8582.01.

The contractor shall collaborate with PCTE Vendors and leverage the integration factory tooling to establish cyber security stages in the CI/CD pipelines for all vendor software and content that automate the identification of vulnerabilities. The stages shall perform the following activities including but not be limited to scanning for known unsecure dependencies, static analysis, and dynamic analysis. The contractor shall perform manual vulnerability analysis on the system when automated solutions do not exist. The contractor shall design and implement solutions using the integration factory tooling to continuously monitor the security of the PCTE platform.

When possible, the contractor shall automate the implementation of security controls.

3.4.2 Risk Management Framework (RMF)

The Contractor shall develop, maintain, and update for triennial reaccreditations of PCTE, and perform reaccreditation tasks at the time of recertification. The Contractor shall maintain the RMF documentation and participate in the necessary milestones to include, but not limited to, the System Registration Review (SRR), System Security Plan (SSP), System Contingency Plan (SCP), System Configuration Management Plan (SCMP), systems Plan of Action and Milestones (POA&M), Information Assurance Vulnerability Alert (IAVA) Reports, STIG Deviation Reports, STIG Checklists, Accreditation and Data Flow Boundaries, Software and Hardware Lists for each system configuration.

The Contractor shall ensure the system remains in a configuration compliant with the current type accreditation Authority to Operate (ATO) certification to the RMF Confidentiality, Integrity, and Availability (CIA) and Certification Level (CL) of all levels at moderate. The contractor shall recommend any ATO waivers or deviations to the PM through the Configuration Management process for Government approval. The Contractor shall coordinate with the Government to maintain the system accreditation by incorporating STIG compliance updates and mitigating the results of penetration testing into all software baseline release activities. The Contractor shall perform automated and manual IAVM scans per the latest STIG requirements and incorporate the updates into each subsystem/system software revision. In the event that Defense Information Systems Agency (DISA) cease support for the current, Information Assurance toolset (For example: Assured Compliance Assessment Solution (ACAS/Nessus and SCAP is required for Vulnerability Testing, and for Security Coding Tool),the Contractor shall migrate to an alternative toolset, an action that will be directed by the Government. This data shall be incorporated into the appropriate System POA&M in order to maintain the ATO. The Contractor shall fix or mitigate items from the POA&M. The Contractor shall incorporate IAVM updates for each system configuration into the system software development process, to include sub-systems, IAW the POA&M; IAVM updates shall be integrated into the fielded system software release quarterly at a minimum or in each software revision, whichever comes first IAW approved SSP and NETCOM TTP. The Contractor shall provide a schedule, for Government approval, for Information Assurance activities including system IA updates for insertion into System Software releases, the update cycle for quarterly STIG review, implementation, and compliance, mitigations, and any other pertinent IA activities IAW DI-

MISC-80508.

All…