SYSTEM AND METHOD FOR ASSESSING A 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 assessing SoS architectures for cyber vulnerabilities. [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 configuring the systems to meet the needs of the SoS. This can involve simply interfacing with systems and leveraging their existing capabilities, or it can require changing system functionality, performance, or interfaces. These changes occur incrementally, and the SoS can evolve over time to meet the changing objectives of the SoS. 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 objectives of the SoS and considers the details of each individual system and its impact on the performance or functionality 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 an 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 indicating the 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, wherein the GUI display data includes 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, which 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 and calculate a probability for each cyber-attack vector indicating the likelihood that the respective cyber-attack will cause a mission failure by an SoS based on the target SoS architecture. Updating the target SoS architecture for the SoS based on the associated calculated probability for the at least one identified potential cyber-attack vector may eliminate the at least one identified potential cyber-attack vector such that an SoS implemented based on the updated target SoS architecture has reduced vulnerability to cyber-attacks compared to an 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 ADF data based on architecture description data and component description data related to the target SoS architecture. The vulnerability analyzer can generate a model of the target SoS architecture related to the SoS based on the ADF data, evaluate the target SoS architecture related to the SoS to identify one or more potential cyber-attack vectors related to 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 the respective cyber-attack will cause a mission failure by an SoS based on the target SoS architecture. The vulnerability analyzer can rank-order each calculated probability for each cyber-attack vector to further generate a rank-ordered list identifying given cyber-attack vectors that are most likely to cause a SoS implemented based on the target SoS to fail to achieve its objective. [Brief explanation of the drawings]

[0006] [Figure 1] FIG. 1 illustrates an example system for analyzing SoS architectures for cyber-attack vulnerabilities. [Figure 2] FIG. 1 illustrates an example vulnerability analyzer. [Figure 3] FIG. 1 illustrates a model of an example of a target SoS architecture. [Figure 4] FIG. 1 illustrates a model of an example of the internal topology of constituent components of a target SoS architecture. [Figure 5] FIG. 2 illustrates another model of an example target SoS architecture. [Figure 6] FIG. 1 illustrates a model of an example of a multi-domain target SoS architecture. [Figure 7] FIG. 10 is a diagram showing a cyber attack vulnerability summary table. [Figure 8] FIG. 10 illustrates an example partial component description table. [Figure 9] FIG. 1 illustrates a model of an example multi-domain communication architecture. [Figure 10] FIG. 2 illustrates another model of an example multi-domain communication architecture. [Figure 11] FIG. 1 illustrates 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 INVENTION

[0007] Current methods for analyzing cyber vulnerabilities of SoS architectures are ad hoc. For example, in developing communication systems, which are 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 quantify the severity of cyber vulnerabilities of the target SoS architecture. As used herein, the term "cyber attack vector" and its derivatives may refer to one or more attack paths through an SoS. A cyber attack vector may identify an entry point in 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. The 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 analyses such as those 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 communications system, the purpose or mission of the communications system is to enable communication between one or more various devices, vehicles (e.g., aircraft or ground vehicles), satellites, etc. that rely on the communications system to exchange data, information, etc.

[0009] The metric-based analysis described herein can enable the comparison of the robustness of one SoS architecture to another SoS architecture, enable the identification of a more secure SoS architecture for the SoS, and enable the 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 the identification and implementation of alternative, more secure SoS architectures for the SoS that a user (e.g., a systems engineer) may not identify 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] Additionally, in some cases, the systems and methods described herein may include rank-ordering all potential cyber-attack vectors for the SoS so 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., using real-time security monitoring software, such as cyber-attack monitoring software, in the field once the SoS is deployed based on the SoS architecture).

[0011] Thus, in some cases, potential cyber vulnerabilities in an SoS may be identified during the SoS design phase by the systems and methods described herein, 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 during the SoS design phase 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 an SoS system based on an SoS architecture.

[0012] According to the systems and methods described herein, a data structure may be generated that enables a vulnerability analyzer to identify potential cyber attack vectors that could result in an SoS based on a target SoS architecture failing to achieve a targeted objective. In some instances, the targeted objective is a mission, and thus, potential cyber attack vectors could result in an SoS based on the target SoS architecture failing to achieve the mission. The vulnerability analyzer may analyze the target SoS architecture relative to 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., to identify 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 can generate ADF data based on architecture description data and component description data for a target SoS architecture. The ADF data can include identification of all component systems of the target SoS architecture, their interconnections, and the internal connectivity 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 multilevel fidelity definition scheme enables analysis of specific portions of the target SoS architecture where that portion of the target SoS architecture has not yet been defined. Thus, a focused analysis of specific threats to an SoS based on the target SoS architecture can be conducted without requiring the user to define the entire target SoS architecture in detail. Defining the entire target SoS architecture in detail can be very large and complex, and large portions of the target SoS architecture may be largely irrelevant to component analysis of potential cyberattack vulnerabilities.

