HR001119S0057.pdf

Broad Agency Announcement Automated Rapid Certification Of Software (ARCOS)

HR001119S0057

May 10, 2019

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

HR001119S0057 ARCOS

Table of Contents

I. Funding Opportunity Description

A. Introduction

B. Program Description

C. Technical Areas

D. Program Assessments/Schedule

E. Deliverables

F. Intellectual Property

G. Security Clearance Requirements

H. Potential Conflicts of Interest

II. Award Information

A. Awards

B. Fundamental Research

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

III. Eligibility Information

A. Eligible Applicants

B. Organizational Conflicts of Interest

C. Cost Sharing/Matching

D. Other Eligibility Requirements

IV. Application and Submission Information

A. Address to Request Application Package

B. Content and Form of Application Submission

C. Submission Dates and Times

D. Funding Restrictions

E. Other Submission Requirements

V. Application Review Information

A. Evaluation Criteria

B. Review and Selection Process

VI. Award Administration Information

A. Selection Notices

B. Administrative and National Policy Requirements

C. Reporting

VII. Agency Contacts

VIII. Other Information

A. Frequently Asked Questions (FAQs)

B. Proposers Day

C. Submission Checklist

D. Associate Contractor Agreement (ACA)

PART I: OVERVIEW INFORMATION

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

Funding Opportunity Title: Automated Rapid Certification Of Software (ARCOS)

Announcement Type: Initial Announcement

Funding Opportunity Number: HR001119S0057

Catalog of Federal Domestic Assistance Numbers (CFDA): Not Applicable

Dates o Posting Date: May 10, 2019 o Proposers Day: May 14, 2019 o Abstract Due Date: May 24, 2019, 12:00 noon (ET) o Proposal Due Date: July 9, 2019, 12:00 noon (ET) o BAA Closing Date: July 9, 2019, 12:00 noon (ET)

Anticipated Individual Awards: DARPA anticipates single awards for technical areas 2 and 4, and multiple awards in technical areas 1 and 3

Types of Instruments that May be Awarded: Procurement contract or Other Transaction

(OT)

Agency Contacts o Technical POC: Raymond Richards, Program Manager, DARPA/I2O o BAA Email: ARCOS@darpa.mil o BAA Mailing Address:

DARPA/I2O

ATTN: HR001119S0057

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

PART II: FULL TEXT OF ANNOUNCEMENT

I. Funding Opportunity Description

DARPA is soliciting innovative research proposals in the area of automating the evaluation of software assurance evidence to enable certifiers to rapidly determine that the system risk is acceptable. Proposed research should investigate innovative approaches that enable revolutionary advances in science, devices, or systems. Specifically excluded is research that primarily results in evolutionary improvements to the existing state of practice.

This Broad Agency Announcement (BAA) is being issued, and any resultant selection will be made, using procedures under Federal Acquisition Regulation (FAR) 6.102(d)(2) and 35.016. Any negotiations and/or awards will use procedures under FAR 15.4. Proposals received as a result of this BAA shall be evaluated in accordance with evaluation criteria specified herein through a scientific review process.

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

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

A. Introduction

The goal of the Automated Rapid Certification Of Software (ARCOS) program is to automate the evaluation of software assurance evidence to enable certifiers to determine rapidly that system risk is acceptable. The process of determining that a system’s risk is acceptable is referred to as “certification1.”

Current certification practices are antiquated and unable to scale with the amount of software deployed by the Department of Defense (DoD). Two factors prevent scaling; (a) the use of human evaluators to determine if the system meets certification criteria, and (b) the lack of a principled means to decompose evaluations.

The use of humans to evaluate the quantities of assurance evidence that support software systems results in superficial, incomplete, and/or unacceptably long evaluations. The amount of evidence needed to determine software conformance to certification can be overwhelming to human subject matter experts. Human evaluators also have unique expertise, experience, and biases that influence their approach to evaluations. Because certification requirements may be vague or poorly written, evaluators often must interpret what is intended. Combined, these factors result in inconsistencies over time and across evaluations.

