DRAFT PWS_Nimbus_2024 10 17.docx

DOCX document 165 KB Posted

Attached to
NIMBUS
Solicitation number
FA875025RB001
Issued by

About this file

This document is a Draft Performance Work Statement (PWS) for the Nimbus PCSN contract. The key details are:

The objective is to provide systems engineering services to facilitate Intelligence, Surveillance and Reconnaissance (ISR) assurance and fielding missions. Major service efforts will include requirements development, logical analysis, solution design, information assurance (IA) and test documentation implementation, integration, verification/validation of IA and security architecture, and certification/accreditation support. The anticipated contract type is Cost-Plus Fixed Fee with a 36-month period of performance. 100% SECRET and 40% TS/SCI clearances will be required at the time of award. The NAICS code is 541512 with a small business size standard of $34M. Foreign participation is excluded at the prime contractor level. Responses from both small and large businesses indicating capability and interest are requested to support market research and a potential small business set-aside determination.

View the file

Other files

File Type Posted
Nimbus RFI Amendment for SAM 18Nov24.docx DOCX document
DRAFT PWS_Nimbus_11-7-2024.docx DOCX document
RFI for SAM_Nimbus_Mod1_31 Oct 24.docx DOCX document

On GovTribe

Work with this file

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

E-5-1501

AIR FORCE RESEARCH LABORATORY

ROME RESEARCH SITE

ROME, NEW YORK

DRAFT

PERFORMANCE WORK STATEMENT

FOR

Nimbus

PCSN E51501

17 OCT 2024

(Solicitation No. FA8750-25-R-B001)

1.0BACKGROUND
1.1The purpose and objective of this effort is to deliver Information Technology (IT) services throughout the AFRL/RIEB Systems Engineering (SE) Vee model (See Figure 1 below) to facilitate Intelligence, Surveillance, and Reconnaissance (ISR) Assurance and Fielding (A&F) missions while architecting, engineering, developing, integrating, testing transitioning and sustaining systems into operational environments with robust Development Test (DT), Operational Test (OT), security and Information Assurance (IA). This process can be applied to any Command, Control, Communications, Computer and Intelligence Surveillance and Reconnaissance (C4ISR) and Cybersecurity program or system being contemplated to meet warfighter mission requirements throughout the Department of Defense (DoD) and Intelligence Community (IC).
1.2Experience has shown that failure of application or system program managers ability to meet mission requirements in the field is very often the lack of incorporating sufficient assurance (IA, DT, OT) and fielding early, often and throughout the Air Force Research Laboratory Information Handling Branch (AFRL/RIEB) Systems Engineering (SE) Lifecycle Vee model. There are numerous examples of excessive schedule delays, excessive cost over runs, and even lost lives because systems were fielded with inadequate assurance of functional, operational suitability and effectiveness, performance, technical, security, and IA capabilities. This failure can be directly attributed to the lack of recognition that test and evaluation are essential components of the normal, routine IT lifecycle. The work performed under this order is not used to evaluate software or documentation delivered to the Government as part of the deliverable acceptance process.
1.3The role of test and evaluation is recognized in the AFRL/RIEB SE Vee model. Test and evaluation do not belong only at the end of the SE life cycle. Instead, there are milestones for evaluation throughout the process that assist the system designer and developer to maintain awareness of the readiness of the system for operational use. This is equally true for new capabilities that are investigated in the laboratory and must be shepherded through the Research and Development (R&D) phases from initial concept to operational prototype.

1.4 Conducting Intelligence Surveillance and Reconnaissance (ISR) missions, including Open Source (OSINT), Signals Intelligence (SIGINT), and Geospatial Intelligence (GEOINT) is critically important in the current geopolitical environment. The implementation of the Processing Exploitation and Dissemination (PED) workflows is also critically important and coincides with the fielding of C4ISR systems, both at CONUS and OCONUS facilities.

2.0DESCRIPTION OF SERVICES: The Contractor shall provide technical engineering services to facilitate C4ISR and Cybersecurity systems and missions as follows:
2.1Requirements Development
2.1.1Gather input from all relevant stakeholders and translate the inputs into technical, functional, performance, system, and security requirements. Requirements shall be quantifiable, have unique definitions, specify thresholds and objectives, be traceable, and define testable requirements. Collaborate with operational users, lead command and other stakeholders to establish and refine goals, attributes, performance parameters, and financial and schedule constraints, and ensure that all relevant requirements are addressed. Ensure the requirements comply with and are consistent with DoD Zero Trust Architecture.
2.1.2In collaboration with the Government, review requirements with respect to eventual verification and identify applicable functional DT, OT, IA and security policies with which the system must comply. Identify steps and processes that must be followed to achieve Assessment and Authorization (A&A).
2.1.3Identify functional DT, OT, security Zero Trust and IA issues in the planned system that will affect its integration, transition and fielding.
2.1.4Carefully examine and review the relevant security policy documents for the specific programs that are applicable to the operational environments in which the system will be deployed. The review should encompass policies for both unclassified Air Force networks, such as Non-Secure Internet Protocol Router NETwork (NIPRNET) and Defense Research and Engineering Network (DREN), as well as classified networks for SECRET and TOP SECRET Sensitive Compartmented Information (TS/SCI) enclaves and Special Access Program (SAP) and Special Access Required (SAR) enclaves.
2.1.5Coordinate with system stakeholders to research and refine functional DT, OT and IA requirements that are appropriate for and comply with security policy of the targeted networking environment. Ensure that the system developer and stakeholders are aware of the applicable security policies and necessary security requirements are addressed in the system architecture and design. Ensure sound systems engineering processes are initiated and updated throughout the SE VEE process including vulnerability management, configuration management, and change management. Review and update SE body of evidence documentation as required. Requirements are anticipated to include custom software and firmware running on commercial operating systems on commercial hardware and on Field Programmable Gate Arrays (FPGA) and Application Specific Integrated Circuits (ASIC).
2.1.6Coordinate with the cognizant Authorizing Official (AO) to identify the appropriate US Government process for A&A that the system must follow and to ensure security and IA robustness for the targeted networking environment is included.
2.1.7Coordinate with the Lead Development Test Organization (LDTO) to identify appropriate US Government processes for verification of requirements and to ensure a successful DT event.
2.1.8Coordinate with the Lead Operational Test Organization (LOTO) to identify appropriate US Government processes for validation of requirements along with mission suitability and effectiveness and to ensure a successful OT event.

