HR001119S0089.pdf

Broad Agency Announcement Assured Micropatching (AMP)

HR001119S0089

September 23, 2019

Defense Advanced Research Projects Agency Information Innovation Office 675 North Randolph Street Arlington, VA 22203-2114

HR001119S0089 AMP 2

Table of Contents

Part I: Overview Information……………………………………………………………………...……...……3

Part II: Full Text of Announcement……………………………………………………………………………..4

I. Funding Opportunity Description

II. Award Information

A. Awards

B. Fundamental Research

C. Disclosure of Information and Compliance with Safeguarding Covered Defense Information Controls

III. Eligibility Information

A. Eligible Applicants

B. Organizational Conflicts of Interest

C. Cost Sharing/Matching

IV. Application and Submission Information

A. Address to Request Application Package

B. Content and Form of Application Submission

C. Submission Dates and Times

D. Funding Restrictions

E. Other Submission Requirements

V. Application Review Information

A. Evaluation Criteria

B. Review and Selection Process

VI. Award Administration Information

A. Selection Notices

B. Administrative and National Policy Requirements

C. Reporting

VII. Agency Contacts

VIII. Other Information

A. Frequently Asked Questions (FAQs)

B. Proposers Day

C. Submission Checklist

D. Associate Contractor Agreement (ACA)

HR001119S0089 AMP 3

PART I: OVERVIEW INFORMATION

Federal Agency Name: Defense Advanced Research Projects Agency (DARPA), Information Innovation Office (I2O)

Funding Opportunity Title: Assured Micropatching (AMP)

Announcement Type: Initial Announcement

Funding Opportunity Number: HR001119S0089

Catalog of Federal Domestic Assistance Numbers (CFDA):

12.910 Research and Technology Development

Dates o Posting Date: September 23, 2019 o Abstract Due Date: October 8, 2019, 12:00 noon (ET) o Proposal Due Date: November 20, 2019, 12:00 noon (ET) o Proposers Day: September 26, 2019

Anticipated Individual Awards: There are multiple technical areas for this solicitation.

Currently, DARPA anticipates multiple awards in Technical Area 1 and Technical Area 2; and a single award for Technical Area 3. DARPA anticipates making multiple awards under this BAA, which has a total anticipated funding amount of approximately $50 million.

Types of Instruments that May be Awarded: Procurement contracts, cooperative agreements or Other Transactions (grants will not be awarded)

Agency Contacts o Technical POC: Dr. Sergey Bratus, Program Manager, DARPA/I2O o BAA Email: AMP@darpa.mil o BAA Mailing Address:

DARPA/I2O

ATTN: HR001119S0089

675 North Randolph Street Arlington, VA 22203-2114 o I2O Solicitation Website: http://www.darpa.mil/work-with-us/opportunities http://www.darpa.mil/work-with-us/opportunities

HR001119S0089 AMP 4

PART II: FULL TEXT OF ANNOUNCEMENT

I. Funding Opportunity Description

DARPA is soliciting innovative research proposals in the area of creating targeted security binary patches (micropatches) to repair legacy binaries of mission-critical systems, with strong guarantees that the patch will not impact the functions of the system. Proposed research should investigate innovative approaches that enable revolutionary advances in science, devices, or systems. Specifically excluded is research that primarily results in evolutionary improvements to the existing state of practice.

This Broad Agency Announcement (BAA) is being issued, and any resultant selection will be made, using procedures under Federal Acquisition Regulation (FAR) 6.102(d)(2) and 35.016.

Any negotiations and/or awards will use procedures under FAR 15.4. Proposals received as a result of this BAA shall be evaluated in accordance with evaluation criteria specified herein through a scientific review process.

