Distributed network-level probabilistic attack graph generation

A method for generating a network-level attack graph is described. A first computing device in a network generates a first attack graph and transmits the first attack graph to a central computing device in the network. A second computing device in the network generates a second attack graph, wherein the second computing device is different than the first computing device, and transmits the second attack graph to the central computing device. The central computing device generates, based on the first attack graph and the second attack graph, a network-level attack graph by merging the first attack graph, the second attack graph, and an attack graph stencil of cross-device vulnerability interactions.

TECHNICAL FIELD

The disclosure relates to network security.

BACKGROUND

Network security systems rely on the ability to monitor vulnerabilities within a network in order to identify vulnerabilities that would be subject to potential malicious activity that may be considered harmful. In particular, network security systems seek to identify unwanted system vulnerabilities that would allow attackers to gain access to assets compromising the confidentiality, integrity, or accessibility of network assets, so that appropriate action may be taken in response to the risk. The system can include computer systems, applications, networks, or any combination thereof. The risk due to vulnerabilities is partially characterized in a threat-based approach where a wide array of attackers, ranging from the initiate, to organized crime to nation-states, are always looking for a way to compromise a network against defenders with limited resources of time, personnel, and funding. Due to the nature of the risk of vulnerabilities, it is recommended that the cyber situational awareness tools require frequent updates which most organizations cannot or do not abide.

SUMMARY

In general, the disclosure describes a methodology for a distributed generation of attack graphs locally and then managing and merging the subgraphs into an enclave level attack graph. The method includes the steps of generating a graph, transmitting and receiving a graph, and merging the subgraph into a larger enclave-level graph where at least one of the steps is carried out using a computer device.

Further, there are a large number of compute cycles and network bandwidth available during off hours. This disclosure describes a process to utilize those down time resources to improve the cyber situational awareness by using these resources, on a daily basis, if not more frequently, to generate a daily or more frequent, enclave-level attack graph for each machine local to the enclave, on that individual machine, and then collate the individual attack graphs into an enclave level attack graph.

This method leverages each of the machine-level assets within an enclave to generate its own attack graph and, by sharing the data with a central processing unit, can generate an enclave-wide probabilistic attack graph. This can be extended by generating enclave-level attack graphs at individual machines and sending the enclave-level attack graphs to a central server to generate a full network-level attack graph if the network includes multiple enclaves. The benefits of this method are that by distributing part of the attack graph generation to individual machines, the computational load is shared during low compute-activity and low network-activity times and thus more frequent cyber-situational awareness can be gained for a daily or even more frequent period. The benefit of more frequent scanning cannot be over-stated especially if the computational and network loads are reduced. Another benefit to this method is that each machine in the enclave can provide its' perspective of itself in the network versus a more assumed perspective based on network tools. Furthermore, the individual machines in the separate enclaves can produce updated attack graphs, compare the updated attack graphs to prior attack graphs, and only transmit the differences between those two attack graphs to the central processing unit, thereby reducing the amount of overall network traffic by reducing the amount of data transmitted between those devices over the network.

In one example, the disclosure is directed to a method in which a first computing device in a network generates a first attack graph. The method further includes generating, by a second computing device in the network, a second attack graph, wherein the second computing device is different than the first computing device. The method also includes transmitting, by the first computing device, the first attack graph from the first computing device to a third computing device in the network, wherein the third computing device is different than the first computing device and the second computing device. The method further includes transmitting, by the second computing device, the second attack graph from the second computing device to the third computing device. The method also includes generating, by the third computing device and based on the first attack graph and the second attack graph, a network-level attack graph by merging the first attack graph, the second attack graph, and an attack graph stencil of cross-device vulnerability interactions.

In another example, the disclosure is directed to a server device that includes one or more communication units configured to communicate with each of a plurality of computing devices in a network, the plurality of computing devices including a first computing device and a second computing device. The server device also includes one or more processors configured to receive, via the one or more communication units, a first attack graph from the first computing device, receive, via the one or more communication units, a second attack graph from the second computing device, access a comprehensive list of known vulnerabilities, determine an operating system for each computing device of the plurality of computing devices in the network, determine each unique operating system pair based on the operating system for each computing device of the plurality of computing devices, for each unique operating system pair, determine, based on the comprehensive list of known vulnerabilities, each interaction vulnerability for the respective unique operating system pair to generate an attack graph stencil of cross-device vulnerability interactions, and generate, based on the first attack graph and the second attack graph, a network-level attack graph by merging the first attack graph, the second attack graph, and the attack graph stencil.

In another example, the disclosure is directed to a system comprising a network comprising a plurality of computing devices. The plurality of computing devices includes at least a first computing device, a second computing device different than the first computing device, and a third computing device different than the first computing device and the second computing device. The first computing device is configured to generate a first attack graph and transmit the first attack graph to the third computing device. The second computing device is configured to generate a second attack graph and transmit the second attack graph to the third computing device. The third computing device is configured to generate, based on the first attack graph and the second attack graph, a first network-level attack graph by merging the first attack graph, the second attack graph, and an attack graph stencil of cross-device vulnerability interactions. The first computing device is further configured to generate a third attack graph, generate a first delta attack graph that includes only differences between the third attack graph and the first attack graph, and transmit the first delta attack graph to the third computing device. The second computing device is further configured to generate a fourth attack graph, generate a second delta attack graph that includes only differences between the fourth attack graph and the second attack graph, and transmit the second delta attack graph to the third computing device. The third computing device is further configured to construct the third attack graph from the first attack graph and the first delta attack graph, construct the fourth attack graph from the second attack graph and the second delta attack graph, and generate, based on the third attack graph and the fourth attack graph, a second network-level attack graph by merging the third attack graph, the fourth attack graph, and a second attack graph stencil of cross-device vulnerability interactions.

In another example, the disclosure is directed to a non-transitory computer-readable storage medium containing instructions. The instructions, when executed, cause one or more processors to perform any of the techniques described herein.

In another example, the disclosure is directed to a method comprising any of the techniques described herein.

In another example, the disclosure is directed to a computing device configured to perform any of the techniques described herein.

In another example, the disclosure is directed to a system including one or more computing devices, wherein the system as a whole is configured to perform any of the techniques described herein.

In another example, the disclosure is directed to an apparatus comprising means for performing any of the techniques described herein.

DETAILED DESCRIPTION

