HR001122S0006.pdf

Broad Agency Announcement

Signature Management using Operational Knowledge and

Environments (SMOKE)

INFORMATION INNOVATION OFFICE

HR001122S0006

12/6/2021

TABLE OF CONTENTS

PART I: OVERVIEW INFORMATION

PART II: FULL TEXT OF ANNOUNCEMENT

I. Funding Opportunity Description

A. Program Overview B. Program Structure C. Program Phases and Metrics D. Government-Furnished Property/Equipment/Information E. Intellectual Property

II. Award Information A. General Award Information B. Fundamental Research

III. Eligibility Information A. Eligible Applicants B. Organizational Conflicts of Interest C. Cost Sharing/Matching D. Other Eligibility Criteria

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

V. Application Review Information A. Evaluation Criteria B. Review of Proposals

VI. Award Administration Information A. Selection Notices and Notifications B. Administrative and National Policy Requirements C. Reporting D. Electronic Systems E. DARPA Embedded Entrepreneur Initiative (EEI)

VII. Agency Contacts VIII. Other Information

IX. APPENDIX 1 – PROPOSAL SUMMARY SLIDE

PART I: OVERVIEW INFORMATION

Federal Agency Name – Defense Advanced Research Projects Agency (DARPA), Information Innovation Office (I2O) Funding Opportunity Title – Signature Management using Operational Knowledge and

Environments (SMOKE) Announcement Type – Initial announcement Funding Opportunity Number – HR001122S0006 Catalog of Federal Domestic Assistance Numbers (CFDA) – Not applicable.

Dates o Posting Date: December 6, 2021 o Proposers Day: December 7, 2021 o Questions Due: January 25, 2022, 12:00 noon, Eastern Time o Proposal Due Date: January 31, 2022, 12:00 noon, Eastern Time o Solicitation Closing Date: May 30, 2022, 5:00 pm, Eastern Time

Program Overview – The SMOKE program will develop signature management technologies that generate evasive cyber infrastructure by incorporating counter-attribution techniques into the design process; quantitatively measuring attribution risk in real-time; and by maintaining evasiveness after infrastructure changes in order to accelerate red team cyber operations (CO) and eliminate signatures as a source of attribution.

Anticipated Individual Awards – There are two technical areas for this solicitation.

Multiple awards are anticipated in Technical Area 1 and Technical Area 2.

Types of Instruments that May be Awarded – Procurement Contracts, or Other Transactions for Prototype

Agency Contacts o Points of Contact

The BAA Coordinator for this effort can be reached at:

Email: SMOKE@darpa.mil

DARPA/I2O

ATTN: HR001122S0006

675 North Randolph Street Arlington, VA 22203-2114

PART II: FULL TEXT OF ANNOUNCEMENT

I. Funding Opportunity Description

This publication constitutes a Broad Agency Announcement (BAA) as contemplated in Federal Acquisition Regulation (FAR) 6.102(d)(2) and 35.016 and 2 C.F.R. § 200.203. Any resultant award negotiations will follow all pertinent law and regulation, and any negotiations and/or awards for procurement contracts will use procedures under FAR 15.4, Contract Pricing, as specified in the BAA.

The Defense Advanced Research Projects Agency (DARPA) is soliciting innovative proposals in the following technical areas:

signature reduction for red team cyber operations;

automated generation of evasive cyber infrastructure;

assessing and quantifying attribution risk for red team cyber operations; and signature generation for adversary cyber activities.

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.

A. Program Overview

Introduction and Background

Networks are under persistent threat from malicious cyber actors (MCAs). In response, a growing industry of network security professionals are offering realistic, threat informed assessments of network owners’ defensive posture. These assessments are performed by a team of ethical hackers (i.e., the red team) in which they assume the role of sophisticated MCAs and perform a controlled security test in collaboration with network defenders (i.e., the blue team).

Red team exercises are designed to exceed simple penetration testing and emulate MCA behaviours as realistically as possible. Realistic emulation of sophisticated cyber threats in a measured exercise is very helpful for providing a comprehensive picture of network defenders’ readiness.