Currently, there is no means to compose evaluations in a principled and trustworthy manner.

Composed evaluations would allow subsystems or components to be evaluated independently and

1 This process is known by several names. Certification and Accreditation (C&A) is the name most commonly used.

The Risk Management Framework (RMF) refers to it as Assessment and Authorization (A&A). This document will use the term “certification” generically to mean any process that assesses software fitness for use, resulting in granting authorization for its use.

https://www.fbo.gov/ the results of those evaluations leveraged as assurance evidence in the composed systems. This would amortize the effort of evaluating any component over all systems using that component.

Current practice requires re-evaluation of components and their assurance evidence in every system that employs them. Our inability to use a divide and conquer approach to certification of large systems increases the cost and time of performing these certifications.

Two factors will support the acceleration of software certification through the automation of evaluations. First, the DoD has articulated its intentions to have its contractors modernize their engineering processes in the DoD Digital Engineering Strategy. The goal of this strategy is to move away from document-based engineering processes and towards design models that are to be the authoritative source of truth for systems. Such a future does not lend itself to current certification practices, but it will facilitate the automated evaluation of assurance.

Second, advances in several technologies provide a basis for confidence that automated evaluation of assurance evidence to support certification is possible. Model-based design technology, including probabilistic model checking, may enable reasoning over a design in in a way that quantifies uncertainty. So-called Big Code analytics have pioneered the application of semantic-based analytics to software and its associated artifacts. Mathematically rigorous analysis and verification provide the ability to develop software implementations that are demonstrably correct and sound. Assurance case languages provide us a means for expressing arguments on how software fulfills its certification goals, in a manner that is machine-readable.

If successful, ARCOS technologies will transition to program offices needing to reduce certification costs, improve their software evaluations, and/or better understand their software risks. These technologies will improve the quality of assurance evidence generated during development, and will therefore be of interest to contractors creating software for program offices that have adopted ARCOS.

Success in the ARCOS program could enable an app store approach to outfitting platforms for missions by assurance composition of apps that are added to a baseline platform. The ultimate goal of the ARCOS program is continuous certification and mission risk evaluation. However, to achieve this, compositional certification is a necessary first step, in order to pave the way for DoD acceptance and utilization of these technologies.

B. Program Description

ARCOS will develop the capability to automatically evaluate evidence that software systems meet their certification criteria and generate assurance case arguments. Substantiation of these arguments comes from analysis of four types of evidence: (1) test; (2) simulation and emulation;

(3) analytical; and (4) software quality assurance.

ARCOS will explore techniques to compose evaluated assurance arguments for pre-evaluated components into the assurance arguments of a system hosting those components. Assurance composition needs to provide evidence that the pre-evaluated components are in an operational context is equivalent to the context of its evaluation. Once this obligation is met, the evaluated properties of the components can be used as evidence in assurance case arguments for the host system. Also of interest are approaches to produce assurance evidence for software implementations that is more amenable to analysis and better able to support composable assurance. ARCOS will explore techniques to improve the coverage and quality of the evidence for both new and legacy software.

To develop trust in ARCOS, the generated assurance arguments need to be compelling. A knowledgeable human evaluator needs to be able to assess the validity of the generated arguments.

ARCOS will explore approaches to assist or automate validity assessments. These assessments will not only check the logical validity of the argument, but also provide a measure of the level of confidence for the arguments, derived from the supporting evidence.

C. Technical Areas

The ARCOS program has four Technical Areas (TAs) as shown in Figure 1:

TA1: Evidence Generation TA2: Evidence Curation TA3: Assurance Generation TA4: Quantitative Assessment

Figure 1: ARCOS overview

Proposers selected for award in TA4 will not be selected for award in any other technical area.

Each proposal may only address a single technical area, but proposers may submit multiple proposals.

There are multiple points of essential collaboration among TAs, and the Government expects that all performers to collaborate effectively, as described below. Proposers should read the descriptions of all TAs and the Program Assessments/Schedule section to ensure a full understanding of the program context, structure, and anticipated relationships required among performers. To facilitate the open exchange of information, all program performers will have Associate Contractor Agreement (ACA) language included in their award. See Section VIII.D for further information.