FIG.1is a block diagram illustrating an example network100with multiple enclaves102A-102C, in accordance with one or more techniques described herein. Each of enclaves102A-102C includes a number of secondary computing devices106A-106G. Some enclaves may include multiple levels of secondary computing devices (e.g., enclave102A includes at least one secondary computing device (106G) with a traceroute distance from central computing device110of 2 hops). Some enclaves may include multiple secondary computing devices with a traceroute distance from central computing device110of 1 hop (e.g., enclave102B includes at least secondary computing devices106C-106E, which are all only 1 hop from central computing device110). Some enclaves may only include a single secondary computing device (e.g., enclave102C includes only secondary computing device106F). However, these are only a few examples of enclave configurations, and any enclave configuration may be suitable for the techniques described herein. For instance, in other examples, each of secondary computing devices106A-106G may be located in a same enclave, and the network-level attack graph generated by central computing device110may be the enclave-level attack graph. In other words, the techniques described herein may be utilized to generate enclave-level attack graphs from multiple individual attack graphs within a same enclave, or to generate network-level attack graphs from multiple individual attack graphs, with at least two of those individual attack graphs being in different enclaves.

The method here leverages mathematical work on adjacency matrices and graph theory. The techniques described herein include merging sub-graphs to form a larger graph structure for proper information extraction from the attack graph. To carry out this process, several algorithms are utilized which merge two community subgraphs into a single graph. For the techniques described herein, individual attack graphs may be generated on a machine-level (e.g., secondary computing device106A-106G) and central computing device110may merge the individual attack graphs utilizing an overlapping attack path stencil which represents how vulnerabilities interact across different machines, thereby joining the individual attack graphs into a merged attack graph.

An aspect of the techniques described herein is, after data collection and transmission, central computing device110matches sections of the individual attack graphs according to their relative connections between one another and how the vulnerabilities interact between them and to make available of initial form of merged enclave-level adjacency matrix. Central computing device110also creates an adjacency matrix vulnerability-based attack graph, and central computing device110may use another algorithm for the adjacency matrices of enclave graph and the creation of merged community enclave-level attack graph adjacency matrix.

It should be noted that the techniques described herein can be extended beyond common vulnerabilities and exposures (CVEs) to include additional attack graph-based layers such as configuration control items (CCI), flow data, IoT, user-type, course-of-action recommendations, etc. in a graph-theory based temporal multiplex to enhance the cyber-situational awareness for risk mitigation.

As new vulnerabilities are discovered, many vendors and developers share this information with the general cybersecurity community. The data is published by a variety of sources such as the National Institute of Science and Technology (NIST), National Vulnerability Database (NVD) or the OpenVAS community Network Vulnerability Tests (NVT) feed. These are examples of extensible markup language (XML) files which contain vulnerability information which can be used as the basis of a vulnerability scan. The combination of the vulnerability data and the resulting network scan provides a foundation for generating an attack graph. New vulnerabilities are discovered daily and as is often the case, these vulnerabilities may exist for both new and old software alike.

The daily process of taking new vulnerabilities into account may trigger the process for one or more secondary devices106A-106G to perform a self-scan and to trigger the process described herein. In order to meet the need of relevant, actionable cyber-situational awareness, it is important to have frequent updates. Some entities recommend at least daily updates, but the techniques described herein may provide for more frequent updates as needed.

Changes in network100occur for a number of reasons. Some of those reasons are machines being added or removed from the network, changes in the software on each machine of the network, activities associated with patching and new vulnerabilities being discovered. The changes listed here are not necessarily all encompassing, but they illustrate the need for updating the awareness of the risk posed by vulnerabilities on a network.

The changes can be monitored in a variety of ways. For network or connectivity context of a machine in the network, since the individual machines need to have context to which other machines that they are connected, an example of gaining this contextual information is using traceroute with a hop of one (1.0). This information may be stored on each of secondary computing devices106A-106G from day-to-day, or scan-to-scan, and may be monitored to detect any changes in the connectivity. Each day machines can be added or deleted from the network. This information can be stored with a date-time-stamp to ensure detection of changes, historical information as well as the necessary context to generate the current enclave-level attack graph. The connectivity context may be transmitted to central computing device110to merge the individual attack graphs and serve as an addressing mechanism to ensure that the correct machines are linked within the larger enclave context.

In addition to the traceroute information, individual machine information may be transmitted to ensure the greatest possible accuracy in identifying an asset. The transmitted information may include, but may not be limited to, the hard drive serial number, the universally unique identifier (UUID), and the network basic input/output system (NetBIOS) information of the respective one of secondary computing devices106A-106G. This would allow not only accurate identification of an asset at the time of processing, but also asset identification through time to facilitate trending.

Every day, new vulnerabilities are discovered and exploits developed. Of all the triggers, the discovery of a new vulnerability may trigger an update on a daily basis. There are a number of open-source data sets that detail each new vulnerability. For example, the National Institute of Technology (NIST), publishes, daily, the list of reported vulnerabilities in the National Vulnerability Database. This database lists vulnerabilities going back to the late 1990s. There are vulnerability scanners based on this database. On a daily basis, during a low processing time, central computing device110and secondary computing devices106A-106G may download the latest vulnerabilities and check the characteristics of the vulnerabilities to see if it would trigger an update to the local attack graph or attack graph stencil. Since vulnerabilities are typically operating system dependent, not all new vulnerabilities may trigger an update. However, there is the case, that the machines may be networked with another that may receive an update and this may act as a trigger for the local machine, but the fact that this process uses attack graph stenciling to act as a bridge between networked machines already handles this on demand.

For software modifications, central computing device110and secondary computing devices106A-106G may perform a daily scan for registry changes (e.g., log files, registry changes, event logs, network configuration). Software on a machine can be modified in several ways. Software can be added or deleted or updated or patched. Each one of these changes can introduce vulnerabilities to the software landscape of a machine and each one of these vulnerabilities has the potential to interact with other vulnerabilities within the machine or enclave. For example, there are a number of advanced third-party utilities available that can monitor changes to the registry. Others can monitor file or folder changes.

In order to provide the underlying data from which an attack graph is built, each of secondary computing devices106A-106G may perform a vulnerability scan. Vulnerability scanning is a process across computational machines and communications equipment in a network to search for and identify potential vulnerabilities which may be exploitable.

A vulnerability scan typically originates with the system owners with the responsibility for the enclave security, but vulnerability scans are also used by attackers looking for points of entry into the enclave.

