HR001123S0002-Amendment-01.pdf

Broad Agency Announcement

Cyber Agents for Security Testing and Learning

Environments (CASTLE)

DARPA I2O

HR001123S0002

October 21, 2022

Amendment 1

November 21, 2022

Summary of Amendment 1 Changes:

The purpose of this amendment is to add clarity regarding necessary clearances and regarding how many proposals a proposer can participate in. The following sections has been amended and changes are highlighted in yellow:

1. PART II. FULL TEXT OF ANNOUNCEMENT; D. Program Structure

2. PART II. FULL TEXT OF ANNOUNCEMENT; E. Technical Areas

TABLE OF CONTENTS

PART I: OVERVIEW INFORMATION

PART II: FULL TEXT OF ANNOUNCEMENT

I. Funding Opportunity Description

A. Introduction B. Problem C. Program Scope D. Program Structure E. Technical Areas F. Program Phases and Metrics G. Schedule and Milestones H. Informational Only Transition Support Activity I. Deliverables Performers are responsible for providing the following deliverables:

J. Government-Furnished Property/Equipment/Information K. 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

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 Entrepreneurship Initiative (EEI) VII. Agency Contacts VIII. Other Information

PART I: OVERVIEW INFORMATION

Federal Agency Name – Defense Advanced Research Projects Agency (DARPA), Information Innovation Office (I2O) Funding Opportunity Title – Cyber Agents for Security Testing and Learning

Environments (CASTLE) Announcement Type – Initial announcement Funding Opportunity Number – HR001123S0002 Catalog of Federal Domestic Assistance Numbers (CFDA) – 12.910 Research and

Technology Development Dates o Posting Date: October 21, 2022 o Proposers Day: October 24, 2022 o Questions Due: December 15, 2022 o Proposal Due Date: December 22, 2022 o Solicitation Closing Date: April 19, 2023

Program Overview – The CASTLE program seeks to develop an AI toolkit to instantiate realistic network environments and train cyber agents to enable resilient network operations against advanced persistent threats (APT). CASTLE will formulate network hardening as a reinforcement learning (RL) problem and train defensive agents in open, evolving, and adversarial environments that mimic actual networks.

Environments execute agents inside instrumented subnets that are deployed to live networks and will simulate defensive actions that counter APT tools. Agent execution will produce calibrated datasets for progressively improving simulations. As an important benefit, toolkit datasets will promote open, rigorous evaluation of defensive approaches beyond the program.

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

Multiple awards are anticipated for all three technical areas.

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

Agency Contacts o Points of Contact

The BAA Coordinator for this effort can be reached at:

Email: CASTLE@darpa.mil

DARPA/I2O

ATTN: HR001123S0002

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 CFR § 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: (TA):

TA1: Purple Team (Automate instantiation of realistic network environments) TA2: Blue Team (Learn defensive actions for maintaining operations) TA3: Red Team (Enumerate possible attack paths)

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

The DARPA Information Innovation Office (I2O) is soliciting innovative research proposals for the development of an AI toolkit that can instantiate realistic network environments and train cyber agents to enable resilient network operations against advanced persistent threats (APTs). The Cyber Agents for Security Testing and Learning Environments (CASTLE) program aims to formulate network hardening as a reinforcement learning (RL) problem and teach RL agents to “operate-through” the post-breach behavior of widely available APT tools. Over progressive rounds of attack and defense, agents will explore defensive actions to proactively stop on-going attacks while maintaining operationally relevant workflows. CASTLE workflows may encompass critical assets and essential services performed by networks. For example, an enterprise network may consider email service an operationally relevant workflow or a university may consider registrar servers as critical assets.

The CASTLE program seeks to generate realistic environments that mimic actual networks. For example, network scans can inform environments with actual network topologies and existing common vulnerabilities and exposures (CVEs). In these environments, agents will train to counter APT tools by learning automated defensive actions such as data-protection policies, firewall rules, and device re-configurations. To support open and evolving training, CASTLE seeks environments and agents that allow for progressive updates such as adding CVEs, ports, protocols, and services.