2.1.9 Create, develop, and engage in continuous improvement of IT capabilities with requirements defined by NASIC/GXK in an agile development environment. The contractors must be able to work in a dynamic environment and adapt to current and future requirements.

2.1.10Identify and document the path or roadmap for functional DT, OT, A&A of the system in its intended operational environments.
2.1.11Coordinate with the Contracting Officer’s Representative (COR) to ensure testable DT, OT, security and IA requirements are defined, documented, and incorporated into the program’s requirements traceability matrix.

2.1.12 Research and architect software factories (e.g. CI/CD Pipelines, DEVSECOPS) to design and deliver secure software development environments that ensure Identification, Authentication, Authorization and Auditing (IAAA) mechanisms are binding for all developed software facilitating an automated Authorization to Operate (AtO) policy.

2.1.13 Work performed under this task order includes providing engineering and technical allsource analysis and data support focusing on adversary supply chains/ecosystems that unlay their research, development, test, acquisition, and sustainment capabilities/processes. Work performed will include evaluating and integrating data from classified and unclassified sources; performing technical analysis; developing assessments and evaluations; and providing reports.

2.1.14 Create and deliver the following documentation:

· Presentation Materials, including briefs, security road maps, and technical reports/white papers, describing the compliance of the system design with the governing security policies. (See CDRLs, A005, C005, D005, E005, F005, G005, H005, J005 and K005)

· Meeting Minutes for Design Reviews, Technical Exchanges, and other meetings attended. (See CDRLs, A006, C006, D006, E006, F006, G006, H006, J006 and K006)

· Trip Reports (See CDRLs, A007, C007, D007, E007, FG007, G007, H007, J007 and K007)

2.2Logical Analysis
2.2.1Perform logical analysis to obtain sets of logical solutions to improve understanding of the defined requirements and the relationships among the requirements (e.g., functional, behavioral, temporal). Once the logical solution sets are formed, allocate performance parameters and constraints and derive the defined technical requirements. Partition technical problems into self-contained, cohesive, logical groupings of elements and, where appropriate, define the key interfaces.
2.2.1.1Evaluate proposed solutions and assess the extent to which the technical and functional requirements can be tested and evaluated.
2.2.1.2Evaluate proposed solutions and assess the extent to which the system’s requirements are in compliance with documented security requirements; to include utilizing Machine Learning, Artificial Intelligence, Data Science and Data Analytics techniques.
2.2.1.3Evaluate ISR assurance and fielding deployment sites.
2.2.2Create and deliver the following documentation:

· Presentation Materials (See CDRLs, A005, C005, D005, E005, F005, G005, H005, J005 and K005)

· Meeting Minutes for Design Reviews, Technical Exchanges, and other meetings attended. (See CDRLs, A006, C006, D006, E006, F006, G006, H006, J006 and K006)

· Trip Reports (See CDRLs, A007, C007, D007, E007, F007, G007, H007, J007 and K007)

· Technical White Papers (See CDRLs, A010, C010, D010, ER010, F010, G010, H010, J010 and K010)

2.3Design Solution
2.3.1Create design solutions to translate the outputs of requirements development and logical analysis processes into alternative technical solutions and select a final technical path to explore. Use an iterative SCRUM, Agile, or waterfall process with the requirements development and logical analysis phases and integrate with the technical management processes; including Data Science and AI/ML, to identify and select the best solution. Deliver the resulting system design or physical architecture sufficiently detailed to allow upward and downward traceability of requirements.
2.3.1.1Evaluate program documentation to determine the extent to which the design of system functionality, systems, security, and components are traceable to documented requirements.
2.3.1.2Evaluate system security and functional requirements are traceable from requirement to code.
2.3.1.3Evaluate the readiness of applications for incorporation into the appropriate operational networking environment.
2.3.1.4Evaluate program documentation to determine the extent to which the site is prepared for installation.
2.3.1.5Conduct trade-off analysis of proposed designs and establish criteria for evaluating the extent to which each proposed design meets functional mission and security requirements.
2.3.1.6Participate in design reviews and technical exchange meetings as required for the purpose of design evaluation.
2.3.2Create and deliver the following documentation:

· Presentation Materials (See CDRLs, A005, C005, D005, E005, F005, G005, H005, J005 and K005)

· Meeting Minutes for Design Reviews, Technical Exchanges, and other meetings attended. (See CDRLs, A006, C006, D006, E006, F006,G006, H006, J006 and K006)

· Trip Reports (See CDRLs, A007, C007, D007, E007, F007, G007, H007, J007 and K007)

· Risk Assessment Reports (See CDRLs, A009, C009, D009, E009, F009, G009, H009, J009 and K009)

