Attachment_1_PWS_MCH_Amendment_0005.pdf

UNCLASSIFIED

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 (Administrative or Operational Use, Export Controlled) (27 October 2016). Other requests shall be referred to Commander, Marine Corps Systems Command, Attn: CES, 2200 Lester Street, Quantico, VA 22134- 6050.

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, (Title 50, U.S.C., App. 2401 et seq), as amended. Violations of these export laws are subject to severe criminal penalties. Disseminate in accordance with provisions of DoD Directive 5230.25.

ii

DESTRUCTION NOTICE: Controlled Unclassified Information (CUI) may be destroyed by any of the means approved for the destruction of classified information or by any other means that would make it difficult to recognize or reconstruct the information. For classified National Security Information (NSI), destroy in accordance with DoDM 5200.01, V3, or DoDM 5220-22.

Table of Contents

1 Introduction

2 Scope

3 Background

MCH Subsystems

3.1.1 EUD Platform Subsystem

3.1.2 EUD Application Subsystem

3.1.3 Server Subsystem

3.1.4 Peripheral Subsystem

3.1.5 Expeditionary Interface Subsystem

MCH Integrated Platform

MCH Operating Constraints

3.3.1 Natural Environments

3.3.2 Threat Environments

3.3.3 Transportation and Storage

3.3.4 Infrastructure Support Limitations

3.3.5 Operational Manning Limitations

3.3.6 Other Design Constraints

MCH Vision

4 Performance Requirements

Program Management

4.1.1 Management

4.1.2 Staff Expertise

4.1.3 Configuration Management

4.1.4 Risk Management

4.1.5 Quality Management

4.1.6 Meetings, Management Reviews, and Reporting

iii

Program Protection

4.2.1 Contractor’s Program Protection

4.2.2 Counterfeit Protection

Platform Development

4.3.1 Design

4.3.2 Performance Requirements

4.3.3 Design Criteria

4.3.4 Cybersecurity

4.3.5 Safety Assessment

Integrated Platform Deliverables

4.4.1 Sample EUDs and Wireless Access Points

4.4.2 Production EUDs and Wireless Access Points

4.4.3 Reserved

4.4.4 Software Development Kit

4.4.5 Secure Host Baseline

4.4.6 Software License

Testing

4.5.1 Factory Acceptance Testing

4.5.2 CSfC Capability Package Testing

Technical Support and Corrective Action

4.6.1 Technical Support

4.6.2 Corrective Action

Technical Data Package Development

4.7.1 System Users Guide

4.7.2 System Security Administrator Operators Document

4.7.3 Interface Control Document

4.7.4 System Design Description

4.7.5 Software Version Description

4.7.6 Product Level Drawing Package

4.7.7 Reserved

Sustainment iv

4.8.1 Component Management

4.8.2 Logistics Product Data

4.8.3 Warranty

5 Contract Administration

Partnering Agreements

Facility Security Requirements

Common Access Card Requirement

5.3.1 Contractor FSO

5.3.2 Email

5.3.3 COR authorization

5.3.4 CAC Eligibility

Contractor Personnel Requirements

5.4.1 Contractor Identification

5.4.2 Contractor Email Correspondence

5.4.3 National Industry Security Policy

5.4.4 USMC Security Policy

Non-Disclosure Agreements

Post Award Orientation (Kickoff)

Enterprise-Wide Contractor Manpower Reporting Application (ECMRA)

5.7.1 Data Entry

5.7.2 Reporting Period

5.7.3 Help Desk

6 Facilities, Other Direct Costs (ODCs), and Travel Requirements

Facilities

Travel

6.2.1 Reimbursable Travel

6.2.2 Travel Requests

6.2.3 Travel Invoicing

6.2.4 Travel Constraints

6.2.5 OCONUS Travel

APPENDIX A CDRL Tracker.................................................................................................... A-1 v

APPENDIX B CLIN Structure ................................................................................................... B-1

APPENDIX C Solicitation Supporting Documentation ............................................................. C-1

APPENDIX D Reference Documentation .................................................................................. D-1

APPENDIX E Acronyms.............................................................................................................E-1

List of Tables

Table 1 MCH Performance Requirements Table 2 MCH System Design Criteria Table 3 Examples of Bloatware To Be Excluded Table 4 MCH Firmware Device Drivers Table 5 CSfC Registration Renewal Events Table 6 Kick off Meeting Information Table 7 Product Service Codes

List of Figures

Figure 1 MCH Notional Acquisition Timeline

