Hosted methods, systems, media, and products for threat detection based on AI agents.

Abstract

This invention relates to a method, system, medium, and product for managed threat detection based on AI agents, and pertains to the field of data processing technology. The method first collects logs from heterogeneous security devices, extracts address identifiers, and constructs an attack behavior graph by combining asset and threat attributes. Second, it matches the graph paths with preset templates and invokes an investigation agent to automatically generate a structured investigation report containing a chain of evidence. Subsequently, it invokes a response agent to dynamically orchestrate response strategies and executes cross-device response actions based on operational risk values. Furthermore, the system can extract the mapping relationship between attack paths and response actions from historical successful cases, generating standard handling templates and storing them in a knowledge base. When faced with a new attack, the system can automatically match the knowledge base template and invoke the agent to execute the response. Implementing the technical solution provided in this application can improve the efficiency of managed threat detection based on AI agents.

Description

Technical Field

[0001] This application relates to the field of data processing technology, specifically to a threat detection hosting method, system, medium, and product based on AI intelligent agents. Background Technology

[0002] With the increasing complexity and diversification of cyberattack methods, enterprises face a persistently high incidence of cybersecurity threats. Modern enterprise IT infrastructure typically deploys a variety of heterogeneous security devices, including firewalls, intrusion detection systems (IDS), intrusion prevention systems (IPS), endpoint detection and response systems (EDR), and security information and event management systems (SIEM). These devices generate massive amounts of security logs and alerts daily. If a cyberattack occurs and the attack path cannot be quickly identified and an effective response implemented, it can lead to data breaches, business disruptions, damage to brand reputation, severe economic losses and legal risks, and incalculable negative impacts.

[0003] To address the aforementioned issues, a managed threat detection method based on AI agents has been proposed. This method deploys various security devices within the enterprise network to collect network traffic and security incident data in real time. The collected log data is then transmitted to a security operations platform, where AI agents are used to automate the analysis and handling of security incidents. Visualization tools are used to display trends in security posture changes, enabling intelligent detection and managed services for security threats.

[0004] However, existing AI-based managed threat detection methods still have certain limitations in practical applications of enterprise security operations. Enterprise network environments are complex and attack methods are diverse. Security threats are often multi-stage, cross-device complex attack chains, potentially involving multiple attack stages such as external network penetration, lateral movement, privilege escalation, and data theft. Existing managed methods typically present each security alert independently, lacking the ability to deeply correlate and analyze multi-stage attack behaviors. This makes it difficult to cope with complex attack scenarios such as advanced persistent threats, resulting in difficulties in reconstructing the complete attack path and insufficient timeliness of response and handling, thus reducing the overall efficiency of AI-based managed threat detection. Summary of the Invention

[0005] This application provides a threat detection hosting method, system, medium, and product based on AI intelligent agents, which can improve the efficiency of threat detection hosting based on AI intelligent agents.

[0006] The first aspect of this application provides a managed threat detection method based on AI agents, comprising:

[0007] Obtain the security logs of heterogeneous security devices, and extract the source address identifier and the destination address identifier from the security logs;

[0008] Based on the source address identifier and the target address identifier, asset attribute information and threat attribute information are matched to generate enriched data records, and an attack behavior map is constructed based on the enriched data;

[0009] The attack behavior graph is matched with a preset attack pattern template to extract the successfully matched attack paths. A preset investigation agent is then invoked to conduct an automated investigation of the attack paths, generating a structured investigation report containing a chain of evidence.

[0010] Based on the structured survey report, a preset response agent is invoked to dynamically orchestrate the response strategy, generate a response strategy execution sequence, and determine the execution method according to the operational risk value of the response strategy execution sequence to complete the cross-device response action execution;

[0011] Extract the target attack path features and target response action sequences from historical cases where response actions were successfully executed, map and bind the target attack path features and target response action sequences to generate a standard handling template, and store the standard handling template in the knowledge base of the preset response agent;

[0012] When a new attack behavior graph is detected, the standard handling template that matches the new attack behavior graph is queried in the knowledge base, and the preset response agent is invoked to execute the target response action sequence in the standard handling template.

[0013] By adopting the above technical solution, and by acquiring security logs from heterogeneous security devices and extracting source and target address identifiers, the problem of independently presented security alarms in existing methods is solved. Based on this, enriched data records are generated by matching asset attribute information and threat attribute information, and an attack behavior graph is constructed based on this enriched data. This achieves deep correlation of dispersed security events, overcoming the limitations of existing technologies in handling complex cross-device, multi-stage attack scenarios. Furthermore, by performing graph structure matching of the attack behavior graph paths with preset attack pattern templates to extract successfully matched attack paths, and calling a preset investigation agent to automatically investigate the attack paths and generate a structured investigation report containing evidence chains, the technical problem of difficulty in reconstructing complete attack paths is effectively solved. This allows complex attack chains involving multiple attack stages such as external network penetration, lateral movement, privilege escalation, and data theft to be clearly identified and presented. After obtaining the structured investigation report, a preset response agent is called to dynamically orchestrate response strategies to generate a response strategy execution sequence. The execution method is determined based on the operational risk value to complete the cross-device response action, significantly improving the timeliness of response and addressing the shortcomings of insufficient timeliness in existing methods. More importantly, by extracting target attack path features and target response action sequences from historical successful response cases, and mapping and binding these two to generate standard response templates, which are then stored in the knowledge base of a pre-defined response agent, a complete closed-loop mechanism from attack identification to response and handling is established. When a new attack behavior graph is detected, the system can directly query the matching standard response template in the knowledge base and execute the target response action sequence. This enables rapid response and automated handling of complex attack scenarios such as advanced persistent threats, improving the overall efficiency of AI-based threat detection management.

[0014] Optionally, the asset information database and threat intelligence database are queried to obtain asset attribute information and threat attribute information associated with the source address identifier and the target address identifier; the asset attribute information and the threat attribute information are attached as context tags to the corresponding security logs to generate the enriched data records; the enriched data records are grouped according to time windows; within each time window, multiple enriched data records with correlation are identified based on the identifier matching relationship and event sequence between the enriched data records; a single enriched data record is represented by a node, and the correlation between enriched data records is represented by directed edges, and the multiple enriched data records are constructed into the attack behavior graph.

[0015] Optionally, each path in the attack behavior graph is matched with the preset attack pattern template; for a successfully matched attack path, a weighted calculation is performed based on the path features and node attributes in the attack path to determine a comprehensive risk score, and a threat queue to be dealt with is generated according to the comprehensive risk score; the successfully matched attack path is extracted from the threat queue to be dealt with; a preset investigation agent with pre-configured tool invocation rules is invoked, and the corresponding external tool interfaces are selected and invoked sequentially according to the event type of the nodes in the attack path; key evidence fields are extracted from the return results of each external tool interface, and the key evidence fields are associated and mapped with the node information in the attack path to generate the structured investigation report containing the evidence chain.

[0016] Optionally, the threat types and affected asset lists in the structured investigation report are parsed; a preset response agent with a pre-configured action atom library is invoked to select response action units corresponding to the operation interfaces of various security devices from the action atom library; the response action units are identified according to the threat types and asset associations in the affected asset list, and the identified response action units are arranged according to the execution sequence to generate the response strategy execution sequence.

[0017] Optionally, for each response action unit in the response strategy execution sequence, a weighted calculation is performed on the business importance level of the affected asset and the risk level of the action type corresponding to the response action unit to determine the operation risk value; when the operation risk value exceeds a preset approval threshold, the response strategy execution sequence is pushed to the approval interface, and execution is triggered after receiving the approval instruction returned by the approval interface; when the operation risk value does not exceed the preset approval threshold, it is marked as automatic execution and execution is triggered; the security device operation interface corresponding to each response action unit is called sequentially according to the response strategy execution sequence to complete the cross-device response action execution.

[0018] Optionally, all attack paths associated with response actions, structured investigation reports, response strategy execution sequences, and feedback results of response action execution are associated and stored as candidate historical handling cases; historical handling cases with a threat blocking rate greater than a blocking rate threshold are selected from each candidate historical handling case; target attack path features and corresponding target response action sequences are extracted from the historical handling cases; the target attack path features are used as triggering conditions, and the target response action sequences are used as executors, and the standard handling template is generated through mapping and binding; the standard handling template is stored in the knowledge base of the preset response agent, and an index relationship between the standard handling template and the target attack path features is established.

[0019] Optionally, for each candidate historical handling case, obtain continuous monitoring logs within a preset time window after the response action is completed; based on the attack path in the candidate historical handling case, extract subsequent attack probing events associated with the attack path from the continuous monitoring logs; parse the action execution results of the subsequent attack probing events, and count the number of successfully blocked events and the total number of subsequent attack probing events; calculate the threat blocking rate of the candidate historical handling case based on the ratio of the number of blocked events to the total number of subsequent attack probing events.

[0020] Secondly, embodiments of this application provide an AI-based threat detection managed system, which includes one or more processors and a memory; the memory is coupled to the one or more processors and is used to store computer program code, which includes computer instructions, and the one or more processors call the computer instructions to cause the AI-based threat detection managed system to perform the methods described in the first aspect and any possible implementation thereof.

[0021] Thirdly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on an AI agent-based threat detection managed system, cause the AI ​​agent-based threat detection managed system to perform the method described in the first aspect and any possible implementation thereof.

[0022] Fourthly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on an AI-based threat detection managed system, cause the AI-based threat detection managed system to execute the method described in the first aspect and any possible implementation thereof.

[0023] In summary, one or more technical solutions provided in this application have at least the following technical effects or advantages:

[0024] By adopting the above technical solution, and by acquiring security logs from heterogeneous security devices and extracting source and target address identifiers, the problem of independently presented security alarms in existing methods is solved. Based on this, enriched data records are generated by matching asset attribute information and threat attribute information, and an attack behavior graph is constructed based on this enriched data. This achieves deep correlation of dispersed security events, overcoming the limitations of existing technologies in handling complex cross-device, multi-stage attack scenarios. Furthermore, by performing graph structure matching of the attack behavior graph paths with preset attack pattern templates to extract successfully matched attack paths, and calling a preset investigation agent to automatically investigate the attack paths and generate a structured investigation report containing evidence chains, the technical problem of difficulty in reconstructing complete attack paths is effectively solved. This allows complex attack chains involving multiple attack stages such as external network penetration, lateral movement, privilege escalation, and data theft to be clearly identified and presented. After obtaining the structured investigation report, a preset response agent is called to dynamically orchestrate response strategies to generate a response strategy execution sequence. The execution method is determined based on the operational risk value to complete the cross-device response action, significantly improving the timeliness of response and addressing the shortcomings of insufficient timeliness in existing methods. More importantly, by extracting target attack path features and target response action sequences from historical successful response cases, and mapping and binding these two to generate standard response templates, which are then stored in the knowledge base of a pre-defined response agent, a complete closed-loop mechanism from attack identification to response and handling is established. When a new attack behavior graph is detected, the system can directly query the matching standard response template in the knowledge base and execute the target response action sequence. This enables rapid response and automated handling of complex attack scenarios such as advanced persistent threats, improving the overall efficiency of AI-based threat detection management. Attached Figure Description

[0025] Figure 1 This is a flowchart illustrating the AI-based managed threat detection method disclosed in the embodiments of this application;

[0026] Figure 2 This is another flowchart illustrating the AI-based threat detection managed method disclosed in the embodiments of this application;

[0027] Figure 3 This is a schematic diagram of the structure of a system provided in an embodiment of this application.

[0028] Explanation of reference numerals in the attached drawings: 301, Central Processing Unit; 302, Read-Only Memory; 303, Random Access Memory; 304, Bus; 305, Input / Output Interface; 306, Input Section; 307, Output Section; 308, Storage Section; 309, Communication Section; 310, Driver; 311, Removable Media. Detailed Implementation

[0029] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0030] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0031] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0032] This application provides a method, referring to Figure 1 , Figure 1 This is a flowchart illustrating a managed threat detection method based on an AI agent, as provided in an embodiment of this application. The method is applied to a system, which can execute programs. The method includes steps 101 to 106, as follows:

[0033] Step 101: Obtain the security logs of heterogeneous security devices and extract the source address identifier and destination address identifier from the security logs.

[0034] Heterogeneous security devices refer to a collection of network security devices from different manufacturers and with different technical architectures, including firewalls, IDS, IPS, EDR, SIEM, WAF, DLP, etc. Security logs are structured data files recording network traffic, security events, and system operations during device operation; different devices use different formats. Source address identifiers are the identity identifiers of the network communication initiator, including source IP address, source MAC address, source hostname, and source user account. Destination address identifiers are the identity identifiers of the network communication receiver, including target IP address, target port number, target hostname, and target application name.

[0035] Specifically, the system acquires raw log data streams from various heterogeneous security devices in real time through log collection agents or standard device interfaces (Syslog, SNMP, RESTAPI). High-traffic devices such as firewalls are collected in batches per second, while low-frequency devices such as EDRs are pushed in near real-time. After receiving the raw logs, the system performs standardized parsing according to a predefined parsing rule base: for firewall logs, the source IP is extracted using the regular expression "\bSRC=(\d{1,3}(?:.\d{1,3}){3})\b", and the target IP is extracted using "\bDST=(\d{1,3}(?:.\d{1,3}){3})\b"; for IDS logs, the "src" and "dst" fields in CEF format are parsed; and for EDR logs, nested fields such as "process.parent.name" and "network.destination.ip" in the JSON object are parsed. Log entries that fail to resolve are marked and written to an exception queue. Successfully extracted address identifiers undergo data type validation: IP addresses must conform to IPv4 or IPv6 format specifications, MAC addresses must conform to the IEEE 802 standard, and hostnames must be verified through DNS resolution. The extracted source and destination address identifiers, along with metadata such as timestamps, event types, and device identifiers, are stored in a columnar structure of a time-series database, providing foundational data for subsequent data enrichment and correlation analysis.

[0036] Step 102: Match asset attribute information and threat attribute information with source address identifier and target address identifier to generate enriched data records, and construct an attack behavior map based on the enriched data.

[0037] Asset attribute information refers to the static attributes (asset number, type, operating system version, software list, department, business importance level, responsible person) and dynamic status (running status, CPU utilization, open ports, etc.) of equipment maintained by the IT asset management system. Threat attribute information refers to threat characteristic data of malicious IPs, domain names, and file hashes provided by external threat intelligence platforms, including intelligence source, threat type, confidence score, attack organization tag, and time dimension information. Enriched data records refer to enhanced data generated after associating raw logs with asset and threat attributes, containing complete semantic information such as business importance score, department, threat type, and attack organization affiliation. Attack behavior graph refers to a directed graph constructed based on enriched data, where nodes represent security events (including event ID, type, timestamp, address, and threat score), and edges represent causal relationships (including correlation strength, correlation type, and time interval).

[0038] Specifically, the system queries the asset management database (CMDB) and retrieves complete asset attributes using the IP address, MAC address, and hostname extracted in step 101 as query keys. Exact matching is used for IP addresses, and fuzzy matching is used for hostnames to handle dynamic IP changes caused by DHCP. Business importance scores (1-5 points), department tags, and software versions are appended to the enriched data records. Simultaneously, the threat intelligence platform API is called to query threat tags and confidence levels using source and target addresses as parameters. Multi-source intelligence fusion uses a weighted average: Comprehensive Threat Score = Σ(Intelligence Source i Score × Intelligence Source i Weight Coefficient) / Σ(Intelligence Source i Weight Coefficient), with weights dynamically adjusted based on historical accuracy. Addresses with empty query results are marked with a threat score of 0. The matched enriched data records are stored as nodes in the graph database. Next, a 1-hour sliding time window is set, and all enriched data records within the window are scanned. A correlation rule engine is used to determine causal relationships: if the target address of event A is the same as the source address of event B, and the time difference is less than 1 hour, a directed edge from node A to node B is created in the graph database. The formula for calculating edge association strength is: Association Strength = Address Matching Degree × Time Decay Factor, where Time Decay Factor = e^(-Time Interval / 1800 seconds). Process chain association rules (creating a process-derived edge when a parent process creates a child process) and file operation association rules (creating a file transfer edge when process A writes to a file and process B reads from it) are also introduced. These multi-dimensional association rules weave discrete events into a temporal causal attack behavior graph, stored in the Neo4j graph database as an adjacency list, supporting efficient path lookup and subgraph matching.

[0039] In one possible implementation, asset attribute information and threat attribute information are matched based on the source address identifier and the target address identifier to generate enriched data records. Based on the enriched data, an attack behavior graph is constructed, specifically including steps 1021-1024, as follows:

[0040] Step 1021: Query the asset information database and threat intelligence database to obtain asset attribute information and threat attribute information associated with the source address identifier and the target address identifier.

[0041] The asset information database is an enterprise IT asset configuration management database that stores the static attributes (device type, operating system, department, responsible person) and dynamic status (running status, resource utilization, open ports) of network nodes. The threat intelligence database is a storage system integrating external intelligence platforms and internal data, including a malicious address database, a domain name database, and a file hash database. Each intelligence record includes a confidence score, intelligence source, and update time. Asset attribute information consists of complete records retrieved from the asset database that match address identifiers, such as server type, department affiliation, and business importance score. Threat attribute information consists of threat characteristic data retrieved from the intelligence database, such as threat type, confidence level, and associated attack groups.

[0042] Specifically, after receiving the extracted address identifiers, the system establishes parallel query threads to access the asset and threat databases. The asset query thread constructs batch query statements, using all identifiers of the source and target addresses as conditions. Fuzzy matching is used to handle dynamic binding issues with hostnames, and unregistered addresses are marked as unknown assets with a minimum importance setting. The threat query thread calls the intelligence service via an interface, sets a minimum confidence threshold to filter low-quality intelligence, and performs a weighted average fusion of different scores returned from multiple intelligence sources. The weights are set based on the historical accuracy of the intelligence sources. Addresses with no results are marked as benign with a confidence level of zero. Both query threads have timeout limits; logs are recorded upon timeout or failure without blocking the process, and missing fields are filled with default values. After the query is completed, an association mapping table is constructed based on the address identifiers and passed to the next step for data enrichment.

[0043] Step 1022: Attach asset attribute information and threat attribute information as context labels to the corresponding security logs to generate enriched data records.

[0044] Asset attribute information includes structured fields such as device type, operating system version, department affiliation, and business importance score. Threat attribute information includes fields such as threat type, confidence score, associated attack organization, and first observation time. Context tags are normalized representations of attribute information converted into key-value pairs, such as department tags, importance tags, and threat type tags. Security logs are standardized parsed log records containing basic fields such as timestamps, event types, address information, and protocol ports. Enriched data records are enhanced data structures built upon raw logs by adding tags and risk scores.

