Systems and methods for dynamic probabilistic risk assessment simulation environments

Abstract

An example method for performing probabilistic risk assessment includes generating a dynamic probabilistic risk assessment corresponding to a system model; and modelling actions in the system model using an action model. An example system for performing probabilistic risk assessment includes a system model comprising a model of a physical system; a dynamic probabilistic risk assessment (DPRA) engine; and an action model.

Description

Docket Number:  103361‐518WO1  SYSTEMS AND METHODS FOR DYNAMIC PROBABILISTIC RISK ASSESSMENT SIMULATION  ENVIRONMENTS    CROSS‐REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. provisional patent application No.  63 / 511,343 filed on June 30, 2023, and titled “SYSTEMS AND METHODS FOR DYNAMIC  PROBABILISTIC RISK ASSESSMENT SIMULATION ENVIRONMENTS,” the disclosure of which is  expressly incorporated herein by reference in its entirety.    STATEMENT REGARDING FEDERALLY FUNDED RESEARCH

[0002] This invention was made with government support under DE‐NE0008986  awarded by the Department of Energy. The government has certain rights in the invention.    BACKGROUND

[0003] Risk assessment involves determining the likelihood of events and the  relationships of those events to dangerous scenarios. A common definition of risk is the  likelihood of an event multiplied by the expected harm caused by the event. Events can include  human errors, malicious actions (e.g., cyberattacks) and mechanical failures. Dangerous  scenarios can be the result of evolution of an individual event or the interaction of one or more  events that can result in scenarios that would not be caused by individual events alone.  Moreover, dangerous scenarios can be caused by the interaction of multiple seemingly benign  events interacting in a complex system. Improved systems and methods for predicting risk in  complex systems can be used to improve the design, control, and operation of those systems.    Docket Number:  103361‐518WO1  SUMMARY

[0004] In some aspects, implementations of the present disclosure include a method  for performing dynamic probabilistic risk assessment, the method including: providing a system  model of a physical system; providing an action model configured to generate a set of operator  and attacker actions based on a game theory analysis; and providing a dynamic probabilistic risk  assessment (DPRA) engine, wherein the DPRA engine is configured to: receive the set of  operator and attacker actions from the action model; sample the set of operator and attacker  actions; and provide the sampled set of operator and attacker actions to the system model for  implementation by the system model.

[0005] In some aspects, implementations of the present disclosure include a method,  wherein the set of operator and attacker actions is randomly sampled.

[0006] In some aspects, implementations of the present disclosure include a method,  wherein the DPRA engine is further configured to receive a state of the physical system from  the system model, and provide the state of the physical system to the action model.

[0007] In some aspects, implementations of the present disclosure include a method,  wherein the system model includes a network model.

[0008] In some aspects, implementations of the present disclosure include a method,  wherein the DPRA engine is further configured to receive a state of the network model from  the system model, and provide the state of the network model to the action model.

[0009] In some aspects, implementations of the present disclosure include a method,  wherein the action model includes a plurality of sub‐models. Docket Number:  103361‐518WO1

[0010] In some aspects, implementations of the present disclosure include a method,  wherein the plurality of sub‐models include a procedure model, an undetected attacker model,  and a game model.

[0011] In some aspects, implementations of the present disclosure include a method,  wherein the DPRA engine is configured to implement an attacker action on the system model.

[0012] In some aspects, implementations of the present disclosure include a method,  wherein the DPRA engine is configured to implement an operator action on the system model.

[0013] In some aspects, implementations of the present disclosure include a method,  wherein the action model is configured to generate a plurality of actions for an operator to  implement on the physical system.

[0014] In some aspects, implementations of the present disclosure include a method,  wherein the action model is configured to generate a plurality of actions for an attacker to  implement on the physical system.

[0015] In some aspects, implementations of the present disclosure include a method,  wherein the action model is configured to generate both a plurality of actions for an attacker  and a plurality of actions for an operator to implement on the physical system.

[0016] In some aspects, implementations of the present disclosure include a method,  further including determining a risk metric based on the actions in the system, wherein the risk  metric is based on the action model and the system model.

[0017] In some aspects, implementations of the present disclosure include a method,  further including modeling a plurality of actions for an attacker and a plurality of actions for a  defender based on a game theory analysis of the attacker and defender's actions. Docket Number:  103361‐518WO1

[0018] In some aspects, implementations of the present disclosure include a method  for performing dynamic probabilistic risk assessment, the method including: modelling actions  in a system model using an action model and sampling the actions to be implemented on the  system model by a DPRA engine from the actions modeled by the action model; and  implementing the sampled actions on the system model.

[0019] In some aspects, implementations of the present disclosure include a method,  further including determining a risk metric based on the actions in the system.

[0020] In some aspects, implementations of the present disclosure include a system  including: a network device; a controller operably coupled to the network device, the controller  including a processor and a memory, the memory having computer‐executable instructions  stored thereon that, when executed by the processor, cause the controller to: model action in a  system model using an action model and sample the actions to be implemented on the system  model by a DPRA engine from the actions modeled by the action model; and implement the  sampled actions on the system model.

[0021] In some aspects, implementations of the present disclosure include a system,  wherein the network device is coupled to a network including a functional node.

[0022] In some aspects, implementations of the present disclosure include a system,  wherein the functional node includes at least one of a controller or sensor.

[0023] In some aspects, implementations of the present disclosure include a system,  wherein the controller is further configured to control the network device based on the  sampled actions implemented on the system model. Docket Number:  103361‐518WO1

[0024] Other systems, methods, features and / or advantages will be or may become  apparent to one with skill in the art upon examination of the following drawings and detailed  description. It is intended that all such additional systems, methods, features and / or  advantages be included within this description and be protected by the accompanying claims.    BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The components in the drawings are not necessarily to scale relative to each  other. Like reference numerals designate corresponding parts throughout the several views.

[0026] FIG. 1A illustrates a simulation environment for performing dynamic  probabilistic risk assessment, according to implementations of the present disclosure.

[0027] FIG. 1B illustrates a system for improving the cybersecurity of a network,  according to implementations of the present disclosure.

[0028] FIG. 2 is a flow chart illustrating a method for performing dynamic  probabilistic risk assessment, according to implementations of the present disclosure.

[0029] FIG. 3 illustrates an example system model, according to implementations of  the present disclosure.

[0030] FIG. 4 illustrates an example dynamic probabilistic risk assessment engine  according to implementations of the present disclosure.

[0031] FIG. 5 illustrates an example action model, according to implementations of  the present disclosure.

[0032] FIG. 6 illustrates an example game model, according to implementations of  the present disclosure. Docket Number:  103361‐518WO1

[0033] FIG. 7 illustrates an example computing device.

[0034] FIG. 8 illustrates an example implementation of the present disclosure  including a model the strategic interactions between attackers / defenders in a system including  physical and digital components.

[0035] FIG. 9 illustrates a model of attacker and defender actions in a system  including digital components, mechanical components, and physical modeling, according to  implementations of the present disclosure.

[0036] FIG. 10 illustrates an example diagram of a controller, digital flow sensor, and  mechanical valve with example discrete states, according to implementations of the present  disclosure.

[0037] FIG. 11 illustrates an example trajectory in physics space, according to  implementations of the present disclosure.

[0038] FIG. 12 illustrates an example model of a trajectory, according to  implementations of the present disclosure.

[0039] FIG. 13 illustrates an example game theory model, according to  implementations of the present disclosure.

[0040] FIG. 14 illustrates an example reactor used in a case study according to  implementations of the present disclosure.

[0041] FIG. 15 illustrates an example simulation of the reactor shown in FIG. 14,  according to implementations of the present disclosure.

[0042] FIG. 16 illustrates example states of components used in the case study shown  in FIGS. 14 and 15.  Docket Number:  103361‐518WO1

[0043] FIG. 17A illustrates a simulation result of narrow water range levels for steam  generator 1, according to implementations of the present disclosure.

[0044] FIG. 17B illustrates a simulation result of narrow water range levels for steam  generator 2, according to implementations of the present disclosure.

[0045] FIG. 17C illustrates a simulation result of narrow water range levels for steam  generator 3, according to implementations of the present disclosure.

[0046] FIG. 18 illustrates a simulator that can be used to evaluate network  architectures and cybersecurity risks, according to implementations of the present disclosure.

[0047] FIG. 19 illustrates co‐simulation of network models and physics models,  according to implementations of the present disclosure.

[0048] FIG. 20 illustrates node‐management and scheduling model that can be used  in the simulator shown in FIG. 18, according to implementations of the present disclosure.

[0049] FIG. 21 illustrates a plot of game‐theory trajectories for attacker and defender  action pairs, according to implementations of the present disclosure.

[0050] FIG. 22 illustrates a timing diagram illustrating parallel operation of a graphical  network simulator, physical simulator, procedure following operator library and game library,  according to implementations of the present disclosure.    DETAILED DESCRIPTION

[0051] Unless defined otherwise, all technical and scientific terms used herein have  the same meaning as commonly understood by one of ordinary skill in the art. Methods and  materials similar or equivalent to those described herein can be used in the practice or testing Docket Number:  103361‐518WO1  of the present disclosure. As used in the specification, and in the appended claims, the singular  forms “a,” “an,” “the” include plural referents unless the context clearly dictates otherwise. The  term “comprising” and variations thereof as used herein is used synonymously with the term  “including” and variations thereof and are open, non‐limiting terms. The terms “optional” or  “optionally” used herein mean that the subsequently described feature, event or circumstance  may or may not occur, and that the description includes instances where said feature, event or  circumstance occurs and instances where it does not. Ranges may be expressed herein as from  "about" one particular value, and / or to "about" another particular value. When such a range is  expressed, an aspect includes from the one particular value and / or to the other particular  value. Similarly, when values are expressed as approximations, by use of the antecedent  "about," it will be understood that the particular value forms another aspect. It will be further  understood that the endpoints of each of the ranges are significant both in relation to the other  endpoint, and independently of the other endpoint. While implementations will be described  for resolving ambiguities in text, it will become evident to those skilled in the art that the  implementations are not limited thereto, but are applicable for generative artificial intelligence  systems and methods.