Towards the aim of realism, red teams plan and deploy tactics, techniques, and procedures (TTPs) that mimic the most advanced cyber threats. Red teams use these TTPs to evade network defenders in order to achieve assessment objectives (e.g., move laterally in networks) and assess how critical networks and mission platforms fare against true MCAs.

A core aspect of red team security assessments are the TTPs used to build and deploy operational infrastructure (e.g., domain names, IP addresses, virtual servers) used for command and control (C2) of red team tools. This infrastructure must exist openly on the public Internet and emits signals that, if detected too easily, can end the assessment quickly without much gain, but at considerable expense. Repeated detection events can lead to patterns which can be crafted into signatures used to attribute red team activities. Signatures are characteristic patterns of the way an operator or organization performs cyber operations. Attribution is the ability to associate a cyber-attack with a responsible party through technical means such as detection and characterization of MCA behaviours (i.e., signatures) observed external to the assessed network.

For example, a class of attribution techniques discover patterns in associations to previously attributed cyber infrastructure. Security assessments can end quickly if the blue team prematurely detects these “guilt-by-association” indicators inside of the assessed network. The premature termination of an assessment is unfortunate, but limited to that specific engagement. If the blue team attributes those indicators to additional infrastructure outside of the assessed network, then the red team stands to lose infrastructure used across multiple network assessment engagements having consequences that outlast the current security assessment. This impairs the long-term effectiveness of the red team and thus requires more time and expense to recover.

The preparation of operational infrastructure that emulates sophisticated threats, evades detection, and reduces signatures requires a significant amount of time and subject matter expertise. Today, red teams study historic security incidents for TTPs of MCAs as attributed by cyber threat analysts and manually generate plans that emulate these threat actors. Indeed, red team operators transform informally documented notes into functional infrastructure and make large numbers of complex, interdependent decisions when deploying this infrastructure. Each decision generates observable emissions that form signatures across a variety of cyber datasets.

Such a manual approach to operational infrastructure creates attributable signatures and makes increasing the number of concurrent assessments difficult.

Today, the demand for network security assessments is greater than the supply because of a shortage of cyber expertise1 and a lack of automation. If successful, SMOKE will develop tools to automate the planning and deployment of threat emulated, attribution-aware cyber infrastructure. These tools will enable red teams to increase the scale, efficiency, duration, and effectiveness of cyber security assessments. Moreover, red teams will be able to provide longer cyber security assessments for a larger number of concurrent networks because of their ability to remain hidden for longer.

To improve the effectiveness of security assessments, the DARPA Information Innovation Office (I2O) is soliciting innovative research proposals for the development of tools that enable automated, scalable, and threat-emulated cyber infrastructure. In addition, these tools need to handle the management of the cyber infrastructure lifecycle (i.e., acquisition, usage, and disposal). The SMOKE program will develop, demonstrate, and evaluate these tools through red team security assessments on a range of diverse and realistic networks of interest.

Exemplary SMOKE Use Cases

The following discussion of exemplary use cases is provided to give concrete examples for some of the challenges the solutions may address. Proposers are encouraged to enhance it with other relevant challenges, systems, and solutions as needed to demonstrate technological acumen.

1 Director, Operational Test & Evaluation FY20 Cybersecurity Cyber Assessments

SMOKE will address the following strategic objectives important to the Department of Defense (DoD):

1. Generation of infrastructure configurations that conform to operational security (OPSEC) risk profiles.

In the context of red team cyber operation planning, SMOKE will inform cyber planners of attribution risk associated with infrastructure decisions and recommend configurations that adhere to OPSEC risk profiles. To achieve this goal, SMOKE may use a combination of active, passive, and indirect device enumeration and traffic analysis techniques, along with existing relevant data sets (public and/or commercially available), to identify and recommend infrastructure elements for plans that meet or exceed OPSEC requirements.

Planning algorithms would need to understand and explain the probabilities of reaching a desired end state using available tools and infrastructure elements as well as the attribution risk associated with each decision. Additionally, to realize these plans, SMOKE may use agents that can safely, reliably, and autonomously acquire, interact, and manage a diverse pool of available infrastructure elements in accordance with mission profiles.

