HR001123S0025.pdf

HR001123S0025

Broad Agency Announcement Faithful Integrated Reverse-Engineering and Exploitation

(FIRE)

Microsystems Technology Office

15 March, 2023

Table of Contents

PART I: OVERVIEW INFORMATION

PART II: FULL TEXT OF ANNOUNCEMENT

I. Funding Opportunity Description A. Background B. Program Description

1. TA1 Modeling: Scaling Complexity in Models while Maintaining Accuracy

2. TA2 Simulation: Maintaining synchronization in simulations as the size of the system grows

3. TA3 Preparation

4. TA4 Integration: The CPVA Tool(s)

5. TA5 Engineering Support Task: Evaluation and Testing

a. Track A: Test and Evaluation Systems

b. Track B: Surrogate Systems

C. Program Structure D. Schedule/Milestones E. Deliverables F. Government Furnished Equipment/Property/Information G. Intellectual Property

II. Award Information A. General Award Information

1. Awards under this BAA will be made to proposers on the basis of the evaluation criteria listed below (see section labeled “Application Review Information” Sec. V.), and program balance to provide overall value to the Government. The Government reserves the right to request any additional, necessary documentation once it makes the award instrument determination. Such additional information may include but is not limited to Representations and Certifications (see Section VI.B.4 “

B. Fundamental Research III. Eligibility Information

A. Eligible Applicants

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

Entities

2. Other Applicants

B. Organizational Conflicts of Interest C. Cost Sharing/Matching D. Other Eligibility Criteria

1. Collaborative Efforts

2. Proposing to Multiple TAs

3. Ability to Support Classified Development

IV. Application and Submission Information A. Address to Request Application Package B. Content and Form of Application Submission

1. Abstract Format

2. Full Proposal Format

a. Volume I, Technical and Management Proposal

b. Volume II, Cost Proposal – {No Page Limit}

3. Proprietary Information

4. Security Information

a. Program Security Information

b. Controlled Unclassified Information (CUI)

i. CUI Proposal Markings

ii. CUI Submission Requirements

c. Unclassified Submissions

d. Both Classified and Unclassified Submissions

e. Classified Submissions

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

6. Human Subjects Research (HSR)/Animal Use

7. Approved Cost Accounting System Documentation

8. Section 508 of the Rehabilitation Act (29 U.S.C. § 749d)/FAR 39.2

9. Small Business Subcontracting Plan

10. Intellectual Property

a. For Procurement Contracts

b. For All Non-Procurement Contracts

11. Patents

12. System for Award Management (SAM) and Universal Identifier Requirements

13. Funding Restrictions

C. Submission Information

1. Submission Dates and Times

a. Abstract Due Date

b. Full Proposal Date

c. Frequently Asked Questions (FAQ)

2. Abstract Submission Information

3. Proposal Submission Information

a. For Proposers Requesting Cooperative Agreements:

b. For Proposers Requesting Technology Investment Agreements

c. For Proposers Requesting Contracts or Other Transaction Agreements

d. Classified Submission Information

4. Other Submission Requirements V. Application Review Information

A. Evaluation Criteria

1. Overall Scientific and Technical Merit

2. Potential Contribution and Relevance to the DARPA Mission

3. Cost Realism

4. Realism of Proposed Schedule

B. Review and Selection Process

1. Review Process

2. Handling of Source Selection Information

3. Federal Awardee Performance and Integrity Information (FAPIIS)

4. Countering Foreign Influence Program (CFIP) VI. Award Administration Information

A. Selection Notices

1. Abstracts

2. Proposals

B. Administrative and National Policy Requirements

1. Meeting and Travel Requirements

2. Solicitation Provisions and Award Clauses, Terms and Conditions

3. Controlled Unclassified Information (CUI) and Controlled Technical Information

(CTI) on Non-DoD Information Systems

4. Representations and Certifications

5. Terms and Conditions

C. Reporting D. Electronic Systems

1. Wide Area Work Flow (WAWF)

2. i-Edison

3. Vault

4. DARPA Embedded Entrepreneurship Initiative (EEI)

VII. Agency Contacts VIII. Other Information

A. Proposers Day B. University Student and Research C. Associate Contract Agreements

ATTACHMENT 1: Cost Volume Proposer Checklist ATTACHMENT 2: Proposal Summary Slide Template ATTACHMENT 3: Standard Cost Proposal Spreadsheet ATTACHMENT 4: Other Transaction Certification Template ATTACHMENT 5: FIRE Controlled Unclassified Information Guide ATTACHMENT 6: SECRET Guide and SECRET BAA Addendum Request Form

PART I: OVERVIEW INFORMATION

Federal Agency Name: Defense Advanced Research Projects Agency (DARPA), Microsystems Technology Office (MTO)

Funding Opportunity Title: Faithful Integrated Reverse-Engineering and Exploitation

(FIRE)

Announcement Type: Initial Announcement Funding Opportunity Number: HR001123S0025 Catalog of Federal Domestic Assistance Numbers (CFDA): 12.910 Research and

Technology Development Dates: (All times listed herein are Eastern Time) o Posting Date: March 15, 2023 o Proposers Day: March 16, 2023 o Abstract Due Date: March 31, 2023 o FAQ Submission Deadline: April 21, 2023 o Proposal Due Date: May 19, 2023 o Estimated period of performance start: October, 2023

Concise description of the funding opportunity: The Faithful Integrated Reverse- Engineering and Exploitation (FIRE) program seeks to develop tools that provide a transformative end-to-end capability from system acquisition to exploitation, including preparation.

Anticipated Funding Available for Award: $70M Anticipated individual awards: DARPA anticipates multiple awards for all Technical

Areas (TAs).

Anticipated funding type: 6.2 Types of instruments that may be awarded: Cooperative Agreement, Procurement contract, or other transaction. Grants will not be considered.

Agency contact:

BAA Coordinator: FIREProgram@darpa.mil

DARPA/MTO

ATTN: HR001123S0025

675 North Randolph Street Arlington, VA 22203-2114 mailto:FIREProgram@darpa.mil

PART II: FULL TEXT OF ANNOUNCEMENT

I. Funding Opportunity Description

The Defense Advanced Research Projects Agency (DARPA) often selects its research efforts through the Broad Agency Announcement (BAA) process. This BAA is being issued, and any resultant selection will be made, using the procedures under Federal Acquisition Regulation (FAR) 6.102(d)(2) and 35.016 and 2 C.F.R. § 200.203. Any negotiations and/or awards will use procedures under FAR 15.4, Contract Pricing. 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 System for Award Management (SAM) website, under the Contract Opportunities link, at https://sam.gov/.The following information is for those wishing to respond to the BAA.

The Microsystems Technology Office (MTO) at DARPA seeks proposals that provide a strong and innovative technical approach that show a constructive plan to fully address the FIRE program goals and metrics. Proposers 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.

The FIRE BAA has a classified addendum that is strongly encouraged for TA4 and TA5 proposers and optional for TA1, TA2, and TA3. Please fill out Attachment 6 for more information.

A. Background The Faithful Integrated Reverse-engineering and Exploitation (FIRE) program seeks to develop transformative tools to find, exploit, and patch vulnerabilities in medium-complexity cyber-physical systems (CPS) within a month from when the physical system is delivered to the analysis team. FIRE is primarily interested in cyber-physical vulnerabilities (CPV), ones that arise from the composition of hardware, software, and physical components where each component may not be vulnerable in-and-of itself.

https://sam.gov/

Figure 1. A quadcopter is an example of a cyber-physical system that operates in the physical world using hardware sensors to perceive the analog environment, digital software for processing, and actuators to interact with the environment.

The FIRE goals are driven by the proliferation of low-cost commercial-off-the-shelf (COTS) components (e.g., sensors, actuators, and algorithms) resulting in diverse classes of CPS including smart meters, medical devices, autonomous vehicles, and industrial control systems to name a few.

Furthermore, agile development practices have shown that even highly complex systems such as a car can be remotely patched every few weeks. Innovative CPS vulnerability analysis tools and techniques are needed to keep pace with increased system diversity and decreased analysis timelines.

The FIRE program uses the following definitions:

Cyber Component: Hardware or software that performs a unique function Physical Component: A part that interacts with the environment, e.g. motors, rotors Hardware (HW): Electronic components, e.g., sensors, filters, communications, FPGAs

(field programable gate arrays), and CPUs (central processing units) Software (SW): Components used to reconfigure hardware such as FPGAs and CPUs Cyber-Physical System (CPS): A system composed of cyber (hardware and software) components, physical components (such as rotors) that operate in the physical environment (see Figure 1)

Medium-complexity CPS: A CPS consisting of ~1000 SW and ~100 HW components.

Plant: The physical properties of a CPS; the totality of the physical components Vulnerability: A property that can lead to unexpected behavior(s) Exploit: Inputs and conditions that use a vulnerability to cause an observable unexpected behavior Patch: A change to a system that removes unexpected behaviors (vulnerabilities) while maintaining expected behaviors; patches might neither be appropriate nor possible until expected behaviors are exhaustively defined

Vulnerability Analysis (VA): The act of finding, exploiting, and patching (when possible and appropriate) vulnerabilities

The FIRE program has five (5) technical areas (TAs):

TA1 Modeling will seek to develop tools that can model entire systems (to include hardware, software, and physical) with enough fidelity to find, exploit, and patch vulnerabilities, and are fast enough to meet the overall one-month program goal.

TA2 Simulation will seek to develop simulators that have enough precision to model interactions between system components and are fast enough to meet the overall program goals.

TA3 Preparation will seek to develop tools that reduce the amount of time needed to prepare a system for analysis to include techniques to accurately identify components, connections, and/or board layouts.

TA4 Integration will seek to create the FIRE tool(s) that meet the overall one-month program metric by integrating TA1, TA2, and TA3 solutions.

TA5 Engineering Support Task will seek to work with government and Independent Verification and Validation (IV&V) teams to develop representative medium-complexity CPS with full data rights for TA1, TA2, TA3, and TA4 performers to test, evaluate, and demonstrate their solutions.

DARPA strongly prefers proposals that respond to either all of TA1 through TA4 or TA5. However individual proposals to TA1, TA2, TA3, or TA4, will also be considered if sufficient funding is available.

Scalable automated software vulnerability analysis techniques pioneered by previous DARPA programs (such as the DARPA Cyber Grand Challenge) are now standard practice. Large commercial organizations and multiple open-source projects (e.g., Continuous Fuzzing for Open Source Software - OSSFuzz) use techniques such as guided fuzzing and symbolic analysis to find software vulnerabilities and generate software exploits. Software patches to these exploits can be generated in cases where expected behaviors are exhaustively defined.

The FIRE program seeks to develop innovative tools that can scale automated vulnerability analysis beyond software systems and into CPS by overcoming the preparation, modeling, and simulation technical challenges.

Cyber-physical systems (such as the quadcopter depicted in Figure 1) operate in the physical world using hardware sensors to perceive the analog environment, digital software for processing, and actuators to interact with the environment. The same applies to cyber-physical vulnerability analysis (CPVA). Similar to how software vulnerability analysis depends on the accuracy of all aspects of software execution (including, but not limited to, protocols, system calls, and instruction set architectures), CPVA is expected to depend on the accuracy of all aspects of cyber-physical execution (including hardware, software, plant, and environment.) The FIRE program is only interested in tools for cyber-physical vulnerabilities, tools that address ONLY cyber vulnerabilities or ONLY physical vulnerabilities are outside of the scope of the program.

To illustrate, consider a simple COTS quadcopter composed of

A hardware MEMS (Micro-Electro-Mechanical Systems) accelerometer to perceive its linear and angular accelerations; this sensor has a data corruption vulnerability due to acoustic interference1

Motors and rotors to produce lift and controlled flight A software program to ensure stability by periodically monitoring accelerometer inputs and generating corresponding rotor outputs

A software-only vulnerability analysis will not be able to detect and recognize the MEMS vulnerability. The hardware sensor must also be modeled. Conversely, the sensor vulnerability might not result in a cyber-physical effect if the corruption is filtered or otherwise accounted for by the control software. That is, while the data corruption behavior is unexpected at the MEMS component level, it was expected and therefore accounted for at the CPS level. It is not a CPV.

1 https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/son

Similarly, a drone that is resting on the ground is not useful for demonstrating an exploit that causes the system to descend.

CPVA requires context from hardware, software, plant, and environment. In the example, the quadcopter has a cyber-physical vulnerability. If the quadcopter uses the problematic MEMS accelerometer, there is no additional filtering, and the system is in flight. An exploit for this vulnerability might be a specific signal that causes the quadcopter to crash, and a patch might be a software filter to remove the RF interference while maintaining expected behaviors.

A medium-complexity cyber-physical system is expected to have tens to hundreds of hardware components and up to thousands of software components that perform unique functions. This includes systems ranging from smart meters to some industrial control systems and autonomous vehicles. The simple six degrees of freedom quadcopter mentioned above has only eleven hardware components (six sensors for each degree of freedom, four actuators, and one processor for software) with an unspecified number of software components.

B. Program Description The FIRE program seeks innovative solutions to find, exploit, and patch vulnerabilities in medium-complexity CPS within a month of an analysis team receiving the physical system. This could be accomplished by overcoming three technical challenges: 1) modeling, 2) simulation, and 3) preparation. This may also require creating a new discipline that bridges mechanical engineering, computer science, electrical engineering, mathematics, and cybersecurity so that proper tradeoffs can be made when integrating the solutions into a single set of tools. The program metrics are defined in Figure 2.

