Attachment_1_PWS_MCH_.docx

PERFORMANCE WORK STATEMENT

FOR

MAGTF COMMON HANDHELD

UNITED STATES MARINE CORPS

ACAT: IV-T

February 2018 Purchase Request: M67854-18-R-2023

Prepared by: Program Manager, Command and Control Systems (C2S) 2200 Lester Street Quantico, VA. 22134

DISTRIBUTION STATEMENT D: Distribution authorized to the Department of Defense and U.S. DoD contractors only (Reason: Administrative or Operational Use, Export Controlled) (Date of Determination: 27 October 2016). Other requests for this document are referred to Marine Corps Systems Command.

WARNING - This document contains technical data whose export is restricted by the Arms Export Control Act (Title 22, U.S.C., Sec 2751, et seq.), or the Export Administration Act of 1979, as amended, Title 50, U.S.C., App. 2401 et seq. Violations of these export laws are subject to severe criminal penalties. Disseminate in accordance with provisions of DoD Directive 5230.25.

DESTRUCTION NOTICE: Destroy by any method that shall prevent disclosure of contents or reconstruction of the document.

Table of Contents

List of Tables

List of Figures Figure 1 MCH Notional Acquisition Timeline 2

This Page Left Intentionally Blank

UNCLASSIFIED

iv

UNCLASSIFIED

Introduction The Marine Air Ground Task Force (MAGTF) Common Handheld (MCH) Performance Work Statement (PWS) has been developed to help establish a partnership between the United States Marine Corps (USMC) and the mobile computing industry through a phased and competitive acquisition approach. The USMC seeks to foster innovation while addressing a specific need for secure mobile computing at the battle space tactical edge. Commercial Solutions for Classified (CSfC) systems will provide the key enabler to meet Marines’ need for secure computing with a rapid paced technology evolution present in the commercial smart phone industry. Industry will provide a secure mobile computing platform, hereafter referred to as the MCH Integrated Platform, upon which the USMC can deploy a wide range of tactical applications providing fire support, command and control, situational awareness, and maneuver support capabilities for dismounted Marines.

Scope This PWS identifies tasking in support of Engineering and Manufacturing Development (EMD), fielding, and sustainment of the MCH Integrated Platform. The activities described in this PWS include program management, program protection, platform development, platform deliverables, testing, technical support and corrective action, technical data package development, and sustainment. The contract Period of Performance (PoP) will begin upon contract award and continue for 5 years consisting of a base year and four 12 month periods. The base year will be used to support the EMD phase, while the final 4 years will support Operational Testing (OT), fielding, and sustainment. The Indefinite Delivery/Indefinite Quantity (ID/IQ) contract form, along with the supporting Contract Line Item Numbers (CLINs), allows the Government to issue delivery orders for MCH Integrated Platform system components in quantities necessary to support each phase of the acquisition over the 5 year period.

Figure 1 depicts the Government’s notional acquisition timeline. Proposals should be drafted in conformance with Addendum 1 of the Request for Proposals (RFP). The Government will evaluate proposals as described in Addendum 2 of the RFP. In accordance with the RFP, three Gates and their related criteria will be used for this acquisition. Gates 1 and 2 will be used in a paper source selection to select the best proposals for award of a Firm Fixed Price ID/IQ contract. Delivery Order (DO) 1 will be issued to procure Sample EUDs, Wireless Access Points and other MCH Integrated Platform deliverables as identified in section 4.4, and data packages for the Government to evaluate and inform the Gate 3 down selection. The intent is for a single contractor to receive the remaining delivery orders. All Gates and the selection process are discussed in further detail in Addendum 2 of the RFP.

The Government planned delivery orders are described as follows. DO-01 will consist of Sample EUDs, Wireless Access Points and other MCH Integrated Platform deliverables as identified in section 4.4, and applicable data deliverables identified in Appendix A. DO-01 follows Gate 2 of the RFP and represents items required by the Government to perform Developmental Testing (DT), Risk Management Framework (RMF) processing, and CSfC registration submission. DO-02 follows the Gate 3 down select and will consist of Production EUDs and Wireless Access Points, and remaining data deliverables identified in Appendix A. DO-02 items are required to conduct OT and fielding. The intent is to use DO-03 through DO-06 to order Production EUDs and Wireless Access Points required to support fielding objectives in years 2 through 5 of the contract. DO-02 through DO-06 follow Gate 3 of the RFP. The Government may execute additional DOs as required to support EMD, OT, fielding, and life cycle sustainment.

