SYSTEM AND METHOD FOR ASSESSING SYSTEM OF SYSTEMS FOR CYBER VULNERABILITY

Abstract

The present disclosure relates to an assessment of a system of systems (SoS) architecture for cyber vulnerabilities. In one example, architecture description data and component description data for the SoS are received. Architecture definition file (ADF) data is generated based on the architecture description data and the component description data. A model of a target SoS architecture for the SoS is generated based on the ADF data. A target SoS architecture of the SoS is assessed to identify potential cyber attack vectors for the target SoS architecture, and a probabilistic analysis of the potential cyber attack vectors is performed to calculate a probability for each cyber attack vector that indicates the likelihood that the respective cyber attack will cause a mission failure by the SoS based on the target SoS architecture. Display data including each identified potential cyber attack vector and an associated calculated probability is generated for visualization on an output device.

Description

[Technical field]

[0001] The present disclosure relates to system-of-systems (SoS) architectures, and more particularly, to evaluating SoS architectures for cyber vulnerability. [Background technology]

[0002] An SoS is a collection of systems capable of independent operation that interoperate together to achieve additional desired capabilities. A key part of systems engineering for an SoS is the configuration of systems to meet the needs of the SoS. This can involve simply interfacing with the systems and leveraging their existing capabilities, or it may require changing system capabilities, capabilities, or interfaces. These changes occur incrementally, and the SoS can evolve over time to meet the changing SoS objectives. System of systems engineering supports these changes by developing and evolving a technical framework that serves as an overlay for the systems that make up the SoS. This framework provides the architecture for the SoS. The SoS architecture defines how the systems work together to meet the SoS objectives, taking into account the details of the individual systems and their impact on the performance or capabilities of the SoS. Summary of the Invention

[0003] The present disclosure relates to the analysis of SoS architectures with respect to cyber vulnerabilities. In one example, a computer-implemented method may include receiving architecture description data and component description data for the SoS; generating architecture definition file (ADF) data based on the architecture description data and the component description data; generating a model of a target SoS architecture for the SoS based on the ADF data; evaluating the target SoS architecture for the SoS to identify one or more potential cyber-attack vectors for the target SoS architecture; performing a probabilistic analysis of the potential cyber-attack vectors to calculate a probability for each cyber-attack vector indicative of a likelihood that a respective cyber-attack will cause a mission failure by an SoS based on the target SoS architecture; and generating output graphical user interface (GUI) display data for visualization on an output device, the GUI display data including each identified potential cyber-attack vector and an associated calculated probability.

[0004] In yet another example, the system may include a memory for storing machine-readable instructions. The system may include one or more processors for accessing the memory and executing the machine-readable instructions. The machine-readable instructions may include a vulnerability analyzer that may include an ADF parser, an attack vector identifier, and an attack vector analyzer. The ADF parser may be programmed to generate a model of a target SoS architecture for the SoS based on the ADF data. The attack vector identifier may be programmed to evaluate the target SoS architecture for the SoS to identify one or more potential cyber-attack vectors for the target SoS architecture. The attack vector analyzer may be programmed to perform a probabilistic analysis of the potential cyber-attack vectors to calculate a probability for each cyber-attack vector indicating a likelihood that the respective cyber-attack will cause a mission failure by the SoS based on the target SoS architecture. By updating the target SoS architecture for the SoS based on an associated calculated probability for the at least one identified potential cyber-attack vector, the at least one identified potential cyber-attack vector may be eliminated such that the SoS implemented based on the updated target SoS architecture has reduced vulnerability to cyber-attacks than the SoS implemented based on the target SoS architecture.

[0005] In a further example, the non-transitory machine-readable medium can include machine-readable instructions including an ADF generator and a vulnerability analyzer. The ADF generator can generate the ADF data based on architecture description data and component description data for the target SoS architecture. The vulnerability analyzer can generate a model of the target SoS architecture for the SoS based on the ADF data, evaluate the target SoS architecture for the SoS to identify one or more potential cyber-attack vectors for the target SoS architecture, and perform a probabilistic analysis of the potential cyber-attack vectors to calculate a probability for each cyber-attack vector indicating the likelihood that a respective cyber-attack will cause a mission failure by an SoS based on the target SoS architecture. The vulnerability analyzer can further rank-order each calculated probability for each cyber-attack vector to generate a rank-ordered list for identifying given cyber-attack vectors that are most likely to cause an SoS implemented based on the target SoS to fail to meet its objective. [Brief description of the drawings]

[0006] [Figure 1] FIG. 1 illustrates an example system for analyzing SoS architectures for cyber-attack vulnerabilities. [Diagram 2] FIG. 1 illustrates an example vulnerability analyzer. [Diagram 3] FIG. 2 illustrates a model of an example of a target SoS architecture. [Figure 4] FIG. 2 illustrates a model of an example of the internal topology of constituent components of a target SoS architecture. [Diagram 5] FIG. 2 illustrates another model of an example of a target SoS architecture. [Figure 6] FIG. 1 illustrates a model of an example of a multi-domain target SoS architecture. [Figure 7] FIG. 13 is a diagram showing a cyber attack vulnerability summary table. [Figure 8] FIG. 13 illustrates an example partial component description table. [Figure 9] FIG. 1 illustrates a model of an example of a multi-domain communication architecture. [Figure 10] FIG. 2 illustrates another model of an example multi-domain communication architecture. [Figure 11] FIG. 1 is a diagram showing an example Failure Mode Effects Analysis (FMEA) table. [Figure 12] FIG. 1 illustrates an exemplary method for analyzing cyber vulnerabilities of an SoS based on a target SoS architecture. [Figure 13] FIG. 1 illustrates an example computing system that can be used to perform an analysis of a target SoS architecture for cyber-attack vulnerability. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0007] Current approaches for analyzing cyber vulnerabilities of SoS architectures with respect to SoS are ad-hoc. For example, in communication system development, which is a type of SoS architecture, existing approaches rely on internal domain experts and employ rule-based heuristics such as minimizing the number of communication links and minimizing the number of message hops between senders and receivers. These heuristic methods do not attempt to identify possible or potential cyber attack vectors or to quantify the severity of cyber vulnerabilities of the target SoS architecture with respect to SoS. As used herein, the term "cyber attack vector" and its derivatives may refer to one or more attack paths through the SoS. A cyber attack vector may identify an entry point of the SoS that can be exploited (e.g., by an external system or an unwanted user such as a hacker) to gain unauthorized access to the SoS. An entry point may be, for example, a system, component, or subsystem of the SoS. Cyber ​​attack vectors may further identify paths through the SoS and, in some cases, to critical systems, components, and / or subsystems of the SoS that, if compromised, would disrupt or undermine the mission of the SoS.

[0008] Examples described herein enable the analysis of an SoS architecture for an SoS to identify potential cyber attack vectors in the SoS based on the SoS architecture and quantification of cyber SoS vulnerabilities. Metric-based analysis as described herein may be used to calculate the likelihood of a successful cyber attack and, in some cases, the likelihood of mission success or failure of an SoS based on the SoS architecture for each potential cyber attack vector. For example, if the SoS is a communication system, the purpose or mission of the communication system is to enable communication between one or more various devices, vehicles (e.g., aircraft or ground vehicles), satellites, etc. that rely on the communication system to exchange data, information, etc.

[0009] The metric-based analysis described herein can enable a comparison of the robustness of one SoS architecture to another SoS architecture, enable identification of a more secure SoS architecture for the SoS, and enable identification of a relative measure of how much more secure one alternative SoS architecture is than another. Thus, the systems and methods described herein enable identification and implementation of alternative, more secure SoS architectures for the SoS that may not be identified by a user (e.g., a systems engineer) during the design phase of the SoS. Thus, a desired amount of cyber-attack robustness is weighed against the cost of designing a more robust target SoS architecture for the SoS according to the systems and methods described herein.