TA1: Evidence Generation

Evidence Generation has two thrusts: (1) generating evidence for new software development, and

(2) generating evidence for legacy software. Proposers may choose to answer either or both thrusts. Proposals that respond to both should provide statements of work and cost proposals that clearly separate the two thrusts into discrete tasks. Each thrust will explore technologies to improve the quality of assurance evidence for a given set of certification criteria. The certification criteria may be at either the system level or the component level. Hosting an independently evaluated component in a larger system requires composition. When composing assurances, the larger system will use the evaluated properties of the component in its own assurance case arguments. The larger system needs to meet whatever obligations the component places on it to ensure its evaluation is valid. To support composition, TA1 will develop technologies to derive the obligations a system must meet in order to utilize a component.

Technologies to support an assurance-driven development approach will be necessary. This will require languages and tools that can produce assurance case arguments prior to and during software design and build. The goal of engineering assurance cases early is to influence and inform software design and build, and drive the development of evidence to support these assurance cases. To support composed assurance, proposed technologies must be able to capture a minimal set of obligations to ensure the generated evidence is valid. TA3 will assure these obligations for systems hosting the component. Key technical challenges include providing language idioms and tools that allow a rich set of arguments, and producing arguments that can support assurance composition.

For legacy software, the goal is to determine gaps in the existing body of evidence, and to automate tests or analysis to bolster the software’s assurance. One approach to this task would be to extract a model or specification of the software structure, analyze the legacy evidence to determine where it is insufficient relative to the structure and certification criteria, and use that information to drive automated means of augmenting the evidence to address the insufficiencies.

To support composed assurance the technologies need to capture a minimal set of obligations to ensure the generated and pre-existing evidence is valid. The primary technical challenge is the extraction of a specification rich enough to drive analysis and evidence generation.

Technical approaches other than those described will be considered and are encouraged. Proposals should clearly identify which thrust(s) they address. Technologies that can address both thrusts are preferred. A proposal responding to both must clearly delineate the two thrusts within its Statement of Work and Cost Proposal, to enable a partial award in the event that DARPA deems the approach to one thrust of greater interest than the approach to the other. Strong TA1 proposals will substantiate their approach’s ability to increase evidence quality. Evidence quality relates to the confidence level of assurance case arguments. High quality evidence results in high confidence arguments. Proposals addressing new software development should discuss how their proposed solution fits into a variety of software development methodologies. Proposals addressing legacy software may assume the use of Evidence Curation (TA2) technology to support the analysis of existing evidence. Strong proposals will describe expected interfaces with Evidence Curation. Strong proposals for legacy software will characterize the types of properties and evidence they expect to address. All proposals should provide analysis of the scalability of their approach. Table 1 shows the program goals and metrics.

TA2: Evidence Curation

Evidence Curation will develop a common representation that can capture all forms of assurance case evidence. This curation representation will link the evidence to particular parts of the software implementation. The data will be organized to facilitate quick identification of the strongest evidence (i.e., that which will provide the highest degree of confidence) for any query.

ARCOS will develop technology to maintain the provenance of the evidence, in order to assure that certifications rely solely upon valid evidence. Technical challenges include the development of representations that scale to the necessary size, and the identification and representation of relationships between evidence domains. Evidence curation plays a central role in the ARCOS program, as both Evidence Generation (TA1) and Assurance Generation (TA3) need to interoperate with Evidence Curation (TA2) technology. TA1 for new software needs to be able to input evidence into the curation representation. TA2 needs to curate existing evidence, often in human readable documents. TA3 needs to be able to perform analytics over the curated evidence, requiring interoperating with the TA2 technologies, as well as collaboration with the TA2 performers.

TA2 proposers may assume that a model of the implementation’s architecture is available. The architectural model may be the product of new software design or a specification derived for legacy software in TA1. Proposers should characterize the level of detail they are assuming in such models. Proposers may assume that electronic representations of all evidence is available.

