BAA-AFRL-RQKS-2015-0009-Atch3.pdf

BAA-AFRL-RQKS-2015-0009

Attachment 3

CYBER ATTACK COUNTERMEASURES FOR OPEN MISSION SYSTEMS

TASK ORDER 0002 - STATEMENT OF OBJECTIVES (SOO)

25 January 2016

1.0 BACKGROUND

The Open Mission System (OMS) and Unmanned Aerial System Command and Control Interface (UCI) define a family of consensus-based Open System Architecture (OSA) standards to integrate mission systems within ground control systems and airborne avionics systems. These OSA standards (and others that are emerging) leverage widely-known and well-documented standards and emphasize the use of commercial technologies in order to reduce integration risk and affordable capability upgrade. However, many of these leveraged standards do not inherently address the cybersecurity needs of DoD weapon systems. Given the ease of gaining access to these commercial standards, adversaries can rapidly gain an in-depth understanding of certain aspects of these systems and develop exploits that could affect multiple weapon systems or the delivery of critical warfighting capability. Traditional security controls such as those identified in the National

Institute of Standards and Technology (NIST) Special Publication (SP) 800-53, “Security and Privacy Controls for

Federal Information Systems and Organizations” that focus on authentication and access controls alone are insufficient to protect against an intelligent adversary from denying, disrupting, or degrading critical mission system capability. Furthermore, testing is insufficient to uncover all susceptibilities. Therefore, it is especially important to incorporate cybersecurity technologies into an OSA implementation to ensure mission success.

Given the increasing emphasis on cybersecurity for weapon systems and the natural vulnerabilities that result from a published open standard, OMS and UCI must incorporate inherent cybersecurity. The standards must support “baked in cybersecurity” for architectural elements such as the Open Computing Environment (OCE), Critical Abstraction Layer (CAL), and the Avionics Service Bus (ASB) to improve overall cybersecurity of OSA implementations.

2.0 OBJECTIVE

The objective of this task order is to develop and demonstrate cyber security countermeasures (i.e., protections) to detect and mitigate cyber attacks against OSA-based avionics and mission systems and ensure continued mission operations. These attacks may occur via a compromised software and hardware supply chain, remote (wired or wireless) access, or insider threat. This task order is principally interested in cybersecurity techniques that augment traditional cybersecurity controls.

3.0 TASKS AND TECHNCIAL REQUIREMENTS

3.1 Cybersecurity Vulnerability Characterization

The contractor shall analyze the OMS and UCI architectural specifications and messages and identify the key vulnerabilities and potential cyber attack paths that could exploit those vulnerabilities. The vulnerabilities in the specification may be the result of omissions within the standards where cybersecurity was not properly addressed. The contractor shall define a process for identifying relevant classes of cyber attacks. The contractor shall define a mission scenario in which such cyber attack paths might be exploited.

3.2 Cyber Attack Countermeasures Development

The contractor shall identify, design, and prototype one or more countermeasures to address the key OMS and

UCI vulnerabilities identified above. The countermeasures demonstrated shall detect and mitigate exploitation attacks against a representative system and seek to maintain mission system operation.

3.3 Assessment of Cyber Attack Countermeasures

The contractor shall evaluate and assess the developed countermeasures for cost and performance impacts and for the added security provided.

3.4 Advanced Component Prototype Demonstration

The contractor shall demonstrate a secure CAL/ASB that incorporates the developed cybersecurity countermeasures. The contractor shall document the results and lessons learned from the demonstration. To the maximum extent possible, the contractor shall demonstrate the prototype components within the AFRL/RY

Open Architecture Research Lab. The contractor shall document all key interfaces including services, subsystems, and platforms, in accordance with the OMS standard or other applicable standards as appropriate.

3.5 Change Proposals to Open System Standards

Research and development accomplished in the aforementioned tasks may result in change proposals to the

OMS and UCI standards. The Government shall approve all change proposals prior to submission. Any proposed changes shall follow the change processes defined by the respective standards.

4.0 DELIVERABLES: Data shall be delivered in accordance with the Contract Data Requirements Lists (CDRLs) as attached to the solicitation. The contractor shall propose additional deliverables for the TO as appropriate.

In addition, software and hardware (including source code, firmware, libraries, and executables) developed on this TO should be delivered with unlimited rights at the end of the technical period of performance. All software developed under this TO shall be delivered in a format acceptable to both parties. The contractor shall identify, within the proposal, any restrictions on the type of rights to be provided with software and hardware delivered but not developed on this TO with full disclosure of any dependencies upon third party software/hardware.

5.0 TECHNICAL REVIEWS: The contractor shall plan and conduct periodic technical review meetings

(estimated quarterly). The contractor shall ensure required contractor, subcontractor(s), AFRL, and other research personnel are involved.

6.0 SECURITY

6.1 Program Security Requirements

Individuals must be US citizens and may be required to have SCI DCID 6/4 Top Secret Eligibility based on a

SSBI/SBPR to work classified efforts. Any/all SCI and/or SAP work will be required to be conducted within an accredited Special Access Program Facility (SAPF) and/or a Sensitive Compartmented Information Facility

(SCIF). Specific security details and requirements will be outlined within future task orders. All classified efforts must be in compliance with National Industrial Security Program Operating Manual (NISPOM). Other regulations/policies that may apply to this contract are JAFAN 6/0 (Revision 1); DoD Directive 5205.07 (Vol 1-

4); AFMAN 16-703 V3; SAF/AAZ Memorandum” Air Force Special Access Programs Nomination Process

(SAPNP)” (30 Sep 2013); USD(I) Memorandum, Special Access Programs Nomination Process (20 May 2013);

JAFAN 6/3 Implementation Guide, Version 1 (Sep 2006); DoD SAPCO Memorandum, Transition to the Risk

Management Framework (RMF) (18 Dec 2013); Joint Special Access Program Implementation Guide (JSIG) (9

Oct 2013); Intelligence Community Directives (ICD) 704 and 705; other applicable SCI regulations/policy; other applicable Security Classification Guides (SCG); and other applicable regulations/policy and subsequent revisions.

6.2 Operational Security (OPSEC)

General OPSEC procedures, policies and awareness are required in an effort to reduce program vulnerability from successful adversary collection and exploitation of critical information. OPSEC will be applied throughout the lifecycle of the contract. The Critical Information List will be provided upon request by the RYOY

Information Protection Office. While working on the government installation OPSEC will be provided by the

RYOY Information Protection Office.

6.3 Security Training

The contractor will be required to participate in the USG's in-house and web-based security training program under the terms of the contract. The USG will provide the contractor with access to the on-line system. The contractor will be required to take specialized security training as deemed applicable by USG.

7.0 SAFETY: The contractor must comply with all Air Force, federal, state, and local safety and environmental regulations. The effort requires an approved Safety Plan (AFI 91-202 AFRL Sup 1) before any experiment may be conducted outside of a laboratory environment. The contractor must comply with safety requirements contained in MIL-STD 882E, Section 4 “General Requirements” for any deliverable systems or hardware. The contractor must identify safety-critical components of those systems or hardware and software interfaces with those components. The contractor must test and verify the safety-critical hardware and software for safety acceptance.

8.0 BASE SUPPORT: Laboratory space/equipment (on a non-interference basis) and computer/network access in AFRL/RYWA for this contract shall be available for the purpose of conducting this effort, if proposed.