2. Semi-autonomous Persistent Cyber Operations (PCO) for Director, Operational Test & Evaluation (DOT&E) to enable simultaneous cybersecurity assessments for DoD networks.

To accelerate red team cyber security assessments of DoD networks, SMOKE will automatically generate attack plans and set up C2 infrastructure that emulates advanced cyber threats. To achieve this goal, SMOKE will develop analytics that extract adversary signatures from relevant data sets (public and/or commercially available) and encode those signatures into recommended infrastructure plans. Red teams can choose which plans to execute and task SMOKE autonomous agents to set up and manage C2 infrastructure for simultaneous cybersecurity assessments of multiple DoD networks.

3. Real-time attribution risk assessments/feedback for cyber infrastructure and operational emissions.

For continuous surveillance of existing cyber infrastructure, SMOKE will provide real-time feedback on infrastructure and operational emissions that may lead to discovery by adversaries or other cyber defenders. To achieve this goal, SMOKE will develop sensors that can monitor infrastructure artifacts that appear in public or commercial datasets and provide real-time attribution risk assessments to ensure infrastructure remains within operational security requirements.

Program Scope

The SMOKE program will develop data-driven tools to automate the planning and execution of threat emulated cyber infrastructure needed for network security assessments (e.g., red team exercises). In a complementary activity, SMOKE will develop data-driven tools to automate the discovery of distinguishable patterns of sophisticated cyber threat infrastructure (i.e., signatures).

Together, SMOKE will prototype components that enable red teams to plan, build, and deploy cyber infrastructure that is informed by machine-readable signatures of sophisticated cyber threats.

Infrastructure planning research that fails to consider realistic network environments is out of scope. Likewise, signature discovery research that fails to provide real-time feedback to infrastructure planning is out of scope.

To ensure realism, SMOKE components will be evaluated on real-world networks controlled by SMOKE performers and/or Government partners. Initially, plans will be executed in simulated or emulated environments created by SMOKE performers. As components mature, plans may be executed on live networks as part of red team network security assessments. Further details on these use cases are described in Section I.A., Exemplary SMOKE Use Cases. Successful components may become candidates for transition.

Transition of SMOKE components is a priority and potential transition partners may include organizations such as DOT&E, DoD Services, and other Government organizations. Early and continuous input from SMOKE transition partners will ensure relevance and provide SMOKE with an understanding of the rapidly evolving state of security assessments. Proposers should explain how their approach will support experts in red team network assessments.

The program seeks breakthrough approaches to the following technical challenges, including but not limited to:

Abstracting away complexities of diverse network environments;

Operating in partially denied environments, reasoning under uncertainty, and reacting to unforeseen detection and/or attribution events;

Measuring tradeoffs among efficiency and effectiveness of plans in terms of speed and evasion;

Overcoming state space explosion of typical models for cyber infrastructure planning;

Developing mechanisms to acquire, manage, and maintain infrastructure elements that conform to signature management policies;

Executing infrastructure changes in accordance with real-time attribution assessments and plan contingencies;

Discovering latent associations between infrastructure artifacts;

Automating expert judgements used to build and traverse infrastructure associations; and Expanding our knowledge of adversary infrastructure.

B. Program Structure

SMOKE is a three-year effort divided into two 18-month phases. Phase 1 will focus on developing, demonstrating, and evaluating individual components. Phase 2 will focus on comparative evaluations formed by integrating program components. Not all efforts will align directly with program phases, so proposers should plan to adjust schedules based on results of Government evaluations and transition opportunities.

SMOKE will be divided into two technical areas (TAs) that will work in parallel throughout the program:

TA1 – Automated Planning and Execution of Attribution-Aware Cyber Infrastructure TA2 – Discover and Generate Infrastructure Signatures

It is expected that TA1 and TA2 performers will deliver components on an iterative and incremental basis to transition partners by leveraging the Constellation Pipeline described in this section, where they will be integrated into existing mission platforms for test and evaluation.