Proposers must describe the interface between their proposed technology and all other technical areas. TA2 proposals must describe the merits of their curation approach in terms of providing access to evidence of high quality that is amenable to analysis. Strong proposals will be able to process human readable technical documents, curating the evidence found within. Strong proposals will describe example data formats for the various evidence domains. Strong proposals will describe, through a use case, an example analysis that can be performed efficiently with their evidence representation. Strong proposals will present an analysis of the scalability of their approach. Table 1 shows the program goals and metrics.

TA3: Assurance Generation

Assurance Generation has two goals. First, develop technology for the automatic construction of assurance cases for certification criteria and obligations imposed by evaluated components.

Second, develop trustworthy technology for validating and assessing the confidence of an assurance case argument. Generation of assurance case arguments may be done through an iterative process of selecting an argument strategy or assurance pattern and then fleshing out that strategy or pattern with evidence and sub-arguments. Analytic technology will select substantiating evidence to provide the highest level of confidence from curated evidence. To foster trust in the ARCOS system, the generated assurance cases must be checkable by humans. A human evaluator must be able to understand the argument and to assess its strength based on the evidence that supports it. This technical area must develop sound and demonstrably correct technology to validate assurance cases. The assurance case validation technology will not only check the logic structure and validity of the argument, it will also calculate the confidence level of the argument, given the evidence used to substantiate.

Proposers to TA3 may respond to assurance case generation, assurance case validation, or both. A proposal responding to both must clearly delineate the two tasks within its Statement of Work and Cost Proposal, to enable a partial award in the event that DARPA deems the approach to one task of greater interest than the approach to the other. Proposals should address developing the capability to construct sound argument tree structures from argument patterns, developing efficient analytics to select strong evidence to substantiate arguments, and developing a sound approach to calculating argument confidence from the evidence used to make the argument. TA3 proposals must describe the expected inputs and interfaces, including design/implementation details, evidence store, and certification criteria. Human-on-the-loop solutions will be considered, although automated solutions are preferred. Solutions producing arguments that are pending additional evidence will be considered. Such solutions should provide the user feedback regarding additional evidentiary needs. Strong TA3 proposals will either use an existing assurance case language (perhaps extending it) or provide a compelling argument for creating a new language.

Strong proposals will clearly characterize the class of certification criteria for which their solution can generate assurance cases. Strong proposals must contain a sound approach for calculating confidence in a composed argument, accounting for the confidence that obligations for using the components have been met, and the confidence in the components’ properties. Strong proposals should illustrate with use case examples how the relative strength of evidence including comparing evidence from multiple domains is determined. Table 1 shows the program goals and metrics.

TA4: Quantitative Assessment

The Quantitative Assessment team will provide progressively challenging sets of artifacts of software systems to measure the progress of ARCOS technologies. Necessary software system artifacts include assurance evidence in the various domains, software design information, software documentation, and software implementations. The progression of challenges will culminate in applying ARCOS technologies to a realistic system. The envisioned progression over three program phases are: (1) a single software module with associated artifacts; (2) a set of interacting modules with associated artifacts; and (3) a realistic military software system. A challenge for the TA4 performer will be to provide artifacts that can be disseminated to all performers, while providing realistic challenges that drive program success. The TA4 performer will provide digital models of the software being assured by the beginning of each assessment. These models are to be sufficiently detailed to allow correlation of curated evidence to the model. The TA4 performer will supply Subject Matter Expertise (SME), to facilitate the understanding of the evaluation system and its evidence. TA4 will, in the final assessment, apply ARCOS technologies, with support from other performers, including the reimplementation of a software module. An ideal system will have a rich set of certification criteria to satisfy from multiple domains. For example, a system that has security requirements and safety requirements.

The TA4 team will run the periodic program assessments. They will provide the assessment inputs, and select which outputs are to be evaluated by a team of government certification experts.