A vulnerability scanner runs from the end point of the person inspecting the attack surface in question. The scanning software compares details about the target attack surface to a database of information about known vulnerabilities in services and ports and anomalies in packet creation. Most vulnerability databases are incomplete due to issues of self-reporting and lag time to publish vulnerabilities, and due to attackers that hold zero-day vulnerabilities in secret to leverage or sell. Should a database of a more fundamental description of underlying execution sequences defined by the flaw or malware, then this data may replace the vulnerability database to get to the truer measure of vulnerabilities, exploits and risk.

Vulnerability scanning can be potentially problematic on the target machine's running operations or flow across a network. As a result, the scan can cause errors and reboots, thereby impacting operations.

There are two categories of vulnerability scanning: authenticated and unauthenticated scans. Unauthenticated scans perform the scan as an attacker initially would, without authenticated access to the enclave. Unauthenticated scan reveals vulnerabilities that can be accessed without officially logging into the network. Authenticated scans are from the dimension of an authenticated (or insider) user, thus revealing the vulnerabilities that are accessible to trusted users, or an attacker that has gained access as a trusted user. Both techniques may be utilized to maximize the utility of actionable cyber situational awareness results of the enclave to be protected.

Ultimately the results of both types of vulnerability scans are used as the see information from which to build the enclave level attack graph. In this situation, a machine level vulnerability scan takes place and the enclave level results are derived from merging the individual machine results.

The merger of two subgraphs into a single graph may involve three broad steps. The first step is an overlay of a stencil that shows the connection of vulnerabilities through their interaction between machines. The second step is ordering the individual machine's adjacency matrices to match those of the stencils. The third step is the actual merger using the individual machine's adjacency matrices and the stencil overlay.

The stencil may be created on a daily basis as the vulnerability list evolves. For example, if the National Institute of Technology (NIST) updates their National Vulnerability Database (NVD), and then the individual secondary machine106A-106G gets an update as well as central computing device110. The secondary machine106A-106G may use their copy of the NIST NVD to create their individual attack graph and adjacency matrices, whereas central computing device110may use it to create attack graph stencils of the cross-machine vulnerability interactions in order to serve the merging process.

Central computing device110may create a file that resembles an actual scan result, which may actually be the template for the stencil. This template may contain the universe of the vulnerabilities on an operating-system-by-operating-system basis. The template may be of two machines, iterating through the operating system possibilities in order to create the stencil that shows the vulnerability interaction between operating system types.

Since there may be multiple adjacency matrices, each matrix element may be accompanied by not only its individual identifying information, but also with respect to its relationship to other machines it is in direct contact with. The relationship information comes from having a timestamp and the traceroute information. The timestamp may serve as a temporal signature so that it may be understood which adjacency matrix this is and at what time to properly merge the most recent adjacency matrices. The traceroute information may serve as an indicator as to which machine is connected to which machine and serve as an overarching framework from within the merge process. The process may include merging two individual adjacency matrices, but this may be generalizable to any number of adjacency matrices. It may also be assumed that the identifying information addressed above may be part of the matching algorithm to account for which adjacency matrices are being processed.

Graph theory and the algebra of adjacency matrices give us a way for the merging of two subgraphs into a larger single enclave-level graph network. The techniques described herein may employ a graph-matching technique by matching one-to-one correspondence of the two subgraphs by keeping track of the originating subgraph, associated vulnerability and the vulnerability interactions across subgraph boundaries. Due to the fact that these adjacency matrices represent attack graphs, there may be the additional consideration of including interactions that are derived between vulnerabilities that exist on different machines. The attack graph stencil addresses this issue by providing the necessary edges between machine interactions and thus enable central computing device110to correctly assemble the cross-machine interactions between vulnerabilities. Central computing device110may represent a subgraph in memory as an adjacency matrix. Graph theory provides three algorithms for merging of two subgraphs. Algorithm-I explains about finding the order of merged graph network of two subgraphs. Algorithm-II explains about creation of adjacency matrix machine-level subgraph. These adjacency matrices of these graphs are used in Algorithm-III. Algorithm-III explains about creation of merged adjacency matrix using the attack subgraph stencil to complete the interactions. Finally, from this adjacency matrix, central computing device110may construct the merged attack graphs of two attack subgraphs and the stencil. It should be noted that the below algorithms are only example algorithms using pseudocode. Alternative data structures, operations, and orders may be used to accomplish the techniques described herein, and one having ordinary skill in the art would understand that the below example algorithms are only one way of accomplishing the techniques described herein.

Algorithm I, provided below, shows the finding of an order of merged subgraphs of two attack subgraphs or an attack subgraph with the stencil then repeated with another subgraph and stencil then together:

CMAS [1:N1+N2]: Global array to hold the merged ensemble arrays CAS1 and CAS2.

MAS [1:size, 1:size]: Global 2D-Array for representation of initial form of merged ensemble matrix.

size: The size of merged array.1. Merge CAS1 and CAS2 and store in CMAS.2. Arrange CMAS in ascending order.3. Set size: =N1+N2.4. [Remove the repeated ensemble from CMAS[]]

CA [1:Size]: Array of an attack graph of dimension Size.

EMatrix [1:Size+1, 1:Size+1]: Ensemble matrix of attack subgraph (AS) of order (Size+1)×(Size+1).

0. [Attack subgraph number assignments at row and column places in ensemble matrix EMatrix[][]]

To create an ensemble graph CAS1[1:N1]'s adjacency matrix as AS1[1:N1+1, 1:N1+1] then follow the given statement:

AS1: Adjacency matrix of the ensemble graph of attack-subgraph-1 of order (N1+1)×(N1+1)]

Algorithm III, shown below, may be for merging two subgraphs adjacency matrices and in order to represent the merged ensemble adjacency matrix MV of order size×size. The initial state of matrix MV [1:size,1:size] may be created in Algorithm-1.

MV [1:size, 1:size]: Global 2D-Array (formed from Algorithm-I) for representation of merged ensemble matrices AS1 and AS2, of order size X size.0. [Adding adjacency matrices V2[][] with merged ensemble matrix mas[][]]

Graphically the algorithmic process described above may take the individual machine attack (sub)graphs generated by an internal scan.

Before central computing device110merges the subgraphs, the connectivity of the subgraphs may be taken into account. The connectivity information comes from identifying each individual secondary computing device106A-106G either by hard drive serial number or IP address. IP address is not necessarily reliable over time since there is the existence of dynamic host configuration protocol (DHCP) or virtual machines. Hard drive serial number is more robust since the vulnerabilities we are concerned about exist on the hard drive. Additionally, the hard drive serial number is stable through time, so an assets vulnerability can be tracked longitudinally. When a machine detects a change through either self-monitoring or daily traceroute (1 hop) pings or network configurations, the identifying information about the individual machine and the traceroute information may identify the machine and its connections to the central collating and aggregation server.