[0045] Specifically, the system iterates through each standardized log entry, extracts the address field, and retrieves attribute information from the mapping table. Asset tags and threat tags are generated for both the source and target addresses. Asset tags are derived from fields such as department, importance, and operating system, while threat tags are extracted from fields such as threat type, confidence level, and attacking organization. A comprehensive risk score is calculated using the formula: source address threat confidence level multiplied by 0.3, target address threat confidence level multiplied by 0.3, asset importance multiplied by 10, and then multiplied by 0.4, with a score range of 0 to 100. The generated tag array and risk score are appended as new fields to the original logs to construct complete enriched data records. These enriched records are published to downstream modules via a message queue and simultaneously written to a time-series database, stored using timestamps as indexes and addresses as tags. This supports efficient time-range queries and tag filtering, providing a data foundation for subsequent time-window grouping and correlation analysis.

[0046] Step 1023: Group the enriched data records according to time windows; within each time window, identify multiple related enriched data records based on the identifier matching relationship and event sequence between the enriched data records.

[0047] A time window is a period of time that divides a continuous timeline into fixed-length or sliding intervals. It is used for batch grouping and processing of event streams. Sliding windows move in specified steps to create overlapping windows. Enriched data records are enhanced logs containing context labels and risk scores, featuring unique identifiers, timestamps, address fields, and label arrays. Grouping is the operation of aggregating records into corresponding window sets based on time window boundaries. Identifier matching relationships are the connections established between records through address fields, including address matching, hostname matching, and process chain matching. Event chronology is a time sequence relationship determined based on timestamp comparisons. Multiple related enriched data records are logically related sets of records identified within the same window through matching and time sequence.

[0048] Specifically, the system subscribes to enriched record streams from a time-series database and establishes a real-time pipeline using a stream processing framework. A sliding window is defined with a one-hour window length and a fifteen-minute step, allocated based on record timestamps. Records are grouped by window identifier, and records within the same window are routed to the same task instance. Association identification is performed when a window is triggered. All records in the current window are received, sorted by time, and an address index hash table is constructed. Record pairs are traversed to perform matching checks, including network address matching, hostname matching, and process chain matching. Successful matches are used to calculate the association strength based on a weight multiplied by a time decay factor; if a threshold is met, an associated edge is added. A connected component detection algorithm is executed, performing a depth-first traversal starting from unvisited nodes and marking reachable nodes as the same component. Isolated components are filtered, and components containing multiple records are verified to have an end-to-end path. Components that pass verification are marked as a set of associated records. The identified set, along with edge information, is packaged and sent to the next step for graph construction.

[0049] Step 1024: Use nodes to represent individual enriched data and directed edges to represent the relationships between enriched data to construct an attack behavior graph from multiple enriched data.

[0050] Nodes are the basic elements in a graph data structure, representing a single enriched data record. They have a unique identifier and a set of attributes, including timestamp, event type, address information, risk score, tag array, and visual attributes such as display name, color code, and node size. Directed edges are directional connections between two nodes in the graph, representing causal relationships between them. Edge attributes include association strength score, matching type, time interval, display tag, and edge weight. The relationships between enriched data are the logical connections between records identified in the previous step, including direct and transitive relationships. The attack behavior graph is a directed graph structure built from the associated enriched records, stored in a graph database, and has global attributes such as graph identifier, number of nodes, number of edges, overall risk score, and creation time.

[0051] Specifically, the system receives a set of associated records and edge information from the message queue, generates a unique graph identifier, and creates an empty list of nodes and edges. It iterates through the records to create a node object for each record, sets an identifier and display name, determines the color and size based on the risk score, and uses all record fields as node attributes. It iterates through edge relationships to generate edge objects, sets identifiers and display labels, and sets the weight to equal the association strength. It calculates the overall risk score of the graph, extracts the risk score from each node, applies a weighted average formula, and calculates the weight based on the node's in-degree; nodes with higher in-degrees are considered critical and given higher weights. It connects to the graph database to create nodes and edges in batches, using transaction processing to improve write performance. It creates indexes for the graph to accelerate subsequent queries, establishing indexes on the identifier, timestamp, and risk score fields. It writes graph metadata to a relational database, recording the graph identifier, number of nodes, number of edges, risk score, and creation time. It generates a graph visualization configuration file, automatically calculates node coordinates using a force simulation algorithm, stores the configuration and graph data for front-end loading and display, and triggers a completion event to push updates to the monitoring panel in real time regarding the attack situation.

[0052] Step 103: Perform graph structure matching between the attack behavior graph path and the preset attack pattern template, extract the successfully matched attack paths, and call the preset investigation agent to automatically investigate the attack paths and generate a structured investigation report containing the evidence chain.

[0053] Attack pattern templates refer to predefined typical attack behavior graph structures, including node type sequences, node attribute constraints, edge connections, and time constraints, stored in a standardized graph pattern language. Graph structure matching refers to a subgraph isomorphism algorithm that compares the attack behavior graph with the template based on topological similarity, outputting a matching confidence score (0-1) and successfully matched subgraph paths. Successfully matched attack paths refer to node sequences and edge connections in the graph that highly match the template, representing the complete process implemented by the attacker. Pre-defined investigation agents refer to automated analysis agents based on large language models, possessing natural language understanding and tool invocation capabilities. They can autonomously plan investigation tasks based on attack paths and invoke tools such as sandbox analysis, threat intelligence query, and EDR forensics to collect evidence. Structured investigation reports refer to standard format JSON / XML documents output by the investigation agent, including fields such as attack type, timeline, affected assets, evidence chain, and threat level.

[0054] Specifically, the system loads all attack pattern templates from the template knowledge base, represented as graph objects G_template=(V_template, E_template). The attack behavior graph is represented as G_attack=(V_attack, E_attack), and the VF2 subgraph isomorphism algorithm is used to traverse all possible paths. In the node matching phase, node similarity is calculated: Node similarity = (Label matching score × 0.6) + (Attribute matching score × 0.4), where label matching is a binary variable (0 or 1), and attribute matching score = number of satisfied constraints / total number of constraints. In the edge matching phase, the direction, type, and time constraints of the edges are verified. The overall matching confidence score = (Σ node similarity / number of template nodes) × 0.7 + (number of successfully matched edges / number of template edges) × 0.3. A match exceeding the 0.8 threshold is considered successful, and the corresponding subgraph path is extracted. For the identified attack paths, an HTTP POST request is sent to the investigation agent service via a RESTful API. The request body contains JSON data of the complete attack path graph structure, attack pattern type, and preliminary threat level. After receiving the task, the investigation agent analyzes the characteristics of each node and formulates an investigation plan based on the reasoning capabilities of a large language model: for suspicious file nodes, it calls the sandbox API (such as Cuckoo's / api / tasks / create / file) to submit samples for dynamic analysis; for malicious IP nodes, it calls the threat intelligence API (such as VirusTotal's / api / v3 / ip_addresses / {ip}) to query historical activity; for abnormal process nodes, it calls the EDR forensics API (such as CrowdStrike's / api / v2 / detects / {detection_id} / details) to extract the process tree; for data outflow nodes, it calls the traffic analysis and DLP system APIs to reconstruct session data. A parallel asynchronous call strategy is adopted, with a 60-second timeout. Timeouts are marked as query failures but do not block the process. The collected evidence data is organized into an evidence chain according to timeline. Each evidence record includes type, source, JSON content, and confidence level (weighted from 0 to 1 based on the tool's historical accuracy). The attack path, evidence chain, affected assets, and threat level are integrated to generate a structured JSON investigation report, which is returned to the main process via API response.

[0055] In one possible implementation, the paths in the attack behavior graph are matched against a preset attack pattern template to extract successfully matched attack paths. A preset investigation agent is then invoked to automatically investigate the attack paths, generating a structured investigation report containing a chain of evidence. Specifically, steps 1031-1033 are described below.

[0056] Step 1031: Match each path in the attack behavior graph with the preset attack pattern template; for the successfully matched attack paths, perform weighted calculations based on the path characteristics and node attributes in the attack paths to determine the comprehensive risk score, and generate a threat queue to be dealt with based on the comprehensive risk score.

[0057] Specifically, the system loads attack behavior graphs from a graph database, uses a depth-first search algorithm to traverse all possible paths, and sets a maximum path length limit of 15 nodes to avoid combinatorial explosion. It loads all attack pattern templates from a template knowledge base; each template is represented as a graph object containing a sequence of node types and edge connection constraints. For each extracted path, it performs subgraph isomorphic matching with all templates. In the node matching phase, node similarity is calculated. Label matching is represented as a binary variable. The attribute matching score equals the number of satisfied constraints divided by the total number of constraints. Node similarity equals the label matching score multiplied by 0.6 plus the attribute matching score multiplied by 0.4. In the edge matching phase, it verifies whether the direction, type, and time constraints of the edges are satisfied. The overall matching confidence is equal to the sum of all node similarities divided by the number of template nodes multiplied by 0.7 plus the number of successfully matched edges divided by the number of template edges multiplied by 0.3. A match is considered successful if the score exceeds a threshold of 0.8. For successfully matched paths, a weighted calculation is performed to determine the overall risk score. First, path feature scores are calculated: path length score equals the number of path nodes multiplied by 5 points; high-value asset participation score equals the number of assets in the path with a business importance score greater than or equal to 4 multiplied by 10 points; and time compactness score is calculated based on the average time interval: less than 5 minutes receives 20 points, 5 to 30 minutes receives 10 points, and more than 30 minutes receives 5 points. Next, node attribute scores are calculated by traversing all nodes in the path and accumulating their risk scores. The sum of node scores divided by the number of nodes yields the average node risk. The overall risk score equals the path length score multiplied by 0.2, the high-value asset participation score multiplied by 0.3, the time compactness score multiplied by 0.2, and the average node risk multiplied by 0.3, with a score range of 0 to 100. Successfully matched paths and their risk scores are inserted into a priority queue. The queue is implemented using a min-heap data structure, with negative risk scores used as priority keys for descending order. The insertion operation has a logarithmic time complexity. The queue simultaneously records the template identifier, matching confidence, path node list, and detailed scores of each path, generating a queue data structure that is persisted to the database for consumption in subsequent steps.