· Technical White Papers (See CDRLs, A010, C010, D010, E010, F010, G010, H010, J010 and K010)

· Site Preparation Requirements and Implementation Plan (SPRIP) (See CDRLs, A021, C021, D021, E021, F021, G021, H021, J021 and K021)

2.4Implementation
2.4.1Implement, design, develop, enhance and test individual elements for suitability within the targeted operational networking environment before they are passed to the integration phase. Develop supporting documentation for the system, such as the as-built configuration, or discovered limitations of the concept.

2.4.2 Develop and enhance systems, hardware, software, and Test Harnesses to facilitate systems engineering, development, and testing activities. To include creating tools that allow automation, enhancement, modeling and simulation of those activities within operational and cyberspace environments.

2.4.2.1 Participate in iterative test cycle activities such as DevSecOps, Continuous Integration / Continuous Development (CI/CD) activities as required in support of system development, testing, and integration.

2.4.3As the Test & Evaluation (T&E) and IA components of the system development, plan and prepare for and conduct Acceptance Test (AT), Integration Acceptance Test (IAT), DT, OT, Blue Team (e.g. CVPA), Red Team (e.g. Aggressor Assessments) evaluations and IA assessment of the system. Ensure the system complies with additional security policies such as Cross Domain T&E that require further evaluation and preparing for DT and OT with the LDTO and the LOTO.
2.4.3.1Review draft system documentation to document, identify, and address potential, IA functional, and security deficiencies.
2.4.3.2Plan and implement the test environment needed to adequately test system, functional, IA and security capabilities as related to the documented IA and security requirements.
2.4.3.3Prepare and draft test plans and test procedures as appropriate for the targeted operational enclave to evaluate the appropriateness of the system IA and security attributes.
2.4.3.4Evaluate the readiness of a site to begin installation or data center migration, ensure environmental resources (e.g. power, space, and cooling) are adequate and reserved for the project.

2.4.3.5 Ensure a complete and comprehensive Body of Evidence is developed for all C4ISR and Cybersecurity system that is designed, architected, engineered, developed, enhanced, integrated, transitioned, and supported under this contract. The body of evidence may include the following areas Supply Chain Risk Management (SCRM), Vulnerability Management, Patch Management, Configuration Management, Change Management, Test and Evaluation Master Plan (TEMP), Systems Engineering, and Program Management.

2.4.4 Deliver all created documentation and any software or hardware developed, enhanced, assembled or acquired in accordance with the following:

· Presentation Materials (See CDRLs, A005, C005, D005, E005, F005, G005, H005, J005 and K005)

· Meeting Minutes for Design Reviews, Technical Exchanges, and other meetings attended. (See CDRLs, A006, C006, D006, E006, F006, G006, H006, J006 and K006)

· Trip Reports (See CDRLs, A007, C007, D007, E007, F007, G007, H007, J007, and K007)

· Risk Assessment Reports document review reports describing findings in the system documentation requiring resolution (See CDRLs, A009, C009, D009, E009, F009, G009, H009, J009 and K009)

· Technical White Papers (See CDRLs, A010, C010, D010, E010, F010, G010, H010, J010 and K010)

· System Test Plan for test and evaluation and/or IA assessment (See CDRLs, A011, C011, D011, E011, F011, G011, H011, J011 and K011)

· System Test Procedures for test and evaluation and/or IA assessment (See CDRLs, A012, C012, D012, E012, F012, G012, H012, J012 and K012)

· Source and object (executable) Code (See CDRLs, A022, C022, D022, E022, F022, G022, H022, J022 and K022)

· Complete software documentation (See CDRLs, A023, C023, D023, E023, F023, G023, H023, J023 and K023)

· Acquired commercial off-the-shelf hardware and software (See CDRLs, A024, C024, D024, E024, F024, G024, H024, J024 and K024)

2.5Integration
2.5.1Integrate lower-level system elements into a higher-level system element in the physical architecture. Identify plans or strategy for the integration process, including the assembly sequence that may impose constraints on the design solution. Develop, integrate, test, and deploy AI/ML algorithms to enhance consistency through the integration phase.
2.5.2Conduct T&E, including System Testing and/or In-plant Acceptance Testing. Evaluate the integrated system against the documented requirements for the targeted operational networking environment. This includes the implementation of security requirements, daily and weekly regression of DT test cards and OT threads. Conduct this evaluation in preparation for development of the A&A packages that the system will need in order to field to operational environments.
2.5.2.1Conduct T&E to verify implementation of operational, functional, performance, and technical requirements in accordance with the Government’s schedule for testing and fielding.

2.5.2.2 Participate in iterative test cycle activities such as AGILE/SCRUM, DevSecOps, Continuous Integration / Continuous Development (CI/CD) activities as required in support of system development, enhancement, testing, and integration.

2.5.2.3 Conduct periodic functional and cybersecurity assessments to verify implementation of requirements.

2.5.3 Develop and enhance systems, hardware, software, and Test Harnesses to facilitate systems engineering, capability development, and testing activities. To include creating tools that allow automation, enhancement, modeling and simulation of development, enhancement and testing activities.

2.5.4 Create and deliver the following documentation:

· Presentation Materials describing progress of testing and issues (See CDRLs, A005, C005, D005, E005, F005, G005, H005, J005 and K005)

· Meeting Minutes for Design Reviews, Technical Exchanges, and other meetings attended. (See CDRLs, A006, C006, D006, E006, F006, G006, H006, J006 K006)

· Trip Reports (See CDRLs, A007, C007, D007, E007, F007, G007, H007, J007 and K007)