The traceroute information may be used to build a template adjacency matrix of the entire enclave. Given the number of machines within an enclave gives us the row and column dimensions of the template. Each cell of the matrix may represent a separate machine. Each cell also represents the individual secondary computing device106A-106G attack subgraph. A simplifying assumption may be made for programming's sake to utilize an n-×-n matrix of the attack subgraph of all vulnerabilities and then just zero-out the vulnerabilities that do not exist within that particular machine type, such as some vulnerabilities in one operating system that may not exist on some other operating systems. For performance reasons, the size of some enclaves cannot fit within RAM memory, so the Cartesian product algorithm may be employed so that only the necessary elements for adjacency matrix operations are loaded into memory and that can be supported within the memory.

The attack graph stencil provides the bridge between vulnerability inter-machine interactions. The techniques described herein provide a method to overlay the stencil of inter-machine vulnerability interactions. The ensemble enclave-level attack graph derived from the individual machine attack (sub)graph and the overlapping stencils. Once the individual machine level attack graphs are merged into the enclave level attack graph, the conditional probabilities of the attacker walking the vulnerabilities through the enclave can be computed.

The techniques described herein describe an approach to merging and aggregating vulnerability metrics in an enterprise network through machine-level probabilistic attack graphs. The techniques include the merging of sub-graphs to form a larger graph which can be used for enclave level probabilistic attack inference. Given the components of the individual attack sub-graphs, the adjoining stencil attack graphs, the triggering mechanisms and the final network-level attack graph gives a method to improve actionable cyber situational awareness results on a more frequent basis and computes a conditional probability across the attack graph for the probability of success for a vulnerability being exploited.

In accordance with the techniques described herein, secondary computing device106A may generate a first attack graph. Secondary computing device106A may generate this attack graph during a low usage period for secondary computing device106A. A low usage period means a time period where one or more processors of secondary computing device106A have a high amount of available compute cycles or where network100has a low bandwidth usage. Secondary computing device106A may transmit the first attack graph from secondary computing device106A to central computing device110in network100.

Secondary computing device106C may also generate a second attack graph, potentially during a low usage period (as with secondary computing device106A). Secondary computing device106C may then transmit the second attack graph from secondary computing device106C to central computing device110.

Central computing device110may generate, based on the first attack graph and the second attack graph, a network-level attack graph by merging the first attack graph, the second attack graph, and an attack graph stencil of cross-device vulnerability interactions. Central computing device110may also generate the attack graph stencil used in this merge. Central computing device110may access a comprehensive (or partial) list of known vulnerabilities. Central computing device110may then determine an operating system for each known secondary computing device106A-106G in network100. Central computing device106A may determine each unique operating system pair based on the operating system for each secondary computing device106A-106G. For each unique operating system pair, central computing device106A may determine, based on the comprehensive list of known vulnerabilities, each interaction vulnerability for the respective unique operating system pair to generate the attack graph stencil of cross-device vulnerability interactions.

At a later time, secondary computing device106A may generate a third attack graph. Rather than transmit the entire third attack graph to central computing device110, secondary computing device106A may take advantage of the low usage period in which the third attack graph may have been generated to generate a first delta attack graph that includes only differences between the third attack graph and the first attack graph. Secondary computing device106A may then transmit only the first delta attack graph to central computing device110.

Secondary computing device106C may perform a similar process, generating a fourth attack graph. Secondary computing device106C may then generate a second delta attack graph that includes only differences between the fourth attack graph and the second attack graph and transmit the second delta attack graph to central computing device110.

Central computing device110may receive the first delta attack graph from secondary computing device106A and the second delta attack graph from secondary computing device106C. Central computing device110may construct the third attack graph from the first attack graph and the first delta attack graph. Central computing device110may also construct the fourth attack graph from the second attack graph and the second delta attack graph. Central computing device110may then generate, based on the third attack graph and the fourth attack graph, a second network-level attack graph by merging the third attack graph, the fourth attack graph, and a second attack graph stencil of cross-device vulnerability interactions. The second attack graph stencil may either be a same attack graph stencil as the first attack graph stencil or may include any updates that may have been determined between generating the first network-level attack graph and generating the second network-level attack graph.

This method leverages each of the machine-level assets within an enclave to generate its own attack graph and then by sharing the data with a central processing unit, can generate an enclave-wide probabilistic attack graph. The benefits of this method are that by distributing part of the attack graph generation to individual machines, the computational load is shared during low compute-activity and low network-activity times and thus more frequent cyber-situational awareness can be gained for a daily or even more frequent period. The benefit of more frequent scanning cannot be over-stated especially if the computational and network loads are reduced. Another benefit to this method is that each machine in the enclave can provide its' perspective of itself in the network versus a more assumed perspective based on network tools. Furthermore, the individual machines in the separate enclaves can produce updated attack graphs, compare the updated attack graphs to prior attack graphs, and only transmit the differences between those two attack graphs to the central processing unit, thereby reducing the amount of overall network traffic by reducing the amount of data transmitted between those devices over the network.

FIG.2is a block diagram illustrating a more detailed example of a central computing device configured to perform the techniques described herein. Central computing device210ofFIG.2is described below as an example of central computing device110ofFIG.1.FIG.2illustrates only one particular example of central computing device210, and many other examples of central computing device210may be used in other instances and may include a subset of the components included in example central computing device210or may include additional components not shown inFIG.2.

As shown in the example ofFIG.2, central computing device210includes user interface device (UID)212, one or more processors240, one or more communication units242, one or more input components244, one or more output components246, and one or more storage components248. UID212includes display component202and presence-sensitive input component204. Storage components248of central computing device210include communication module220, graph module222, and stencil data store226.

One or more processors240may implement functionality and/or execute instructions associated with central computing device210to generate an attack graph stencil and a network-level attack graph. Examples of processors240include application processors, display controllers, auxiliary processors, one or more sensor hubs, and any other hardware configure to function as a processor, a processing unit, or a processing device. Modules220and222may be operable by processors240to perform various actions, operations, or functions of central computing device210. For example, processors240of central computing device210may retrieve and execute instructions stored by storage components248that cause processors240to perform the operations described with respect to modules220and222. The instructions, when executed by processors240, may cause central computing device210to generate an attack graph stencil and a network-level attack graph.

