Rainfire_BOA_Guide_v2.0_21September_2018.docx

UNCLASSIFIED//FOR OFFICIAL USE ONLY

UNCLASSIFIED

ORDERING GUIDE FOR

RAINFIRE

Version 2.0 21 September 2018

Table of Contents

1. (U) Introduction (U//FOUO) The United States Cyber Command (USCYBERCOM) Capability Development Group (CDG) has a recurring requirement for analytics support capabilities, to include analytic development, transition, and optimization. The analytic capabilities procured under this effort support cyber warfighters within the Department of Defense (DoD).

(U) Through these Basic Ordering Agreements (BOAs), the Government seeks to develop, maintain, sustain, optimize, and customize robust analytic capabilities for USCYBERCOM mission sets. Furthermore, these BOAs will position USCYBERCOM CDG to rapidly respond to emerging mission needs and ongoing DoD operational requirements.

1.1. Purpose

(U) This document describes the process for ordering RAINFIRE development and services. The establishment of the BOAs under a multiple award basis was intended to streamline the acquisition timeline to get analytics awarded and to the mission force. At time of original solicitation, the Government established that all BOA holders are technically acceptable.

(U) Future orders for standard analytics will be based on the lowest price. No additional technical volumes will be required, as technical acceptability was determined at time of award.

(U) Future orders for non-standard analytics will be based on best value to the Government. Minimal technical volumes will be required (no greater than 10 pages) and will be traded off with the cost factors to determine best value to the Government.

(U) This document is intended as guidance only. In the event that any statement in the Ordering Guide conflicts with the terms and conditions of the BOA, the terms and conditions will take precedence.

1.2. (U) RAINFIRE Requirement Development Process

(U) RAINFIRE will enable USCYBERCOM to procure analytic development support, in real time, as analytic requirements are identified through the CDG process. As depicted in Figure 1, once analytic requirements are identified and documented by the CDG, BOA holders will be able to provided a copy of the need statement and asked to price the effort. The process will afford contractors an opportunity to ask questions to resolve any unknown items and clarify requirements.

(U) Following delivery of each analytic, the Government will conduct integration activities, maintain configuration control and lead sustainment activities.

(U) FIGURE 1: Analytic Development Process

1.3. (U) Authorized Users

(U) The RAINFIRE contract is intended for use by USCYBERCOM, Service Cyber Components, the Cyber Mission Forces (CMFs) and other users as approved by the Procuring Contracting Officer (PCO).

2. (U) Ordering Process

2.1. (U) Customer Identification of Requirements:

(U//FOUO) USCYBERCOM CDG shall consolidate and validate cyber mission needs associated with analytic requirements. USCYBERCOM shall prioritize development/support. Once the requirement is identified, a call shall be developed for the BOA that identifies if the effort is a standard analytic or non-standard analytic. If the effort is a non-standard analytic, the BOA holder must have the tasking for that optional requirement (Statement of Work, Section 4.5) in order to be eligible to respond.

The requiring activity shall develop and document the analytic requirement, as approved by CDG and documented as a CDG Requirement (CDGR). An order template can be found in Appendix A. The requiring activity shall ensure that each cyber analytic requirement is vendor neutral. Each Call Order shall include the following considerations:

· Results of Make-Reuse analysis conducted in support of the CDGR

· Analytic Technical Requirements

· CDGR and overarching analytic requirement description

· Functional and Non-Functional Requirements

· Tolerance of false positives and required successful detection rates

· Description of Target Environment(s) and platform complexity

· Description of visualization needs

· Description of Operational Architecture

· Description of datasets to be run through the analytic, to include data throughput and scaling

· Period of Performance

· Identification of small business set-aside opportunities or an explanation for why the requirement cannot be set aside for small business participants.

· Available Government Furnishings

· Access to production representative environment/infrastructure for testing

· Provision of a development cloud for analytic development

· Sample data for testing

· Operational Test plan template

· Use cases for each analytic

· Required Delivery Timelines

· CDRL Requirements

· Acceptance Criteria and Acceptable Levels of Performance, including metrics for successful development

· Security and Classification Restrictions

· Milestone Payment Process

2.2. (U) Release of the Call

(U) The Government will issue a call for each analytic requirement (or related set of analytic requirements) to the eligible BOA holders. If the analytic work being requested is derived from other efforts, such as prototypes developed in a lab environment, a bidders library will be included in the call. Classification of the requirement, place of performance for the requirement, and a description of the analytic shall be issued with the call. The call shall also identify the specified due date for response. If the call is for non-standard analytics, the technical evaluation criteria and relative weighting with the cost factor shall be released at time of the call.

2.3. (U) Question Period

(U) Eligible BOA holders may have questions regarding the requirement or performance specifications. BOA holders have three (3) business days to submit written questions to the PCO. The Government will respond within three (3) business days, depending on the complexity of the questions received.

2.4. (U) Eligible BOA Holder Response

(U) From date of release of the Call, the eligible BOA holders shall have fifteen (15) business days to provide a firm fixed price associated with delivering the analytic. There shall be no page limits to the price volume for the standard analytics. All technical volumes for the non-standard analytics shall have page limits (not to exceed 10 pages) in the call source selection plan.

(U) All responses shall include a Basis of Estimate and total fixed price to complete the analytic. All responses must be delivered in an MS Office format. If MS Excel files are delivered to support the proposal, the file must contain fully executable formulas. PDF files will not be accepted. If the BOA holder is requesting milestone payments with the delivery of the analytic, the milestone and payment schedule must be clearly identified at the time of proposal submission.

(U) The offeror is cautioned that any proposals the Government considers to be unrealistic in terms of approach, cost, or schedule will be deemed indicative of an inherent lack of comprehension of the complexity and risks of the effort and may be rejected.

2.5. (U) Government Evaluation

(U) The Government anticipates awards based upon initial offers, without discussions.

(U) For standard analytics, the Government shall review the Basis of Estimate and perform a mathematical verification. Awards will be issued on a low priced basis (based on the mathematically verified price, if there are deviations from the price proposed by the BOA holder, the Government number shall be used for evaluations), as all BOA holders have already been deemed technically acceptable. Should initial proposals exceed the Government budget, the Government reserves the right to cancel the order to re-define the analytic requirements.

(U) For non-standard analytics, the Government may choose to solicit on a best value basis. The Government will issue an independent Source Selection Plan for such occasions that outlines the process.

2.6. (U) Notification, Award and Debrief of Offerors

(U) The PCO shall notify all Offerors of the successful BOA holder. A written notification shall be issued to the unsuccessful BOA holders that includes the successful BOA Holder name and price.

(U) Debriefs are not anticipated for standard analytics, as all eligible BOA holders were deemed technically acceptable and no further analysis is being performed other than evaluation of the lowest price.

(U) Debriefs may be requested for non-standard analytics. The Government reserves the right to provide the debrief in writing.

2.7. (U) Order Modifications

(U) Order modifications are generally made for administrative reasons, to correct oversights or changes in conditions from original order. If the proposed modification alters the scope of the order significantly, the PCO shall issue a new call to acquire the analytic. Only the PCO can make the determination as to whether a change may be incorporated as a modification or will be issued as a new call.

3. (U) Eligibility Considerations

3.1. (U) Performance

(U) The BOA holders must maintain 100% delivery for analytics in accordance with contract period of performance. Should a BOA holder win an order, but fail to meet performance requirements or the performance delivery date, they will become in-eligible for future calls (upon notice of non-delivery) for a period of 12 months.

3.2. (U) Small Business Set Asides

(U) The Government reserves the right to restrict calls to small businesses. Small business set asides shall be indicated at time of call.

3.3. (U) Maintenance and Support

(U) For Cyber Analytics developed under the RAINFIRE BOA, the Government retains the right to issue follow-on sole source orders for continued maintenance and sustainment, beyond the 180 day post-delivery support period, to the vendor that built the original analytic.

4. (U) Security Requirements (U//FOUO) Performance under this contract may be up to the TOP SECRET level. Some work perform under this contract may be at the UNCLASSIFIED, CONFIDENTIAL, or SECRET levels. All program related activities and deliverables shall be provided at the lowest classification level possible.

(U) At time of issuance of a call, the Government will identify the security requirements and the anticipated place of performance. BOA holders may be responsible for acquiring access to a facility cleared for the processing and storing classified material up to, and including, TS/SCI level.

(U) Personnel working on the integration of the analytic may be required to possesses a TOP SECRET (TS) SECURE COMPATMENTALIZED INFORMATION (SCI) level clearance. It is anticipated that transition/deployment/user acceptance activities will require cleared facilities and personnel. Calls may be released at the TS/SCI security level, at the discretion of the PCO.

APPENDIX A: BOA HOLDERS

APPENDIX B: RAINFIRE REQUIREMENT TEMPLATE

Cyber Analytic Requirement Title: Title Date: Date Primary Point of Contact: POC Overview: Provide an overview (1 to 2 sentences) of the Cyber Analytic requirement, to include the user set, the capability need, the data sources, and the overarching operational objectives.

Background and Operational Architecture: Provide background information relevant to understanding the capability need. Include a thorough depiction of how the Cyber Analytic will be utilized inside the USCYBERCOM operational architecture. Use diagrams to the greatest extent practicable.

Problem: Define the overarching problem set that precipitates the need for a Cyber Analytic effort. This could include descriptions of the current process (which fails to utilize or underutilizes analytics). Describe cyber mission risks that the cyber analytic effort will help mitigate. Describe cyber-specific mission context, as applicable (e.g., Cyber hunt, operational detect/response, net defense, cyber capture the flag, document analysis, defensive cyber operations, offensive cyber operations). Describe use cases for how and when the analytic will be utilized. Reference attachments, as necessary CDGR: Describe the requirement, as defined in the applicable CDGR. Attach all relevant documentation that would be needed to fully understand the requirement.

Make/Reuse Analysis: Describe the results of the make/reuse analysis that was conducted by CDG. The results will identify if a new analytic should be created or if the Cyber Analytic Requirement can be met by providing previously developed analytic(s). Any requirement for Analytic Maintenance (SOW 4.3) and Sustainment and Analytic Optimization and Customization (SOW 4.4) will require reused analytic components. For any reused analytic, consider all Government Furnishings that will be required in order for vendors to understand the analytic components to be reused.

The Government may award sole source follow-ons for maintenance and sustainment of analytics developed under RAINFIRE. If that provision applies to this analytic, describe it here.

BOA Analysis: Place a checkmark beside the appropriate pool

Describe the reasoning and technical content necessitating the use of any non-standard analytic pool.

Requirements:

· Functional Requirements: Describe what the analytic needs to accomplish. Define the overall functions of the analytic, to include required inputs, outputs, and behaviors. Often described in terms of “The Analytic must [do] ___________” and can be listed in bullet-point format. All requirements should be testable. Functional requirements must also address visualization requirements, as applicable.

· Non-functional requirements: Describe requirements that impose constraints on the design or implementation of the analytic. These can be performance requirements. Often described in terms of “The analytic shall [be] ____________” and can be listed in bullet-point format. All requirements should be testable. Non-functional requirements must address the following, as applicable:

· Tolerance of False Positives

· Interoperability – Describe any interoperability requirements (to include other analytics or other systems that the analytic must interface with

· Required Successful Detection Rates

· Accessibility – Describe any access requirements

· Throughput and scaling – Describe all throughput and scaling requirements, such as the analytic processing rate on input data, which other analytics need to work in conjunction with this analytic, and describe the analytic system that this cyber analytic requirement will operate within.

· Usability

· Analytic Need Date: When does the analytic requirement need to be delivered?

· Target Environment and Platform: Describe the target computing environment, to include descriptions of the use of the Big Data Platform (BDP) or the Distributed Cyber Analytic Framework (DCAF). This area may also include discussion of other target computing environments (cloud environments, etc.)

· Description of Datasets to be run through the analytic: Describe the datasets to be used in conjunction with the analytic.

Sustainment Considerations: Describe any unique sustainment considerations related to this cyber analytic effort. If the analytic will be maintained in a library, describe the characteristics of that library and what interface requirements the analytic must adhere-to.

Other Considerations and Requirements: Describe other considerations that may be relevant to this Cyber Analytic Requirement. Describe if a development environment will be provided to the vendor in support of this effort. Other considerations could include reconfiguration requirements after installation, policies and procedures that apply to the effort, stakeholders that the vendor must interface with (and why), etc.

Unique Test and Evaluation Requirements: Describe any unique testing requirements or characteristics related to this analytic, beyond those described in SOW 4.2.3 and 4.2.4.

· What test standards will be required?

· What will the process be for transition? Will the contractor require access to Government systems and spaces for this transition, and does this necessitate a security classification requirement? What work is the contractor expected to perform during testing, evaluation, and transition (beyond that described in SOW 4.2.3 and 4.2.4?

· Will access to a production representative environment/infrastructure be provided for testing? If so, in what ways does the environment represent the production environment (e.g., is it only a percentage of deployed operational resources).

· Will sample data be provided for testing?

· Will an operational test plan template be provided?

· Will a common operational test framework be provided?

Classification Requirements: Describe any unique classification requirements for this analytic. For example, if the analytic must be developed in a classified environment, that should be described here. Any activities within the analytic process that will necessitate classified access should be described here.

Call Order RFQ Response Time:

Question Period: 3 Days from Date of RFP release.

RFQ Responses due: 15 Days from Date of RFP release.

Government Furnishings: Describe any Government Furnishings that will be provided after award of this call order:

· Access to Production Representative Environment/Infrastructure

· Sample data for testing Attachments: Describe any attachments to this RFQ Worksheet. These are items that will be released to RAINFIRE BOA holders in order to help inform their RFQ responses.

· CDGR References

· Requirement Documentation References

· Reference Architectures

· Reuse Analytics and Associated Documentation

· Operational Architecture References

· Use Cases

· Operational Test Plan Template

User Need(s) Identified (Gov't led)

CDG Req'ts Documented (Gov't led)

BPA Call and Selection of Vendor

Development, Test and Delivery

Integration (Gov't led)

Sustainment (Gov't led) image1.png