Figure 1 MCH Notional Acquisition Timeline Background The MCH system will exhibit a modular, man-portable equipment suite that allows the warfighter to quickly acquire targets in day, night, and near all-weather visibility conditions; and control close air support (CAS) as well as artillery and Naval surface fire support missions. The MCH system will further serve as a digital information processing and display system that provides integrated, on-the-move secure, timely, and relevant Command and Control/Situational Awareness (C2/SA) information to tactical combat, combat support and combat service support commanders, leaders, and key C2 nodes using digital communications. The initial MCH system increment will be interoperable with the Joint Battle Command Platform (JBC-P) Family of Systems, the Joint Tactical COP Workstation, the Advanced Field Artillery Tactical Data System (AFATDS), The Target Handoff System (THS), and various other USMC MAGTF C2 and Close Air Support (CAS) platforms.

MCH Subsystems The MCH system requirements have been allocated to five subsystems to help align requirements to the Government’s acquisition strategy. This strategy leverages the contractor efforts defined by this PWS, software application development by Digital Precision Strike Suite (DPSS) China Lake, and subsystem integration by SPAWAR Systems Command Atlantic (SSC-LANT). The contractor will provide the MCH Integrated Platform, which is described in more detail in section 3.2 and section 4.4. DPSS China Lake is developing the EUD Application Subsystem software (reference section 3.1.2) which will reside on both EUDs (small and large form factor) and provide fires and C2/SA functionality. SSC-LANT will develop the Expeditionary Interface Subsystem (reference section 3.1.5) and mission planner (reference section 3.1.4), provide the final integration of all subsystems, and conduct provisioning of the complete system to support dismounted operations.

Sections 3.1.1 through 3.1.5 of this PWS further describe the anticipated subsystem composition necessary to meet the system requirements. The subsystem composition description is notional and should not be interpreted by the contractor as a prescription of any particular component solution beyond those constrained by the requirements. The contractor should utilize section 4.3 of this PWS to develop the actual solutions. Table 1 in section 4.3.2 and Table 2 in section 4.3.3 identify the performance requirements and design criteria along with the applicable subsystem designations, which the contractor should refer to when developing the MCH Integrated Platform solution.

EUD Platform Subsystem The EUD Platform Subsystem will consist of commercial EUDs, including both small and large form factors, the Android operating system and Android SDK, Original Manufacturer (OM) and tactical device drivers, security system including Data at Rest (DAR) and Data in Transit (DIT), MDM client, Application Programmer Interfaces (APIs), and accessories.

EUD Application Subsystem The EUD Application Subsystem will consist of application services, extensions, clients, and an application SDK to support third party development.

Server Subsystem The Server Subsystem will consist of mobile management / security components.

Peripheral Subsystem The Peripheral Subsystem will consist of the wireless access point and the mission planner.

Expeditionary Interface Subsystem The Expeditionary Interface Subsystem will consist of interconnects and small distribution components such as hubs required to connect EUD(s) worn or carried in support of dismount operations.

MCH Integrated Platform The MCH Integrated Platform includes the EUD Platform Subsystem, the Server Subsystem, and the wireless access point from the Peripheral Subsystem. Section 4.4 identifies the specific MCH Integrated Platform deliverables the contractor is expected to provide including Sample EUDs and Wireless Access Points, Production EUDs and Wireless Access Points, Accessories, SDK, Secure Host Baseline, and Software Licenses.

MCH Operating Constraints Natural Environments The MCH System will operate in expeditionary environments including hot, basic, and cold climates, during day and night, and in all weather conditions. The MCH PSPEC has identified specific environmental and power requirements pursuant to this constraint. Refer to Table 1 in section 4.3.2 for MCH PSPEC paragraph references.