[0010] Further, in some cases, the systems and methods described herein may include a rank ordering of all potential cyber attack vectors for the SoS such that prioritized SoS architecture decisions can be made (e.g., by another system or a user). Prioritization may include determining a priority for addressing each potential cyber vulnerability for the SoS, and in some cases, determining whether the cyber vulnerability should be addressed by an architectural change or managed as a risk (e.g., in the field using real-time security monitoring software such as cyber attack monitoring software once the SoS is deployed based on the SoS architecture).

[0011] Thus, in some cases, potential cyber vulnerabilities of an SoS may be identified by the systems and methods described herein at the SoS design stage, eliminating the need for cyber attack monitoring tools or software for the SoS system or system components, or reducing the number of cyber threats to the SoS during deployment. Potential cyber vulnerabilities identified according to the systems and methods described herein may be mitigated by a user at the SoS design stage based on data provided according to the examples described herein. Furthermore, data generated according to the systems and methods described herein may be used to design a real-time cyber attack monitoring system for a SoS system based on an SoS architecture.

[0012] According to the systems and methods described herein, a data structure may be generated that allows a vulnerability analyzer to identify potential cyber attack vectors that may result in a SoS based on a target SoS architecture failing to achieve a targeted objective. In some instances, the targeted objective is a mission, and thus the potential cyber attack vectors may result in a SoS based on a target SoS architecture failing the mission. The vulnerability analyzer may analyze the target SoS architecture for the SoS to calculate a probabilistic vulnerability model for cyber vulnerabilities of the target SoS architecture. The probabilistic vulnerability model may be generated to enable a comparison of the robustness of one target SoS architecture to another target SoS architecture (e.g., for identifying a more secure target SoS architecture) and a relative measure of how much more secure one alternative target SoS architecture is than another alternative target SoS architecture.

[0013] For example, the ADF generator may generate ADF data based on architecture description data and component description data for the target SoS architecture. The ADF data may include identification of all component systems of the target SoS architecture, connectivity between the component systems, and connectivity of internal elements of each component system, such as component subsystems. In some cases, not all component subsystems of the target SoS architecture need to be specified at the same level of detail. Such a multi-level fidelity definition scheme allows for analysis of specific parts of the target SoS architecture where parts of the target SoS architecture have not yet been defined. Thus, a focused analysis of specific threats to an SoS based on the target SoS architecture may be conducted without requiring the user to define the entire target SoS architecture in detail. Defining the entire target SoS architecture in detail may be very large and complex, and large parts of the target SoS architecture may be of little relevance to a component analysis of potential cyber attack vulnerabilities.