[0052] As used herein, the terms "about" or "approximately" when referring to a  measurable value such as an amount, a percentage, and the like, is meant to encompass  variations of ±20%, ±10%, ±5%, or ±1% from the measurable value.

[0053] The term “artificial intelligence” is defined herein to include any technique  that enables one or more computing devices or comping systems (i.e., a machine) to mimic  human intelligence. Artificial intelligence (AI) includes, but is not limited to, knowledge bases, Docket Number:  103361‐518WO1  machine learning, representation learning, and deep learning. The term “machine learning” is  defined herein to be a subset of AI that enables a machine to acquire knowledge by extracting  patterns from raw data. Machine learning techniques include, but are not limited to, logistic  regression, support vector machines (SVMs), decision trees, Naïve Bayes classifiers, and  artificial neural networks. The term “representation learning” is defined herein to be a subset  of machine learning that enables a machine to automatically discover representations needed  for feature detection, prediction, or classification from raw data. Representation learning  techniques include, but are not limited to, autoencoders. The term “deep learning” is defined  herein to be a subset of machine learning that that enables a machine to automatically discover  representations needed for feature detection, prediction, classification, etc. using layers of  processing. Deep learning techniques include, but are not limited to, artificial neural network or  multilayer perceptron (MLP).

[0054] Machine learning models include supervised, semi‐supervised, and  unsupervised learning models. In a supervised learning model, the model learns a function that  maps an input (also known as feature or features) to an output (also known as target or targets)  during training with a labeled data set (or dataset). In an unsupervised learning model, the  model learns patterns (e.g., structure, distribution, etc.) within an unlabeled data set. In a semi‐ supervised model, the model learns a function that maps an input (also known as feature or  features) to an output (also known as target or target) during training with both labeled and  unlabeled data.

[0055] Deep learning models, including LLMs, may include artificial neural networks.  An artificial neural network (ANN) is a computing system including a plurality of interconnected Docket Number:  103361‐518WO1  neurons (e.g., also referred to as “nodes”). This disclosure contemplates that the nodes can be  implemented using a computing device (e.g., a processing unit and memory as described  herein). The nodes can be arranged in a plurality of layers such as input layer, output layer, and  optionally one or more hidden layers. An ANN having hidden layers can be referred to as deep  neural network or multilayer perceptron (MLP). Each node is connected to one or more other  nodes in the ANN. For example, each layer is made of a plurality of nodes, where each node is  connected to all nodes in the previous layer. The nodes in a given layer are not interconnected  with one another, i.e., the nodes in a given layer function independently of one another. As  used herein, nodes in the input layer receive data from outside of the ANN, nodes in the hidden  layer(s) modify the data between the input and output layers, and nodes in the output layer  provide the results. Each node is configured to receive an input, implement an activation  function (e.g., binary step, linear, sigmoid, tanH, or rectified linear unit (ReLU) function), and  provide an output in accordance with the activation function. Additionally, each node is  associated with a respective weight. ANNs are trained with a dataset to maximize or minimize  an objective function. In some implementations, the objective function is a cost function, which  is a measure of the ANN’s performance (e.g., error such as L1 or L2 loss) during training, and the  training algorithm tunes the node weights and / or bias to minimize the cost function. This  disclosure contemplates that any algorithm that finds the maximum or minimum of the  objective function can be used for training the ANN. Training algorithms for ANNs include, but  are not limited to, backpropagation.

[0056] Industrial facilities can include complex networked controllers, computing  devices, sensors, and actuators, which interact with physical systems to operate the facility. Docket Number:  103361‐518WO1  These complexed networked systems create cyber risks due to the interaction of the digital  systems with the physical systems of the facility, and allow for attackers to cause physical  damage to facilities using cyber attacks.

[0057] For example, the increasing adaptation of nuclear power plants to  incorporate software‐based components along with digital communication networks in their  operation has resulted in improved control, automation, monitoring and diagnostics, while  simultaneously opening those power plants to a new dimension of risk, cyber‐attacks.  Additionally, the attackers have become more knowledgeable about the vulnerabilities  associated with such software systems and network architectures. The complicated physical  and digital systems of industrial facilities pose challenges to existing methods and systems for  evaluating cyber attacks and cyber defenses.

[0058] Implementations of the present disclosure improve systems and methods for  evaluating cyber attacks and defenses, for example by using a dynamic probabilistic risk  assessment (DPRA) framework for nuclear power plants in the context of cyber security. In  addition to stochastic events such as component failures, the framework considers cyber‐ attacks along with defenders' (e.g., the plant operators), and the attackers' behaviors and their  interactions in a game theory‐based framework.

[0059] The example implementation described herein includes improvements to the  simulation of complex systems including nuclear powerplants. The implementations described  herein allow a dynamic probabilistic risk assessment simulation environment that can model  the physical operation of a facility (e.g., the system model) to operate with game‐theory based  frameworks for decision making, to improve computation of risk metrics associated with cyber‐Docket Number:  103361‐518WO1  attacks. Existing frameworks can fail to account for both physical conditions / events and the  strategic interactions between the actions of individuals (e.g., the attackers and the operators  in relation to those systems).

[0060] For example, conventional probabilistic risk assessment (PRA) methods  include fault trees and event trees, which can identify potential failures in a system. But  conventional PRA methods are limited by modeling and incorporating the changes of system  properties as functions of physics and time, for example failure rates of components are  dependent on physical conditions, modeling the changes in the behavior of human operators  with respect to system states and time, for example the operator can be under a significant  amount of stress depending on the state of the system, and capturing the evolution of the  system over time due to events such as random component failures or operator errors.

[0061] The systems and methods described herein (e.g., the dynamic probabilistic  risk assessment methods referred to herein as DPRA) include a set of probabilistic risk  assessment techniques that uses deterministic physics based dynamic models of the system to  study its evolution in the context of random events [8], [9] and can overcome the limitations of  classical PRA and provide more accurate estimates of risk. DPRA systems can include evaluating  initiating events such as failure of hardware components either due to aging or random failures  [8],

[0010] , failure of digital systems

[0011] and human operator errors

[0012] ‐

[0014] into consideration,  for example using continuous event tree approaches, continuous time DPRA methods, and  modeling random events including equipment failures, operator actions, and operator errors.  [8],

[0012] . Docket Number:  103361‐518WO1