1CPVA Accuracy: the model’s ability to predict an exploit’s effect 2Simulation Time: the time needed to simulate one second of real time 3Preparation Time: the time needed to identify components, their inter-dependencies, analysis point locations, and how the analysis points can be used 4CPVA Development Time: the total time from receiving CPS to exploit including preparation

Figure 2. Program Metrics

Metrics will be evaluated using a specially designed test and evaluation platform (see TA5 description) with known cyber-physical vulnerabilities inserted by the IV&V team. This will serve as the ground truth. Previously unknown vulnerabilities found by performers and verified by IV&V will be added to the corpus for test and evaluation purposes. Since not all vulnerabilities can be successfully demonstrated to be correct and successfully patched, but all exploits can be successfully demonstrated, the FIRE program uses exploits as the basis for metrics. Patching tools and techniques, while not directly measured, are still of interest to the FIRE program. Proposers are encouraged to identify additional metrics in their technical approaches.

DARPA may establish a government-run, incremental, and iterative development and operations (DevOps) pipeline to accelerate the creation, adoption, and delivery of FIRE tools into transition partner ecosystems. The pipeline will also enable collaboration between each of the TAs to facilitate earlier and easier integration. The pipeline will provide an environment where operational users, developers, and researchers can engage collaboratively in the creative process to converge on solutions that neither group(s) would conceive in isolation.