Since it will be infeasible for the evaluation team to consider all of the generated output, the TA4 team will provide a method for selecting output for evaluation to maximize the confidence in the assessments.

Proposals must describe a progression of challenge sets and the final evaluation system, as well as the target certification requirements. The challenge sets must have assurance evidence in consumable electronic formats (e.g., databases, spreadsheets), and also in human readable electronic formats. Strong proposals will include a strategy for providing access to all performers of relevant challenge problems while meeting the scaling goals of the program. Strong proposals will describe how data will be selected for evaluation to optimize the evaluation team’s time and maximize the confidence in the technology assessment. Strong proposals will include approval from a Government Program Office for the use of the system as the ARCOS evaluation system.

Table 1 shows the program goals and metrics.

D. Program Assessments/Schedule

ARCOS is a four-year program, divided into three phases. The first and second phases will be 18 months each, and the third phase will be 12 months long for a total program length of 48 months, or four years. There will be five assessments to measure the technical progress over the course of the program, including two assessments in Phase 1, two assessments in Phase 2, and one assessment in Phase 3. The initial assessment in phases 1 and 2 will generate feedback for the performers from the assessment and evaluation teams, and verify that the various components interoperate correctly. Human-in-the-loop or human-on-the-loop processing is allowed during these two assessments. The goal is to get a sampling of the intended outputs to critique. The final assessment from each phase is to measure a realistic application of the program-developed technology. The TA1 assessments will require the re-implementation of software and the generation of new assurance evidence, and consequently it is envisioned that the TA1 assessments will need more time and will start slightly ahead of the TA2 and TA3 assessments.

For planning purposes, proposers should assume all meetings are two (2) days in length and alternate between the East and West coast. Table 1 shows the goals and metrics for the assessments, Figure 2 shows the program schedule. Program Principal Investigator (PI) meetings are scheduled to facilitate the assessment process, preparing evaluators for assessments, and disseminating results after assessments. The planned PI meetings are as follows:

Kickoff Meeting

PI meetings with all performers will occur before the initial assessments in Phase 1 and Phase 2

PI meetings of the TA1 and TA4 performers will occur before end-of-phase TA1 assessments

PI meetings of TA2, TA3, and TA4 performers will occur before end-of-phase TA2 and TA3 assessments

PI meetings will occur after evaluation of assessment data to present the findings of the evaluators and provide general feedback

Table 1: ARCOS Goals and Metrics

Figure 2: ARCOS Schedule

E. Deliverables

All performers (all TAs) shall be required to provide the following deliverables:

Commented source code, other necessary data, and accompanying documentation for all software developed under this program.

Regular code drops provided to the Quantitative Assessment Team (TA4) to include source code, build scripts, development environments, and test inputs.

For all developed tools, a document discussing concepts of operation for conducting evaluations, and user guidance for conducting tool assessments. This is to be delivered 30 calendar days before each assessment.

Slide Presentations - Annotated slide presentations shall be submitted within one month after the program kickoff meeting and after each program event (program reviews, assessments, PI meetings, and technical interchange meetings).

Quarterly Progress Reports - A monthly progress report describing technical progress made, resources expended, major risks, planned activities, trip summaries, changes to key personnel, and any potential issues and problem areas requiring the attention of the Government team shall be provided within 15 calendar days after the end of each month.

A Technical and Management Work Plan with a project schedule including milestones, updated as required.

End of Phase Report after each program phase and a Final Technical Report; the final report shall concisely summarize the effort conducted up to the end of the period of performance.

In addition, the following deliverables are required for TA4:

A report on each assessment. The reports must include quantitative results, including data collected in digital format, and results of each performer’s performance with respect to the goals and metrics outlined in Table 1. This is to be delivered 30 calendar days after the end of each assessment. Preliminary results of assessments shall be presented at the post-assessment PI meeting.

F. 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 VI.B.1 for more details on intellectual property.

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 a minimum of Government Purpose Rights (GPR), as lesser rights may adversely impact the lifecycle costs of affected items, components, or processes.

G. Security Clearance Requirements