Proposers may only submit one proposal as lead institution per TA. Proposals must address only one TA. Proposers may submit as lead institution for at most two proposals, one for TA1 and one for TA2. Proposers may be selected for no TA awards, a TA1 award, a TA2 award, or two awards, namely for TA1 and TA2.

Proposers are strongly encouraged to offer up to two (2), 12-month options for additional integration work that will take place within the Constellation Pipeline in parallel and/or beyond the three-year research and development portion of the program. In addition, proposers are encouraged to identify additional technologies that increase the operational use cases and associate them to proposal options. These options and their optional add-ons may or may not be exercised at the sole discretion of the Government.

The selected SMOKE performers are required to collaborate with each other. The Government has determined that an Associate Contractor Agreement (ACA) is necessary to help facilitate an open exchange of information and ensure complete compatibility between software components, the system architecture, equipment, data, and other program elements to prevent unnecessary duplication of effort, and to maximize commonality to guarantee appropriate coordination and integration of work. All selected performers will be required to have their ACAs in place prior to the program kick-off meeting.

The Government will assess performer progress with regular technology evaluations and adversarial engagements driven by specific operational scenarios. The operational scenarios may incorporate red teams, U.S. Government cyber operators, and other elements. DARPA encourages technical efforts that allow for flexibility in testing and evaluation to take advantage of opportunities to access data sets under time constraints while permitting long-term research and development.

Proposers addressing either TA1 or TA2 may benefit from having personnel with Top Secret clearances that are eligible for Sensitive Compartmented Information (SCI) and, in particular, a Principal Investigator (PI) that has a Top Secret clearance and is eligible for SCI. Having cleared personnel or a cleared PI is not a requirement and will not be considered during TA1 and TA2 evaluations. Academic institution and small company participation is explicitly encouraged, regardless of any possession of security clearances.

Technical Areas

DARPA seeks innovative proposals in the following TAs, as shown in Figure 1 and described in detail as follows:

Figure 1: SMOKE TAs with notional subtasks and challenges

The Government anticipates multiple awards for both technical areas. Proposers are encouraged to read descriptions of both TAs to ensure full understanding of the program context and anticipated feedback loops between performer efforts.

TA1 – Automated Planning and Execution of Attribution Aware Cyber Infrastructure

The goal of TA1 is to plan, build, and deploy threat emulated cyber infrastructure that is required for network security assessments. TA1 has five objectives:

1. Build tools for automated cyber infrastructure generation with contingencies that mimics signatures of advanced cyber threat actors provided by TA2.

2. Build tools for automated acquisition, management, and disposal of available pools of infrastructure resources/options.

3. Build tools for acquisition, management, and disposal of cyber personas for third-party services and infrastructure interactions.

4. Build tools for recommending and executing contingencies based on real-time attribution risk assessments of cyber infrastructure, provided by TA2 sensors.

5. Integrate tools with existing mission platforms provided by transition partners.

TA1 proposals must describe an innovative, data-driven approach to modeling threat emulated cyber infrastructure plans that can be used for security assessments of diverse and complex networks. TA1 approaches must be able to generate infrastructure plans that can evade detection or emulate adversary activity by conforming to TA2-provided signatures. Approaches must also be able to recommend contingency infrastructure plans when the risk of attribution becomes too high.

Additionally, teams will build tools to realize infrastructure plans as components and will evaluate them during simulated operations in real-world network environments (e.g., red team security assessments). Approaches must be deployable and capable of acquiring, interacting, managing, and disposing of infrastructure elements in accordance with desired adversary signatures. TA1 approaches must also be capable of reaching a target network automatically so red team operators can focus on actions within the target network. TA1 solutions will be customized for integration into multiple mission platforms and will permit repeatable and scalable red team security assessments on networks of interest.

Strong proposals will consider using reinforcement learning techniques to reason about plans under uncertainty and incorporate information about attribution into cyber infrastructure decisions or explain why their approach has the potential to produce better results. TA1 components will need to consider tradeoffs between efficiency and effectiveness of plans in terms of speed and evasion. Strong proposals will also consider extending current cyber range and infrastructure as code technologies to realize infrastructure plans via a platform capable of deploying, managing, and continuously monitoring a globally diverse set of infrastructure elements.

