N241-038 TITLE: Runtime Software Verification for Non-Standard Compute Infrastructure

OUSD (R&E) CRITICAL TECHNOLOGY AREA(S): Integrated Sensing and Cyber

The technology within this topic is restricted under the International Traffic in Arms Regulation (ITAR), 22 CFR Parts 120-130, which controls the export and import of defense-related material and services, including export of sensitive technical data, or the Export Administration Regulation (EAR), 15 CFR Parts 730-774, which controls dual use items. Offerors must disclose any proposed use of foreign nationals (FNs), their country(ies) of origin, the type of visa or work permit possessed, and the statement of work (SOW) tasks intended for accomplishment by the FN(s) in accordance with the Announcement. Offerors are advised foreign nationals proposed to perform on this topic may be restricted due to the technical data under US Export Control Laws.

OBJECTIVE: Develop an automated software runtime verification capability that reveals errors or conditions for combat management systems running on US Navy ship computer hardware.

DESCRIPTION: Current US Naval platform combat management systems are a system-of-systems, operating as a complex collection of computers, controllers, sensors, communications networks, rack-mounted servers and hardware, and other systems required to accomplish the ship’s objectives. These components communicate and interact over local area networks. Safeguards must be taken to identify unexpected errors before they result in potentially catastrophic system failure modes, improving the resilience and reliability of platforms and the safety of embarked personnel. Currently there are no commercial solutions known that apply to the Navy’s need. The Navy seeks an automated software solution, using current development and engineering approaches, that updates both software and computing infrastructure (CI) hardware on faster timescales than current refreshes and overhauls.

Improved methods to identify unexpected but potentially catastrophic failure modes while new software is running on new CI would significantly improve the resilience and reliability of the Navy’s future combat management systems. Three Ship Self-Defense System (SSDS) Top Level Requirements (TLRs) would be supported by this investigation. The TLRs will be provided by the government to awardee.

These requirements are:

• The SSDS Combat System (CS) shall have the ability to automatically discover, identify, and record security relevant information such as hardware and software attributes [SSDS_CS_TLR-1065];

• The SSDS CS shall periodically validate the integrity of persistent operating system and application software files against a known-good baseline, and log and notify the operator for further analysis [SSDS_CS_TLR-1071]; and

• The SSDS CS shall support modular, extensible, rapid, and transparent introduction and integration of new and updated cybersecurity capabilities to the CS elements [SSDS_CS_TLR- 2162].

The solution must monitor and detect early indicators and warnings (I&W) of combat system software component errors or failures through the application of runtime verification or dynamic software analysis techniques. Critically, this approach must be able to detect these conditions in combinations of software and CI that cannot be anticipated and tested prior to release (i.e., as both hardware and software are upgraded across the lifetime of the ship). An approach should be used that supports displaying detected findings relevant for embarked personnel. It should provide personnel an understanding of the nature of the identified I&W so actionable steps can be taken before catastrophic system failure occurs. Runtime error types relevant to combat management systems include memory leaks and memory management errors, system process concurrency errors, race conditions, livelocks, deadlocks, and unexpected system process executions. Furthermore, while relevant errors can address potential cybersecurity vulnerabilities, solutions are desired that address the above types of runtime errors. Note that potential solutions should be distinct from software verification techniques that can be used during the software engineering process (e.g., static code analysis, fuzzing, testing, and others). Potential solutions should be suitable for the SSDS but also support extensibility to other combat management systems [Ref 1]. Finally, solutions must be flexible enough to support prototype construction and integration into US Navy consoles and display system approaches, as well as perform these tasks agnostic of specific combinations of software and CI hardware.

Work produced in Phase II may become classified. Note: The prospective contractor(s) must be U.S. owned and operated with no foreign influence as defined by 32 U.S.C. § 2004.20 et seq., National Industrial Security Program Executive Agent and Operating Manual, unless acceptable mitigating procedures can and have been implemented and approved by the Defense Counterintelligence and Security Agency (DCSA) formerly Defense Security Service (DSS). The selected contractor must be able to acquire and maintain a secret level facility and Personnel Security Clearances. This will allow contractor personnel to perform on advanced phases of this project as set forth by DCSA and NAVSEA in order to gain access to classified information pertaining to the national defense of the United States and its allies; this will be an inherent requirement. The selected company will be required to safeguard classified material during the advanced phases of this contract IAW the National Industrial Security Program Operating Manual (NISPOM), which can be found at Title 32, Part 2004.20 of the Code of Federal Regulations. Reference: National Industrial Security Program Executive Agent and Operating Manual (NISP), 32 U.S.C. § 2004.20 et seq. (1993). https://www.ecfr.gov/current/title-32/subtitle-B/chapter-XX/part-2004

PHASE I: Develop a concept for performing automated runtime verification of combat management system (CMS) software components. The concept must demonstrate feasibility to detect early indications and warnings (I&W) of potential error modes, as well as an approach to display those errors for relevant embarked personnel according to the parameters of the Description. Demonstrate feasibility through modeling, simulation, analysis, or other formal methods. The Phase I Option, if exercised, will include the initial design specifications and capabilities description to build a prototype solution in Phase II.

PHASE II: Develop and deliver a prototype automated runtime verification solution capable of meeting realistic operational requirements for the SSDS based on the results of Phase I. Demonstrate at a Government- or company-provided facility that the prototype meets all parameters detailed in the Description. The government will provide a reference combat management system architecture example and additional information for demonstration development. The technology will be assessed over the course of Phase II by Navy subject matter experts.

It is probable that the work under this effort will be classified under Phase II (see the Description section for details).

PHASE III DUAL USE APPLICATIONS: Support the Navy in transitioning the technology to Navy use. The final product will use system integration and qualification testing. This prototype will be delivered to support the Navy through a critical experiment conducted jointly by the company and the combat system engineering agent (CSEA). This is expected to take place in a live environment with tactical SSDS CMS software. Integrate the prototype into the SSDS CMS.

Dual use applications to consider include extension of these technologies and capabilities to any safety-critical system monitoring use cases, including but not limited to: industrial control systems; manufacturing systems; electrical grid or other resource distribution systems; transportation and logistics systems; and others.

REFERENCES:

1. Bath, W. G. "Overview of Platforms and Combat Systems." Johns Hopkins APL Technical Digest, Volume 35, Number 2, 2020. https://www.jhuapl.edu/Content/techdigest/pdf/V35-N02/35-02-Bath.pdf
2. Sanchez, C., et al. "A Survey of Challenges for Runtime Verification from Advanced Application Domains (Beyond Software)." Formal Methods in System Design, Volume 54, 2019. https://doi.org/10.1007/s10703-019-00337-w
3. Stockmann, L.; Laux, S. and Bodden, E. "Architectural Runtime Verification." 2019 IEEE International Conference on Software Architecture Companion (ICSA-C). https://doi.org/10.1109/ICSA-C.2019.00021

KEYWORDS: Runtime verification; software verification; dynamic software analysis; formal methods; system failure modes; combat management systems

---