The ARCOS program and developed technology are unclassified. In order to support working with classified systems, either from the TA4 Quantitative Assessment team, or through a transition partner, it is desired that each awardee have at least one SECRET cleared person.

H. Potential Conflicts of Interest

Each proposal may only address a single technical area, but proposers may submit multiple proposals. While proposers may submit proposals for all four technical areas, proposers selected for TA4 cannot be selected for any other technical areas, whether as a prime, subcontractor, or in any other capacity from an organizational to individual level. This is to avoid organizational conflict of interest (OCI) situations between the technical areas and to ensure objective test and evaluation results. The decision as to which proposal to consider for award is at the discretion of the Government.

II. Award Information

A. Awards

DARPA anticipates multiple awards for TA1 and TA3, as well as single awards for TA2 and TA4.

The level of funding for individual awards made under this solicitation has not been predetermined and will depend on the quality of the proposals received and the availability of funds. Awards will be made to proposers whose proposals are determined to be the most advantageous to the Government, all factors considered, including the potential contributions of the proposed work, overall funding strategy, and availability of funding. See Section V for further information.

The Government reserves the right to:

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

make awards without discussions with proposers;

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

segregate portions of resulting awards into pre-priced options;

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

fund proposals in increments and/or with options for continued work at the end of one or more phases;

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

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

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

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

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

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 BAA, the Government expects that program goals as described herein may be met by proposed efforts for fundamental research and non-fundamental research.

Some proposed research may present a high likelihood of disclosing performance characteristics of military systems or manufacturing technologies that are unique and critical to defense. Based on the anticipated type of proposer (e.g., university or industry) and the nature of the solicited work, the Government expects that some awards will include restrictions on the resultant research that will require the awardee to seek DARPA permission before publishing any information or results relative to the program.

Proposers should indicate in their proposal whether they believe the scope of the research included in their proposal is fundamental or not. While proposers should clearly explain the intended results of their research, the Government shall have sole discretion to determine whether the proposed research shall be considered fundamental and to select the award instrument type.

Appropriate language will be included in resultant awards for non-fundamental research to prescribe publication requirements and other restrictions, as appropriate. This language can be found at http://www.darpa.mil/work-with-us/additional-baa.

For certain research projects, it may be possible that although the research to be performed by a potential awardee is non-fundamental research, its proposed subawardee’s effort may be fundamental research. It is also possible that the research performed by a potential awardee is fundamental research while its proposed subawardee’s effort may be non-fundamental research. In all cases, it is the potential awardee’s responsibility to explain in its proposal which proposed efforts are fundamental research and why the proposed efforts should be considered fundamental research.

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

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

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

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

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

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

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

http://www.darpa.mil/work-with-us/additional-baa#NPRPAC https://doi.org/10.6028/NIST.SP.800-171r1

III. Eligibility Information

A. Eligible Applicants

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

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

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

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

b. Government Entities Government Entities (e.g., Government/National laboratories, military educational institutions, etc.) are subject to applicable direct competition limitations. Government entities must clearly demonstrate that the work is not otherwise available from the private sector and provide written documentation citing the specific statutory authority and contractual authority, if relevant, establishing their ability to propose to Government solicitations. 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. Foreign Participation 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 BAA. 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 supplemental OCI policy that prohibits contractors/performers from concurrently providing Scientific Engineering Technical Assistance (SETA), Advisory and Assistance Services (A&AS) or similar support services and being a technical performer.

Therefore, as part of the FAR 9.5 disclosure requirement above, a proposer must affirm whether the proposer or any proposed team member (subawardee, consultant) is providing SETA, A&AS, or similar support to any DARPA office(s) under: (a) a current award or subaward; or (b) a past award or subaward that ended within one calendar year prior to the proposal’s submission date.

If SETA, A&AS, or similar support is being or was provided to any DARPA office(s), the proposal must include:

The name of the DARPA office receiving the support;

The prime contract number;

Identification of proposed team member (subawardee, consultant) providing the support; and An OCI mitigation plan in accordance with FAR 9.5.