The primary challenges for TA1 are the accuracy, scale, diversity, and speed of plan generation and execution. DARPA will facilitate access to relevant data sources by leveraging commercial relationships, U.S. Government (USG) partners, and data exchange agreements. Proposers are strongly encouraged to propose their own data sources and methods, and to identify their data needs concretely. Proposers are strongly encouraged to offer up separate, costed options for program-wide access to their own data sources. These options may or may not be exercised at the Government’s sole discretion. Of particular interest are data sources that enable the characterization of real-time global networks for candidate infrastructure elements.

TA1 proposals should, at a minimum, address the following topics:

1. Methods to abstract away complexities of diverse network environments so autonomous agents can learn infrastructure configurations (i.e., plans) that are capable of reaching a target network and maintain C2;

2. Methods to operate in partially denied environments and to reason under uncertainty, gain information about attribution risks, and react to unforeseen detection or attribution events; and

3. Planning algorithms to measure the tradeoff among efficiency and effectiveness in terms of speed and evasion.

Proposers should additionally discuss how their solutions will provide insights as to how infrastructure plans either conform to or evade a set of signatures.

TA2 – Discover and Generate Infrastructure Signatures

The goal of TA2 is to develop technologies to generate adversary cyber signatures that will inform the automated preparation of cyber infrastructures used during network security assessments. TA2 has the following five objectives:

1. Develop algorithms to extract infrastructure associations from large-scale cyber datasets;

2. Generate and provide machine-readable signatures of cyber threat groups;

3. Produce attribution risk assessments for TA1 generated plans;

4. Build tools/sensors for the detection of TA1 infrastructure emissions and provide feedback for infrastructure in use; and

5. Integrate with existing mission platforms provided by transition partners.

TA2 proposals must describe an innovative, data-driven approach to discover cyber infrastructure signatures. Approaches must focus on infrastructure signatures that are useful for attribution and lend themselves to automation. In addition, approaches must generate machine-readable signatures that TA1 approaches can mimic. Approaches must also inform red teams of the attribution risk associated with their infrastructure decisions. TA2 proposals must describe how an approach will learn cyber infrastructure patterns and model infrastructure associations of cyber threat groups hidden in global Internet datasets.

Strong proposals will consider machine-learning approaches to model infrastructure associations through automated pattern recognition and graph-based inferences. Of particular interest are techniques that can extract useful attribution features from global Internet datasets, explain attribution risks to cyber operators for infrastructure in use, and predict if infrastructure configurations can evade or conform to discovered signatures.

The primary challenges for TA2 are the accuracy and effectiveness of adversary signatures and risk assessments. DARPA will facilitate access to relevant data sources by leveraging commercial relationships, USG partners, and data exchange agreements. Proposers are encouraged to propose their own data sources and methods, and to identify their data needs concretely. Proposers are strongly encouraged to offer up separate, costed options for program-wide access to their own data sources. These options may or may not be exercised at the Government’s sole discretion. Of particular interest are data sources that enable the extraction of historical and current adversary signatures.

TA2 proposals should at a minimum address the following topics:

1. Generating adversary signatures requires discovering associations between infrastructure elements. Proposers should address how their solutions will extract associations from large-scale cyber datasets and build graph-based models from those associations;

2. To achieve the scale of signatures required for informing TA1 plan generation, TA2 requires unsupervised learning techniques to build and traverse associations. Proposers should discuss how their solutions will build and measure associations with the same quality as subject matter experts and be able to explain attribution assessments to red team operators;

3. Proposals should discuss how their automated approaches can be used by non-experts in attribution and should minimize as much human intervention as possible; and

4. Discovering signatures of cyber infrastructure requires using real-world network traffic datasets. Proposers should discuss how their solutions will generate useful statistics that can be used by planners to predict how well infrastructure configurations will conform or evade desired signatures and capture SMOKE emissions during red team security assessments to provide feedback.

