Intelligent alarm auditing and processing method based on large language model

Abstract

The embodiment of the application relates to the technical field of network security and intelligent operation and maintenance, and particularly relates to an intelligent alarm auditing and processing method based on a large language model, which comprises the following steps: collecting multi-source security data and standardizing and integrating the multi-source security data to form a unified event object; constructing an alarm context to obtain an alarm intention, a security entity and an investigation target; obtaining an associated knowledge fragment, generating an initial search plan and performing directional query to obtain a query result; performing evidence screening on the query result to obtain an initial evidence set and judging whether the initial evidence set meets an evidence sufficiency condition; if the initial evidence set does not meet the evidence sufficiency condition, generating a supplementary investigation step and performing progressive tracking to obtain an extended evidence set; generating a treatment suggestion based on the extended evidence set, performing verification, and generating an auditing treatment result according to the verification result. Through the progressive investigation and evidence verification mechanism of multi-agent collaboration, the automatic evidence chain closure and credible auditing treatment of complex security alarms are realized.

Description

Technical Field

[0001] This application relates to the fields of network security and intelligent operation and maintenance technology, and in particular to an intelligent alarm auditing and processing method based on a large language model. Background Technology

[0002] As enterprise network environments, cloud-native businesses, and API open platforms continue to become more complex, the number of alerts received by security operations centers is exploding daily. Existing technologies suffer from the following problems: Current alert handling methods primarily rely on rule matching, manual retrieval, and experience-based judgment. Analysts need to manually query threat intelligence, retrieve logs, compare entity relationships, and deduce attack chains across multiple systems. This process is not only time-consuming but also prone to overlooking covert anomalies across hosts, accounts, and API call chains. When facing advanced persistent threats, multi-stage intrusions, abuse of abnormal call chains, and camouflage, traditional methods struggle to form a complete and verifiable loop of evidence.

[0003] Although some intelligent analysis systems have incorporated machine learning or knowledge retrieval capabilities, the following shortcomings remain: First, they lack intent understanding and multi-step reasoning capabilities based on large language models, making it impossible to adaptively adjust retrieval paths based on intermediate investigation results. Second, they lack unified and collaborative orchestration of external threat databases, historical case libraries, situational awareness platform knowledge bases, and system log databases, resulting in low knowledge utilization. Third, they lack security verification mechanisms for intelligent analysis conclusions, which may lead to output conclusions that are misleading, lack sufficient evidence, or exceed the scope of inference. Fourth, they lack optimization strategies for interface calls and knowledge retrieval processes, making it difficult to meet efficiency requirements in real-time alarm processing scenarios. Fifth, they lack efficient linkage with the situational awareness platform, resulting in insufficient alarm context reuse and unclear write-back links.

[0004] Therefore, there is an urgent need to provide an intelligent alarm auditing and processing technology solution that can take a large language model as the core and combine intelligent agents, external threat databases, system log databases and situational awareness platforms to achieve efficient, verifiable and closed-loop identification and handling of complex abnormal behaviors. Summary of the Invention

[0005] To address this, the present invention provides an intelligent alarm auditing and processing method based on a large language model, which overcomes the problems of fragmented multi-source alarms, high cost of manual investigation, incomplete evidence chain, and insufficient interpretability of alarm conclusions in the prior art.

[0006] To achieve the above objectives, this invention provides an intelligent alarm auditing and processing method based on a large language model. It includes: Step S1: Collect security-related data from different data sources, and perform standardization and correlation integration on the security-related data to form a unified event object; Step S2: Construct an alarm context based on the unified event object, parse the alarm context to obtain the alarm intent, security entity and investigation target; Step S3: Obtain the associated knowledge fragments corresponding to the security entity; generate an initial retrieval plan based on the alarm intent, the security entity, and the associated knowledge fragments; and execute a targeted query based on the initial retrieval plan to obtain the targeted query results. Step S4: Perform evidence screening and association processing on the targeted query results to obtain an initial evidence set, and determine whether the initial evidence set meets the preset evidence sufficiency conditions; Step S5: In response to the initial evidence set not meeting the preset evidence sufficiency conditions, a supplementary investigation step is generated based on the initial evidence set and the investigation objective, and the supplementary investigation step is progressively tracked to obtain an extended evidence set. In response to the initial evidence set meeting the preset evidence sufficiency conditions, the initial evidence set is used as the extended evidence set. Step S6: Generate handling suggestions and alarm conclusions based on the extended evidence set, and verify the alarm conclusions, the extended evidence set, and the handling suggestions to obtain the verification results; Step S7: Using the verification result, combined with the alarm conclusion, the extended evidence set, and the handling suggestions, an audit handling result is generated.

[0007] Further, in step S1, a unified event object is formed, including: The security-related data from different sources are processed by time unification, field standardization, and entity normalization to obtain the processing results; Based on the processing results, establish the relationship between cross-source data, and aggregate and generate a unified event object according to the relationship.

[0008] Further, in step S2, an alarm context is constructed based on the unified event object, including: Obtain alarm association metadata associated with the unified event object, and aggregate the alarm association metadata with the unified event object to form an alarm context.

[0009] Further, in step S2, the alarm context is parsed to obtain the alarm intent, security entity, and investigation target, including: The alarm context is semantically understood to identify the alarm intent, the security entities involved in the alarm context are extracted, and the investigation target is generated based on the alarm intent and the security entities.

[0010] Further, in step S3, an initial search plan is generated, including: Obtain the associated knowledge fragments corresponding to the security entity; Determine the search direction based on the alarm intent; The type of the target entity to be retrieved is determined based on the security entity; Determine the query constraints and priorities corresponding to the target entity type based on the associated knowledge fragments; An initial search plan is generated based on the search direction, the target entity type, the query constraints, and the priority.

[0011] Further, based on the associated knowledge fragments, the query constraints and priorities corresponding to the target entity type are determined, including: Extract query constraints from the associated knowledge fragments; Prioritize each target entity type based on the threat level of the associated knowledge fragments; Associate the query constraints and priorities with the corresponding target entity types.

[0012] Further, in step S4, an initial evidence set is obtained, including: The targeted query results are deduplicated to obtain the deduplicated query results; The deduplicated query results are sorted by timestamp to obtain a sorted evidence sequence; The sorted evidence sequence is subjected to anomaly scoring and filtering to remove regular events below a preset anomaly threshold, thereby obtaining filtered valid evidence. The filtered valid evidence is correlated to establish causal relationships between the evidence, resulting in a correlated evidence set. The associated evidence sets are aggregated to form an initial evidence set.

[0013] Furthermore, the filtered valid evidence includes: Map each piece of evidence in the sorted evidence sequence to a feature vector; The feature vectors are encoded and decoded to obtain the reconstruction error of each piece of evidence; Evidence with a reconstruction error greater than a preset anomaly threshold is retained as valid evidence, while evidence with a reconstruction error less than or equal to the preset anomaly threshold is discarded.

[0014] Further, in step S4, determining whether the initial evidence set meets the preset evidence sufficiency conditions includes: Determine the required types of key evidence and the minimum amount of evidence required for each type based on the stated investigation objectives; Traverse the evidence in the initial evidence set, identify the key evidence types contained therein, and determine the number of evidence corresponding to each type; If the identified key evidence types cover all required types, and the number of evidence corresponding to each type is greater than or equal to the corresponding preset minimum number, then the initial evidence set is determined to meet the preset evidence sufficiency conditions. If the identified key evidence types do not cover all required types, or if the number of evidence corresponding to any type is less than the corresponding preset minimum number, then the initial evidence set is determined to not meet the preset evidence sufficiency conditions.

[0015] Further, the feature is that, in step S5, a supplementary investigation step is generated, including: The initial evidence set is compared with the key evidence required for the investigation objective to identify the missing key evidence items; Based on the missing key evidence items, determine the types of entities that need to be tracked and the corresponding entities to be tracked; The investigation order is determined based on the logical relationships between the entities to be tracked, and a corresponding query template is configured for each entity to be tracked. Configure the cycle step budget and stop conditions, and combine the entity to be tracked, the survey order, the query template, the cycle step budget, and the stop conditions to generate supplementary survey steps.