1. TA1 Modeling: Scaling Complexity in Models while Maintaining Accuracy Accurate models run the risk of losing accuracy once the complexity starts increasing. Software vulnerability analysis has traditionally focused on a small variety of systems (such as Windows, Linux, iOS, Android on x86, and ARM). Large corpora of software can be analyzed once models for this small set of systems is created – often by hand. This approach is not practical for CPS, where both hardware and software are reconfigurable. In addition to general purpose central processing units, CPS often contain digital signal processors (DSP), FPGAs, programmable logic controllers (PLC), etc. All of these components and their software-like programs will likely need to be modeled in order to properly support CPVA. Furthermore, hardware sensors, discrete electronic components, the physical characteristics of the plant and environment, any timing-sensitive behaviors, etc. might need to be modeled as well. Special consideration should be paid to modeling explicit and implied timing-sensitive behaviors of individual components as well as across HW, SW and physical components.

Since the modeling space is enormous, guided modeling tools and techniques are needed to balance model accuracy with performance. The model accuracy needed for finding vulnerabilities may be different from that needed for predicting the effects of an exploit on the actual system which may also be different from that needed to patch CPS. Proposals should describe these differences, if any, their implications to the CPVA workflow, and corresponding mitigating approaches in the technical proposal.

The FIRE program is interested in tools and techniques to perform vulnerability analysis with imperfect models, not tools and techniques to create perfect models for vulnerability analysis. The latter approach is likely not have the performance required to meet program goals. Potential approaches include, but are not limited to, falsification, adaptive partitioning, automated model inference and system identification, and abstract surrogates.