· Technical White Papers (See CDRLs, A010, C010, D010, E010, F010, G010, H010, J010 and K010)

· Test Reports (See CDRLs, A013, C013, D013, E013, F013, G013, H013, J013 and K013)

· Describing software bugs, performance issues, and issues in security and functionality observed during test and evaluation

· Incorporating the findings, conclusions, and possible mitigations resulting from the test activity

· Source and object (executable) Code (See CDRLs, A022, C022, D022, E022, F022, G022, H022, J022 and K022)

· Complete software documentation (See CDRLs, A023, C023, D023, E023, F023, G023, H023, J023 and K023)

· Acquired commercial off-the-shelf hardware and software (See CDRLs, A024, C024, D024, E024, F024, G024, H024, J024 and K024)

2.6Verification
2.6.1Verify that the system meets design specifications for the targeted operational networking environment. Test the system elements against the functional DT, OT, security and IA requirements defined earlier in the SE process. Formal Verification activities will be conducted by the LDTO. Ensure the program is prepared for a successful DT event. Verify design solutions at all levels of the physical architecture through a cost-effective combination of analysis, examination, demonstration, and testing, all of which can be aided by modeling and simulation.
2.6.2Document, review and build the Body of Evidence to verify that IA requirements are met and that additional security requirements that must be met for fielding, such as Continuity of Operation and Physical Security, that are not part of the system’s technical design are adequately addressed.
2.6.3Take into consideration that: (a) there is still much variation in A&A practices across the DOD and Intelligence Community; (b) the Body of Evidence may differ depending upon the community in which the system will be deployed; (c) security policy is evolving; and (d) IA assessment is based upon the DOD Risk Management Framework (RMF) and the use of the NIST 800-37 and NIST 800-53 security controls, to prepare the Body of Evidence necessary for the target community.
2.6.3.1Register the system in the appropriate tracking system (e.g., eMASS or XACTA), facilitating communication among Government stakeholders.
2.6.3.2Document and build the Body of Evidence required for A&A for the targeted operational networking environment and communities of interest to be utilized by the AO and application program manager and developer.
2.6.3.3Verify the implementation of functional, IA, and security requirements and record the results of testing during the verification phase in the appropriate tracking system.
2.6.3.4Verify implementation of DT cards and OT plans and maintain the results in the appropriate tracking system (e.g. Confluence, JIRA, Remedy, Serena).

2.6.4 Develop and enhance systems, hardware, software, and Test Harnesses to facilitate systems engineering, capability development, and testing activities. To include creating tools that allow automation, enhancement, modeling and simulation of testing activities.

2.6.5 Conduct functional, IA, and cybersecurity testing, to include vulnerability, penetration, and adversarial assessment testing, for systems, hardware, firmware, and software.

2.6.6 Create and deliver the following documentation:

· Presentation Materials describing progress of contractor activities during the verification phase (See CDRLs, A005, B005, C005, D005, E005, F005, G005, H005, J005 and K005)

· Meeting Minutes documenting Technical Exchanges attended during the verification phase (See CDRLs, A006, B006, C006, D006, E006, F006, G006, H006, J006 and K006)

· Trip Reports (See CDRLs, A007, B007, C007, D007, E007, F007, G007, H007, J007 and K007)

· Technical White Papers (See CDRLs, A010, B010, C010, D010, E010, F010, G010, H010, J010 and K010)

· Source and object (executable) Code (See CDRLs, A022, B022, C022, D022, E022, F022, G022, H022, J022 and K022)

· Complete software documentation (See CDRLs, A023. B023, C023, D023, E023, F023, G023, H023, J023 and K023)

· Acquired commercial off-the-shelf hardware and software (See CDRLs A024, B024, C024, D024, E024, F024, G024, H024, J024 and K024)

2.7Validation
2.7.1Validate the performance of the system, specifically system suitability and effectiveness, against program goals established to ensure system functional DT, OT, IA, security robustness, and penetration testing, which may include the use of red and blue teams, for the targeted operational networking environment. Formal Validation activities will be conducted by the LOTO. Ensure the program is prepared for a successful OT event.
2.7.2Evaluate the system Body of Evidence against the security controls or requirements specified in the governing security policy. Map the Body of Evidence to the appropriate security control. Validate in accordance with the Risk Management Framework (RMF) process, NIST 800-37, NIST 800-53 controls, and the current Cross Domain System Security Assessment (CDSSA) process. CDSSA is based on the Lab Based Security Assessment, or Cross Domain Risk Management (CDRM) that evaluates the level of risk of implementing the Cross Domain Solution (CDS).
2.7.3Comply with security functions provided by the site infrastructure, the host operating system and/or operational location standard operating procedures. Take into account those functions and assess the extent to which these functions assist the system to fully meet security policy.
2.7.4In collaboration with the Government, evaluate the risk of fielding the system in the targeted network operational environment based on the identification and mitigation of risk as opposed to the evaluation of compliance with security controls.
2.7.5Work closely with the requirement owner, lead command, program office and the LOTO to ensure validation test plans are incorporated as early and often throughout the SE process. One area of particular attention is coordination and agreement on the Risk Assessment Level of Test (RALOT) process. Define the RALOT early in the process and update as more information is determined as the solution is finalized in preparation of the OT event.
2.7.5.1Review and document the implementation of functional and IA requirements and record the compliance of the system with governing policy in the appropriate tracking system required for the targeted operational networking environment during the validation phase.
2.7.5.2Identify areas of non-compliance with governing security policy and contribute to development of a Plan of Actions and Milestones (POA&M) that documents the mitigation strategy and schedule for resolution of these areas of non-compliance.
2.7.5.3Complete the Validation component for the system entry in IA tracking system (e.g., eMASS, XACTA).
2.7.5.4Conduct or witness, as required, Security T&E events as determined by the AO.
2.7.5.5Conduct Risk Analysis based on the RMF and provide a Risk Assessment Report to the Government.
2.7.5.6Document the review of potential mitigations in the POA&M recommended for areas on non-compliance.