Threat Environments The MCH system will be exposed to Information Operations (IO) threats including Computer Network Attacks (CNAs), Computer Network Exploitation (CNE), Electronic Warfare (EW), Foreign Influence Operations (FIO), Denial and Deception (D&D), and Directed Energy Weapons (DEWs). The MCH PSPEC has identified specific security and Information Assurance (IA) requirements to mitigate elements of these threats. Additionally, Section 4.2 of this PWS identifies program protection requirements. Refer to Table 1 in section 4.3.2 for MCH PSPEC paragraph references.

Transportation and Storage The MCH system will be transported between, and stored at military facilities, submarines, ships, vessels and aircraft. The MCH system will be transported in both military and commercial modes of transportation. The MCH PSPEC has identified requirements for packaging, storage, transit, and battery safety. Refer to Table 1 in section 4.3.2 for MCH PSPEC paragraph references.

Infrastructure Support Limitations The MCH system will be employed in a tactical environment with limited network infrastructure. MCH PSPEC requirements and design criteria have been established to include radio interoperability in support of the tactical requirement. Refer to Table 1 in section 4.3.2 for MCH PSPEC paragraph references, and Table 2 in section 4.3.3 for MCH design criteria.

Operational Manning Limitations Each MCH EUD will be operated by a single dismounted Marine operating at the tactical edge of the battle space. Management functions of the MCH system, such as mobile device management, security administration, and mission planning will be executed by system administrators.

Other Design Constraints Refer to Table 2 in section 4.3.3 of this PWS for additional design criteria.

MCH Vision The MCH Integrated Platform supports the USMC vision to acquire a unified mobile computing architecture upon which dismounted capability is delivered. Further, the vision includes the migration of existing capability from diverse “stove pipe” platforms to the MCH common commercial handhelds. CSfC accreditation will provide the means to acquire and maintain the Authority to Operate (ATO) while staying up to date with fast pace technology improvements in the commercial industry.

Performance Requirements The contractor is responsible for identifying, selecting, and integrating mobile computing components into the MCH Integrated Platform, which meet threshold requirements of the MCH PSPEC, and for providing these platform components in quantity to meet Government orders under the associated CLINs. Additionally, the contractor is responsible for program protection implementation; and testing and data package development to support CSfC registration, Government RMF processes and lifecycle sustainment.

Program Management Management The contractor shall establish and maintain program management practices throughout the PoP. Program management practices shall provide visibility into the contractor’s organization and techniques used in managing the program. Documentation identified in this PWS shall be readily available to Government representatives during planned visits.

Staff Expertise The contractor shall provide Subject Matter Experts (SMEs) that possess expertise in software management, software and hardware integration, cybersecurity, CSfC compliance and registration, DoD RMF, Security Technical Implementation Guide (STIG) / Security Requirements Guide (SRG) implementation, vulnerability assessment and benchmarking, DAR and DIT security techniques, MDM selection and scaling, interfacing tactical devices to Android based EUDs via secured wireless and tethered connections, and Android custom ROM development. Additionally, the contractor shall possess expertise with DoD, Department of the Navy (DoN), and USMC acquisition policies and procedures to include program management processes, systems engineering, configuration management, risk management, quality management practices, program protection, and lifecycle sustainment.

Configuration Management Contractor’s Configuration Management The contractor shall maintain configuration management (CM) for the control of all hardware and software configuration documentation, media and parts. The principles contained in EIA-649 and MIL-HDBK-61A may be used for guidance. The contractor's CM process shall consist of configuration identification, configuration control, configuration status accounting, and configuration audits. Consideration for interfacing with other acquisition requirements, such as design review, assurance, and other program related disciplines, shall be addressed. The contractor’s CM process shall align with the Program Manager’s (C2S) CM Plan.

Configuration Management Plan The contractor shall provide a CM Plan detailing the contractor’s plans for identifying, defining, and baselining configuration items (CI), controlling modifications and releases of CIs, reporting and recording status of CIs and any requested modifications, ensuring completeness, consistency, and correctness of CIs, and controlling storage, handling, and delivery of the CIs.

· CDRL B003, DI-CMAN-80858B, Configuration Management Plan Risk Management The contractor shall conduct risk management of cost, schedule, and performance. Risk management shall include identification, assessment, monitoring and control of risks during performance of the contract. Risks and mitigation steps shall be reported in the Monthly Status Report (MSR).