Requirements for Both TA1 and TA2 Proposals

TA1 and TA2 components will form a feedback loop, as shown in Figures 1 and 2. The feedback loop will enable detection and characterization of TA1 plans. TA1 proposals should explain how their components will generate risk assessment requests. TA2 proposals should explain how their components will incorporate TA1 plans (e.g., ground truth) into their algorithms during research and development (see grey dotted line in Figure 2). Both TA1 and TA2 performers should plan on coordinating closely with each other and proposals should discuss methods for expanding upon proposed feedback mechanisms between TAs.

Figure 2: TA1 and TA2 proposals should address how Plan Representations and Attribution Risk Feedback will be exchanged

Information Only Transition Support Activity (i.e., Constellation Pipeline)

The following section is provided as information only to aid proposers in preparing their proposal submissions.

DARPA will establish a user-directed, incremental, and iterative DevSecOps (development, security, and operations) pipeline to accelerate the creation, adoption, and delivery of SMOKE components into U.S. Cyber Command, DOT&E, and other transition partner software ecosystems. The Constellation 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 would conceive in isolation. To this end, in-person tech exchanges, hackathons, and virtual technical exchanges will be planned once development environments become operational. As capabilities mature, pilot tests with operational user communities of significant size and diversity will be conducted to assess the viability and generality of the approaches. Ultimately, pilot tests will span across services, user communities, and combatant commands (COCOMs) to ensure that capabilities provide value to diverse stakeholders.

Proposals should discuss how their components could leverage the Constellation Pipeline and integrate with relevant Government mission platforms. Proposals should also discuss existing relationships with Government partners, Government development networks, and Government mission platforms.

C. Program Phases and Metrics The SMOKE program is a 36-month effort divided into two 18-month phases. Phase 1 will focus on developing, demonstrating, and evaluating individual components. Phase 2 will focus on comparative evaluations formed by integrating program components.

SMOKE will evaluate components on networks of interest as part of real-world security assessments performed by red team partners. Each exercise will be designed by an Independent Verification and Validation (IV&V) team that will generate multiple scenarios informed by prior related I2O efforts to simulate operations. SMOKE TA1 metrics focus on time, scalability, and attribution. TA1 components will be evaluated on the ability of cyber operators to reduce cyber operations’ response time – and the ability to launch and maintain multiple concurrent operations without being attributed. In addition, infrastructure plans will be judged by their ability to confound attribution, reconstitute infrastructure after attribution, and explain the rationale behind automated decisions to red team partners. SMOKE TA2 metrics focus on generating and detecting signatures. TA2 components will be measured according to how well signatures match the judgement of attribution experts, how well attribution risk assessment matches emulations, and how well they can be incorporated as sensors that provide meaningful feedback.

Precision and recall will be used to measure detection and attribution performance. Precision, recall, and F1 are three metrics that are commonly used to measure detection performance. To this end, we define a true positive as a detection of an infrastructure element (e.g., host, user, or network address) that was used in a TA1 plan (e.g., emulated threat), and a false positive is defined as an identified infrastructure element that was not used in a TA1 plan. Similarly, a false negative is defined as an infrastructure element that was missed and a true negative is an infrastructure element that was not used in a TA1 plan. Likewise, precision, recall, and F1 are three metrics that are commonly used to measure attribution performance. To this end, we define a true positive as a correct attribution of infrastructure elements used in a TA1 plan (i.e., actual TA1 threat actor), and a false positive is defined as misattributed infrastructure elements that was used in a TA1 plan (i.e., emulated threat actor). Similarly, false negative is defined as the inability to attribute infrastructure elements and a true negative as identification of benign infrastructure elements.

During the first phase, SMOKE will define the initial operationally-relevant baselines for precision and recall (See Table 1); as well as measure speed and scalability of deployment. Phase 2 will improve upon the initial baselines and will define additional metrics for evaluating performance.

TAs Metrics Phase 1 Objectives Phase 2 Objectives TA1 (Planning and Execution)

Precision and recall for blue team attribution

Establish blue team baseline and reduce it by 10%