2.7.6 Develop and enhance system, hardware, software, and Test Harnesses to facilitate systems engineering, development, and testing activities. To include creating tools that allow automation, enhancement, modeling and simulation of testing activities within software factories based on CI/CD Pipeline, AGILE/SCRUM or DEVSECOPS.

2.7.7 Create and deliver the following documentation:

· Presentation Materials (See CDRLs A005, B005, C005, D005, E005, F005, G005, H005, J005 and K005)

· Meeting Minutes for Design Reviews, Technical Exchanges, and other meetings attended. (See CDRLs, A006, B006, C006, D006, E006, F006, G006, H006 J006 and K006)

· Trip Reports (See CDRLs, A007, B007, C007, D007, E007, F007, G007, H007, J007 and K007)

· Risk Assessment Report describing the results of system risk analysis as it applies to RMF (See CDRLs, A009, B009, C009, D009, E009, F009, G009, H009, J009 and K009)

· Technical White Papers (See CDRLs, A010, B010, C010, D010, E010, F010, G010, H010, J010 and K010)

· Test Reports (See CDRLs, A013, B013, C013, D013, E013, F013, G013, H013, J013 and K013)

· RMF IA Control Validation Reports describing the results and issues for systems under evaluation (See CDRLs, A014, B014, C014, D014, E014, F014, G014, H014, J014 and K014)

· Source and object (executable) Code (See CDRLs, A022, B022, C022, D022, E022,F022, G022, H022, J022 and K022)

· Complete software documentation (See CDRLs, A023, B023, C023, D023, E023, F023, G023, H023, J023 and K023)

· Acquired commercial off-the-shelf hardware and software (See CDRLs, A024, B024, C024, D024, E024, F024, G024, H024, j024 and K024)

2.8Transition
2.8.1Conduct transition activities that delivers a supportable technology into the hands of the warfighter.
2.8.2Conduct system transition to operational environments after the appropriate certifying and approval authority grants the approval to operate. Depending upon the system architecture, mission, and operational environment targeted for deployment, transition can vary and may include:
2.8.2.1Guidance, development, and/or review of required documentation in support of DT, OT, Red Team, Blue Team, and Security/IA testing.
2.8.2.2Guidance, development, and/or review of required documentation in support of fielding, deployment and transition.
2.8.2.3Execution and/or analysis of security scans and applicable Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIGs).
2.8.2.4Validation of RMF Packages (and DIACAP packages for programs utilizing legacy processes) and Information Systems Continuous Monitoring (ISCM) including Cyber Security Service Provider (CSSP) services. Provide 24X7 ISCM services as required in Technical Solution and Cost Estimates.
2.8.2.5Assessment of Risk Analysis packages.
2.8.2.6Evaluation of applications that qualify for the Air Force Evaluated Products List (EPL).
2.8.2.7Planning, execution, and reporting of CDSSA.
2.8.3Provide expertise and capability for deployment and A&A support.
2.8.3.1Identify and prepare the body of evidence (i.e., required documentation and data) for A&A and provide review of system documentation from an IA assessment perspective.
2.8.3.2Ensure the Site Preparation Requirements and Installation Plan (SPRIP) is finalized and fully coordinated and validated.
2.8.3.3Ensure environmental factors such as power, space and cooling parameters have not changed and that the transition location is still prepared for program deployment.
2.8.3.4Conduct required security scans including tools (e.g., Retina, Nessus, ACAS, SCAP) and analyze results for compliance with security policy.
2.8.3.5Execute DISA STIGs and analyze the results as appropriate for the system.
2.8.3.6Conduct IA control validation, continuous monitoring of system changes, and review of artifacts necessary for RMF A&A.
2.8.3.7Update IA Control validation and other findings in the System of Record (e.g., eMASS or XACTA).
2.8.3.8Review the Body of Evidence for the system.
2.8.3.9Prepare the system Risk Assessment Report as required by the CA.
2.8.3.10Review system POA&M.
2.8.3.11Review and assess Cross Domain solutions as specified by the Unified Cross Domain Management Organization and mandated for Cross Domain solutions.
2.8.3.12Prepare and conduct the Test Readiness Review and document the readiness of the system, the system developer, and the contractor test team for the scheduled start of AT, IAT, DT, OT, CDSSA testing and fielding.
2.8.3.13Prepare the CDSSA Test Plan and Objectives, mapping system capabilities to both the NIST Security Controls and to the RDAC or CDRM risk elements.
2.8.3.14Prepare test procedures to evaluate the compliance of the system under test to the appropriate NIST security controls documented in the CDS Overlay.
2.8.3.15Conduct CDSSA test and evaluation and record all procedures, findings, and data in the CDSSA tracking repository.
2.8.3.16Prepare the Technical Risk Rating Report and Policy Bypass Report for delivery to the Government.
2.8.3.17Provide CDSSA briefing materials to the COR for presentation to the Cross Domain Technical Advisory Board (CDTAB) and Defense Information Assurance Security Accreditation Working Group (DSAWG).

2.8.3.18 Provide oversight and maintenance, change and configuration management, and enhancement services of C4ISR systems.