[0014] In addition to connectivity information, the ADF data can describe one or more mission-critical subsystems within the target SoS architecture and their respective failure modes. A subsystem within a target SoS architecture may be referred to as a mission-critical subsystem if a failure of such a subsystem would cause a mission failure of an SoS based on the target SoS architecture. A mission failure is a type of failure that inhibits, hinders, or prevents an SoS based on the target SoS architecture from performing its intended purpose. For example, consider a target SoS architecture that performs inventory management and order processing (i.e., the architecture's mission) for products produced, stored, and distributed worldwide. This target SoS architecture also has 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 cyberattack and can no longer relay messages within the target SoS architecture, the architecture will cease to function. The failure 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 combinations of multiple mission-critical subsystems and their respective failure modes. Failure modes (failure modes) of one or more mission-critical subsystems can be identified during compilation of the architecture description data and component description data and automatically encoded by the ADF generator into an internal failure model data structure. The failure mode data can be captured, for example, in an FMEA table (or another format), which can be ingested by the ADF generator and automatically encoded into an internal failure model data structure for use by a 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 each component's definition to enable cost trade-off analysis.

[0016] As used herein, the term "target SoS architecture" is used to identify the SoS architecture for an SoS (e.g., a communications 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 search of improved robustness. These changes to the target architecture are referred to as the target SoS architecture for a variant or updated SoS architecture. 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. Overall, 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 system's functionality. The vulnerability analysis concepts described herein apply equally to the analysis of single system architectures as they do to target SoS architectures. Furthermore, the systems and methods described herein can 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, can 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 cyber-attack vulnerabilities. The system 100 can evaluate the target SoS architecture to identify potential cyber-vulnerabilities in the SoS architecture, identify an SoS based on such architecture, and, in some cases, identify the level of threat such vulnerabilities pose to the SoS (e.g., whether the cyber-threat would cause an objective failure). 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, an SoS implemented based on the updated SoS architecture can have a reduced number of cyber-vulnerabilities compared to an 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 context, 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 multiple instances of hardware where an application runs across multiple (e.g., distributed) instances of hardware (e.g., computers, routers, memory, 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 constituent component definitions. The ADF data 114 can have a data format that allows the ADF data 114 to 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 target architecture description data 116 and component description data 118. The target architecture description data 116 may characterize a constituent component list and component connectivity. The component description data 118 may characterize components of the target SoS architecture. For example, the component description data 118 may characterize the role or function of a component, a functional description of a subsystem, the interconnectivity of the subsystem, and identify the cost of mission-critical subsystems and / or components (e.g., the total cost of the component or the cost of an individual subsystem). The ADF generator 108 may be programmed to provide 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 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. 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 ingested 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 the 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 the 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 related to 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 an interactive analysis tool 130 that enables exploration of cyber vulnerabilities versus architecture variants in search of cyber robustness. The interactive analysis tool 130 may include cost-based visualization that enables 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 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 for the target SoS architecture topology and data structures for 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 mission-critical subsystems to a 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 topological model of the target SoS architecture and to analyze 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, and provides an interactive tool for what-if evaluation of alternative architectures for interactive exploration of the architecture's trade space and associated cyber vulnerabilities. This exploratory approach to analyzing an architecture's cyber vulnerabilities allows users to efficiently conduct trade-off analyses 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 its internal data structure and identify potential cyber attack vectors that could cause system degradation, system failure, or mission failure of an SoS based on the target SoS architecture. For example, the vulnerability analyzer 200 may identify potential cyber attack vectors that could cause a constituent component, subsystem, or a particular combination of constituent components and subsystems to deviate from normal operation during deployment of an SoS based on the target SoS architecture to an extent (e.g., level) that would cause the SoS to be throttled or unable to complete its objectives (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 failure model data structure that establishes mission-critical failure modes.

[0027] In one example, the attack vector identifier 206 may be programmed to identify a single path or multiple paths (in some cases, all paths) of a fixed number of events. An event can 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 long-term potential cyber attacks 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 may include an attack vector analyzer 208. The attack vector analyzer 208 may be programmed to perform a probabilistic analysis of potential cyber-attack vectors to calculate vulnerability analysis data 210. The potential cyber-attack vectors may be provided as part of the vulnerability analysis data 210. In some examples, the vulnerability analyzer 200 may 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 may be vulnerability analysis data 122 as shown in FIG. 1. The attack vector analyzer 208 may be programmed to simulate the potential cyber-attack vectors to calculate probabilistic cyber-attack performance metrics that may be characterized by the vulnerability analysis data 210. The attack vector analyzer 208 may use the probabilistic performance metrics to perform probabilistic analyses, such as determining the likelihood of success for each potential cyber-attack vector and / or the likelihood of mission failure for an 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 a computer-readable format for ingestion and processing by other computer analysis application software.

[0029] In some examples, the attack vector analyzer 208 can 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 can be output as part of the vulnerability analysis data 210, and 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; a vulnerability assessment determines whether a potential cyber-vulnerability requires an architectural change or can be managed as a risk to the target SoS architecture; if a 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 visual determination of the trade-off between the threat posed by the cyber-vulnerability and the cost of modifying the architecture to mitigate the vulnerability is made.

[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 consists of a series of events, and each event 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 208 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, a 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 analytical 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 for each cyber attack vector against an SoS based on a target SoS architecture, indicating the likelihood that the respective cyber attack 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, relying only on the analysis producing probabilistically quantified results. Therefore, the systems and methods described herein can utilize any analytical technique for calculating vulnerability probabilities, including AI techniques as described herein. Furthermore, the examples described herein should not be construed and / or limited solely to the analysis of communication systems based on target SoS architectures. The systems and methods described herein can be used for cyber vulnerability analysis of target SoS architectures intended for implementing such systems in military systems, commercial systems, consumer internet systems, business-to-business systems, and intra-enterprise systems.

[0033] FIG. 3 illustrates a model of an example target SoS architecture 300 for an SoS that may be generated by vulnerability analyzer 110 as shown in FIG. 1 or 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. Target SoS architecture 300 may be generated by vulnerability analyzer 110 or 200 based on ADF data 114 as shown in FIG. 1 or ADF data 202 as shown in FIG. 2. Target SoS architecture 300 may be provided to GUI generator 112 for rendering on output device 126, as shown in FIG. 1. In some examples, target SoS architecture 300 is provided as part of vulnerability analysis data 122 as shown in FIG. 1 or vulnerability analysis data 210 as shown in FIG. 2. ADF parser 204 may be programmed to generate target SoS architecture 300 based on 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 ADF 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 in the ADF data 114 or 202 may define each of the constituent components (e.g., functions, characteristics, etc.) of the target SoS architecture 300 at the component abstraction level. The constituent component definitions may include a component role or component functional description, a subsystem list, a subsystem functional description, subsystem interconnectivity (e.g., topology), a mission-critical subsystem list (e.g., subsystems that would cause 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 be identified in the subsystem list; only those 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 interconnectivity 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 could cause mission failure if compromised.

[0036] The component cost data of constituent components can represent absolute cost data (e.g., in fiat or cryptocurrency) or relative cost data. 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 and Y is a decimal multiplier of the base value of constituent component A. 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 allow for cost-benefit analysis to be performed when absolute costs are unknown. 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 . Accordingly, in some examples, reference may be made 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 fewer subsystems than three. 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 definitions 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, if compromised, could cause mission failure. In the example of FIG. 4, subsystem b3 is identified as a critical system that, if compromised, could cause mission failure. Subsystem b3 in 406 is identified as a critical system. In some examples, subsystems b2 and b3 may be a combination of critical subsystems that both need to be compromised for mission failure. 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 target SoS architecture 500 with identified potential cyber vulnerability vectors. The target SoS architecture 500 may be generated by the vulnerability analyzer 110 shown in FIG. 1 or the vulnerability analyzer 200 shown in FIG. 2. In some examples, the target SoS architecture 500 corresponds to the target SoS architecture 300 shown in FIG. 3. Accordingly, in some examples, reference may be made to FIGS. 1-4 in the example of FIG. 5. The target SoS architecture 500 includes constituent component A and constituent component B. Constituent component A connects to constituent component B through subsystem b1 of constituent component B. Subsystem b1 also connects to constituent components C and D of the target SoS architecture 500. Within constituent component B, subsystem b1 connects to subsystems b2 and b3. Subsystem b3 is identified in 502 as a mission-critical subsystem, and a failure of this subsystem could cause a mission failure of the SoS. For the method used by the system 100, not all constituent components and / or subsystems need to 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 could cause mission failure of the SoS if implemented based on the target SoS architecture in the same or similar manner as described herein. With reference 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 begins with compromising constituent component A, leads to compromising subsystem b1, and ends with compromising subsystem b3. The second potential cyber attack vector 506 identifies a potential attack path that begins with compromising constituent component C, leads to compromising subsystem b1, and ends with compromising subsystem b3. The third potential cyber attack vector 508 identifies a potential attack path that begins with compromising constituent component D, leads to compromising subsystem b1, and ends with compromising 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 an 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 use Monte Carlo analysis or another type of computational algorithm to analyze the identified potential cyber attack vectors 504, 506, and 508 to estimate a resulting failure rate (e.g., the probability of mission failure by an SoS based on the target SoS architecture 500). Thus, in some instances, the attack vector analyzer 208 may be programmed to provide a probability indicating the likelihood that a cyber attack along a corresponding attack path will succeed in reaching a critical system that, once compromised, will cause an objective failure of the SoS.

[0042] In some examples, the attack vector analyzer 208 may be programmed to determine an acceptable 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 specific potential cyber attack vector 504, 506, and 508 that has the highest probability from among the potential cyber attack vectors 504, 506, and 508. In other examples, the attack vector analyzer 140 may be programmed to identify a specific potential cyber attack vector 504, 508, and 508 by comparing each probability for each potential cyber attack vector 504, 506 with 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 specific potential cyber attack vector (e.g., as part of the vulnerability analysis data 122 shown in FIG. 1 or the vulnerability analysis data 208 shown in FIG. 2).

[0043] 5 , attack vector analyzer 208 determines that potential cyber attack vector 504 has a 3% estimated mission failure rate, potential cyber attack vector 506 has a 7% estimated mission failure rate, and potential cyber attack vector 508 has a 90% estimated mission failure rate. Because potential cyber attack vector 508 has the highest estimated mission failure rate compared to potential cyber attack vectors 504 and 506, attack vector analyzer 208 can indicate in vulnerability analysis data 122 or 208 that potential cyber attack vector 508 has the most significant vulnerability impact on an SoS based on the target SoS architecture. Vulnerability analysis data 122 or 208 can be rendered on output device 126 by 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 cyber-attack vector grouping criteria. For example, the cyber-attack vector grouping criteria may indicate that potential cyber-attack vectors having respective estimated mission failure rates equal to or less than a first estimated mission failure rate threshold should be associated with a first cyber-attack category, and that potential cyber-attack vectors having respective estimated mission failure rates equal to or greater than the first estimated mission failure rate threshold but equal to or less than a second estimated mission failure rate threshold should be associated with a second cyber-attack category. The cyber-attack vector grouping criteria may indicate that potential cyber-attack vectors having respective estimated mission failure rates equal to or greater than 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 criteria may indicate that potential cyber-attack vectors having respective estimated mission failure rates equal to or greater than the third estimated mission failure rate threshold should be associated with a fourth cyber-attack category.

[0045] In some examples, a first cyberattack category may identify potential cyberattack vectors that will have little impact on the SoS based on the target SoS architecture 500, a second cyberattack category may identify potential cyberattack vectors that can be risk-managed through processes and procedures (e.g., cyberattack monitoring software), a third cyberattack category may identify potential cyberattack vectors that can be mitigated or eliminated by one or more minor changes to the target SoS architecture 500, and a fourth cyberattack category may identify potential cyberattack vectors that require significant changes to the target SoS architecture 500 for mitigation or elimination. The quantification of minor and major 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, the 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 a model of an example multi-domain target SoS architecture 600 for an SoS. The multi-domain target SoS architecture 600 may be generated by a vulnerability analyzer 110 such as that shown in FIG. 1 or a vulnerability analyzer 200 such as that 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 purpose 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] 6, the attack vector analyzer 208 may be programmed to identify one or more potential cyber-attack vectors within 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 distinguished 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 distinguish at 612 within the target SoS architecture 600 that a potential cyber-attack intrusion through the mobile ground node D would compromise subsystem b3 and therefore have a high probability of causing 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, such as that 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 during a cyber-attack simulation (e.g., by the attack vector analyzer 208, as shown in FIG. 2 ), or components that were accessed and compromised during the cyber-attack simulation. 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 a potential cyber attack entry point, that ground component D and airborne component B have been accessed and are at risk, that the communication link between ground component D and airborne component B (identified at 614 in FIG. 6) has been traversed and therefore accessed, and that the communication link between subsystems b1 and b3 (identified at 616 in FIG. 6) has been traversed and therefore accessed.

[0051] FIG. 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. Accordingly, 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. 1.

[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, first and second aircraft, and first and second satellites. 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 the type of 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 the 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 the types of communication links that may be established between each component system 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 communication architecture 900, first satellite 904 and second satellite 910 are located in the space domain (labeled “Space”), first aircraft 906 and second aircraft 912 are located in the air domain (labeled “Air”), and ground station 916 is located in the ground domain (labeled “Ground”).

[0055] Vulnerability analyzer 110, as shown in FIG. 1, or vulnerability analyzer 200, as shown in FIG. 2, can evaluate multi-domain communication architecture 900 to identify potential cyber-attack vectors that are most likely to lead to mission failure, in the same or similar manner as described herein. For example, 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 may disable a subsystem within the component system under test. For example, the simulated cyber-attack may disable communications between first aircraft 906 and ground station 916. Vulnerability analyzer 110 can probabilistically move from component system to component system within multi-domain communication architecture 900 and traverse the communication network during the cyber-attack simulation, in the same or similar manner as described herein.

[0056] Based on the cyber-attack simulation, the vulnerability analyzer 110 or 200 can output vulnerability analysis data 122 as shown in FIG. 1 or vulnerability analysis data 210 as shown in FIG. 2, which indicates the probability that a failure of a given component will result in mission failure, mission impairment, or the probability that the 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 can identify the communication paths traversed during the simulation, the links used, the systems and subsystems disabled, and the mission status (e.g., mission failure, mission impaired, and mission success). The GUI generator 112 can use the vulnerability analysis data 122 or 210 to graphically indicate the frequency or occurrence of failures of a given component system during the cyber-attack simulation on the multi-domain communication architecture 900 (e.g., by changing the color or transparency of the component in the multi-domain communication architecture 900). For example, a component system in the multi-domain communication architecture 900 that frequently failed during the cyber-attack simulation can be colored 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 the target SoS to identify a particular target SoS architecture for the target SoS that has 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 the communication system, as shown in FIG.

[0058] Multi-domain communication architecture 1000 may illustrate types of communication links that may be established between respective component systems of a communication system based on multi-domain communication architecture 1000. In the example of Figure 10, a first BLOS communication link 1002 may be established between a first satellite 1004 and a first aircraft 1006. A second BLOS communication link 1008 may be established between a second satellite 1010 and the first aircraft 1006. A first LOS communication 1012 may be established between the first aircraft 1006 and a second aircraft 1014. A second LOS communication 1016 may be established between the first aircraft 1006 and a ground station 1018. As shown in multi-domain communication 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 may simulate a cyber-attack on 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 may be evaluated by a user, or in some cases by the vulnerability analyzer 110 or 200, to identify the particular multi-domain communication architecture for the communication system having the lowest mission failure rate. For example, if the first multi-domain communication architecture 900 has a 7% mission failure rate and the second multi-domain communication architecture 900 has a 23% mission failure rate, the vulnerability analyzer 110 or 200 may recommend the first multi-domain communication architecture 900 for use in implementing the communication system on the output device 126 (e.g., via the GUI generator 112).

[0060] FIG. 11 illustrates an example FMEA table 1100. The FMEA table 1110 indicates the types of failures that may result from a cyber attack on individual elements or subsystems of a target SoS architecture, for example, as described herein. Accordingly, 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 described above in mind, the exemplary method will 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 in other examples some operations may be performed multiple times and / or simultaneously in a different order than 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. Method 1200 may be performed by vulnerability analyzer 110 as shown in FIG. 1 or vulnerability analyzer 200 as shown in FIG. 1. In some examples, the target SoS architecture is one of the target SoS architectures described herein. Accordingly, in some examples, reference is made to FIGS. 1-11 in the example of FIG. 12.

[0063] 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 first and second data structures. The first data structure may characterize the 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) for performing one or more embodiments. As shown in FIG. 13 , 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), flash memory sticks, etc.), and numerous other elements and functionality. Computer processor 1302 may be an integrated circuit for processing instructions. For example, computer processor 1302 may be one or more cores or micro-cores of a processor. The components of 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 touchscreen, keyboard, mouse, microphone, touchpad, electronic pen, or any other input device. The input devices 812 may be 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 touchscreen, 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 output devices 126 as shown in FIG. 1.

[0067] In some examples, the output device(s) 1312, such as a touchscreen, may be the same physical device as the input device(s) 1310. In other examples, the output device(s) 1312 and the input device(s) 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(s) 1310 and the output device(s) 1312 may be coupled to the computer processor 1302, the memory 1304, and / or the storage device(s) 1306 locally and / or remotely (e.g., via the network 1312). Many different types of computing systems exist, and the input device(s) 1310 and the output device(s) 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 multiple applications and / or modules that may be used to implement the analysis techniques for SoS architectures 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 computing system 1300 may be located remotely and coupled to other elements via network 1314. Additionally, some examples may be implemented on a distributed system having multiple nodes, with portions of the embodiment being located on different nodes within 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 illustrative. Of course, it is not possible to describe every conceivable combination of elements or methodologies, 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 "comprising" means including without limitation. The term "based on" means based at least in part on. Furthermore, when this disclosure or claims recite "a," "first," or "another" element, or equivalents thereof, it should be construed as including one or more such elements, and does not require or exclude more than one element. The technical concepts that can be understood from the above-described embodiment will be described below as supplementary notes. [Appendix 1] 1. A computer-implemented method comprising: receiving architecture description data and component description data relating to 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 that indicates the likelihood that the respective cyber-attack will cause a mission failure by 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. [Appendix 2] 10. 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-attack than the SoS implemented based on the target SoS architecture. [Appendix 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, and definitions of the constituent components, internal subsystems, subsystem connectivity, and identification of mission-critical subsystems. [Appendix 4] generating a model of the target SoS architecture for the SoS, 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, further 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. [Appendix 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. [Appendix 6] 6. The computer-implemented method of claim 5, wherein simulating the potential cyber-attack vector via the target SoS on the SoS is performed using a computational algorithm. [Appendix 7] 6. The computer-implemented method of claim 5, wherein simulating the potential cyber-attack vector via the target SoS on the SoS is performed using an artificial intelligence algorithm. [Appendix 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 for identifying given cyber-attack vectors for which the SoS implemented based on the target SoS is most likely to fail to achieve its objective. [Appendix 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. [Appendix 10] 10. The computer-implemented method of claim 9, wherein the grouping criteria for the cyber-attack vectors 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. [Appendix 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 eliminate each identified potential cyber-attack vector associated with the third cyber-attack category. [Appendix 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 that characterizes the probability for each cyber-attack vector for the first target SoS architecture; receiving additional architecture description data and component description data for the SoS; generating second ADF data based on the additional architecture description data and component description data; generating a second model of a second target SoS architecture for the SoS based on the second ADF data; assessing 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 the respective cyber-attack will cause a mission failure by 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, the vulnerability analysis data characterizing the probability for each cyber-attack vector for the second target SoS architecture. [Appendix 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 with a lower number of potential cyber-attack vulnerabilities that could cause the SoS to fail in its objectives. [Appendix 14] 1. A system comprising: a memory for storing machine-readable instructions and architecture definition file (hereinafter referred to as ADF) data; 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; an attack vector analyzer programmed to perform a probabilistic analysis of the potential cyber-attack vectors and 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 the 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 compared to the SoS implemented based on the target SoS architecture. [Appendix 15] The ADF parser: 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 comprising: a processor configured to generate 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. [Appendix 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. [Appendix 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, when implemented based on the target SoS, to fail in its objective. [Appendix 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 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 by 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 a target SoS, when implemented based on the SoS, to fail to achieve its objective. [Appendix 19] 19. 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 an SoS implemented based on the updated target SoS architecture has reduced vulnerability to cyber-attacks than an SoS implemented based on the target SoS architecture. [Appendix 20] 19. 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.

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 by 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. generating a model of the target SoS architecture for the SoS, 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, further 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 vector 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 vector 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 for identifying given cyber-attack vectors that are most likely to cause the SoS implemented based on the target SoS to fail in its objective.

9. 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 grouping criteria for the cyber-attack vectors 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. 11. The computer-implemented method of claim 10, 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 eliminate 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 that characterizes the probability for each cyber-attack vector for the first target SoS architecture; receiving additional architecture description data and component description data for said SoS; generating second ADF data based on the additional architecture description data and component description data; generating a second model of a second target SoS architecture for the SoS based on the second ADF data; assessing 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 the respective cyber-attack will cause a mission failure by 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 that have a fewer 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 (hereinafter referred to as ADF) data; 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 the 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 compared to the SoS implemented based on the target SoS architecture.

15. The ADF parser 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, wherein the system is programmed to generate 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.

Images