DARPA BAAs are posted on the Federal Business Opportunities (FBO) website (https://www.fbo.gov/) and the Grants.gov website (https://www.grants.gov/).

The following information is for those wishing to respond to this BAA.

Introduction

Our society’s infrastructure is increasingly dependent on software deployed on a wide variety of computing devices other than commodity personal computers, such as industrial equipment, automobiles, and airplanes. Unlike commodity computers that have short upgrade cycles and are easily replaceable in case of failure, these computing devices are intended for longer service, and are hard to replace. Thus, the amount of deployed software that needs to be maintained is continually increasing, while the growing use of telemetry on such devices potentially exposes their software to cyber-attacks.

To fix cybersecurity flaws in software, vendors distribute patched versions of the software.

Unfortunately, even after a particular flaw has been fully understood, and a remediation approach has been developed and expressed as a source code change in the current version of the software, the ability of vendors to produce patches for all of their deployed devices in a timely, assuredly safe, and scalable manner is limited. Additional challenges arise when the exact source code version has been lost, the process for building the software from source code was not documented, and/or the original software development environment is not available. These limitations and challenges result in mission-critical software going unpatched for months to years, increasing the opportunity for attackers.

The goal of AMP is to create the capability for rapid patching of legacy binaries in mission-critical systems, including the cases where the original source code version and/or build process is not available. AMP will create new capabilities to analyze, modify, and fix legacy software in binary form, to produce assured targeted micropatches for known security flaws in existing binaries. Micropatches change the fewest possible bytes to achieve their https://www.fbo.gov/

HR001119S0089 AMP 5

objective, which minimizes potential side effects, and should enable proofs that the patches will preserve the original baseline functionality of the system. With these proofs, the time to test and deploy the patched system will be reduced from months to days.

Insufficiency of Current Approaches

Today’s software methodologies and tools do not support systematic assured modification of binaries, such as synthesizing a change for an existing binary from a source-code level description and safely applying and analyzing the change. Instead, the binary is regarded as an opaque end-point of the build process, to be discarded and re-created from scratch when any changes need to be applied to it. This approach disregards the growing footprint of deployed legacy binaries and the difficulties of preserving build processes for binaries meant to be deployed in long-serving mission-critical infrastructure assets. The challenges of security patching at scale are illustrated by (but are not limited to) the following typical concerns. In these examples, the terms software and firmware are used interchangeably.

A. Re-building binaries from changed source code risks breaking tested baseline functionality.

Although software flaws are commonly understood and fixed at the source code level, the actual operation of a device is controlled by the binary executable image of the software, obtained from the source via the build process. The build process produces executable binary units from the source code units via compilation and then unifies these units via linking into a single executable binary image to be loaded onto the device. The culmination of the software development process for a platform is the integration stage, wherein all the binary software modules obtained via their separate build processes are functionally tested as a whole.

Functional testing at the integration stage tests the properties of the binary image as created by the build process rather than those of the source code. The actual accepted or certified baseline of the device's mission-critical functionality is thus as much a product of the compilation, linking, and other build process artifacts as it is of the source code. In particular, testing cannot distinguish whether an intended behavior of the binary code is due to its correct representation in the source code that was correctly translated into the binary executable code, or whether it is actually due to a serendipitous compiler decision that won’t be reliably reproduced in another compilation. A small change in the source code, the compiler configuration, or the compiler's internal algorithms could cause the compiler to emit binary code that fails to perform as intended. Since such decisions depend on an exponential number of configuration options, as well as on the particular version of the build tool chain, any recompilation of mission-critical code is fraught with danger, even when the original build environment is exactly reproduced.

However, the particulars of the build process are the least likely to be documented, even under otherwise aggressive source control approaches.

Uncertainties of recompiling source code are exacerbated when the exact version of the source code or the build process configuration are not known. Under such circumstances, preserving as much of the known-good binary executable code that has successfully passed integration and testing is advisable. However, this mode of operation is not supported by any existing build chain, as any compilation is undertaken from scratch without regard for the previous binary.

HR001119S0089 AMP 6

B. Manual micropatching changes to existing binaries are not scalable or assured.

An empirically viable alternative method of fixing known flaws is the so-called manual binary micropatching process. In this process, experts manually decompile and reverse engineer the binary, then analyze the results to find the locus of the desired source code change. They then translate the source code change into a change in the binary executable code that respects the structure of the existing binary, including the original compiler’s conventions and artifacts.

Further manual analysis ensures that the changes will not disrupt the code paths inherent in the binary’s baseline functionality.

However, there is no automated methodology for reasoning about the effects of a binary micropatch on the rest of the system. The changed binary code must undergo the same extensive testing accomplished during the original software’s integration stage. In the end, the data flow and control flow properties of a manual binary micropatch are subject to the manual analysis by the expert, unaided by any kind of potentially relevant sophisticated analyses typically performed by the compiler when optimizing code for efficiency. While side-stepping the risks of from-scratch recompilation, manual binary micropatching remains an unscalable approach.

C. Decompilation tools aren’t suited to situating patches and do not utilize relevant information.

Decompiling binaries produces source-level code that looks nothing like the original source, and lacks the landmarks to situate the patch, requiring experts to conduct painstaking manual analysis to identify the loci of the needed change. Current binary decompilation and analysis tools that could help situate a source-level security patch into a binary component or highlight deviations of the binary component from an available source code version cannot take advantage of available source code samples, desired code style information, or other available information about the source code or the build process. In a similar vein, there are no tools today for reconstructing an undocumented, lost, or incomplete build process for a binary from available information.

Current decompilers produce source code-level representations that target vague concepts of readability by human reverse engineers. These tools do not support analysis on the resulting decompiled form, recompilation, nor situating of patches. They cannot provide any assurance of non-interference with the intended baseline functionality of the code to be patched.

Current decompilation approaches encompass complex stacks of multi-level heuristics and logics representing the collective experience of many binary analysis experts. These heuristics select particular representations of the binary code semantics from among a wide range of semantically equivalent representations. A state-of-the-art decompiler produces one of many semantically equivalent representations of the code, but lacks the ability to explore the space of such semantically equivalent representations with respect to a particular goal. The lack of clear goals and metrics for the decompilation process stymies the progress of automation techniques. No frameworks exist for searching the space of semantically equivalent representations to select those fit to a purpose.

HR001119S0089 AMP 7

Compiler research has benefited from the establishment of open, modular architectures and frameworks that enable composable transformations to act on source code and intermediate representations thereof in order to produce performant executable binaries. These frameworks support sophisticated control and data flow analyses of source code for the purposes of performance optimization, parallelization, and security. They take advantage of many purpose-built intermediate representations to facilitate these analyses. No such open infrastructure has appeared to support decompilation.

D. Embedded software faces additional challenges from aging development environments.

For embedded software, the situation is further exacerbated by restrictive licensing and customization of build tools chains, which may be constrained to run on a single computer with an outdated operating system and programming environment. In a typical scenario, a flawed version of a component library is included in an embedded software development kit (SDK) and becomes part of many different firmware images. The version of the library included in the SDK may be modified to integrate with other components of the SDK or to address the embedded platform's features and constraints. When flaws are fixed in the stock version of the library, the SDK version may be left behind—especially in the case when it has been modified. As a result, the availability of a well-understood patch for a stock version does not automatically entail the availability of patches for a multitude of SDK-derived binary firmwares. In such cases, there is no viable automated path for rebuilding these firmwares, and no scalable way of micropatching them.

The AMP program seeks to address these gaps in the current software development paradigm, elevating the tasks of assured manipulation of existing binaries to the first-class status currently enjoyed by the compiler analysis for performance optimization and software verification.

The program seeks breakthroughs in and novel approaches to the following technical challenges including but not limited to:

Identifying modular units in executable binary images, identifying modules’ interfaces, interactions, and linking artifacts to enable subsequent assured re-linking and re-integration of patched binary modules;

Decompiling the executable binary code into forms suitable for automatically situating a patch for a known security flaw existing in the binary;

Generating minimal-change binary micropatches for existing binary images and for rigorous reasoning about their effects and testing these effects to verify non-interference of the changes with the binary’s baseline functionality; and

Using available sources of information, such as source code and binary samples, to recover missing relevant parts of the source code and the build process.

Program Scope

The AMP program will address rapid patching of software in mission-critical systems by combining techniques from compiler research, binary decompilation and analysis, and program verification. Compiler research to date treats creating executable code as a clean-slate task for every compilation unit, without regard for restrictions imposed by the binary environment into

HR001119S0089 AMP 8

which the resulting compiled code must be re-integrated. Decompilation has not made effective use of composable semantically-equivalent transformations, which drive state-of-the-art compilation research. And finally, program verification focuses on proving behaviors of programs with respect to their specifications, rather than proving intended behavior equivalence between patched and unpatched binary versions. AMP will create challenges to spur collaborations among experts in these areas, to enable assured modification of binaries via automated micropatching.

Program Structure

The program will produce theories, technologies, and formal proof techniques leading to experimental prototype(s) that will demonstrate the use of targeted micropatches for repairing legacy mission-critical binaries with strong guarantees that the patch will not impact the baseline functions of the system. It is expected that these prototypes will provide a starting point for technology transition to mission-critical software for cyber physical system domains.

The AMP is a 48 month program divided into three Technical Areas (TAs), TA1 Goal-driven decompilation, TA2 Assured recompilation and TA3 Evaluation, organized into three (3) phases;

Phase I will be 18 months, followed by an 18-month Phase 2, and then concluded with Phase 3 at 12 months, with milestones as described in Table 1. DARPA anticipates funding multiple technical approaches and performers across the AMP technical areas. It is desired that selected performers be funded through Phase 1, 2, and 3 of the program. Beyond Phase 1, subsequent phases will be considered options, and may or may not be exercised at the sole discretion of the government. Funding of option phases will be based on demonstrated technical progress towards the goals of the AMP program and the availability of funds.

TA1 and TA2 performers should be prepared to work closely with each other in order to support integration of the TA1-goal-driven decompilation results with the TA2-automated, proof-guided relinking of the targeted patch. To facilitate the open exchange of information, performers will have Associate Contractor Agreement (ACA) language included in their award. See Section VIII.D for more information regarding an ACA. While TA3 performers will be a party to the ACA, it is expected that TA3 outputs will be largely independent of TA1 and TA2 work.

Each abstract and proposal may only address one TA. Proposers may submit multiple proposals to any one TA, and they may propose to mulitple TAs. In the case of submissions to multiple TAs, the Government reserves the right to decide which, if any, to select for award. A proposer submitting a proposal to TA1 and another to TA2 may be selected to perform on both TAs.

However, TA3 performers cannot perform on any other TA.

DARPA encourages proposers to consider the investigation of techniques and strongly prefers proposals that will provide an overall AMP framework that will result in an open, modular architecture for decompilation, analysis, and manipulation of binaries and that embraces free software principles and experimental reproducibility. Proposals restricting technology transition of the AMP technology may be considered a weakness.

The Government will assess performer progress against target goals set for each phase, using a progression of technical challenges as outlined below in the Technical Areas. In addition, an advisory panel composed of participants from interested Government partners may participate in the meetings and in the informal challenges to provide feedback to the PM.

HR001119S0089 AMP 9

Technical Areas (TAs)

The program will address rapid patching of software in mission-critical systems by combining techniques from compiler research, binary decompilation and analysis, and program verification, through progress in three key technical areas of

• Goal-driven decompilation (TA1)

• Assured recompilation (TA2)

• Evaluation (TA3) as shown in Figure 1. The first two technical areas are focused on the program’s technical challenges: automatic component and interface discovery, goal-driven decompilation to isolate and analyze the known flawed components, and assured recompilation to rebuild the affected binaries with assured minimal changes and guarantees of non-interference with baseline functionality—in timelines of hours to days instead of the current timelines of months to years. The third technical area provides the program challenge tests to evaluate the results using, but not limited to, a cyber physical mission-critical systems domain use case such as the heavy vehicle domain.

Figure 1 – AMP Technical Areas (TAs)

TA1: Goal-driven decompilation

TA1 performers will develop novel approaches to identify modular units in executable binary images; identify modules’ interfaces, interactions, and linking artifacts to enable subsequent assured re-linking and re-integration of patched binary modules; and, to decompile the executable binary code into forms suitable for automatically situating a patch for a known security flaw existing in the binary.

An AMP TA1 decompiler tools should take advantage of existing source code samples, binary code samples, available parts of the build process, or any other available information and suitable

HR001119S0089 AMP 10

analysis methods. The decompiler will use this information to direct decompilation towards a goal such as alignment with existing source code, a particular desired pattern or style of the decompiled code, or a fitness function for an analysis task. The resulting goal-driven decompilation prototype will demonstrate feasibility of guiding decompilation towards the goal of automatically situating and analyzing patches for repairing binary flaws.

Strong TA1 proposals will develop new open architectures for decompilers, in which decompiler operations are decoupled from the current stacks of heuristics, are made composable, and enable modular approaches to analysis. Strong TA1 proposals will support interoperability with intermediate representations and specification languages used by leading industry standard tools, and will support creation of and translations between novel intermediate representations required for goal-driven decompilation tasks.

Strong TA1 proposals will present a review of the existing approaches, techniques, and challenges in academia and industry, supported by appropriate literature citations. Strong proposals will offer metrics and benchmarks for evaluating the success of the existing and newly developed technologies, in open reproducible settings.

TA2: Assured recompilation

TA2 performers will focus on the research and development of novel techniques for generating minimal-change binary micropatches for existing binary images and for reasoning about their effects. Proposals should describe approaches to precisely track the effects of patches from their source or source-equivalent high-level abstraction representations to the binary executable code throughout compilation, to identify the footprint of changes on requirements tests, and to rigorously verify non-interference of the changes with the binary’s baseline functionality. For cases where the original build process is not available, proposals should describe approaches to use available sources of information, such as source code and binary samples, to recover the build process sufficiently to translate a source-level patch to the executable binary form. TA2 systems should use a suitable representation of the pre-existing binary code, aided by the decompiler analysis from TA1.

The TA2 recompiler tools will reason about a source-level change to produce a targeted binary patch that results in a minimal change of the binary’s behaviors with respect to the functional baseline of the pre-existing binary. In addition to the binary patch, the re-compiler will produce a formal representation of the effects of the change, to be used in isolation proofs and for generating tests for guided, limited re-testing of the patched binary image if necessary. Checking isolation proofs and testing and will be performed automatically.

TA2 performers will develop theories to identify and distinguish between the classes of security patches that can be effectively translated into binary micropatches, and the levels of assurance that can be achieved with various analyses of these patches.

Strong TA2 proposals will present a review of the existing approaches, techniques, and challenges in academia and industry, supported by appropriate literature citations. Strong proposals will offer metrics and benchmarks for evaluating the success of the existing and newly developed technologies, in open reproducible settings.

HR001119S0089 AMP 11

Essential Interactions between TA1 and TA2

TA1 analysis tools are required to provide binary analysis results to assist TA2’s reasoning about changes to the binary and the construction of isolation proofs. For example, TA1 tools should produce useful representations of the modules, interfaces, linking artifacts, application binary interfaces (ABI) artifacts, and other relevant artifacts for TA2’s use.

Robust interaction is expected and should be planned for between TA1 and TA2 in identifying the goals of automated analyses and in representation of the analysis results such as intermediate representations.

TA3: Evaluation

The TA3 performer will assist the Government team in the development of evaluations for the technological capabilities developed by the TA1 and TA2 performers and to provide feedback to the TA1 and TA2 performers. The TA3 performer will be responsible for defining and executing a testing approach that enables the incremental development and demonstration of AMP capabilities.

The TA3 performer will produce the testbed for evaluating the AMP technological capabilities developed by TA1 and TA2 performers, and will evaluate these capabilities. Evaluation will include both security testing of the AMP micropatching technologies and rigorous testing of the baseline functionality preservation by these technologies, via a series of challenge tests of increasing complexity and difficulty, as described below.

Security Testing Activities Proposals should describe methods for developing tactics, techniques and procedures capable of demonstrating specific weaknesses in the TA1 and TA2 performers’ technologies. Strong TA3 proposals should address TA1 and TA2 performer technologies, integrated system software security proofs/analysis, and AMP system traffic instrumentation.

Evaluation Testbed Development The series of the challenge tests will progress from commodity connected software and firmware in Phase 1, to real-time controller units for a cyberphysical system in Phase 2, to a networked system of controllers for a cyberphysical system in Phase 3, increasing the technical complexity of the challenges and the assurance guarantees that TA1 and TA2 technologies must meet.

In each challenge test, TA1 and TA2 performers will receive binary software/firmware images alongside with source-level or equivalent high-level representations of the patches that need to be applied to the binary images to fix a known vulnerability. The performers will also be provided with additional information such as relevant source code samples, compiled binary code samples, or elements of the build process. After the performers formulate and apply binary micropatches, the patched images will be tested for robustness, preservation of the baseline functionality, and security.

In addition, TA3 will produce tests to evaluate progress on mechanized TA1 and TA2 analysis tasks against the ground truth, such as precision of decompilation and of relevant binary

HR001119S0089 AMP 12

analyses. TA3 will ensure that the evaluated technological capabilities are reproducible and at least comparable to those of the state-of-the-art tools.

Strong TA3 proposals shall provide detailed plans, descriptions, and test protocols for creating challenge problems of increasing difficulty culminating in a networked system that are representative of actual mission-critical software and firmware targets, flaws, and fixes in the chosen domain use cases. These challenges will guide the TA1 and TA2 performers in the development of their tools and theories.

The TA3 performer should form strong collaborative relationships with vendors and industry subject-matter experts (SMEs) in the chosen systems domain to formulate the representative challenges, and should collaborate with the Government SMEs to ensure relevance of the developed tests and technologies, and consistency with Government standards for acceptance testing and certification.

Strong proposals shall focus on realistic and industry-relevant patching and testing scenarios, including testing protocols that should be at least as strong as the accepted industry practice. The TA3 performer will submit plans for the challenge problem events to the Government team at least two months prior to each event. Evaluation approaches for maximizing test coverage of unclassified target platforms are highly encouraged.

Program challenge events will be conducted at the performer’s site over the course of the program. The events will determine whether TA1 and TA2 technologies are meeting program metrics, thereby aiding the Government in determining the value added for additional AMP program phases. Specific AMP end-of-program goals will be used during the Phase 3 evaluation assessment events. Strong proposals will present detailed plans for organizing the evaluations, demonstrations, and hackathons for the TA1 and TA2 performers using the testbed, as well as plans for allowing the performers suitable access to the testbed to prepare for these events.

Challenges should be drawn from, but not limited to, a cyber physical mission-critical software domain such as heavy vehicle firmware or a similar domain of mission-critical systems combining commodity and real-time components. The challenges should be suitable for fundamental research, will be shared without limitations with the TA1 and TA2 fundamental research teams, and should not contain Controlled Technical Information

(CTI).

To aid the TA3 proposers, the following discussion of an exemplary evaluation testbed from the heavy vehicle domain is provided below. Proposers are encouraged to enhance it with other relevant challenges, systems, and domains as needed to demonstrate robust assured micropatching capabilities.

Exemplary Evaluation Testbed for a Heavy Vehicle Use Case

Phase 1: A potential evaluation challenge test platform for this phase is a heavy vehicle telematics unit. These units, mandated by the US Department of Transportation for heavy vehicles since December 2017, combine commodity cellular modems with access to the vehicle’s systems, as well as management and reporting interfaces. These devices present

HR001119S0089 AMP 13

security concerns typical for networked embedded commodity systems, yet interact with mission-critical control systems.

Phase 2: Potential evaluation challenges are heavy vehicle brakes, transmission, or engine Electronic Control Units (ECUs). Typically under one million lines of code, these units present a realistic and highly performance-sensitive mission-critical target.

Phase 3: A potential evaluation challenge in this phase is a networked system of multiple ECUs interoperating over the J1939 bus used in heavy commercial vehicles, with appropriate test cases for the whole-system evaluation.

The AMP program metrics are delineated in Table 1, with the respective exemplary test platforms for a heavy vehicle use case noted in the first row.

Table 1 – AMP Metrics

Program Phases and Metrics

The AMP program is a 48 month effort, divided into three phases: an initial 18-month commodity systems phase, followed by an 18-month real-time systems phase. A final 12-month phase will focus on scaling the technology to a networked system. The schedule is summarized in Figure 2.

Proposers should describe specific devices that they will use for test and evaluation purposes during each of the program phases. To ensure maximum relevance to the government, DARPA will select specific devices to be used in evaluation, at each phase. The specific metrics provided in the remainder of this section are indicative of the expected progress.

HR001119S0089 AMP 14

Phase 1: The first phase will create the frameworks and the prototypes of the recompiler and the goal-driven decompiler, and apply them to a series of challenges in micropatching commodity embedded software with known flaws. The software is assumed to be connected to the Internet while being a part of a cyberphysical system.

Phase 2: The second phase continues development and successfully applies micropatches to embedded real-time control system software components. The program’s midterm exam is the ability to generate micropatches for such performance-sensitive control system components, wherein naively rebuilding a flawed component would result in a non-functional system.

Phase 3: The third and final phase scales the program’s success to a networked system of multiple control devices that interoperate over a standard bus to control a cyberphysical system. The units of the system must be patched in concert. Patching of separate components without regard for their interactions would result in a non-functional system.

The AMP program metrics are delineated in Table 1. The first row of the table references the respective exemplary platforms for a heavy vehicle use case.

The Government will assess individual performer efforts in terms of the viability of their technical approaches, the trend in the performance of their systems over time, and their overall progress toward AMP program objectives.

Schedule and Milestones

For each year of the effort, there will be quarterly meetings with the Program Manager (PM), consisting of two site visits and two Principal Investigator (PI) meetings. During these reviews, the PM will assess progress toward solution via performer briefings, technical discussions, demonstrations, and informal end-of-phase evaluations/challenges based on the target goals of each phase.

PI meetings will focus on open technical exchange. Difficulties encountered and possible solutions will also be discussed. The goals of the PI meetings will be to: (a) review and share innovations/accomplishments of the AMP program; (b) review and discuss plans and options for technology demonstrations and prototypes and AMP challenge events (c) review and discuss results from meetings and events conducted prior to the tests and evaluation challenge events; (d) demonstrate prototypes; and (e) plan for the next six-month period.

The Government will specify the locations for the technical interchanges and PI meetings.

Challenge events will be held at the TA3 performer’s site. For budgeting purposes, assume the locations of the two PI meetings held each year will alternate between Washington, D.C., and at a location on the west coast. Actual locations will be determined on performer locations and relative cost to the Government. In addition to site visits, regular teleconference meetings are encouraged to enhance communications and collaborations, as required, among the performers.

Should important issues arise between program reviews, the Government team will be available to support informal interim meetings.

HR001119S0089 AMP 15

The schedule listed in Figure 2 contains notional estimates. Proposers should propose a detailed schedule that is consistent with the maturity of their approaches and the risk reduction required for their concepts, and their program plan. These schedules will be synchronized across performers, as required, and monitored and revised as necessary, throughout the AMP program’s period of performance. A start date of April 1, 2020, should be assumed for budgeting purposes.

Subject to the availability of funding, the program is intended to last for four years.

Figure 2 – AMP Program Schedule

Deliverables

Performers are responsible for providing the following deliverables, as applicable:

Slide Presentations – Annotated slide presentations will be submitted within two weeks after program kick-off meeting and after each review.

Quarterly Coordination Reports – A quarterly technical coordination report describing progress made, resources expended, and any issues requiring the attention of the Government team will be provided within 10 calendar days after the end of each quarter.

Monthly expenditure reports and uploading of required deliverables to the DARPA Technology Financial Information Management System (TFIMS) reporting system are required by all AMP program performers.

System Development Plan (SDP) – An SDP will be provided within one month after the kickoff meeting for each phase, and shared with other performers for synchronization.

The SDPs for each phase will be based on the performers’ proposal and will be presented at the kickoff meeting for each phase. The SDP will describe the scope of the design and development effort, describe the hardware and software architecture in sufficient detail for review and planning, reference any applicable documents, and provide a program schedule.

Software – All computer software developed or delivered under the AMP program must be delivered as source and as object (executable) code. Include the source listings and source code for the target computer systems, as well as any build scripts or other

HR001119S0089 AMP 16

technical information required for DARPA to compile all delivered source code.

Delivered software under this effort is to be completely maintainable and modifiable with no reliance on any non-delivered computer programs or documentation.

Software Documentation – Software documentation shall be provided within one month after the end of each phase documenting source code, hardware description language specifications, system diagrams, part numbers and other data necessary to maintain and to produce copies of the software.

Hardware - At the conclusion of the last Phase, all custom hardware procured or developed under the AMP program shall be delivered. The delivered components shall be the same as those used to perform the last Phase final performance tests and evaluations. The delivery is to include sufficient documentation so as to be completely operable, maintainable and modifiable with no reliance on any non-delivered hardware or hardware documentation developed or procured under the AMP program.

Final Technical Report – The final report, due at contract completion, will concisely summarize the effort conducted and provide any lessons learned during the development of the AMP technology.

All reporting must be delivered as required in Section VI.C.

Government-furnished Property/Equipment/Information

Proposals should clearly state any assumptions regarding the use of proposed Government test facilities and capabilities, as well as any proposed Government Furnished Equipment (GFE) used as part of their development, test, and evaluation approach. Proposers should not assume that the Government will provide them with any tools, hardware-in-the-loop testing tools, or ready-to-use threats needed to perform their tasks.

Intellectual Property

A key goal of the AMP program is to facilitate rapid innovation by providing a base for future users or developers of program technologies and deliverables. In particular, the AMP program aims to establish an open, standards-based, multi-source, modular plug-and-play architectures that allow for interoperability and integration. This includes the ability to easily add, remove, substitute, and modify software and hardware components, to facilitate rapid innovation by providing a base for future users or developers of program technologies and deliverables.

Therefore, it is desired that all non-commercial software (including source code), software documentation, hardware designs and documentation, and technical data generated by the program be provided as deliverables to the Government, with a minimum of Government Purpose Rights (GPR), as lesser rights may adversely impact the lifecycle costs of affected items, components, or processes.

The program will emphasize creating and leveraging open source technology and an open source architecture. Intellectual property rights asserted by proposers are strongly encouraged to be aligned with open source regimes. See Section VI.B.1 for more details on intellectual property.

HR001119S0089 AMP 17

II. Award Information

A. Awards

DARPA anticipates multiple awards in Technical Area 1 and Technical Area 2; and a single award for Technical Area 3. The level of funding for individual awards made under this solicitation has not been predetermined. Awards will be made to proposers whose proposals are determined to be the most advantageous to the Government, all factors considered, including the potential contributions of the proposed work, overall funding strategy, and availability of funding. See Section V for further information.

The Government reserves the right to:

select for negotiation all, some, one, or none of the proposals received in response to this solicitation;

make awards without discussions with proposers;

conduct discussions with proposers if it is later determined to be necessary;

segregate portions of resulting awards into pre-priced options;

accept proposals in their entirety or to select only portions of proposals for award;

fund proposals in phases with options for continued work at the end of one or more of the phases, as applicable;

request additional documentation once the award instrument has been determined (e.g., representations and certifications); and remove proposers from award consideration should the parties fail to reach agreement on award terms within a reasonable time or the proposer fails to provide requested additional information in a timely manner.

Proposals selected for award negotiation may result in a procurement contract, cooperative agreement, or Other Transaction (OT) depending upon the nature of the work proposed, the required degree of interaction between parties, and other factors. Grants will NOT be awarded under this program.

Proposers looking for innovative, commercial-like contractual arrangements are encouraged to consider requesting Other Transactions. To understand the flexibility and options associated with Other Transactions, consult http://www.darpa.mil/work-with-us/contract-management#OtherTransactions.

In accordance with 10 U.S.C. § 2371b(f), the Government may award a follow-on production contract or Other Transaction (OT) for any OT awarded under this BAA if: (1) that participant in the OT, or a recognized successor in interest to the OT, successfully completed the entire prototype project provided for in the OT, as modified; and (2) the OT provides for the award of a follow-on production contract or OT to the participant, or a recognized successor in interest to the OT.

In all cases, the Government contracting officer shall have sole discretion to select award instrument type, regardless of instrument type proposed, and to negotiate all instrument terms and conditions with selectees. DARPA will apply publication or other restrictions, as necessary, if it determines that the research resulting from the proposed effort will present a high likelihood http://www.darpa.mil/work-with-us/contract-management#OtherTransactions http://www.darpa.mil/work-with-us/contract-management#OtherTransactions

HR001119S0089 AMP 18

of disclosing performance characteristics of military systems or manufacturing technologies that are unique and critical to defense. Any award resulting from such a determination will include a requirement for DARPA permission before publishing any information or results on the program. For more information on publication restrictions, see the section below on Fundamental Research.

B. Fundamental Research

It is DoD policy that the publication of products of fundamental research will remain unrestricted to the maximum extent possible. National Security Decision Directive (NSDD) 189 defines fundamental research as follows:

‘Fundamental research’ means basic and applied research in science and engineering, the results of which ordinarily are published and shared broadly within the scientific community, as distinguished from proprietary research and from industrial development, design, production, and product utilization, the results of which ordinarily are restricted for proprietary or national security reasons.

As of the date of publication of this BAA, the Government expects that program goals as described herein may be met by proposed efforts for fundamental research and non-fundamental research. Some proposed research may present a high likelihood of disclosing performance characteristics of military systems or manufacturing technologies that are unique and critical to defense. Based on the anticipated type of proposer (e.g., university or industry) and the nature of the solicited work, the Government expects that some awards will include restrictions on the resultant research that will require the awardee to seek DARPA permission before publishing any information or results relative to the program.

Proposers should indicate in their proposal whether they believe the scope of the research included in their proposal is fundamental or not. While proposers should clearly explain the intended results of their research, the Government shall have sole discretion to determine whether the proposed research shall be considered fundamental and to select the award instrument type. Appropriate language will be included in resultant awards for non-fundamental research to prescribe publication requirements and other restrictions, as appropriate. This language can be found at http://www.darpa.mil/work-with-us/additional-baa.

For certain research projects, it may be possible that although the research to be performed by a potential awardee is non-fundamental research, its proposed subawardee’s effort may be fundamental research. It is also possible that the research performed by a potential awardee is fundamental research while its proposed subawardee’s effort may be non-fundamental research.

In all cases, it is the potential awardee’s responsibility to explain in its proposal which proposed efforts are fundamental research and why the proposed efforts should be considered fundamental research.

C. Disclosure of Information and Compliance with Safeguarding Covered Defense Information Controls

The following provisions and clause apply to all solicitations and contracts; however, the definition of “controlled technical information” clearly exempts work considered fundamental research and therefore, even though included in the contract, will not apply if the work is fundamental research.

http://www.darpa.mil/work-with-us/additional-baa

HR001119S0089 AMP 19

DFARS 252.204-7000, “Disclosure of Information” DFARS 252.204-7008, “Compliance with Safeguarding Covered Defense Information Controls” DFARS 252.204-7012, “Safeguarding Covered Defense Information and Cyber Incident Reporting”

The full text of the above solicitation provision and contract clauses can be found at http://www.darpa.mil/work-with-us/additional-baa#NPRPAC.

Compliance with the above requirements includes the mandate for proposers to implement the security requirements specified by National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171, “Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations” (see https://doi.org/10.6028/NIST.SP.800-171r1) that are in effect at the time the BAA is issued.

For awards where the work is considered fundamental research, the contractor will not have to implement the aforementioned requirements and safeguards. However, should the nature of the work change during performance of the award, work not considered fundamental research will be subject to these requirements.

III. Eligibility Information

A. Eligible Applicants

DARPA welcomes engagement from all responsible sources capable of satisfying the Government's needs, including academia (colleges and universities); businesses (large, small, small disadvantaged, etc.); other organizations (including non-profit); other entities (foreign, domestic, and Government); FFRDCs; minority institutions; and others.

DARPA welcomes engagement from non-traditional sources in addition to current DARPA performers.

1. Federally Funded Research and Development Centers (FFRDCs) and Government Entities

a. FFRDCs FFRDCs are subject to applicable direct competition limitations and cannot propose to this BAA in any capacity unless they meet the following conditions. (1) FFRDCs must clearly demonstrate that the proposed work is not otherwise available from the private sector. (2) FFRDCs must provide a letter, on official letterhead from their sponsoring organization, that (a) cites the specific authority establishing their eligibility to propose to Government solicitations and compete with industry, and (b) certifies the FFRDC’s compliance with the associated FFRDC sponsor agreement’s terms and conditions. These conditions are a requirement for FFRDCs proposing to be awardees or subawardees.

b. Government Entities Government Entities (e.g., Government/National laboratories, military educational institutions, etc.) are subject to applicable direct competition limitations. Government Entities must clearly demonstrate that the work is not otherwise available from the http://www.darpa.mil/work-with-us/additional-baa#NPRPAC https://doi.org/10.6028/NIST.SP.800-171r1

HR001119S0089 AMP 20

private sector and provide written documentation citing the specific statutory authority and contractual authority, if relevant, establishing their ability to propose to Government solicitations and compete with industry. This information is required for Government Entities proposing to be awardees or subawardees.

c. Authority and Eligibility At the present time, DARPA does not…