Over the course of the program, CASTLE seeks to model networks at greater scale and fidelity and develop agents with more sophisticated defensive actions. The CASTLE program discourages proposals that cannot model operationally relevant workflows performed in existing networks.

To improve simulations, CASTLE aims to instantiate environments as deployable subnets inside live networks such that the subnets are instrumented to record network and device events. The CASTLE program aims for top performing simulated agents to be instantiated inside subsets as well. Furthermore, the CASTLE program seeks to capture the side effects of agent actions being executed inside the live network such that observations can inform future rounds of agent training.

For example, captured agent execution can be used to establish realistic success probabilities or training parameters. The CASTLE program views agent execution in instrumented subnets as a risk reduction measure intended to ensure simulations do not deviate from reality.

As an important benefit, captured agent execution in instantiated environments enable the generation of continuously updated datasets with known ground truth labels. CASTLE aims to promote open, rigorous evaluations of defensive approaches by publicly releasing toolkit generated datasets. Moreover, CASTLE aims for toolkit datasets to serve as standard benchmarks for rigorous measurement of cyber security performance beyond the program. Thus, proposers are encouraged to discuss concepts for publishing datasets to include labeling tool behavior, curating community-driven results, and making datasets amenable to open source machine learning libraries.

The CASTLE program seeks research leading to open source standards and software for hardening networks. In particular, CASTLE aims to tailor defensive actions to a variety of bespoke networks;

that is, networks intended to perform a specific function or serve a specific userbase. Thus, proposers are encouraged to discuss open source approaches to produce technology that is repeatable, portable, and shareable. In addition, CASTLE aims to encourage cross-pollination across communities of data scientists, machine learning researchers, and cybersecurity experts.

Thus proposers are encouraged to discuss open source approaches to develop APIs that abstract network hardening so different communities can collaborate together with a common understanding. Altogether, CASTLE aims to promote the adoption of a community developed project that can contribute to collective network defense.

If successful, CASTLE will transition automated, data-driven network hardening technology to defensive cyber personnel. With CASTLE, defenders will improve mission resiliency of bespoke networks by means of containing APTs in action, accelerating security assessments, and driving cybersecurity data science.

B. Problem

The CASTLE program seeks to address the following challenges to current defensive cyber operations. Proposers are encouraged to explain how their approaches can address one or more of these challenges. In addition, strong proposals will indicate any assumptions that may limit the applicability of their approaches.

Today, defensive security operations anticipate threats with infrequent, internal vulnerability scanning. Unfortunately, this process is burdensome and primarily reserved for periodic authorization to operate (ATO) accreditation. Yet, new vulnerabilities are published daily, so this approach will always lag behind attackers’ abilities to find vulnerable paths towards critical assets.

The CASTLE program seeks to provide defenders with a better understanding of network vulnerabilities than what attackers can discover.

Beyond scanning, network owners are often required to perform periodic cyber security assessments. During assessments, defensive cyber personnel compete against trained penetration testers that mimic APT-style attacks (e.g., discovery, lateral movement, command-and-control) and use the same widely available attacker tools. The defensive cyber personnel are often referred to as the blue team, while the penetration testers are referred to as the red team. Demands for assessments are hard to fill because required personnel are very skilled and scarce. Moreover, post-assessment feedback is informal, time-compressed, and lacks quantifiable measures of either team’s performance. Thus, the CASTLE program seeks to accelerate security assessments with approaches that are automated, repeatable, and measurable.

Efforts to improve defensive cyber operations with real-time incident response and automated forensics are limited by the dearth of data-driven descriptions of attacker tools. Instead, advanced defenses focus on detecting subtle network changes rather than directly on attacker tools.

Moreover, detection performance degrades after legitimate network changes, which are constant.

Consequently, incident response can take months and is often incomplete. Thus, the CASTLE program seeks to generate data-driven, machine-readable descriptions of how attacker tools behave, how attack paths unfold, and how to label observable attack behavior.

C. Program Scope