[0058] Step 1032: Extract successfully matched attack paths from the queue of threats to be dealt with; invoke a pre-configured investigation agent with pre-defined tool invocation rules, and select and sequentially invoke the corresponding external tool interfaces according to the event type of the nodes in the attack path.

[0059] Specifically, the system initiates a threat handling task, extracting the attack paths with the highest risk scores from the threat queue in priority order, and parsing the path data to obtain a node list and template identifier. It then calls a pre-defined investigation agent service, transmitting complete attack path data via an interface. Upon receiving the task, the investigation agent traverses the nodes in the path, sorting them in ascending order by timestamp, and extracts the event type field value for each node. Based on the event type, it queries the rule base, which stores the corresponding tool configuration using the event type as the key: network connection types map to threat intelligence query tools, file creation types map to sandbox analysis tools, process execution types map to endpoint forensics tools, and data transmission types map to traffic analysis tools. The system sequentially calls the corresponding tool interfaces according to the node order. For network connection nodes, it extracts the target address field from the node attributes, constructs a threat intelligence query request, uses the intelligence platform query endpoint as the interface address, and includes the target address and query type in the request parameters. It sets the request timeout to 60 seconds, sends the request, and waits for a response. For the file creation node, the file hash field is extracted, and a sandbox analysis request is constructed. The interface address is the sandbox task creation endpoint, and the request parameters include the file hash and analysis options. After submitting the task, the task status is polled to wait for analysis completion or timeout. For the process execution node, the process identifier and host identifier are extracted, and a terminal forensics request is constructed. The interface address is the response platform forensics endpoint, and the request parameters include the host identifier and process identifier. The interface is called to obtain detailed information such as the process tree, loaded modules, and network connections. For the data transmission node, the session identifier is extracted, and a traffic analysis request is constructed. The interface address is the traffic platform query endpoint, and the request parameters include the session identifier and time range. The interface is called to restore the session data and protocol parsing results. A parallel asynchronous call strategy is adopted, submitting multiple tool call tasks to a thread pool for concurrent execution. A global timeout is set to 300 seconds. Tasks that time out or fail to call are marked as query failures but do not block the overall process. The return results of all tool interfaces are collected. Each return result is a structured data object containing the tool type, query parameters, response status code, response data, and query timestamp. The returned result set is packaged with the original attack path data to generate an investigation task result object, which includes path identifier, number of nodes, number of successful calls, number of failed calls, and an array of tool return results. This object is then passed to the next step for evidence extraction and report generation.

[0060] Step 1033: Extract key evidence fields from the results returned by each external tool interface, and associate and map the key evidence fields with the node information in the attack path to generate a structured investigation report containing the evidence chain.

[0061] Specifically, the system receives the investigation task result object, iterates through the array of results returned by the tools, and performs field extraction for each result based on the tool type. For threats intelligence tools, the system parses the response data object, extracts fields such as threat type, confidence score, attack organization tag, geographic location, and first observation time, encapsulates these fields into evidence objects, marks the evidence type as intelligence matching, marks the source tool as the intelligence platform name, and the evidence content as the extracted field values. The confidence weight is equal to the confidence score of the intelligence return divided by 100. For sandbox analysis tools, the system parses the behavior report, extracts the behavior description from the malicious behavior list, the target address and protocol from the network communication records, and the operation type and target path from the file operation records, generating multiple evidence objects. The evidence type is marked as dynamic analysis, the source tool is marked as the sandbox platform name, and the confidence weight is set according to the behavior risk level: 0.9 for high-risk behavior, 0.7 for medium-risk behavior, and 0.5 for low-risk behavior. For endpoint forensics tools, the system extracts process command-line parameters, parent-child process relationships, loaded module lists, and registry modification records, generating evidence objects. The evidence type is marked as host forensics, and the confidence weight is 0.8. For data returned by traffic analysis tools, the protocol type, data transmission size, session duration, and payload characteristics are extracted to generate evidence objects. The evidence type is labeled as "traffic analysis," with a confidence weight of 0.7. After extraction, the node list of the attack path is traversed. Based on the node's event type and address information, corresponding evidence objects are matched. Network connection nodes are matched with intelligence and traffic evidence sharing the same target address; file creation nodes are matched with sandbox evidence sharing the same file hash; and process execution nodes are matched with forensic evidence sharing the same process identifier. A mapping relationship between node identifiers and evidence object arrays is established and stored in an association mapping data structure. The path is traversed in ascending order by node timestamp. Evidence objects for each node are extracted from the association mapping and assembled into an evidence chain sequence. Each evidence record includes an evidence sequence number, timestamp, evidence type, source tool, evidence content summary, associated node identifier, and confidence weight. Generate a structured investigation report. The attack type field is obtained from the template identifier matched to the path. The timeline field is generated from the time range from the start node to the end node of the path. The list of affected assets is extracted and deduplicated from the asset tags of the path nodes. The evidence chain field is filled with the assembled evidence sequence. The threat level is mapped according to the comprehensive risk score of the path: a score greater than 80 is severe, 60 to 80 is high-risk, 40 to 60 is medium-risk, and less than 40 is low-risk. The remediation recommendation field loads predefined text from the recommendation template library according to the attack type. The investigation report is output in a standard format document, expressed using structured markup language, and returned to the caller via an interface or stored in a report library for querying and auditing.

[0062] Step 104: Based on the structured survey report, call the preset response agent to dynamically orchestrate the response strategy, generate the response strategy execution sequence, and determine the execution method according to the operational risk value of the response strategy execution sequence to complete the cross-device response action execution.

[0063] The pre-defined response agent refers to an automated response proxy based on a large language model, with a built-in action atomic library (standardized definitions for firewall blocking, host isolation, account disabling, etc.) and orchestration rule engine, capable of autonomously formulating response strategies based on threat information. Dynamic orchestration of response strategies refers to the process by which the response agent selects actions from the action atomic library and arranges them according to logical dependencies and priorities to form an execution sequence. The response strategy execution sequence refers to an ordered list of actions, each containing type, parameters, priority, dependencies, and expected duration, expressed as a JSON array. Operational risk value refers to a quantitative indicator of the negative impact of executing response actions on the business, calculated as: Operational Risk Value = Target Asset Business Importance Score × Inherent Risk Level of Action, where asset scores range from 1 to 5, action risk levels are predefined from 1 to 5, and risk values ​​range from 1 to 25. Execution mode refers to the authorization mode determined based on the operational risk value: automatic execution below a threshold (e.g., 12), and manual approval required when the threshold is reached or exceeded. Cross-device response action execution refers to using a unified orchestration engine to call the APIs of different vendors' security devices, converting abstract action instructions into device-specific commands and issuing them for execution.