[0062] The improvements to cybersecurity systems and methods described herein  can thereby improve physical systems by improving the security of the networks that sense and  control those systems (e.g., the networks of a nuclear power plant or other industrial facility).  For example, the cybersecurity systems and methods described herein include systems and  methods for analyzing the physical system (e.g., a nuclear power plant) that is sensed and / or  controlled by the network, which improves on cybersecurity systems and methods that do not  incorporate the physical system into the analysis and therefore do not consider the risks of  different types of cyberattacks on the physical system.  In other words, the present disclosure  includes cybersecurity analysis including both physical modeling and behavioral modeling (e.g.,  using game theory, that can improve on previous systems which do not combine behavioral  modeling with physical modeling. [7],

[0015] .

[0063] With reference to FIG. 1A, a system 100 for performing dynamic probabilistic  risk assessment (DPRA) is shown according to an implementation of the present disclosure. As  shown in FIG. 1A, the system 100 includes a system model 102. The system model 102 can be a  model of a physical system. As a non‐limiting example, the physical system can be an industrial  facility, for example a nuclear power plant or reactor. The system model 102 can optionally  include mathematical models of how physical parts of the system perform under different  conditions and / or how those physical parts of the system interact with each other. A non‐ limiting example of a nuclear power plant system model 300 is shown in FIG. 3. Alternatively or  additionally, the system model 102 can include a network model that models a network within  the system.  Docket Number:  103361‐518WO1

[0064] Still with reference to FIG. 1A, the system 100 can include a DPRA engine 110.  The DPRA engine 110 can be configured to implement an attacker action on the system model  102.  As an example, an attacker action can include a simulation of a cyber attack by an attacker  on the system model 102. A non‐limiting example of an attacker action includes a cyber attack  on a nuclear facility. FIG. 4 illustrates an example DPRA engine 400 configured for use with the  nuclear power plant system model 300 shown in FIG. 3.

[0065] The DPRA engine can be optionally configured to receive a state of the  network model from the system model, and provide the state of the network model to the  action model. As described in Example 1, herein, the network model can include functional  nodes (e.g., any number or combination of sensors, actuators, computers, and controllers) and  data links that can be used for sensing and / or control (e.g., the monitoring and control of a  nuclear power plant).

[0066] Alternatively or additionally, the DPRA engine 110 can be configured to  implement a defender action on the system model 102. A defender action can represent  actions taken to prevent or mitigate attacker actions. As a non‐limiting example, a defender  action can represent actions taken by an operator of a nuclear power plant to prevent a cyber  attack or respond to a cyber attack. As used herein, the term “operator” can refer to a  “defender,” of a facility, an operator of a facility, or both.

[0067] Alternatively or additionally, the DPRA engine 110 can be configured to  generate a randomly‐generated component failure scenario on the system model 102. The  randomly generated component failure scenario can include simulating the failure of part or all  of the physical system modelled by the system model.  Docket Number:  103361‐518WO1

[0068] Still with reference to FIG. 1A, the system 100 can further include an action  model 120. The action model 120 can include one or more sub‐models (not shown). Non‐ limiting examples of sub‐models include a procedure model, an undetected attacker model,  and a game model. The action model 120 can be configured to generate a plurality of actions  for an operator to implement on the system model 102.  Alternatively or additionally, the  action model can be configured to generate a plurality of actions for an attacker to implement  on the system model 102. As yet another example, the action model 120 can optionally include  a lookahead game model to simulate the attacker anticipating future moves of the defender  and / or the defender anticipating future moves of the attacker.

[0069] A non‐limiting example of an action model 500 is illustrated in FIG. 5. The  action model 500 can be used in conjunction with the nuclear power plant system model 300  shown in FIG. 3 and the example DPRA engine 400 shown in FIG. 4. As shown in FIG. 5, the  example action model 500 can include a game model 502, an undetected attacker model 504,  and a procedure model 506. An example game model 600 is illustrated in FIG. 6 and can be  used as the game model 502 of FIG. 5., according to implementations of the present disclosure.

[0070] It should be understood that the system model 300, action model 500, and  DPRA engine 400 in FIGS. 3‐5 are intended only as non‐limiting examples of systems and  methods that can be used to implement the action model 120, system model 102, and DPRA  engine 110 shown in FIG. 1A.

[0071] In some implementations, the action model 500 can be configured to  generate both a plurality of actions for an attacker and a plurality of actions for a defender. Docket Number:  103361‐518WO1  Optionally, the actions generated for the attacker and / or defender are based on a game theory  analysis of the attacker and defender’s actions.

[0072] It should be understood that in the “attacker,” “defender,” and “operator”  actors described herein can be simulations of people acting in those roles, and / or game‐theory  models of actors (as opposed to human users). Thus, for example, the action model 120 shown  in FIG. 1A, or the action model 500 shown in FIG. 5 can be configured to simulate the behaviors  of human attackers, defenders, and / or operators in different scenarios. As described herein,  the action model 120 can generate sets of actions that an be taken by the human attackers,  defenders, and / or operators that are being simulated. The action model 120 can select among  the sets of action, using game theory methods to determine which actions the attacker,  defender, and / or operator will take and how the actions of the attacker, defender and / or  operators can be related.

[0073] In some implementations, the system 100 can further include a post  processing module 130.  The post processing module 130 can receive information from DPRA  engine 110. The post processing module 130 can be configured to determine a risk metric  based on the information received from the DPRA engine 110. Alternatively or additionally, the  risk metric determined by the post processing module 130 can be based the action model 120  and system model 102.

[0074] With reference to FIG. 1B, implementations of the present disclosure can use  the system 100 described with reference to FIG. 1A to improve the cybersecurity of a network  150 (e.g., a nuclear power plant network). The network 150 can include any number of network  devices 152, functional nodes 154, and data links 156 operatively connecting the network Docket Number:  103361‐518WO1  devices 152 and / or functional nodes 154 together in any combination. The system 100 can  perform the methods described herein (e.g., with reference to FIGS. 1A and 2, and example 1)  to control one or more network devices 152 in the network 150 to improve cyber security. For  example the network devices 152 can be controlled to suspend data links 156 between network  devices 152 and / or functional nodes 154. Suspending data links 156 can improve cyber security  by preventing an attacker from propagating an attack to new functional nodes. Thus,  implementations of the present disclosure provide systems and methods for integrating both  physical modeling of nuclear power plants and game theory to predict attacker actions, model  the consequences of those actions, and control a network of the nuclear power plant to  mitigate the effect of the attack.

[0075] With reference to FIG. 2, implementations of the present disclosure further  include methods of performing probabilistic risk assessment, for example using the systems  shown in FIG. 1A and 1B. At step 201 the method includes generating the system state using  the system model. At step 202 the method includes providing the system state to the action  model using the dynamic probabilistic risk assessment engine.  At step 203, the method  includes sampling the actions to be implemented on the system model from the actions  generated by the action model and sampling component failures to be implemented on the  system model using the dynamic probabilistic risk assessment engine.  At step 204 the method  includes implementing the sampled actions and component failures on the system model. At  step 205, the method includes the collection of data generated during the process using the  dynamic probabilistic risk assessment engine. Docket Number:  103361‐518WO1

[0076] At step 210, the method 200 includes generating risk metrics using the post  processing module in performing the dynamic probabilistic risk assessment corresponding to a  system model.

[0077] At step 220, the method 200 further includes modelling actions in the system  model using an action model.

[0078] In some implementations, the method 200 further includes modeling a  plurality of actions for an attacker and a plurality of actions for a defender based on a game  theory analysis of the attacker and defender’s actions.

[0079] In some implementations, the method 200 further includes determining a risk  metric based on the actions in the system.

[0080] It should be appreciated that the logical operations described herein with  respect to the various figures may be implemented (1) as a sequence of computer implemented  acts or program modules (i.e., software) running on a computing device (e.g., the computing  device described in FIG. 7), (2) as interconnected machine logic circuits or circuit modules (i.e.,  hardware) within the computing device and / or (3) a combination of software and hardware of  the computing device. Thus, the logical operations discussed herein are not limited to any  specific combination of hardware and software. The implementation is a matter of choice  dependent on the performance and other requirements of the computing device. Accordingly,  the logical operations described herein are referred to variously as operations, structural  devices, acts, or modules. These operations, structural devices, acts and modules may be  implemented in software, in firmware, in special purpose digital logic, and any combination  thereof. It should also be appreciated that more or fewer operations may be performed than Docket Number:  103361‐518WO1  shown in the figures and described herein. These operations may also be performed in a  different order than those described herein.

[0081] Referring to Fig. 7, an example computing device 1100 upon which the  methods described herein may be implemented is illustrated. It should be understood that the  example computing device 1100 is only one example of a suitable computing environment  upon which the methods described herein may be implemented. Optionally, the computing  device 1100 can be a well‐known computing system including, but not limited to, personal  computers, servers, handheld or laptop devices, multiprocessor systems, microprocessor‐based  systems, network personal computers (PCs), minicomputers, mainframe computers, embedded  systems, and / or distributed computing environments including a plurality of any of the above  systems or devices. Distributed computing environments enable remote computing devices,  which are connected to a communication network or other data transmission medium, to  perform various tasks. In the distributed computing environment, the program modules,  applications, and other data may be stored on local and / or remote computer storage media.

[0082] In its most basic configuration, computing device 1100 typically includes at  least one processing unit 1106 and system memory 1104. Depending on the exact configuration  and type of computing device, system memory 1104 may be volatile (such as random access  memory (RAM)), non‐volatile (such as read‐only memory (ROM), flash memory, etc.), or some  combination of the two. This most basic configuration is illustrated in FIG. 7 by dashed line  1102. The processing unit 1106 may be a standard programmable processor that performs  arithmetic and logic operations necessary for operation of the computing device 1100. The Docket Number:  103361‐518WO1  computing device 1100 may also include a bus or other communication mechanism for  communicating information among various components of the computing device 1100.

[0083] Computing device 1100 may have additional features / functionality. For  example, computing device 1100 may include additional storage such as removable storage  1108 and non‐removable storage 1110 including, but not limited to, magnetic or optical disks or  tapes. Computing device 1100 may also contain network connection(s) 1116 that allow the  device to communicate with other devices. Computing device 1100 may also have input  device(s) 1114 such as a keyboard, mouse, touch screen, etc. Output device(s) 1112 such as a  display, speakers, printer, etc. may also be included. The additional devices may be connected  to the bus in order to facilitate communication of data among the components of the  computing device 1100. All these devices are well known in the art and need not be discussed  at length here.

[0084] The processing unit 1106 may be configured to execute program code  encoded in tangible, computer‐readable media. Tangible, computer‐readable media refers to  any media that is capable of providing data that causes the computing device 1100 (i.e., a  machine) to operate in a particular fashion. Various computer‐readable media may be utilized  to provide instructions to the processing unit 1106 for execution. Example tangible, computer‐ readable media may include, but is not limited to, volatile media, non‐volatile media,  removable media and non‐removable media implemented in any method or technology for  storage of information such as computer readable instructions, data structures, program  modules or other data. System memory 1104, removable storage 1108, and non‐removable  storage 1110 are all examples of tangible, computer storage media. Example tangible, Docket Number:  103361‐518WO1  computer‐readable recording media include, but are not limited to, an integrated circuit (e.g.,  field‐programmable gate array or application‐specific IC), a hard disk, an optical disk, a  magneto‐optical disk, a floppy disk, a magnetic tape, a holographic storage medium, a solid‐ state device, RAM, ROM, electrically erasable program read‐only memory (EEPROM), flash  memory or other memory technology, CD‐ROM, digital versatile disks (DVD) or other optical  storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage  devices.

[0085] In an example implementation, the processing unit 1106 may execute  program code stored in the system memory 1104. For example, the bus may carry data to the  system memory 1104, from which the processing unit 1106 receives and executes instructions.  The data received by the system memory 1104 may optionally be stored on the removable  storage 1108 or the non‐removable storage 1110 before or after execution by the processing  unit 1106.

[0086] It should be understood that the various techniques described herein may be  implemented in connection with hardware or software or, where appropriate, with a  combination thereof. Thus, the methods and apparatuses of the presently disclosed subject  matter, or certain aspects or portions thereof, may take the form of program code (i.e.,  instructions) embodied in tangible media, such as floppy diskettes, CD‐ROMs, hard drives, or  any other machine‐readable storage medium wherein, when the program code is loaded into  and executed by a machine, such as a computing device, the machine becomes an apparatus  for practicing the presently disclosed subject matter. In the case of program code execution on  programmable computers, the computing device generally includes a processor, a storage Docket Number:  103361‐518WO1  medium readable by the processor (including volatile and non‐volatile memory and / or storage  elements), at least one input device, and at least one output device. One or more programs  may implement or utilize the processes described in connection with the presently disclosed  subject matter, e.g., through the use of an application programming interface (API), reusable  controls, or the like. Such programs may be implemented in a high level procedural or object‐ oriented programming language to communicate with a computer system. However, the  program(s) can be implemented in assembly or machine language, if desired. In any case, the  language may be a compiled or interpreted language and it may be combined with hardware  implementations.

[0087] Examples

[0088] The following examples are put forth so as to provide those of ordinary skill in  the art with a complete disclosure and description of how the compounds, compositions,  articles, devices and / or methods claimed herein are made and evaluated, and are intended to  be purely exemplary and are not intended to limit the disclosure. Efforts have been made to  ensure accuracy with respect to numbers (e.g., amounts, temperature, etc.), but some errors  and deviations should be accounted for. Unless indicated otherwise, parts are parts by weight,  temperature is in  ^C or is at ambient temperature, and pressure is at or near atmospheric.

[0089] Example 1

[0090] An example implementation of the present disclosure was designed and  tested to evaluate nuclear power plant cyber security risk. The example implementation of the  present disclosure includes a system where “attackers” and “defenders” are modeled in an  evolving system including a physics‐based model of the system, stochastic events, and a game Docket Number:  103361‐518WO1  theory analysis.  The example implementation was implemented according to the system 100  shown in FIG. 1A. In the example implementation, the system 100 was configured to use a full‐ scale nuclear power plant simulator (GSE) physics model, and a GNS3 network simulator co‐ simulated with the physics model, and a reduced‐order model of a PWR (pressurized water  reactor).

[0091] FIG. 8 illustrates an example implementation of the present disclosure  including a model 800 of the strategic interactions between attackers / defenders in a system  including physical components. The example implementation models an attacker 802, a  defender 804 (e.g., the operator of a network) and an industrial control system 810 (“ICS”). The  industrial control system 810 includes digital components 812 (e.g., software running on  networked devices) and physical components 814 (e.g., controllers, computing devices, sensors,  actuators, etc.). The industrial control system 810 is configured to sense and control physical  components of a system 820 (e.g., any or all of the components of the nuclear reactor shown in  FIG. 14, and / or any other industrial system).

[0092] With reference to FIG. 9, an example method of analyzing the system of FIG. 8  is shown according to implementations of the present disclosure. The method includes  analyzing the actions taken by the attacker 802 and defender 804 that affect the digital  components 812 of the ICS. The actions of the attacker 802 and defender 804 on the digital  components 812 can affect the physical (e.g., mechanical) components 814 of the ICS, and in  turn impact the system 820. The example method can therefore include analyzing both the  interactions between the attacker 802 and defender 804, as well as the subsequent effects that  the actions taken by the attacker 802 and defender 804 have on the entire system by modeling Docket Number:  103361‐518WO1  the effect of attacks on the digital components, physical components, and the system 820. It  should be understood that the steps shown in FIG. 9 can be performed iteratively. For example,  the actions taken by the attacker 802 and defender 804 can be based on the state of the system  820, so that moves made in one iteration of the method can subsequently effect further  iterations of the method. Implementations of the present disclosure can therefore improve  analysis of cyber attacks and defenses on complicated physical systems 820 by modeling the  ongoing evolution of the attack over time.

[0093] At any time  ^^, the overall system state of the NPP is represented using the  tuple (  ^‾^, ^^, ^^, ^^, ^^^.

[0094] ^‾^ ‐ A vector representing the physical state of a nuclear power plant.

[0095] Vector of physical variables such as pressure, flowrate, temperature etc.

[0096] ^‾^ ∈ ℝ^ is a point in continuous space with its boundaries determined by  system physics.

[0097] ^^ ⊂ ℝ^ represents the space of all possible physical state vectors  ^‾^.

[0098] ^^ ‐ The states of the components in the NPP are represented using a discrete  vector.  ^^ represents the set of all possible component states.

[0099] The couple ^ ^^, ^^^ represents the latest pair of actions taken by the defender  and the attacker respectively.  ^^ ൌ ^ ^^^, ^^ଶ, ^^ଷ… ^ is the defender's action space.  ^^ ൌ ^ ^^^, ^^ଶ, ^^ଷ… ^ is the attacker's action space. The example implementation assumes that the  defender and the attacker action spaces are discrete.

[0100] ^^^ ^‾^, ^^, ^^, ^^, ^^^ ൌ the probability density of the overall system state  ^ ^‾^, ^^, ^^, ^^, ^^^ at time  ^^. Docket Number:  103361‐518WO1

[0101] The example implementation further includes a description of continuous  event trees.

[0102] Probability that the system is in unsafe operating region at time  ^^ ൌ ∑ௗ,^ ∑^ ^^^ೆ  ^^^ ^‾^, ^^, ^^, ^^, ^^^ ^^ ^‾^, where  ^^^ is the Unsafe region in state space

[0104] For example, the study can use integers to represent discrete states of  components. 0 ‐ Normal, 1 ‐ Failed, 2 ‐ Compromised.

[0105] For the example system,  ^^ ൌ^^^^, ^^ଶ, ^^ଷ^, where  ^^^, ^^ଶ∈ ^0,1,2^, ^^ଷ∈ ^0,1^

[0106] Assume that the attacker actions are:  ^^^, ^^ଶ∈ ^^, where  ^^^ is  compromise the controller, and  ^^ଶ is compromise the sensor.

[0107] If the components are initially in the state  ^^^ൌ ^0,0,0^ and the attacker  takes action  ^^^, then the system state changes to  ^^ଶൌ ^2,0,0^.

[0108] FIG. 10 illustrates an example diagram of a controller, digital flow sensor,  and mechanical valve that can each be assigned discrete states, according to implementations  of the present disclosure.

[0109] The example implementation of the present disclosure further includes a  description of trajectories describing the system’s evolution in physics state space represented  by a set of differential equations.

[0110] ப^‾^ ൌ ^^^^ ^‾^, ^^^ ^‾^^ ^^^ ൌ ^^^^ ^^, ^‾^^^. Docket Number:  103361‐518WO1

[0112] Trajectory is dependent on the component state vector  ^^, which in turn  depends on physics (component failures), and the actions of the defender and the attacker  ^ ^^, ^^^:  ^ ^^^ ^‾^, ^^, ^^, ^^, ^^^ ൌ^^    ^^^ ^‾^ , ^^, ^^, ^^, 0^ ൈ ^^^^‾^ െ ^^^^ ^^, ^‾^^^ൈ ^ ^^ି^బ ఒ^,^,ೌ^^^^^,௨‾^^ௗ^^ ^^ ^‾^^^^ ^‾^^ herein, and FIG. 12 illustrates a model of an example trajectory.

[0114] The example implementation further includes game theory modeling of  actions in the system:  ௧ ^   ^   ^   ^^    ^^^^‾^ , ^^, ^^ᇱ, ^^ᇱ, ^^^ൈ ^^^^^ᇱ, ^^ᇱ→ ^^, ^^ ^‾^ , ^^, ^^^ൈ ^^^ ^^ → ^^^‾^behave in their respective objectives, where  ^^^ ^^ᇱ, ^^ᇱ→ ^^, ^^ ∣ ^‾^ , ^^, ^^^ represents the probability  that the defender and attacker take new actions  ^^, ^^ at time  ^^,given the physical system state  ^‾^   and component state  ^^. As described herein, game theory can quantify this value based on the  strategic interactions between one or more “players” (e.g., one or more attackers and one one  or more defenders). Docket Number:  103361‐518WO1

[0116] An example game theory model is shown in FIG. 13, where ^^, ^ ^^, ^^^,^^^^, ^^ௗ^, ^^,^^^^, ^^ௗ^, ^^. As shown in FIG. 13, the model includes two players: attacker and defender, where:

[0117] ^^ ൌ ^^ ൈ ^^ is the set of system states.

[00118] ^^ ൌ^^^^, ^^ଶ, ^^ଷ …^ is the defender's action space.

[0119] ^^ ൌ^^^^, ^^ଶ, ^^ଷ …^ is the attacker's action space.

[0120] ^^ௗ and  ^^^ are the action policies of the defender and the attacker.

[0121] ^^: ^^ ൈ ^^ ൈ ^^ ൈ ^^ → ^0,1^ is the state transition probability mapping.

[0122] ^^ௗ: ^^ ൈ ^^ ൈ ^^ ൈ ^^ → ℝ is the reward function of the defender.

[0123] ^^^^: ^^ ൈ ^^ ൈ ^^ ൈ ^^ → ℝ is the attacker's reward function.

[0124] ^^ௗ, ^^^ ‐ Value functions representing the goodness of the state. These  are the expected cumulative rewards by following a given policy from the current state.

[0125] In the example implementation, the model of continuous events in the  game theory simulation includes:  ^^ఈ^ ^‾^, ^^, ^^, ^^, ^^^ൌ^^ఈ^^௧^^^ ^ actionఈ ^^^ ^ ^^^^ ^^ → ^^ ^‾^^ ൈ ^ ^ ^^^^   ^^ ^^attacker) for taking the action ఈ ^ ^^, ^^^ at the physical system state  ^‾^, the component state  ^^  and time  ^^.

[0127] ∑^  ^^^ ^^ → ^^ ∣ ^^, ^^, ^‾^^ ൈ ^ ^^tఈransition ^ ^^, ^^^^ ‐ This is the expected immediate  reward received by the player  ^^ when there is a transition out of the component state  ^^ due to  the pair of actions ^ ^^, ^^^. The term  ^^tఈransition ^ ^^, ^^^ is the immediate reward received by the Docket Number:  103361‐518WO1  player  ^^, when the component state transitions from  ^^ to  ^^ due to the pair of actions ^ ^^, ^^^,  where  ^^^ ^^ → ^^ ∣ ^^, ^^, ^‾^^ is the probability of that transition.

[0128] The third term represents the recursive equation to compute rewards  from future states.

[0129] Equilibrium concepts, for example the concept of mixed strategy Nash  Equilibrium can be used to compute the policies of the attacker and the defender given the  value functions. In a Nash Equilibrium, no player would unilaterally deviate from his / her  strategy at the equilibrium.

[0130] The example implementation can further include simulating  consequences (e.g., reactor trips) when cyberattacks are successfully conducted.

[0131] As described with reference to FIG. 1A, the example implementation can  be used to model a system including a network with sensors, computers, and controllers that  are linked together by a network with one or more data links. Attacker actions can include  disrupting one or more of the data links of the network. Additional non‐limiting examples of  attacker actions include tampering and / or blocking data from different functional nodes.  Defender actions can include suspending data links (e.g. from functional nodes that are being  tampered with).

[0132] FIG. 14 illustrates an example case study performed of an  implementation of the present disclosure. FIG. 14 includes a PWR model with three steam  generators implemented on the GPWR by GSE systems is used as the system model, where a  Loss of Feedwater event is considered. The PWR model includes three steam generators and  feedwater loops, where each steam generator is supplied feedwater through a main feedwater Docket Number:  103361‐518WO1  valve,  the feedwater valves are controlled by local valve controllers (VC1, VC2, VC3) which   receive control signals from the main computers (MC) and backup computers (BC). The MC and  BC receive sensor signals from three flowmeters, one from each loop. (SENS1, SENS2, SENS3)

[0133] To compute the control signals for the valves, the MC and BC use signals  from respective sensors. The sensors are connected to the MC and BC through two switches  (SW1, SW2), and similarly the valve controllers are connected to the MC and BC through two  switches (SW3, SW4). A total of 16 links are considered between the sensors, computers and  valve controllers. It should be understood that the case study shown in FIG. 14 is intended only  as a non‐limiting example, and that different types of reactor and network can be modeled  according to implementations of the present disclosure.

[0134] FIG. 15 illustrates an example simulation of the case study shown in FIG.  14.

[0135] FIG. 16 illustrates example states of components used in the case study.

[0136] The action space for the defender in the case study, includes:

[0137] 1‐16: Deactivate links 1‐16

[0138] 17: Change the valve controllers’ state from 1 to 2 (e.g., start using input  from the backup computer)

[0139] 18: No action.

[0140] The action space for the attacker in the case study includes:

[0141] 1: Compromise flow sensor 1

[0142] 2: Compromise flow sensor 2

[0143] 3: Compromise flow sensor 3 Docket Number:  103361‐518WO1

[0144] 4: Compromise Main Computer

[0145] 5: Compromise Backup Computer

[0146] 6: Compromise Valve controller 1

[0147] 7: Compromise Valve Controller 2

[0148] 8: Compromise Valve Controller 3

[0149] 9: No action.

[0150] The case study assumed:

[0151] 1. The attacker is already in the system and is trying to initiate a Loss of  Feedwater event.

[0152] 2. The attacker can successfully compromise any component initially with  probability 0.125 .

[0153] 3. If the attacker tries to compromise a component the probability of  success is 0.3 if a neighboring component is already compromised, else it is  0.125.

[0154] 4. Once a component is compromised, it remains in that state until the  end of mission time.

[0155] 5. Once a link is deactivated, it remains in that state until the end of  mission time.

[0156] Results

[0157] The simulation case study was run with a time of 240 seconds in 10‐ second time steps. Docket Number:  103361‐518WO1

[0158] The trajectories of narrow water range levels in each of the three steam  generators are illustrated in FIGS. 17A‐17C, where FIG. 17A illustrates the water level in steam  generator 1, FIG. 17B illustrates the water level in steam generator 2, and FIG. 17C illustrates  the water level in steam generator 3.

[0159] The simulation case study used a Mixed‐Strategy Nash Equilibrium to  compute the attacker and defender strategies.

[0160] In the case study, the reactor was tripped once in thirty scenarios.

[0161] While the case study was employed for modeling a nuclear reactor, it  should be understood that any kind of industrial network can be modeled and evaluated for  cyber security. The present disclosure contemplates that, for example, firewalls, network  diodes, and other network components can be modeled and evaluated according to  implementations of the present disclosure. Additionally, it should be understood that the  attacker and defender actions described herein are non‐limiting examples.

[0162] Finally, it should be understood that implementations of the present  disclosure can be used to control the performance of industrial networks (e.g., nuclear power  plant controls). For example, implementations of the present disclosure can be used to  evaluate an ongoing attack, and / or model the performance of potential attacker and defender  actions to improve the cyber security of a power plant in real time.

[0163] Example 2:

[0164] A study was performed of an example implementation of the present  disclosure shown in FIG. 1A.  Docket Number:  103361‐518WO1

[0165] The study included configuring the example implementation for dynamic  probabilistic risk assessment (DPRA) configured to incorporate the stochastic nature of the  operator's as well as the attacker's actions using a game theory based framework in addition to  component failures, and study their effects on the evolution of the system. Hence, the example  DPRA simulation architecture is configured to include the three below elements:

[0166] (1) The system model to emulate the evolution of the system under  consideration, in this case a nuclear power plant.

[0167] (2) The DPRA engine, that monitors the state of the system, and  implements the sampled attacker and defender actions as well as randomly generated  component failure scenarios

[0015] .

[0168] (3) The action model which generates a set of possible operator and  attacker actions to be implemented on the system. In addition to the system model and the  DPRA engine, the example implementation explicitly considers an action model that generates  possible defender and attacker actions to be implemented on the system model using a game  theory based analysis. The action model and its components are explained in this section.

[0169] Additionally, a post processing module can be used to analyze the large  amounts of data generated during the simulations and compute meaningful risk metrics. FIG.  1A depicts a high‐level schematic of the DPRA simulation architecture used to perform  cybersecurity risk analysis.

[0170] The study included configuring the implementation of the DPRA engine  400 shown in FIG. 4. The DPRA engine was configured so that the data collection module 402 of  the DPRA engine 400 receives system physical state information (e.g., a vector of relevant Docket Number:  103361‐518WO1  physical variables, and the current component state information) from the system model. This  information can be disseminated to the component failure models element 404 of the DPRA  engine and the action model 500. Using this information as input, the component failure  models element 404 updates the failure rates and the failure modes of the NPP components  and transmits the updated values back to the data collection module 402. Similarly, the action  model 500 returns a set of possible attacker and defender actions to the data collection module  402. The output of the component failure models element 404, and the action model 500  received by the data collection module 402 is transmitted to the sampler. The next state  transition time, the next state transition to be implemented on the system model from the set  of failure modes generated by the component failure models and the next operator and  attacker actions to be enforced on the system model form the inputs received from the action  model are sampled by the sampler element 406 of the DPRA engine 400 and provided to the  data collection module 402. The data collection module 402 then shares this information with  the scheduler 408, which then implements the sampled transitions and the sample actions on  the system model 102. The data collection module assimilates all the data generated by all the  elements of the DPRA architecture. This data can be sent to the post processing module for  analysis and computation of relevant risk metrics.

[0171] The example study further included configuring the system model 300  shown in FIG. 3. The system model 300 includes mathematical models of the components in the  physical systems layer under different states, mathematical models of the controllers, and the  models of other network elements. The system model 300 can be configured to simulate the  evolution of the physical system when subjected to stochastic events including component Docket Number:  103361‐518WO1  failures and cyber‐attacks. The example implementation included an abnormal event detection  and classification system 302

[0016] that can detect an abnormal event and differentiate it as  either a safety event caused by component failure or a cyber‐attack. This can be used to  explore scenarios of undetected attackers and evaluate the associated risks, according to  implementations of the present disclosure. Implementations of the present disclosure can  further be configured to evaluate scenarios in which a cyber‐attack is undetected, resulting in  the operator taking incorrect actions, which can therefore generate risks.

[0172] The study further included configuring the example action model 500  shown in FIG. 5. The action model 500 can receive system monitoring information (e.g.,  information about the system state as defined by the vector of a list of physical variables and  vector of component states) and generate a set of possible attacker and operator actions. As  shown in FIG. 5, the example action model 500 can include three individual models, the  procedure model 502, the undetected attacker model 504, and the game model 506. The study  assumed that the operator is procedure following and is not prone to errors. The procedure  model 502 is used to generate possible operator actions when no cyberattack is detected by  the abnormal event detection module in the system model. The undetected attacker model 504  is used to represent and model initial launching of cyber‐attacks and the scenarios in which a  cyber‐attack remains undiagnosed.

[0173] The study further included configuring the game model 600 shown in FIG.  6. The action model 500 can switch to the game model 600 when a cyberattack is detected in  the system. In the presence of a cyber‐attack, the operator takes the role of a defender. The  components of the game model 600 are the game itself of which the attacker and defender(s) Docket Number:  103361‐518WO1  are the players, and a spinoff DPRA process. The optimal attacker and defender actions can  depend on the physics of the system. The game model 600 can consider the computation of  optimal actions based on physics and implement those on the system to observe it's evolution.  So the example implementation can simulate (e.g., by running a parallel model to predict the  system behavior under different pairs of attacker and defender actions to a certain time point  in the future and use that knowledge to inform the attacker and defender policies in the  original DPRA process.

[0174] The study further included an analysis of continuous event trees for  cybersecurity risk analysis, which can be implemented using the system 100 shown in FIG. 1A.

[0175] The study included a mathematical formulation of continuous event trees  [8] for cybersecurity risk analysis that can be applied using the system 100 of FIG. 1A.

[0176] An example nuclear power plant system was modeled as follows in the  example implementation studied:

[0177] The physical state of a nuclear power plant can be represented using a  state vector,  ^‾^, a vector of physical variables such as pressure, flowrate, temperature etc. It is  implicit that  ^‾^ ∈ ℝ^ is a point in continuous space with its boundaries determined by the physics. Let  ^^ ⊂ ^‾^.

[0178] The states of the components in the NPP can be represented using a  vector  ^^, a vector on a discrete space. The example implementation uses discrete component  states (e.g., normal or failed states). Integers can be used to represent such discrete states of  components. For example, 0, 1 and 2 can be used to denote that a component is in normal  state or failed state or compromised state respectively. Consider an example system with three Docket Number:  103361‐518WO1  components, a digital controller, a digital sensor and a mechanical valve. Then  ^^ ൌ ^ ^^^, ^^ଶ, ^^ଷ^  where  ^^^, ^^ଶ, and  ^^ଷ represent the states of the controller, the sensor and the valve respectively.  Here,  ^0,1,2^ and  ^^ଷ∈ ^0,1^ because the digital controller and the sensor can be  compromised whereas the mechanical valve cannot be subjected to cyber‐attacks. Let ℂ  represent the set of all possible component states.

[0179] ^^ ൌ ^ ^^^, ^^ଶ, ^^ଷ… ^ is the defender's action space and  ^^ ൌ ^ ^^^, ^^ଶ, ^^ଷ… ^  is the attacker's action space. The study assumes that the defender and the attacker action  spaces are discrete, with actions such as switch from main controller to backup controller or  compromise the controller and shut down the pump etc. Continuous action spaces can also be  used in implementations of the present disclosure. Feasible defender and attacker actions can  depend on the physical state as well as the state of components. For example, the example  implementation can assume that a component that has been compromised by the attacker  cannot be compromised again and remains in that state, until it is "repaired." Additionally,  certain actions may not be physically possible depending on the physical state of system, and  implementations of the present disclosure can model the physically possible actions of the  system. For example, the speed of a pump cannot be reduced to zero instantaneously.

[0180] At any time  ^^, the overall system state of the NPP can be represented  using the tuple (  ^‾^, ^^, ^^, ^^, ^^^, where the physical state vector  ^‾^ represents the physical system  state, the component state is represented by the vector  ^^, and the couple ^ ^^, ^^^ represents the  latest pair of actions taken by the defender and the attacker respectively. For the remainder of  this example, the expressions physical state vector and physical state will be used Docket Number:  103361‐518WO1  interchangeably. The same is true for the expressions component state vector and component  state.

[0181] A system of differential equations as presented by equation (1) can be  used to represent the trajectory of the NPP in the physical state space [8].

[0182] பப௧^‾^ ൌ ^^^^ ^‾^, ^^^ of the components i.e., when the states of components change, the differential equations  representing the dynamics of the system will change and the system follows a different  trajectory in the state space, as shown in FIG. 11.

[0184] The component state  ^^ can change either due to random component  failures or due to the actions of the defender and the attacker. Additionally, the defender and  attacker may not be able to directly interfere with the physical process and may only change  the component state vector, which in turn will change the trajectory of system evolution i.e.,  the trajectory of the reactor in the physical state space is conditionally independent of the  actions of the attacker and the defender given the component state vector. In the example  depicted in FIG. 11, initially the system is in the state (  ^‾^^, ^^, ^^^, ^^^, ^^^ ), and evolves along the  trajectory defined by  ^^^ until time  ^^, where the physical state vector is  ^‾^^. The defender and the attacker then take actions ^^^^, ^^^^ at ^^‾^^, ^^^ and the component state vector transitions from  ^^ to  ^^ as a result, following which the system evolves along the trajectory defined by  ^^^. The study  assumes that the component state transitions due to attacker and defender actions if any, are  instantaneous, but the present disclosure contemplates that non‐instantaneous transitions can  be modeled in implementations of the present disclosure.  Docket Number:  103361‐518WO1

[0185] Let equation (2) represent the solution to the system of differential  equations presented in equation (1), where  ^‾^^ is the initial condition [8]. It is implicit that for  time  ^^ ൌ 0, ^‾^^ൌ ^^^^0, ^‾^^^. It is also implicit that  ^^^ and  ^^^ represent the same trajectories in the ^^.  ^‾^^ ^^^ ൌ ^^^^^^, ^‾^^^^2^

[0186] ^^ be  ^^^ ^‾^, ^^, ^^, ^^, ^^^. Let the conditional probability density that the system is in state  ^ ^‾^, ^^, ^^, ^^, ^^^ at time  ^^, given the initial state (  ^‾^^, ^^, ^^^, ^^^, ^^^ ) be denoted by  ^^^^‾^, ^^, ^^, ^^, ^^ ∣ ^‾^^, ^^, ^^^, ^^^, ^^^^ [8]. It is implicit that: Kronecker delta functions. An objective of the study is to compute the value  ^^^ ^‾^, ^^, ^^, ^^, ^^^ and  to consequently estimate the probability that the physical state of the reactor is in a certain  region of the state space at any given instant of time.

[0188] As discussed above, the trajectories in physical state space are  determined by the component state vector. The component state vector can change either due  to random failures of components or due to the actions of the attacker and the defender. In  summary, the trajectories in the physical state space are dependent on the substate ^ ^^, ^^, ^^^.

[0189] Let  ^^^,ௗ,^^ ^‾^^Δ ^^ be the conditional probability that there is a transition out  of the substate ^ ^^, ^^, ^^^ in the interval Δ ^^, when the system is in state (  ^‾^, ^^, ^^, ^^, ^^ ). The failure  rates of the components are dependent on the physical state  ^‾^. Let  ^^^^ ^^ → ^^ ∣ ^‾^^Δ ^^ be the  conditional probability that the component state transitions from  ^^ to  ^^ in the interval Δ ^^ Docket Number:  103361‐518WO1  explicitly due to random component failures when the physical state vector is  ^‾^ and the  defender and attacker take no new actions. Additionally, the physical state  ^‾^ influences the  actions of the defender as well as the attacker. Let  ^^^^ ^^ →  ^^ ∣ ^^ᇱ, ^^ᇱ, ^‾^^Δ ^^ be the conditional  probability that the component state transitions from  ^^ to  ^^ in the interval Δ ^^ when the  defender and attacker take new actions  ^^ᇱ and  ^^ᇱ respectively at the physical state  ^‾^. The  relation between  ^^^,ௗ,^^ ^‾^^, ^^^^ ^^ → ^^ ∣ ^‾^^ and  ^^^^ ^^ → ^^ ∣ ^^ᇱ, ^^ᇱ, ^‾^^ is presented in equation (4)  where  ^^^ ^^, ^^ →^^ᇱ^ is the probability that the defender and the attacker take new actions  ^^ᇱ, ^^ᇱ respectively.  ^^^,ௗ,^^ ^‾^^ ൌ ^     ^^^^ ^^ → ^^ ∣ ^‾^^ ^ ^    ^^^ ^^, ^^ → ^^ᇱ, ^^ᇱ ∣ ^‾^^ ൈ ^     ^^^^ ^^ → ^^ ∣ ^^ᇱ, ^^ᇱ, ^‾^^ ^4^density that the system reaches the physical state  ^‾^ at time  ^^ while remaining in the substate (  ^^, ^^, ^^^ until time  ^^ is given by the product  ^^^ ^‾^ െ ^^ ^ ^^ െ ^^ , ^‾^ ^^ ൈ ^ି^ ^^బఒ^,^,ೌ^^^^^,௫‾బ^^ௗ^^^ ^^  where  ^ he term  ^^ି^^tబ^ ^^, ^^, ^^ )^^^ during the interval ^ ^^^, ^^^ and the term  ^^^^‾^ െ ^^^^^^ െ ^^^, ^‾^^^^ represents the probability density that ^ ^‾^, ^^^ is the only point reachable from ^ ^‾^^, ^^^^ along the trajectory defined by  ^^^^8^.

[0191] The study further included determining the equation of an extended  continuous event tree.

[0192] Equation (5) presents the integral form of the continuous event tree  equation based on the Chapman Kolmogorov equation [8] extended to the cyber‐attack case to  compute the probability density that the system is in state ^ ^‾^, ^^, ^^, ^^, ^^^ at time  ^^. Docket Number:  103361‐518WO1  ^^^ ^‾^, ^^, ^^, ^^, ^^^ ^5^ൌ^^     ^^^ ^‾^ , ^^, ^^, ^^, 0^ ൈ ^^^^‾^ െ ^^^^ ^^, ^‾^^^ൈ ^ ^^ି ^^బ ఒ^,^,ೌ^^^^^,௨‾^^ௗ^^ ^^ ^‾^^parentheses):

[0194] (1) ^   ^^^ ^‾^ , ^^, ^^, ^^, 0^ ൈ ^^^ ^‾^ െ ^^ ^ ^^ ^ି^ ^బ ఒ^,^,ೌ^^^^^,௨‾^^ௗ^^^ ^, ^‾^^ ൈ ^ ^^ ^ ^^ ^‾^  ‐ This , ^^, ^^, ^^, 0^,  and reaches the physical state  ^‾^ at time  ^^ while remaining in the substate (  ^^, ^^, ^^ ) until time  ^^,  along the trajectory defined by  ^^^. While the integral is computed over the entire physical state  space  ^^, the Dirac delta function  ^^^^‾^ െ ^^^^ ^^, ^‾^^^ ensures that only a specific subset of  appropriate  ^‾^  values are valid.

[00195] ^2^  ∑^ஷ^ ^ ^^  ^^௧^  ^^^ ^^ → ^^ ∣ ^‾^^ ൈ ^^^ ^‾^ , ^^, ^^, ^^, ^^^ ൈ ^^^^‾^ െ ^^^^ ^^ െ ^^, ^‾^^^ൈ ି^ ^^ ^^(  ^‾^ , ^^, ^^, ^^, ^^^ at some intermediate time  ^^  between 0 and  ^^, when the component state transitions from  ^^ to  ^^ due to a random event and  not due to attacker and defender actions, and after that the system evolves along the trajectory  defined by  ^^^ while remaining in the state ^ ^^, ^^, ^^^ from time  ^^ to  ^^, and eventually reaches the  physical system state  ^‾^ at time  ^^. The sum of this probability density over all possible (  ^‾^ , ^^, ^^ ) is Docket Number:  103361‐518WO1  computed. The second part of equation (5) is recursive in nature, similar to the Chapman‐ Kolmogorov equation [8].

[0196] ^3^ ∑௧ௗᇲ,^ᇱஷௗ,^ ∑^ ^^^ ^^^  ^^^ ^‾^ , ^^, ^^ᇱ, ^^ᇱ, ^^^ ൈ ^^^ ^^ᇱ, ^^ᇱ→ ^^, ^^ ∣ ^‾^ , ^^, ^^^ ൈ(  ^‾^ , ^^, ^^ᇱ, ^^ᇱ, ^^ ) at some time  ^^ between 0 and  ^^, at which point the defender and the attacker  take new actions ^ ^^, ^^^ as a result of which the component state transitions from  ^^ to  ^^ and  subsequently the system evolves along the trajectory defined by  ^^^, while remaining in the  substate ^ ^^, ^^, ^^^ from time  ^^ to  ^^ and eventually arrives at the physical system state  ^‾^ at time  ^^. The probability that the defender and the attacker take a new pair of actions  ^^^ ^^ᇱ, ^^ᇱ→ ^^, ^^ ∣ ^‾^ , ^^, ^^^ i.e., the mixed equilibrium strategies of the defender and the attacker  at physical state  ^‾^ , component state  ^^ and time  ^^ can be computed using a game theory based  approach. It can also be observed that the third term of equation (5) is recursive in nature as  well.

[0197] The conditional probability density  ^^^ ^‾^, ^^, ^^, ^^, ^^ ∣ ^‾^^, ^^^, ^^^, ^^^, ^^^^ that  the system is in the state ^ ^‾^, ^^, ^^, ^^, ^^^ at time (  ^‾^^, ^^^, ^^^, ^^^, ^^^ ) can be computed using equation (6) (see equation (3)). Docket Number:  103361‐518WO1  ^^^ ^‾^, ^^, ^^, ^^, ^^ ∣ ^‾^^, ^^^, ^^^, ^^^, ^^^^ ^5^^^^^^ ^‾^^ ^^^ ^‾^ ^^ ^‾^^^ ^ ^^ି^^బ ఒ^,^,ೌ^^^^^,௨‾^^ௗ^^ ^^ ^‾^^ players i.e., the defender and the attacker. Here  ^^ is used as an index and is not an exponent.  ^^^^ ^‾^, ^^, ^^, ^^, ^^^ and  ^^ଶ^ ^‾^, ^^, ^^, ^^, ^^^ are the expected cumulative rewards received by the  defender and the attacker respectively when the defender takes an action  ^^ and the attacker  takes an action  ^^ at the physical system state  ^‾^, the component state  ^^ and time  ^^. These  rewards are used to compute the mixed strategies of the defender and the attacker using a  game theory based approach [7]. The computation of mixed strategies is not explicitly  discussed herein.  ^^ఈ^ ^‾^, ^^, ^^, ^^, ^^^ ^7^ equation (5) are explained below:  1. ^^aఈction ^^‾^, ^^, action ఈ, ^^^: ^^a^ction ^ ^‾^, ^^, ^^, ^^^ is the cost incurred by the defender for  taking the action  ^^ at the physical system state  ^‾^, the component state  ^^ and time  ^^, Docket Number:  103361‐518WO1  while  ^^^ଶ^௧^^^^ ^‾^, ^^, ^^, ^^^ is the cost incurred by the attacker for taking the action  ^^ at  the physical system state  ^‾^, the component state  ^^ and time  ^^.  2. ∑^  ^^^ ^^ → ^^ ∣ ^^, ^^, ^‾^^ ൈ^^^tఈransition ^ ^^, ^^^^ is the expected immediate reward received by  the player  ^^ when there is a transition out of the component state  ^^ due to the pair ^^, ^^^ is the immediate reward received by the  ^^ to  ^^ due to the pair of actions  ^ ^^, ^^^, where  ^^^ ^^ →  ^^ ∣ ^^, ^^, ^‾^^ is the probability of that transition.  3. ∑௧^^ೞೞ^^^^  ^^^ ^^ → ^^ ∣ ^^, ^^, ^‾^^ ൈ ∑^ ∑ௗᇲ,^ᇲ ^ ^^ᇱ௧  ^^^^‾^ , ^^, ^^ , ^^ᇱ, ^^ ∣ ^‾^, ^^, ^^, ^^, ^^^ൈ^^, when the ^^ and the attacker takes the action  ^^, there is an  immediate transition in the component state from  ^^ to  ^^, and the new system state  is ^ ^‾^, ^^, ^^, ^^, ^^^. The term  ^^ఈ^^‾^ , ^^, ^^ᇱ, ^^ᇱ, ^^^ represents the reward received by the  player  ^^ at some future state (  ^‾^ , ^^, ^^ᇱ, ^^ᇱ, ^^^ at time  ^^ ^ ^^ ^ ^^mission , physical system  state  ^‾^  and component state  ^^, when the defender takes action  ^^ᇱ and the attacker  takes an action  ^^ᇱ. The term  ^^^^‾^ , ^^, ^^ᇱ, ^^ᇱ, ^^ ∣ ^‾^, ^^, ^^, ^^, ^^^ represents the conditional  probability density of arriving at the system state (  ^‾^ , ^^, ^^ᇱ, ^^ᇱ, ^^ ) given that the  initial state is (  ^‾^, ^^, ^^, ^^, ^^^. The probability that the players take the pair of actions  ^ ^^ᇱ, ^^ᇱ^ at ^ ^‾^ , ^^, ^^^ is encoded in this conditional probability density.

[0200] Example 3

[0201] An example implementation of the present disclosure was designed and  tested. The example implementation includes a simulator 1800. The simulator 1800 can be  used to evaluate the protection offered by various network architectures and quantify cyber  security risks. For example, the simulator 1800 can be used to meet the demands of  cybersecurity research with increasing digitalization of nuclear power plants. FIG. 18 illustrates  the example implementation of the simulator 1800. The simulator 1800 includes a DPRA engine  1802, a physical simulator 1804, and simulation management and scheduling module 1806, a  graphical network simulator 1808, an attack library 1820, a game library 1822, and a procedure  following operator library 1824.  Docket Number:  103361‐518WO1

[0202] As described with reference to examples 1 and 2, for example, the DPRA  engine 1802 can be based on Dynamic Probabilistic Risk Assessment (DPRA), a set of  probabilistic risk assessment (PRA) techniques in which a deterministic physics‐based model is  used to study the evolution of a system in the context of stochastic events. The DPRA engine  1802 monitors the state of the system (e.g., a system modeled by a physical simulator 1804),  and implements the sampled attacker and defender actions as well as randomly generated  component failure scenarios.

[0203] The physical simulator 1804 can model the state of a physical system. As  described herein, the physical simulator 1804 can optionally model any kind of industrial  facility. In the example shown in FIG. 18, the physical simulator 1804 is a generic pressurized  water reactor simulator sold under the tradename GSE. In the example shown in FIG. 18, the  physical simulator implements a physics model of a pressurized water reactor.

[0204] The graphical setwork simulator 1808 (GNS3) includes a simulated  network model. The network model is co‐simulated with the physics model of the physical  simulator 1804 with the graphical network simulator 1808. Fig. 19 illustrates the co‐simulation  of the network and physics models implemented by the graphical network simulator 1808 and  the physical simulator 1804, respectively. The memory read / write process for data transmission  in the physics model of the physical simulator 1804 is replaced with data transmission across a  simulated network implemented on the graphical network simulator 1808 simulator with  components such as network switches. As a non‐limiting example, a platform sold under the  tradename Emulab can be used to implement the network model as an alternative or addition  to the graphical network simulator 1808.  Docket Number:  103361‐518WO1

[0205] An example implementation of a node‐management and scheduling  module 1830 that can be used with the simulation management and scheduler module 1806 is  shown in FIG. 20. The node management and scheduler module 1830 can include the  communication and digital component node in the example GNS3 environment. The node  management and schedule module 1830 module schedules communications (e.g., dictates the  frequency with which information is received and sent, and identifies the nodes from which the  input data should be received and to which the output data is sent) through the node  communication function 1832 using the input from the simulation management and scheduler  module 1806. Additionally, the node management and scheduler module 1830 provides the  node state information to the node component function 1834. It is implicit that each node can  represent a digital component in the system such as controller, sensor etc., as described with  reference to the example implementations herein, and the function of such a component is  dependent on its state.

[0206] Again with reference to FIG. 18, the simulator 1800 can further include an  attack library 1820. The attack library can include a set of cyber‐attack actions and scenarios  that can be implemented using the graphical network simulator and / or the physical simulator  1804. As non‐limiting examples, the scenarios of the attack library 1820 can include abnormal  event detection and / or classification scenarios.

[0207] The simulator 1800 can further include a game library 1822. The game  library can apply a game‐theory model to model behaviors of rational attackers / defenders in  the simulator 1800. The game library 1822 can optionally generate attacker and / or defender  strategies. Optionally attacker and defender strategies can be implemented using game theory Docket Number:  103361‐518WO1  techniques including mixed‐strategy Nash equilibriums and / or Stackelberg equilibriums, for  example. When the attacker and / or defender actions are implemented by the simulator 1800  (e.g., by modeling the attacker / defender actions on the physical model of the physical  simulator1804), trajectories can be generated for the mixed strategies of the attacker and  defender. Pairs of defender‐attacker actions can be sampled from the mixed strategies by the  DPRA engine 1802, and implemented using the physical simulator and / or the graphical network  simulator 1808. An example plot 2100 of game‐theory trajectories 2104 for attacker and  defender action pairs 2102 in a lookahead game is illustrated in FIG. 21.

[0208] Again with reference to FIG. 18, the simulator 1800 can further include a  procedure following operator library 1824. The procedure following operator library 1824 can  be configured to emulate a procedure that is performed during an operation of the physical  simulator 1804. As a non‐limiting example, the procedure following operator library 1824 can  include procedures performed by an operator of a physical system modeled by the physical  simulator 1804 under emergency conditions (e.g., the operation of a nuclear plant under a  cyber attack). The procedure following operator library can optionally run in parallel to the  graphical network simulator 1808 and / or the physical simulator 1804 to simulate procedures  that are performed based on the states of the physical system simulated by the physical  simulator 1804 and / or based on the state of a network modeled by the graphical network  simulator.

[0209] Still with reference to FIG. 18, the simulation management and  scheduling module 1806 is configured to manage / control the operation of the other modules  (e.g., any or all of the DPRA engine 1802, physical simulator 1804, graphical network simulator Docket Number:  103361‐518WO1  1808, attack library 1820, game library 1822, and / or procedure following operator library  1824).

[0210] FIG. 22 illustrates a timing diagram illustrating the parallel operation of  the graphical network simulator 1808, physical simulator 1804, procedure following operator  library 1824, and game library 1824. The simulation management and scheduling module 1806  can initialize the communication and digital component nodes of the graphical network  simulator 1808 and initialize states of any or all of the DPRA engine 1802, physical simulator  1804, graphical network simulator 1808, attack library 1820, game library 1822, and / or  procedure following operator library 1824. The simulation is considered to start at time  ^^^, and  the graphical network simulator 1808, physical simulator 1804 and procedure following  operator library 1824 run in parallel as shown in FIG 22. At time steps T step  ^^^,   ^^ ^ 0, the  game library 1822 can use a lookahead game simulation to implement all possible pairs of  attacker and defender actions on the low order model and runs a predictive simulation for  predefined number of time steps into the future as presented in FIG. 21. Again, as shown in FIG.  21, the mixed strategies of attacker and defender can be computed from those trajectories  2104. The DPRA engine 1802 samples one or more attacker and defender action pairs 2102  from the mixed strategies, and implements those actions on the physical simulator 1804 and / or  graphical network simulator 1808 to evaluate the effects of the attacker and defender action  pairs 2102 on the physical system and network modeled by the physical simulator 1804 and / or  graphical network simulator 1808.

[0211] Although the subject matter has been described in language specific to  structural features and / or methodological acts, it is to be understood that the subject matter Docket Number:  103361‐518WO1  defined in the appended claims is not necessarily limited to the specific features or acts  described above. Rather, the specific features and acts described above are disclosed as  example forms of implementing the claims.

[0212] The following patents, applications, and publications, as listed below and  throughout this document, describes various application and systems that could be used in  combination the exemplary system and are hereby incorporated by reference in their entirety  herein

[0213] [1] A. Mosleh, "PRA: A PERSPECTIVE ON STRENGTHS, CURRENT  LIMITATIONS, AND POSSIBLE IMPROVEMENTS," Nucl. Eng. Technol., vol. 46, no. 1, pp. 1‐10,  Feb. 2014, doi: 10.5516 / NET.03.2014.700.

[0214] [2] R. J. Breeding, T. J. Leahy, and J. Young, "Probabilistic risk assessment  course documentation. Volume 1: PRA fundamentals," Energy, Inc., Seattle, WA (USA),  NUREG / CR‐4350 / 1; SAND85‐1495 / 1, Aug. 1985. doi: 10.2172 / 6277413.

[0215] [3] International Atomic Energy Agency, "Defining initiating events for  purposes of probabilistic safety assessment," IAEA‐TECDOC‐719, International Atomic Energy  Agency. 1993.

[0216] [4] N. J. McCormick, Reliability and risk analysis: methods and nuclear  power applications. Academic Press New York, 1981.

[0217] [5] J. W. Park and S. J. Lee, "Probabilistic safety assessment‐based  importance analysis of cyberattacks on nuclear power plants," Nucl. Eng. Technol., vol. 51, no.  1, pp. 138‐145, Feb. 2019, doi: 10.1016 / j.net.2018.09.009. Docket Number:  103361‐518WO1

[0218] [6] Y. Zhao, L. Huang, C. Smidts, and Q. Zhu, "A game theoretic approach  for responding to cyberattacks on nuclear power plants," Nucl. Sci. Eng., 2021.

[0219] [7] Y. Zhao, L. Huang, C. Smidts, and Q. Zhu, "Finite‐horizon semi‐Markov  game for timesensitive attack response and probabilistic risk assessment in nuclear power  plants," Reliab. Eng. Syst. Saf., vol. 201, p. 106878, Sep. 2020, doi: 10.1016 / j.ress.2020.106878.

[0220] [8] J. Devooght and C. Smidts, "Probabilistic Reactor Dynamics‐I: The  Theory of Continuous Event Trees," Nucl. Sci. Eng., vol. 111, no. 3, pp. 229‐240, Jul. 1992, doi:  10.13182 / NSE92A23937.

[0221] [9] T. Aldemir, "A survey of dynamic methodologies for probabilistic  safety assessment of nuclear power plants," Ann. Nucl. Energy, vol. 52, pp. 113‐124, Feb. 2013,  doi: 10.1016 / j.anucene.2012.08.001.

[0222]

[0010] C. Smidts and J. Devooght, "Probabilistic Reactor Dynamics‐II: A  Monte Carlo Study of a Fast Reactor Transient," Nucl. Sci. Eng., vol. 111, no. 3, pp. 241‐256, Jul.  1992, doi: 10.13182 / NSE92‐A23938.

[0223]

[0011] T. Aldemir et al., "NUREG / CR‐6942: Dynamic Reliability Modeling of  Digital Instrumentation and Control Systems for Nuclear Reactor Probabilistic Risk  Assessments," 2007.

[0224]

[0012] J. Devooght and C. Smidts, "Probabilistic Reactor Dynamics ‐ III. A  Framework for TimeDependent Interaction between Operator and Reactor during a Transient  Involving Human Error," Nucl. Sci. Eng., vol. 112, no. 2, pp. 101‐113, Oct. 1992, doi:  10.13182 / NSE92‐A28407. Docket Number:  103361‐518WO1

[0225]

[0013] C. Smidts, "Probabilistic Reactor Dynamics ‐IV. An Example of  Man / Machine Interaction," Nucl. Sci. Eng., vol. 112, no. 2, pp. 114‐126, Oct. 1992, doi:  10.13182 / NSE92‐A28408.

[0226]

[0014] K.‐S. Hsueh and A. Mosleh, "The development and application of the  accident dynamic simulator for dynamic probabilistic risk assessment of nuclear power plants,"  Reliab. Eng. Syst. Saf., vol. 52, no. 3, pp. 297‐314, Jun. 1996, doi: 10.1016 / 0951‐8320(95)00140‐ 9.

[0227]

[0015] Y. Zhao et al., "Dynamic Probabilistic Risk Assessment for Cyber  Security Risk Analysis of the Electric Grid," in Proceedings of the 30th European Safety and  Reliability Conference and 15th Probabilistic Safety Assessment and Management Conference,  2020, pp. 2020‐2027. doi: 10.3850 / 978‐981‐14‐8593‐0_5058‐cd.

[0228]

[0016] P. K. Vaddi et al., "Dynamic bayesian networks based abnormal event  classifier for nuclear power plants in case of cyber security threats," Prog. Nucl. Energy, vol.  128, p. 103479, Oct. 2020, doi: 10.1016 / j.pnucene.2020.103479.

Claims

Docket Number:  103361‐518WO1  WHAT IS CLAIMED:

1. A method for performing dynamic probabilistic risk assessment, the method comprising:    providing a system model of a physical system;    providing an action model configured to generate a set of operator and  attacker actions based on a game theory analysis; and    providing a dynamic probabilistic risk assessment (DPRA) engine, wherein the  DPRA engine is configured to:      receive the set of operator and attacker actions from the action model;       sample the set of operator and attacker actions; and      provide the sampled set of operator and attacker actions to the system  model for implementation by the system model.

2. The method of claim 1, wherein the set of operator and attacker actions is randomly  sampled.

3. The method of claim 1 or claim 2, wherein the DPRA engine is further configured to  receive a state of the physical system from the system model, and provide the state of  the physical system to the action model.

4. The method of any one of claims 1‐3, wherein the system model comprises a network  model.  Docket Number:  103361‐518WO1  5. The method of claim 4, wherein the DPRA engine is further configured to receive a state  of the network model from the system model, and provide the state of the network  model to the action model.

6. The method of any one of claims 1‐5, wherein the action model comprises a plurality of  sub‐models.

7. The method of claim 6, wherein the plurality of sub‐models comprise a procedure  model, an undetected attacker model, and a game model.

8. The method of any one of claims 1‐7, wherein the DPRA engine is configured to  implement an attacker action on the system model.

9. The method of any one of claims 1‐8, wherein the DPRA engine is configured to  implement an operator action on the system model.

10. The method of any one of claims 1‐9, wherein the action model is configured to  generate a plurality of actions for an operator to implement on the physical system.

11. The method of any one of claims 1‐10, wherein the action model is configured to  generate a plurality of actions for an attacker to implement on the physical system.   Docket Number:  103361‐518WO1  12. The method of any one of claims 1‐11, wherein the action model is configured to  generate both a plurality of actions for an attacker and a plurality of actions for an  operator to implement on the physical system.

13. The method of any one of claims 1‐12, further comprising determining a risk metric  based on the actions in the system, wherein the risk metric is based on the action model  and the system model.

14. The method of claim 13, further comprising modeling a plurality of actions for an  attacker and a plurality of actions for a defender based on a game theory analysis of the  attacker and defender’s actions.

15. A method for performing dynamic probabilistic risk assessment, the method comprising:    modelling actions in a system model using an action model and    sampling the actions to be implemented on the system model by a DPRA  engine from the actions modeled by the action model; and    implementing the sampled actions on the system model.

16. The method of claim 15, further comprising determining a risk metric based on the  actions in the system.

17. A system comprising: Docket Number:  103361‐518WO1      a network device;  a controller operably coupled to the network device, the controller  comprising a processor and a memory, the memory having computer‐executable  instructions stored thereon that, when executed by the processor, cause the  controller to:    model action in a system model using an action model;     sample the actions to be implemented on the system model by a DPRA engine  from the actions modeled by the action model; and    implement the sampled actions on the system model.

18. The system of claim 17, wherein the network device is coupled to a network comprising  a functional node.

19. The system of claim 18, wherein the functional node comprises at least one of a  controller or sensor.

20. The system of any one of claims 17‐19, wherein the controller is further configured to  control the network device based on the sampled actions implemented on the system  model.

Images