Communication module220may perform operations for communicating with outside computing devices and enclaves, such as secondary computing devices106A-106G in respective enclaves102A-102C. For example, UI module220of central computing device210may receive local attack graphs from various secondary computing devices106A-106G, which are merged together with an attack graph stencil to generate the network-level attack graph.

In some examples, graph module222may execute locally (e.g., at processors240) to provide functions associated with generating an attack graph stencil and a network-level attack graph. In some examples, graph module222may act as an interface to a remote service accessible to central computing device210. For example, graph module222may each be an interface or application programming interface (API) to a remote server that generates an attack graph stencil and a network-level attack graph.

One or more storage components248within central computing device210may store information for processing during operation of central computing device210(e.g., central computing device210may store data accessed by modules220and222and stencil data store226during execution at central computing device210). In some examples, storage component248is a temporary memory, meaning that a primary purpose of storage component248is not long-term storage. Storage components248on central computing device210may be configured for short-term storage of information as volatile memory and therefore not retain stored contents if powered off. Examples of volatile memories include random access memories (RAM), dynamic random access memories (DRAM), static random access memories (SRAM), and other forms of volatile memories known in the art.

Storage components248, in some examples, also include one or more computer-readable storage media. Storage components248in some examples include one or more non-transitory computer-readable storage mediums. Storage components248may be configured to store larger amounts of information than typically stored by volatile memory. Storage components248may further be configured for long-term storage of information as non-volatile memory space and retain information after power on/off cycles. Examples of non-volatile memories include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. Storage components248may store program instructions and/or information (e.g., data) associated with modules220and222and stencil data store226. Storage components248may include a memory configured to store data or other information associated with modules220and222and stencil data store226.

Communication channels250may interconnect each of the components212,240,242,244,246, and248for inter-component communications (physically, communicatively, and/or operatively). In some examples, communication channels250may include a system bus, a network connection, an inter-process communication data structure, or any other method for communicating data.

One or more communication units242of central computing device210may communicate with external devices via one or more wired and/or wireless networks by transmitting and/or receiving network signals on one or more networks. Examples of communication units242include a network interface card (e.g. such as an Ethernet card), an optical transceiver, a radio frequency transceiver, a GPS receiver, or any other type of device that can send and/or receive information. Other examples of communication units242may include short wave radios, cellular data radios, wireless network radios, as well as universal serial bus (USB) controllers.

One or more input components244of central computing device210may receive input. Examples of input are tactile, audio, and video input. Input components244of central computing device210, in one example, includes a presence-sensitive input device (e.g., a touch sensitive screen, a PSD), mouse, keyboard, voice responsive system, camera, microphone or any other type of device for detecting input from a human or machine. In some examples, input components244may include one or more sensor components252one or more location sensors (GPS components, Wi-Fi components, cellular components), one or more temperature sensors, one or more movement sensors (e.g., accelerometers, gyros), one or more pressure sensors (e.g., barometer), one or more ambient light sensors, and one or more other sensors (e.g., infrared proximity sensor, hygrometer sensor, and the like). Other sensors, to name a few other non-limiting examples, may include a heart rate sensor, magnetometer, glucose sensor, olfactory sensor, compass sensor, or a step counter sensor.

One or more output components246of central computing device210may generate output in a selected modality. Examples of modalities may include a tactile notification, audible notification, visual notification, machine generated voice notification, or other modalities. Output components246of central computing device210, in one example, includes a presence-sensitive display, a sound card, a video graphics adapter card, a speaker, a cathode ray tube (CRT) monitor, a liquid crystal display (LCD), a light emitting diode (LED) display, an organic LED (OLED) display, a virtual/augmented/extended reality (VR/AR/XR) system, a three-dimensional display, or any other type of device for generating output to a human or machine in a selected modality.

UID212of central computing device210may include display component202and presence-sensitive input component204. Display component202may be a screen, such as any of the displays or systems described with respect to output components246, at which information (e.g., a visual indication) is displayed by UID212while presence-sensitive input component204may detect an object at and/or near display component202.

While illustrated as an internal component of central computing device210, UID212may also represent an external component that shares a data path with central computing device210for transmitting and/or receiving input and output. For instance, in one example, UID212represents a built-in component of central computing device210located within and physically connected to the external packaging of central computing device210(e.g., a screen on a mobile phone). In another example, UID212represents an external component of central computing device210located outside and physically separated from the packaging or housing of central computing device210(e.g., a monitor, a projector, etc. that shares a wired and/or wireless data path with central computing device210).

UID212of central computing device210may detect two-dimensional and/or three-dimensional gestures as input from a user of central computing device210. For instance, a sensor of UID212may detect a user's movement (e.g., moving a hand, an arm, a pen, a stylus, a tactile object, etc.) within a threshold distance of the sensor of UID212. UID212may determine a two or three-dimensional vector representation of the movement and correlate the vector representation to a gesture input (e.g., a hand-wave, a pinch, a clap, a pen stroke, etc.) that has multiple dimensions. In other words, UID212can detect a multi-dimension gesture without requiring the user to gesture at or near a screen or surface at which UID212outputs information for display. Instead, UID212can detect a multi-dimensional gesture performed at or near a sensor which may or may not be located near the screen or surface at which UID212outputs information for display.

In accordance with the techniques of this disclosure, communication module220may receive the first attack graph from a first secondary computing device and the second attack graph from a second, different secondary computing device. Upon receiving these attack graphs, graph module222may generate, based on the first attack graph and the second attack graph, a network-level attack graph by merging the first attack graph, the second attack graph, and an attack graph stencil of cross-device vulnerability interactions.

In some instances, graph module222may also generate the attack graph stencil. In such instances, the network further includes a plurality of computing devices (including secondary computing device306and the additional secondary computing device), and generating the attack graph stencil includes graph module222accessing a comprehensive (or partial) list of known vulnerabilities. Graph module222may determine an operating system for each computing device of the plurality of computing devices in the network. Graph module222then may determine each unique operating system pair based on the operating system for each computing device of the plurality of computing devices. For each unique operating system pair, graph module222may determine, based on the comprehensive list of known vulnerabilities, each interaction vulnerability for the respective unique operating system pair, thereby forming the attack graph stencil. The operating system may be one or more of an operating system family and a version number installed on the respective computing device of the plurality of computing devices.