[0064] Specifically, the system transmits the structured investigation report to the response agent service ( / api / response-agent / orchestrate) via HTTP POST. The response agent extracts key fields: identifying the attack type from "attack_type", extracting asset IDs and business importance scores from "affected_assets", extracting IoCs such as malicious IPs, stolen credentials, and malicious file hashes from "evidence_chain", and obtaining the threat level from "threat_level". Based on the attack type, it loads the response framework from the policy template library and then dynamically adjusts it through the rule engine: "IF contains lateral movement THEN, add the action to reset the domain administrator password", "IF contains data outflow THEN, add the action to block external IPs". It instantiates action objects from the action atomic library, instantiating the firewall_block_ip action based on the C2 server IP in the investigation report and setting the parameters {"ip_address": "203.0.113.50", "direction": "both"}, and instantiating the edr_isolate_host action based on the affected host ID. Analyze action dependencies to construct a dependency graph: Blocking C2IPs is prioritized to cut off remote control; isolating hosts depends on blocking IPs to avoid alarms; resetting credentials can be done in parallel with isolation. Generate a JSON array sorted by dependency and priority, with each element containing `action_id`, `action_type`, `action_params`, `priority`, `depends_on`, and `estimated_duration`. Calculate the operation risk value by traversing the sequence: Query the asset management database to obtain `business_criticality` (1-5 points), and obtain `risk_level` (1-5 levels) from the action atomic library. Calculate: Operation risk value = business_criticality × risk_level. Set a threshold of 12; risk values ​​less than 12 are marked with "execution_mode": "auto", and values ​​greater than or equal to 12 are marked with "manual_approval". Actions marked as "manual_approval" generate approval work orders, sending approval requests via WeChat API, SMS gateway, and SMTP. Approver makes approval / rejection decisions on the mobile device, and the results are returned via callback interface.When approval is granted or marked for automatic execution, the system routes to the device driver module based on the action type: the firewall_block_ip action invokes the firewall driver, identifies the device model, and selects the API protocol (PaloAlto uses RESTAPI's POST / restapi / v9.1 / Objects / Addresses to create address objects and POST / restapi / v9.1 / Policies / SecurityRules to add denial rules; CiscoASA executes "access-listBLOCK_LISTextendeddenyiphost203.0.113.50any" via SSH); The `edr_isolate_host` action invokes the EDR driver, issuing isolation commands to the Agent via the management API (CrowdStrike's ` / devices / entities / devices-actions / v2`, SentinelOne's ` / web / api / v2.1 / agents / actions / disconnect`). The Agent disables the host's network interface (while maintaining a heartbeat channel with the management server). The `ad_reset_password` action invokes the AD driver, connecting to the domain controller via the LDAP protocol to modify the `unicodePwd` attribute, generating a random password and setting a "must be changed on next login" flag. Each driver module returns execution status and logs, recording them in the audit database and updating the status (pending / running / completed / failed) of each action item in the sequence. Execution progress is pushed to the front-end dashboard in real time via WebSocket.

[0065] In one possible implementation, a pre-defined response agent is invoked based on the structured survey report to dynamically orchestrate the response strategy and generate a response strategy execution sequence, specifically including steps 1041-1042, as follows:

[0066] Step 1041: Analyze the threat types and list of affected assets in the structured investigation report; invoke the preset response agent with a pre-configured action atom library, and select the response action unit corresponding to the operation interface of various security devices from the action atom library.

[0067] Specifically, upon receiving the structured investigation report, the system parses the report's data structure, extracts threat type field values ​​(e.g., "ransomware attack"), and extracts an array of asset objects from the affected asset list field. It then iterates through the asset list, extracting attributes such as asset identifier, asset type, IP address, business importance score, and department for each asset, constructing an asset mapping table to store complete attributes using the asset identifier as the key. The system then calls a pre-defined response agent service, transmitting the threat type and asset list data via an interface. The response agent queries the action atom library based on the threat type. This library stores a set of recommended response actions indexed by the threat type. Action sets associated with ransomware attack types include blocking command and control server IPs, isolating infected hosts, terminating malicious processes, disabling stolen credentials, and blocking lateral movement channels. The agent iterates through the recommended action set, instantiating each action atom and converting the action template into a response action unit. For actions that block command and control server IPs, the command and control server address (e.g., 203.0.113.50) is extracted from the evidence chain in the report. A firewall blocking action unit is instantiated, with the target device set to the enterprise perimeter firewall and the operation interface set to the firewall policy management interface. Parameters include: source IP: arbitrary; target IP: 203.0.113.50; action: deny; direction: bidirectional. For actions that isolate infected hosts, affected hosts with asset types of server or terminal are extracted from the asset list. A terminal isolation action unit is instantiated, with the target device set to the terminal detection and response platform and the operation interface set to the host isolation interface. Parameters include a list of host identifiers. For actions that disable stolen credentials, stolen user account information is extracted from the evidence chain. An account disabling action unit is instantiated, with the target device set to the domain controller and the operation interface set to the account management interface. Parameters include the username and a disabling flag. The instantiated response action unit includes a unique action identifier, action type, target device identifier, operation interface address, parameter object, initial priority value, and dependencies initially empty. All instantiated response action units are added to the action unit set for orchestration.

[0068] Step 1042: Identify the response action units according to the threat type and the asset associations in the affected asset list, and arrange the identified response action units according to the execution sequence to generate a response strategy execution sequence.

[0069] Specifically, the system receives the generated set of response action units and extracts threat type and affected asset list data. For each response action unit, an identification operation is performed. First, based on the target address or host identifier in the action parameters, the corresponding asset object is located in the asset list, and attributes such as the asset's business importance score, department, and asset type are appended to the associated asset field of the action unit. The relationships between assets are analyzed. For the isolated host action, the host's location in the network topology is queried, and it is checked whether there are other assets dependent on that host. For example, before isolating a database server, it is necessary to ensure that the application server has been switched to a backup database. Prerequisites are identified: the prerequisite for blocking the command control server IP is confirming the IP address's validity; the prerequisite for isolating the host is that critical business operations have been migrated or are within the maintenance window. Expected effects are identified: the expected effect of blocking actions is to block communication with malicious IPs; the expected effect of isolating actions is to cut off the host's network connection to prevent lateral spread. Priorities are set according to threat type and action type. For ransomware attacks, the priority for blocking the command control server is set to 1 (highest), the priority for isolating infected hosts is set to 2 (second highest), the priority for disabling credentials is set to 3, and the priority for initiating data recovery is set to 4 (lowest). Analyze the dependencies between actions. The blocking command control server action has no dependencies and can be executed immediately. The host isolation action depends on the completion of the blocking action to prevent attackers from destroying evidence after detection. The credential disabling action depends on the completion of the isolation action to prevent attackers from continuing to use credentials through other hosts. The data recovery action depends on the completion of all blocking actions to ensure the threat has been eliminated. Construct a directed acyclic graph of dependencies, where nodes are response action units and edges represent dependencies from the dependent action to the dependent action. Execute a topology sorting algorithm to generate the execution sequence. First, find all nodes with an in-degree of 0 as the first batch of actions to be executed, add these nodes to the execution sequence and remove them from the graph, update the in-degree of other nodes, and repeat this process until all nodes are added to the sequence. For actions with the same priority and no dependencies, sort them in descending order of business importance score, with response actions for high-importance assets executed first. Generate a response strategy execution sequence, which is an ordered array. Each element contains an action identifier, execution sequence number, action type, target device, operation parameters, a list of dependent preceding action identifiers, estimated execution time, and a list of associated assets.

[0070] In one possible implementation, the execution method is determined based on the operational risk value of the response strategy execution sequence to complete the cross-device response action, specifically including steps 1043-1044, as follows:

[0071] Step 1043: For each response action unit in the response strategy execution sequence, perform a weighted calculation on the business importance level of the affected asset and the risk level of the action type corresponding to the response action unit to determine the operation risk value; when the operation risk value exceeds the preset approval threshold, push the response strategy execution sequence to the approval interface, and trigger execution after receiving the approval instruction returned by the approval interface; when the operation risk value does not exceed the preset approval threshold, mark it as automatic execution and trigger execution.

[0072] Specifically, after receiving the response policy execution sequence, each response action unit in the sequence is traversed, and a risk assessment is performed on each action unit. The affected asset object is extracted from the associated asset field of the action unit, and the business importance score field value of the asset is read. The risk level definition corresponding to the action type of the action unit is queried from the action atomic library. For example, the risk level of a firewall blocking IP action is 2, a host network isolation action is 4, a domain controller account disabling action is 3, a database service stop action is 5, and a process termination action is 2. The operation risk value is calculated using the formula: operation risk value equals business importance score multiplied by action risk level. For example, performing a host isolation action on a core database with a business importance score of 5 results in a risk level of 4, and the operation risk value equals 5 multiplied by 4, which equals 20. The operation risk value is compared with the preset approval threshold of 12. If the operation risk value of 20 is greater than the threshold of 12, the execution method of the action unit is marked as manual approval; otherwise, it is marked as automatic execution. For action units marked as requiring manual approval, an approval request data object is constructed, containing an action identifier, action type description, target asset information, operation risk value, expected impact description, and urgency level label. The approval system pushes approval requests via an API call. The API address is the endpoint of the enterprise approval system, and the request data is sent using the HTTP POST method. The request header includes an authentication token, and the request body is in structured data format. Upon receiving the request, the approval system generates an approval work order and notifies the approver via enterprise instant messaging tools, SMS, email, etc. The approver can view the work order details, including the attack path, evidence chain, response action description, and risk assessment results, on mobile or desktop devices. The approver makes an approval or rejection decision, and the approval system returns an approval or rejection instruction via a callback API. The approval instruction includes the approval result field values ​​as "approved," the approver's identifier, the approval timestamp, and the approval comment text. Upon receiving an approval instruction, the system updates the action unit status to "pending execution." Upon receiving a rejection instruction, it marks it as "cancelled" and records the rejection reason. For action units marked as automatically executed, the status is directly updated to "pending execution" without waiting for approval. After traversal, each action unit in the execution sequence has a clear execution method marker and status. Execution is triggered according to dependencies and execution order. The current action remains in a pending state until the prerequisite actions are completed; the current action is triggered immediately upon completion of the prerequisite actions.

[0073] Step 1044: In accordance with the response strategy execution sequence, call the security device operation interface corresponding to each response action unit in sequence to complete the cross-device response action execution.

[0074] Specifically, the response orchestration engine is initialized, and the response policy execution sequence and device driver module mapping table are loaded. The device driver module mapping table stores the corresponding driver class and interface adapter using device type as the key. Firewall types are mapped to firewall driver modules, terminal response platform types to terminal driver modules, and domain controller types to domain controller driver modules. The execution sequence is traversed in ascending order of execution sequence number. For each response action unit, the status field is checked. Execution is triggered when the status is "pending execution" and the list of dependent preceding actions is empty, or when all preceding actions are in the "completed" state. The target device identifier and device type are extracted from the action unit. The corresponding driver module is found in the device driver mapping table, a driver object is instantiated, and device connection parameters such as IP address, port, and authentication credentials are passed in. The execution method of the driver object is called, passing in the action type and operation parameters. For firewall actions that block IPs, the firewall driver module identifies the device manufacturer and model, selects the interface protocol, and uses the REST API to construct a POST request to the policy management endpoint. The request body includes an arbitrary source address, a malicious IP address as the target address, a denial action, and an automatically generated unique identifier for the policy name. After sending the request, it waits for a response; a 200 response status code indicates successful policy creation. It then submits the configuration changes and waits for the device to apply the policy. For Cisco ASA firewalls, it uses an SSH connection to execute command-line instructions to create access control list entries. The command format is: access-list + list name + extended + deny + ip + host + malicious IP + any. After executing the command, it verifies that the configuration has taken effect. For endpoint isolation actions, the endpoint driver module calls the endpoint response platform API, constructs a POST request to the host operation endpoint, and includes an action type of isolation and a list of host identifiers in the request body. After receiving the request, the platform issues an isolation command to the agent process of the target host. The agent process disables the host's network interface but maintains the heartbeat channel with the management server, and returns an isolation status confirmation. For account disabling actions, the domain controller driver module connects to the domain controller via the LDAP protocol, constructs a modification request to update the userAccountControl property of the user object, sets the account disabling flag, and verifies successful property modification after submitting the request. The driver module returns execution results including execution status, response data, execution duration, and error information. The orchestration engine receives the execution results, updates the action unit status to completed or failed, and records the execution log in the audit database, including action identifier, execution time, execution result, response data, and operator. It checks subsequent actions that depend on the current action, updates the completion status of the preceding actions of the subsequent actions, and triggers subsequent actions that meet the execution conditions. The execution progress is pushed to the front-end monitoring panel in real time via WebSocket, displaying the execution status, completion time, and execution result of each action.Once all actions are completed, a response execution summary report is generated, including the total number of actions, the number of successes, the number of failures, the total execution time, and a list of affected devices. The report is stored in the case library and linked to the original attack path record for subsequent knowledge base updates and effectiveness evaluation.

[0075] Step 105: Extract the target attack path features and target response action sequences from historical cases where response actions were successfully executed. Map and bind the target attack path features and target response action sequences to generate a standard handling template, and add the standard handling template to the knowledge base of the preset response agent.

[0076] Historical cases of successful response actions refer to cases in the system's historical records where responses have been completed and subsequent monitoring has verified that the threat has been effectively contained. The criteria for judgment are: all actions were executed without failure, no attack recurrence was detected within a 72-hour monitoring period, and the threat blocking rate reached over 90%. Target attack path characteristics refer to feature vectors extracted from the attack graph of historical cases, including node type sequences, node attribute characteristics (protocol type, port number set), graph topology characteristics (path depth and width), IoC characteristics (malicious IP geographical location, file type), and time characteristics (total duration, average interval), stored in feature vector or hash form. Target response action sequences refer to the verified and effective response policy sequences actually executed in historical cases. Mapping and binding refers to the key-value pair mapping that establishes an association between attack path characteristics and response action sequences, using feature vectors / hashes as keys and action sequence JSON as values. Standard handling templates refer to reusable response policy templates generated through mapping and binding, including trigger condition definitions, response action sequences, and metadata (template ID, historical success rate, number of applications). A knowledge base refers to a structured knowledge storage system maintained by a responding agent, which uses relational or graph databases to store knowledge objects such as templates and historical cases.

[0077] Specifically, the system starts a scheduled task (default 3 AM daily) to query the case database, filtering cases that have been successfully executed within the last 30 days, have a threat blocking rate ≥ 0.9, and have completed a 3-day monitoring period. The SQL WHERE condition is "execution_status='completed' AND threat_block_rate>=0.9 AND monitoring_period_days>=3 AND created_time>=(current time - 30 days)". For each case record, the system loads the attack behavior graph subgraph corresponding to the case_id from the graph database and extracts the target attack path features: traversing nodes, sorting them in ascending order by timestamp, and extracting the event_type field values ​​to form a node type sequence (e.g., "phishingemail", "macroexecution", "registrypersistence", "smblateralmovement"). The attack involves several steps: First, it calculates "persistence" and "smblateral movement". Second, it generates a set of protocol types (by iterating through the `protocol` field to remove duplicates), a set of port numbers (by iterating through the `dest_port` field), and a set of file types (by iterating through the `file_extension` field). Third, it calculates the longest path length as the path depth using depth-first search and the average out-degree of all nodes as the path width. Fourth, it extracts IoC features: malicious IPs are extracted from the `source_ip` field, and the country and city distribution is obtained from a geolocation database; hash values ​​are extracted from the `file_hash` field, and file types and family tags are obtained from threat intelligence. Fifth, it calculates time features: the total attack duration is obtained by subtracting the initial node's timestamp from the terminating node's timestamp, and the average time interval between adjacent nodes is calculated. The feature data is organized into feature vectors, and the high-dimensional vectors are converted into 128-bit binary strings using MinHash or SimHash algorithms. The feature hash value serves as the unique fingerprint of the attack path. Finally, it extracts complete JSON data of the response strategy execution sequence from the case records as the target response action sequence.Perform mapping and binding operations to create a standard handling template record in the knowledge base: `template_id` is generated using a UUID, `template_name` is automatically named according to the attack type (e.g., "APT28-Data Theft-Standard Handling Template"), the `trigger_condition` field stores the attack path characteristics JSON (node ​​type sequence, topology characteristics, IoC characteristics), the `response_action_sequence` field stores the response action sequence JSON array, and the metadata includes `success_rate` (threat blocking rate, e.g., 0.95), `applied_count` (initialized to 1), `created_time` (current timestamp), and `attack_type_tags` (attack type tag array). Submit the template data by calling the knowledge base ingestion interface POST / api / knowledge-base / templates. After the knowledge base service verifies the JSON format, required fields, and data types, it inserts the data into the `templates` table and simultaneously creates an index record in the feature index table, using the feature hash value as the index key pointing to `template_id`. Before data entry, deduplication logic is executed: the feature hash value of the new template is calculated, and the feature index table is queried to see if there is an existing template with the same hash value or a Hamming distance < 10. If it exists, instead of creating a new template, the applied_count of the existing template is updated by 1, and the average success rate is recalculated as (original success_rate × original applied_count + new case blocking rate) / (original applied_count + 1). Incremental updates make the template success rate assessment more accurate.

[0078] Step 106: When a new attack behavior graph is detected, query the knowledge base for a standard response template that matches the new attack behavior graph, and call the preset response agent to execute the target response action sequence in the standard response template.

[0079] The new attack behavior graph refers to the latest graph instance built in real time during continuous system monitoring. Generated through steps 101 and 102, it represents currently occurring suspected attack activities and includes the latest security event nodes, related edges, enriched attributes, and is assigned a unique `graph_id` and creation timestamp. Querying the knowledge base refers to calling the knowledge base query interface to retrieve the standard handling template with the highest matching degree based on attack path characteristics. It supports exact matching (completely identical feature hashes), similarity matching (cosine similarity or Hamming distance exceeding a threshold), and tag matching (attack type tag filtering). The matched standard handling template refers to the template object returned by the knowledge base that highly matches the features of the new graph. Matching is determined based on a similarity score exceeding a threshold (e.g., 0.85). Executing the target response action sequence in the standard handling template refers to the responding agent loading the predefined response action sequence from the template and replacing the parameterized placeholders with the actual values ​​of the current attack (e.g., ...). Replace with 203.0.113.100), and execute actions step by step according to execution order and dependencies.