The vision of the CASTLE program is to contain and clear APTs from bespoke networks without affecting operationally relevant workflows. Towards this end, a notional view of an integrated CASTLE approach is as follows (see Figure 1 below): to begin, a purple team generates an RL-environment using insights from vulnerability scans of actual networks. Next, blue team agents learn defensive actions to counter APT tools as demonstrated by red team agents. In these simulations, blue team agents receive rewards for maintaining operationally relevant workflows and anticipating red team actions. On the other hand, red team agents receive rewards for reaching critical assets. After sufficient training, the environment and top-k agents are instantiated inside a live network as an instrumented subnet. To ensure realism, agent execution inside the subnet will be captured, labeled, and used to inform future rounds of attack and defense. Lastly, successful agents will be transferred back to the original vulnerable network or to another unseen network.

Figure 1: CASTLE Vision

D. Program Structure

The CASTLE program is a four (4) year effort divided into three phases: Phase 1 and 2 are both 18-months and phase 3 is 12-months. Phase 1 will focus on development, demonstration, and evaluation of individual approaches. The phase will end with an evaluation of agents’ ability to stop attacks inside live, unseen baseline networks. Phase 2 will focus on comparative evaluations and evaluations of feedback loops formed by integrating prototype approaches. The phase will end with an evaluation of an integrated toolkit’s ability to automate security assessments of transition partner networks of interest. Finally, Phase 3 will customize approaches and transition to specific classes of bespoke networks. 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.

Selected performers are expected 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. Additional information on ACAs can be found in Section VIII.

The Government will assess performer progress using formal and informal technology evaluations, as well as adversarial engagements that incorporate aspects of real-world cyber operations. These engagements will be driven by specific operational scenarios in collaboration with red teams and defensive cyber analysts. Proposers are encouraged to allow for adaptability in testing and evaluation so it is possible to take advantage of time-sensitive opportunities, while also supporting program planned research and development. Additionally, proposers are encouraged to view technology transition as a continuous process underway at all times during their period of performance.

Strong fundamental research proposals should either (1) have a means to deploy and integrate software into DoD systems without the need for developer access (e.g., open source libraries) or

(2) have a prime (or subcontractor) capable of performing work at the Controlled Unclassified Information (CUI) and classified levels. Proposers to CASTLE are not required to hold facility or personnel security clearances to submit proposals; however, all non-fundamental research proposals must describe the proposer’s eligibility and plan of action for one team member to obtain (or upgrade to) a Top Secret Facility clearance and process key personnel for Top Secret clearances with SCI eligibility by the end of Q3, Phase-I. Classified safeguarding is not required. Proposers with current FCLs must provide their CAGE code, Facility Security Officer point(s) of contact, and personnel security clearance eligibility for key personnel in their proposals. Alternatively, proposers with no facility clearances must submit the enclosed (attached) FCL request for at least one team member with their proposals to demonstrate eligibility to obtain an FCL.

E. Technical Areas

The CASTLE program will develop open-source technology to generate training environments and enable cyber agents to perform controlled, measurable, and repeatable security assessments.

CASTLE is structured with three technical areas. TA1 consists of purple team(s) responsible for building open, evolving and adversarial RL environments resembling realistic network environments. TA2 consists of blue team(s) responsible for building agents that learn defensive actions to maintain environment workflows. TA3 consists of red team(s) responsible for developing agents that enumerate possible attack paths within the environment’s common vulnerability exposures.

Figure 2: Technical Areas The ultimate objective for each technical area is to create open-source software to be incorporated into an open-source codebase. Strong proposals will develop all tools, methods, processes, and prototypes to work seamlessly in the open source network hardening toolkit. In addition, strong proposals will describe an approach to support rigorous measurement and clear communications during cybersecurity training. Strong purple team proposals should describe an approach to simulating and instantiating environments that enables extensible and realistic agent training.

Strong blue team proposals should describe an approach that enables DoD defensive security personnel to operate-through APT-attacks in real-time by automating defensive actions. Strong red team proposals should describe an approach that enable agents to perform economical, repeatable, and test-driven security posture validation.