2.8.3.19 Provide Tier 2, 3, and 4 Help Desk support services as necessary by mission partner organization.

2.8.3.20 Conduct system familiarization and knowledge transfer activities for the systems developed and/or enhanced as part of this PWS.

2.8.3.21 Perform Information System Security Officer (ISSO) and Information System Security Engineer duties to include scanning, account management, access control, and auditing.

2.8.3.22 Perform system and/or network administration.

2.8.4 Conduct ISR PED and RDA

2.8.4.1 Conduct comprehensive Processing, Exploitation, and Dissemination (PED) missions to support Intelligence, Surveillance, and Reconnaissance (ISR) operations. This includes the efficient processing of raw ISR data, its subsequent analysis to extract actionable intelligence, and the timely dissemination of this intelligence to relevant stakeholders. This mission aims to enhance situational awareness, operational effectiveness, and decision-making capabilities across various platforms and environments.

2.8,4.1.1 Processing: Perform and support the ingestion and initial processing of ISR data, which includes data normalization, decryption, and formatting to ensure compatibility with analytical tools and systems. Processing must adhere to established standards and protocols to ensure data integrity and readiness for exploitation.

2.8.4.1.2 Exploitation: Conduct detailed analysis of processed ISR data to identify, assess, and interpret relevant information. This includes leveraging advanced analytical techniques and tools to derive actionable intelligence. Analysts are expected to produce high-quality intelligence products, including situational reports, threat assessments, and operational recommendations.

2.8.4.1.3 Dissemination: Manage and support the dissemination of intelligence products to appropriate end-users in a timely manner. This involves the preparation and distribution of intelligence reports, briefings, and other relevant documents through secure channels. The contractor must ensure that dissemination processes comply with all relevant security protocols and ensure that information reaches stakeholders promptly and efficiently.

2.8.4.2 Using SCRUM methodologies conduct a comprehensive evaluation and analysis of the Research, Development and Acquisition (RDA) capabilities, processes, facilities, entities, and ecosystems of foreign states and non-state actors. This analysis will include identifying the networks of individuals, organizations, facilities, and resources required to support the research, development, testing, manufacturing, acquisition, distribution, and sustainment of these adversary systems and capabilities. Additionally, the contractor will identify key foreign decision-makers and decision-making bodies, as well as their funding programs and sources. As part of this analysis develop architectures and systems to counter adversary capabilities. Provide engineering and technical all source analysis and data support focusing on adversary supply chains/ecosystems that unlay their research, development, test, acquisition, and sustainment capabilities/processes. Work performed will include evaluating and integrating data from classified and unclassified sources; performing technical analysis; developing assessments and evaluations; and providing reports.

2.8.5 Deliver all created documentation and any software or hardware developed, enhanced, assembled or acquired in accordance with the following:

· Presentation Material - CDSSA Briefings to CDTAB (classified reports) for Cross Domain systems (See CDRLs, A005, B005, C005, D005, E005, F005, G005, H005, J005 and K005)

· Meeting Minutes for Design Reviews, Technical Exchanges, and other meetings attended. (See CDRLs, A006, B006, C006, D006, E006, F006, G006, H006, J006 and K006)

· Trip Reports (See CDRLs, A007, B007, C007, D007)

· Risk Assessment Reports for the CA on the risk to the operational environment by fielding the system under evaluation (See CDRLs, A009, B009, C009, D009, E009, F009, G009, H009, J009 and K009)

· E/APL Certification Memos (See CDRLs, A015, B015, C015, D015, E015, F015, G015, H015, J015 and K015)

· Security/Design/Test Readiness Report (See CDRLs, A016, B016, C016, D016, E015, F016, G016, H016, J016 and K016)

· Security Design Review Reports for Cross Domain systems

· Test Readiness Review Reports for Cross Domain systems

· CDSSA Test Procedures for Cross Domain systems (See CDRLs, A017, B017, C017, D017, E017, F017, G017, H017, J017 and K017)

· CDSSA Test Reports for Cross Domain systems (See CDRLs, A018, B018, C018, D018, E018, F018, G018, H018, J018 and K018)

· Technical Risk Rating Reports (classified reports) for Cross Domain systems (See CDRLs, A019, B019, C019, D019, E019, F019, G019, H019, J019 and K019)

· Policy Bypass Reports (classified reports) for Cross Domain systems (See CDRLs, A020, B020, C020, D020, E020, F020, G020, H020, J020 and K020)

· Site Preparation Requirements and Implementation Plan (SPRIP) (See CDRLs, A021, B021, C021, D021, E021, F021, G021, H021, J021 and K021)

· Source and object (executable) Code (See CDRLs, A022, B022, C022, D022, E022, F022, G022, H022, J022 and K022)

· Complete software documentation (See CDRLs, A023, B023, C023, D023, E023, F023, G023, H023, J023 and K023)

· Acquired commercial off-the-shelf hardware and software (See CDRLs, A024, B024, C024, D024, E024, F024, G024, H024, J024 and K024)