[0016] Furthermore, the investigation order is determined based on the logical relationships between the entities to be tracked, including: Based on the missing key evidence items, determine the dependencies between the entities to be tracked; Entities without dependencies are identified as entities to be investigated in parallel, and entities with dependencies are investigated in the order of being depended on first and the dependencies being investigated second. The investigation order is associated with and stored with each entity to be tracked.

[0017] Further, in step S5, an expanded set of evidence is obtained, including: Select the entity to be tracked according to the investigation order in the supplementary investigation steps; Execute a targeted query based on the query template corresponding to the currently tracked entity to obtain the query results for this round; The results of this round of queries are correlated with the existing evidence set, and the evidence set is updated. Determine whether the updated evidence set meets the stopping condition in the supplementary investigation step. If it does, terminate the tracking and output the updated evidence set as an extended evidence set. If it does not meet the condition, determine the next entity to be tracked based on the updated evidence set and return to the step of executing the targeted query until the stopping condition is met.

[0018] Further, in step S6, a disposal recommendation is generated based on the expanded evidence set, including: Reconstruct the chain of anomalous behavior based on the extended evidence set to identify the attack phase; Assess the risk level based on the expanded evidence set and the attack phases; The expanded set of evidence is matched with a preset strategy to determine the appropriate action. Based on the stated action, the stated risk level, and the stated attack phase, a response recommendation is generated.

[0019] Further, in step S6, the verification result is obtained, including: The verifiability of the alarm conclusion is verified to obtain the first sub-verification result; The consistency of the alarm conclusion and the extended evidence set is verified to obtain the second sub-verification result; The proposed handling measures are validated using security policies to obtain a third sub-validation result. The verification result is determined based on the first sub-verification result, the second sub-verification result, and the third sub-verification result.

[0020] Further, in step S7, an audit handling result is generated, including: In response to the verification result being passed, an audit conclusion and an explanation of the abnormal behavior are generated based on the alarm conclusion, an evidence chain is generated based on the extended evidence set, and a corresponding action is generated based on the handling suggestion. The audit conclusions, explanations of abnormal behavior, chains of evidence, and handling recommendations are structured and assembled to generate audit handling results.

[0021] Further, determining whether the verification result is passed includes: If the first sub-verification result, the second sub-verification result, and the third sub-verification result are all passed, then the verification result is passed.

[0022] Compared with the prior art, the beneficial effects of the present invention are that by performing time unification, field standardization and entity normalization processing on security-related data from different sources, and establishing cross-source association relationships to aggregate and generate structured unified event objects, the present invention can effectively eliminate naming ambiguity and duplicate descriptions in multi-source data, provide a standardized and associative data foundation for subsequent alarm auditing, and significantly improve data processing efficiency and entity tracing capabilities in multi-source heterogeneous scenarios.

[0023] Furthermore, this invention addresses the issues of information conflict and misinformation interference in multi-source heterogeneous data by introducing data source credibility assessment and source identification. Subsequent evidence screening, evidence sufficiency judgment, and disposal recommendation generation can be weighted according to credibility, prioritizing the adoption of highly credible evidence chains, significantly improving the robustness and reliability of audit results and reducing the negative impact of low-quality data sources on analytical conclusions.

[0024] Furthermore, by introducing a large language model as the core of reasoning and combining it with a multi-role prompting mechanism, this invention performs deep semantic understanding and security entity extraction on the alarm context. It can accurately identify the alarm intent and risk type, and automatically generate structured investigation targets, significantly improving the intelligence level of alarm parsing and the accuracy of investigation direction, providing a reliable foundation for subsequent progressive tracking and evidence chain closure.

[0025] Furthermore, this invention achieves deep integration of audit intelligence and large language model, combined with retrieval enhancement generation mechanism to obtain related knowledge fragments, and adaptively generates a structured initial retrieval plan based on alarm intent, security entity, and related knowledge fragments, including entity type, query template, time window, and priority. At the same time, it automatically extracts query constraints from related knowledge fragments and dynamically allocates priorities according to threat level, which makes the initial retrieval plan more targeted and effective, avoids invalid queries, and significantly improves the intelligence level, retrieval efficiency, and accuracy of alarm investigation.

[0026] Furthermore, by drawing on successful historical experiences, this invention makes the initial search plan more targeted and more in line with the actual and effective investigation path, avoids invalid or inefficient search attempts, significantly accelerates the convergence speed from alarms to preliminary evidence, and realizes the continuous learning and evolution of investigation strategies.

[0027] Furthermore, this invention effectively avoids the inflation of irrelevant results and filters high-frequency normal background events by using entity-type-oriented queries and anomaly scoring filtering based on autoencoder reconstruction errors, retaining only high-risk, low-frequency, or suspicious behavior events to form a high-quality, compact initial evidence set. Simultaneously, by setting key evidence types and quantity thresholds based on historical statistical results and automatically traversing and matching the initial evidence set, it can objectively and quantitatively assess the sufficiency of evidence, providing a clear basis for determining whether to trigger a progressive investigation, avoiding misjudgments or omissions due to insufficient evidence, and significantly improving the intelligence and reliability of alarm auditing.

[0028] Furthermore, this invention automatically identifies missing evidence items, analyzes entity dependencies, and determines the investigation order by following the intelligent agent. It configures an investigation strategy that combines parallel and progressive approaches, while setting a cycle step budget and multi-dimensional stopping conditions. This enables the generation of targeted, structured supplementary investigation steps and automatically executes multiple rounds of progressive tracking queries according to the investigation order. After each round of queries, the evidence set is dynamically updated and stopping conditions are determined to ensure timely termination when the evidence is sufficient or a preset boundary is reached. This effectively fills gaps in the evidence chain, avoids infinite loops, and significantly improves the automation, efficiency, and controllability of progressive investigations.

[0029] Furthermore, this invention significantly improves the investigation speed of complex alarms through multi-agent parallel investigation. Simultaneously, the introduction of an arbitration mechanism ensures that evidence from different investigation paths can be objectively and consistently integrated, avoiding inconsistencies in conclusions caused by conflicting evidence, and significantly enhancing the parallel processing capability and consistency of conclusions of the audit system.

[0030] Furthermore, this invention avoids the risks associated with automated processing through pre-assessment, ensuring that the processing recommendations meet security requirements while remaining compatible with actual operational permissions and business continuity constraints, thus significantly improving the practicality and security of automated processing.

[0031] Furthermore, this invention reconstructs abnormal behavior chains through a security intelligent agent to identify attack phases, comprehensively assess risk levels, and match preset strategies to determine appropriate actions, generating structured and evidence-based handling recommendations. Simultaneously, a triple verification mechanism—including evidence verifiability verification, consistency verification, and security policy verification—effectively identifies issues such as missing evidence, logical contradictions, and policy violations. When verification fails, a rollback investigation is automatically triggered, feeding back the verification failure information to the follow-up intelligent agent to further complete the evidence chain, forming a complete closed-loop audit process. This significantly improves the reliability, credibility, and intelligence level of automated alarm auditing, making it suitable for application scenarios such as situational awareness platforms, host security analysis platforms, and intelligent security operations.

[0032] Furthermore, this invention generates a complete audit handling result that includes audit conclusions, explanations of abnormal behavior, evidence chains, and handling suggestions by structuring and assembling the conclusions that pass the verification. It also supports writing back to the situational awareness platform or work order system, thus realizing the automated closed-loop handling of alarm audits. For cases where the verification fails, a rollback investigation mechanism is automatically triggered to ensure the integrity of the evidence chain and the reliability of the conclusions.

[0033] Furthermore, through a closed-loop feedback mechanism, this invention enables the system's alarm parsing capabilities, retrieval plan generation capabilities, evidence sufficiency judgment criteria, and the rationality of handling suggestions to continuously optimize and improve itself, significantly enhancing its long-term value and inventiveness. Attached Figure Description