Establish blue team baseline and reduce it by 25%

Number of nodes in simulated network

At least 3 networks with 100 nodes

At least 30 networks with 1000 nodes

Time to develop plan Within 8 hours Within 60 minutes Number of concurrent attack plan emulations

2 20

Emulate multiple environments in parallel

10 100

Time to deploy infrastructure

Within 2 days Within 8 hours

Integrated demonstration with TA2

In emulated environments

In real-world environments (e.g., red team security assessments)

# of Advanced Persistent Threats

2 5TA2 (Signatures)

Precision and recall for blue team attribution

Establish blue team baseline and increase it by 10%

Establish blue team baseline and increase it by 25%

Table 1: SMOKE Metrics

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 SMOKE program objectives.

Schedule and Milestones

For each year of effort, there will be quarterly meetings with the Program Manager (PM), consisting of two (2) alternating technical exchanges and two (2) alternating integrated demonstrations. During these meetings/reviews, the PM will assess progress towards the solution via performer briefings, technical discussions, integrated demonstrations, and evaluation/challenge exercises. At the end of each phase, SMOKE will conduct pilot tests with operational users to integrate SMOKE components into existing workflows and mission platforms. Once the Constellation Pipeline is operational, the goal will be to host integrated demonstrations and pilot tests within the Constellation’s development environment.

These quarterly meetings will focus on open technical exchange and demonstration of SMOKE capabilities on realistic challenge problems, in real-world environments, and in collaboration with operational users. Difficulties encountered and possible solutions will also be discussed.

The goals of the quarterly technical exchanges and integrated demonstrations will be to: (1) review and share innovations/accomplishments of the SMOKE program; (2) review and discuss plans and options for technology demonstrations and prototypes; (3) review and discuss results from meetings and events conducted prior to and after the tests and evaluation/challenge exercises; (4) demonstrate prototypes; and (5) plan for the next six-month period.

The Government will specify the locations for the technical interchanges and PI meetings. For budgeting purposes, assume the locations of the two PI meetings held each year will alternate between Washington, D.C. and San Diego, CA. 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 meetings. In-person meetings, evaluations, and site visits may be replaced with virtual ones, if necessary.

Figure 3 below provides a tentative program schedule. 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 SMOKE program’s period of performance. A start timeframe of August 2022, should be assumed for budgeting purposes.

22-Aug 23-Nov 23-F eb 23-May 23-Aug 24-Nov 24-F eb 24-May 24-Aug 25-Nov 26-F eb 26-May T echnical C omponents :

T A1 - Generate E vas ive Infras truc ture

T A2 - D is c over Infras truc ture S ig natures

T rans ition S upport Ac tivity

E valuation:

T ec hnic al exc hang es and evaluation

Integ rated demons trations

Operational evaluation (pilot tes ts )

B as elines es tablis hed

K ickoff and P I Meetings

P has e 1 P has e 2

Automate infras truc ture plan generation on s imulated data, initial integration with TA2 to generate plans informed by TA2 operational data

Automate infras truc ture s ignature dis c overy, initial integration with TA1 to inform planning and feedbac k

Demons trate TA1 and TA2 protype on operational data

Automate infras truc ture plan generation on operational data, fully integrate with TA2 (automated)

Automate infras truc ture s ignature dis c overy, fully integrate with TA1, automated feedbac k

Integrate c omponents on operational platforms

Demons trate TA1 and TA2 on operational data; Demons trate fully integrated prototype on mis s ion platform(s )

Technology D emonstrations 18 Months

C omparative E valuations 18 Months

Es tablis h J oint Development Environment

Integrate c omponents on S MOK E platform

Government T eam Demons trate TA1 prototype on s imulated data, TA2 on operational data

2 4 5K 31 6

Figure 3: SMOKE Tentative 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 Technical Status Reports – A quarterly technical status report to the DARPA

Vault reporting system 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 Financial Reporting – Monthly expenditure reports and uploading of required deliverables to the DARPA Vault reporting system are required by all SMOKE performers.