[0080] Specifically, the system monitors the graph construction process through an event listening mechanism. After the new graph is built in step 102, a graph detection event is triggered. The event handler receives the notification (including graph_id) and loads the complete graph data from the graph database. First, a preliminary screening is performed to calculate the graph threat score: the threat_score field value is accumulated by traversing all nodes and multiplied by the normalization coefficient. The formula is "graph threat score = Σ(node ​​threat score) / sqrt(total number of nodes)". A threshold of 60 points is set, and only graphs exceeding the threshold enter the template matching process. For graphs that pass the screening, the feature extraction process is started to extract node type sequences, topological features, IoC features, and time features. The feature hash value is calculated as the query key. The knowledge base query interface is called, and an HTTPGET request is constructed and sent to / api / knowledge-base / templates / search. The parameters include feature_hash, attack_type_tags, similarity_threshold (0.85), and top_k (10). The knowledge base service first searches the feature index table for records that perfectly match the `feature_hash`. If a match is found, the corresponding template is returned directly (similarity 1.0). If no match is found, similarity matching is initiated. All template feature hash values ​​are loaded, and the Hamming distance between each template and the query hash is calculated (the number of 1s in the bitwise XOR operation of two 128-bit binary strings). The similarity is calculated as (128 - Hamming distance) / 128. Simultaneously, the node type sequence similarity is calculated using the Longest Common Subsequence (LCS) algorithm. The ratio of the LCS length to the shorter sequence length is used as the sequence similarity. The overall similarity is calculated as: Feature Hash Similarity × 0.6 + Sequence Similarity × 0.4. Templates with a similarity score exceeding 0.85 are filtered and returned as the Top-10 in descending order of score. The returned JSON array contains `template_id`, `template_name`, `similarity_score`, `success_rate`, `applied_count`, and `response_action_sequence`. After receiving the query results, check if the array is empty: if empty, go back to step 103 to call the survey agent for manual analysis; if not empty, select the first template with the highest score and record the matching result in the case association table (graph_id, template_id, matching similarity, matching timestamp). Call the response agent to execute the template. The interface is POST / api / response-agent / execute-template, and the parameters include template_id and context_data (context data: attacker IP, affected asset ID, stolen credentials, etc.).The responding agent loads the complete template_id data from the knowledge base, extracts the response_action_sequence field, and iterates through the action items, replacing the parameter placeholders with the actual values ​​of context_data: for example. Replace with {"ip_address": "203.0.113.100"}. After parameter replacement, reuse the execution flow of step 104: traverse the action sequence to calculate the operation risk value, determine the execution method (automatic or approval) based on the risk value, call the device API to execute the response action according to priority and dependency, collect the execution results and record them in the execution log, and update the status of the record corresponding to graph_id from "pending_analysis" to "responding" and then to "completed" in real time. Start subsequent monitoring tasks, continuously monitor relevant logs for 72 hours after the response is completed, detect new attack events similar to the original attack path, and calculate the threat blocking rate by counting the number of subsequent attack attempts and the number of successful blocking attempts. After the monitoring period ends, write the data of this case back to the knowledge base, update the template applied_count by 1, and recalculate the average success rate = (original success_rate × original applied_count + this blocking rate) / (original applied_count + 1), realizing the self-evolution and continuous improvement of the knowledge base through a closed-loop feedback mechanism.