In some instances, the first and second secondary computing devices may generate a first delta attack graph and a second delta attack graph, respectively, when central computing device210is to update the network-level attack graph to generate a second, subsequent network-level attack graph. Communication module220may receive only the first delta attack graph and the second delta attack graph during the process of generating a second, updated network-level attack graph. Graph module222may construct third attack graph from the first attack graph and the first delta attack graph to get an updated picture of the vulnerabilities recognized by the first secondary computing device, and may construct the fourth attack graph from the second attack graph and the second delta attack graph to get an updated picture of the vulnerabilities recognized by the second secondary computing device. Graph module222may then generate, based on the third attack graph and the fourth attack graph, a second network-level attack graph by merging the third attack graph, the fourth attack graph, and a second attack graph stencil of cross-device vulnerability interactions. The second attack graph stencil from attack graph stencils data store226may either be a same attack graph stencil as the first attack graph stencil or may include any updates that may have been determined between generating the first network-level attack graph and generating the second network-level attack graph.

Graph module222may utilize any number of attack graphs generated by separate secondary devices when merging local attack graphs with the attack graph stencil to generate the network-level attack graph. For instance, one or more additional secondary computing devices may each generate an additional attack graph for the respective additional secondary computing device. Each of these additional secondary computing devices may transmit the respective additional attack graph from the respective additional computing device to central computing device210. Communication module220may receive each of these additional attack graphs. Graph module222may then generate the network-level attack graph by merging all of the first attack graph, the second attack graph, each of the one or more additional attack graphs, and the attack graph stencil.

FIG.3is a block diagram illustrating a more detailed example of a secondary computing device306configured to perform the techniques described herein. Secondary computing device306ofFIG.3is described below as an example of secondary computing devices106A-106G ofFIG.1.FIG.3illustrates only one particular example of secondary computing device306, and many other examples of secondary computing device306may be used in other instances and may include a subset of the components included in example secondary computing device306or may include additional components not shown inFIG.3.

As shown in the example ofFIG.3, secondary computing device306includes user interface device (UID)312, one or more processors340, one or more communication units342, one or more input components344, one or more output components346, and one or more storage components348. UID312includes display component302and presence-sensitive input component304. Storage components348of secondary computing device306include communication module320, graph module322, and attack graph data store326.

One or more processors340may implement functionality and/or execute instructions associated with secondary computing device306to generate a local attack graph either for secondary computing device306or for all or a portion of the enclave that includes secondary computing device306. Examples of processors340include application processors, display controllers, auxiliary processors, one or more sensor hubs, and any other hardware configure to function as a processor, a processing unit, or a processing device. Modules320and322may be operable by processors340to perform various actions, operations, or functions of secondary computing device306. For example, processors340of secondary computing device306may retrieve and execute instructions stored by storage components348that cause processors340to perform the operations described with respect to modules320and322. The instructions, when executed by processors340, may cause secondary computing device306to generate a local attack graph and transmit the graph to a central computing device (e.g., central computing device110ofFIG.1).

Communication module320may perform processes for communicating with outside computing devices. For example, communication module320of secondary computing device306may transmit local attack graphs to a central computing device.

In some examples, graph module322may execute locally (e.g., at processors340) to provide functions associated with generating the local attack graphs. In some examples, graph module322may act as an interface to a remote service accessible to secondary computing device306. For example, graph module322may be an interface or application programming interface (API) to a remote server that generates local attack graphs for secondary computing device306.

One or more storage components348within secondary computing device306may store information for processing during operation of secondary computing device306(e.g., secondary computing device306may store data accessed by modules320and322and attack graphs data store326during execution at secondary computing device306). In some examples, storage component348is a temporary memory, meaning that a primary purpose of storage component348is not long-term storage. Storage components348on secondary computing device306may be configured for short-term storage of information as volatile memory and therefore not retain stored contents if powered off. Examples of volatile memories include random access memories (RAM), dynamic random access memories (DRAM), static random access memories (SRAM), and other forms of volatile memories known in the art.

Storage components348, in some examples, also include one or more computer-readable storage media. Storage components348in some examples include one or more non-transitory computer-readable storage mediums. Storage components348may be configured to store larger amounts of information than typically stored by volatile memory. Storage components348may further be configured for long-term storage of information as non-volatile memory space and retain information after power on/off cycles. Examples of non-volatile memories include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. Storage components348may store program instructions and/or information (e.g., data) associated with modules320and322and attack graphs data store326. Storage components348may include a memory configured to store data or other information associated with modules320and322and attack graphs data store326.

Communication channels350may interconnect each of the components312,340,342,344,346, and348for inter-component communications (physically, communicatively, and/or operatively). In some examples, communication channels350may include a system bus, a network connection, an inter-process communication data structure, or any other method for communicating data.

One or more communication units342of secondary computing device306may communicate with external devices via one or more wired and/or wireless networks by transmitting and/or receiving network signals on one or more networks. Examples of communication units342include a network interface card (e.g. such as an Ethernet card), an optical transceiver, a radio frequency transceiver, a GPS receiver, or any other type of device that can send and/or receive information. Other examples of communication units342may include short wave radios, cellular data radios, wireless network radios, as well as universal serial bus (USB) controllers.

One or more input components344of secondary computing device306may receive input. Examples of input are tactile, audio, and video input. Input components344of secondary computing device306, in one example, includes a presence-sensitive input device (e.g., a touch sensitive screen, a PSD), mouse, keyboard, voice responsive system, camera, microphone or any other type of device for detecting input from a human or machine. In some examples, input components344may include one or more sensor components352one or more location sensors (GPS components, Wi-Fi components, cellular components), one or more temperature sensors, one or more movement sensors (e.g., accelerometers, gyros), one or more pressure sensors (e.g., barometer), one or more ambient light sensors, and one or more other sensors (e.g., infrared proximity sensor, hygrometer sensor, and the like). Other sensors, to name a few other non-limiting examples, may include a heart rate sensor, magnetometer, glucose sensor, olfactory sensor, compass sensor, or a step counter sensor.

One or more output components346of secondary computing device306may generate output in a selected modality. Examples of modalities may include a tactile notification, audible notification, visual notification, machine generated voice notification, or other modalities. Output components346of secondary computing device306, in one example, includes a presence-sensitive display, a sound card, a video graphics adapter card, a speaker, a cathode ray tube (CRT) monitor, a liquid crystal display (LCD), a light emitting diode (LED) display, an organic LED (OLED) display, a virtual/augmented/extended reality (VR/AR/XR) system, a three-dimensional display, or any other type of device for generating output to a human or machine in a selected modality.