· CDRL B001, DI-MGMT-80368A, Status Report Quality Management The contractor shall implement and maintain a quality assurance program. The contractor’s established internal quality assurance control and inspection procedures shall be made available for Government review.

Meetings, Management Reviews, and Reporting Technical Interchange Meetings Technical Interchange Meetings (TIMs) will occur as needed throughout the contract PoP. Exact dates and locations will be defined by the Government. The contractor shall provide SMEs to support TIMs as requested by the Government.

Management Reviews Management reviews will occur as needed throughout the contract PoP. Exact dates and locations will be defined by the Government. The contractor shall provide personnel to support management reviews as requested by the Government. The contractor should be prepared to address all risks and issues affecting cost, schedule, and performance.

Status Reports The contractor shall provide written MSRs that include a summary of accomplishments for the reporting period, planned tasks for the next ninety days, percentage of project completed, expenditures to date and projected expenditures, key programmatic risks and mitigation steps, summary of deliverables provided, schedule status and changes, concerns or issues affecting the cost, schedule, and performance, and any other information identified within this PWS as reportable in the MSR.

· CDRL B001, DI-MGMT-80368A, Status Report Program Protection Contractor’s Program Protection Program Protection Implementation Plan (Preliminary) The contractor shall develop a preliminary Program Protection Implementation Plan (PPIP) using guidance from DAG Chapter 13, counterfeit protection provisions of section 4.2.2, and MCH program protection data. The MCH program protection data will be supplied by the government After Contract Award (ACA). The preliminary PPIP will support the EMD phase of the acquisition. The preliminary PPIP shall include program protection plans for contractor and sub-contractor products and processes in the supply chain, development and test environments, and operational environments. The PPIP shall include plans for Critical Program Information (CPI) and Critical Component (CC) identification, analysis, and protection; threat analysis, vulnerability assessment, and countermeasures implementation.

· CDRL B002, DI-MGMT-81826C (Tailored), Program Protection Implementation Plan Preliminary PPIP Government Review The contractor shall submit the preliminary PPIP within 120 days After Delivery of Contract (A DC). The Government will review the contractor’s preliminary PPIP and provide comments for incorporation into the plan.

Program Protection Implementation The Government Contracting Officer’s Representative (COR) will notify the contractor of Government acceptance of the contractor’s preliminary PPIP at which time the contractor shall begin implementation, incorporating protections into their products and processes.

Program Protection Reporting The contractor shall ensure that updated assumptions, rationale, and results related to program protection are included in MSRs, made available for Government review at each TIM and management review, and are incorporated into updates of the PPIP. Program protection reporting shall include information developed from the counterfeit protection reporting provisions in section 4.2.2.2.

· CDRL B001, DI-MGMT-80368A, Status Report

· CDRL B002, DI-MGMT-81826C (Tailored), Program Protection Implementation Plan Program Protection Implementation Plan (Final) The contractor shall complete a final PPIP using the authorized MCH Program Protection Plan, which will be supplied by the government after gate 3. The final PPIP will support the OT, fielding, and sustainment phase of the acquisition.

· CDRL B002, DI-MGMT-81826C (Tailored), Program Protection Implementation Plan Counterfeit Protection Preventing Counterfeit Material The contractor shall plan and implement counterfeit protection as part of the contractor’s program protection IAW section 4.2.1. Documentation supporting counterfeit protection shall be included in the contractor’s PPIP. Counterfeit protections shall include the actions identified below at a minimum. The contractor:

i. shall maximize availability of authentic, originally designed and/or qualified parts throughout the product's lifecycle, including management of parts obsolescence;

ii. Shall assess potential suppliers to minimize the risk of receiving counterfeit material;

iii. Shall maintain a listing of approved suppliers with documented criteria for approval and removal of suppliers from the list;

iv. Shall have purchasing procedures which require the selection of parts and material from OM or authorized suppliers whenever possible;

v. Shall require a certificate of compliance and supply chain traceability for all material purchases;

vi. Shall use Government or industry services such as Government-Industry Data Exchange Program (GIDEP) and other commercially available services to identify part or supplier quality or authenticity problems;

vii. Shall define minimum inspection and test requirements for material being procured from unauthorized suppliers, and shall ensure that in-house, third-party, and/or distributor inspection and test procedures and facilities comply with these requirements;