CASTLE aims to create open source technology that can support the creation of a sustainable competition league in which fresh cybersecurity datasets are continually generated. It is desirable for these datasets to become standard benchmarks used to drive future academic and industry data science efforts.

Each proposal must address a single TA and proposals cannot combine TAs. Each proposer (as identified by CAGE code) may only submit one proposal per TA (for a limit of 3 proposals per institution). Note that should a proposer submit multiple proposals (i.e., one per TA), that proposer may only be selected as a prime for a single TA, selected at the Government’s sole discretion. In other words, a proposer can participate as Prime for one TA and as a sub to any

TA.

The Government anticipates multiple awards for all three technical areas. Proposers are encouraged to read descriptions of all TAs to ensure a full understanding of the program context and expected relationships among performers. Proposers are encouraged to pay special attention to the feedback loops expected between technical areas, as well as the general criteria listed in the evaluation and metrics sections.

TA1. The Purple Team (Automated instantiation of realistic network environments):

Advances in open-source RL training environments, such as the AI-gym, offer the promise of hardening bespoke networks with automated security assessments. The CASTLE program seeks to model and evaluate network security in a measurable and repeatable manner using RL. Strong proposals will describe an RL approach to simulate security assessments on large networks hosting operationally relevant workflows.

The purple team’s first objective is to build RL training environments that enable open, evolving, and adversarial agent development. Strong proposals will enable TA2 and TA3 performers to develop action spaces and reward functions capable of training cyber agents to learn effective defensive actions and enumerate complex attack paths. Proposers should explain their approach to modeling network environments informed with insights from a variety of actual vulnerability scans and system configurations, and failure to do so will negatively impact evaluations. Strong approaches will accept raw vulnerability scans and system configurations as input and then output an RL-environment with sufficient detail to ensure realistic agent training. Strong proposals will describe techniques for building environments that will encode critical simulation details such as CVEs, system configurations, operating systems, ports, protocols, and services to name a few.

Strong proposals should explain their approach to extending environments with more sophisticated details and network topologies as the program progresses and failure to do so may reflect negatively on their evaluation.

The purple team’s second objective is to simulate progressive rounds of attack and defense.

CASTLE proposers should describe an extensible approach for accommodating blue team and red team agent development. For example, strong proposals will explain their approach for enabling agents to simulate attack and defense of operationally relevant workflows. Proposals should describe an extensible approach that permits agents to train with custom actions and reward functions. In addition, proposals should describe an approach to improve communication and feedback between technical areas during training so progress can be monitored and tracked over time.

The purple team’s third objective is to instantiate RL simulations inside actual networks. Strong proposals should describe an approach to deploy RL environments inside an instrumented subnetwork such that known vulnerabilities are still present. Proposed software should include instrumenting subnetworks with comprehensive network and device event collection, and deploy default open source intrusion detection tools. Strong approaches will describe openly-available candidate instrumentation that can ensure agent execution can be observed and captured in curated datasets. Proposers are encouraged to describe an approach to package curated datasets for public release. The intent of the datasets is to support the development of cyber defenses by a broader research community. In addition, proposers are encouraged to describe a concept for potentially maintaining curated datasets after the end of the program. In addition to environments, proposers should describe their approach for deploying trained agents. For example, strong proposals will describe the development of an extensive API for blue team and red team agents to use. Lastly, proposals should explain how the performer will ensure instantiated environments and agents will not negatively affect the actual network.

The purple team’s fourth objective should be clearly severable from all other objectives and provided to the Government as an optional, separately priced task to be exercised at the Government’s sole discretion. The intent of this objective is to establish and maintain computing infrastructure that can facilitate and support research, development, internal testing, and formal evaluation exercises. Good infrastructure approaches will enable all technical areas to collaborate by supporting result communication, feedback contributions, and datasets access all together with shared computing resources. Strong proposals will describe an approach to adapt and extend open source tools to create the purple team infrastructure, which may consist of commercial and private cloud infrastructure. Proposals should include a sound, detailed technical plan that describes remote access options, user management, data management, and collaboration tools for TA1 – TA3 performers and Government evaluators. TA1 performers will assist the Government evaluation team in establishing remotely accessible infrastructure for exercise evaluations. The purple team data-management plan should explain an approach to facilitate remotely accessible data access, ingest, indexing, search, and filtering for evaluation. In particular, proposals are highly encouraged to describe an approach to accomplish the following technical objectives: (1) ingest subnet datasets; (2) store data in a manner that facilities exploration and algorithmic processing by TA1-TA3 performers; (3) share context, analysis, and results across TA1-TA3 and government performers; and (4) establish communication processes that facilitate discussion, clarification of ideas, and evaluation. Proposals should include a maintenance plan for infrastructure hardware and software for the length of the program.