[0034] Figure 1 This is a flowchart of the intelligent alarm auditing and processing method based on a large language model according to an embodiment of this application; Figure 2 This is a flowchart illustrating the determination of whether the initial evidence set meets the preset evidence sufficiency conditions in the intelligent alarm auditing and processing method based on a large language model, as described in this application embodiment. Detailed Implementation

[0035] To make the objectives and advantages of the present invention clearer, the present invention will be further described below with reference to embodiments; it should be understood that the specific embodiments described herein are merely for explaining the present invention and are not intended to limit the present invention.

[0036] Preferred embodiments of the present invention will now be described with reference to the accompanying drawings. Those skilled in the art should understand that these embodiments are merely illustrative of the technical principles of the present invention and are not intended to limit the scope of protection of the present invention.

[0037] Please see Figures 1-2 As shown, Figure 1 This is a flowchart of the intelligent alarm auditing and processing method based on a large language model according to an embodiment of this application; Figure 2 This is a flowchart illustrating the determination of whether the initial evidence set meets the preset evidence sufficiency conditions in the intelligent alarm auditing and processing method based on a large language model, as described in this application embodiment.

[0038] The technical solution provided in this application includes the following steps: Step S1: Collect security-related data from different data sources, and perform standardization and correlation integration on the security-related data to form a unified event object; Step S2: Construct an alarm context based on the unified event object, parse the alarm context to obtain the alarm intent, security entity and investigation target; Step S3: Obtain the associated knowledge fragments corresponding to the security entity; generate an initial retrieval plan based on the alarm intent, the security entity, and the associated knowledge fragments; and execute a targeted query based on the initial retrieval plan to obtain the targeted query results. Step S4: Perform evidence screening and association processing on the targeted query results to obtain an initial evidence set, and determine whether the initial evidence set meets the preset evidence sufficiency conditions; Step S5: In response to the initial evidence set not meeting the preset evidence sufficiency conditions, a supplementary investigation step is generated based on the initial evidence set and the investigation objective, and the supplementary investigation step is progressively tracked to obtain an extended evidence set; Step S5: In response to the initial evidence set not meeting the preset evidence sufficiency conditions, a supplementary investigation step is generated based on the initial evidence set and the investigation objective, and the supplementary investigation step is progressively tracked to obtain an extended evidence set. In response to the initial evidence set meeting the preset evidence sufficiency conditions, the initial evidence set is used as the extended evidence set. Step S6: Generate handling suggestions and alarm conclusions based on the extended evidence set, and verify the alarm conclusions, the extended evidence set, and the handling suggestions to obtain the verification results; Specifically, in step S1, a unified event object is formed, including: The security-related data from different sources are processed by time unification, field standardization, and entity normalization to obtain the processing results; Based on the processing results, establish the relationship between cross-source data, and aggregate and generate a unified event object according to the relationship.

[0039] In this embodiment, the system receives raw data from situational awareness platforms, security devices, host agents, log systems, and external threat intelligence sources. This data includes alarm titles, alarm descriptions, timestamps, host identifiers, process information, file paths, IP addresses, ports, account identifiers, API call records, asset profile information, alarm rule identifiers, and context log information. Field mapping, time alignment, and format standardization are performed on data from different systems, and a unified identifier is assigned to the same entity across different logs, reducing naming ambiguity and redundant descriptions in multi-source data.

[0040] Raw alerts and logs are aggregated into a unified event object. The unified event object can be represented as:

[0041] Where id represents the event number, time represents the event time, type represents the event type, subject represents the main entity, object represents the object entity, attrs represents extended attributes, and source represents the source system.

[0042] This invention performs time unification, field standardization, and entity normalization on security-related data from different sources, and then aggregates and generates structured unified event objects after establishing cross-source relationships. This effectively eliminates naming ambiguity and duplicate descriptions in multi-source data, provides a standardized and associative data foundation for subsequent alarm auditing, and significantly improves data processing efficiency and entity tracing capabilities in multi-source heterogeneous scenarios.

[0043] Specifically, a dynamic trust score is pre-defined for each access data source (such as a situational awareness platform, host agent, or external threat intelligence source). When generating a unified event object E={id,time,type,subject,object,attrs,source}, a new field, s_trust, is added. The system calculates the trust weight of the event object based on the data source's historical accuracy, false positive rate, and consistency with other sources. Simultaneously, the system records the source chain for each key attribute (such as IP address and process name) in the event object, forming a traceable source map. For example, IP 1.2.3.4, obtained from an external threat intelligence source, is marked as malicious. This source has a historical accuracy rate of 95% and is assigned a trust score of 0.95. The same IP is also extracted from logs reported by an older version host agent, but this agent frequently generates false positives, resulting in a trust score of only 0.6. The system generates two unified event objects and assigns trust scores to each. During subsequent evidence aggregation, evidence with a trust score of 0.95 will receive a higher weight.

[0044] Specifically, the security-related data provided by the situational awareness platform includes, but is not limited to: alarm name, alarm description, risk level, asset identifier, alarm trigger rule ID, associated event ID, and context summary; the security-related data provided by the host agent includes, but is not limited to: hostname, operating system type, process list, process startup parameters, file access records, network connection records, account login records, and API call sequence; the security-related data provided by external threat intelligence sources includes, but is not limited to: malicious IP / domain name, vulnerability number (CVE), attack tool name, malware family, attacker organization affiliation, intelligence confidence level, and active time window.

[0045] This invention addresses the issues of information conflict and misinformation interference in multi-source heterogeneous data by introducing data source credibility assessment and source identification. Subsequent evidence screening, evidence sufficiency assessment, and disposal recommendation generation can be weighted according to credibility, prioritizing the adoption of highly credible evidence chains. This significantly improves the robustness and reliability of audit results and reduces the negative impact of low-quality data sources on analytical conclusions.

[0046] Specifically, in step S2, constructing an alarm context based on the unified event object includes: Obtain alarm association metadata associated with the unified event object, and aggregate the alarm association metadata with the unified event object to form an alarm context.

[0047] Specifically, in step S2, the alarm context is parsed to obtain the alarm intent, security entity, and investigation target, including: The alarm context is semantically understood to identify the alarm intent, the security entities involved in the alarm context are extracted, and the investigation target is generated based on the alarm intent and the security entities.

[0048] In this embodiment, the system constructs an alarm context based on the unified event object. Specifically, the system obtains alarm-related metadata associated with the unified event object, including alarm title, alarm description, risk label, context summary output by the situational awareness platform, and asset profile information; the alarm-related metadata is aggregated with the unified event object to form an alarm context. The system parses the alarm context. Specifically, using a large language model as the inference core, and loading role prompts such as digital forensics analysis, system security analysis, and knowledge retrieval, the system performs joint semantic understanding on the alarm context to identify the alarm intent and risk type; security entities are extracted from the alarm context, including one or more of suspicious processes, sensitive files, abnormal IP addresses, target hosts, and related accounts; and investigation targets are generated based on the alarm intent and the security entities.

[0049] This invention introduces a large language model as the core of reasoning and combines it with a multi-role prompting mechanism to perform deep semantic understanding and security entity extraction of alarm context. It can accurately identify alarm intent and risk type, and automatically generate structured investigation targets, significantly improving the intelligence level of alarm parsing and the accuracy of investigation direction, providing a reliable foundation for subsequent progressive tracking and evidence chain closure.

[0050] Specifically, in step S3, an initial retrieval plan is generated, including: Obtain the associated knowledge fragments corresponding to the security entity; Determine the search direction based on the alarm intent; The type of the target entity to be retrieved is determined based on the security entity; Determine the query constraints and priorities corresponding to the target entity type based on the associated knowledge fragments; An initial search plan is generated based on the search direction, the target entity type, the query constraints, and the priority.