2.9Program Management
2.9.1Develop, update and maintain Program Management Plans. Identify specific schedule requirements for production of other deliverables under this order for Government approval.
2.9.2Continually determine the status of the effort and report progress toward accomplishment of Order requirements.
2.9.3Continually determine the status of funding required for Order performance.
2.9.4Provide engineering analysis services throughout the AFRL/RIEB SE Lifecycle Process Vee.
2.9.5Conduct oral presentations at such times and places designated in the Order schedule or by the COR. Provide status of technical progress made to date in performance of the order during presentations.
2.9.6Provide data management services including: filing, maintaining equipment, software, license and library databases; hardware and software market research.
2.9.7Attend working group and user group meetings, test planning meetings, technical information exchanges, conferences, test activities, and other meetings supporting program activities. Participate in appropriate technical reviews and interchange sessions (i.e., System Requirements and Specifications reviews, User Groups, Program/Project Status Reviews, community conferences).
2.9.8Maintain and update existing program Virtual Test Folders (VTF) to provide a repository for all tests and evaluations conducted as part of contractor testing.
2.9.9Update existing Government documentation in the form of revisions. Format and content of changes shall not deviate from that of the existing documentation.
2.9.10Maintain a complete set of the Government documentation, including: standards, manuals, regulations, plans, concepts of operation, system/segment specifications and models, and technical interchange and review meeting minutes.
2.9.11Document all technical work accomplished and information gained during performance of this acquisition. Include all pertinent observations, nature of problems, positive and negative results, and design criteria established where applicable. Document procedures followed, processes developed, “Lessons Learned”, etc. Document the details of all technical work to permit full understanding of the techniques and procedures used in evolving technology or processes developed. Cross-reference separate design, engineering, or process specifications delivered to permit a full understanding of the total acquisition.

2.9.12 This effort will require TS/SCI cleared Intelligence Analysts and Data Scientists experienced with NASIC.

analytical standards and environment with a background in adversary supply chains.

2.9.13 Create and deliver the following documentation:

· Contractor Progress, Status and Management Report (See CDRLs A001, B001, C001, D001, E001, F001, G001, H001, J001 and K001)

· Contract Funds Status Report (See CDRLs, A002, B002, C002, D002, E002, F002, G002, H002, J002 and K002)

· Funds and Man-Hour Expenditure Report (See CDRLs, A003, B003, C003, D003, E003, F003, G003, H003, J003 and K003)

· Program Management Plan (See CDRLs, A004, B004, C004, D004, E004, F004, G004, H004, J004 and K004)

· Presentation Materials (See CDRLs, A005, B005, C005, D005, E005, F005, G005, H005, J005 and K005)

· Meeting Minutes (See CDRLs, A006, B006, C006, D006, E006, F006, G006, H006, J006 and K006)

· Trip Reports (See CDRLs, A007, B007, C007, D007, E007, F007, G007, H007, J007 and K007)

· Revisions to Existing Government Documents (See CDRLs, A008, B008, C008, D008, E008, F008, G008, H008, J008 and K008)

· Integration Requirements and Evaluation Procedures

· Virtual Test Folder

· System Architecture

· System Test Plan (See CDRLs, A011, B011, C011, D011, E011, F011, G011, H011, J011 and K011)

· System Test Procedures (See CDRLs, A012, B012, C012, D012,E012, F012, G012, H012, J012 and K012 )

2.9.14Perform Paragraphs 2.0 through 2.9 for Research Development Test & Evaluation funded activities.
2.9.15Perform Paragraphs 2.0 and 2.6 through 2.9 for Procurement funded activities.
2.9.16Perform Paragraphs 2.0 through 2.9 for the O&M funded activities.
3.0SERVICES SUMMARY (SS). The order service requirements are summarized in performance objectives. The performance threshold briefly describes the minimally acceptable levels of service required for each requirement. The SS and the Contractor’s Quality Control Plan provide information on order requirements, the expected level of Contractor performance, and the expected method of Government validation and confirmation of services provided. These thresholds are critical to mission success. Procedures as set forth in the contract Inspection/Acceptance clause will be used to remedy all deficiencies.
Identifier
Performance Objective
PWS Para
Performance Threshold
Remedy
Method of Assessment
SS1
Accurately and efficiently perform the functional requirements during the following phases:

-Requirement Development

-Logical Analysis

-Design Solution

-Implementation

-Integration

-Verification

-Validation

-Transition

2.1

2.2

2.3

2.4

2.5

2.6

2.7

2.8 Exceptional = 0 deficiencies.

Very Good = 1-2 deficiencies.

Satisfactory = 3 functionally unrelated deficiencies.

Marginal = 3 or more functionally related deficiencies or 4 or more functionally unrelated deficiencies. Corrective action acceptable to the COR is planned or underway.

Unsatisfactory = 3 or more functionally related deficiencies or 4 or more functionally unrelated deficiencies. No corrective action acceptable to the COR is planned or underway.

Reperformance within COR specified timeline
Periodic Inspection and Customer Complaints
SS2
Quality documentation is delivered in a timely manner.
2.0 - 2.9
Rating (R) will be calculated as follows:

R = Tr x Cr

RRange
Exceptional16 points
Very Good8 - 12 points
Satisfactory4 - 6 points
Marginal0.25 - 2 points
Unsatisfactory0 points
PointsTime (Tr)
4no more than 1
deliverable is no
more than 2 working
days late.
32 deliverables are no
more than 2 working
days late.
23 deliverables are no
more than 2 working
days late.
0.54 deliverables are no
more than 2 working
days late.
0anything other than
above.

Points Content (Cr)

4all deliverables
require no more than
minimal rework.
3most deliverables
require no more than
minimal rework, but
1 deliverable requires
major rework.
2most deliverables
require no more than
minimal rework, but
2 deliverables require
major rework.
0.5most deliverables
require no more than
minimal rework, but
3 deliverables require
major rework.
0anything other than
above.
Reperformance within COR specified timeline
Periodic Inspection and Customer Complaints
SS3
Ensure compliance with security requirements
DD 254 and 4.2
Satisfactory = 0 deficiencies