• System Development Plan (SDP) –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. A SDP deliverable will be submitted within one month after the kickoff meeting for each phase, and shared with other performers for synchronization.

• Software – All computer software delivered under the SMOKE program must be delivered as source and object executable code. Include the source listings and source code for the target computer systems, as well as any build scripts or other technical information required for the Government 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 deliverables will 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 period of performance, all hardware procured or developed under the SMOKE program will be delivered to the Government. The delivered components will be the same as those used to perform final performance tests and evaluations at the end of the period of performance. The delivery should include sufficient documentation to be completely operable, maintainable, and modifiable, with no reliance on any non-delivered hardware or hardware documentation developed or procured under the SMOKE program.

• Phase and Final Technical Reporting – End-of-phase reports are due at the conclusion of each phase, including through final phase contract completion. A separate Final Technical Report is due at the end of the period of performance. The reports will concisely summarize the effort conducted and provide any lessons learned during the development of the SMOKE technology, and should be delivered to the DARPA Vault reporting system.

• Science & Technology Program Implementation Plan (S&T PIP) – One plan covering TA1 and TA2, as applicable. Due 30 calendar days prior to executing sensitive testing and updates as required by DARPA Program Security.

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

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

E. Intellectual Property

The program will emphasize creating and leveraging open-source technology and architecture.

Intellectual property rights asserted by proposers are strongly encouraged to be aligned with open-source regimes. See Section IV.B.2.i for more details on Intellectual Property.

A key goal of the program is to establish an open, standards-based, multi-source, plug-and-play architecture that allows for interoperability and integration. This includes the ability to easily add, remove, substitute, and modify software and hardware components. This will facilitate rapid innovation by providing a base for future users or developers of program technologies and deliverables. Therefore, it is desired that all noncommercial software (including source code), software documentation, and technical data generated by the program be provided as deliverables to the Government with Government Purpose Rights (GPR), and all hardware designs and documentation with a minimum of GPR, as lesser rights may adversely impact the lifecycle costs of affected items, components, or processes.

II. Award Information

A. General Award Information

Multiple awards are anticipated under this BAA. The amount of resources made available 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, as applicable.

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 IV.B.2.d, “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/or cost/price within a reasonable time, and the proposer fails to timely provide requested additional information. Proposals identified for negotiation may result in a procurement contract, or other transaction for prototype, 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. § 2371b(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 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.

http://www.darpa.mil/work-with-us/contract-management#OtherTransactions

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.

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.

III. Eligibility Information

A. Eligible Applicants

All responsible sources capable of satisfying the Government's needs may submit a proposal that shall be considered by DARPA.

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

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

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 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 consider 15 U.S.C. § 3710a to be sufficient legal authority to show eligibility. While 10 U.S.C.§ 2539b may be the appropriate statutory starting point for some entities, specific supporting regulatory guidance, together with evidence of agency approval, will still be required to fully establish eligibility. DARPA will consider FFRDC and Government Entity eligibility submissions on a case-by-case basis; however, the burden to prove eligibility for all team members rests solely with the proposer.

2. Other Applicants Non-U.S. organizations and/or individuals may participate to the extent that such participants comply with any necessary nondisclosure agreements, security regulations, export control laws, and other governing statutes applicable under the circumstances.

B. Organizational Conflicts of Interest

FAR 9.5 Requirements

In accordance with FAR 9.5, proposers are required to identify and disclose all facts relevant to potential OCIs involving the proposer’s organization and any proposed team member (subawardee, consultant). Under this Section, the proposer is responsible for providing this disclosure with each proposal submitted to the solicitation. The disclosure must include the proposer’s, and as applicable, proposed team member’s OCI mitigation plan. The OCI mitigation plan must include a description of the actions the proposer has taken, or intends to take, to prevent the existence of conflicting roles that might bias the proposer’s judgment and to prevent the proposer from having unfair competitive advantage. The OCI mitigation plan will specifically discuss the disclosed OCI in the context of each of the OCI limitations outlined in FAR 9.505-1 through FAR 9.505-4.

Agency Supplemental OCI Policy

In addition, DARPA has a…