[0051] In this embodiment, the auditing agent uses a large language model as its reasoning core and loads role prompts such as digital forensics analysis, system security analysis, and knowledge retrieval. It performs joint semantic understanding on alarm titles, alarm descriptions, risk tags, context summaries output by the situational awareness platform, and asset profiles to obtain associated knowledge fragments corresponding to the security entity. This includes using a retrieval enhancement generation mechanism to fuse vector retrieval and keyword retrieval of alarm judgment knowledge accumulated from threat intelligence reports, vulnerability announcements, attack sample analysis, historical event recap documents, contingency plan knowledge bases, and the situational awareness platform. Vector retrieval is used to capture the semantic similarity between the current alarm and historical attack descriptions, while keyword retrieval is used to accurately hit IOC, CVE number, attack tool name, file path fragment, command fragment, and C2 address. Let the query vector be qv, the knowledge fragment vector be kv, and the semantic relevance be denoted as... The system is set to... The comprehensive score is used to rank and output candidate knowledge fragments, where α and β are empirical weights.

[0052] The audit agent determines the search direction based on the alert intent and identifies the target entity type to be searched based on the security entities extracted from the current alert (including suspicious processes, sensitive files, abnormal IPs, target hosts, and related accounts). The audit agent determines the query constraints and priorities corresponding to the target entity type based on the associated knowledge fragments. To ensure the investigation results are executable, the audit agent outputs an initial search plan:

[0053] Where entity represents the entity to be retrieved, type represents the entity type, template represents the query template, window represents the time window, priority represents the priority, and expectation represents the expected output content.

[0054] Specifically, determining the query constraints and priorities corresponding to the target entity type based on the associated knowledge fragments includes: Extract query constraints from the associated knowledge fragments; Prioritize each target entity type based on the threat level of the associated knowledge fragments; Associate the query constraints and priorities with the corresponding target entity types.

[0055] In this embodiment, the auditing agent parses the acquired related knowledge fragments and extracts query constraints related to each target entity type from the related knowledge fragments. The query constraints include one or more of the following: retrieval time range, retrieval field, keyword matching rules, and logical combination conditions. Specifically, if the related knowledge fragment contains intelligence indicating that an IP address is marked as a malicious C2 server, the query constraints for that IP entity type include: limiting the time window to the active time period of the intelligence report, the retrieval field to the target IP field in the network connection log, and the keyword matching rule to exactly match the IP address. The auditing agent determines the priority of each target entity type based on the threat level indicated in the related knowledge fragment. Entity types with higher threat levels, earlier attack stages, or closer association with the alert intent are assigned higher priority. For example, if the related knowledge fragment indicates that a process is a derivative process of known ransomware, then the priority of that process entity is higher than that of file entities in the related knowledge fragment that do not explicitly state a threat level. The auditing agent associates and stores the extracted query constraints and determined priorities with the corresponding target entity types, generating a mapping relationship in the form of {entity type: query constraint, priority}, which serves as the basis for generating the initial retrieval plan.

[0056] This invention achieves deep integration of audit intelligence and large language model, combined with retrieval enhancement generation mechanism to obtain related knowledge fragments, and adaptively generates a structured initial retrieval plan based on alarm intent, security entity, and related knowledge fragments, including entity type, query template, time window, and priority. At the same time, it automatically extracts query constraints from related knowledge fragments and dynamically allocates priorities according to threat level, which makes the initial retrieval plan more targeted and effective, avoids invalid queries, and significantly improves the intelligence level, retrieval efficiency, and accuracy of alarm investigation.

[0057] Specifically, a historical successful audit case library is constructed. Each case includes: alarm feature vector, initial retrieval plan, actual execution steps, final evidence set, and handling conclusion. When generating the initial retrieval plan for the current alarm, the system calculates the similarity between the current alarm context (alarm intent + security entity) and historical cases. If a successful case with high similarity (>90%) exists, its key elements in the retrieval plan (such as query template combination, time window setting, and entity tracking order) are directly transferred and used to replace or merge the currently generated initial plan.

[0058] In this embodiment, the current alert is "ransomware variant attack". The system found three successful cases with a similarity of over 92% in the historical case database. These cases all used a search plan of "first check the process creation chain → then check the file encryption API calls → finally check the external C2 domains", and the results were good. The system automatically and dynamically adjusts the currently initially generated general search plan to this verified and efficient plan.

[0059] By drawing on past successful experiences, this invention makes the initial search plan more targeted and more in line with the actual and effective investigation path, avoids invalid or inefficient search attempts, significantly accelerates the convergence speed from alarms to preliminary evidence, and realizes the continuous learning and evolution of investigation strategies.

[0060] Specifically, in step S4, an initial set of evidence is obtained, including: The targeted query results are deduplicated to obtain the deduplicated query results; The deduplicated query results are sorted by timestamp to obtain a sorted evidence sequence; The sorted evidence sequence is subjected to anomaly scoring and filtering to remove regular events below a preset anomaly threshold, thereby obtaining filtered valid evidence. The filtered valid evidence is correlated to establish causal relationships between the evidence, resulting in a correlated evidence set. The associated evidence set is constructed into a directed acyclic graph (DAG), where nodes represent evidence events and edges represent causal relationships. The evidence chain is verified using pre-defined temporal logic rules. The temporal reasoning engine is invoked to check whether the timestamp sequence in the evidence graph violates these logic rules. If a violation is found, the evidence chain is automatically marked as "weakly closed" or "broken," and the evidence that violates the logic is removed or its weight is reduced. In this embodiment, the initial evidence set includes: Evidence E1 (process A accesses file B at 10:00:05) and Evidence E2 (process A starts at 10:00:02). The logical rule requires that "process start" should precede "file access." The temporal reasoning engine verifies this. Another chain: Evidence E3 (process A connects to IPC at 10:00:10) and Evidence E4 (process A writes a ransom note at 10:00:12). The rule requires that "writing the ransom note" should occur after "connecting to C2," but E4 occurs earlier than E3, violating the logic. The system marks the E4-E3 chain as suspicious and reduces its weight. The associated evidence sets are aggregated to form an initial evidence set.

[0061] Specifically, the filtered valid evidence includes: Map each piece of evidence in the sorted evidence sequence to a feature vector; The feature vectors are encoded and decoded to obtain the reconstruction error of each piece of evidence; Evidence with a reconstruction error greater than a preset anomaly threshold is retained as valid evidence, while evidence with a reconstruction error less than or equal to the preset anomaly threshold is discarded.

[0062] In this embodiment, the system log database retrieval module performs type-based targeted queries on process, file, IP, account, and API call records based on the initial retrieval plan generated by the audit agent. It uses entity-type-oriented query templates to avoid irrelevant result inflation and obtain targeted query results. The targeted query results are then deduplicated, removing duplicate log records to obtain deduplicated query results. The deduplicated query results are sorted by timestamp to obtain a sorted evidence sequence. Anomaly scoring filtering is then applied to the sorted evidence sequence. Specifically, each piece of evidence in the sorted evidence sequence is mapped to a feature vector, which includes one or more of the following: event type, entity type, event frequency, time interval, number of upstream and downstream associations, risk label, and context similarity. The feature vector is input into an autoencoder for encoding and decoding, and the reconstruction error of each piece of evidence is calculated. Evidence with a reconstruction error greater than a preset anomaly threshold is retained as valid evidence, while evidence with a reconstruction error less than or equal to the preset anomaly threshold is discarded, thus obtaining filtered valid evidence. This filtering mechanism can filter out high-frequency normal background events, retaining only high-risk, low-frequency, or suspicious behavior events. The filtered valid evidence is correlated to establish causal relationships between the evidence, resulting in a correlated evidence set. This correlated evidence set is then aggregated to form an initial evidence set.

[0063] Specifically, in step S4, determining whether the initial evidence set meets the preset evidence sufficiency conditions includes: Determine the required types of key evidence and the minimum amount of evidence required for each type based on the stated investigation objectives; Traverse the evidence in the initial evidence set, identify the key evidence types contained therein, and determine the number of evidence corresponding to each type; If the identified key evidence types cover all required types, and the number of evidence corresponding to each type is greater than or equal to the corresponding preset minimum number, then the initial evidence set is determined to meet the preset evidence sufficiency conditions. If the identified key evidence types do not cover all required types, or if the number of evidence corresponding to any type is less than the corresponding preset minimum number, then the initial evidence set is determined to not meet the preset evidence sufficiency conditions.