Unsatisfactory = 1 or more deficiencies

Reperformance within COR specified timeline
Periodic Inspection and Customer Complaints
3.1Quality Control. The Contractor shall develop and maintain a Quality Control program to ensure services are performed in accordance with commonly accepted practices and quality of service. The Contractor shall develop and implement procedures to identify and prevent performance deficiencies. As a minimum, the Contractor shall develop quality control procedures addressing the areas identified in the Services Summary.
3.2Quality Assurance. The Government will evaluate the Contractor's performance through periodic surveillance and customer feedback, as well as review of the Contractor’s application of its Quality Control program. The Government may inspect each task as completed or increase/decrease the number of inspections as appropriate. The Contractor shall initially validate customer feedback. The Government will make final determination of the validity of customer feedback in cases of disagreement or conflict.
3.3Performance Deficiency. The Government will evaluate the Contractor’s performance to ensure services meet order requirements. When a performance threshold has not been met or Contractor performance has not been accomplished, the COR will consider such an event as a performance deficiency and provide the Contracting Officer (CO) a Corrective Action Report (CAR) or similar documentation. The COR and CO will objectively evaluate observed deficiencies and, if validated, notify the Contractor. The Contractor shall respond to the CO in accordance with instructions provided and within 10 calendar days of receipt. Responses from the Contractor will be considered prior to the final decision made by the CO.

3.4 Methods of Assessment. The COR will inspect the Contractor’s performance of contract requirements using a combination of (1) periodic inspection and (2) customer complaints.

3.4.1 Periodic Inspection. These items are inspected using periodic surveillance (daily, weekly, monthly, quarterly, etc.) as determined by the COR. The results of the periodic surveillance inspections may be used as the basis for actions (other than payment deductions) toward the contractor. In such cases, the Inspection of Services clause becomes the basis for the CO’s actions. The schedules (if requested) are submitted to the CA for review prior to the period being inspected. All inspections will be documented accordingly.

3.4.2 Customer Complaints. The COR is the point of contact and must collect all customer complaints. The AF Form 714, Customer Complaint Record, or a similar locally devised form may be used for this purpose. All complaints and any resulting resolution of such complaints must be documented with the information required on the customer complaint form. Customer complaint forms become a permanent part of the COR surveillance records. The COR will contact each customer involved with this order periodically to assure there is an understanding of the requirement by all appropriate personnel.

4.0GENERAL INFORMATION
4.1Contractor Employees. The following DoD approved 8570.01 certifications for technical staff members are required at the beginning of task order performance and must be maintained throughout the period of performance by the Contractor employees: Comp TIA Security + Certification, Microsoft Certified Technology Specialist (MCTS), Certified Ethical Hackers (CEH), and Certified Information Systems Security Professional (CISSP). In addition, the technical Contractor employees shall possess a mix of advanced degrees (Bachelors and Masters) in Information Assurance, Computer Science, Information Technology, and Information Systems, or equivalent. The Contractor Task Order Project Manager (PM) shall be a Program Management Professional (PMP) or Defense Acquisition University (DAU) Level III certified in Engineering, Science and Technology Management (STM), or Program Management.
4.1.1The Contractor shall not employ persons for work on this task order identified by the CO as a potential threat to the health, safety, security, general well-being, or operational mission of the installation and its population.
4.1.2The Contractor will not employ any person who is an employee of the United States Government if the employment of that person would create a conflict of interest, or an appearance of a conflict of interest. When employing off-duty Air Force military personnel, the Contractor shall comply with AFI 64-106, Paragraph 3. In the event it becomes necessary to replace any order personnel, the Contractor shall not be reimbursed for costs associated with such removal including the costs for replacement of any personnel so removed.
4.1.3The Contractor is prohibited from employing off-duty Government personnel who are responsible for surveillance of any contracts/subcontracts awarded to the Contractor.
4.1.4The Contractor shall inform the CO in writing within five (5) working days of any incidents of misconduct by their employees that violate laws of the US. Incidents that may lead to problems between Rome Research Site and local Government officials must also be reported within five (5) workdays.
4.1.5The Contractor shall be responsible for obtaining any necessary licenses and permits to comply with any applicable U.S., state, and local laws, codes, and regulations. Ensure that employees have current and valid professional certifications before starting work as required.
4.1.6Contractor employees involved in the performance of this task order must complete, and provide to the COR, the Non-Disclosure Agreement (Appendix 1).
4.1.7The Contractor shall provide personnel who are qualified at the beginning of their work under this task order and who meet the minimum criteria for their respective labor categories, as those categories are defined in the underlying contract vehicle used to establish this task order.
4.1.8Vacancies. The Contractor shall fill positions with qualified personnel to ensure all performance objectives are fulfilled without performance degradation. If a change of personnel occurs, the Contractor must ensure a replacement is hired and in place, with complete Common Access Card access and clearance (prior to the departure of the incumbent unless impossible). If a vacancy is anticipated to exceed 30 calendar days, the Contractor shall provide a written plan acceptable to the COR and CO describing how the vacancy will be filled or otherwise resolved.
4.1.9TRAINING. The Contractor shall ensure all employees provided under this task order are current in all training required to fulfill the requirements of this work statement.
4.1.9.1Maintain an individual training record for each employee that includes a listing of all order specific training provided to the employee. Provide to the Government for inspection when requested.
4.1.9.2Ensure all personnel attend/accomplish any required Government-provided training (e.g. RRS Home Page Required Reading and Training page).

This is the start of the file's text. The full file is on GovTribe.

File details come from the government source that posted it. Updated .