The program goal of TA1 is to develop tools and solutions to assist TA4 solutions in finding, exploiting, and patching (when possible and appropriate) CPVs within the overarching program metrics. The TA1 proposal should address:

Models at different levels of abstractions such as component, sub-system and system levels Optimization strategies to utilize available time prior to when the CPS is received Situations where components might be damaged, inaccessible or incomplete (e.g., only one side of a two-way communication) The ability to continuously improve models over time and across systems

Proposers bidding to all TA1 through TA4 should consider inter-dependencies and impacts across all TAs. This includes, but is not limited to, information needed from TA3 performers, dependencies on debug accesses from TA5 performers, and reliance on access to facilities for physical measurements if needed. TA1 proposers should also consider the impact of models and representations (e.g., data formats) on the overall CPVA goal. Different data formats may impact the performance of TA2 simulators and vice versa. TA1 proposers are encouraged to differentiate between model inaccuracy, imprecision, and errors as well as how to identify and fix them.

2. TA2 Simulation: Maintaining synchronization in simulations as the size of the system grows

Timing accuracy in simulations decreases as simulations increase in size and complexity. For example, timing jitter is an important consideration for embedded systems design and therefore may need to be accurately simulated. Furthermore, cyber-physical systems are composed of distributed concurrent hardware, software, and physical components operating in both discrete and continuous time domains, which make synchronizing time infeasible in general. Traditional simulation techniques used hardware-in-the-loop to overcome timing and synchronization, but this limits scaling to the number of physical systems that could be used in hardware-in-the-loop. The increased diversity and decreased timelines of system updates creates a need for more scalable and performant approaches.

Guided simulation tools and techniques are needed that can find the balanced zone of synchronizing just the components that need to be synchronized, with just the necessary time granularity and just the right timing disturbances in order to perform CPVA. Potential approaches include, but not limited to, dynamic temporal decoupling, limiting simulation time horizons, dynamic detection, and temporal logic(s).

An overarching goal of TA2 tools and solutions is to scale CPVA beyond the limits of hardware-in-the-loop analysis. The TA2 proposal should address:

Simulators that enable analyses in virtual environments Scalability to available compute resources rather than physical systems Optimization strategies to utilize available time prior to when the CPS is received The ability to continuously improve simulations across time and across systems

Proposers bidding to all TA1 through TA4 should consider inter-dependencies and impacts across all TAs. For example, proposals should consider the differences between event ordering accuracy and timing accuracy since these can depend on TA1 and TA3 capabilities and can impact TA4 algorithms. Similarly, TA2 proposers are encouraged to differentiate between inaccuracies, imprecision, and errors, as well as how to identify and fix them. TA2 proposers are encouraged to consider the differences between clock domains such as those, at the hardware component, board, communications bus, control systems, and processor levels. They are also encouraged to consider the differences between clocks, events, interrupts, etc. These may pose unique challenges and opportunities and should be described in the technical proposal.

