A method and system for assessing vulnerabilities in network communication transmission nodes

Abstract

This invention belongs to the technical field of computer network security and relates to a method and system for assessing vulnerabilities in network communication transmission nodes. The method includes: matching vulnerabilities based on static attributes of communication nodes, analyzing their exploitation prerequisites and impacts to generate an asset knowledge base; analyzing network topology and access control permissions to generate potential communication topologies; collecting information such as session connections and process activities, and encapsulating it into critical state transition events; determining whether the transition events meet the vulnerability exploitation prerequisites and updating the logical state; generating dynamic attack paths based on the updated logical state and communication topology, constructing a complete attack graph, and calculating a network-wide vulnerability risk score; simulating intervention measures for nodes with risk exposure values ​​greater than a preset threshold, and generating defense hardening strategies based on changes in the risk score. This invention addresses the problem of insufficient accuracy and timeliness in risk assessment results.

Description

Technical Field

[0001] This invention belongs to the technical field of computer network security and relates to a method and system for assessing vulnerabilities in network communication transmission nodes. Background Technology

[0002] In complex communication network environments, security risk assessments face challenges of dynamism and interconnectedness. The communication patterns, operational services, and user activities within the network are constantly changing. These dynamic changes directly affect the exploitability of vulnerabilities, giving attackers the opportunity to construct multi-step attack chains using a series of seemingly disparate events, thereby threatening core network assets.

[0003] In existing technologies, risk assessment typically employs methods such as periodic vulnerability scanning, static attack graph analysis, or security information and event management systems. Periodic vulnerability scanning proactively probes network nodes based on known vulnerability signature databases to identify security flaws. Static attack graph analysis pre-calculates all theoretical attack paths based on the network's fixed topology and node vulnerability information. Security information and event management systems identify potential threats by collecting network-wide logs and event streams and performing correlation analysis using preset rules.

[0004] However, the aforementioned existing technical solutions have certain limitations when dealing with dynamic network environments. Periodic vulnerability scanning only provides snapshots of the state at discrete points in time, which may miss attack windows that appear during the scanning interval. Furthermore, the output vulnerability list lacks correlation, making it difficult to prioritize risk mitigation. Static attack graph analysis, based on fixed network configuration information, struggles to reflect dynamic changes in network traffic and user sessions in real time, and the effectiveness and accuracy of its predicted attack paths at specific moments need improvement. The correlation analysis rules of security information and event management systems largely rely on manual experience for configuration; their coverage and predictive capabilities are limited by the completeness of the rules, and they are insufficient in comprehensively depicting the complex causal relationships between system state changes and vulnerability exploitation conditions. Summary of the Invention

[0005] In a first aspect, the present invention provides a method for assessing vulnerabilities in network communication transmission nodes, comprising the following steps:

[0006] Known vulnerabilities are matched based on the static attributes of communication nodes, and the known vulnerabilities are parsed into the preconditions for exploitation and the impact after exploitation, generating a structured knowledge base of asset vulnerabilities.

[0007] Based on the network topology architecture and firewall access control permissions of the physical network, analyze the theoretical reachability between communication nodes and generate potential communication link topologies.

[0008] Collect session connection data, process activity and user permission change information between communication nodes, and filter and standardize the encapsulation to generate key state transition events;

[0009] Based on a structured knowledge base of asset vulnerabilities, it is determined whether critical state transition events meet the preconditions for vulnerability exploitation, and the logical state is updated according to the determination results.

[0010] Based on the updated logical state, the impact after exploitation, and the potential communication link topology, a directed edge for a dynamic attack path is generated between nodes that meet the permission crossing condition.

[0011] Search all directed edges of dynamic attack paths to generate a complete attack graph, and perform risk calculations on the paths in the complete attack graph to generate a network-wide vulnerability association risk score.

[0012] For nodes in the complete attack graph whose risk exposure value exceeds a preset threshold, simulate intervention measures and generate defense hardening strategies based on the difference in the overall network vulnerability-related risk scores before and after the intervention.

[0013] Preferably, as one possible implementation method, the method involves matching known vulnerabilities based on the static attributes of communication nodes, parsing the known vulnerabilities into preconditions for exploitation and the impact of exploitation, and generating a structured knowledge base of asset vulnerabilities, including the following steps:

[0014] Obtain the hardware configuration, operating system version, and open services of the communication node as static attributes;

[0015] The static attributes are formatted and compared with a preset vulnerability database to identify known vulnerabilities.

[0016] Extract the description text of known vulnerabilities and parse it to generate structured vulnerability exploitation prerequisites and post-exploitation impact;

[0017] Establish a correlation matrix of static attributes, known vulnerabilities, vulnerability exploitation prerequisites, and post-exploitation impact to generate a structured knowledge base of asset vulnerabilities.

[0018] Preferably, as one possible implementation method, based on the network topology architecture of the physical network and firewall access control permissions, the theoretical reachability between communication nodes is analyzed to generate a potential communication link topology, including the following steps:

[0019] Calculate the physical link reachability between communication nodes based on the routing information in the network topology;

[0020] The protocol port pairs between communication nodes are matched against the firewall's access control rule set to determine the reachability of logical policies.

[0021] The logical AND result of physical link reachability and logical policy reachability is used as the theoretical reachability between communication nodes, and a graph structure is constructed based on this to generate potential communication link topologies.

[0022] Preferably, as one possible implementation method, the process involves collecting session connection data, process activity, and user permission change information between communication nodes, filtering and standardizing the data, and generating key state transition events, including the following steps:

[0023] Collect session connection data, process activity, and user permission change information through network traffic probes and host monitoring agents;

[0024] Set filtering rules to filter out new network connections, potential service startups, and privileged account logins as real-time incremental data from the collected information;

[0025] Real-time incremental data is encapsulated into a unified data format that includes event type, subject, and object information to generate critical state transition events.

[0026] Preferably, as one possible implementation method, based on an asset vulnerability structured knowledge base, it determines whether a critical state transition event meets the preconditions for vulnerability exploitation, and updates the logical state according to the determination result, including the following steps:

[0027] Extract event type and event detail parameters from critical state transition events;

[0028] Compare the event details parameters with the condition parameters of the vulnerability exploitation prerequisites indexed from the asset vulnerability structured knowledge base;

[0029] If the comparison result is satisfactory, the Boolean value of the corresponding condition bit in the logical state is flipped to complete the update of the logical state.

[0030] Preferably, as one possible implementation method, based on the updated logical state, the impact after exploitation, and the potential communication link topology, a directed edge for a dynamic attack path is generated between nodes that meet the permission crossing condition, including the following steps:

[0031] Poll the logic status to identify vulnerabilities whose preconditions have all been met and their source nodes;

[0032] Based on the impact of exploiting the vulnerability, determine the new privilege level obtained by the source node;

[0033] In the potential communication link topology, find candidate target nodes that can be reached from the source node, and determine whether the new permission level meets the permission crossing condition for attacking the candidate target node.

[0034] If the permission crossing condition is met, a directed connection with a vulnerability severity score as the weight is generated between the source node and the candidate target node, serving as a directed edge for the dynamic attack path.

[0035] Preferably, as one possible implementation, the step of searching all directed edges of dynamic attack paths to generate a complete attack graph, and calculating the risk of the paths in the complete attack graph to generate a network-wide vulnerability association risk score includes the following steps:

[0036] Starting from a preset initial intrusion point, a graph traversal algorithm is used to search for all reachable directed edges of dynamic attack paths to generate a complete attack graph.

[0037] For each path in the complete attack graph, the risk transmission coefficient of each path is calculated by combining the inverse correlation coefficient of the severity of the vulnerabilities contained therein, the attack difficulty, and the criticality of the path's endpoint node.

[0038] The risk exposure values ​​of all paths are aggregated and normalized to generate a network-wide vulnerability association risk score.

[0039] Preferably, as one possible implementation method, intervention measures are simulated for nodes in the complete attack graph whose risk exposure value is greater than a preset threshold, and a defense hardening strategy is generated based on the difference in the change of the network-wide vulnerability-related risk score before and after the intervention, including the following steps:

[0040] The risk exposure value of each path in the complete attack graph is evaluated, and the attack path with a risk exposure value greater than the preset threshold is identified as a high-risk attack path, and the preceding attack nodes on the high-risk attack path are extracted.

[0041] In the digital twin, for each of the extracted preceding attack nodes, the corresponding logical state is simulated to be revoked or the virtual patch is simulated to be implemented.

[0042] Based on the simulated digital twin state, the steps for generating the network-wide vulnerability association risk score are repeated to obtain the simulated score.

[0043] The simulated intervention action that caused the largest decrease in the overall network vulnerability association risk score was selected and converted into a sequence of instructions to generate a defense hardening strategy.

[0044] Preferably, as one possible implementation, the risk exposure values ​​of all paths are aggregated, including the following steps:

[0045] The attack success probability of each path is calculated based on the length of each path and the preset single-step attack success probability.

[0046] The risk transmission coefficient of each path is multiplied by the probability of successful attack to obtain the risk exposure value of each path;

[0047] The risk exposure values ​​of all paths are summed to obtain the total risk exposure value, and a network-wide vulnerability association risk score is generated based on the total risk exposure value.

[0048] Secondly, this invention provides a network communication transmission node vulnerability assessment system, comprising the following modules:

[0049] The knowledge base construction module matches known vulnerabilities based on the static attributes of communication nodes, and parses the known vulnerabilities into the preconditions for exploitation and the impact after exploitation, generating a structured knowledge base of asset vulnerabilities.

[0050] The topology initialization module analyzes the theoretical reachability between communication nodes and generates potential communication link topologies based on the physical network topology architecture and firewall access control permissions.

[0051] The state event capture module is used to collect session connection data, process activity and user permission change information between communication nodes, and to filter and standardize the encapsulation to generate key state transition events.

[0052] The state determination and update module, based on the asset vulnerability structured knowledge base, determines whether critical state transition events meet the preconditions for vulnerability exploitation, and updates the logical state according to the determination results.

[0053] The attack path reconstruction module generates dynamic directed edges for attack paths between nodes that meet the permission crossing conditions, based on the updated logical state, the impact after exploitation, and the potential communication link topology.