TA2. The Blue Team (Learn defensive actions for maintaining operationally-relevant workflows):

Advances in machine learning offer the promise of blue team agents capable of stopping APT attacks in action. The maturity of network sensors provide evidence that attacker tool behavior can be captured and used to create models describing the steps taken by attackers. The CASTLE program seeks to develop attacker models and use them to develop data-driven defensive actions such as predicting attacker movements, simulating stopping of attacks, and designing network topologies to minimize impacts of a breach. In addition, strong proposals will describe approaches to defend against dynamic APT attack paths in large environments modeled on actual networks.

Blue team proposals may assume RL environments are provided by the purple team, but are expected to recommend productive additions or modifications to the action-space, reward function, and environment states. Blue team proposals may assume TA3 will provide machine readable descriptions of APT tool behavior, but are expected to recommend methods to improve descriptions, record tool behavior, and ensure capture of needed data. Proposers may assume default intrusion detection capabilities are available in the instrumented subnet and APT tool behavior will be available for analysis, so proposers are strongly discouraged from proposing new threat detection algorithms and technology.

The blue team’s first objective is to anticipate attacker objectives; therefore, proposers should describe an approach to define agent action-spaces based on actual APT behavior. CASTLE proposers should describe a novel data-driven approach to analyze APT behavior observed within a network. Proposals should describe an approach to address the following research challenges using internal network and endpoint events as input: generate models of attack path sequences, discover the most relevant features needed for recognizing tool execution, and disseminate indications of tools for use in real-time defensive actions. Since proposers may assume APT tool behavior will be available for analysis, the CASTLE program seeks data-driven, machine-readable descriptions of attacker tool behavior in the form of labeled datasets, representation learning algorithms, and sharable models. In addition, proposals should describe an approach to generate useful models of APT behavior by fusing multiple information channels such as network/device events, vulnerability scans, and if available, attacker tool logs. In addition, proposers should describe an approach to explain how actions change the underlying environment such that TA1 performers can incorporate environmental state changes into simulations.

The blue team’s second objective is to prevent attacker movements while maintaining operations.

Proposals should describe an approach to formulate defensive rewards based on actual attacker tool behavior. In addition, strong proposals should describe methods to explore defensive action spaces such that attacker options are limited while maintaining operationally-relevant workflows.

Potential agent execution will include firewall changes, device manipulation, and data loss policy enforcement. As the program progresses, strong proposals are expected to limit the attacker’s impact to network operations using more sophisticated and less disruptive agent executions.

The last blue team objective is to enable the purple team to instantiate the top performing agents inside an instrumented subnetwork. The CASTLE program seeks approaches to deploy the best performing agents and execute their actions in real time. Proposals should describe an approach to transform agents into executable code and implement an API to enable agent execution in real time and in a variety of workflows. Strong proposal should describe how the API will incorporate feedback from all technical areas into the design process and contribute functionality to TA1 environments. Proposers are encouraged to expand open source standards when implementing agent execution. The results of agent execution will be captured and used to generate curated datasets. Proposals should describe an approach to incorporate these datasets as input to generate tool behavior models and as feedback to improve agent performance and update model parameters

TA3. The Red Team (Enumerate possible attack paths):

Advances in automated penetration testing offer the promise of enabling economical, repeatable, and test-driven validation of a network’s security posture. The CASTLE program seeks to develop RL agents capable of automating typical red team activities such as finding key cyber-terrain, moving towards important networks devices, and escalating user privileges. In addition, strong proposals will describe approaches that can consider sophisticated network topologies, a variety of widely-available tools, and provide better feedback to defenders during security assessments.