This Page Left Intentionally Blank vi

1 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.

2 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

3 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.

3.1.1 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.

3.1.2 EUD Application Subsystem

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

3.1.3 Server Subsystem

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

3.1.4 Peripheral Subsystem

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

3.1.5 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

3.3.1 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.

3.3.2 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.

3.3.3 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.

3.3.4 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.

3.3.5 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.

3.3.6 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.

4 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

4.1.1 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.

4.1.2 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.

4.1.3 Configuration Management

4.1.3.1 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.

4.1.3.2 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

4.1.4 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

4.1.5 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.

4.1.6 Meetings, Management Reviews, and Reporting

4.1.6.1 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.

4.1.6.2 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.

4.1.6.3 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

4.2.1 Contractor’s Program Protection

4.2.1.1 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

4.2.1.2 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.

4.2.1.3 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.

4.2.1.4 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

4.2.1.5 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

4.2.2 Counterfeit Protection

4.2.2.1 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

4.2.2.2 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).

4.2.2.3 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

4.3.1 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.

4.3.1.1 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.

4.3.1.2 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.

4.3.1.3 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

4.3.1.4 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

4.3.2 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

PSPEC

Section

Title Subsystem(s) Effectivity Revised Requirement

3.2.1 Environmental System All

3.2.2 Security & MDM System All

3.2.3 Safety System All

3.2.4 Human Factors

Engineering System All https://www.nsa.gov/resources/everyone/csfc/capability-packages/

PSPEC

Section

Title Subsystem(s) Effectivity Revised Requirement

3.2.5 Reliability System All

3.2.6 Maintainability System All

3.2.7 Interoperability System 3.2.7.1 – 3.2.7.29, 3.2.7.48

3.2.8 Survivability System All

3.2.9 Support Equipment

(includes packaging) System 3.2.9.2 – 3.2.9.6

3.2.10 Family of Systems System N/A

3.2.11 Wireless Access Point Peripheral All

3.3.1 EUD Operating System EUD Platform All

3.3.2 EUD MDM Agent EUD Platform All

3.3.3 EUD Security EUD Platform All

3.3.4 Commercial EUD EUD Platform All except 3.3.4.12

(T/O), 3.3.4.7 (T) [see below]

3.3.4.12 Tablet Screen

Resolution (T)

EUD Platform See revised requirement

1280 X 800

3.3.4.12 Tablet Screen

Resolution (O)

EUD Platform See revised requirement

2048 X 1536

3.3.4.7 EUD Pixel Density (T) EUD Platform See revised

requirement

180 pixels per inch

3.4.1 Application Graphical

User Interface (GUI)

EUD Application N/A

3.4.2 Configuration and

Utility

EUD Application N/A

3.4.3 Message Exchanges EUD Application N/A

3.4.4 Command and Control EUD Application N/A

3.4.5 Map, Imagery, Video EUD Application N/A

3.4.6 Navigation EUD Application N/A

3.4.7 Common Tactical

Picture (CTP) Track Management

EUD Application N/A

3.4.8 CTP Display Tailoring EUD Application N/A

3.4.9 Fires EUD Application N/A

3.4.10 Application

Programmer Interfaces EUD Application N/A

3.5.1 Human System

Integration

Expeditionary Interface

N/A

3.6.1 Mission Planner Peripheral N/A

4.3.3 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

Ref Criteria Subsystem(s) 1 MCH user input methods shall activate application software functionality in a consistent manner. EUD input methods shall include, at a minimum, stylus input, single and multi-touch, and on screen QWERTY keyboard.

EUD Platform

2 MCH hardware component interfaces shall utilize military specification compliant cabling connectors IAW military standards including MIL- DTL-22992H, MIL-DTL-26482H w/Amendment 2, and MIL-DTL- 38999M w/Amendment 1.

System

3 MCH hardware component interfaces shall be designed with cable shielding, proper termination, and filtering (such as with ferrite beads) to maximize signal to noise ratio and minimize radiated signals.

System

4 The MCH system shall not contain bloatware, where bloatware is defined as unwanted, preloaded software on a new device that is specific to the vendor and device. See Table 3 for a non-exhaustive list of currently known bloatware.

EUD Platform

5 The MCH EUDs shall include firmware device drivers identified in Table 4. This list represents specific drivers which the Government anticipates will be necessary to support serial and Ethernet interoperability and does not preclude inclusion of additional device drivers which the contractor may deem necessary to meet requirements.