[0054] The risk calculation module is used to search for all directed edges of dynamic attack paths to generate a complete attack graph, and to calculate the risk of the paths in the complete attack graph to generate a network-wide vulnerability association risk score.

[0055] The defense strategy generation module is used to simulate intervention measures for nodes whose risk exposure value in the complete attack graph is greater than a preset threshold, and generate defense hardening strategies based on the difference in the change of the network vulnerability-related risk score before and after the intervention.

[0056] In summary, the present invention has the following beneficial technical effects:

[0057] 1. This invention constructs a structured knowledge base of asset vulnerabilities and captures key state transition events in the network in real time to dynamically update the logical states associated with vulnerability exploitation prerequisites, thereby effectively linking static vulnerability information with dynamic network behavior. This mechanism enables vulnerability exploitability determination to be based on the current actual operating state of the network, which helps improve the accuracy and timeliness of vulnerability assessment results compared to traditional methods that rely on static configurations or periodic snapshot scans.

[0058] 2. This invention, based on real-time updated vulnerability exploitation conditions and combined with the impact of vulnerability exploitation and a preset network topology, generates directed edges for dynamic attack paths between nodes that meet the permission crossing conditions, constructing an attack graph that evolves with the network state. This dynamic attack graph enables the identification and analysis of potential attack chains across nodes and multiple steps, providing a technical approach for in-depth understanding of complex and interconnected risks.

[0059] 3. This invention simulates the implementation of defense hardening measures in a digital twin and performs quantitative evaluation based on changes in the overall network risk score before and after intervention, enabling a preliminary assessment of the effectiveness of different defense measures. This provides data support for the selection of defense strategies, helping to identify solutions with better risk reduction effects before actual deployment, thereby improving the rationality and accuracy of security operation and maintenance decisions. Attached Figure Description

[0060] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. The drawings are used to provide a further understanding of the present invention.

[0061] Figure 1 A flowchart illustrating an embodiment of this application is disclosed.

[0062] Figure 2 Structural schematic diagrams of embodiments of this application are disclosed. Detailed Implementation

[0063] The following is in conjunction with the appendix Figure 1 - Figure 2 A preferred description of the present invention is provided below.

[0064] See attached document Figure 1 This invention proposes a method for assessing vulnerabilities in network communication transmission nodes, comprising the following steps:

[0065] S1. Based on the static attributes of communication nodes, match known vulnerabilities and parse the known vulnerabilities into the preconditions for vulnerability exploitation and the impact after exploitation, and generate a structured knowledge base of asset vulnerabilities.

[0066] S2. Based on the network topology architecture and firewall access control permissions of the physical network, analyze the theoretical reachability between communication nodes and generate potential communication link topologies;

[0067] S3. Collect session connection data, process activity and user permission change information between communication nodes, and perform filtering and standardized encapsulation to generate key state transition events;

[0068] S4. Based on the structured knowledge base of asset vulnerabilities, determine whether the critical state transition events meet the preconditions for vulnerability exploitation, and update the logical state according to the determination results.

[0069] S5. Based on the updated logical state, the impact after exploitation, and the potential communication link topology, dynamic attack path directed edges are generated between nodes that meet the permission crossing conditions.

[0070] S6. Search for all directed edges of dynamic attack paths to generate a complete attack graph, and perform risk calculation on the paths in the complete attack graph to generate a network-wide vulnerability association risk score.

[0071] S7. Simulate intervention measures for nodes whose risk exposure value in the complete attack graph is greater than a preset threshold, and generate a defense hardening strategy based on the difference in the change of the network vulnerability-related risk score before and after the intervention.

[0072] In one embodiment of the present invention, step S1 includes the following steps:

[0073] The hardware configuration, operating system version, and open services of the communication node are obtained as static attributes; the static attributes are formatted and compared with a preset vulnerability database to match known vulnerabilities; the description text of the known vulnerabilities is extracted and parsed to generate structured vulnerability exploitation prerequisites and post-exploitation impact; an association matrix of static attributes, known vulnerabilities, vulnerability exploitation prerequisites, and post-exploitation impact is established to generate a structured knowledge base of asset vulnerabilities.

[0074] A structured knowledge base for asset vulnerabilities is constructed, and a mapping relationship between the static attributes and security attributes of physical communication nodes is established. The specific implementation process is as follows:

[0075] A knowledge base building engine is deployed as the execution entity on a dedicated server independent of the physical production network. First, the static attributes of each communication node in the communication network are identified. Query requests are sent to the intelligent management unit within the node via the standard network management protocol SNMP, or by logging into each node via the secure shell protocol SSH to execute predefined system information collection scripts. For example, shell scripts containing commands such as `lscpu`, `free -g`, and `cat / etc / os-release` are used to obtain the node's CPU model, memory capacity, and the number and model of network interface cards. This data constitutes the hardware configuration information. Simultaneously, by parsing the system fingerprint information released by the node's operating system, or by reading the system registry and version configuration files, the major version number, minor version number, and patch package version number of the operating system are determined.

[0076] For open system services, the network port scanning tool Nmap is used to initiate TCPSYN and UDP scans on the IP addresses of each node to detect ports in the LISTEN state. Based on the port number service mapping relationship assigned by IANA and the flag information extracted from the scan response, the corresponding service name and version are identified. It should be noted that in this embodiment, static attributes refer to the inherent configuration information of the communication node. Specific items include: hardware configuration, covering CPU model, number of cores, memory capacity in GB, and network interface card model; operating system version following the format of major version number.minor version number.build number; open system services, referring to software processes listening for connection requests on the node's network interface, identified by protocol, port number, and service software name and version number. The collected hardware configuration, operating system version, and open service list are organized by node IP address and stored in a local relational database table to complete the extraction of static attributes of the communication nodes. During implementation, the port scan timeout can be set to 2000 ms to 5000 ms to ensure effective response in complex network environments.

[0077] Based on the static attributes of the communication nodes, the corresponding set of known vulnerabilities is matched against the vulnerability database. A generic vulnerability disclosure (CVE) database is loaded from the local image. Each record in this database contains a CVE number, an enumerated CPE expression for the affected product configuration platform, a vulnerability description, and a CVSS score. The static attributes of each node, particularly the operating system version and the open services and their versions, are formatted into a standard CPE syntax string. The matching process compares the node's CPE string with the affected configuration CPE expressions in the CVE database using either a database query language (SQL) LIKE fuzzy match or a dedicated CPE matching library.

[0078] When a node's CPE string satisfies the version range constraint of the CPE expression affecting the configuration in the vulnerability record, the vulnerability is determined to be related to that node. All successfully matched CVE records are aggregated into the known vulnerability set for that node. It should be understood that the known vulnerability set refers to the set of vulnerabilities that affect the hardware and software configuration described by the node's static attributes, obtained from a standard vulnerability database, and each vulnerability is identified by a unique CVE number. For version comparison during the CPE matching process, a semantic version comparison algorithm is preferably used to handle special cases such as leading zeros and letter suffixes in the version number.

[0079] Next, each vulnerability in the known vulnerability set is parsed into machine-readable exploit prerequisites and post-exploitation impact. The descriptive text in the CVE records is read, and key entities are extracted using rule-based regular expressions, or a pre-trained Natural Language Processing (NLP) model is invoked for named entity recognition and relation extraction. For exploit prerequisites, the parser identifies and formats conditional items such as required network access permissions, required authentication status, and specific service components and versions that are dependent. For example, descriptions such as requiring authentication or allowing remote attackers to exploit without authentication are extracted from the text and converted into Boolean fields.

[0080] In this embodiment, the preconditions for exploitation are a set of system or network states that must be met for successful exploitation, described in a machine-readable structure. The data structure contains one or more condition items, each consisting of a condition type and condition parameters. Regarding the post-exploitation impact, the parser identifies effect type keywords, such as gaining administrator privileges, executing arbitrary code, or causing denial of service, and maps them to predefined enumeration values. It may also extract relevant affected files or resource identifiers. The post-exploitation impact is a security effect on the target node after successful exploitation, described in a machine-readable structure. The data structure includes impact type and impact scope, with the impact type being a predefined enumeration value.

[0081] The parsed results are stored as a structured JSON object, containing a list of preconditions and fields describing the impact. In natural language parsing, if a rule-based approach is used, the regular expression pattern library needs to cover common vulnerability description phrases; if a model-based approach is used, the BERT model, fine-tuned for cybersecurity text, can be used, with its output layer designed to simultaneously perform entity recognition and relationship classification. A similarity threshold of 0.7 to 0.9 can be set to determine the confidence level of the match between the extracted entities and predefined categories.

[0082] Establish an association matrix of static attributes, known vulnerability sets, vulnerability exploitation prerequisites, and post-exploitation impacts to generate a structured knowledge base of asset vulnerabilities. Create a sparse matrix data structure where row indices are unique node identifiers and column indices are unique vulnerability identifiers extracted from all known vulnerability sets. Each non-empty cell in the matrix stores an associated data packet. The content of this data packet includes: a key CPE string extracted from the node's static attributes for matching the vulnerability, a vulnerability-parsed prerequisite object, and a vulnerability-parsed impact object.

[0083] In this embodiment, the association matrix is ​​a sparse data structure used to efficiently store the multidimensional associations between nodes and vulnerabilities. It can be implemented using an adjacency list based on hash mapping, where the row key is the node's IP address, the column key is the CVE number, and the values ​​are associated data packets containing preconditions and impact objects. The association matrix is ​​ultimately serialized and stored as a subgraph in a graph database, where node entities represent physical communication nodes and CVE vulnerabilities, and edge relationships represent the existence of vulnerabilities and attributes consisting of preconditions and impacts, thus completing the construction of a structured knowledge base for asset vulnerabilities.

[0084] The process of building a structured knowledge base for asset vulnerabilities is illustrated below:

[0085] Assume there is a communication node in the target network with the IP address 192.168.1.100. The knowledge base building engine first performs static attribute identification on this node. It logs into the node via SSH, executes the `uname` command to obtain the operating system kernel information, and reads the ` / etc / os-release` file, confirming that its operating system is Ubuntu 22.04.2 LTS. Next, it executes the `lscpu` and `free` commands, obtaining the hardware configuration as an 8-core CPU and 16GB of memory. Subsequently, it uses the Nmap tool to scan 192.168.1.100, performing a TCP SYN scan with the `-sS` parameter, finding open TCP ports 22 and 80. Using the `-sV` parameter for version detection, it identifies that OpenSSH 8.9p1 is running on port 22 and Apache httpd 2.4.52 is running on port 80. This information is then integrated to form the static attribute record for this node.

[0086] Next, vulnerability matching is performed. The node attributes are formatted as CPE strings: `cpe:2.3:o:canonical:ubuntu_linux:22.04.2:*:*:*:*:*:*:* (operating system)` and `cpe:2.3:a:apache:http_server:2.4.52:*:*:*:*:*:*:* (service). A query is performed in the local CVE database to look for vulnerability records whose affected configuration CPE matches the above strings or a wider version. For example, if the query finds that the affected configuration for CVE-2023-25690 contains `cpe:2.3:a:apache:http_server:*:*:*:*:*:*:` and the version range covers 2.4.52, and the affected configuration for CVE-2023-38408 contains `cpe:2.3:a:openbsd:openssh:*:*:*:*:*:*:*:` and the version range covers 8.9p1, then... Then add CVE-2023-25690 and CVE-2023-38408 to the known vulnerability set of this node.

[0087] Analyzing the vulnerabilities, for CVE-2023-25690, its description text, "...the mod_proxy module may cause HTTP request smuggling under certain configurations...", reveals the preconditions as "mod_proxy module enabled" and "specific proxy configuration exists," with the impact being "HTTP request smuggling, potentially leading to security bypass." The parsed result is a JSON object: {"preconditions":[{"type":"module_enabled","params":"mod_proxy"},{"type":"config_exists","params":"proxy-relateddirectives"}],"impact":{"type":"SECURITY_BYPASS","scope":"HTTP traffic"}}. For CVE-2023-38408, the parsed preconditions are remote connection permission and public key forwarding enabled, with the impact being privilege escalation.

[0088] Finally, an association matrix is ​​constructed. In the matrix, the row node is "192.168.1.100", and the columns are the vulnerabilities "CVE-2023-25690" and "CVE-2023-38408". The corresponding cells contain the associated data packets. For CVE-2023-25690, the data packet contains the matching CPE string "cpe:2.3:a:apache:http_server:2.4.52", as well as the preconditions and affected objects obtained from the parsing. The data packet for CVE-2023-38408 is constructed similarly. This sparse matrix is ​​then persisted, forming the initial data for the structured knowledge base of asset vulnerabilities.

[0089] In one embodiment of the present invention, step S2 includes the following steps:

[0090] Based on the routing information in the network topology, the physical link reachability between communication nodes is calculated; the protocol port pairs between communication nodes are matched with the rule set of firewall access control permissions to determine the logical policy reachability; the logical AND result of physical link reachability and logical policy reachability is used as the theoretical reachability between communication nodes, and a graph structure is constructed based on this to generate the potential communication link topology.

[0091] The initialization of the potential communication link topology between nodes establishes the logical connection foundation in the digital twin. The specific implementation process is as follows:

[0092] On the same dedicated server where the knowledge base building engine is deployed, the engine is initialized as the execution entity. First, the original network topology, routing protocols, and firewall access control permissions of the physical communication network are obtained. It should be noted that the original network topology refers to the actual connection model between network devices and communication nodes in the physical network, including but not limited to the identifiers of switches, routers, and host nodes, as well as the physical or logical link information connecting these devices. Routing protocols refer to the set of rules that determine the path of data packets from source to destination in the network. Firewall access control permissions refer to the set of rules configured by security devices deployed on critical network nodes to allow or deny network traffic with specific characteristics.

[0093] By invoking the Simple Network Management Protocol (SNMP), the system queries the ipRouteTable and ipNetToMediaTable entries in the Management Information Base (MIB) of core switches and routers in the network to obtain the network-wide IPv4 routing table and Address Resolution Protocol (ARP) table, thereby inferring subnetting and Layer 3 device interconnection relationships. Simultaneously, the system logs into each layer of network devices via Secure Shell (SSH) and executes display commands such as `show cdp neighbors` or `show lldp neighbors` to obtain link layer discovery protocol information and establish Layer 2 connections between devices. The original network topology is composed of these collected node device identifiers, interface identifiers, and connection relationship data, cached in memory as an adjacency table.

[0094] For routing and forwarding protocols, the source protocol field of each route entry is identified by analyzing the routing table collected from the router, such as Open Shortest Path First (OSPF), Border Gateway Protocol (BGP), or static routes, and its metric value is recorded. For firewall access control permissions, the firewall deployed at the network boundary and the internal distributed firewall agent are connected via SSH or an application programming interface (API) to read their currently effective Access Control List (ACL) rule sets. Each rule contains a source IP address range, a destination IP address range, a protocol type, a port range, and an action flag indicating whether to allow or deny the request.

[0095] Based on the original network topology and firewall access control permissions, the theoretical reachability between communication nodes in terms of physical links and logical policies is analyzed. The analysis process consists of two layers.

[0096] The first layer is physical link reachability analysis: Based on the original network topology, the IP addresses of each node are obtained from the asset vulnerability structured knowledge base and treated as terminal hosts in the network. Simulated packet forwarding is performed, and based on the collected routing table, it is calculated whether a valid IP-layer forwarding path exists from the source node IP to the destination node IP. This is achieved by performing longest prefix matching between the source node IP and routing table entries. If a next hop is found and the recursive query ultimately points to a directly connected interface, the physical link is considered reachable. In physical link reachability analysis, the timeout for route lookup can be set to 1000ms.

[0097] The second layer is logical policy reachability analysis: Firewall access control permissions are loaded, and the IP addresses of the source and target nodes, along with preset protocol port pairs to be evaluated, are sequentially substituted into each ACL rule for matching tests. In this embodiment, the preset protocol port pairs used for testing typically select well-known ports ranging from 1 to 1024. For firewall rules containing address groups in logical policy analysis, the groups must first be expanded into a specific list of IP addresses before matching. Matching follows the top-down order of the rule list and the first-match principle. If a rule allowing action is matched and is not blocked by preceding deny rules, the logical policy is determined to be reachable for that protocol port pair.

[0098] Ultimately, theoretical reachability is defined as the logical AND result of physical link reachability and logical policy reachability. It should be understood that theoretical reachability is a Boolean-type determination used to describe whether a path exists between two communicating nodes based on the static configuration and policies of the network infrastructure that might allow data packet transmission; its determination requires both physical link connectivity and logical policy permission. For a pair of nodes, if at least one protocol port pair satisfies the above conditions, then the pair of nodes is determined to be theoretically reachable.

[0099] Using communication nodes as vertices and theoretical reachability as undirected edges, a graph structure representing the initial communication capability between nodes is constructed, generating a potential communication link topology. It should be noted that undirected edges are a fundamental concept in graph theory, here representing the potential for bidirectional communication between two communication nodes. This symmetry is based on the analysis of fundamental network strategies. A graph structure is a mathematical model composed of vertices and edges used to represent objects and their relationships. In this step, its specific implementation can be an adjacency matrix or an adjacency list. The potential communication link topology specifically refers to the graph structure generated in this step that reflects the fundamental connectivity capability of the network; it serves as the static baseline for subsequent dynamic attack path analysis. A list of all identified node IP addresses is extracted from the asset vulnerability structured knowledge base, with each unique IP address representing a vertex.

[0100] For any two distinct vertices, the theoretical reachability analysis function is invoked. If the analysis function returns true, an undirected edge is created between the two vertices. The graph structure is implemented in memory using an adjacency list data structure, where each vertex maintains a linked list storing the IDs of all adjacent vertices connected to it by an edge. Additionally, each edge can be associated with a set of attributes recording a list of specific protocol port pairs that make it reachable. The completed graph structure is serialized into a JSON or graph database format file and stored on disk. This file represents the initial logical connection base in the digital twin used for subsequent attack path analysis, i.e., the potential communication link topology.

[0101] An example of the process for initializing the potential communication link topology between nodes is as follows:

[0102] Continuing from the S1 example, assume the asset vulnerability structured knowledge base already contains node 192.168.1.100. The initialization engine discovers another node, 192.168.1.200, in the network via the network management protocol and confirms it as a communication node. The routing table obtained from the core switch shows that the next hop to network 192.168.1.0 / 24 is a direct connection, determining that the physical link between nodes 192.168.1.100 and 192.168.1.200 is reachable. Next, the firewall's access control list is read. Assume there is a rule: source address 192.168.1.0 / 24, destination address 192.168.1.0 / 24, protocol TCP, action allowed. The IP addresses of the source node 192.168.1.100 and the destination node 192.168.1.200, along with the TCP / 445 protocol port to be tested, are substituted into the rule. Since both IPs belong to the 192.168.1.0 / 24 network segment, the rule match is successful, and the action is permitted. Therefore, the logical policy is reachable via TCP / 445. Considering both the physical link and the logical policy determination, it is determined that the node has theoretical reachability between 192.168.1.100 and 192.168.1.200.

[0103] Next, the graph structure is constructed. The vertex set is {192.168.1.100, 192.168.1.200}. For this pair of vertices, since the theoretical reachability is true, an undirected edge is created between them. This edge is associated with an attribute that records a list of protocol port pairs, for example, [{"protocol":"tcp","port":445}]. The final generated potential communication link topology is represented in the form of an adjacency list: the adjacency list of vertex 192.168.1.100 contains 192.168.1.200, and the adjacency list of vertex 192.168.1.200 contains 192.168.1.100. The graph structure is serialized and stored, for example, generating a JSON file: {"vertices":["192.168.1.100","192.168.1.200"],"edges":[[0,1,{"allowed_services":[{"protocol":"tcp","port":445}]}]]}, where vertex indices 0 and 1 correspond to two IP addresses. This file completes the initialization of the logical connection base.

[0104] In one embodiment of the present invention, step S3 includes the following steps:

[0105] By using network traffic probes and host monitoring agents, session connection data, process activity, and user permission change information are collected; filtering rules are set to select new network connections, potential service startups, and privileged account logins as real-time incremental data from the collected information; the real-time incremental data is encapsulated into a unified data format containing event type, subject, and object information to generate key state transition events.

[0106] The process of monitoring and capturing key state transition events in the physical network to achieve state synchronization between the digital twin and the physical entity is as follows:

[0107] Network traffic probes are deployed in bypass mode at key aggregation nodes of the physical communication network, and host monitoring agents are installed on all communication nodes requiring monitoring, together forming the event acquisition layer. It should be understood that network traffic probes refer to hardware or software devices or modules deployed in network links to capture, parse, and analyze transmitted data packets; their operating mode is passive listening. Host monitoring agents refer to lightweight software daemons installed on the target operating system to collect information about internal system activity. An independent event processing server acts as the central execution entity, connecting to the probes and agents through a secure channel. The server invokes the network traffic probes to collect session connection data between nodes in real time. The probes operate in promiscuous mode on the network interface card (NIC), performing deep packet inspection on the mirrored network traffic to extract the five-tuple information of Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) sessions, including source IP address, source port, destination IP address, destination port, and protocol type, and recording the session's start and end timestamps. Session connection data refers to the metadata of the logical communication channel established at the transport layer, with the core being the five-tuple plus the session's lifecycle timestamp.

[0108] Simultaneously, the server invokes the host monitoring agent to synchronously capture node process activity and user permission change information. The agent listens for system call events related to process creation and termination through operating system hook mechanisms or performance counter interfaces, recording the process identifier, parent process identifier, executable file path, and startup command-line parameters. Process activity information refers to dynamic information related to the creation, execution, and destruction of process instances within the operating system. For user permission changes, the agent listens to the security subsystem logs or directly queries the user session list, capturing user login, logout, and permission token change events, recording the username, security identifier, login type, and source IP address. User permission change information refers to events related to changes in system account authentication and authorization status.

[0109] The event processing server filters real-time incremental data involving new network connections, service port openings, and privileged account logins using preset filtering rules. These preset filtering rules are a set of Boolean conditions used to identify specific patterns from the continuous data stream that have a potential impact on security. The server maintains a dynamically updated connection state table in memory, recording historical session information. The filtering rules are defined as follows: For network connection data, the currently collected session 5-tuple is compared with the connection state table. If no identical active session record exists, the session is marked as a new network connection. Simultaneously, it checks whether the session's target port belongs to a preset list of critical service ports. If so, it is further marked as a service port opening event, regardless of whether the port has been used by other sessions previously. The list of critical service ports in the event typically includes common database ports, remote management ports, and vulnerable service ports.

[0110] When collecting data, network probes can use a 1:1 sampling rate or, under extremely high traffic conditions, a sampling rate such as 1:100, and record the sampling factor. For process activity data, rules check whether the executable file path of a newly created process matches a predefined system service binary path pattern; if so, it is marked as a potential service startup event. For user permission change data, rules check whether the logged-in user's username or their user group exists in the privileged account list; if so, it is marked as a privileged account login event. The privileged account list in the event needs to be predefined according to organizational policies and typically includes account names such as administrator, root, and domain administrator, or their corresponding security groups. All marked data constitutes real-time incremental data, separated from the original data stream. Real-time incremental data specifically refers to the subset of data that has changed compared to the previous state after being processed by filtering rules.

[0111] The server standardizes and encapsulates real-time incremental data to generate critical state transition events that drive updates to the digital twin's state. Standardization and encapsulation refers to the process of converting raw data from different sources and formats into a standardized data format according to a predefined, unified architecture. Critical state transition events are standardized and encapsulated data units that represent discrete, observable state transition points in the physical network that can cause changes in the security logic state within the digital twin. The encapsulation process follows a unified event pattern. Each event is constructed as a JSON object containing the following required fields:

[0112] A unique identifier for the event, generated from a timestamp and a random number;

[0113] Event types, enumerated values ​​such as NET_CONNECTION_NEW, SERVICE_PORT_OPEN, PRIVILEGED_LOGIN;

[0114] Event source, identifying the probe or agent ID that generated the data;

[0115] A timestamp indicates the precise time an event occurred.

[0116] The subject refers to the IP address or hostname of the node directly affected by the event;

[0117] The object refers to the IP address or resource identifier of the other node associated with the event;

[0118] Details, a nested object, contains specific parameters for the event. For example, for the NET_CONNECTION_NEW type, details include the protocol, source port, and destination port; for the PRIVILEGED_LOGIN type, details include the username and login source.

[0119] The encapsulated events are serialized into strings and published to a designated topic in a high-throughput message queue such as Apache Kafka. This allows the downstream digital twin decision engine to subscribe and consume the events, thus driving state synchronization. The aging time for records in the connection state table of the event processing server can be set to 24 hours to clean up old sessions. The event retention policy in the message queue can be set to retain the most recent 1 million events or retain events for 7 days to ensure consumption reliability.

[0120] The following is an example of the process of listening to and capturing critical state transition events in a physical network:

[0121] Continuing from the S2 example, assume a host monitoring agent is installed on node 192.168.1.100. A network traffic probe is deployed on a mirror port of a switch connected to the same network segment as this node. After the event handling server starts, it continuously receives data from these two sources. At a certain point, the probe captures a new TCP handshake packet, parsing out the 5-tuple as: source IP 192.168.1.150, source port 55000, destination IP 192.168.1.100, destination port 22, protocol TCP. The server queries the connection state table in memory and finds no active record for this 5-tuple, so it marks it as a new network connection event according to the rules. Simultaneously, since destination port 22 is in the preset list of critical service ports, this event is also marked as a service port open event. Subsequently, the host monitoring agent reports a process activity message: on node 192.168.1.100, the sshd process with process ID 1234 has started. The filtering rule checks the executable path ` / usr / sbin / sshd`, matches the system service binary path pattern, and marks it as a potential service startup event. Shortly after, the agent reports a user permission change: user `admin` successfully logged into node 192.168.1.100 from IP 192.168.1.150. The filtering rule checks that the username `admin` exists in the privileged account list and marks it as a privileged account login event.

[0122] Next, the server standardizes and encapsulates these three real-time incremental data entries. For the newly added network connection event, a JSON object is generated: `{"event_id":"e123456789","type":"NET_CONNECTION_NEW","source":"net-probe-01","timestamp":"2023-10-27T10:30:00.123Z","subject":"192.168.1.100","object":"192.168.1.150","details":{"protocol":"tcp","local_port":22,"remote_port":55000}}`. For the "privileged account login" event, a JSON object is generated: `{"event_id":"e123456790","type":"PRIVILEGED_LOGIN","source":"host-agent-100","timestamp":"2023-10-27T10:30:05.456Z","subject":"192.168.1.100","object":"admin","details":{"source_ip":"192.168.1.150"}}`. Potential service startup events are also encapsulated in a similar format. Finally, these three encapsulated critical state transition events are sequentially published to a Kafka topic named "security-state-events," awaiting pull and processing by the digital twin's decision engine, thus achieving the synchronous injection of physical network state into the digital space.

[0123] In one embodiment of the present invention, step S4 includes the following steps:

[0124] Extract event type and event detail parameters from critical state transition events; compare the event detail parameters with the condition parameters of vulnerability exploitation prerequisites indexed from the asset vulnerability structured knowledge base; if the comparison result is satisfactory, invert the Boolean value of the corresponding condition bit in the logical state to complete the logical state update.

[0125] The logical state of the vulnerability exploitation prerequisites is updated, and the micro-trigger points of the security exploitation chain are determined. The specific implementation process is as follows:

[0126] The decision engine in the digital twin, acting as the execution entity, first continuously consumes critical state transition events published by the event processing server from the message queue. It's important to note that the decision engine refers to the software component or module within the digital twin responsible for receiving events, performing logical reasoning, and updating its internal state. The critical state transition events are then input into the decision engine's processing pipeline. The event JSON object is parsed, extracting the event type, subject IP address, object information, and details fields. Subsequently, based on the event's subject IP address, the asset vulnerability structured knowledge base is queried, and all vulnerability entries associated with that IP address are indexed from the association matrix. For each associated vulnerability, its machine-readable exploit prerequisite set is further extracted.

[0127] Next, a logical matching algorithm is used to calculate whether critical state transition events satisfy specific vulnerability exploitation preconditions. The logical matching algorithm is a set of rules that compares real-time event data with static vulnerability preconditions to determine if the conditions are met. The matching algorithm executes independently for each precondition item for each vulnerability. The algorithm compares the parameters in the event details with the condition parameters defined in the precondition items. The matching rules are preset based on the condition type:

[0128] If the condition type is network reachability, the algorithm checks if there is an event of type NET_CONNECTION_NEW or SERVICE_PORT_OPEN, and the target IP address, protocol, and port in the event details are completely consistent with the condition parameters; if the condition type is authentication status, the algorithm checks if there is an event of type PRIVILEGED_LOGIN or an event containing a specific username, and the username in the event details matches the condition parameters.

[0129] If the condition type is "Service Component Enabled," the algorithm checks for the existence of an event of type "SERVICE_PORT_OPEN" or "Potential Service Startup," where the service identifier in the event details matches the condition parameters. The matching result is a Boolean value; it is true if the event parameters satisfy all constraints of the condition item, and false otherwise. To ensure timeliness, the event processing delay during logical matching algorithm execution must be controlled within milliseconds. For network reachability condition type matching, in addition to checking the protocol port, the potential communication link topology generated in step S2 can also be used for verification to ensure the path exists.

[0130] The Boolean values ​​of the corresponding condition bits are toggled in real time based on the calculation results, updating the logical state stored in the digital twin's memory. It should be understood that the logical state is a dynamic data structure maintained by the digital twin in memory, used to track and record in real time whether each exploit prerequisite for each vulnerability has been met. The Boolean value of a condition bit indicates the satisfied state of a single condition item stored in the logical state. The toggle operation refers to the atomic operation that changes the Boolean value of a condition bit from its current state to the opposite state. A global logical state table is maintained; it is a two-dimensional key-value structure. The first-level key is the unique identifier of the vulnerability (CVE number), and the second-level key is the unique identifier of each prerequisite item under that vulnerability. The value corresponding to each key is a Boolean variable, i.e., a condition bit.

[0131] During initialization, all condition bits are set to false by default. The logical state table can be initialized by loading historical states from persistent storage or by completely resetting it to false when the digital twin starts. When the logical matching algorithm determines that an event meets a specific precondition, the decision engine flips the Boolean value corresponding to that condition bit from false to true. The flipping operation is atomic, and the system records the timestamp of the flip and the event ID that triggered the event. The updated logical state table is persisted to an in-memory database or a file, providing the latest exploit condition fulfillment status for subsequent steps. If a condition is met but a subsequent event indicates that the condition is no longer true, such as a network connection being lost, the corresponding condition bit can be reset to false according to a policy. The reset policy can be based on the event type or set a state timeout for automatic reset, such as a connection termination event or maintaining a true state for 300 seconds. If an event simultaneously satisfies multiple conditions for multiple vulnerabilities, the engine updates all relevant condition bits in parallel.

[0132] The following is an example of the process for updating the logical state of the preconditions for exploiting a vulnerability:

[0133] Continuing from the S3 example, the decision engine consumes a critical state transition event from the Kafka topic "security-state-events". The event ID is e123456789, the type is NET_CONNECTION_NEW, the subject is 192.168.1.100, the object is 192.168.1.150, and the details include the protocol TCP and the local port 22. Based on the subject IP address 192.168.1.100, the engine queries the asset vulnerability structured knowledge base and indexes the associated vulnerability CVE-2023-38408. The engine extracts the exploit prerequisite object for CVE-2023-38408 from the knowledge base, which contains a condition item: type is network reachability, and parameters are protocol TCP and port 22.

[0134] Next, the logical matching algorithm is executed. For this condition, the algorithm checks if the event type is NET_CONNECTION_NEW, if the protocol in the event details is TCP, and if the port is 22. Since event e123456789 fully satisfies these constraints: TCP protocol, port 22, correct event type, and the source host matches the implied network reachability meaning of the condition, the algorithm determines that the event meets this prerequisite and outputs a boolean value of true.

[0135] Then, the logical state is updated. In the logical state table, the network reachability condition entry under the key CVE-2023-38408 is located. The initial value of this condition bit is false. If the match result is true, a flip operation is performed to update its value to true. At the same time, the timestamp "2023-10-27T10:30:00.123Z" and the trigger event ID "e123456789" are recorded. The state table is updated, for example, represented in memory as: {"CVE-2023-38408":{"network_accessibility_tcp_22":true}}.

[0136] Subsequently, event e123456790 is consumed, with type PRIVILEGED_LOGIN, subject 192.168.1.100, and object admin. Similarly, indexing CVE-2023-38408 reveals another precondition: authentication status, with the parameter "user is logged in." The matching algorithm checks that the event type is PRIVILEGED_LOGIN and the username admin satisfies the generalized meaning of "user is logged in," thus determining that the condition is met and outputting true. The authentication status condition bit under CVE-2023-38408 in the logical status table is flipped again, updating from false to true. At this point, both precondition bits of CVE-2023-38408 are set to true, indicating that the micro-trigger point of this vulnerability has been activated at the current moment.

[0137] In one embodiment of the present invention, step S5 includes the following steps:

[0138] The system polls the logical state to identify vulnerabilities whose preconditions have all been met and their source nodes. Based on the impact of exploiting the vulnerabilities, it determines the new privilege level granted to the source node. It searches the potential communication link topology for candidate target nodes reachable from the source node and determines whether the new privilege level satisfies the privilege crossing conditions for attacking the candidate target node. This includes: obtaining the authentication status required for known vulnerabilities on the candidate target node from the asset vulnerability structured knowledge base; comparing the new privilege level granted to the source node with the authentication status required for known vulnerabilities on the candidate target node; if the new privilege level meets the authentication status requirements, the privilege crossing condition is deemed met; if the privilege crossing condition is met, a directed connection with vulnerability severity scores as weights is generated between the source node and the candidate target node, serving as a directed edge for the dynamic attack path.

[0139] The directed edges of the dynamic attack path are reconstructed in real time, generating an attack evolution chain within the digital twin space. The specific implementation process is as follows:

[0140] The path reconstruction engine within the digital twin acts as the execution entity, first polling the logical state. Polling refers to the process of periodically or conditionally reading data sources to obtain the latest state. In this step, the polling interval for the logical state can be set to 500 milliseconds to 2000 milliseconds to balance real-time performance and system overhead. A scheduled task is started to read the current Boolean values ​​of all vulnerability identifiers and their subordinate condition bits from the memory database or file storing the logical state at fixed time intervals. The entire state table is traversed to identify all vulnerability exploitation prerequisites with a true state value. A true state value means that the Boolean value of a certain condition bit in the logical state table is true, indicating that the specific exploitation prerequisite for the vulnerability is met at the current moment. For each true condition, its associated unique vulnerability identifier (CVE) number and a detailed description of the condition are extracted. A list of pending satisfied conditions is maintained, and the identified information is added to the list in key-value pairs.

[0141] Based on the impact of exploits defined in the asset vulnerability structured knowledge base, and combined with the potential communication link topology, identify node pairs that could be exploited by attackers for lateral movement or privilege escalation. A node pair is a tuple consisting of the IP addresses of two communicating nodes, describing the potential source and target of an attack. For each entry in the list that meets the criteria, perform the following operations:

[0142] Search the knowledge base using the CVE number to obtain the impact objects after vulnerability analysis. Extract fields such as gained permissions or accessible resources from the impact objects, for example, gaining administrator privileges or access to a certain intranet segment.

[0143] The node where the current conditions are met, i.e., the IP address of the event subject, is identified and denoted as the source node. Considering the impact, all adjacent nodes from the source node with theoretically reachable undirected edges are identified from the potential communication link topology and denoted as the candidate target node set. For each candidate target node, the permission crossing condition from the source node to the target node is evaluated. The permission crossing condition is defined as: whether the new permission level currently obtained by the source node due to vulnerability exploitation is sufficient to initiate a new attack phase on the target node, or whether the target node has a vulnerability that can be directly exploited by this permission level. The permission crossing condition is a logical judgment rule used to determine whether the permissions already obtained on one node are sufficient as a valid starting point for attacking another node; its specific implementation can be based on a permission level model. When evaluating the permission crossing condition, if the impact is to obtain administrator privileges, the permission prerequisite for launching a new attack on any adjacent node is assumed to be met. During the evaluation, the new permissions of the source node are compared with the authentication status required in the prerequisites of the known vulnerability of the target node. If the permission crossing condition is met, the source node-target node pair is marked as an exploitable node pair.

[0144] The logical judgment process for the "permission crossing condition" is as follows: Obtain the target node vulnerability list: From the asset vulnerability structured knowledge base, obtain all known vulnerabilities of the target node and their corresponding "exploitation prerequisites". Then, extract the conditions regarding "authentication status" or "required privilege level" from the "exploitation prerequisites" of each vulnerability. Compare the "new privilege level" obtained by the source node (e.g., ordinary user, administrator) with the "required privilege level" of each vulnerability on the target node. If the privilege level of the source node is greater than or equal to the required privilege level of at least one vulnerability on the target node, the permission crossing condition is considered satisfied. The resulting directed edge of the attack path can be the vulnerability whose privileges were matched (or the highest-scoring matching vulnerability is selected by default).

[0145] Weighted directed connection vectors are inserted between nodes that meet the permission crossing conditions to form dynamic attack path directed edges that describe the attacker's attack intent mapping. The directed connection vector is a directed edge in the attack graph, pointing from the source node of the attack springboard to the target node. The weight is a numerical attribute attached to the directed edge, used to quantify the difficulty or potential harm of exploiting the vulnerability corresponding to that edge for an attack step. It usually directly references the vulnerability's CVSS base score, with a score ranging from 0.0 to 10.0. Dynamic attack path directed edges specifically refer to directed edges generated and inserted into the attack graph in real time during this step. They represent the probability of a single-step attack progression inferred based on the current network state and the fulfillment of vulnerability conditions. The attack graph is a directed graph data structure whose vertices are network nodes and whose edges are dynamic attack path directed edges, used for visualizing or calculating and analyzing multi-step attack chains.

[0146] For each marked exploitable node pair, a directed edge data structure is created. The source vertex of this edge is the starting node IP of the attack springboard, and the target vertex is the target node IP of the attack springboard. The directed edge is associated with a weight attribute, calculated based on the severity score of the vulnerability generated by the triggering edge, such as the base score from the Common Vulnerability Scoring System (CVSS). If CVSS scores are used, the weight can be directly obtained from the asset vulnerability structured knowledge base. This directed edge is inserted into a dynamically maintained attack graph data structure. The attack graph is initially empty and grows as events are processed. During insertion, it is checked whether the same source-target vertex pair already exists in the graph. If so, the weights are compared, and the edge with the larger weight can be retained or multiple parallel edges can be recorded. The graph database can be Neo4j or JanusGraph using Cypher or Gremlin query languages ​​for edge insertion and querying. All newly inserted edges and their weight information are persisted to the graph database and timestamped. This process repeats continuously. As the logical state is continuously updated, the directed edges of the dynamic attack path are reconstructed in real time, thereby forming a link within the digital twin space that maps the possible evolution of real attacks.

[0147] The following is an example of the process of real-time reconstruction of directed edges in dynamic attack paths:

[0148] The path reconstruction engine polls the logical status at 1000-millisecond intervals. It reads the status table and identifies that both condition bits for CVE-2023-38408—network reachability (_tcp_22) and authentication status—are true. It then adds CVE-2023-38408 and its condition information to the list of satisfied conditions.

[0149] Next, the asset vulnerability structured knowledge base was queried using CVE ID CVE-2023-38408, revealing its impact as granting administrator privileges. The source node satisfying this condition was determined to be 192.168.1.100. A query of the potential communication link topology revealed an undirected edge connecting node 192.168.1.100 to node 192.168.1.200. Therefore, the candidate target node set is {192.168.1.200}. The privilege traversal condition from source node 192.168.1.100 to target node 192.168.1.200 was evaluated: the source node has already gained administrator privileges through vulnerability exploitation, a privilege level considered sufficient to attempt to exploit most vulnerabilities on the target node. Assuming the target node 192.168.1.200 has a vulnerability in the knowledge base, one prerequisite is having ordinary user privileges. Administrator privileges are higher than ordinary user privileges, satisfying the traversal condition. Therefore, the node pair source 192.168.1.100 and target 192.168.1.200 are marked as exploitable node pairs.

[0150] Finally, a directed connection vector is inserted between the node pairs. The CVSS baseline score for CVE-2023-38408 is retrieved from the knowledge base, assumed to be 9.8. A directed edge is created from vertex 192.168.1.100 to vertex 192.168.1.200, and its weight is set to 9.8. This edge is inserted into the dynamic attack graph. Assuming there were no edges in the graph before, the attack graph after insertion will contain one edge: 192.168.1.100 -> (weight 9.8) 192.168.1.200. This edge represents the attacker's potential use of node 192.168.1.100 as a springboard to launch a lateral movement attack towards node 192.168.1.200 after exploiting the CVE-2023-38408 vulnerability. This edge is persisted to the graph database, completing the dynamic attack path reconstruction for this round.

[0151] In one embodiment of the present invention, step S6 includes the following steps:

[0152] Starting from a preset initial intrusion point, a graph traversal algorithm is used to search for all reachable directed edges of dynamic attack paths to generate a complete attack graph. For each path in the complete attack graph, the risk propagation coefficient of each path is calculated by combining the severity of the vulnerabilities it contains, the inverse correlation coefficient of the attack difficulty, and the criticality of the path's endpoint node. The inverse correlation coefficient of the attack difficulty is 1 minus the attack difficulty coefficient. Then, the risk exposure values ​​of all paths are aggregated and normalized to generate a network-wide vulnerability association risk score. Aggregating the risk exposure values ​​of all paths includes the following steps: calculating the attack success probability of each path based on its length and a preset single-step attack success probability; multiplying the risk propagation coefficient of each path by the attack success probability to obtain the risk exposure value of each path; summing the risk exposure values ​​of all paths to obtain the total risk exposure value, and generating a network-wide vulnerability association risk score based on the total risk exposure value.

[0153] The dynamic propagation calculation of network-wide vulnerability association risks is performed to quantify system-level security risk indicators. The specific implementation process is as follows:

[0154] The risk assessment engine within the digital twin acts as the execution entity. First, within the digital twin space, it uses a graph traversal algorithm to search for all directed edges of dynamic attack paths originating from a preset initial intrusion point, generating a complete attack graph. The preset initial intrusion point is the attacker's hypothetical starting position in network attack simulation analysis, typically set as a vulnerable node at the network boundary or a known externally controlled node; its IP address is configured by the system administrator before the risk assessment engine starts. The graph traversal algorithm is used to search for all nodes reachable from the starting point in a graph structure; here, it is used to discover all possible attack paths. The complete attack graph refers to the subset of the graph structure obtained through the traversal algorithm, containing all possible attack sequences originating from the initial intrusion point.

[0155] The system receives configuration parameters specifying the IP address of the initial intrusion point, which typically represents the node that the attacker initially controls or can access. It loads all directed edges and their associated weights of dynamic attack paths from a persistent graph database, constructing a temporary directed graph data structure. Using the initial intrusion point node as the starting vertex, it executes a Depth-First Search (DFS) or Breadth-First Search (BFS) algorithm to explore all possible paths. During traversal, it follows the direction of directed edges, moving from one vertex to the adjacent vertex pointed to by its outgoing edge, and recording the vertices and edges traversed along the path. A path length limit N is used to prevent traversing infinite loops or excessively long invalid paths; it can be set to 5 to 10 steps based on the typical attack chain length. To avoid infinite recursion caused by looping paths, a maximum path length limit is set, for example, a maximum of N paths, where N ranges from 5 to 10. The traversal algorithm ultimately outputs a set of paths, where each path is a sequence of vertices representing a series of attack jumps that the attacker might follow starting from the initial intrusion point. This set of paths, along with their edges and weights, constitutes a complete attack graph reflecting the current network's dynamic attack possibilities.

[0156] The risk transmission coefficient for each path is calculated by comprehensively considering the vulnerability severity score, attack difficulty coefficient, and the criticality of the target node in the asset chain. The vulnerability severity score is a quantitative assessment of the potential harm of a vulnerability, typically using the base score from the general vulnerability scoring system CVSS, which can be directly obtained from the asset vulnerability structured knowledge base. The attack difficulty coefficient is a quantitative assessment of the technical complexity required to exploit a vulnerability, usually between 0 and 1; a lower value indicates easier exploitation. This coefficient can be calculated directly using the general vulnerability scoring system CVSS or imported from additional fields in a third-party vulnerability database. The criticality of the target node in the asset chain assigns a value to the node's importance in the business system, and can be manually or automatically classified according to the type of service the node provides. For example: Level 3: core database server, domain controller; Level 2: application server, file server; Level 1: ordinary user terminal, printer. The risk transmission coefficient is a composite calculated value used to quantify the relative risk intensity of a single potential attack path, and it is inversely proportional to the attack difficulty coefficient; it integrates the vulnerability harm, exploitation difficulty, and target value.

[0157] For each path in the complete attack graph, the following calculations are performed: First, the base value of the path risk transmission coefficient is determined by the weight of each edge on the path. The weight of each edge corresponds to the severity score of the vulnerability, such as the CVSS base score. The base value is calculated using a weighted summation method or a maximum value selection method. In this implementation, a weighted summation method is used, summing the weights of all edges on the path as the base score. Second, the attack difficulty coefficient is used to adjust this base score. The attack difficulty coefficient is a value between 0 and 1, representing the comprehensive technical difficulty required to exploit all vulnerabilities on the path; the lower the coefficient, the easier it is to exploit. This coefficient can be obtained from the additional fields of each vulnerability in the asset vulnerability structured knowledge base, or converted from the vulnerability's CVSS exploitation complexity index. For a path, the geometric mean or minimum value of the attack difficulty coefficients of the vulnerabilities corresponding to all its edges is taken as the overall attack difficulty coefficient of the path. Finally, the criticality of the target node in the asset chain is used for further weighting. The criticality is a value assigned based on the importance of the node's business, for example, based on the type of service carried by the node, it is divided into three levels: 1, 2, and 3 according to preset rules, with higher levels being more critical. For a given path, its risk transmission coefficient The calculation formula is: the sum of the basic scores of the paths multiplied by the inverse correlation coefficient of the overall attack difficulty of the paths, i.e. This is then multiplied by the criticality value of the target node at the end of the path. This mechanism ensures that the lower the attack difficulty coefficient, the higher the risk weight of the path.

[0158] Risk transmission coefficient The calculation formula is as follows:

[0159] ;

[0160] in, This represents the weight of the i-th edge in the complete attack graph, which is the severity score of the corresponding vulnerability. This represents the total number of edges on the path. This indicates the overall attack difficulty coefficient of this path. This represents the criticality value of the target node at the end of the path.

[0161] Overall difficulty of attacking the path The difficulty of attacking a single vulnerability can be determined by the attack difficulty coefficient of each edge on the path. Calculations, such as taking the geometric mean:

[0162] ;

[0163] The risk exposure values ​​of all potential attack paths are aggregated to generate a network-wide vulnerability-related risk score that reflects the overall security posture of the communication network at the current moment. The risk exposure value is a quantitative risk value adjusted based on the risk transmission coefficient and the success probability of the attack path, reflecting the actual risk level exposed by that path in the current environment. The network-wide vulnerability-related risk score is a normalized comprehensive value used to characterize the overall risk level faced by the entire network under the current dynamic attack path graph.

[0164] Calculate the risk exposure value for each path. The risk exposure value is defined as the risk transmission coefficient for that path. The probability of a successful attack on this path in the current attack graph. The product of . Probability A simple estimation can be made based on path length, for example, by setting a certain percentage decrease in probability for each additional hop, or by analyzing historical attack data. In this embodiment, a path length-based attenuation model is used, assuming that the independent probability of success for each attack step is... Then the length is The probability of the path for of Power of 1 A suitable empirical value is 0.7. This represents the independent base probability of success for each attack step. This is an empirical parameter that can be set based on industry average attack success rates or organizational historical data, for example, between 0.6 and 0.8. The engine then aggregates the risk exposure values ​​for all paths. The aggregation method can be summation, adding the risk exposure values ​​of all paths to obtain the total risk exposure value. Alternatively, it can consider taking the maximum value, i.e., finding the path with the highest risk exposure value.

[0165] Finally, to obtain a standardized score, the total risk exposure value or the maximum risk exposure value is mapped to a preset score range, such as 0 to 100. The mapping function can use linear scaling, normalized based on the historical maximum risk exposure value or the theoretical maximum value. (Maximum risk exposure value) The score normalization can be set to a fixed value, such as 1000, or based on the maximum value observed since the system began operating. Dynamic adjustment. After calculation and mapping, a final numerical value is output, which is the network-wide vulnerability association risk score.

[0166] Risk Exposure Value The calculation formula is as follows:

[0167] ;

[0168] in, This is the risk transmission coefficient for this path. This represents the probability of a successful attack on this path within the current attack graph. Successful attack probability for each path. A path length-based attenuation model can be used:

[0169] ;

[0170] in, Let be the independent base probability of a successful attack at each step, and let be a preset constant. This represents the length of the path, which is also the total number of edges.

[0171] Network-wide vulnerability association risk score Linear normalization after summation and aggregation can be used:

[0172] ;

[0173] in, Risk exposure values ​​for all paths The sum of . This is the preset maximum risk exposure value, used for normalization, and can be set based on historical data or theoretical upper limits.

[0174] An example of the process of performing dynamic propagation calculations of network-wide vulnerability association risks is as follows:

[0175] The risk assessment engine defaults to the initial intrusion point being 192.168.1.100. It loads the current directed edges of the dynamic attack path; currently, there is only one edge: from 192.168.1.100 to 192.168.1.200, with a weight... The CVSS score is 9.8. A breadth-first search is performed starting from 192.168.1.100, with a maximum path length of 5. The traversal finds a path of length 1: 192.168.1.100 -> 192.168.1.200. This set of paths constitutes the current complete attack graph.

[0176] Calculate the risk transmission coefficient of this path. The path has only one edge, with a weight of [weight missing]. Assume the attack difficulty coefficient of CVE-2023-38408 obtained from the knowledge base. The difficulty level is 0.9, indicating a relatively complex attack method. The overall attack difficulty coefficient for this path is... Pick The value is 0.9. Assume the criticality of the target node 192.168.1.200 is... Its default value is 2 based on its role as a file server. Substituting this into the formula calculates... Calculate the risk exposure value for this path. Assume an independent base probability for each successful attack step. The default value is 0.7. Path length. The success rate of a path attack is 1. Risk exposure value .

[0177] Aggregate and generate a comprehensive online rating. Currently, there is only one path, and the total risk exposure value is... Preset maximum risk exposure value The score is 100. Overall network vulnerability-related risk score. Output rating This score reflects the overall network risk level based on activated vulnerabilities and potential attack paths at any given moment. As more vulnerability conditions are met and attack edges are generated, this score will be dynamically updated.

[0178] In one embodiment of the present invention, step S7 includes the following steps:

[0179] The risk exposure value of each path in the complete attack graph is evaluated, and the attack path with a risk exposure value greater than the preset threshold is identified as a high-risk attack path, and the preceding attack nodes on the high-risk attack path are extracted.

[0180] In the digital twin, for each of the extracted preceding attack nodes, the corresponding logical state is simulated to be revoked or the virtual patch is simulated to be implemented.

[0181] Based on the simulated digital twin state, the steps for generating the network-wide vulnerability association risk score are repeated to obtain the simulated score.

[0182] The simulated intervention action that caused the largest decrease in the overall network vulnerability association risk score was selected and converted into a sequence of instructions to generate a defense hardening strategy.

[0183] A defense hardening strategy based on simulation intervention is generated, completing a feedback loop from assessment to proactive defense. The specific implementation process is as follows:

[0184] The defense strategy generation engine within the digital twin acts as the execution entity. It first reads the risk exposure values ​​of each path in the complete attack graph calculated and output by the risk assessment engine, and sets preset thresholds. These preset thresholds can be manually configured by the system administrator based on the organization's tolerable network security baseline or the historically calculated maximum single point of failure risk value, or they can be dynamically generated based on the current average risk exposure value of the entire network.

[0185] By assessing the risk exposure values ​​of all paths, attack paths with risk exposure values ​​exceeding a preset threshold are identified as high-risk attack paths. The preset threshold can be pre-set according to network security level protection requirements or based on the average value calculated from historical attack data. Then, the first attack springboard node on these high-risk attack paths is extracted—that is, the source node of the first directed edge of the dynamic attack path originating from the preset initial intrusion point. This node is used as the associated node with a risk exposure value exceeding the preset threshold, i.e., the preceding attack node requiring focused attention. Employing batch filtering rules based on preset thresholds can cover all potential threats exceeding the system's tolerance threshold, making the defense scope more comprehensive.

[0186] For each of the extracted preceding attack nodes, simulated intervention operations are performed individually or in parallel within the digital twin:

[0187] Simulated revocation logic state refers to artificially forcing the Boolean values ​​of all vulnerability exploit prerequisite bits corresponding to the vulnerability that caused the generation of the first attack edge on the node to be false in the simulation environment of the digital twin, so as to simulate the state in which the vulnerability triggering condition is eliminated. This operation only affects the state copy in the twin.

[0188] Simulated virtual patching refers to simulating a temporary software configuration change in a digital twin to mitigate a vulnerability. Its purpose is to block the exploit path rather than to fix the vulnerable code itself. The operation targets the attributes of the node in the digital twin, such as simulating the modification of network access policies or application layer filtering rules, or temporarily removing the permission edge that allows access to the vulnerable service port, such as TCP / 22, in the potential communication link topology.

[0189] Simulating the implementation of temporary blocking measures refers to simulating a more direct and immediate blocking operation within a digital twin. The target of the operation is also a node attribute within the digital twin, such as simulating the execution of a script command to stop services on that node, setting the corresponding service port status to closed. When simulating multiple defense measures, combinations can be made based on a pre-defined library of intervention actions. For example, the intervention action library includes clearing specific user sessions, adding firewall denial rules to target ports, and stopping specific service processes.

[0190] The dynamic propagation calculation of network-wide vulnerability-related risks is retried, and the change in risk scores before and after intervention is compared to assess the effectiveness of defensive measures. The difference in score change refers to the numerical deviation between the original network-wide vulnerability-related risk score before intervention and the score recalculated after the simulated intervention. Generally, a larger difference between the original score and the simulated score indicates a more significant intervention effect. The effectiveness of defensive measures is quantified using the difference in score change. After completing the simulation state revocation and measure implementation, a module with the same logic as the risk assessment engine is invoked, but the calculation is performed based on the updated digital twin state.

[0191] Specifically, using the logical state table after simulated revocation and the updated potential communication link topology after simulated implementation as input, the entire process of S6 graph traversal, risk transmission coefficient calculation, risk exposure value aggregation, and score generation is re-executed to obtain a new network-wide vulnerability-related risk score. When re-triggering the calculation, it is necessary to ensure that the simulated twin state data is read, rather than the real, continuously updated state. The absolute difference between the original score before intervention and the simulated score after intervention is calculated. Furthermore, for various simulated defensive measures, such as revoking only the state, implementing only virtual patches, implementing only temporary blocking, or combined measures, multiple simulated scenarios can be executed in parallel or sequentially, triggering recalculation for each to obtain a set of corresponding post-simulation scores. For each simulated scenario, the score change difference is calculated; the larger the difference, the higher the effectiveness of the simulated defensive measure in the current context. The comparison of score change differences can be an absolute value comparison or a relative percentage decrease calculation.

[0192] Finally, the simulated intervention action that causes the largest decrease in the associated risk score is selected as the final prompt instruction and sent to the security orchestration terminal to generate a defense hardening strategy. The final prompt instruction refers to the set of specific operational commands that can be understood and executed by the security orchestration automation platform, corresponding to the intervention action that causes the largest decrease in score after simulation evaluation. The security orchestration terminal is a centralized platform used to receive instructions, coordinate, and automatically execute various security tools. The defense hardening strategy is the action plan ultimately generated by the security orchestration terminal for actual implementation in the physical network to reduce risk. The difference in score changes across all simulated scenarios is compared, and the simulated intervention action combination corresponding to the scenario with the largest difference is selected.

[0193] This combination of actions is translated into a sequence of executable instructions by the security orchestration automation platform. The generation of these instructions follows predefined mapping rules: simulating a revocation logic state maps to instructions for restoring vulnerability trigger conditions in a real network, such as notifying an administrator to forcibly log out a specific user session; simulating a virtual patch maps to instructions for issuing temporary firewall rule changes; and simulating temporary blocking measures maps to instructions for issuing service stop or process termination. These specific instructions, target node IP addresses, and execution parameters are encapsulated into requests conforming to the security orchestration terminal API format, such as JSON objects, and sent to the terminal over the network. Upon receiving the request, the security orchestration terminal parses it into an executable automated process script or direct command, thereby implementing corresponding defense and hardening measures in the physical network, completing a closed loop from digital twin space risk assessment to proactive physical network defense.

[0194] An example of the process for generating a defense hardening strategy based on simulation intervention is as follows:

[0195] The defense strategy generation engine reads the current network-wide vulnerability association risk score of 1.372 and traces its composition. Currently, there is only one attack path: 192.168.1.100 -> 192.168.1.200, with a risk exposure value of 1.372. The system administrator or the defense strategy generation engine has preset a risk exposure value threshold of 1.0. Since the risk exposure value of this path (1.372) is greater than the preset threshold of 1.0, it is identified as a high-risk attack path, and the preceding attack nodes on this path are extracted. This path is triggered by the vulnerability CVE-2023-38408 on node 192.168.1.100. Therefore, the preceding attack node requiring intervention is 192.168.1.100.

[0196] Perform simulated intervention on node 192.168.1.100. Simulate reversing the logical state: In the simulated environment, force the network reachability_tcp_22 and authentication status condition bits corresponding to CVE-2023-38408 to false; Simulate implementing a virtual patch: In the simulated environment, modify the potential communication link topology, deleting the allowed connection edge on TCP port 22 between nodes 192.168.1.100 and 192.168.1.200; Simulate implementing temporary blocking measures: In the simulated environment, mark the SSH service status on node 192.168.1.100 as stopped.

[0197] Next, the risk assessment is retried. First, based on the state after the simulation was revoked: the condition bit of CVE-2023-38408 in the logical state table is false, therefore no condition-fulfilled event will be generated in S4, and no directed edge of the dynamic attack path from 192.168.1.100 to 192.168.1.200 will be generated in S5. The calculation in S6 is re-executed. Since the attack graph is empty, the total risk exposure value Sum_E is 0, and a new network-wide vulnerability-related risk score is generated. The value is 0. The difference in score change ΔS is 1.372 - 0 = 1.372.

[0198] The effects of simulating a virtual patch alone and simulating a temporary blocking measure alone are evaluated separately. If only a virtual patch is simulated, the TCP / 22 connection in the potential communication link topology is deleted, but the logical state remains true. During recalculation, an attack edge may still be generated in S5, but in S6, due to path reachability being blocked, the probability is reduced. It may decrease, leading to a new rating. The score is 0.8, with a difference of 0.572. If only temporary blocking measures are simulated, the service state is closed, and the network reachability condition in the logical state may indirectly not be met, resulting in a new score. The value is 0.9, and the difference is 0.472.

[0199] Finally, the score changes for the three simulated scenarios were compared: 1.372 for the revocation state, 0.572 for the virtual patch, and 0.472 for the temporary block. The simulated intervention action that caused the largest drop in score was the operation corresponding to the revocation logical state. This action was converted into a final prompt instruction: send an instruction to the security orchestration terminal, requesting the execution of "force logout of user admin's session" and "disconnect all TCP / 22 connections from 192.168.1.150" on node 192.168.1.100. The instruction was encapsulated in JSON format: `{"target":"192.168.1.100","actions":[{"type":"kill_session","user":"admin"},{"type":"block_connection","src_ip":"192.168.1.150","proto":"tcp","port":22}],"priority":"high"}`. After receiving this instruction, the security orchestration terminal executes the corresponding script or API in the physical network to generate and implement a defense hardening strategy.

[0200] Example 2

[0201] See appendix Figure 2 Embodiment 2 of the present invention also proposes a network communication transmission node vulnerability assessment system, which includes the following modules:

[0202] The knowledge base construction module matches known vulnerabilities based on the static attributes of communication nodes, and parses the known vulnerabilities into the preconditions for exploitation and the impact after exploitation, generating a structured knowledge base of asset vulnerabilities.

[0203] The topology initialization module analyzes the theoretical reachability between communication nodes and generates potential communication link topologies based on the physical network topology architecture and firewall access control permissions.

[0204] The state event capture module is used to collect session connection data, process activity and user permission change information between communication nodes, and to filter and standardize the encapsulation to generate key state transition events.

[0205] The state determination and update module, based on the asset vulnerability structured knowledge base, determines whether critical state transition events meet the preconditions for vulnerability exploitation, and updates the logical state according to the determination results.

[0206] The attack path reconstruction module generates dynamic directed edges for attack paths between nodes that meet the permission crossing conditions, based on the updated logical state, the impact after exploitation, and the potential communication link topology.

[0207] The risk calculation module is used to search for all directed edges of dynamic attack paths to generate a complete attack graph, and to calculate the risk of the paths in the complete attack graph to generate a network-wide vulnerability association risk score.

[0208] The defense strategy generation module is used to simulate intervention measures for nodes whose risk exposure value in the complete attack graph is greater than a preset threshold, and generate defense hardening strategies based on the difference in the change of the network vulnerability-related risk score before and after the intervention.

[0209] Each of the modules can be implemented in whole or in part through software, hardware, or a combination thereof. It supports hardware embedded in or independent of the processor in the computer device, and also supports software stored in the memory of the computer device, so that the processor can call and execute the operations corresponding to each of the above modules.

[0210] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for assessing vulnerabilities in network communication transmission nodes, characterized in that, Includes the following steps: Known vulnerabilities are matched based on the static attributes of communication nodes, and the known vulnerabilities are parsed into the preconditions for exploitation and the impact after exploitation, generating a structured knowledge base of asset vulnerabilities. Based on the network topology architecture and firewall access control permissions of the physical network, analyze the theoretical reachability between communication nodes and generate potential communication link topologies. Collect session connection data, process activity and user permission change information between communication nodes, and filter and standardize the encapsulation to generate key state transition events; Based on a structured knowledge base of asset vulnerabilities, it is determined whether critical state transition events meet the preconditions for vulnerability exploitation, and the logical state is updated according to the determination results. Based on the updated logical state, the impact after exploitation, and the potential communication link topology, a directed edge for a dynamic attack path is generated between nodes that meet the permission crossing condition. Search all directed edges of dynamic attack paths to generate a complete attack graph, and perform risk calculations on the paths in the complete attack graph to generate a network-wide vulnerability association risk score. For nodes in the complete attack graph whose risk exposure value exceeds a preset threshold, simulate intervention measures and generate defense hardening strategies based on the difference in the overall network vulnerability-related risk scores before and after the intervention.

2. The method for assessing vulnerabilities in network communication transmission nodes according to claim 1, characterized in that, Based on the static attributes of communication nodes, known vulnerabilities are matched, and these vulnerabilities are parsed into exploit prerequisites and post-exploitation impacts to generate a structured knowledge base of asset vulnerabilities. This includes the following steps: Obtain the hardware configuration, operating system version, and open services of the communication node as static attributes; The static attributes are formatted and compared with a preset vulnerability database to identify known vulnerabilities. Extract the description text of known vulnerabilities and parse it to generate structured vulnerability exploitation prerequisites and post-exploitation impact; Establish a correlation matrix of static attributes, known vulnerabilities, vulnerability exploitation prerequisites, and post-exploitation impact to generate a structured knowledge base of asset vulnerabilities.

3. The method for assessing vulnerabilities in network communication transmission nodes according to claim 1, characterized in that, Based on the physical network topology and firewall access control permissions, the theoretical reachability between communication nodes is analyzed to generate potential communication link topologies, including the following steps: Calculate the physical link reachability between communication nodes based on the routing information in the network topology; The protocol port pairs between communication nodes are matched against the firewall's access control rule set to determine the reachability of logical policies. The logical AND result of physical link reachability and logical policy reachability is used as the theoretical reachability between communication nodes, and a graph structure is constructed based on this to generate potential communication link topologies.

4. The method for assessing vulnerabilities in network communication transmission nodes according to claim 1, characterized in that, Collect session connection data, process activity, and user permission change information between communication nodes, and filter and standardize the data to generate key state transition events, including the following steps: Collect session connection data, process activity, and user permission change information through network traffic probes and host monitoring agents; Set filtering rules to filter out new network connections, potential service startups, and privileged account logins as real-time incremental data from the collected information; Real-time incremental data is encapsulated into a unified data format that includes event type, subject, and object information to generate critical state transition events.

5. The method for assessing vulnerabilities in network communication transmission nodes according to claim 1, characterized in that, Based on a structured knowledge base of asset vulnerabilities, the system determines whether critical state transition events meet the preconditions for vulnerability exploitation and updates the logical state according to the determination results, including the following steps: Extract event type and event detail parameters from critical state transition events; Compare the event details parameters with the condition parameters of the vulnerability exploitation prerequisites indexed from the asset vulnerability structured knowledge base; If the comparison result is satisfactory, the Boolean value of the corresponding condition bit in the logical state is flipped to complete the update of the logical state.

6. The method for assessing vulnerabilities in network communication transmission nodes according to claim 1, characterized in that, Based on the updated logical state, the impact of exploitation, and the potential communication link topology, directed edges for dynamic attack paths are generated between nodes that meet the permission crossing conditions, including the following steps: Poll the logic status to identify vulnerabilities whose preconditions have all been met and their source nodes; Based on the impact of exploiting the vulnerability, determine the new privilege level obtained by the source node; In the potential communication link topology, find candidate target nodes that can be reached from the source node, and determine whether the new permission level meets the permission crossing condition for attacking the candidate target node. If the permission crossing condition is met, a directed connection with a vulnerability severity score as the weight is generated between the source node and the candidate target node, serving as a directed edge for the dynamic attack path.

7. The method for assessing vulnerabilities in network communication transmission nodes according to claim 1, characterized in that, The process of searching all directed edges of dynamic attack paths to generate a complete attack graph, and calculating the risks of the paths in the complete attack graph to generate a network-wide vulnerability association risk score, includes the following steps: Starting from a preset initial intrusion point, a graph traversal algorithm is used to search for all reachable directed edges of dynamic attack paths to generate a complete attack graph. For each path in the complete attack graph, the risk transmission coefficient of each path is calculated by combining the inverse correlation coefficient of the severity of the vulnerabilities contained therein, the attack difficulty, and the criticality of the path's endpoint node. The risk exposure values ​​of all paths are aggregated and normalized to generate a network-wide vulnerability association risk score.

8. The method for assessing vulnerabilities in network communication transmission nodes according to claim 1, characterized in that, For nodes in the complete attack graph whose risk exposure value exceeds a preset threshold, simulate intervention measures and generate a defense hardening strategy based on the difference in the overall network vulnerability-related risk score before and after the intervention, including the following steps: The risk exposure value of each path in the complete attack graph is evaluated, and the attack path with a risk exposure value greater than the preset threshold is identified as a high-risk attack path, and the preceding attack nodes on the high-risk attack path are extracted. In the digital twin, for each of the extracted preceding attack nodes, the corresponding logical state is simulated to be revoked or the virtual patch is simulated to be implemented. Based on the simulated digital twin state, the steps for generating the network-wide vulnerability association risk score are repeated to obtain the simulated score. The simulated intervention action that caused the largest decrease in the overall network vulnerability association risk score was selected and converted into a sequence of instructions to generate a defense hardening strategy.

9. The method for assessing vulnerabilities in network communication transmission nodes according to claim 7, characterized in that, Aggregate the risk exposure values ​​for all paths, including the following steps: The attack success probability of each path is calculated based on the length of each path and the preset single-step attack success probability. The risk transmission coefficient of each path is multiplied by the probability of successful attack to obtain the risk exposure value of each path; The risk exposure values ​​of all paths are summed to obtain the total risk exposure value, and a network-wide vulnerability association risk score is generated based on the total risk exposure value.

10. A network communication transmission node vulnerability assessment system, characterized in that, Includes the following modules: The knowledge base construction module matches known vulnerabilities based on the static attributes of communication nodes, and parses the known vulnerabilities into the preconditions for exploitation and the impact after exploitation, generating a structured knowledge base of asset vulnerabilities. The topology initialization module analyzes the theoretical reachability between communication nodes and generates potential communication link topologies based on the physical network topology architecture and firewall access control permissions. The state event capture module is used to collect session connection data, process activity and user permission change information between communication nodes, and to filter and standardize the encapsulation to generate key state transition events. The state determination and update module, based on the asset vulnerability structured knowledge base, determines whether critical state transition events meet the preconditions for vulnerability exploitation, and updates the logical state according to the determination results. The attack path reconstruction module generates dynamic directed edges for attack paths between nodes that meet the permission crossing conditions, based on the updated logical state, the impact after exploitation, and the potential communication link topology. The risk calculation module is used to search for all directed edges of dynamic attack paths to generate a complete attack graph, and to calculate the risk of the paths in the complete attack graph to generate a network-wide vulnerability association risk score. The defense strategy generation module is used to simulate intervention measures for nodes whose risk exposure value in the complete attack graph is greater than a preset threshold, and generate defense hardening strategies based on the difference in the change of the network vulnerability-related risk score before and after the intervention.

Images