Red team proposals may assume RL environments are provided by the purple team, but are expected to recommend productive additions or modifications to the action-space, reward function, and environment states. Red team proposals may assume subnetworks are instrumented to observe agent actions, but if additional instrumentation is needed, are expected to recommend methods to record tool behavior and ensure capture of agent execution. Red team proposers are expected to consider tools recommended by the evaluation team and other performers.

The red team’s first objective is to generate attack paths from arbitrary network devices to predefined critical assets. Proposals should describe an approach to use RL to find attack paths within environments using only published CVEs. The CASTLE program will not develop CVEs and discourages proposers from developing CVEs. Proposers should describe an approach to define reward functions that teach agents to perform security assessments on operationally relevant workflows. Good reward functions should be flexible enough to adjust to the introduction of blue agent actions or environmental updates such as the introduction of new network configurations or CVEs. Lastly, the CASTLE program seeks proposals capable of continuously testing a variety of environments and workflows.

The second objective of the red team is to demonstrate attack paths using widely-available penetration testing tools. CASTLE proposers should describe an approach to define RL-agent action-spaces modeled on attacker tools to include open source, commercial, or natively installed network software. Good action-space models will limit agent decisions to only permissible functionality of the modeled tool. Proposals should describe an approach to integrate action space results into purple team environments in the form of environmental feedback to agents. The CASTLE program seeks proposals for methods to clearly explain attack paths through a network, so proposers should describe an approach to generate machine-readable descriptions of attack paths that are amenable to further analysis. In particular, descriptions should support purple team efforts to label datasets and blue team efforts to generate models of attacks.

In the same vein as the blue team, the red team’s third objective is to enable the purple team to instantiate the top-performing red agents as executable functions within instrumented subnets.

Therefore, proposers should describe an approach to transform agents into executable code.

Proposals should describe an approach to implement an API for agent execution and an ability to contribute functionality to the purple team. Of particular interest to the CASTLE program is for agent execution to be captured and used to generate curated datasets. Therefore, proposals should describe an approach to generate machine-readable descriptions of how attacks unfold and be able to incorporate feedback from other technical areas into the design process. Good descriptions should enable the proper labeling of datasets to include sufficiently describing all red agent actions.

Proposers should also describe an approach to parse all available tool logs and make such information available to the other technical areas. The CASTLE program seeks to use executable agents to continuously test network security postures. Therefore, proposals should also describe an approach to use descriptions to help blue team agents proactively prepare to defend against agents.

The last red team objective is to incorporate curated datasets as feedback to agent simulations.

Proposals should describe an approach that can incorporate these datasets as feedback, so simulations do not deviate from reality. Proposals should be able to update RL-agent parameters using data from instantiated subnetworks.

F. Program Phases and Metrics

The key program metric will measure defensive agents’ ability to maintain operationally relevant network workflows versus APT threats. Therefore, purple team(s) will be evaluated on the number of network environments and workflows simulated and instantiated. Blue team(s) will be evaluated on the number of operationally relevant workflows successfully defended. Finally, red team(s) will be evaluated based on demonstrated attack paths to critical workflow assets. A detailed listing of TA metrics based on program phases is provided in Table 1.

TA Capability Phase 1:

Baseline Environments

Phase 2:

Transition Relevant Environments

Phase 3:

Operational Tailoring

TA1: Purple Team (Instantiate high fidelity network environments)

Simulate/Execute actual environments

Enable agents to simulate/execute at least 3 operationally relevant workflows in at least 3 exemplar environments

Enable agents to simulate/execute at least 5 operationally relevant workflows in at least 2 transition partner environments

TA2: Blue Team (Enable resilient network workflows

vs. APT threats via trained agents)

Maintain operationally relevant workflows

Defend at least 5 operationally relevant workflows over at least 2 environments

Defend at least 5 operationally relevant workflows in at least 2 transition partner environments