viii. Shall incorporate procurement clauses which plainly identify quality requirements and liability to all approved suppliers; and

ix. Shall flow the requirements above to affected Subcontractors. SAE AS6174 contains information regarding the detection, avoidance, and mitigation of counterfeit material, and may be used as a reference document for meeting the above steps.

· CDRL B002, DI-MGMT-81826C (Tailored), Program Protection Implementation Plan Counterfeit Parts and Materials Reporting The prime contractor and Program Office shall be notified of the occurrence of a suspect or confirmed counterfeit part or material, and the actions taken to identify, contain, and impound all product from the lot. The contractor shall also contact the OM, and supplier if applicable. The contractor shall initiate and submit an ALERT to the GIDEP within 60 days of knowledge of the counterfeit part or material. The contractor shall notify the appropriate parties to document the case for legal action if required (e.g., contracting officer, DOD Office of Inspector General).

Counterfeit Control The contractor warrants that the goods delivered pursuant to this Contract shall

i. be and only contain materials obtained directly from the OM or an authorized OM reseller or distributor;

ii. not be or contain Counterfeit Items, as defined below; and

iii. contain only authentic, unaltered OM labels and other markings.

The contractor shall obtain and retain all documentation required to fully trace the distribution and sale of the goods delivered hereunder back to the relevant OM, and shall include such authenticating documentation within the contractor’s PPIP.

· CDRL B002, DI-MGMT-81826C (Tailored), Program Protection Implementation Plan Counterfeit Items include, but are not limited to, goods or separately-identifiable items or components of goods that:

i. are an illegal or unauthorized copy or substitute of an OM item;

ii. are not traceable to an OM sufficient to ensure authenticity in OM design and manufacture;

iii. do not contain proper external or internal materials or components required by the OM or are not constructed in accordance with OM design;

iv. have been re-worked, re-marked, re-labeled, repaired, refurbished, or otherwise modified from OM design but not disclosed as such or are represented as OM authentic or new;

v. have not passed successfully all OM required testing, verification, screening, and quality control processes; or

vi. an item with altered or disguised documentation, package labeling, or item marking intended to mislead a person into believing a non-OM item is genuine, or that an item is of better or different performance when it is not.

The contractor further warrants that it has and shall have an internal Counterfeit Item control process for goods delivered hereunder in accordance with the standards or instructions set forth in any Buyer's specifications, including but not limited to specifications, or other provisions incorporated into this Contract. Buyer shall have the right to audit, inspect, and / or approve the processes at any time before or after delivery of the goods ordered hereunder. Buyer shall have the right to require changes to the processes to conform to Buyer's defined standards, if any. Failure of the Seller to conform its processes to Buyer's defined standards may result in the termination of this Contract in accordance with the termination provisions set forth herein. Seller shall include this clause in any agreement between Seller and its lower tier sellers.

Platform Development Design The contractor shall design MCH Integrated Platforms leveraging existing Commercial off the Shelf (COTS) components where possible. The contractor’s MCH Integrated Platform solution shall be composed of approved components which collectively meet the requirements of CSfC CPs selected within the design. Refer to section 4.3.1.3 for CSfC registration documentation required with the initial platform deliveries and section 4.7 in its entirety for complete Technical Data Package (TDP) requirements.

CSfC Trusted Integrator The contractor shall ensure integration activities pursuant to all CSfC related tasks are executed by an approved integrator listed on the National Security Agency’s (NSA’s) CSfC trusted integrator list. The contractor’s facilities and process capabilities shall be in compliance with all CSfC requirements necessary to obtain system registration.

CSfC Listed Components The contractor shall ensure that each component selected to be included in the MCH Integrated Platform solution has a National Information Assurance Partnership (NIAP) certification that allows it to be registered for inclusion as an approved component on the NSA CSfC component list. In the case that a non-listed component is selected for inclusion, refer to section 4.3.1.4.

CSfC Registration Documentation The contractor shall provide CP documentation for all CPs included in the MCH Integrated Platform design IAW the NSA requirements for registration processing. Additionally, the contractor shall provide a solution diagram depicting the CSfC solution boundary, hardware and software components, interconnects, and data flow. Guidance for development of the CSfC documentation and a list of approved CPs can be found at the link below.