3. TA3 Preparation The tangible nature of CPS imposes additional constraints that challenge existing analysis techniques. It is necessary, but not sufficient, to simply extract firmware/software from a CPS. The timing, data, and control dependencies between hardware and software components might need to be exposed before modeling and simulation can begin. After modeling and simulation has begun, it may be necessary to continuously guide the exploit analysis by gathering information on and/or setting the CPS context (also known as the CPS state.)

The CPS context is expected to be component and CPS specific, which will require automated tools and techniques to uniquely identify the components, their inter-dependencies, and analysis points where the context can be gathered and/or set. At a minimum, TA3 solutions will provide a list of components (also known as a bill of materials), their inter-dependencies, candidate analysis points, and how the points can be used.

Potential approaches include, but are not limited to, multi-modal imaging, electro-magnetic emanations, and side channel analysis.

The overarching goal of TA3 is to provide the information necessary to enable TA1, TA2, and TA4 tools and solutions as early in the program as possible. However, it is important to focus on working towards the one-month FIRE program goal. TA3 involvement does not have to end after the minimum information has been provided. The TA3 proposal should address:

Optimization strategies to utilize available time prior to when the CPS is received Data formats and interfaces so TA1, TA2, and TA4 tools can quickly ingest and act upon new TA3 information Providing staggered or incremental updates across the entire one-month analysis timeframe after satisfying the initial Preparation Time metric Analysis points for analog (e.g., oscilloscopes), digital (e.g., logic analyzers), and logical

(e.g., breakpoints) means of gathering and setting CPS context

Proposers bidding to all TA1 through TA4 should consider inter-dependencies and impacts across all TAs. For example, strong proposals might consider the benefits of providing physical access to analysis tap points for TA1, TA2, and TA4 performers rather than simply identifying them. Strong proposals should consider first providing information such as a bill of materials, data sheets, software/firmware images, data dependencies, images, and high-level system description.

4. TA4 Integration: The CPVA Tool(s) The overarching goal of the FIRE program is to find, exploit, and patch vulnerabilities in CPS within a month. It is expected that the CPVA tool(s) can be created by integrating and guiding preparation activities and tools for modeling and simulation towards finding, exploiting, and potentially patching vulnerabilities. Disjoint solutions and simple agile feedback mechanisms will likely not work. This multi-aspect optimization and search problem requires new algorithms and approaches for CPVA.

Traditional vulnerability analysis algorithms such as guided fuzzing, symbolic and concolic analysis, abstract interpretation, data and control flow, etc. will require refinements or entirely new variants for CPVA. Potential approaches include, but are not limited to, cyber-physical dependence graphs (similar to program dependence graphs), policy-guided analysis, trace-based analysis, hardware-on-the-loop analysis, and state estimation and homing.

The TA4 proposal should address:

The breadth of possible CPS components that need to be analyzed and prioritizing research and development tasks accordingly

The ability to perform a single analysis (e.g., track data) across multiple components such as when an analog signal reaches an antenna, is processed by a software defined radio, is further post processed by a DSP, passed to a PLC, and is then passed to a CPU

Hybrid analysis algorithms that combine static and dynamic analysis concepts Differences between cyber-physical system contexts and traditional software-only system contexts that only include CPU and memory states How gathering and setting state is not only limited, but also driven by, available test points, probes, lab equipment, etc.

Performance and scalability limitations due to potential need for physical systems such as for hardware-in-the-loop analysis Performing vulnerability analysis despite having damaged, inaccessible, or incomplete components, models, and/or simulators Programmability and extensibility of solutions to include both software and hardware (e.g., lab equipment)

Proposers bidding to all TA1 through TA4 should consider inter-dependencies and impacts across all TAs. Additionally, TA4 proposals are encouraged to consider the benefits of having interchangeable TA1, TA2, and TA3 approaches during program execution, and should describe strategies to achieve this in the technical approach.

TA4 proposers must consider inter-dependencies and impacts across all TAs. Strong proposals will, at a minimum, consider the technical, management, and schedule challenges to integration.

These can include, but are not limited to, complementary TA1, TA2, and TA3, approaches, diversity and depth of expertise and experience, team organization, coordination, collaboration, internal milestones, and test and evaluation timelines.

TA4 proposals should include a notional workflow on how and when CPVA activities will take place over the course of the one-month program metric. TA4 proposals should describe the variety of laboratory and test equipment needed as well as the ability to orchestrate analysis through them.

For proposers with access to the classified addendum, it is strongly recommended that TA4 proposals describe how these tools will be used in the classified use case.