UID312of secondary computing device306may include display component302and presence-sensitive input component304. Display component302may be a screen, such as any of the displays or systems described with respect to output components346, at which information (e.g., a visual indication) is displayed by UID312while presence-sensitive input component304may detect an object at and/or near display component302.

While illustrated as an internal component of secondary computing device306, UID312may also represent an external component that shares a data path with secondary computing device306for transmitting and/or receiving input and output. For instance, in one example, UID312represents a built-in component of secondary computing device306located within and physically connected to the external packaging of secondary computing device306(e.g., a screen on a mobile phone). In another example, UID312represents an external component of secondary computing device306located outside and physically separated from the packaging or housing of secondary computing device306(e.g., a monitor, a projector, etc. that shares a wired and/or wireless data path with secondary computing device306).

UID312of secondary computing device306may detect two-dimensional and/or three-dimensional gestures as input from a user of secondary computing device306. For instance, a sensor of UID312may detect a user's movement (e.g., moving a hand, an arm, a pen, a stylus, a tactile object, etc.) within a threshold distance of the sensor of UID312. UID312may determine a two or three-dimensional vector representation of the movement and correlate the vector representation to a gesture input (e.g., a hand-wave, a pinch, a clap, a pen stroke, etc.) that has multiple dimensions. In other words, UID312can detect a multi-dimension gesture without requiring the user to gesture at or near a screen or surface at which UID312outputs information for display. Instead, UID312can detect a multi-dimensional gesture performed at or near a sensor which may or may not be located near the screen or surface at which UID312outputs information for display.

In accordance with the techniques of this disclosure, graph module322may generate a local attack graph, which may be stored in attack graphs data store326. This attack graph may be a probabilistic attack graph that include ranked vulnerabilities, or may be a multiplex attack graph. The one or more nodes of the attack graph each indicate a vulnerability for either secondary computing device306, a network connection for secondary computing device306, or another secondary computing device or network connection in the same enclave as secondary computing device306. The one or more edges of the attack graph each indicate a logical connection between two of the vulnerabilities, where one or more of the logical connections may include a condition. In addition to the vulnerabilities and connections, the attack graphs may also include timestamps.

In some instances, graph module322may generate the respective attack graphs during times of low usage, such as where a high amount of CPU cycles in processors340are available or when the network that includes secondary306has a low bandwidth usage. As such, graph module322may determine a low usage period for secondary computing device306, wherein the low usage period is a time period where processors340of secondary computing device306have a high amount of available compute cycles and/or where the network has a low bandwidth usage. Graph module322may then generate the first attack graph occurs during the low usage period for secondary computing device306.

In some instances of generating the first attack graph, graph module322may determine a set of connected devices as all other computing devices in the network where a traceroute distance between secondary computing device306and the other computing device is equal to 1 hop. Graph module322may then perform one or more scans for vulnerabilities within secondary computing device306, as well as one or more scans for vulnerabilities in connections between secondary computing device306and each connected device of the set of connected device. Graph module322may then generate the first attack graph based on the vulnerabilities within the first computing device and the vulnerabilities in connections between secondary computing device306and each connected device of the set of connected device. In such instances, each of the one or more scans for vulnerabilities within secondary computing device306and each of the one or more scans for the vulnerabilities in connections between secondary computing device306and each connected device of the set of connected device is either an authenticated scan or an unauthenticated scan.

In other instances, secondary computing device306may be in a first enclave. In such instances, the first attack graph generated by graph module322may indicate vulnerabilities throughout the first enclave.

Communication module320may transmit the first attack graph from secondary computing device306to a central computing device (e.g., central computing device210) in the network, which may generate the network-level attack graph.

In some instances, graph module322of secondary computing device306may further generate a second attack graph at a later time than the generation of the first attack graph. Graph module322may then generate a first delta attack graph that includes only differences between the second attack graph and the first attack graph. Communication module320may then transmit the first delta attack graph from secondary computing device306to the central computing device210rather than transmitting the entirety of the second attack graph, as most nodes in the attack graphs are likely to be relatively static in nature.

FIG.4is a conceptual diagram illustrating a merging of two attack graphs450A-450B and an attack graph stencil450C to produce a network-level attack graph450D, in accordance with one or more techniques described herein. Attack graph450A may be generated by a first computing device, such as secondary computing device106A ofFIG.1. As shown in attack graph450A, the first computing device has found three connected vulnerabilities, represented as vulnerability nodes452A-452C with logical connections454A-454C.

A second computing device, such as secondary computing device106B ofFIG.1, may generate attack graph450B. Attack graph450B includes same vulnerability node452C as attack graph450A, but also includes vulnerability nodes452D-452E and three new logical connections454D-454F.

The central computing device (e.g., central computing device110) may generate attack graph stencil450C locally with information based on known interactions in the network and known operating systems within the network. However, the central computing device may not be aware of every possible interaction between operating systems within the network, giving the central computing device only a portion of the entire interaction potential. As such, attack graph stencil450C only includes vulnerability nodes452B-452E and logical connections454B and454D-H.

The first and second computing devices transmit attack graphs450A and450B, respectively, to the central computing device, which may merge attack graphs450A and450B with attack graph stencil450C to generate network-level attack graph450D. Attack graph stencil450C includes most of the information for the network, including each vulnerability node and logical connection in attack graph450B. However, attack graph450A also includes vulnerability node452A and logical connections454A and454C. As such, during the merging, the central computing device adds vulnerability node452A and logical connections454A and454C to the attack graph stencil450C to obtain a more complete network-level attack graph450D while also distributing the processing across multiple devices rather than calculating the entire network-level attack graph on the central computing device.

An attack graph (e.g., attack graphs450A-450B) is a network structure, subject to graph theory, where its nodes are a combination of vulnerability findings, attack steps, and aggregated nodes, and the relationship between them can be represented using vertices and arcs. This network structure allows us to reason about the elements of the attack graph and how they relate to one another. One way to reason about the elements of the attack graph and their arcs is to compute a conditional probability of an attack path through the attack graph network.

Here we denote n for number of vertices and m for number of arcs. When an arc, a directional edge, is created by using two vertices u and v, which is represented by uv, then the initial vertex is the u and the terminal vertex is the v in the arc uv.

A graph G=(V, A) with V={v1, v2, vn} whose adjacency matrix A is the n×n square matrix ((aij)) where aijis 1 or 0 depending on whether there is an arc (1) or not (0) between viand vj(vivj). In the case of a probabilistic attack graph the value is 0.0<=aij<=1.0.