Government Procedures In accordance with FAR 9.503, 9.504 and 9.506, the Government will evaluate OCI mitigation plans to avoid, neutralize or mitigate potential OCI issues before award and to determine whether it is in the Government’s interest to grant a waiver. The Government will only evaluate OCI mitigation plans for proposals that are determined selectable under the BAA evaluation criteria and funding availability.

The Government may require proposers to provide additional information to assist the Government in evaluating the proposer’s OCI mitigation plan.

If the Government determines that a proposer failed to fully disclose an OCI; or failed to provide the affirmation of DARPA support as described above; or failed to reasonably provide additional information requested by the Government to assist in evaluating the proposer’s OCI mitigation plan, the Government may reject the proposal and withdraw it from consideration for award.

C. Cost Sharing/Matching

Cost sharing is not required; however, it will be carefully considered where there is an applicable statutory condition relating to the selected funding instrument (e.g., OTs under the authority of 10 U.S.C. § 2371).

For more information on potential cost sharing requirements for Other Transactions, see http://www.darpa.mil/work-with-us/contract-management#OtherTransactions.

D. Other Eligibility Requirements

1. Ability to Receive Awards in Multiple Technical Areas - Conflict of Interest While proposers may submit proposals for all four technical areas, proposers selected for TA4 cannot be selected for any other technical areas, whether as a prime, subcontractor, or in any other capacity from an organizational to individual level. This is to avoid OCI situations between the technical areas and to ensure objective test and evaluation results. The decision as to which proposal to consider for award is at the discretion of the Government.

2. Ability to Support Classified Development The ARCOS program and developed technology are unclassified. However, in order to support working with classified systems, either from the TA4 Quantitative Assessment team or through a transition partner, it is desired that each awardee (TA1, TA2, TA3, and TA4) have at least one SECRET cleared person at time of proposal. Proposers must provide their CAGE code and security point(s) of contact in their proposals.

IV. Application and Submission Information

A. Address to Request Application Package