[0064] In this embodiment, the system determines the required key evidence types and the minimum number of pieces of evidence required for each type based on the investigation objectives. The preset minimum number of pieces of evidence can be determined based on the statistical results of historical alarm cases. For example, based on statistical analysis of 1000 confirmed security incidents, a general threshold is set: at least 1 piece of process evidence, at least 2 pieces of file evidence, at least 1 piece of network connection evidence, and at least 1 piece of API call evidence. For specific types of alarms, the threshold can be dynamically adjusted; for example, the minimum number of file evidence pieces is increased to 3 for ransomware alarms. The system traverses the evidence in the initial evidence set, identifies the key evidence types contained therein, and counts the number of pieces of evidence corresponding to each type. For example, the initial evidence set may identify 2 pieces of suspicious process evidence, 4 pieces of file encryption operation evidence, and 0 pieces of abnormal network connection evidence.

[0065] The system determines whether the identified key evidence types cover all required types, and whether the number of evidence for each type is greater than or equal to the corresponding preset minimum number. If the determination result is yes, the initial evidence set is deemed to meet the preset evidence sufficiency conditions; if the determination result is no, i.e., there are missing key evidence types or the number of evidence for any type does not meet the minimum requirement, the initial evidence set is deemed not to meet the preset evidence sufficiency conditions. Taking the above example, since the number of abnormal network connection evidence is 0, which does not meet the minimum requirement of 1, the system determines that the initial evidence set does not meet the preset evidence sufficiency conditions and triggers the follow-up agent to conduct a progressive supplementary investigation.

[0066] This invention effectively avoids the inflation of irrelevant results and filters high-frequency normal background events by using entity-type-oriented targeted queries and anomaly scoring filtering based on autoencoder reconstruction errors. It retains only high-risk, low-frequency, or suspicious behavior events, forming a high-quality, compact initial evidence set. At the same time, by setting key evidence types and quantity thresholds based on historical statistical results and automatically traversing and matching the initial evidence set, it can objectively and quantitatively assess the sufficiency of evidence, providing a clear basis for determining whether to trigger a progressive investigation. This avoids misjudgments or omissions due to insufficient evidence and significantly improves the intelligence and reliability of alarm auditing.

[0067] Specifically, in step S5, a supplementary investigation step is generated, including: The initial evidence set is compared with the key evidence required for the investigation objective to identify the missing key evidence items; Based on the missing key evidence items, determine the types of entities that need to be tracked and the corresponding entities to be tracked; The investigation order is determined based on the logical relationships between the entities to be tracked, and a corresponding query template is configured for each entity to be tracked. Configure the cycle step budget and stop conditions, and combine the entity to be tracked, the survey order, the query template, the cycle step budget, and the stop conditions to generate supplementary survey steps.

[0068] In this embodiment, when the initial evidence set does not meet the preset sufficiency conditions, the follow-up agent is triggered to execute a supplementary investigation. First, the follow-up agent compares the initial evidence set with the key evidence required for the investigation target to determine the missing key evidence items. For example, if the investigation target is "confirming whether ransomware attacks exist," the required key evidence types include evidence of suspicious processes, evidence of file encryption operations, and evidence of abnormal network connections. However, the initial evidence set only contains evidence of suspicious processes and evidence of file encryption operations, lacking evidence of abnormal network connections. Therefore, the missing key evidence item is determined to be "evidence of abnormal network connections." Second, based on the missing key evidence item, the follow-up agent determines the type of entity to be tracked and the corresponding entity to be tracked. For example, if "evidence of abnormal network connections" is missing, the entity type to be tracked is determined to be a network address entity, and the corresponding entity to be tracked includes the external IP addresses connected to by the suspicious processes already appearing in the initial evidence set.

[0069] Then, the tracking agent determines the investigation order based on the logical relationships between the entities to be tracked. For example, it first tracks the external IP addresses of suspicious processes, then the associated domain names of those IP addresses, and finally the historical DNS records of those domain names. Simultaneously, a corresponding query template is configured for each entity to be tracked, such as a network connection log query template for IP addresses and a DNS resolution log query template for domain names. Finally, the tracking agent configures the loop step budget and stopping conditions. The loop step budget can be dynamically set according to the complexity of the missing evidence items, such as a preset maximum tracking depth of 3 layers. Stopping conditions include: all missing key evidence items have been supplemented, the risk conclusion has stabilized, the preset maximum loop step count has been reached, or a policy prohibiting expansion is detected (such as involving sensitive data or unauthorized operations). The tracking agent combines the above-mentioned entities to be tracked, investigation order, query templates, loop step budget, and stopping conditions to generate structured supplementary investigation steps to guide subsequent progressive tracking queries.

[0070] Specifically, the investigation order is determined based on the logical relationships between the entities to be tracked, including: Based on the missing key evidence items, determine the dependencies between the entities to be tracked; Entities without dependencies are identified as entities to be investigated in parallel, and entities with dependencies are investigated in the order of being depended on first and the dependencies being investigated second. The investigation order is associated with and stored with each entity to be tracked.

[0071] In this embodiment, the tracking agent analyzes the dependencies between the entities to be tracked based on the missing key evidence items. These dependencies include one or more of causal relationships, temporal relationships, and access relationships. For example, there may be an access dependency between a process entity and a file entity, a connection dependency between a process entity and a network address entity, and a startup dependency between an account entity and a process entity. The tracking agent identifies entities without dependencies as parallel investigation entities. For instance, if the missing key evidence item involves two independent process entities with no access or calling relationship between them, these two entities can be identified as parallel investigation entities, and targeted searches can be performed simultaneously in subsequent queries to improve investigation efficiency.

[0072] The tracking agent determines the investigation order of entities with dependencies based on the order in which the dependent entity comes first and the dependent entity comes last. For example, if the investigation goal is to track the external connections of a suspicious process, the process entity is the dependent entity, and the network address entity is the dependent entity. The investigation order is to first track the process entity to obtain its process ID and behavioral characteristics, and then track the external network address entity it connects to based on the process ID. As another example, in an API call chain tracing scenario, if interface A calls interface B, and interface B calls interface C, the dependency relationship is A→B→C, and the investigation order is A, B, C in that order. The tracking agent associates the determined investigation order with each entity to be tracked, generating a mapping relationship in the form of {entity: investigation sequence number, dependency identifier}, as part of the supplementary investigation steps to guide the execution order of subsequent progressive tracing queries.

[0073] Specifically, in step S5, an expanded set of evidence is obtained, including: Select the entity to be tracked according to the investigation order in the supplementary investigation steps; Execute a targeted query based on the query template corresponding to the currently tracked entity to obtain the query results for this round; The results of this round of queries are correlated with the existing evidence set, and the evidence set is updated. Determine whether the updated evidence set meets the stopping condition in the supplementary investigation step. If it does, terminate the tracking and output the updated evidence set as an extended evidence set. If it does not meet the condition, determine the next entity to be tracked based on the updated evidence set and return to the step of executing the targeted query until the stopping condition is met.

[0074] In this embodiment, the follow-up agent selects the current entity to be tracked according to the investigation order in the supplementary investigation steps. For example, in the scenario of tracking the external connection behavior of a suspicious process, the investigation order is: first track the suspicious process entity, then track the network address entity it connects to, and finally track the domain name entity associated with the network address. Therefore, the suspicious process entity is selected first as the current entity to be tracked. The follow-up agent performs a targeted query based on the query template corresponding to the current entity to be tracked, obtaining the query results for this round. For example, for the suspicious process entity, the process behavior query template is used to retrieve the process's startup time, executed commands, parent process information, and accessed file list from the system log database, obtaining the query results for this round.