[0081] In the above embodiments, a basic threat detection and response framework was implemented through attack behavior graph construction, pattern matching, and intelligent investigation. To further improve the automation level and efficiency of response strategies and reduce the time consumption of repetitive threat analysis, this application also provides another managed threat detection method based on AI agents. This method achieves automated threat response decision-making by extracting the mapping relationship between attack path features and response action sequences from successful response cases and constructing a knowledge base template. This enables the system to handle response requirements for known attack patterns more quickly, and ensures the accuracy and effectiveness of the knowledge base through continuous monitoring verification and threat blocking rate assessment. The following section combines... Figure 2 Another managed threat detection method based on AI agents is described in the embodiments of this application:

[0082] Please see Figure 2 This is a flowchart illustrating a threat detection managed method based on an AI agent in an embodiment of this application.

[0083] Step 201: Link and store all attack paths associated with the execution of response actions, structured investigation reports, response strategy execution sequences, and feedback results of response actions as candidate historical handling cases.

[0084] The attack path associated with the response action execution is the original attack behavior graph path that triggered the response operation, including node sequences, edge relationships, and matching attack patterns. The structured investigation report is an analysis document containing attack types, evidence chains, and affected assets. The response strategy execution sequence is a list of response action units arranged chronologically. The feedback result of the response action execution is the status data after execution, including the execution status of each action, execution duration, device response, and error information. Candidate historical disposal cases are complete disposal records that link and store the above four types of data, including case identifier, creation time, and disposal status.

[0085] Specifically, after completing the response action, all execution feedback results are collected, including action identifier, execution status, execution duration, device response data, and error information. Complete attack path data triggering this response is loaded from the graph database, including a node list, edge relationships, path features, matching template identifiers, and comprehensive risk scores. The structured investigation report generated in step 1033 is extracted, including attack type, timeline, evidence chain, affected assets, and threat level. The response strategy execution sequence generated in step 1042 is extracted, including all action units and their execution order, dependencies, and operation parameters. A unique case identifier is generated, and candidate historical handling case data objects are constructed, including case identifier, attack path data, investigation report data, execution sequence data, feedback result data, creation timestamp, and an initial value of "processing" for the handling status field. The case objects are written to the case library database, establishing an association index between attack path identifiers and case identifiers. Subsequent monitoring tasks are initiated, continuously monitoring relevant logs for 72 hours after the response is completed, detecting new attack events similar to the original attack path, and recording the number of attack recurrences and preventions. After the monitoring period ends, the threat blocking rate is calculated as the number of blocked attacks divided by the total number of attack attempts. The threat blocking rate field and handling status of the case object are then updated to "completed".

[0086] In one possible implementation, before selecting historical handling cases with a threat blocking rate greater than the blocking rate threshold from among the candidate historical handling cases, the process further includes steps 2011 and 2013, as follows:

[0087] Step 2011: For each candidate historical handling case, obtain the continuous monitoring log within the preset time window after the response action is completed.

[0088] The completion of a response action is the point in time when all action units in the response policy execution sequence have been completed. The preset time window is the time range for continuous monitoring after the response is completed; the default setting is 72 hours. Continuous monitoring logs are all security device log data collected within the time window, including firewall logs, endpoint detection logs, intrusion prevention logs, and network traffic logs.

[0089] Specifically, the system queries all candidate historical handling case records from the case database and extracts the execution completion timestamp of each case's response action. Based on the completion timestamp, it calculates the start and end times of the monitoring window; the start time equals the completion timestamp, and the end time equals the completion timestamp plus 72 hours. It calls the log collection interface to query all security logs within the time window, constructing query conditions including time range filtering, device type filtering, and log level filtering. It queries the raw log records within this time range from the time-series database, using timestamp indexes to accelerate the query and setting a query result limit of 1 million records to avoid memory overflow. The queried log data is sorted in ascending order by timestamp and stored in a temporary dataset. Standardized parsing is performed on the log data to extract fields such as source address, destination address, event type, protocol port, and action result. The parsed continuous monitoring logs are associated with case identifiers and stored, establishing a mapping relationship between case identifiers and the monitoring log set, completing the collection and preprocessing of monitoring data.

[0090] Step 2012: Based on the attack paths in the candidate historical handling cases, extract subsequent attack probing events associated with the attack paths from the continuous monitoring logs.

[0091] Attack paths in candidate historical handling cases are the original attack behavior graph path data contained in the case records, including node sequences, address information, and event types. Continuous monitoring logs are the collection of security log data within the time window. Attack path correlation is the criterion for determining whether a new event is similar to the original attack path, including address matching, event type matching, and behavior pattern matching. Subsequent attack probing events are security events in the monitoring logs that have similar characteristics to the original attack, indicating the attacker's continued attempts or attack recurrence.

[0092] Specifically, the system iterates through each candidate case, extracting attack path feature information from the case data, including the attacker's source IP address list, target asset IP address list, protocol port combinations used, event type sequence, malicious file hash value, and command and control server address. It loads the corresponding continuous monitoring log set for that case, iterates through each log record, and performs correlation matching. Matching rules include: source address matching (the log's source IP exists in the attacker's IP list); target address matching (the log's target IP exists in the affected asset list); protocol port matching (the log's protocol and port combination match the communication characteristics in the attack path); event type matching (the log's event type exists in the attack path's event type sequence); and behavior pattern matching (using a sequence similarity algorithm to compare the log event sequence with the attack path node type sequence; a similarity greater than 0.7 is considered a match). Log records satisfying any of these matching rules are marked as subsequent attack probe events. The complete field data of this event, including timestamp, source address, target address, event type, and action result, is extracted. The extracted event is added to the subsequent probe event list, completing the identification and extraction of related events.

[0093] Step 2013: Analyze the action execution results of subsequent attack probing events, and count the number of successfully blocked events and the total number of subsequent attack probing events; calculate the threat blocking rate of candidate historical handling cases based on the ratio of the number of blocked events to the total number of subsequent attack probing events.

[0094] Subsequent attack probes are a list of security events identified from monitoring logs that are related to the original attack. The action execution result is the security device's response to the event, with values ​​including allow, deny, block, and isolate. Blocked events are probes whose action execution result is deny or block, indicating that the response policy successfully prevented the attack attempt. The total number of subsequent attack probes is the number of elements in the probe list. The threat blocking rate is the ratio of the number of blocked events to the total number of probes, representing a quantitative indicator of response effectiveness.

[0095] Specifically, the system receives a list of subsequent attack probe events and initializes the blocking event counter and the total event counter to 0. It iterates through the event list, extracting the action execution result field value for each event. It determines whether the action result is a blocking action such as denial, blocking, or isolation; if the condition is met, the blocking event counter is incremented by 1. After the iteration is complete, the total event counter equals the length of the event list. The threat blocking rate is calculated as the number of blocked events divided by the total number of events, handling division by zero. When the total number of events is 0, the threat blocking rate is set to 1.0, indicating no attack recurrence. The calculated threat blocking rate is updated in the threat blocking rate field of the candidate historical handling case record, and the handling status field is updated to "completed," recording the calculation timestamp. The updated case data is written to the case database to complete the case effectiveness evaluation.

[0096] Step 202: Select historical cases with a threat blocking rate greater than the blocking rate threshold from the candidate historical cases; extract the target attack path features and the corresponding target response action sequence from the historical cases.

[0097] Candidate historical handling cases are the complete set of handling records generated in step 201. Threat blocking rate is a quantitative indicator of response effectiveness, calculated by dividing the number of attacks successfully blocked during the monitoring period by the total number of attack attempts. The blocking rate threshold is the critical value for determining the effectiveness of the handling, set to 0.9 by default. Historical handling cases are valid cases where the threat blocking rate exceeds the threshold. Target attack path features are feature vectors extracted from the attack paths of valid cases, including node type sequences, topological features, and temporal features. Target response action sequence is the sequence of response strategies actually executed in valid cases.

[0098] Specifically, the system initiates a scheduled task to query the case database, filtering case records with a completed handling status and a threat blocking rate greater than or equal to 0.9. For the selected historical cases, features are extracted from the attack path data, event type sequences are extracted by traversing nodes, path length and average time interval are calculated, and the set of involved protocol types and port numbers, as well as malicious IP geographical location and file type tags, are extracted. The feature data is organized into feature vectors, and a 128-bit feature fingerprint is generated using a hash algorithm as a unique identifier for the attack path. The target response action sequence is extracted from the execution sequence data, including the action type, parameter template, and execution order of all action units, completing the feature and sequence extraction preparation for subsequent template generation.

[0099] Step 203: Use the target attack path characteristics as the triggering condition and the target response action sequence as the executor to generate a standard handling template through mapping and binding.

[0100] The target attack path features are the feature vector representation of the attack path, serving as the template trigger condition. The trigger condition is the matching rule definition for the standard handling template, including node type sequence constraints, topological feature constraints, and temporal feature constraints. The target response action sequence is a verified and effective response strategy, serving as the template executor. The executor is a list of response actions defined in the template, including action type, parameter placeholders, and execution order. Mapping and binding are key-value pair mappings that associate the trigger condition with the executor. The standard handling template is a reusable response strategy template object, containing a template identifier, trigger condition, executor, and metadata.

[0101] Specifically, the system receives target attack path characteristics and target response action sequence data. It constructs a trigger condition object, converting the node type sequence into constraint expressions, topological features into path length and width ranges, and time features into average interval thresholds. It constructs an execution body object, traversing the response action sequence and replacing specific parameter values ​​with placeholders, malicious IP parameters with variable markers, and host identifiers with asset markers. It generates a unique template identifier and automatically names the template based on the attack type. It constructs a standard handling template data object, including template identifier, template name, trigger condition, execution body, initial success rate value, initial application count value (1), creation timestamp, and attack type tag. It performs a mapping and binding operation, establishing an index mapping using the feature fingerprint as the key and the template identifier as the value, completing the template object construction and preparing for knowledge base storage.

[0102] Step 204: Store the standard handling template in the knowledge base of the preset response agent, and establish an index relationship between the standard handling template and the target attack path characteristics.

[0103] Standard response templates are generated reusable response strategy objects. The knowledge base of the pre-defined response agent is a template storage system maintained by the response agent, using a relational database to store template objects and index relationships. Target attack path features are the triggering conditions identifiers for the templates. The index relationships are a mapping between feature fingerprints and template identifiers, supporting fast query matching.

[0104] Specifically, the system receives a standard processing template object and submits the template data by calling the knowledge base ingestion interface. The knowledge base service verifies the data format and the integrity of required fields, calculates the template feature fingerprint, and queries the feature index table to check for existing templates with the same or similar features. If the feature fingerprint is a perfect match or the Hamming distance is less than 10, instead of creating a new template, the application count of the existing template is incremented by 1, and the average success rate is recalculated as the original success rate multiplied by the sum of the original application count and the new case blocking rate, divided by the original application count plus 1. If no similar template exists, the new template is inserted into the template table, and an index record is created in the feature index table, with the feature fingerprint as the index key pointing to the template identifier. A full-text index is created in the template table to support attack type tag queries, and a hash index is created in the feature fingerprint field to support exact matching. A successful ingestion response is returned. After the knowledge base update is complete, a cache refresh is triggered, loading the new template into the memory cache to improve subsequent query performance. All responding agent instances are notified via a message queue to synchronize the knowledge base update, ensuring that distributed agents use the latest template data.

[0105] The following describes a threat detection managed system based on an AI agent from the perspective of hardware processing in an embodiment of this invention. Please refer to [link / reference]. Figure 3 This is a schematic diagram of the structure of a threat detection managed system based on an AI agent in an embodiment of this application.

[0106] It should be noted that, Figure 3 The structure of the AI ​​agent-based threat detection managed system shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0107] like Figure 3 As shown, a threat detection managed system based on an AI agent includes a Central Processing Unit (CPU) 301, which can perform various appropriate actions and processes according to a program stored in Read-Only Memory (ROM) 302 or a program loaded from storage portion 308 into Random Access Memory (RAM) 303, such as executing the methods described in the above embodiments. The RAM 303 also stores various programs and data required for system operation. The CPU 301, ROM 302, and RAM 303 are interconnected via a bus 304. An Input / Output (I / O) interface 305 is also connected to the bus 304.