This document contains all information required to submit a response to this solicitation. No additional forms, kits, or other materials are needed except as referenced herein. No request for proposal (RFP) or additional solicitation regarding this opportunity will be issued, nor is additional information available except as provided at the Federal Business Opportunities website (https://www.fbo.gov), or referenced herein.

B. Content and Form of Application Submission

1. Abstracts Proposers are highly encouraged to submit an abstract in advance of a proposal to minimize effort and reduce the potential expense of preparing an out of scope proposal. The abstract provides a synopsis of the proposed project, including brief answers to the following questions:

What is the proposed work attempting to accomplish or do?

What is the technical approach (concisely), what are the major innovations, and what are the risks?

How much will it cost, and how long will it take?

DARPA will respond to abstracts with a statement as to whether DARPA is interested in the idea. If DARPA does not recommend the proposer submit a full proposal, DARPA will provide feedback to the proposer regarding the rationale for this decision. Regardless of DARPA’s response to an abstract, proposers may submit a full proposal. DARPA will review all conforming full proposals using the published evaluation criteria and without regard to any comments resulting from the review of an abstract.

Abstract Format: Abstracts shall not exceed a maximum of five (5) pages including the cover sheet and all figures, tables, and charts. The page limit does not include a submission letter (optional).

Reminder – Each abstract submitted in response to this BAA shall address only one TA.

Organizations may submit multiple abstracts to any one TA, or they may submit abstracts to multiple TAs.

All pages shall be formatted for printing on 8-1/2 by 11 inch paper with 1-inch margins and font size not smaller than 12 point. Font sizes of 8 or 10 point may be used for figures, tables, and charts. Document files must be in .pdf, .odx, .doc, .docx, .xls, or .xlsx formats.

Submissions must be written in English. All pages should be numbered.

Abstracts must include the following components:

Cover Sheet: Provide the administrative and technical points of contact (name, address, phone, email, lead organization). Include the BAA number, title of the proposed project, primary subcontractors, estimated cost, duration of the project, and the label “Abstract.”

https://www.fbo.gov/

Goals and Impact: Describe what is being proposed and what difference it will make (qualitatively and quantitatively) if successful. Describe the innovative aspects of the project in the context of existing capabilities and approaches, clearly delineating the relationship of this work to any other projects from the past and present.

Technical Plan: Outline and address all technical challenges inherent in the approach and possible solutions for overcoming potential problems. Provide appropriate specific milestones (quantitative, if possible) at intermediate stages of the project to demonstrate progress.

Capabilities/Management Plan: Provide a brief summary of expertise of the team, including subcontractors and key personnel. Identify a principal investigator for the project and include a description of the team’s organization including roles and responsibilities. Describe the organizational experience in this area, existing intellectual property required to complete the project, and any specialized facilities to be used as part of the project. List Government-furnished property, facilities, or data assumed to be available.

Statement of Work, Cost and Schedule: Provide a top-level work breakdown structure with a succinct description of what is to be accomplished in each task. Provide a cost estimate for resources over the proposed timeline of the project, broken down by phase.

Include labor, materials, a list of deliverables and delivery schedule. Provide cost estimates for each subcontractor (may be a rough order of magnitude).

2. Proposals Proposals consist of Volume 1: Technical and Management Proposal (including mandatory Appendix A); Volume 2: Cost Proposal; the Level of Effort Summary by Task Excel spreadsheet; and the PowerPoint summary slide.

All pages shall be formatted for printing on 8-1/2 by 11-inch paper with 1-inch margins, single-line spacing, and a font size not smaller than 12 point. Font sizes of 8 or 10 point may be used for figures, tables, and charts. Document files must be in .pdf, .odx, .doc, .docx, .xls, or .xlsx formats. Submissions must be written in English. All pages of Volume 1 should be numbered.

A summary slide of the proposed effort, in PowerPoint format, should be submitted with the proposal. A template slide is provided as an attachment to the BAA. Submit this PowerPoint file in addition to Volumes 1 and 2 of your full proposal, and the Level of Effort Summary by Task Excel spreadsheet. This summary slide does not count towards the total page count.

Reminder – Each proposal submitted in response to this BAA shall address only one TA.

Organizations may submit multiple proposals to any one TA, or they may propose to multiple TAs.

Proposals not meeting the format prescribed herein may not be reviewed.

a. Volume 1: Technical and Management Proposal The maximum page count for Volume 1 is 40 pages, if responding to multiple thrusts in either TA1 or TA3 the maximum page count is 43, including all figures, tables and charts but not including the cover sheet, table of contents or appendices. A submission letter is optional and is not included in the page count. Appendix A does not count against the page limit and is mandatory.

Volume 1 must include the following components:

i. Cover Sheet: Include the following information.

Label: “Proposal: Volume 1” BAA number (HR001119S0057) Technical Area Proposal title Lead organization (prime contractor) name Type of organization, selected from the following categories: Large Business, Small Disadvantaged Business, Other Small Business, HBCU, MI, Other Educational, or Other Nonprofit

Technical point of contact (POC), including name, mailing address, telephone number, and email address

Administrative POC, including name, mailing address, telephone number, and email address

Security POC, including name, mailing address, telephone number, and email address

Award instrument requested: procurement contract (specify type), or OT2 Total amount of the proposed effort Place(s) and period(s) of performance Other team member (subcontractors and consultants) information (for each, include Technical POC name, organization, type of organization, mailing address, telephone number, and email address)

Proposal validity period (minimum 120 days) Data Universal Numbering System (DUNS) number3 Taxpayer Identification Number (TIN)4 Commercial and Government Entity (CAGE) code5

2 Information on award instruments can be found at http://www.darpa.mil/work-with-us/contract-management.

3 The DUNS number is used as the Government's contractor identification code for all procurement-related activities.

Go to http://fedgov.dnb.com/webform/index.jsp to request a DUNS number (may take at least one business day). For further information regarding this subject, please see www.darpa.mil/work-with-us/additional-baa for further information.

4 See…