[0075] The agent then correlates the results of the current query with the existing evidence set, updating the evidence set accordingly. For example, it correlates newly queried process execution commands and access file lists with evidence in the initial evidence set, establishing a causal relationship edge of "process A → file B," forming an updated evidence set. The agent then determines whether the updated evidence set meets the stopping conditions in the supplementary investigation step. These stopping conditions include: all missing key evidence items have been supplemented, the risk conclusion has stabilized, the preset maximum number of loop steps has been reached, or a policy prohibiting expansion has been detected. If any stopping condition is met, the tracking terminates, and the updated evidence set is output as the expanded evidence set. If the stopping conditions are not met, the agent determines the next entity to be tracked based on the updated evidence set. For example, if a suspicious process entity is tracked in the current round and abnormal external connection behavior is found, but its connected IP address has not yet been tracked, then the next entity to be tracked is determined to be that IP address. The agent then returns to the step of executing the targeted query and continues tracking until the stopping conditions are met. Finally, the tracking agent integrates all the evidence obtained from multiple rounds of tracking to form an extended evidence set, which is used for generating subsequent handling suggestions and security verification.

[0076] This invention automatically identifies missing evidence items, analyzes entity dependencies, and determines the investigation order by following the intelligent agent. It configures an investigation strategy that combines parallel and progressive approaches, while setting a cycle step budget and multi-dimensional stopping conditions. This enables the generation of targeted, structured supplementary investigation steps and automatically executes multiple rounds of progressive tracking queries according to the investigation order. After each round of queries, the evidence set is dynamically updated and stopping conditions are determined to ensure timely termination when the evidence is sufficient or a preset boundary is reached. This effectively fills gaps in the evidence chain, avoids infinite loops, and significantly improves the automation, efficiency, and controllability of progressive investigations.