TA4 performers will participate in demonstrations on real-world systems of interest. The performance in demonstration events may be taken into consideration for down-selects. Additional information can be found in the classified addendum. TA4 proposals should also consider potential impacts of personnel, facilities, and equipment to participating in demonstrations and how specific demonstration systems may impact personnel and tools.

5. TA5 Engineering Support Task: Evaluation and Testing Evaluating the quality of vulnerability analysis tools is difficult without ground truth. In addition to solving the technical challenges and integrating the solutions into usable tools as outlined above, there also is a need to create representative medium-complexity CPS for test and evaluation (T&E) purposes. These T&E systems must not be restricted by data rights and must contain realistic cyber-physical vulnerabilities for CPVA without violating existing laws, statutes, or policies. At the same time, for potential transition purposes there is a need to perform CPVA on systems of DoD interest with real vulnerabilities. This requires additional protections and safeguards that include, but are not limited to, creating surrogate systems and performing evaluations in secure environments. These surrogate systems will be used for demonstration purposes only.

The overarching goal of TA5 is to support the IV&V team in building, distributing, and supporting T&E systems and surrogate systems. There are two tracks of TA5 tasks and proposers are highly encouraged to propose to both tracks, although outstanding proposals to only one track may be considered.

a. Track A: Test and Evaluation Systems In Track A, TA5 performers will develop an open, data-rights free, experimentation platform for cyber-physical vulnerability analysis. The FIRE program is interested in CPS systems that have available low-cost COTS components (such as a wide variety of sensors and actuators) to create a variety of missions and effects at a low cost. The potential experimentation platform should have a wide variety of test facilities that are readily available.

TA5 Track A proposals should consider:

Balancing the need to provide physical test articles for TA1, TA2, TA3, and TA4 performers without biasing towards specific approaches

Anticipating different types of vulnerabilities, effects, and patches that may need to be implemented and how they impact the overall system design

Extensible architectures that can represent multiple CPS types such as rotorcraft unmanned aerial systems (UAS), space, ground, sea, undersea, medical, industrial control systems, etc.

The ability to upgrade and update systems rather than building entirely new systems for each delivery in order to meet program schedules

The need for IV&V to verify vulnerabilities, exploits, and patches found by TA1 through TA4 performers to include both known vulnerabilities inserted by IV&V and unknown vulnerabilities that must be verified by IV&V

Safety considerations such as moving surfaces, electro-magnetic emanations, and noise

TA5 proposers should consider software and hardware interfaces with other TAs. TA5 cost proposals should provide a per-unit cost estimate for the proposed test and evaluation platform.

They also should estimate the cost of an expected minimum number of 50 (fifty) systems for the program.

b. Track B: Surrogate Systems Proposers bidding on TA5 Track B must have a security clearance and be cleared. In addition to T&E systems, the FIRE program is interested in TA5 proposals that can work with government team(s) to build surrogates of real-world systems of interest for demonstration purposes. These systems may have real-world vulnerabilities, both known and unknown, for real systems and therefore TA5 proposers must have the security clearances, facilities, and capabilities to perform this work. Additional information can be found in the classified addendum.

C. Program Structure FIRE is a 42-month, two-phase program that comprises five technical areas (TAs.) The goal of each phase is listed below:

Phase 1a (18 months, Base): Validate the feasibility of the approaches

Phase 1b (6 months, Option 1): Perform real-world demonstration of the approaches Phase 2a (12 months, Option 2): Scale the approaches to medium-complexity systems Phase 2b (6 months, Option 3): Perform final demonstrations

FIRE tool(s) will be demonstrated on systems of increasing complexity, and will be evaluated by a government IV&V team. The IV&V team will insert exploitable vulnerabilities into the test and evaluation systems developed by TA5 performers for TA1-TA4 performers.

Proposers must propose to all phases and all options and their proposal must address the metrics for each phase. Options may be exercised, at the Government’s sole discretion, based on technical progress against the metrics and milestones defined in the BAA and funding availability.

Performers are expected to provide continuous integration and continuous delivery pipelines that enable government independent verification and validation (IV&V) to rapidly test and validate the performer tools.

DARPA may establish a government-run, incremental, and iterative DevOps pipeline to accelerate the creation, adoption, and delivery of FIRE tools into transition partner ecosystems. The pipeline will also enable collaboration between each of the TAs to facilitate earlier and easier integration.

The pipeline will provide an environment where operational users, developers, and researchers can engage collaboratively in the creative process to converge on solutions that neither group(s) would conceive in isolation. To this end, in-person technical exchanges, hackathons, and virtual technical exchanges may be planned once development environments become operational. As capabilities mature, pilot tests with operational user communities of significant size and diversity may be conducted to assess the viability and generality of the approaches.

D. Schedule/Milestones The government will specify the locations for quarterly program reviews, demonstrations, and kickoff/PI meetings. For budgeting purposes, assume the quarterly program reviews will alternate between Arlington, VA, and Philadelphia, PA.