A sub-digraph of G to be (V1, A1) where V1 is a subset V, A1 is a subset A and if uv is an element of A1 then u and v belong to V1.

The converse of a digraph G=(V, A) is the digraph H with the same vertex set V, uv being an arc in H if and only if vu is an arc of G. Note that the adjacency matrix of the converse of G is the transpose AT of the adjacency matrix A of G.

A digraph G is said to be symmetric if vu is an arc whenever uv is an arc. G is symmetric if and only if its adjacency matrix is a symmetric matrix. G is said to be asymmetric (or anti-symmetric) if vu is not an arc whenever uv is an arc.

A=(Nd, Np, Ndf, E, Mnl, G) is an attack graph, where Nd, Np, Ndfare called derived nodes, primitive and derived fact nodes respectively; E⊆((Np∪Ndf)×Nd)∪(Nd×Ndf); Mnlis a mapping from a node to its label; G⊆Ndfis an attacker's final goals.

A derived node, Nd, consists of facts derived by applying an interaction rule to other primitive facts and prior derived facts. An interaction between vulnerabilities is called a derived node.

FIG.5is a flow chart illustrating an example network-level attack graph generation process, in accordance with one or more techniques described herein. The techniques ofFIG.5may be performed by one or more processors of various computing devices, such as central computing devices110ofFIGS.1and210ofFIG.2and secondary computing devices106A-106G ofFIGS.1and306ofFIG.3. For purposes of illustration only, the techniques ofFIG.5are described within the context of central computing device210ofFIG.2and secondary computing device306ofFIG.3, although computing devices having configurations different than that of central computing device210and secondary computing device306may perform the techniques ofFIG.5.

In accordance with the techniques described herein, graph module322may generate a first attack graph (502). Another secondary computing device, different than secondary computing device306, may generate a second attack graph (504). These attack graphs may be probabilistic attack graphs that include ranked vulnerabilities, or may be multiplex attack graphs. The one or more nodes of the attack graphs each indicate a vulnerability for the respective secondary computing device or a network connection for respective secondary computing device. The one or more edges of the attack graphs each indicate a logical connection between two of the vulnerabilities, where one or more of the logical connections may include a condition. In addition to the vulnerabilities and connections, the attack graphs may also include timestamps.

In some instances, graph module322and the additional secondary computing device may generate the respective attack graphs during times of low usage, such as where a high amount of CPU cycles are available or when the network has a low bandwidth usage. As such, graph module322may determine a low usage period for secondary computing device306, wherein the low usage period is a time period where processors340of secondary computing device306have a high amount of available compute cycles and/or where the network has a low bandwidth usage. Graph module322may then generate the first attack graph occurs during the low usage period for secondary computing device306.

In some instances of generating the first attack graph, graph module322may determine a set of connected devices as all other computing devices in the network where a traceroute distance between secondary computing device306and the other computing device is equal to 1 hop. Graph module322may then perform one or more scans for vulnerabilities within secondary computing device306, as well as one or more scans for vulnerabilities in connections between secondary computing device306and each connected device of the set of connected device. Graph module322may then generate the first attack graph based on the vulnerabilities within the first computing device and the vulnerabilities in connections between secondary computing device306and each connected device of the set of connected device. In such instances, each of the one or more scans for vulnerabilities within secondary computing device306and each of the one or more scans for the vulnerabilities in connections between secondary computing device306and each connected device of the set of connected device is either an authenticated scan or an unauthenticated scan.

In other instances, secondary computing device306may be in a first enclave, and the additional secondary computing device is in a second enclave different than the first enclave. In such instances, the first attack graph generated by graph module322may indicate vulnerabilities throughout the first enclave, while the second attack graph indicates vulnerabilities throughout the second enclave. In other instances, both secondary computing device306and the additional secondary computing device are both located in a same enclave.

Communication module320may transmit the first attack graph from secondary computing device306to central computing device210in the network (506). Central computing device210may be either a same type of computing device as secondary computing device306or a central server or processing unit. The additional secondary device may transmit the second attack graph from the additional secondary computing device to central computing device210(508).

Communication module220may receive the first attack graph from secondary computing device306and the second attack graph from the additional secondary computing device. Upon receiving these attack graphs, graph module222may generate, based on the first attack graph and the second attack graph, a network-level attack graph by merging the first attack graph, the second attack graph, and an attack graph stencil of cross-device vulnerability interactions (510).

In some instances, graph module222may also generate the attack graph stencil. In such instances, the network further includes a plurality of computing devices (including secondary computing device306and the additional secondary computing device), and generating the attack graph stencil includes graph module222accessing a comprehensive list of known vulnerabilities. Graph module222may determine an operating system for each computing device of the plurality of computing devices in the network. Graph module222then may determine each unique operating system pair based on the operating system for each computing device of the plurality of computing devices. For each unique operating system pair, graph module222may determine, based on the comprehensive list of known vulnerabilities, each interaction vulnerability for the respective unique operating system pair, thereby forming the attack graph stencil. The operating system may one or more of an operating system family and a version number installed on the respective computing device of the plurality of computing devices.

In some instances, graph module322of secondary computing device306may further generate a third attack graph. Graph module322may then generate a first delta attack graph that includes only differences between the third attack graph and the first attack graph. Communication module320may then transmit the first delta attack graph from secondary computing device306to central computing device210. The additional secondary computing device may follow a similar process, generating a fourth attack graph, generating a second delta attack graph that includes only differences between the fourth attack graph and the second attack graph, and transmitting the second delta attack graph from the additional secondary computing device to central computing device210. Communication module220may receive only the first delta attack graph and the second delta attack graph during the process of generating a second, updated network-level attack graph. Graph module222may construct the third attack graph from the first attack graph and the first delta attack graph, and may construct the fourth attack graph from the second attack graph and the second delta attack graph. Graph module222may then generate, based on the third attack graph and the fourth attack graph, a second network-level attack graph by merging the third attack graph, the fourth attack graph, and a second attack graph stencil of cross-device vulnerability interactions.

Graph module222may utilize any number of attack graphs generated by separate secondary devices when merging local attack graphs with the attack graph stencil to generate the network-level attack graph. For instance, one or more additional secondary computing devices may each generate an additional attack graph for the respective additional secondary computing device. Each of these additional secondary computing devices may transmit the respective additional attack graph from the respective additional computing device to central computing device210. Communication module220may receive each of these additional attack graphs. Graph module222may then generate the network-level attack graph by merging all of the first attack graph, the second attack graph, each of the one or more additional attack graphs, and the attack graph stencil.