[0077] Specifically, when the supplementary investigation step identifies multiple independent entities to be tracked (parallel investigation entities), the system does not process them serially by a single follow-up agent. Instead, it instantiates multiple independent follow-up agent sub-agents, each responsible for investigating one entity or one sub-chain. Each sub-agent executes targeted queries and evidence expansion in parallel. After the investigation is completed, an arbitration agent is activated to collect the sub-evidence sets returned by all sub-agents. The arbitration agent compares the sub-evidence sets for conflicts (e.g., two sub-agents reach contradictory conclusions about the same IP address's origin or give opposing judgments about the same process behavior) and makes a ruling based on preset conflict resolution rules (e.g., "high-confidence data source priority," "majority priority," "latest timestamp priority"), forming a consistent and conflict-free expanded evidence set.

[0078] In this embodiment, the initial investigation identified two independent suspicious processes, P1 and P2. The system initiated sub-agent A1 to track P1, and sub-agent A2 to track P2. A1 discovered that P1 was connected to IP 1.2.3.4, and determined it to be malicious (C2); A2 discovered from another low-confidence source that the same IP 1.2.3.4 was marked as a CDN node, and determined it to be non-malicious. The arbitration agent intervened, and according to the rule of "high-confidence data source priority", adopted A1's conclusion and marked A2's conclusion as a false alarm, outputting the final extended evidence set.

[0079] This invention significantly improves the investigation speed of complex alarms through multi-agent parallel investigation. Simultaneously, the introduction of an arbitration mechanism ensures that evidence from different investigation paths can be objectively and consistently integrated, avoiding inconsistencies in conclusions caused by conflicting evidence, and significantly enhancing the parallel processing capability and consistency of conclusions of the audit system.

[0080] Specifically, in step S6, generating an alarm conclusion based on the extended evidence set includes: The security agent extracts attack features and affected entities based on the extended evidence set. Specifically, the system extracts evidence items with malicious labels or abnormal scores exceeding a threshold from the extended evidence set as attack features (such as malicious process hashes, C2 communication domain names, and abnormal privilege escalation commands), and identifies objects that have been accessed, modified, or destroyed as affected entities (such as encrypted core database files and stolen sensitive directories).

[0081] The security agent matches the attack signatures with a preset threat knowledge base to determine the attack type. The preset threat knowledge base includes the MITRE ATT&CK framework, a CVE vulnerability database, and a local threat intelligence database. For example, if the extracted attack signatures include the command "vssadmin delete shadows" and batch renaming behavior with a specific suffix, the system matches it with the threat knowledge base to determine the attack type as "ransomware."

[0082] The security agent assesses the scope of the event's impact based on the affected entities and the attack type. Specifically, the system combines the asset topology relationships in the CMDB (Configuration Management Database) to assess the business importance and potential spread of the affected entities. For example, if the affected entity is a core transaction database, its impact is assessed as "global business disruption risk."

[0083] Finally, based on the attack type and the scope of the event's impact, the security agent uses a large language model to generate structured alert conclusions. These alert conclusions include event characterization, attacker profile inference, a list of compromised assets, and a confidence score.

[0084] Specifically, in step S6, generating a disposal recommendation based on the expanded evidence set includes: Reconstruct the chain of anomalous behavior based on the extended evidence set to identify the attack phase; Assess the risk level based on the expanded evidence set and the attack phases; The expanded set of evidence is matched with a preset strategy to determine the appropriate action. Based on the stated action, the stated risk level, and the stated attack phase, a response recommendation is generated.

[0085] In this embodiment, the security agent reconstructs anomaly behavior chains based on the extended evidence set to identify attack phases. Specifically, the security agent analyzes the causal relationships between the evidence in the extended evidence set and reconstructs a complete attack behavior chain according to chronological order and dependencies. For example, starting from the initial suspicious process initiation, it tracks a series of behaviors such as accessing sensitive files, establishing abnormal network connections, and performing encryption operations, forming a complete attack chain. Based on the reconstructed attack chain, the attack phase of the current alert is identified, including one or more of initial intrusion, privilege escalation, lateral movement, data theft, or ransomware. The security agent assesses the risk level based on the extended evidence set and the attack phase. Specifically, the security agent calculates a comprehensive risk level by combining the evidence sufficiency score, the behavior chain integrity score, and the severity of the attack phase. For example, if the attack chain completely covers multiple phases from initial intrusion to data theft, and the extended evidence set contains conclusive evidence of malicious behavior, it is rated as a high-risk level; if it is only in the initial intrusion phase and the evidence chain is incomplete, it is rated as a medium-risk or low-risk level.

[0086] The security agent matches the extended evidence set with preset policies to determine the appropriate action. The preset policies include one or more of isolation, blocking, monitoring, and alerting policies. Specifically, the security agent matches key evidence (such as malicious process names, malicious IP addresses, and abnormal API calls) in the extended evidence set with a preset security policy library. For example, if the extended evidence set contains ransomware-featured processes, an isolation policy is matched to determine the action of isolating the host containing that process; if it contains a malicious C2 server IP address, a blocking policy is matched to determine the action of blocking network connections to that IP address. The security agent generates a handling recommendation based on the handling action, the risk level, and the attack stage. The handling recommendation includes specific handling actions, the target of the action, the timing of the action, and the expected effect. For example, the following handling recommendation might be generated: "Given that the current alert is in the ransomware attack stage with a high risk level, it is recommended to immediately isolate host 10.0.0.1 and block its connection to external IP 1.2.3.4." Specifically, in step S6, the verification result is obtained, including: The verifiability of the alarm conclusion is verified to obtain the first sub-verification result; The consistency of the alarm conclusion and the extended evidence set is verified to obtain the second sub-verification result; The proposed handling measures are validated using security policies to obtain a third sub-validation result. Specifically, the security policy verification is not limited to a simple "whether to allow execution" approach. Instead, it breaks down the proposed action (such as "isolate host 10.0.0.1") into multiple atomic actions: {action:"isolate",target:"host10.0.0.1",duration:"30min",impact:["Business A","Business B"]}. The system connects to the CMDB and IAM system to evaluate the execution permissions and potential impact of this atomic action in real time. If the impact exceeds the preset risk tolerance, even if the policy verification passes, a secondary verification result of "recommend not to execute" or "requires manual approval" will be generated. In this embodiment, the recommended action is to "isolate host 10.0.0.1". After system disassembly, a CMDB query revealed that this host carries "database core services", with an impact score as high as 9.5 / 10, exceeding the preset threshold of 7.0. Simultaneously, IAM verification found that the current security operations role lacked the authority to isolate the database host. The final third sub-verification result was "failed - high-risk impact and lack of authority", and a more refined action of "blocking the host's connection to a specific external IP address" was recommended. This invention avoids the risks associated with automated processing through pre-assessment, ensuring that the processing recommendations meet security requirements while remaining compatible with actual operational permissions and business continuity constraints, thus significantly improving the practicality and security of automated processing. The verification result is determined based on the first sub-verification result, the second sub-verification result, and the third sub-verification result.

[0087] In this embodiment, the security agent performs evidence verifiability verification on the alarm conclusion to obtain a first sub-verification result. Specifically, the security agent checks whether each key assertion in the alarm conclusion can be mapped to a specific evidence item in the extended evidence set. The evidence item includes one or more of log records, event numbers, node numbers, or edge numbers. For example, if the alarm conclusion includes "process A started ransomware," then the corresponding process startup log or process creation event record needs to be found in the extended evidence set. If all key assertions are supported by corresponding evidence, the first sub-verification result is passed; if there are assertions that cannot be mapped, the first sub-verification result is failed, and the assertion item with missing evidence is marked.

[0088] The security agent performs a consistency check on the alarm conclusion and the extended evidence set, obtaining a second sub-check result. Specifically, the security agent checks whether there is a logical contradiction between the assertion in the alarm conclusion and the extended evidence set. For example, if the alarm conclusion determines that it is a "ransomware attack," but the extended evidence set only contains abnormal login records and lacks key evidence such as file encryption or the generation of ransom notes, then a logical contradiction is determined. Simultaneously, it checks whether the handling recommendations are consistent with the alarm conclusion. For example, if the alarm conclusion is low risk but the handling recommendation is to isolate the host, then an inconsistency is determined. If there is no contradiction and the handling recommendation is consistent with the conclusion, the second sub-check result is passed; otherwise, it is failed, and the contradictory item is marked.

[0089] The security agent performs security policy verification on the proposed actions, obtaining a third sub-verification result. Specifically, the security agent compares the proposed actions with preset security policies and access control rules to determine whether the actions comply with policy requirements and are within the authorized scope. For example, if the proposed action is to "isolate the host," but the host is a core business server and the preset policy prohibits isolation operations on it, then it is determined to be non-compliant with the security policy. If all actions comply with the security policy and access control rules, the third sub-verification result is passed; otherwise, it is failed, and a violation is marked. The security agent determines the final verification result based on the first, second, and third sub-verification results. If all three sub-verification results are passed, the verification result is determined to be passed; if any sub-verification result is failed, the verification result is determined to be failed, and the specific information of the verification failure is encapsulated as the basis for triggering a rollback investigation. When the verification result is failed, the system marks the current conclusion as pending supplementation and triggers a rollback investigation, feeding back the verification failure information to the follow-up agent to further supplement the evidence chain and improve the audit conclusion.

[0090] This invention reconstructs abnormal behavior chains through a security intelligent agent to identify attack phases, comprehensively assess risk levels, and match preset strategies to determine appropriate actions, generating structured and evidence-based handling recommendations. Simultaneously, it employs a triple verification mechanism for alarm conclusions: evidence verifiability verification, consistency verification, and security policy verification. This effectively identifies issues such as missing evidence, logical contradictions, and policy violations. When verification fails, a rollback investigation is automatically triggered, feeding back the verification failure information to the follow-up intelligent agent to further complete the evidence chain, forming a complete closed-loop audit process. This significantly improves the reliability, credibility, and intelligence level of automated alarm auditing, making it suitable for application scenarios such as situational awareness platforms, host security analysis platforms, and intelligent security operations.

[0091] Specifically, in step S7, an audit processing result is generated, including: In response to the verification result being passed, an audit conclusion and an explanation of the abnormal behavior are generated based on the alarm conclusion, an evidence chain is generated based on the extended evidence set, and a corresponding action is generated based on the handling suggestion. The audit conclusions, explanations of abnormal behavior, chains of evidence, and handling recommendations are structured and assembled to generate audit handling results.

[0092] Specifically, determining whether the verification result is passed includes: If the first sub-verification result, the second sub-verification result, and the third sub-verification result are all passed, then the verification result is passed.

[0093] In this embodiment, the security agent first determines whether the verification result is passed. Specifically, if the first sub-verification result (evidence verifiability verification), the second sub-verification result (consistency verification), and the third sub-verification result (security policy verification) are all passed, the verification result is determined to be passed; if any sub-verification result is failed, the verification result is determined to be failed. When the verification result is passed, the security agent generates an audit conclusion and an explanation of abnormal behavior based on the alarm conclusion. The audit conclusion includes the alarm type, attack determination result, and confidence assessment. The explanation of abnormal behavior includes a natural language description of the attack behavior, such as "The process svchost.exe (PID 1234) was detected to have launched a suspicious PowerShell command. This process subsequently accessed a file encryption API commonly used by ransomware and attempted to connect to the known C2 server IP 1.2.3.4."

[0094] The security agent generates an evidence chain based on the extended evidence set. Specifically, the security agent links key evidence from the extended evidence set in chronological order and according to causal relationships to generate a traceable evidence chain. The evidence chain includes event number, entity name, operation type, timestamp, and evidence source, for example, "Event E1: Process A starts → Event E2: Process A accesses file B → Event E3: Process A connects to IPC → Event E4: Process A performs encryption operation". The security agent generates corresponding actions based on the proposed actions. These actions include one or more of the following: isolating the process, blocking network connections, blocking IP addresses, freezing accounts, or suspending API calls, specifying the target and timing of the action.

[0095] The security agent structurally assembles the audit conclusions, explanations of abnormal behavior, evidence chains, and handling suggestions to generate audit handling results. These results include one or more of the following: alarm number, risk level, evidence summary, description of abnormal behavior, credibility score, suggested action, and write-back timestamp. Finally, the system writes the audit handling results back to the situational awareness platform or work order system via the situational awareness platform adaptation module, forming a complete closed-loop audit process. When the verification result fails, the system marks the current conclusion as pending supplementation and feeds back the verification failure information (including missing evidence items, contradictory items, or violations) to the follow-up agent, triggering a new round of supplementary investigation to further complete the evidence chain and improve the audit conclusions.

[0096] This invention generates a complete audit handling result by structuring and assembling the verified conclusions, which includes audit conclusions, explanations of abnormal behavior, evidence chains, and handling suggestions. It also supports writing back to the situational awareness platform or work order system, realizing automated closed-loop handling of alarm audits. For cases where verification fails, a rollback investigation mechanism is automatically triggered to ensure the integrity of the evidence chain and the reliability of the conclusions.

[0097] Specifically, after the audit process is completed (regardless of whether the verification passed or failed), the system automatically packages the key information of the entire process: the original alarm, the generated initial / supplementary investigation plan, the intermediate evidence set, the final extended evidence set, the verification results (including failures), the audit conclusions, and the handling recommendations. This information is then transformed into a structured "audit case." This case is used to incrementally update the large language model prompts in step S2, the related knowledge fragment library in step S3 (updating the vector database through a retrieval-enhanced generation mechanism), and the historical successful case library in step S5. For failed cases, the reasons for failure are marked (insufficient evidence / logical contradiction / strategy violation) to proactively avoid similar failure patterns in the future.

[0098] In this embodiment, an audit was deemed insufficient due to "missing evidence of abnormal network connections," and a supplementary investigation was triggered, but no evidence was found. The final case was marked as "Incomplete Evidence Chain - Missing Network Evidence." This case was then fed back to the knowledge base. The system updated the associated knowledge fragment library, forcibly adding a "network connection log" query item to the initial search plan for subsequent similar "ransomware" alerts, and setting its priority to the highest. Simultaneously, the minimum quantity requirement for "network evidence" in the evidence sufficiency conditions was adjusted.

[0099] This invention, through a closed-loop feedback mechanism, enables the system's alarm parsing capabilities, retrieval plan generation capabilities, evidence sufficiency judgment criteria, and the rationality of handling suggestions to continuously optimize and improve itself, significantly enhancing its long-term value and inventiveness.

[0100] The above embodiments are merely illustrative examples and are not intended to limit the implementation. Those skilled in the art will recognize that other variations or modifications can be made based on the above description. It is neither necessary nor possible to exhaustively list all possible implementations. However, obvious variations or modifications derived therefrom are still within the scope of protection of this application.

Claims

1. A method for intelligent alarm auditing and processing based on a large language model, characterized in that, include: Step S1: Collect security-related data from different data sources, and perform standardization and correlation integration on the security-related data to form a unified event object; Step S2: Construct an alarm context based on the unified event object, parse the alarm context to obtain the alarm intent, security entity and investigation target; Step S3: Obtain the associated knowledge fragments corresponding to the security entity; generate an initial retrieval plan based on the alarm intent, the security entity, and the associated knowledge fragments; and execute a targeted query based on the initial retrieval plan to obtain the targeted query results. Step S4: Perform evidence screening and association processing on the targeted query results to obtain an initial evidence set, and determine whether the initial evidence set meets the preset evidence sufficiency conditions; Step S5: In response to the initial evidence set not meeting the preset evidence sufficiency conditions, a supplementary investigation step is generated based on the initial evidence set and the investigation objective, and the supplementary investigation step is progressively tracked to obtain an extended evidence set. In response to the initial evidence set meeting the preset evidence sufficiency conditions, the initial evidence set is used as the extended evidence set. Step S6: Generate handling suggestions and alarm conclusions based on the extended evidence set, and verify the alarm conclusions, the extended evidence set, and the handling suggestions to obtain the verification results; Step S7: Using the verification result, combined with the alarm conclusion, the extended evidence set, and the handling suggestions, an audit handling result is generated.

2. The method according to claim 1, characterized in that, In step S1, a unified event object is formed, including: The security-related data from different sources are processed by time unification, field standardization, and entity normalization to obtain the processing results; Based on the processing results, establish the relationship between cross-source data, and aggregate and generate a unified event object according to the relationship.

3. The method according to claim 1, characterized in that, In step S2, an alarm context is constructed based on the unified event object, including: Obtain alarm association metadata associated with the unified event object, and aggregate the alarm association metadata with the unified event object to form an alarm context.

4. The method according to claim 1, characterized in that, In step S2, the alarm context is parsed to obtain the alarm intent, security entity, and investigation target, including: The alarm context is semantically understood to identify the alarm intent, the security entities involved in the alarm context are extracted, and the investigation target is generated based on the alarm intent and the security entities.

5. The method according to claim 1, characterized in that, In step S3, an initial search plan is generated, including: Obtain the associated knowledge fragments corresponding to the security entity; Determine the search direction based on the alarm intent; The type of the target entity to be retrieved is determined based on the security entity; Determine the query constraints and priorities corresponding to the target entity type based on the associated knowledge fragments; An initial search plan is generated based on the search direction, the target entity type, the query constraints, and the priority.

6. The method according to claim 5, characterized in that, Based on the associated knowledge fragments, the query constraints and priorities corresponding to the target entity type are determined, including: Extract query constraints from the associated knowledge fragments; Prioritize each target entity type based on the threat level of the associated knowledge fragments; Associate the query constraints and priorities with the corresponding target entity types.

7. The method according to claim 1, characterized in that, In step S4, an initial set of evidence is obtained, including: The targeted query results are deduplicated to obtain the deduplicated query results; The deduplicated query results are sorted by timestamp to obtain a sorted evidence sequence; The sorted evidence sequence is subjected to anomaly scoring and filtering to remove regular events below a preset anomaly threshold, thereby obtaining filtered valid evidence. The filtered valid evidence is correlated to establish causal relationships between the evidence, resulting in a correlated evidence set. The associated evidence sets are aggregated to form an initial evidence set.

8. The method according to claim 7, characterized in that, The filtered valid evidence includes: Map each piece of evidence in the sorted evidence sequence to a feature vector; The feature vectors are encoded and decoded to obtain the reconstruction error of each piece of evidence; Evidence with a reconstruction error greater than a preset anomaly threshold is retained as valid evidence, while evidence with a reconstruction error less than or equal to the preset anomaly threshold is discarded.

9. The method according to claim 1, characterized in that, In step S4, determining whether the initial evidence set meets the preset evidence sufficiency conditions includes: Determine the required types of key evidence and the minimum amount of evidence required for each type based on the stated investigation objectives; Traverse the evidence in the initial evidence set, identify the key evidence types contained therein, and determine the number of evidence corresponding to each type; If the identified key evidence types cover all required types, and the number of evidence corresponding to each type is greater than or equal to the corresponding preset minimum number, then the initial evidence set is determined to meet the preset evidence sufficiency conditions. If the identified key evidence types do not cover all required types, or if the number of evidence corresponding to any type is less than the corresponding preset minimum number, then the initial evidence set is determined to not meet the preset evidence sufficiency conditions.

10. The method according to claim 1, characterized in that, In step S5, a supplementary investigation step is generated, including: The initial evidence set is compared with the key evidence required for the investigation objective to identify the missing key evidence items; Based on the missing key evidence items, determine the types of entities that need to be tracked and the corresponding entities to be tracked; The investigation order is determined based on the logical relationships between the entities to be tracked, and a corresponding query template is configured for each entity to be tracked. Configure the cycle step budget and stop conditions, and combine the entity to be tracked, the survey order, the query template, the cycle step budget, and the stop conditions to generate supplementary survey steps.

11. The method according to claim 10, characterized in that, The investigation order is determined based on the logical relationships between the entities to be tracked, including: Based on the missing key evidence items, determine the dependencies between the entities to be tracked; Entities without dependencies are identified as entities to be investigated in parallel, and entities with dependencies are investigated in the order of being depended on first and the dependencies being investigated second. The investigation order is associated with and stored with each entity to be tracked.

12. The method according to claim 1, characterized in that, In step S5, an expanded set of evidence is obtained, including: Select the entity to be tracked according to the investigation order in the supplementary investigation steps; Execute a targeted query based on the query template corresponding to the currently tracked entity to obtain the query results for this round; The results of this round of queries are correlated with the existing evidence set, and the evidence set is updated. Determine whether the updated evidence set meets the stopping condition in the supplementary investigation step. If it does, terminate the tracking and output the updated evidence set as an extended evidence set. If it does not meet the condition, determine the next entity to be tracked based on the updated evidence set and return to the step of executing the targeted query until the stopping condition is met.

13. The method according to claim 1, characterized in that, In step S6, a disposal recommendation is generated based on the expanded evidence set. The disposal recommendation includes: Reconstruct the chain of anomalous behavior based on the extended evidence set to identify the attack phase; Assess the risk level based on the expanded evidence set and the attack phases; The expanded set of evidence is matched with a preset strategy to determine the appropriate action. Based on the stated action, the stated risk level, and the stated attack phase, a response recommendation is generated.

14. The method according to claim 1, characterized in that, In step S6, the verification result is obtained, including: The verifiability of the alarm conclusion is verified to obtain the first sub-verification result; The consistency of the alarm conclusion and the extended evidence set is verified to obtain the second sub-verification result; The proposed handling measures are validated using security policies to obtain a third sub-validation result. The verification result is determined based on the first sub-verification result, the second sub-verification result, and the third sub-verification result.

15. The method according to claim 14, characterized in that, In step S7, the audit handling result is generated, including: In response to the verification result being passed, an audit conclusion and an explanation of the abnormal behavior are generated based on the alarm conclusion, an evidence chain is generated based on the extended evidence set, and a corresponding action is generated based on the handling suggestion. The audit conclusions, explanations of abnormal behavior, chains of evidence, and handling recommendations are structured and assembled to generate audit handling results.

16. The method according to claim 15, characterized in that, Determining whether the verification result is passed includes: If the first sub-verification result, the second sub-verification result, and the third sub-verification result are all passed, then the verification result is passed.

Images