Search NASA⌕ Search

Engineering topics

Simon, Tori Brooke

Publications and source records attributed to Simon, Tori Brooke.

Software Bill of Materials in the Nuclear Industry

Nuclear power plants (NPP) have thousands of digital assets throughout their facility. Typically, NPPs have asset and configuration management programs that capture the make, model, and version of a component. This information, however, usually only includes first- or second-tier components and does not capture the complete enumeration of software components and their dependencies within operational technology (OT) equipment. As seen with recent cyberattacks, this level of detail is insufficient for identifying if and where an exploitable vulnerability exists within a facility. A software bill of materials (SBOM) provides this detailed enumeration. Further, integrating SBOMs with vulnerability data sources and vulnerability attestation reports can provide improved awareness leading to better cyber risk management and incident response. Preferably, SBOMs are provided by the supplier; however, when an NPP already owns a device, it is less likely they will have a supplier provided-SBOM. Fortunately, SBOMs can be generated on installed digital assets. This paper provides an introduction to the U.S. Department of Energy Office of Nuclear Energy paper titled “Towards Software Bill of Materials in the Nuclear Industry,” which describes the SBOM ecosystem and provides a suggested approach to methodically and seamlessly integrate an SBOM program in an NPP.

98 NUCLEAR DISARMAMENT, SAFEGUARDS, AND PHYSICAL P↗

Towards Software Bill of Materials in the Nuclear Industry

Large, modern industrial facilities often incorporate thousands of digital assets in their operational technology. Regulated facilities, such as nuclear power plants (NPPs), maintain robust cybersecurity and configuration management programs that often use bills of materials (BOMs) for these assets, including make, model, and version of hardware, firmware, and software. However, these BOMs typically capture only first- or second-tier information provided by the original equipment manufacturer (OEM). Unfortunately, as indicated by the increasing number and sophistication of software supply chain attacks, this level of detail is insufficient for identifying all the potential vulnerabilities and risks in software applications. Software BOMs (SBOMs) provide detailed enumeration of components and dependencies within the product or devices, including firmware. SBOMs can be combined with vulnerability data sources and vendor vulnerability attestations to improve vulnerability management and enable rapid identification of affected components when new software vulnerabilities are discovered. Ideally, SBOMs are created by the OEM prior to installation. However, since this practice is not yet commonplace and since NPPs are typically slow to adopt new technology, most NPPs do not incorporate SBOMs into their asset or configuration management programs. Fortunately, SBOMs can be generated by NPPs on existing digital assets to provide further insight into risk management decisions. This report provides an overview of the current SBOM ecosystem and recommends guidance on how to get started in a “crawl, walk, run” manner to develop and implement a sustainable SBOM program for digital assets in an NPP.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

Autonomous System Subversion Tactics: Prototypes and Recommended Countermeasures

One of the fielding requirements for Advanced and Small Modular Reactors (AR/SMR) is the ability to support remote and autonomous operations. Autonomous Control Systems (ACS) are found on platforms such as Autonomous Space Vehicles, Cruise Missiles, and advanced driver-assistance systems. Each of these ACS implementations depends upon a set of decision support subsystems responsible for supporting Autonomous Mission Managers (names vary based upon field and author preferences). These Autonomous Mission Managers receive inputs from system sensors (e.g., LIDAR collection from an automobile travelling down a street; transients from a nuclear reactor), and perform a set of classifications (e.g., Red Traffic Light; Small Pedestrian at 10m; Load Rejection; Single Coolant Pump Trip), and then use these classifications in combination with recommendation algorithms to achieve platform goals (e.g., Stop the Vehicle at the Traffic Light, Avoid the Small Pedestrian; Trip the Reactor to prevent a Safety Event). The design, implementation, and fielding of an ACS capability will alter the cyber-attack surface such that existing risk management plans will need to be updated to include how to protect and defend against data-science and decision-support-system attack classes. These attack classes would include protection of the design and training environments where algorithm selection and testing and training data would be obvious attack vectors. These attack classes would also require an informed set of detection and response procedures to identify anomalous behaviors and document best practices for anomaly assessment and vulnerability mitigation and remediation. Last year we published a Cyber Threat Assessment Methodology for Autonomous and Remote Operations for AR/SMRs along with a companion publication on Cyber Attack and Defense Use Cases. The focus of the methodology was on describing and enumerating ACS processes, components, and functions such that security engineers could: evaluate subversion options against the target; identify threat actor attributes and capabilities derived from each subversion option; and identify security controls and response countermeasures. The Use Cases document offered detailed methodology examples including an assessment of a Military Base SMR, an Autonomous System Decision Loop, and implementation of AR/SMR Machine Learning algorithms. Our proposal at the end of last year was to focus on implementation of subversion prototypes related to the last Use Case area: AR/SMR Machine Learning (ML) Algorithms. We included six attack scenarios in our Use Cases paper: a Poisoning Attack against ML functions implemented using an FPGA; a Trojaning Attack against ML classifiers exploiting the excitability of Nuclear Engineers; a Backdooring Attack against ML Training environments to ensure persistence of an attack vector; a False Positive Evasion Attack against multi-factor Access Control Systems using clever inputs; an Inference Attack against ML models by an Insider with access to the Operational environment; and an Adversarial Reprogramming Attack against a Material Access Control Video Surveillance System. At the beginning of this year these six attack scenarios were provided to our research teams at Georgia Tech and Idaho State University and each team successfully implemented a subversion attack against a ML implementation to include transient misclassifications. While this is a notable outcome from this type of research, this paper offers the reader insight into not only how to structure and execute these types of attacks, but into the thought process behind how the researcher investigated the problem space, performed initial algorithm implementation, and the trial-and-error behind arriving at the successful subversion prototypes. We include in this paper a set of associated Scenarios on how these subversion prototypes could be implemented and an initial set of guidance for AR/SMR architects, Nuclear Regulators, and Cyber Defenders to implement awareness and defense capabilities into their current operational portfolios.

42 ENGINEERING↗