[0014] In addition to the connectivity information, the ADF data may describe one or more mission-critical subsystems and their respective failure modes in the target SoS architecture. A subsystem in the target SoS architecture may be referred to as a mission-critical subsystem if a failure of such subsystem causes a mission failure of the SoS based on the target SoS architecture. A mission failure is a type of failure that inhibits, impedes, or prevents the SoS from performing its intended purpose in a SoS based on the target SoS architecture, for example, consider a target SoS architecture that performs inventory management and order processing for products that are produced, stored, and distributed worldwide (i.e., the architecture's mission). Consider this target SoS architecture also having a globally distributed network of message processors that route all message traffic for the architecture worldwide. If this network of message processors is compromised by a cyber attack and can no longer relay messages within the target SoS architecture, the architecture will cease to function. The cessation of functioning of the target SoS architecture is considered a mission failure, and the network of message processors is considered a critical mission subsystem.

[0015] In some cases, the ADF data can describe a combination of multiple mission-critical subsystems and their respective failure modes. Failure modes of one or more mission-critical subsystems can be identified during compilation of the architecture description data and the component description data and automatically encoded by the ADF generator into the internal failure model data structure. The failure mode data can be captured, for example, in an FMEA table (or another format), which can be populated by the ADF generator and automatically encoded into the internal failure model data structure for use by the vulnerability analyzer. In some cases, if cost data (absolute or relative) is available for components of the system, the cost data can be included in the ADF data as part of the definition of each component enabling cost trade-off analysis.

[0016] As used herein, the term "target SoS architecture" is used to identify an SoS architecture for an SoS (e.g., a communication system) to be analyzed by the systems and methods described herein. During vulnerability analysis, one may choose to investigate the impact of changes to the target architecture in the search for improved robustness. These changes to the target architecture are referred to as the target SoS architecture for the SoS variant or updated SoS. In some cases, the target SoS architecture may be a collection of multiple component systems, each built by a different vendor, performing different mission functions, achieving different goals, and having different interfaces. As a whole, the target SoS architecture may exhibit desired emergent behavior that cannot be achieved by the individual component systems alone. In some examples, the systems and methods used herein may be used on a single system composed of multiple subsystems, each contributing to the functionality of the system. The concepts of vulnerability analysis described herein apply equally to the analysis of single system architectures as well as target SoS architectures. Additionally, the systems and methods described herein may be used for any type of software architecture, from high-level SoS architectures to circuits or computer programs. For example, a system composed of multiple subcomponents, each of which contributes to the overall functionality of the system, may be considered a target architecture for vulnerability analysis according to the systems and methods described herein.

[0017] FIG. 1 illustrates an example system 100 for analyzing a target SoS architecture for a SoS for cyber-attack vulnerabilities. The system 100 can evaluate the target SoS architecture to identify potential cyber-vulnerabilities in the SoS architecture, and thus identify an SoS based on such architecture, and in some cases, identify the level of threat that such vulnerabilities pose to the SoS (e.g., whether the cyber threats cause objective failures). The target SoS architecture for the SoS can be updated to mitigate the cyber threats to provide an updated SoS architecture for the SoS based on the cyber-threat vulnerabilities identified by the system 100. Thus, the SoS implemented based on the updated SoS architecture can reduce the number of cyber vulnerabilities compared to the SoS based on the target SoS architecture. Thus, the system 100 can be used to improve the overall performance of the SoS, for example, by reducing cyber vulnerabilities in the SoS and / or reducing or eliminating cyber-attack monitoring tools or software.

[0018] The system 100 includes a computing platform 102. The computing platform 102 may include a memory 104 for storing machine-readable instructions and data, and a processing unit 106 for accessing the memory 104 and executing the machine-readable instructions. The memory 104 represents a non-transitory machine-readable memory (or other medium), such as a random access memory (RAM), a solid-state drive, a hard disk drive, or a combination thereof. The processing unit 104 may be implemented as one or more processor cores. The computing platform may include an output device 108 (e.g., a display) for rendering graphical user interface (GUI) data, as described herein. The computing platform 102 may be implemented within a computing cloud. In such a situation, the functionality of the computing platform 102, such as the processing unit 106 and the memory 104, may represent a single instance of hardware, or may represent multiple instances of hardware where an application runs across multiple (e.g., distributed) instances of hardware (e.g., computers, routers, memories, processors, or combinations thereof). Alternatively, the computing platform 102 may be implemented on a single dedicated server or workstation.

[0019] The processing unit 106 can access the memory 104 to execute an architecture definition file (ADF) generator 108, a vulnerability analyzer 110, and a GUI generator 112. The ADF generator 108 can be programmed to provide ADF data 114. The ADF data 114 can characterize or describe a target SoS architecture. For example, the ADF data 114 can include a target architecture definition and a constituent component definition. The ADF data 114 can have a data format such that the ADF data 114 can be ingested (e.g., processed) by the vulnerability analyzer 110. Because an SoS architecture is characterized from one or more viewpoints in various formats with information distributed among multiple SoS architectures, the ADF generator 108 can be programmed to compile data (e.g., architecture description data 116 and / or component description data 118) into a common format for processing by the vulnerability analyzer 110, as described herein.

[0020] For example, the ADF generator 108 may be programmed to receive the target architecture description data 116 and the component description data 118. The target architecture description data 116 may characterize the constituent component list and the component connectivity. The component description data 118 may characterize the components of the target SoS architecture. For example, the component description data 118 may characterize the role or function of the components, the functional description of the subsystems, the internal connectivity of the subsystems, and identify the cost of the mission-critical subsystems and / or components (e.g., the total cost of the components or the cost of the individual subsystems). The ADF generator 108 may be programmed to provide the ADF data 114 based on the architecture description data 116 and the component description data 118. As an example, the architecture description data 116 and the component description data 118 may be generated based on user input at the input device 120. If cost data (absolute or relative) is available for the components of the system of the target SoS architecture, the cost data may be included in the ADF data 114 as part of the definition of each component. In some examples, the ADF data 114 may describe at least one target SoS architecture and at least one mission-critical subsystem defined from information about the target SoS architecture.

[0021] In some instances, the ADF data 114 may characterize a combination of multiple mission-critical subsystems and their respective failure modes. The failure modes of one or more mission-critical subsystems may be identified during compilation of the architecture description data 116 and the component description data 118 (e.g., based on user input at the input device 120) and encoded into a failure model data structure by the ADF generator 108. The failure model data may be captured in an FMEA format, which may be captured by the ADF generator 108 and encoded into the failure model data structure for use by the vulnerability analyzer 110.

[0022] The vulnerability analyzer 110 may be programmed to model a target SoS architecture and apply vulnerability analysis techniques to the modeled target SoS architecture to identify potential cyber vulnerabilities in the target SoS architecture. The vulnerability analyzer 110 may output vulnerability analysis data 122 based on the vulnerability analysis techniques. The vulnerability analysis data 122 may characterize potential cyber-attack vectors and a probability of a mission failure of an SoS based on the target SoS architecture due to such cyber-attacks. The vulnerability analysis data 122 may be provided to a GUI generator 112, which may be programmed to generate GUI display data 124 as described herein. The GUI display data 124 may be rendered on an output device 126 (e.g., a display). The GUI generator 112 may be programmed to provide an interactive user interface for visualizing the cyber-attack vectors and a probability of a mission failure of an SoS based on the target SoS architecture due to such cyber-attacks.

[0023] The GUI generator 112 may be programmed to provide GUI display data 124 that can be rendered as interactive graphics on the output device 126. For example, the GUI generator 112 may be programmed to generate GUI elements (e.g., checkboxes, radio buttons, sliding scales, etc.) that a user can use to visualize a target SoS architecture and cyber attack vectors for the target SoS architecture on the output device 126. In some examples, the GUI generator 112 may employ visualization and decision support 128 for user inspection of the target SoS architecture's topology and attack vector vulnerabilities. The GUI generator 112 may include interactive analysis tools 130 that enable exploration of cyber vulnerabilities versus architecture variants in a search for cyber robustness. The interactive analysis tools 130 may include cost-based visualizations that enable identification of a Pareto Frontier for selection of cost-effective SoS architecture variants when optional cost information is provided as part of the ADF data 114.

[0024] FIG. 2 illustrates an example vulnerability analyzer 200. The vulnerability analyzer 200 may be the vulnerability analyzer 110 as shown in FIG. 1. Accordingly, in some examples, reference is made to FIG. 1 in the example of FIG. 2. The vulnerability analyzer 200 may be programmed to receive ADF data 202, which may be the ADF data 114 as shown in FIG. 1. The vulnerability analyzer 200 may employ an ADF parser 204. The ADF parser 204 may be programmed to process the ADF data 202 to build internal data structures that model the architecture topology and constituent components. The internal data structures may include a data structure of the target SoS architecture topology and a data structure of the constituent components.

[0025] The ADF parser 204 may be programmed to map the target architecture definition in the ADF data 202 to a data structure that models the topology of the target SoS architecture to the level of detail specified in the ADF data 202. The ADF parser 204 may be programmed to map the mission-critical subsystems to the failure model data structure. For example, the ADF parser 204 may be programmed to parse the ADF data 202 to generate an architecture topology data structure that establishes a topology model of the target SoS architecture and to parse the identified mission-critical subsystems to generate a failure model data structure. The GUI generator 112 may be employed to display on the output device 126 a visualization of the architecture topology modeled in the architecture topology data structure along with the identified mission-critical subsystems modeled in the failure model data structure. The GUI generator 112 enables visualization of the defined architecture and its defined mission-critical subsystems as well as providing interactive tools for what-if type evaluation of alternative architectures for interactive exploration of the architecture trade space and associated cyber vulnerabilities. This exploratory approach to analyzing cyber vulnerabilities of an architecture enables users to efficiently conduct trade-off analysis and identify a desired architecture from a set of variants for implementation before making significant investments in developing the architecture.

[0026] The vulnerability analyzer 200 may employ an attack vector identifier 206 to process the internal data structure to identify potential cyber attack vectors that may cause system degradation of the SoS based on the target SoS architecture, system failure of the SoS, or mission failure of the SoS. For example, the vulnerability analyzer 200 may identify potential cyber attack vectors that may cause a constituent component, subsystem, or a particular combination of constituent components and subsystems to deviate from normal operation during deployment of the SoS based on the target SoS architecture to an extent (e.g., a level) that causes the SoS to be throttled or unable to complete its objective (e.g., mission). The attack vector identifier 206 may be programmed to identify potential cyber attack vectors given a definition of the architecture topology and its identified mission-critical subsystems. The attack vector identifier 206 may be programmed to add the identified potential cyber attack vectors to a data structure of failure models that establish mission-critical failure modes.

[0027] In one example, the attack vector identifier 206 may be programmed to identify a single path or paths (in some cases, all paths) of a fixed number of events. An event may correspond to a single action, such as an attack moving from one component to the next, or an attack compromising a current internal component. The resulting potential cyber attack vectors may include a list of events that may occur as the attack passes through the target SoS architecture. In some examples, the attack vector identifier 206 may be programmed to randomly identify potential cyber attack vectors without the limitation of a fixed number of events. In this way, the attack vector identifier 206 may be programmed to discover potential cyber attacks over time that may be difficult to discover through an exhaustive search. In a further example, the attack vector identifier 206 may be programmed to calculate an event probability for each event. The event probability may represent the likelihood that a given event will occur. The event probability may be used to identify potential cyber attacks that are more likely to occur than others.

[0028] The vulnerability analyzer 200 can include an attack vector analyzer 208. The attack vector analyzer 208 can be programmed to perform a probabilistic analysis of potential cyber-attack vectors to calculate vulnerability analysis data 210. The potential cyber-attack vectors can be provided as part of the vulnerability analysis data 210. In some examples, the vulnerability analyzer 200 can output the vulnerability analysis data 210 in a data format that can be ingested by a third-party software application for other types of analysis. The vulnerability analysis data 210 can be the vulnerability analysis data 122 as shown in FIG. 1. The attack vector analyzer 208 can be programmed to simulate the potential cyber-attack vectors to calculate probabilistic cyber-attack performance metrics that can be characterized by the vulnerability analysis data 210. The attack vector analyzer 208 can perform probabilistic analysis, such as using the probabilistic performance metrics to determine the likelihood of success of each potential cyber-attack vector and / or the likelihood of mission failure of the SoS based on the target SoS architecture. The probabilistic cyber-attack performance metrics may be visualized on the output device 126 (e.g., via the GUI generator 112) to enable analysis of alternative SoS architectures for the SoS, as well as output in computer-readable format for ingestion and processing by other computer analysis application software.

[0029] In some examples, the attack vector analyzer 208 may be programmed to rank-order each calculated probabilistic cyber-attack performance metric to provide a critical cyber-attack vulnerability ranking for the target SoS architecture. The results of the cyber-attack vulnerability ranking may be output as part of the vulnerability analysis data 210, in some cases in a computer-readable format for ingestion and processing by other computer application programs and visualization on the output device 126. A priority scheme for addressing each vulnerability identified by the vulnerability analyzer is determined, whether a potential cyber vulnerability requires an architecture change through vulnerability assessment or the potential cyber vulnerability can be managed as a risk to the target SoS architecture, if the potential cyber vulnerability cannot be managed as a risk to the target SoS architecture, whether real-time intrusion monitoring is required and what the monitoring should detect, and if optional cost data (absolute or relative) for components of the target SoS architecture is available, a trade-off between the threat posed by the cyber vulnerability and the cost of modifying the architecture to mitigate the vulnerability is visually determined.

[0030] As a further example, the attack vector analyzer 208 may be programmed to simulate attacks by applying probabilities to identified potential cyber attack vectors. Each potential cyber attack vector is composed of a sequence of events, each of which may have a probability of occurrence. In one example, the probabilities may be assigned by a user (e.g., via the input device 120 as shown in FIG. 1) or may be loaded from a database of probabilities compiled from other vulnerability analyses. The probability that a given component of the target SoS architecture is compromised may be greater due to known defects in that component. In another example, the probabilities may be assigned by the vulnerability analyzer 20 via a random distribution, which may be useful for components with incomplete data.

[0031] In one example, the attack vector analyzer 208 may be programmed to perform a probabilistic analysis using a computational algorithm such as a Monte Carlo algorithm (e.g., a simulation algorithm). In another example, the attack vector analyzer 208 may be programmed to perform a probabilistic analysis using an artificial intelligence (AI) algorithm such as a rule-based expert system, neural network, or machine learning to evaluate potential cyber attack vectors. In a further example, the attack vector analyzer 208 may be programmed to employ a combination of analysis techniques along with decision logic that selects the best result or fuses multiple results together into a single improved result (e.g., a probability). Thus, in some instances, the attack vector analyzer 208 may be programmed to determine a probability of each cyber attack vector that indicates the likelihood that a respective cyber attack against a SoS based on the target SoS architecture will result in a mission failure by the SoS or that a system or subsystem will be compromised beyond an acceptable level.

[0032] While the vulnerability analysis examples herein use Monte Carlo probabilistic analysis techniques, the systems and methods described herein are not dependent on the particular embodiment of the analysis used, but only on the analysis producing probabilistically quantified results. Thus, the systems and methods described herein may utilize any analysis technique for calculating vulnerability probabilities, including AI techniques as described herein. Furthermore, the examples described herein should not be construed and / or limited to only the analysis of communication systems based on the target SoS architecture. The systems and methods described herein may be used for cyber vulnerability analysis of intended target SoS architectures for implementing said systems in military systems, commercial systems, consumer internet systems, business-to-business systems, and intra-enterprise systems.

[0033] FIG. 3 illustrates an example model of a target SoS architecture 300 for an SoS that may be generated by the vulnerability analyzer 110 as shown in FIG. 1 or the vulnerability analyzer 200 as shown in FIG. 2. Accordingly, in some examples, reference is made to FIGS. 1-2 in the example of FIG. 3. The target SoS architecture 300 may be generated by the vulnerability analyzer 110 or 200 based on the ADF data 114 as shown in FIG. 1 or the ADF data 202 as shown in FIG. 2. The target SoS architecture 300 may be provided to the GUI generator 112 for rendering on the output device 126 as shown in FIG. 1. In some examples, the target SoS architecture 300 is provided as part of the vulnerability analysis data 122 as shown in FIG. 1 or the vulnerability analysis data 210 as shown in FIG. 2. The ADF parser 204 may be programmed to generate the target SoS architecture 300 based on the ADF data 202 or 114.

[0034] For example, the ADF data 114 or the ADF data 202 may include a target architecture definition and a constituent component definition. The target architecture definition may include a constituent component list and a component connectivity (e.g., topology) description. The constituent component list may define the components of the target SoS architecture. In the example of FIG. 3, the target SoS architecture 300 generated by the ADF parser 204 may include four constituent components A, B, C, and D. The ADP file data 202 or 114 may include a connectivity description that defines how the constituent components are connected. In the example of FIG. 3, the connectivity description may indicate that constituent component A connects to constituent component B, constituent component B connects to constituent component C, and constituent component D connects to constituent component D.

[0035] As a further example, the constituent component definitions of the ADF data 114 or 202 may define (e.g., functions, characteristics, etc.) of each of the constituent components of the target SoS architecture 300 at a component abstraction level. The constituent component definitions may include a component role or a component functional description, a subsystem list, a subsystem functional description, the subsystem internal connectivity (e.g., topology), a mission-critical subsystem list (e.g., subsystems that will cause a mission failure if a failure occurs), and / or component cost and subsystem cost data. The component role or functional description may be a concise textual description of the component for context identification within the target SoS architecture 300. The subsystem list may define multiple subsystems of the component in a list that may be ordered based on an ordering criterion. In some examples, not all subsystems of the component need to be identified in the subsystem list, only those subsystems to be analyzed are identified. The subsystem functional description may be a textual description of the subsystem for identification in the target SoS architecture. The subsystem internal connectivity may be a description of the connectivity of each subsystem within the component. The mission-critical subsystem list may identify subsystems and / or specific combinations of subsystems that may cause a mission failure if compromised.

[0036] The component cost data of the constituent components can represent absolute cost data (e.g., in fiat or crypto currency) or relative cost data. The relative cost data can be given with respect to a base component having a defined value of 1.0. All other components of the target SoS architecture can be evaluated as fractional multiples of the base component. For example, constituent component A can be defined as a base component with a cost of (A) equal to 1.0. All other constituent components can be evaluated with respect to the cost (or relative complexity as a cost proxy) of constituent component A, given a given value of [XY], where X is an integer multiplier of the base value of constituent component A and Y is a decimal multiplier. In this example, a relative cost of constituent component B equal to 1.5 indicates that constituent component B is 50% more costly (or 50% more complex) than constituent component A. Relative costs make it possible to perform a cost-benefit analysis when absolute costs are not known. If any cost data (absolute or relative) is available, the vulnerability analyzer 200 or 110 can be programmed to perform a cost-benefit analysis for the target SoS architecture. The results of the cost-benefit analysis may be provided as part of the vulnerability analysis data 122 or 210.

[0037] FIG. 4 illustrates a model of an example of an internal topology 400 of a constituent component 400 of a target SoS architecture, such as the target SoS architecture 300 shown in FIG. 3. The constituent component 400 may be constituent component C or D as shown in FIG. 3. Thus, in some examples, refer to FIGS. 1-3 in the example of FIG. 4. In the example of FIG. 4, the constituent component 400 has three subsystems b1, b2, and b3, but in other examples, the constituent component 400 may have more or less than three subsystems. The constituent component 400 of the target SoS architecture 300 may be generated by the vulnerability analyzer 110 or 200 based on the constituent component definition in the ADF data 114 or 202. In the example of FIG. 4, the subsystem b1 may have a connection 404 to an external component, such as constituent component B as shown in FIG. 3.

[0038] Subsystem b1 can be connected to subsystem b2 and can be connected to subsystem b3. As described herein, the mission-critical subsystem list can identify subsystems and / or particular combinations of subsystems that can cause a mission failure if compromised. In the example of FIG. 4, subsystem b3 is identified as a critical system that can cause a mission failure if compromised. Subsystem b3 at 406 is identified as a critical system. In some examples, subsystems b2 and b3 can be a combination of critical subsystems that both need to be compromised for a mission to fail. In these examples, the mission-critical subsystem list can indicate that subsystems b2 and b3 are critical subsystems. As described, the target SoS architecture 300 can be provided to the GUI generator 112 for rendering on the output device 126, as shown in FIG. 1. The internal topology 400 of the constituent components 400 can be rendered on the output device 126 and visually highlighted using the visualization and decision support 128, such as via color or other graphical indicators. For example, subsystem b3 may be bolded at 406 in a rendering of the internal topology 400 on the output device 126 to indicate that subsystem b3 is a critical system, as shown in FIG.

[0039] FIG. 5 illustrates a model of an example of a target SoS architecture 500 with identified potential cyber vulnerability vectors. The target SoS architecture 500 may be generated by a vulnerability analyzer 110 as shown in FIG. 1 or a vulnerability analyzer 200 as shown in FIG. 2. In some examples, the target SoS architecture 500 corresponds to the target SoS architecture 300 as shown in FIG. 3. Thus, in some examples, refer to FIGS. 1-4 in the example of FIG. 5. The target SoS architecture 500 includes a constituent component A and a constituent component B. The constituent component A connects to the constituent component B via a subsystem b1 of the constituent component B. The subsystem b1 also connects to constituent components C and D of the target SoS architecture 500. Within the constituent component B, the subsystem b1 connects to subsystems b2 and b3. The subsystem b3 is identified in 502 as a mission-critical subsystem, and a failure of this subsystem may cause a mission failure of the SoS. For the methodology used by the system 100, it is not necessary that all constituent components and / or subsystems be defined to the same level of detail. The input device 120 can receive user data identifying the constituent components, component subsystems, connectivity (topology), and mission-critical subsystems of the target architecture, and / or a combination of these can be obtained from architecture documentation or interviews with individual designers.

[0040] As an example, the vulnerability analyzer 110 or 200 may evaluate the target SoS architecture 500 to identify one or more potential cyber attack vectors that may cause a mission failure of the SoS if implemented based on the target SoS architecture in the same or similar manner as described herein. With respect to the example of FIG. 5, the attack vector identifier 206 has identified three potential cyber attack vectors 504, 506, and 508. The first potential cyber attack vector 504 identifies a potential attack path that starts from compromising a constituent component A, leads to compromising a subsystem b1, and ends with compromising a subsystem b3. The second potential cyber attack vector 506 identifies a potential attack path that starts from compromising a constituent component C, leads to compromising a subsystem b1, and ends with compromising a subsystem b3. The third potential cyber attack vector 508 identifies a potential attack path that starts from compromising a constituent component D, leads to compromising a subsystem b1, and ends with compromising a subsystem b3.

[0041] The attack vector analyzer 208 may be programmed to calculate, for each identified potential cyber attack vector 504, 506, and 508, a probability that the given identified potential cyber attack vector will actually cause a mission failure of the SoS based on the target SoS architecture 500. In some examples, the probability may be referred to as a mission failure rate of the SoS when implemented based on the target SoS architecture 500. For example, the attack vector analyzer 208 may be programmed to analyze the identified potential cyber attack vectors 504, 506, and 508 using a Monte Carlo analysis or another type of computational algorithm to estimate a resulting failure rate (e.g., a probability of mission failure by the SoS based on the target SoS architecture 500). Thus, in some instances, the attack vector analyzer 208 may be programmed to provide a probability indicative of the likelihood that a cyber attack along a corresponding attack path, once compromised, will succeed in reaching a critical system causing an objective failure of the SoS.

[0042] In some examples, the attack vector analyzer 208 may be programmed to determine the amount of tolerable probability of failure for the target SoS architecture, taking into account the cost of failure in terms of fiat currency or human life. For example, the attack vector analyzer 208 may be programmed to identify a particular potential cyber attack vector 504, 506, and 508 that has the highest probability among the potential cyber attack vectors 504, 506, and 508. In other examples, the attack vector analyzer 140 may be programmed to identify a particular potential cyber attack vector 504, 508, and 508 by comparing each probability for each potential cyber attack vector 504, 506 to a vulnerability threshold. A potential cyber attack vector 504, 506, or 508 that has a probability equal to or greater than the vulnerability threshold may be identified by the attack vector analyzer 208 as a particular potential cyber attack vector (e.g., as part of the vulnerability analysis data 122 as shown in FIG. 1 or the vulnerability analysis data 208 as shown in FIG. 2).

[0043] 5, the attack vector analyzer 208 determines that the potential cyber attack vector 504 has an estimated mission failure rate of 3%, the potential cyber attack vector 506 has an estimated mission failure rate of 7%, and the potential cyber attack vector 508 has an estimated mission failure rate of 90%. Because the potential cyber attack vector 508 has the greatest estimated mission failure rate compared to the potential cyber attack vectors 504 and 506, the attack vector analyzer 208 may indicate in the vulnerability analysis data 122 or 208 that the potential cyber attack vector 508 has the most significant vulnerability impact on the SoS based on the target SoS architecture. The vulnerability analysis data 122 or 208 may be rendered on the output device 126 by the GUI generator 112 as described herein.

[0044] In some examples, the attack vector analyzer 208 may be programmed to group the identified potential cyber-attack vectors into respective categories based on a cyber-attack vector grouping criterion. For example, the cyber-attack vector grouping criterion may indicate that potential cyber-attack vectors having respective estimated mission failure rates that are less than or equal to a first estimated mission failure rate threshold should be associated with a first cyber-attack category, and potential cyber-attack vectors having respective estimated mission failure rates that are greater than or equal to the first estimated mission failure rate threshold but less than or equal to a second estimated mission failure rate threshold should be associated with a second cyber-attack category. The cyber-attack vector grouping criterion may indicate that potential cyber-attack vectors having respective estimated mission failure rates that are greater than or equal to the second estimated mission failure rate threshold but less than a third estimated mission failure rate threshold should be associated with a third cyber-attack category. The cyber-attack vector grouping criterion may indicate that potential cyber-attack vectors having respective estimated mission failure rates that are greater than or equal to the third estimated mission failure rate threshold should be associated with a fourth cyber-attack category.

[0045] In some examples, a first cyber-attack category may identify potential cyber-attack vectors that will have little impact on the SoS based on the target SoS architecture 500, a second cyber-attack category may identify potential cyber-attack vectors that can be risk managed by processes and procedures (e.g., cyber-attack monitoring software), a third cyber-attack category may identify potential cyber-attack vectors that can be mitigated or eliminated by one or more minor changes to the target SoS architecture 500, and a fourth cyber-attack category may identify potential cyber-attack vectors that require significant changes to the target SoS architecture 500 for mitigation or elimination. The quantification of minor and significant changes is relative to the target SoS architecture being analyzed, its development timeline, and the expected cost of the changes. For example, a change requiring a 1% increase in cost and / or schedule may be considered minor, while a change requiring a 25% increase in either cost and / or schedule may be considered significant.

[0046] The attack vector analyzer 208 may be programmed to provide potential cyber-attack vector grouping data characterizing cyber-attack categories and groupings of potential cyber-attack vectors as part of the vulnerability analysis data 122 or 208. The GUI generator 112 may render the potential cyber-attack vector grouping data on the output device 126. A user may evaluate the rendered cyber-attack vector grouping data to define or set an acceptable level of vulnerability mitigation for an SoS based on the SoS architecture 500. For example, a user may determine that a potential cyber-attack vector 508 requires mitigation based on the rendered cyber-attack vector grouping data on the output device 126 and update the SoS architecture 500 to eliminate the cyber-attack vector 508.

[0047] FIG. 6 illustrates an example model of a multi-domain target SoS architecture 600 for an SoS. The multi-domain target SoS architecture 600 may be generated by a vulnerability analyzer 110 as shown in FIG. 1 or a vulnerability analyzer 200 as shown in FIG. 2. Accordingly, in some examples, reference is made to FIGS. 1-2 in the example of FIG. 6. For example, the multi-domain target SoS architecture 600 may include a space domain 602 (labeled "SPACE"), an air domain 604 (labeled "AIR"), and a ground domain 606 (labeled "GROUND"). The space domain 602 may include a space component A, the air domain 604 may include an airborne component B, identified at 608 in the example of FIG. 6, and the ground domain 606 may include ground components C and D.

[0048] Space component A may represent a communications satellite, airborne component B may represent a communications repeater, and ground components C and D may represent a fixed site and a mobile unit, respectively. Airborne component B may include three subsystems b1, b2, and b3. Subsystem b1 may represent a camera, subsystem b2 may represent a radio transceiver, and subsystem b3 may represent a communications repeater unit that converts messages from one communications link to another for rebroadcast. The objective or mission of target SoS architecture 600 may be to provide continuous communications connectivity between satellite component A and ground components C and D.

[0049] In the example of FIG. 6, the attack vector analyzer 208 may be programmed to identify one or more potential cyber attack vectors in the multi-domain target SoS architecture 600 for the SoS in the same or similar manner as described herein. Subsystem b3 may be an objectively critical subsystem in the example of FIG. 6. The GUI generator 112 may be programmed to render the target SoS architecture 600 on the output device 126 with subsystem b3 graphically differentiated at 610 from other components and subsystems to indicate that subsystem b3 is a critical subsystem. The target SoS architecture 600 may be rendered on the output device 126 to graphically differentiate at 612 within the target SoS architecture 600 that there is a high probability that a potential cyber attack intrusion through the mobile ground node D would compromise subsystem b3 and thus cause an objective failure (e.g., mission failure). The GUI generator 130 can render the interactive analysis tool 130 on the output device 126, and a user can interact with the interactive analysis tool 130 to display a cyber attack vulnerability summary table 700, as shown in FIG. 7, for the multi-domain target SoS architecture 600 on the output device 126.

[0050] The cyber-attack vulnerability summary table 700 may be generated by the GUI generator 130 based on the vulnerability analysis data 122 or 210 provided by the vulnerability analyzer 110 or 200. The cyber-attack vulnerability summary table 700 may identify potential cyber-attacks that may cause mission failure by the SoS, as well as identify components that were accessed but not compromised or components that were accessed and compromised during a cyber-attack simulation (e.g., by the attack vector analyzer 208 as shown in FIG. 2 ). The cyber-attack vulnerability summary table 700 may further identify communication links traversed during the cyber-attack simulation and the entry points of the cyber-attack into the multi-domain target SoS architecture 600. For example, the cyber attack vulnerability summary table 700 indicates that mobile ground node D is an entry point for a potential cyber attack, that ground component D and airborne component B have been accessed and compromised, that the communication link between ground component D and airborne component B (identified at 614 in FIG. 6 ) has been traversed and thus accessed, and that the communication link between subsystems b1 and b3 (identified at 616 in FIG. 6 ) has been traversed and thus accessed.

[0051] 8 is an example partial component description table 800. The partial component description table 800 may form part of the component description data 118 received by the ADF generator 108, as shown in FIG. 1. Thus, in some examples, reference is made to FIGS. 1-2 in the example of FIG. 8. In the example of FIG. 8, the component description table 800 is organized (e.g., structured) in a tabular format, although in other examples, the component description information in the component description table 800 may be arranged in a different manner. The partial component description table 800 may be provided based on user input at the input device 120, as shown in FIG.

[0052] In the example of FIG. 8, a first column 802 of the partial component description table 800 may identify component systems, such as a ground station, a first and second aircraft, and a first and second satellite. A second column 804 of the partial component description table 800 may identify the role of each component system and the domain to which each component system belongs. For example, as shown in FIG. 8, the domains may include a ground domain, an air domain, and a space domain. The partial component description table 800 includes a third column 806 and a fourth column 808 that may indicate a type of each communication link supported by each component system. For example, a ground station may support a line of sight (LOS) link type and a beyond line of sight (BLOS) link type. A fifth column 810 of the partial component description table 800 may indicate whether each component system has Global Positioning System (GPS) capability and whether each component system uses encrypted or unencrypted GPS signals. For example, the first and second aircraft receive encrypted GPS signals. In some examples, the ADF generator 108 may be programmed to process the component description data 118, including the partial component description table 800, to generate the ADF data 114 as shown in FIG. 1, or the ADF data 202 as shown in FIG.

[0053] As a further example, the vulnerability analyzer 110 or 200 may process the ADF data 114 or 202 to generate a model of a multi-domain communication architecture 900 for the communication system in the same or similar manner as described herein, as shown in Figure 9. The multi-domain communication architecture 900 may be rendered on the output device 126 by the GUI generator 112. The multi-domain communication architecture 900 may indicate types of communication links that may be established between respective component systems of the communication system.

[0054] In the example of FIG. 9, a first BLOS communication link 902 may be established between a first satellite 904 and a first aircraft 906. A second BLOS communication link 908 may be established between a second satellite 910 and a second aircraft 912. A first LOS communication 914 may be established between the first aircraft 906 and a ground station 916. A second LOS communication 918 may be established between the second aircraft 912 and a ground station 916. As shown in multi-domain communications architecture 900, the first satellite 904 and the second satellite 910 are located in the space domain (labeled “Space”), the first aircraft 906 and the second aircraft 912 are located in the air domain (labeled “Air”), and the ground station 916 is located in the ground domain (labeled “Ground”).

[0055] The vulnerability analyzer 110 as shown in FIG. 1 or the vulnerability analyzer 200 as shown in FIG. 2 can evaluate the multi-domain communication architecture 900 to identify potential cyber attack vectors that are most likely to lead to a mission failure in the same or similar manner as described herein. For example, the vulnerability analyzer 110 can be programmed to simulate a cyber attack against a random component system (e.g., ground station 916). The simulated cyber attack can disable a subsystem within the component system being tested. For example, the simulated cyber attack can disable communications between the first aircraft 906 and the ground station 916. The vulnerability analyzer 110 can probabilistically move from component system to component system within the multi-domain communication architecture 900 as well as traverse the communication network during the cyber attack simulation in the same or similar manner as described herein.

[0056] The vulnerability analyzer 110 or 200 may output vulnerability analysis data 122 as shown in FIG. 1 or vulnerability analysis data 210 as shown in FIG. 2 based on the cyber-attack simulation, which indicates the probability that a failure of a given component will result in a mission failure, a mission being impaired, or the probability that a mission can be completed even if a given component is impaired as a result of a cyber-attack. In some examples, the vulnerability analysis data 210 may identify communication paths taken during the simulation, links used, systems and subsystems that were disabled, and mission status (e.g., mission failure, mission impaired, and mission success). The GUI generator 112 may use the vulnerability analysis data 122 or 210 to graphically indicate (e.g., by changing the color or transparency of a component of the multi-domain communication architecture 900) the frequency with which a given component system was impaired or the occurrence of failures during a cyber-attack simulation on the multi-domain communication architecture 900. For example, a component system in the multi-domain communication architecture 900 that was impaired frequently during the cyber-attack simulation may be changed to red to alert a user that the component is vulnerable to a cyber-attack.

[0057] In some examples, the system 100 may compare different target SoS architectures for a target SoS to identify a particular target SoS architecture for the target SoS with the lowest mission failure rate. In some examples, referred to herein as a "given example," the multi-domain communication architecture 900 may be referred to as a first multi-domain communication architecture 900. The system 100 may be employed to generate a model of a second multi-domain communication architecture 1000 for a communication system, as shown in FIG.

[0058] The multi-domain communications architecture 1000 may illustrate types of communications links that may be established between respective component systems of a communications system based on the multi-domain communications architecture 1000. In the example of FIG. 10, a first BLOS communications link 1002 may be established between a first satellite 1004 and a first aircraft 1006. A second BLOS communications link 1008 may be established between a second satellite 1010 and the first aircraft 1006. A first LOS communications link 1012 may be established between the first aircraft 1006 and a second aircraft 1014. A second LOS communications link 1016 may be established between the first aircraft 1006 and a ground station 1018. As shown in multi-domain communications architecture 1000, a first satellite 1004 and a second satellite 1010 are located in the space domain (labeled “Space”), a first aircraft 1014 and a second aircraft 1006 are located in the air domain (labeled “Air”), and a ground station 1018 is located in the ground domain (labeled “Ground”).

[0059] In a given example, the vulnerability analyzer 110 or 200 can simulate a cyber attack for each of the first and second multi-domain communication architectures 900 and 1000 and generate a respective mission failure rate (e.g., as part of the vulnerability analysis data 122 or 210). The respective mission failure rates can be evaluated by a user, or in some cases by the vulnerability analyzer 110 or 200, to identify a particular multi-domain communication architecture for a communication system having the lowest mission failure rate. For example, if the first multi-domain communication architecture 900 has a mission failure rate of 7% and the second multi-domain communication architecture 900 has a mission failure rate of 23%, the vulnerability analyzer 110 or 200 can recommend on the output device 126 (e.g., via the GUI generator 112) the first multi-domain communication architecture 900 for use in implementing the communication system.

[0060] FIG. 11 illustrates an example FMEA table 1100. The FMEA table 1110 indicates types of failures that may result from a cyber attack of individual elements or subsystems of a target SoS architecture, for example, as described herein. Thus, in some examples, reference is made to FIGS. 1-2 in the example of FIG. 11. As described herein, the FMEA table 1100 may be processed by the ADF generator 108 and encoded into a failure model data structure for use by the vulnerability analyzer 110 or 200. In some instances, the failure model data structure may be provided to the vulnerability analyzer 110 or 200 as part of the ADF data 114.

[0061] With the structural and functional features discussed above in mind, the exemplary method may be better understood with reference to Figure 12. For ease of explanation, the exemplary method of Figure 12 is shown and described as being performed sequentially, however, it should be understood and appreciated that the present example is not limited by the order shown, as some operations may be performed multiple times and / or simultaneously in other examples and in different orders than those shown and described herein. Moreover, not all illustrated operations need to be performed to implement the method.

[0062] FIG. 12 illustrates an example method 1200 for analyzing cyber vulnerabilities of an SoS based on a target SoS architecture. The method 1200 may be performed by a vulnerability analyzer 110 as shown in FIG. 1 or a vulnerability analyzer 200 as shown in FIG. 1. In some examples, the target SoS architecture is one of the target SoS architectures described herein. Thus, in some examples, reference is made to FIGS. 1-11 in the example of FIG. 12.

[0063] The method 1200 may begin at 1202 by receiving architecture description data (e.g., architecture description data 116 as shown in FIG. 1 ) and component description data (e.g., component description data 118 as shown in FIG. 1 ). The architecture description data may be defined along with identification of all mission-critical subsystems and / or combinations of subsystems by evaluating architecture documentation and information provided by one or more systems engineers. The component description data may define all constituent components, component subsystems, and topologies. In some examples, the component description data is logically organized in a tabular format. The component description data may include, for example, a partial component description table 800 as shown in FIG. 8 .

[0064] At 1204, ADF data (e.g., ADF data 114 as shown in FIG. 1 or ADF data 202 as shown in FIG. 12) is generated based on the architecture description data and the component description data. The ADF data may be generated by the ADF generator 108 as shown in FIG. 1. For example, the ADF data may be generated to include at least a first and a second data structure. The first data structure may characterize a topology of the target SoS architecture, and the second data structure may characterize each constituent component of the target SoS architecture. At 1206, a model of the target SoS architecture is generated based on the ADF data. The target SoS architecture may be generated by the ADF parser 204 as shown in FIG. 2. At 1208, the target SoS architecture is evaluated to identify one or more potential cyber-attack vectors. At 1210, a probabilistic analysis of the potential cyber-attack vectors is performed to calculate a probability for each cyber-attack vector indicating the likelihood that the respective cyber-attack will cause a mission failure (e.g., mission failure) by an SoS based on the target SoS architecture. At 1212, method 1200 may include outputting GUI display data (e.g., GUI display data 124 as shown in FIG. 1 ) on an output device (e.g., output device 126) to update the target SoS to prevent (e.g., eliminate) the at least one identified potential cyber attack vector.

[0065] Examples herein may be implemented on virtually any type of computing system, regardless of the platform used. For example, the computing system may be one or more mobile devices (e.g., laptop computers, smartphones, personal digital assistants, tablet computers, or other mobile devices), desktop computers, servers, blades in a server chassis, or any other type of computing device that includes at least the minimum processing power, memory, and input and output device(s) to perform one or more embodiments. As shown in FIG. 13, the computing system 1300 may include a computer processor 1302, memory 1304 (e.g., RAM, cache memory, flash memory, etc.), one or more storage devices 1306 (e.g., solid state drives, hard disk drives, optical drives (e.g., compact disc (CD) drives or digital versatile disc (DVD) drives, etc.), flash memory sticks, etc.), and numerous other elements and functionalities. The computer processor 1302 may be an integrated circuit for processing instructions. For example, the computer processor 1302 may be one or more cores or micro-cores of a processor. The components of the computing system 1300 may communicate via a data bus 1308.

[0066] The computing system 1300 may also include input devices 1310, such as any combination of one or more of a touch screen, a keyboard, a mouse, a microphone, a touch pad, an electronic pen, or any other input device. The input devices 812 may be the input devices 120 as shown in FIG. 1. Additionally, the computing system 1300 may include output devices 1312, such as one or more of a screen (e.g., a light emitting diode (LED) display, an organic light emitting diode (OLED) display, a liquid crystal display (LCD), a plasma display, a touch screen, a cathode ray tube (CRT) monitor, a projector, or other display device), a printer, external storage, or any other output device. The output devices 1312 may be the output devices 126 as shown in FIG.

[0067] In some examples, the output device 1312, such as a touch screen, may be the same physical device as the input device 1310. In other examples, the output device 1312 and the input device 1310 may be implemented as separate physical devices. The computing system 1300 may be coupled to a network 1314 (e.g., a local area network (LAN), a wide area network (WAN) such as the Internet, a mobile network, or any other type of network) via a network interface (not shown). The input device 1310 and the output device(s) 1312 may be locally and / or remotely coupled (e.g., via the network 1312) to the computer processor 1302, the memory 1304, and / or the storage device 1306. Many different types of computing systems exist, and the input device 1310 and the output device 1312 may take other forms.

[0068] Software instructions in the form of computer readable program code for implementing the embodiments disclosed herein may be stored, in whole or in part, temporarily or permanently, on a non-transitory computer readable medium, such as a CD, DVD, storage device, diskette, tape, flash memory, physical memory, or any other computer readable storage medium. Specifically, the software instructions may correspond to computer readable program code configured to perform the operations disclosed herein when executed by a processor. The computing system 1300 may communicate with a server 1316 via a network 1314. The memory 1304 may include a number of applications and / or modules that may be used to implement the analysis techniques of the SoS architecture as described herein. More specifically, the memory 1304 may include a vulnerability analyzer 1318 and a GUI generator 1320. The vulnerability analyzer 1318 may be the vulnerability analyzer 110 as shown in FIG. 1 or the vulnerability analyzer 200 as shown in FIG. 2, and the GUI generator 1320 may be the GUI generator 112 as shown in FIG. 1.

[0069] Additionally, one or more elements of the computing system 1300 may be located remotely and coupled to other elements via a network 1314. Additionally, some examples may be implemented on a distributed system having multiple nodes, with portions of the embodiments being located on different nodes in the distributed system. In one example, the nodes in the example of FIG. 13 correspond to separate computing devices. Alternatively, the nodes may correspond to computer processors with associated physical memory. Alternatively, the nodes may correspond to computer processors or micro-cores of computer processors with shared memory and / or resources.

[0070] The above description is an example. Of course, it is not possible to describe every conceivable combination of elements or methods, but one skilled in the art will recognize that many more combinations and permutations are possible. Accordingly, this disclosure is intended to embrace all such changes, modifications, and variations that are within the scope of this application, including the appended claims. As used herein, the term "comprises" means including without limitation. The term "based on" means based at least in part on. Furthermore, when the disclosure or claims recite "a," "first," or "another" element, or equivalents thereof, it should be construed as including one or more of such elements, and does not require or exclude more than one element.

Claims

1. 1. A computer-implemented method comprising: receiving architecture description data and component description data for a system of systems (hereinafter referred to as SoS); generating architecture definition file (hereinafter referred to as ADF) data based on the architecture description data and the component description data; generating a model of a target SoS architecture for the SoS based on the ADF data; assessing the target SoS architecture with respect to the SoS to identify one or more potential cyber attack vectors with respect to the target SoS architecture; performing a probabilistic analysis of the potential cyber-attack vectors to calculate a probability for each cyber-attack vector indicating the likelihood that the respective cyber-attack will cause a mission failure of the SoS based on the target SoS architecture; and generating output graphical user interface (hereinafter GUI) display data for visualization on an output device, the GUI display data including each identified potential cyber-attack vector and an associated calculated probability.

2. 2. The computer-implemented method of claim 1, further comprising: updating the target SoS architecture for the SoS based on the associated calculated probability for at least one identified potential cyber-attack vector, thereby eliminating the at least one identified potential cyber-attack vector, such that the SoS implemented based on the updated target SoS architecture is less vulnerable to cyber-attacks than the SoS implemented based on the target SoS architecture.

3. 3. The computer-implemented method of claim 2, wherein the ADF data describes the target SoS architecture and includes a list of constituent components of the target SoS architecture, connectivity of the constituent components, definitions of the constituent components, internal subsystems, subsystem connectivity, and identification of mission-critical subsystems.

4. The step of generating a model of the target SoS architecture for the SoS comprises: extracting a target architecture definition from the ADF data to generate an architecture topology data structure for establishing a topology model of the target SoS architecture; extracting constituent component definitions from the ADF data to generate a constituent component definition data structure; extracting information identifying mission-critical subsystems and / or combinations of critical subsystems of the SoS defined as mission-critical in the ADF data to generate a failure model data structure; 2. The computer implemented method of claim 1, comprising generating the model of the target SoS architecture based on the architecture topology data structure, the constituent component definition data structure, and the failure model data structure.

5. 5. The computer-implemented method of claim 4, wherein performing a probabilistic analysis of the potential cyber-attack vectors includes simulating the potential cyber-attack vectors via a target SoS for the SoS to calculate a probabilistic cyber-attack performance metric including an associated probability for each potential cyber-attack vector.

6. 6. The computer-implemented method of claim 5, wherein simulating the potential cyber attack vectors via the target SoS with respect to the SoS is performed using a computational algorithm.

7. 6. The computer-implemented method of claim 5, wherein simulating the potential cyber attack vectors via the target SoS with respect to the SoS is performed using an artificial intelligence algorithm.

8. 6. The computer-implemented method of claim 5, further comprising rank-ordering each calculated probability for each cyber-attack vector to generate a rank-ordered list to identify given cyber-attack vectors that are most likely to cause the SoS performed based on the target SoS to fail in its objective.

9. 6. The computer-implemented method of claim 5, further comprising grouping the identified potential cyber-attack vectors into respective categories based on cyber-attack vector grouping criteria.

10. 10. The computer-implemented method of claim 9, wherein the cyber-attack vector grouping criteria includes at least a first cyber-attack category, a second cyber-attack category, and a third cyber-attack category, and each of the identified potential cyber-attack vectors is associated with a respective one of the first, second, and third cyber-attack categories.

11. 10. The computer-implemented method of claim 9, wherein the first cyber-attack category indicates potential cyber-attack vectors that do not affect the SoS when implementing an objective of the SoS based on the target SoS, the second cyber-attack category indicates potential cyber-attack vectors that should be risk-managed by processes and procedures during operation of the SoS based on the target SoS, and the third cyber-attack category identifies potential cyber-attack vectors that should be eliminated by one or more changes to the target SoS architecture that remove each identified potential cyber-attack vector associated with the third cyber-attack category.

12. The model is a first model, the target SoS architecture is a first target SoS architecture for the SoS, the ADF data is first ADF data, and the computer-implemented method includes: generating vulnerability analysis data for the first target SoS architecture, the vulnerability analysis data characterizing the probability for each cyber-attack vector for the first target SoS architecture; receiving additional architecture description data and component description data regarding said SoS; generating second ADF data based on the additional architecture description data and the component description data; generating a second model of a second target SoS architecture for the SoS based on the second ADF data; evaluating the second target SoS architecture with respect to the SoS to identify one or more potential cyber attack vectors with respect to the second target SoS architecture; performing a probabilistic analysis of the potential cyber-attack vectors to calculate a probability for each cyber-attack vector indicating the likelihood that a respective cyber-attack will cause a mission failure of the SoS based on the second target SoS; 12. The computer-implemented method of claim 11, further comprising: generating vulnerability analysis data for the second target SoS architecture that characterizes the probability for each cyber-attack vector for the second target SoS architecture.

13. 13. The computer-implemented method of claim 12, further comprising evaluating the vulnerability analysis data for each of the first target SoS architecture and the second target SoS architecture to identify potential target SoS architectures for the SoS having a lower number of potential cyber-attack vulnerabilities that could cause the SoS to fail in its objectives.

14. 1. A system comprising: a memory for storing machine readable instructions and architecture definition file (ADF) data; and one or more processors for accessing the memory and executing the machine-readable instructions, the machine-readable instructions including a vulnerability analyzer, the vulnerability analyzer comprising: an ADF parser programmed to generate a model of a target SoS architecture for the SoS based on the ADF data; an attack vector identifier programmed to evaluate the target SoS architecture with respect to the SoS to identify one or more potential cyber attack vectors with respect to the target SoS architecture; and an attack vector analyzer programmed to perform a probabilistic analysis of the potential cyber-attack vectors to calculate a probability for each cyber-attack vector indicating the likelihood that a respective cyber-attack will cause a mission failure by the SoS based on the target SoS architecture, wherein at least one identified potential cyber-attack vector is eliminated by updating the target SoS architecture for the SoS based on an associated calculated probability for the at least one identified potential cyber-attack vector, such that the SoS implemented based on the updated target SoS architecture has reduced vulnerability to cyber-attacks than the SoS implemented based on the target SoS architecture.

15. The ADF parser is Extracting a target architecture definition from the ADF data to generate an architecture topology data structure for establishing a topology model of the target SoS architecture; Extracting constituent component definitions from the ADF data to generate a constituent component definition data structure; Extracting information identifying mission-critical subsystems and / or combinations of critical subsystems of the SoS defined as mission-critical in the ADF data to generate a failure model data structure; 15. The system of claim 14, further programmed to generate the model of the target SoS architecture based on the architectural topology data structure, the constituent component definition data structure, and the failure model data structure.

16. 16. The system of claim 15, wherein the attack vector analyzer is programmed to perform a probabilistic analysis of the potential cyber-attacks by simulating the potential cyber-attack vectors via a target SoS for the SoS to calculate a respective probability for each potential cyber-attack vector.

17. 17. The system of claim 16, wherein the attack vector analyzer is programmed to rank-order each calculated probability for each cyber attack vector to generate a rank-ordered list to identify given cyber attack vectors that are most likely to cause the SoS performed based on the target SoS to fail in its objective.

18. A non-transitory machine-readable medium having machine-readable instructions, the machine-readable instructions comprising: an architecture definition file (hereinafter referred to as ADF) generator for generating ADF data based on architecture description data and component description data relating to a target SoS architecture; a vulnerability analyzer, the vulnerability analyzer comprising: generating a model of the target SoS architecture for SoS based on the ADF data; Evaluating the target SoS architecture with respect to the SoS to identify one or more potential cyber attack vectors with respect to the target SoS architecture; performing a probabilistic analysis of the potential cyber-attack vectors to calculate a probability for each cyber-attack vector indicating the likelihood that the respective cyber-attack will cause a mission failure of the SoS based on the target SoS architecture; A non-transitory machine-readable medium for rank-ordering each calculated probability for each cyber-attack vector to generate a rank-ordered list for identifying given cyber-attack vectors that are most likely to cause said SoS, when performed based on a target SoS, to fail to achieve its objective.

19. 20. The non-transitory machine-readable medium of claim 18, wherein a given identified potential cyber-attack vector is eliminated by updating the target SoS architecture for the SoS based on an associated calculated probability for the given identified potential cyber-attack vector, such that a SoS implemented based on the updated target SoS architecture has reduced vulnerability to cyber-attacks than a SoS implemented based on the target SoS architecture.

20. 20. The non-transitory machine-readable medium of claim 18, wherein the machine-readable instructions further include a graphical user interface (GUI) generator for generating GUI display data for visualization on an output device, the GUI display data including each identified potential cyber-attack vector and an associated calculated probability and the rank-ordered list.

Images