TA3: Red Team (Emulate APTs with representative threats to support blue agent training)

Demonstrate possible attack paths in operationally relevant workflows

Reach critical assets in at least 5 operationally relevant workflows with widely available tools used by APTs

Reach critical assets in at least 5 operationally relevant workflow objectives with widely available tools in transition partner environments

Customize to Mission Partner Platform

Table 1: Program Metrics

G. Schedule and Milestones

The CASTLE transition strategy is to integrate R&D efforts into a useful open source toolkit for hardening bespoke networks. CASTLE will collaborate with potential transition partners early and continuously throughout the program to ensure that CASTLE capabilities support transition partner needs. Collaboration will ensure DoD relevance and provide CASTLE with a continuous understanding of the rapidly evolving state of defensive cyber operations (DCO).

Anticipated transition partners include teams responsible for DoD security assessments. Transition partners will shape realistic challenge problems and will help evaluate performer validity throughout the program. Evaluations will measure CASTLE performance under a variety of challenge workflows and in different network environments. Operational evaluations will be conducted once a year to rigorously measure performer metrics with an emulated advanced persistent threat. After the first six months, the government will also conduct three integrated demonstrations in each phase. A summary of the program schedule is depicted in Figure 3 below:

Figure 3: CASTLE program schedule H. Informational Only Transition Support Activity

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

DARPA may establish a user-directed, incremental, and iterative DevSecOps pipeline to accelerate the creation, adoption, and delivery of CASTLE components into USCYBERCOM, DOT&E, and other transition partner software ecosystems. 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 would conceive in isolation. To this end, in-person tech 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 will be conducted to assess the viability and generality of the approaches. Ultimately, pilot tests will span across services, user communities, and combatant commands to ensure that capabilities provide value to diverse stakeholders.

Proposers are encouraged to discuss how their components could leverage this pipeline, provide feedback on additional technology the pipeline needs to support transition, and integrate with relevant Government mission platforms. Proposals are also encouraged to discuss existing relationships with Government partners, Government development networks, and Government mission platforms.

I. Deliverables Performers are responsible for providing the following deliverables:

• Slide Presentations – Annotated slide presentations are due two weeks after the program kick-off meeting and after each review.

• Quarterly Coordination Reports – A quarterly technical coordination report is due ten

(10) calendar days after the end of each quarter. The unclassified report must be submitted to the DARPA Vault reporting system and must describe progress made, resources expended, and any issues that require the attention of the Government team.

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

• 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. An SDP deliverable is due thirty

(30) calendar days after the kickoff meeting for each phase, and will be shared with other performers to enable collaboration and schedule synchronization.

• Software – All computer software developed or utilized during the program must be delivered as source and executable code. Performance must include 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. Delivered software under this effort is to be maintainable and modifiable with no reliance on any non-delivered computer programs or documentation.

• Software Documentation – Software documentation deliverables are due thirty (30) calendar days after the end of each phase. 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 – With some exceptions, at the conclusion of the period of performance, all hardware procured or developed under the program will be delivered to the Government.

However nonprofit R&D entities (e.g., universities) are allowed to keep equipment/materials purchased as long as they continue to use them for R&D purposes.

The delivered components will include 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.

• 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, and should be delivered to the DARPA Vault reporting system at the end of each phase.

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

J. 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 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. Cost Volumes should include a separate list of the cost of each GFE item if it is unavailable from the Government.

K. 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 architecture includes the ability to easily add, remove, substitute, and modify software and hardware components. This structure 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 unlimited rights, and all hardware designs and documentation with a minimum of Government Purpose Rights (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. 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, 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 VI.B.2., “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, 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 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 http://www.darpa.mil/work-with-us/contract-management#OtherTransactions 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. Historically Black Colleges and Universities, Small Businesses, Small Disadvantaged Businesses and Minority Institutions are encouraged to submit proposals and join others in submitting proposals; however, no portion of this announcement will be set aside for these organizations’ participation due to the impracticality of reserving discrete or severable areas of this research for exclusive competition among these entities.

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.

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 http://www.darpa.mil/work-with-us/additional-baa 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…