[0108] The following components are connected to I / O interface 305: input section 306 including audio input devices, push-button switches, etc.; output section 307 including a liquid crystal display (LCD) and audio output devices, indicator lights, etc.; storage section 308 including a hard disk, etc.; and communication section 309 including a network interface card such as a LAN (Local Area Network) card, modem, etc. Communication section 309 performs communication processing via a network such as the Internet. Drive 310 is also connected to I / O interface 305 as needed. Removable media 311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 310 as needed so that computer programs read from them can be installed into storage section 308 as needed.

[0109] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311. When the computer program is executed by central processing unit (CPU) 301, it performs the various functions defined in the present invention.

[0110] It should be noted that specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0111] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0112] Specifically, the AI-based threat detection managed system of this embodiment includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, it implements the AI-based threat detection managed method provided in the above embodiment.

[0113] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the AI-based threat detection managed system described in the above embodiments; or it may exist independently and not incorporated into the AI-based threat detection managed system. The storage medium carries one or more computer programs, which, when executed by a processor of the AI-based threat detection managed system, enable the AI-based threat detection managed system to implement the IoT-based encrypted data transmission-based threat detection managed method provided in the above embodiments.

Claims

1. A managed threat detection method based on AI intelligent agents, characterized in that, The method includes: Obtain the security logs of heterogeneous security devices, and extract the source address identifier and the destination address identifier from the security logs; Based on the source address identifier and the target address identifier, asset attribute information and threat attribute information are matched to generate enriched data records. Based on this enriched data, an attack behavior graph is constructed, including: The enriched data records are grouped according to time windows; Within each time window, multiple related enriched data records are identified based on the identifier matching relationship and event sequence among the enriched data records; The attack behavior graph is constructed by using nodes to represent individual enriched data and directed edges to represent the correlation between enriched data. The attack behavior graph is matched with a preset attack pattern template to extract the successfully matched attack paths. A preset investigation agent is then invoked to conduct an automated investigation of the attack paths, generating a structured investigation report containing a chain of evidence. Based on the structured survey report, a preset response agent is invoked to dynamically orchestrate response strategies, generate a response strategy execution sequence, and determine the execution method according to the operational risk value of the response strategy execution sequence to complete the cross-device response action, including: For each response action unit in the response strategy execution sequence, the operational risk value is determined by weighting the business importance level of the affected asset and the risk level of the action type corresponding to the response action unit. When the operational risk value exceeds the preset approval threshold, the response strategy execution sequence is pushed to the approval interface, and execution is triggered after receiving the approval instruction returned by the approval interface; When the operational risk value does not exceed the preset approval threshold, it is marked as automatically executed and execution is triggered. The security device operation interface corresponding to each of the response action units is called sequentially according to the response strategy execution sequence to complete the cross-device response action execution. Extract target attack path features and target response action sequences from historical successful response cases, and map and bind the target attack path features and target response action sequences to generate a standard handling template, including: The target attack path characteristics are used as triggering conditions, and the target response action sequence is used as the executor. The standard handling template is generated through mapping and binding. The standard handling template is then added to the knowledge base of the preset response agent. When a new attack behavior graph is detected, the standard handling template that matches the new attack behavior graph is queried in the knowledge base, and the preset response agent is invoked to execute the target response action sequence in the standard handling template.

2. The method according to claim 1, characterized in that, The step of matching asset attribute information and threat attribute information based on the source address identifier and the target address identifier to generate enriched data records includes: Query the asset information database and threat intelligence database to obtain asset attribute information and threat attribute information associated with the source address identifier and the target address identifier; The asset attribute information and the threat attribute information are attached as context labels to the corresponding security log to generate the enriched data record.

3. The method according to claim 1, characterized in that, The process involves performing graph structure matching between the attack behavior graph and a preset attack pattern template, extracting successfully matched attack paths, and invoking a preset investigation agent to automatically investigate the attack paths, generating a structured investigation report containing a chain of evidence, including: Match each path in the attack behavior graph with the preset attack pattern template; For a successfully matched attack path, a weighted calculation is performed based on the path characteristics and node attributes in the attack path to determine a comprehensive risk score, and a threat queue to be dealt with is generated according to the comprehensive risk score. Extract the successfully matched attack paths from the queue of threats to be dealt with; The system invokes a pre-configured investigation agent with pre-defined tool invocation rules, and selects and sequentially invokes the corresponding external tool interfaces based on the event type of the nodes in the attack path. Key evidence fields are extracted from the return results of each of the external tool interfaces, and the key evidence fields are associated and mapped with the node information in the attack path to generate the structured investigation report containing the evidence chain.

4. The method according to claim 1, characterized in that, The dynamic orchestration of response strategies based on the structured survey report by invoking a preset response agent to generate a response strategy execution sequence includes: Analyze the threat types and list of affected assets in the structured investigation report; Invoke a preset response agent with a pre-configured action atom library, and select a response action unit corresponding to the operation interface of various security devices from the action atom library; The response action units are identified according to the threat type and the asset associations in the affected asset list, and the identified response action units are arranged according to the execution sequence to generate the response strategy execution sequence.

5. The method according to claim 1, characterized in that, The extraction of target attack path features and target response action sequences from historical cases of successful response actions, and the addition of the standard handling template to the knowledge base of the preset response agent, include: All attack paths associated with response actions, structured investigation reports, response strategy execution sequences, and feedback results of response actions are associated and stored as candidate historical handling cases. The threat blocking rate of the candidate historical handling cases is calculated based on the ratio of the number of blocked events to the total number of subsequent attack probes. Historical handling cases with a threat blocking rate greater than the blocking rate threshold are selected from all the candidate historical handling cases. Extract the target attack path features and corresponding target response action sequences from the historical handling cases; The standard handling template is stored in the knowledge base of the preset response agent, and an index relationship is established between the standard handling template and the target attack path features.

6. The method according to claim 5, characterized in that, Before selecting historical handling cases with a threat blocking rate greater than the blocking rate threshold from each of the candidate historical handling cases, the process further includes: For each candidate historical handling case, obtain continuous monitoring logs within a preset time window after the response action is completed; Based on the attack paths in the candidate historical handling cases, subsequent attack probing events associated with the attack paths are extracted from the continuous monitoring logs; Analyze the execution results of the subsequent attack probing events, and count the number of successfully intercepted blocking events and the total number of subsequent attack probing events.

7. A managed threat detection system based on AI intelligent agents, characterized in that, The AI-based agent-based threat detection managed system includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the AI-based agent-based threat detection managed system to perform the method as described in any one of claims 1-6.

8. A computer-readable storage medium comprising instructions, characterized in that, When the instructions are executed on an AI agent-based threat detection managed system, the AI ​​agent-based threat detection managed system performs the method as described in any one of claims 1-6.

9. A computer program product, characterized in that, When the computer program product is run on an AI agent-based threat detection managed system, the AI ​​agent-based threat detection managed system performs the method as described in any one of claims 1-6.

Images