Reference: https://www.nsa.gov/resources/everyone/csfc/capability-packages/

· CDRL A007, DI-IPSC-81430, CSfC Solution Diagram

· CDRL A00A, NSA Format, CSfC Capability Package Binder CSfC Capability Package Deviations The contractor shall identify, document, and inform the Government of all instances where the contractor intends to deviate from any CP requirement, including when a deviation is deemed necessary to meet other requirements. In such cases, the contractor shall draft deviation requests and submit them with the CSfC capability package registration binder IAW section 4.3.1.3. Deviation requests shall include a justification for deviating from the CP with a mitigation strategy and timeline for aligning the solution to the existing CP requirements. The contractor shall report all existing and anticipated deviations in the MSRs and at each TIM and management review.

· CDRL B001, DI-MGMT-80368A, Status Report

· CDRL A00A, NSA Format, CSfC Capability Package Binder Performance Requirements The contractor’s MCH Integrated Platform solution shall meet, at a minimum, threshold MCH System PSPEC requirements and threshold revised requirements as identified in Table 1. Revised requirements supersede MCH System PSPEC requirements IAW Table 1. Note that the “Effectivity” column in Table 1 indicates whether all or some portion of the PSPEC requirements is applicable or, if marked Not Applicable (N/A), is not to be implemented by the contractor, but is provided for contextual purposes to assist the contractor with interface implementation. Note that the “Subsystem(s)” column in Table 1 indicates the Subsystem that the PSPEC allocated requirements apply to, or if marked “System” indicate that requirements have not been allocated to a specific Subsystem.

Table 1 MCH Performance Requirements

Design Criteria The contractor’s MCH Integrated Platform solution shall incorporate the design criteria identified in Table 2, Table 3, and Table 4 into the MCH Integrated Platform design.

Table 2 MCH System Design Criteria

Table 3 Examples of Bloatware To Be Excluded Bloatware

OM maintenance apps

Table 4 MCH Firmware Device Drivers Driver

PL2303, FTDI & CP210X

RNDIS_HOST & CDC ECM

ASIX (V4.13 or newer) & CDC EEM

ACM

CDC-ACM.KO

FTDI_SIO.KO

PPP_ASYNC.KO

PPP_SYNCTTY.KO

Cybersecurity The contractor shall perform all tasks in this section, except 4.3.4.3, to establish the initial Cybersecurity Baseline. The initial Cybersecurity Baseline is represented in the security hardened sample MCH Integrated Platforms and the related cybersecurity documentation IAW sections 4.3.4.1, 4.3.4.2, and 4.3.4.4. Cybersecurity updates, which include all tasking and deliverables in this section including section 4.3.4.3, shall be provided by the contractor every 30 days starting after gate 3 and continuing for the remainder of the PoP or final delivery under the last order is accepted, whichever is later. In the event a critical vulnerability is discovered, after gate 3, the contractor shall complete all tasks in this section and deliver the critical update within 15 days from discovery of the critical vulnerability.

Cybersecurity Policy The contractor shall perform cybersecurity tasks in accordance with the latest releases or revisions of the following policies:

· MCO 5239.2B, Marine Corps Cybersecurity, dated 05 Nov 2015

· DOD Instruction (DODI) 8500.01, Cybersecurity, dated 14 Mar 2014

· SECNAVINST 5239.3B, DoN Information Assurance (IA) Policy, dated 17 Jun 2009

· United States Marine Corps Enterprise Cybersecurity Manual (ECSM) 018 Marine Corps Assessment and Authorization Process (MCAAP) dated 28 July 2017 Cybersecurity System Hardening, Vulnerability and Assessment The contractor shall use DISA STIGs/SRGs in all software development, integration, and sustainment activities, adapting software to function in a hardened cybersecurity environment. The contractor shall utilize the DISA Assured Compliance Assessment Solution (ACAS) and DISA Security Content Automation Protocol (SCAP) tools to assist with vulnerability scanning, assessment, and benchmarking the security posture of the MCH Integrated Platform. The MCH cybersecurity control application comes from CNSSI 1253, Security Categorization and Control Selection for National Security Systems and NIST SP 800-53.

The MCH system categorization is:

· Confidentiality=High