EUD Platform

6 The MCH EUDs shall provide On the Go (OTG) and Universal Serial Bus (USB) connection/data transmission and parallel charging capabilities, allowing Accessory Charger Adaptor (ACAD) Dock detection for charge while in host mode. The MCH EUDs shall support full charging when connected to a tactical USB hub.

EUD Platform

7 The MCH EUDs shall support multiple Ethernet devices (eth0, eth1, etc.). Android settings shall be capable of configuring multiple Ethernet devices or an API shall be provided to configure any Ethernet port in the system. The ability to select from Dynamic Host Configuration Protocol (DHCP) and static configurations of Ethernet ports shall be provided.

EUD Platform

8 The MCH EUDs shall provide an API to add/delete routes from the routing table.

EUD Platform

9 The MCH EUDs shall support stay awake when the device is in charging mode.

EUD Platform

10 The MCH EUDs shall allow user access to set/display date and time from an external Global Positioning System (GPS) when connected.

EUD Platform

Ref Criteria Subsystem(s) 11 The MCH EUDs shall implement a boot screen which includes a

USMC Logo with “MAGTF Common Handheld” displayed beneath.

EUD Platform

12 The MCH EUDs shall provide an API to select between SECRET and UNCLASSIFIED screen banners.

EUD Platform

13 The MCH EUDs shall provide users quick access to common system settings and background applications. The intent is to allow users to configure which settings out of all available settings are provided in a quick access slide out or comparable menu, such as screen brightness, sound level, Wi-Fi, Bluetooth, location services, power saving mode, airplane mode, do not disturb, screen lock, etc.

EUD Platform

14 The MCH EUDs shall provide persistent indicators of common system status items. The intent is to display active devices, connections, and/or modes such as Wi-Fi, Bluetooth, location services, power saving mode, airplane mode, do not disturb, screen lock, USB connection, battery state, etc.

EUD Platform

15 The MCH EUDs shall provide a screen capture function. The intent is that screen capture can be accomplished with a combination or short sequence of user actions.

EUD Platform

16 The MCH EUDs shall provide power OFF confirmation. The intent is that the power off sequence is verified prior to the EUDs powering down.

EUD Platform

17 The MCH EUDs shall provide configurable ring tones and vibrate functionality for system alerts and in an API for developer use.

EUD Platform

18 The MCH EUDs shall provide file management functions for files on the EUDs including available SD card(s).

EUD Platform

19 The MCH EUDs shall provide power conservation mode(s). The intent is to provide one or more modes which allow the user to configure power conservation attributes such as CPU performance, screen output, and other system functionality.

EUD Platform

20 The MCH EUDs shall provide an Android operating system version of at least 7.0.

EUD Platform

21 The MCH EUDs MDM client shall provide an API to support secure wipe of the end user device in accordance with established DoD policies such as DoD 5220-M, National Industrial Security Program Operating Manual.

EUD Platform

Table 3 Examples of Bloatware To Be Excluded

Bloatware AllShare FileShare Service Hangouts Backup (Backup and Restore Agent) Health Service BeaconManager HP Print Service Plugin Briefing Instagram Bubbles Live wallpaper picker Car Mode Live weather Chromecast Server Service Messenger DirectShareManager Milk Drive (Google Drive) Mobile print service Dropbox My Interests DT Ignite My Places Evernote PEN.UP Facebook Print Spooler Flipboard Remote Player Galaxy Apps S-Finder Google Play Music S Health Google Play Services Scrapbook Google Play Books Selfie Alarm Google Play Games Smart Remote Google Play Movies & TV Skype Google Play Newsstand Trim Google Search Weather Google+ YouTube

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

4.3.4 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.

4.3.4.1 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

4.3.4.2 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.

4.3.4.2.1 Contractor’s Cybersecurity Representations

The contractor warrants that any hardware, software and firmware goods delivered under this Contract:

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

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.

4.3.4.3 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

4.3.4.4 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

4.3.5 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).

4.4.1 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.

4.4.2 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 and Fielding. in year one of the contract and fielding in years two through five.

4.4.3 Reserved

4.4.4 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

4.4.5 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 https://www.disa.mil/

4.4.6 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

4.5.1 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.

• CDRL A00B DI-QCIC-80553A, Factory Acceptance Test Plan w/ Procedures

• CDRL A00C DI-QCIC-81891, Factory Acceptance Test Report

4.5.2 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

4.6.1 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.

4.6.2 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.

4.6.2.1 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…