Figure 3. Program schedule and milestones.

Major Milestones:

Kickoff – 1 month Post Contract Award (PCA) Quarterly program reviews, every 3 months PCA EOP1 – 18 months PCA Demo 1 – 24 months PCA

TA1 & TA2 & TA3 Major Milestones:

Delivery 1 of tools – 6 months PCA Delivery 2 of tools – 10 months PCA Delivery 3 of tools – 14 months PCA Delivery 4 of tools – 28 months PCA Delivery 5 of tools – 32 months PCA Delivery 6 of tools – 36 months PCA

TA4 Major Milestones:

Interface Control Document/Application Programming Interface – 3 months PCA Delivery 1 of tools – 10 months PCA Delivery 2 of tools – 14 months PCA Delivery 3 of tools – 28 months PCA Delivery 4 of tools – 32 months PCA Delivery 5 of tools – 36 months PCA

TA5 Major Milestones:

Delivery 1 of demonstration platform – 6 months PCA Delivery 2 of demonstration platform – 10 months PCA Delivery 3 of demonstration platform – 14 months PCA Delivery 4 of demonstration platform – 28 months PCA Delivery 5 of demonstration platform – 32 months PCA Delivery 6 of demonstration platform – 36 months PCA

E. Deliverables Proposers are encouraged to discuss how their tools and deliverables could leverage the DevOps pipeline, provide feedback on additional technology the DevOps pipeline needs to support transition, and integrate with relevant government transition partners.

Proposers are responsible for providing the following deliverables:

Slide Presentations – Annotated slide presentations are due 24 hours before the program kick-off meeting and after each review.

Monthly Financial Reporting – Each team must submit monthly expenditure reports and any associated deliverables within fifteen (15) calendar days after the end of each month.

Monthly Technical Status Report – A quarterly technical status report is due ten (10) calendar days after the end of each quarter. The report must describe technical progress made, progress towards TA metrics, resources expended, and any issues that require the attention of the government team.

Quarterly Program Review – Each team will attend a quarterly program review that provides technical status, resources expended, and progress towards metrics.

Phase and Final Technical Reporting – End-of-phase reports are due at the conclusion of each phase. A separate Final Technical Report is due at the end of the period of performance. The unclassified reports will concisely summarize the effort conducted and provide any lessons learned during the development of the technology.

Software – All computer software developed or utilized during the program must be delivered as source and executable code. The source versions and source code for the target computer systems, as well as any build scripts or other technical information required for the Government to compile and configure all delivered source code must also be included.

Delivered software under this effort is to be maintainable and modifiable with no reliance on any non-delivered computer programs or documentation. Software is expected to be delivered utilizing continuous delivery and integration methods. At the end of each phase, software deliverables must also include unit tests to help the Government quickly determine whether the software is running as expected.

Software Documentation – Software documentation deliverables are due ten (10) calendar days after the delivery of each software. Documentation must describe the source code, build system, hardware description language specifications, system diagrams, part numbers, and any other data necessary to build, maintain, and produce copies of the software.

Hardware – All hardware procured or developed under the program will be delivered to the Government. The delivery should include sufficient documentation to be completely operable, maintainable, and modifiable with no-reliance on any non-delivered hardware or hardware documentation. The delivery should also include unit tests to help the Government quickly determine whether the hardware is running as expected.

F. Government Furnished Equipment/Property/Information DARPA does not intend to provide specialized equipment, facilities, or support to the performers.

Government furnished property of demonstration and test and evaluation systems is expected throughout the program. These demonstration systems are separate from the test and evaluation systems used to measure metrics. This is primarily for TA4 and TA5 performers. Please see the classified addendum for additional information on the demonstration systems.

G. Intellectual Property Transitioning the capabilities and providing tools that foster and enable a greater community in cyber-physical capabilities is a core tenant of the FIRE program. It is strongly desired that the end intellectual property is provided with Unlimited rights or with Government Purpose Rights (GPR) at a minimum. It is further encouraged to provide data rights that enable sharing, such as through open-source licenses, to provide a foundation for the community to continuously expand and grow the tools.

II. Award Information A. General Award Information

Multiple awards are anticipated. The amount of resources made available under this BAA will depend on the quality of the proposals received and the availability of funds.

The Government reserves the right to select for negotiation all, some, one, or none of the proposals received in response to this solicitation, and to make awards without discussions with proposers.

The Government also reserves the right to conduct discussions if it is later determined to be necessary. If warranted, portions of resulting awards may be segregated into pre-priced options.

Additionally, DARPA reserves the right to accept proposals in their entirety or to select only portions of proposals for award. In the event that DARPA desires to award only portions of a proposal, negotiations may be opened with that proposer. The Government reserves the right to fund proposals in phases with options for continued work at the end of one or more of the phases, as applicable.