· Integrity=High

· Availability=Medium

· Classified overlay

· Moderate privacy overlay

Reference: https://rmfks.osd.mil/rmf/Pages/default.aspx.

Contractor’s Cybersecurity Representations The contractor warrants that any hardware, software and firmware goods delivered under this Contract:

i. shall not contain any viruses, malicious code, Trojan horse, worm, time bomb, self-help code, back door, or other software code or routine designed to: (a) damage, destroy or alter any software or hardware; (b) reveal, damage, destroy, or alter any data; (c) disable any computer program automatically; or (d) permit unauthorized access to any software or hardware;

ii. shall not contain any third party software (including software that may be considered free software or open source software) that (a) may require any software to be published, accessed or otherwise made available without the consent of Buyer, or (b) may require distribution, copying or modification of any software free of charge; and

iii. shall not infringe any patent, copyright, trademark, or other proprietary right of any third party or misappropriate any trade secret of any third party.

Cybersecurity Patches The contractor shall provide cybersecurity patches, which include installation instructions. Each delivery shall be accompanied by a SVD (reference section 4.7.5). The contractor is not responsible for installing patches to MCH Integrated Platforms, which have been delivered to the Government. However, the contractor shall ensure that the latest security patches are incorporated into MCH Integrated Platforms prior to delivery to the Government.

· CDRL A005, DI-IPSC-81442A, Software Version Description Cybersecurity Documentation The contractor shall provide technical data supporting the Government’s RMF process. The cybersecurity documentation shall include STIG/SRG and SCAP benchmarks (RMF Artifacts), and a Security Assessment Report. Cybersecurity documentation shall contain data which is no older than 30 days from date of submission.

· CDRL A008, DI-MGMT-82000 (Tailored), RMF Artifacts

· CDRL A009, DI-MGMT-82135 (Tailored), Security Assessment Report Safety Assessment The contractor shall conduct a safety assessment of the MCH Integrated Platform and document the results in a Safety Assessment Report (SAR) IAW Task 301 of MIL-STD-882E. The SAR shall address safety concerns for government DT, OT, and fielding.

· CDRL A00F, DI-SAFT-80102, Safety Assessment Report Integrated Platform Deliverables MCH Integrated Platform deliverables, which are necessary to support Government conducted DT, OT, and fielding, are identified in this section. Government DT is planned for year one of the contract (DO-01), with OT to follow (DO-02). Fielding is planned for years two through five in accordance with planned orders DO-03 through DO-06. The maximum value of the contract will determine ceiling quantities. Unless specified otherwise in a referenced CDRL or the delivery order itself, Integrated Platform deliverables identified in this section and specified in DO-01 shall be provided to the Government 90 days After Delivery of Contract (ADC).

Sample EUDs and Wireless Access Points The contractor shall provide sample EUDS (small and large form factor), and Wireless Access Points, which have been developed IAW section 4.3 and tested IAW sections 4.5.1, and 4.5.2. Sample units shall have the initial cybersecurity baseline incorporated IAW section 4.3.4. Sample units will be used by the Government to support DT in year one of the contract.

Production EUDs and Wireless Access Points The contractor shall provide production EUDS (small and large form factor), and Wireless Access Points, which have been developed IAW section 4.3 and tested IAW section 4.5.1. Production units shall have the latest cybersecurity updates incorporated IAW section 4.3.4. Production units will be used by the Government to support OT in year one of the contract and fielding in years two through five.

Reserved Software Development Kit The contractor shall provide a MCH Integrated Platform Software Development Kit (SDK) including the software tools and documentation necessary to support application developer access to system functionality and data while maintaining security solution protections in accordance with established DoD and Industry Standard Software Assurance practices. Each delivery shall be accompanied by a SVD (reference section 4.7.5).

· CDRL A005, DI-IPSC-81442A, Software Version Description Secure Host Baseline The contractor shall provide a Secure Host Baseline for the EUD / Wireless Access Point hosted components and a separate Secure Host Baseline for the Mobile Management / Security server hosted components. The Secure Host Baseline for the EUD / Wireless Access Point hosted components shall include instructions to support Government imaging of EUD and Wireless Access Point components. The Secure Host Baseline for the Mobile Management / Security server hosted components shall include instructions to support Government server installation. The contractor shall ensure that all Secure Host Baseline images have been developed IAW section 4.3, and include the latest cybersecurity updates IAW section 4.3.4. Each delivery shall be accompanied by a SVD (reference section 4.7.5). Refer to https://www.disa.mil for further definition of the Secure Host Baseline.