1. Awards under this BAA will be made to proposers on the basis of the evaluation criteria listed below (see section labeled “Application Review Information” Sec.

V.), and program balance to provide overall value to the Government. The Government reserves the right to request any additional, necessary documentation once it makes the award instrument determination. Such additional information may include but is not limited to Representations and Certifications (see Section VI.B.4 “

Further information on Controlled Unclassified Information identification, marking, protecting and control, to include processing on Non-DoD Information Systems, is incorporated herein and can be found at www.darpa.mil/work-with-us/additional-baa.

Representations and Certifications”). The Government reserves the right to remove proposers from award consideration should the parties fail to reach agreement on award terms, conditions and cost/price within a reasonable time or the proposer fails to timely provide requested additional information. Proposals identified for negotiation may result in a procurement contract, cooperative agreement, or other transaction, depending upon the nature of the work proposed, the required degree of interaction between parties, whether or not the research is classified as Fundamental Research, and other factors 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. § 4022(f), the Government may award a follow-on production contract or Other Transaction (OT) for any OT awarded under this solicitation 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 http://www.darpa.mil/work-with-us/contract-management#OtherTransactions http://www.darpa.mil/work-with-us/contract-management#OtherTransactions 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 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 solicitation, 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.

University or non-profit research institution performance under this solicitation may include effort categorized as fundamental research. In addition to Government support for free and open scientific exchanges and dissemination of research results in a broad and unrestricted manner, the academic or non-profit research performer or recipient, regardless of tier, acknowledges that such research may have implications that are important to U.S. national interests and must be protected against foreign influence and exploitation. As such, the academic or non-profit research performer or recipient agrees to comply with the following requirements:

(a) The University or non-profit research institution performer or recipient must establish and maintain an internal process or procedure to address foreign talent programs, conflicts of commitment, conflicts of interest, and research integrity. The academic or non-profit research performer or recipient must also utilize due diligence to identify Foreign Components or participation by Senior/Key Personnel in Foreign Government Talent Recruitment Programs and agree to share such information with the Government upon request.

i. The above described information will be provided to the Government as part of the proposal response to the solicitation and will be reviewed and assessed prior to award. Generally, this information will be included in the Research and Related Senior/Key Personnel Profile (Expanded) form (SF-424) required as part the proposer’s submission through Grants.gov.

1. Instructions regarding how to fill out the SF-424 and its biographical sketch can be found through Grants.gov.

ii. In accordance with USD(R&E) direction to mitigate undue foreign influence in DoD-funded science and technology, DARPA will assess all Senior/Key Personnel proposed to support DARPA grants and cooperative agreements for potential undue foreign influence risk factors relating to professional and financial activities. This will be done by evaluating information provided via the SF-424, and any accompanying or referenced documents, in order to identify and assess any associations or affiliations the Senior/Key Personnel may have with foreign strategic competitors or countries that have a history of intellectual property theft, research misconduct, or history of targeting U.S. technology for unauthorized transfer. DARPA’s evaluation takes into consideration the entirety of the Senior/Key Personnel’s SF-424, current and pending support, and biographical sketch, placing the most weight on the Senior/Key Person’s professional and financial activities over the last 4 years. The majority of foreign entities lists used to make these determinations are publicly available. The DARPA Countering Foreign Influence Program (CFIP) “Senior/Key Personnel Foreign Influence Risk Rubric” details the various risk ratings and factors. The rubric can be seen at the following link:

https://www.darpa.mil/attachments/092021DARPACFIPRubric.pdf

iii. Examples of lists that DARPA leverages to assess potential undue foreign influence factors include, but are not limited to:

1. Executive Order 13959 “Addressing the Threat From Securities Investments That Finance Communist Chinese Military Companies”:

https://www.govinfo.gov/content/pkg/FR-2020-11-17/pdf/2020-25459.pdf

2. The U.S. Department of Education’s College Foreign Gift and Contract Report: College Foreign Gift Reporting (ed.gov)

3. The U.S. Department of Commerce, Bureau of Industry and Security, List of Parties of Concern: https://www.bis.doc.gov/index.php/policy-guidance/lists-of-parties-of-concern

4. Georgetown University’s Center for Security and Emerging Technology (CSET) Chinese Talent Program Tracker:

https://chinatalenttracker.cset.tech

5. Director of National Intelligence (DNI) “World Wide Threat Assessment of the US Intelligence Community”: 2021 Annual Threat Assessment of the U.S. Intelligence Community (dni.gov)

6. Various Defense Counterintelligence and Security Agency (DCSA) products regarding targeting of US technologies, adversary targeting of academia, and the exploitation of academic experts: https://www.dcsa.mil/

(b) DARPA’s analysis and assessment of affiliations and associations of Senior/Key Personnel is compliant with Title VI of the Civil Rights Act of 1964.