· CDRL A005, DI-IPSC-81442A, Software Version Description Software License The contractor shall provide software licenses to the Government, which allow the Government to use software from the prime and third party providers whose software is included as a component in any deliverable under the contract. As necessary the contactor shall ensure that software licenses are transferrable to the Government. The contractor shall provide information regarding licensing alternatives. The Government will review and make a determination for licensing in accordance with the Government concept of employment. The contractor shall provide a Certificate of Compliance, which provides certification that MCH Integrated Platform components are in full compliance with all contract requirements including vendor license requirements. The contractor shall provide a Software License Requirements List, which describes all license requirements, including requirements for renewal and maintenance.

· CDRL D008, DI-MISC-81356A, Certificate of Compliance

· CDRL D009, DI-PSSS-82046, Software License Requirements List Testing Factory Acceptance Testing The contractor shall perform factory acceptance testing of each MCH Integrated Platform at the contractor’s facilities prior to delivery to the Government. At a minimum the acceptance testing shall ensure components are correctly imaged with a Government approved image at a static patch level, systems are free from physical defects, systems are complete including all components and accessories specified in the bill of materials, all system batteries are fully charged, and components pass a power on self-test and are ready for end user configuration. Government representatives may witness the acceptance test procedure for each system by the contractor at the contractor’s facility. The Government reserves the right to approve or disapprove each system for shipment based upon the test results witnessed at the contractor’s facility. Final acceptance of each system shall be performed at destination. The contractor shall provide test plans, procedures, and reports detailing the planning and execution of the contractor’s factory acceptance test program. Acceptance test reports shall be provided with each system or lot upon delivery to the Government.

CSfC Capability Package Testing The contractor shall plan and conduct CSfC capability package testing IAW the contractor selected CSfC capability packages and NIAP protection profiles at the contractor’s facilities. Separate CSfC test documentation shall be provided by the contractor for each adopted capability package to support the CSfC registration submittal IAW section 4.3.1.3.

Technical Support and Corrective Action Technical Support The contractor shall provide technical assistance to the Government labs, including SSC-LANT, Marine Corps Tactical Systems Support Activity (MCTSSA), and DPSS China Lake; and external developers and integrators, as determined by the MCH Program Office. Technical assistance encompasses providing subject matter expertise for both the technical and operational aspects of the MCH Integrated Platform. This support is required during development, integration, and testing efforts starting after DO-01 and ending upon the Government fielding determination. Support may be required via teleconference, electronic communications, and/or on-site as determined by the Program Office.

Corrective Action After delivery of sample MCH Integrated Platforms the Government will conduct DT, and generate Test Incident Reports (TIRs) as needed. The TIR is a report which identifies conditions and capability reduction due to system errors or anomalies. The TIR will provide a description of the incident, the capability with which the incident interfered, the necessary steps to reproduce the condition, and any work arounds that were discovered.

Test Incident Report Evaluation TIRs will be provided to the contractor by the Government within 30 days after completion of DT. Upon receipt of TIRs the contractor shall evaluate all TIRs and provide a technical report to the Government within 30 days.

· CDRL A00E, DI-MISC-80508B, Technical Report-Study/Services

The technical report will include, at a minimum, the items listed below.

For each TIR, provide concurrence that there is an actual defect or, if not, provide a rationale explaining why there is no defect.

For each TIR where there is a defect, generate a Defect Report (DR) which identifies the impacted system components, the proposed fix, and the version of the hardware and software in which the fix will be implemented. The DR shall be included in the technical report.

For each DR, provide a list of impacts to the TDP, including CSfC accreditation and RMF.

Provide a list of DR fixes which are recommended to be incorporated in the next revision of the system. For Government selected DR fixes, complete technical data or software related to the fix shall be delivered to the Government.

Corrective Action Implementation The Government will review and approve or disapprove DRs for implementation and provide its determination to the contractor within 30 days after receipt of the…