A network security operation method, device, equipment and storage medium

Abstract

The present disclosure relates to the technical field of computer, and particularly relates to a network security operation method and device, equipment and storage medium, to provide a network security operation scheme which can balance efficiency and accuracy and adapt to the current dynamic evolving network threat environment. The method comprises the following steps: obtaining running data to be processed, wherein the running data is obtained by preprocessing network flow data and log data; processing the running data by using a lightweight model to generate initial alarm data; based on the initial alarm data, performing alarm authenticity discrimination and threat level determination by using a heavy model to output confirmed threat event information; the threat event information indicates alarm data and threat level corresponding to the threat event confirmed by the heavy model; based on the threat event information, performing risk disposal, obtaining affected asset information and matching a trace evidence tool to generate a standardized evidence report; and based on the standardized evidence report, performing vulnerability repair.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a network security operation method, apparatus, device and storage medium. Background Technology

[0002] With the advancement of digitalization, the cybersecurity environment is becoming increasingly complex, and attack methods are becoming more diversified and dynamic. The generation cycle of new attack variants has been shortened to the hour level, which places extremely high demands on the real-time, accuracy and automation of security operations.

[0003] Traditional security operation models rely heavily on manual intervention. While some existing cybersecurity operation solutions in the industry have adopted model-based threat detection systems, they struggle to balance efficiency and accuracy, resulting in a large number of alerts and a high false alarm rate.

[0004] Therefore, existing cybersecurity operation solutions are unable to adapt to the current dynamically evolving cyber threat environment, and there is an urgent need for a cybersecurity operation solution that can systematically solve the above problems. Summary of the Invention

[0005] In view of this, the present disclosure provides a network security operation method, apparatus, device and storage medium to provide a network security operation solution that can balance efficiency and accuracy.

[0006] In a first aspect, a network security operation method is provided, comprising: acquiring operational data to be processed, wherein the operational data is obtained by preprocessing network traffic data and log data; processing the operational data using a lightweight model to generate initial alarm data; based on the initial alarm data, performing alarm authenticity verification and threat level determination using a heavyweight model, and outputting confirmed threat event information; the threat event information indicating the alarm data and threat level corresponding to the threat event confirmed by the heavyweight model; performing risk disposal based on the threat event information, and acquiring information on affected assets and matching source tracing and evidence collection tools to generate a standardized evidence collection report; and performing vulnerability remediation based on the standardized evidence collection report.

[0007] In one implementation, acquiring the runtime data to be processed includes: collecting Transmission Control Protocol (TCP) traffic, User Datagram Protocol (UDP) traffic, and Hypertext Transfer Protocol (HTTP) session data through a full-traffic probe to generate network layer raw data; and collecting system logs, application logs, and device alarm logs through a log collection probe to generate host layer raw data; and performing data format standardization and field mapping based on the network layer raw data and the host layer raw data to obtain preprocessed runtime data.

[0008] In one implementation, the runtime data is processed using a lightweight model to generate initial alarm data, including: extracting threat features based on the runtime data and performing incremental learning to generate threat classification results and variant identification results; filtering false alarms and removing duplicate alarms based on the threat classification results and variant identification results to generate alarm data with preliminary noise reduction; and performing multi-source log correlation analysis based on the alarm data with preliminary noise reduction to obtain the initial alarm data.

[0009] In one implementation, based on the operational data, threat features are extracted and incremental learning is performed to generate threat classification results and variant identification results, including: extracting attack payload features, traffic statistics features, and temporal behavior features based on the operational data to generate a high-dimensional feature vector; inputting the high-dimensional feature vector into a pre-trained lightweight model to determine known threat classification results and samples to be confirmed; obtaining the variant identification results corresponding to the samples to be confirmed, and updating the lightweight model parameters through incremental learning based on the variant identification results corresponding to the samples to be confirmed.

[0010] In one implementation, based on the alarm data after preliminary noise reduction, multi-source log correlation analysis is performed to obtain the initial alarm data, including: extracting the source IP address, destination IP address, and time window information involved in the alarm based on the alarm data after preliminary noise reduction, and generating correlation query conditions; retrieving relevant log records from network layer raw data and host layer raw data based on the correlation query conditions, and generating a correlation log set; and analyzing the behavior sequence before and after the alarm based on the correlation log set and removing isolated alarms to obtain the initial alarm data.

[0011] In one implementation, a heavyweight model is used to verify the authenticity of alarms and determine their threat levels, outputting confirmed threat event information. This includes performing the following processes through the heavyweight model: generating alarm semantic features based on the alarm data by analyzing alarm context information; determining the attack chain integrity, asset importance, and historical attack pattern matching degree based on the alarm semantic features and stored historical attack patterns, generating an alarm authenticity assessment result; and removing redundant information and determining the threat level based on the alarm authenticity assessment result, outputting the threat event information.

[0012] In one implementation, when the heavy model performs alarm authenticity verification and threat level determination, it adopts a successive analysis and progressive call mechanism, including: based on the alarm data, performing an initial heavy model call and outputting a list of information to be supplemented; based on the list of information to be supplemented, supplementing corresponding information from the asset database, threat intelligence database, and historical event database and performing a second heavy model call to generate preliminary judgment results and suspicious information; based on the suspicious information, iteratively performing information supplementation and heavy model calls until the iteration termination condition is met, and then outputting the threat event information.

[0013] In one implementation, acquiring information about affected assets and matching source tracing and forensic tools to generate a standardized forensic report includes: acquiring the IP address, operating system, deployment location, and business line information of the affected assets based on the threat event information; matching memory forensic tools and / or file integrity monitoring tools to the affected assets based on the IP address, operating system, deployment location, and business line information of the affected assets, as well as the threat characteristics corresponding to the alarm data in the threat event information, and distributing them to the affected assets to generate forensic data; and using the forensic data to perform clue association and attack path reconstruction through a heavy-duty model to generate the standardized forensic report.

[0014] In one implementation, the risk mitigation includes: based on the threat event information, invoking response tools to perform firewall policy adjustments, endpoint isolation, or malicious file scanning, and generating mitigation execution results; the vulnerability remediation includes: for the vulnerability information in the standardized forensics report, extracting the common vulnerability disclosure CVE number and remediation recommendations, generating a vulnerability remediation task based on the CVE number and remediation recommendations, and issuing the vulnerability remediation task to perform vulnerability remediation operations.

[0015] In one embodiment, the method further includes: generating a verification feasibility prototype (POC) code based on the remediation plan completed by the vulnerability remediation task through a heavy model; simulating an attack scenario by calling a penetration testing tool based on the POC code and generating test execution results; determining the remediation effect based on the test execution results, and returning to re-execute the vulnerability remediation operation when the remediation effect indicates that there is a residual risk.

[0016] Secondly, a network security operation device is provided, comprising:

[0017] The data acquisition module is used to acquire the operational data to be processed, which is obtained by preprocessing network traffic data and log data;

[0018] The lightweight model execution module is used to process the execution data using the lightweight model and generate initial alarm data.

[0019] The heavy model running module is used to identify the authenticity of alarms and determine the threat level based on the initial alarm data through the heavy model, and output confirmed threat event information; the threat event information indicates the alarm data and threat level corresponding to the threat event confirmed by the heavy model;

[0020] The report generation module is used to obtain information on affected assets based on the threat event information and match them with source tracing and evidence collection tools to generate a standardized evidence collection report.

[0021] The remediation module is used to perform vulnerability remediation based on the standardized forensic report.

[0022] Thirdly, an electronic device is provided, including a processor and a memory, the memory storing machine-readable instructions executable by the processor, the processor executing the machine-readable instructions stored in the memory, and when the machine-readable instructions are executed by the processor, the processor performing the steps of the network security operation method as described in any of the above embodiments.

[0023] Fourthly, a computer-readable storage medium is provided, including instructions stored thereon, wherein, when executed by a processor, the network security operation method as described in any of the above embodiments is executed.

[0024] The network security operation method provided in this disclosure first employs a lightweight model to process the pre-processed operational data, enabling rapid generation of initial alarms. This lightweight model's pre-processing filters out a large amount of invalid data and false alarms, pushing only valid initial alarm data to the heavyweight model. The heavyweight model then performs in-depth assessments of the alarm's authenticity and threat level, significantly improving the accuracy of threat identification and effectively balancing response efficiency and threat identification accuracy. Furthermore, risk mitigation is implemented immediately after confirming threat event information, promptly reducing the severity of the threat event. Moreover, this disclosure, through automated integration with asset information and precise matching of threat events and asset information with tracing tools, can quickly secure attack evidence and generate standardized forensic reports without manual intervention, greatly reducing evidence collection time, effectively preventing the destruction of attack traces, providing accurate evidence for subsequent vulnerability remediation, and significantly reducing reliance on security expert experience, thus improving the reliability and efficiency of tracing and evidence collection. Moreover, the embodiments disclosed herein trigger vulnerability patching immediately after source tracing and evidence collection, which can significantly shorten the overall response and patching cycle, reduce manual operation steps in security operations, improve the stability and controllability of security operation results, and effectively reduce the operational pressure caused by the diversification and dynamic nature of current network threats. Attached Figure Description

[0025] Figure 1This is a flowchart illustrating a network security operation method according to an exemplary embodiment of the present disclosure;

[0026] Figure 2 This is a schematic diagram of a system architecture shown in an exemplary embodiment of the present disclosure;

[0027] Figure 3 This is a schematic diagram of a network security operation device shown in an exemplary embodiment of the present disclosure;

[0028] Figure 4 This is a schematic diagram of an electronic device illustrated in an exemplary embodiment of the present disclosure. Detailed Implementation

[0029] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0030] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “the,” and “the” as used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0031] It should be understood that although the terms first, second, third, etc., may be used in this disclosure to describe various information, such information should not be limited to these terms. These terms are used only to distinguish information of the same type from one another. For example, without departing from the scope of this disclosure, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0032] Furthermore, the symbol “ / ” in this disclosure indicates that there is an “or” relationship between the related objects before and after the symbol, or that the related objects have an exemplary relationship that can coexist.

[0033] like Figure 1 The diagram shown is a flowchart of a network security operation method provided in an embodiment of this disclosure, including:

[0034] S101: Obtain the running data to be processed, which is obtained by preprocessing network traffic data and log data.

[0035] In practical implementation, full traffic probes and log collection probes can be deployed at key network nodes to collect network layer data and log data. The collected raw data can be standardized (e.g., unified format, redundancy removal) to form operational data to be processed.

[0036] In some embodiments, acquiring the runtime data to be processed may include: collecting Transmission Control Protocol (TCP) traffic, User Datagram Protocol (UDP) traffic, and Hypertext Transfer Protocol (HTTP) session data through a full-traffic probe to generate raw network layer data; and collecting system logs, application logs, and device alarm logs through a log collection probe to generate raw host layer data; and performing data format standardization processing and field mapping based on the raw network layer data and the raw host layer data to obtain preprocessed runtime data.

[0037] Here, the full-traffic probe collects network data such as TCP / UDP traffic and HTTP sessions, while the log collection probe collects host data such as system / application / device logs, achieving full data coverage of network and host scenarios. The aforementioned network and host data are then standardized in format (e.g., uniformly converted to JSON format) and their fields mapped (e.g., aligning core fields such as timestamps and IP addresses) to obtain structured runtime data.

[0038] Specifically, when collecting TCP traffic, UDP traffic, and HTTP session data using full-traffic probes, full-traffic probes can be deployed on network mirror ports to mirror traffic and generate mirrored traffic data. Based on the mirrored traffic data, deep packet inspection technology is used to parse protocol fields and extract source IP addresses, destination IP addresses, port numbers, timestamps, and payload data. Based on the source IP addresses, destination IP addresses, port numbers, timestamps, and payload data, traffic is reassembled according to the session dimension to generate raw network layer data. When collecting system logs, application logs, and security device alarm logs using log collection probes, log collection probes can be deployed on each business host to generate collection channels. Based on these collection channels, operating system logs, application runtime logs, firewall alarm logs, and intrusion detection system alarm logs are collected to generate multi-source heterogeneous log data. Based on this multi-source heterogeneous log data, timestamp alignment and source tag addition are performed to generate raw host layer data.

[0039] In addition, when performing data format standardization and field mapping, the original format of each data source can be identified based on the original data from the network layer and the original data from the host layer, and a format mapping table can be generated. Based on the format mapping table, logs of different formats are uniformly converted into JavaScript Object Notation (JSON) format to generate standardized format data. Based on the standardized format data, a unified field naming convention is established and field mapping is performed to obtain the preprocessed running data.

[0040] Here, a format mapping table is generated, recording information such as the data source name, original format type, and format parsing rules. This provides a basis for subsequent unified format conversion, avoiding parsing errors or conversion mistakes due to unfamiliarity with the data format. Generating standardized format data means converting all raw logs in different formats to JSON format based on the generated format mapping table. Then, based on the JSON format data, a unified field naming convention is established, field mapping is performed according to the convention, and finally, the preprocessed runtime data is output. This unified field naming convention involves defining globally unified data dictionary rules, such as using lowercase English letters with underscores; semantic unification, clarifying the meaning of fields (e.g., event_type only allows three values: attack alert, normal access, and abnormal traffic); and format unification, specifying data types (e.g., timestamp is uniformly set to millisecond-level timestamps, and ip_address is uniformly set to IPv4 strings).

[0041] S102: Process the running data using a lightweight model to generate initial alarm data.

[0042] Here, lightweight models (or simply small models) refer to models employing lightweight deep learning architectures. These are artificial intelligence models with fewer parameters, simpler architectures, and lower resource consumption, capable of running in real-time in resource-constrained environments. In practical implementation, lightweight models can be used to quickly analyze runtime data in real time. On the one hand, they can accurately classify known threats and identify new attacks such as ransomware variants. On the other hand, rule engines can filter false positives and duplicate alerts, retaining only valid information with potential threats to generate initial alert data, thus balancing real-time detection efficiency with preliminary threat screening capabilities.

[0043] In some embodiments, processing the operational data using a lightweight model to generate initial alarm data may include: extracting threat features based on the operational data and performing incremental learning to generate threat classification results and variant identification results; performing false alarm filtering and duplicate alarm removal based on the threat classification results and variant identification results to generate alarm data with preliminary noise reduction; and performing multi-source log correlation analysis based on the alarm data with preliminary noise reduction to obtain the initial alarm data.

[0044] In one embodiment, the above-described embodiments, based on the threat classification results and variant identification results, perform false alarm filtering and duplicate alarm removal to generate alarm data with preliminary noise reduction. This may include: matching the threat classification results and variant identification results with a whitelist rule base to generate a whitelist filtering result; aggregating alarms with the same source IP address, destination IP address, and threat type within a time window based on the whitelist filtering result to generate aggregated alarms; and removing alarms with confidence levels below a threshold based on the aggregated alarms to generate the alarm data with preliminary noise reduction.

[0045] In one implementation, the above embodiments, based on the pre-denoised alarm data, perform multi-source log correlation analysis to obtain the initial alarm data, which may include: extracting the source IP address, destination IP address, and time window information involved in the alarm based on the pre-denoised alarm data, and generating correlation query conditions; retrieving relevant log records from network layer raw data and host layer raw data based on the correlation query conditions, and generating a correlation log set; and analyzing the behavior sequence before and after the alarm based on the correlation log set and removing isolated alarms to obtain the initial alarm data.

[0046] In practical implementation, key threat features such as attack payloads, traffic statistics, and temporal behavior can be extracted from preprocessed operational data and transformed into high-dimensional feature vectors. These vectors are then input into a pre-trained lightweight model to classify known threats and identify some variants. For unconfirmed samples (suspected new variant attacks) that cannot be directly determined, incremental learning can be used to update model parameters, allowing the model to continuously adapt to new threats during operation. Combining the completed classification and variant identification results, a whitelist rule base can be used to filter false alarms caused by compliant operations (such as maintenance scans). Furthermore, alarms with the same source IP, destination IP, and threat type are aggregated within a time window to remove duplicate information (i.e., multiple alarms triggered by the same machine repeatedly attacking the same target in a short period using the same method are duplicate alarms that need to be processed; time window aggregation aims to determine only whether alarms within the same time window are duplicates, ensuring that alarms from different windows do not interfere with each other). Finally, low-confidence alarms with a confidence level below a threshold are removed, generating preliminary noise-reduced alarm data. Information such as source IP, destination IP, and time window can be extracted from the alarms after initial noise reduction. These can be used as correlation conditions to retrieve the original data at the network layer and host layer, and related logs can be integrated to form a correlation set. By analyzing the behavior sequence before and after the alarm, isolated alarms without context support are eliminated, and finally accurate initial alarm data with complete behavioral support is obtained, avoiding missed or misjudgments caused by single log analysis.

[0047] Here, by correlating multiple sources of raw data and analyzing behavioral sequences, a complete attack scenario is pieced together for each alarm. This transforms isolated signals into risk events supported by a chain of evidence, preventing the omission of real attacks or the misclassification of invalid alarms due to relying on a single log entry. The analysis of the behavioral sequence before and after an alarm refers to analyzing the coherent operations related to the source and destination IPs before and after the alarm occurs. If the associated log set contains only a single alarm log without any supporting preceding or following behaviors (e.g., only one port scan alarm, but no subsequent vulnerability exploitation, data access, or other device-related logs), such alarms are highly likely to be false alarms or invalid alarms (e.g., a normal business scan being misjudged). By analyzing the behavioral sequence, it is determined whether the alarm belongs to a complete attack process. If the behavior is coherent and the chain of evidence is complete, the alarm is retained; if it is an isolated alarm (without any contextual support), it is directly discarded.

[0048] In one implementation, the specific process of extracting threat features and performing incremental learning based on the above embodiments based on the operational data may include: extracting attack payload features, traffic statistics features, and temporal behavior features based on the operational data to generate a high-dimensional feature vector; inputting the high-dimensional feature vector into a pre-trained lightweight model to determine known threat classification results (and possibly some variant identification results) and samples to be confirmed; obtaining the variant identification results corresponding to the samples to be confirmed, and updating the lightweight model parameters through incremental learning based on the variant identification results corresponding to the samples to be confirmed.

[0049] Here, attack payload characteristics are the core content features of the attack behavior, such as malicious code payload fragments, keywords in SQL injection statements, and encryption features of ransomware (such as file extensions and hash values); traffic statistics characteristics are the network traffic pattern characteristics during the attack process, such as the number of connections per unit time, packet size distribution, protocol type (TCP / UDP / HTTP), and port access frequency; temporal behavior characteristics are the time sequence pattern characteristics of the attack, such as the time interval between attack initiation, the order of port scanning, and the sequential logic of multi-step attacks (such as probing first, then exploiting, and finally controlling). The generated high-dimensional feature vector is a feature vector (similar to an ordered string of numbers / identifiers) that integrates the above three types of features (which may contain hundreds or even thousands of specific feature items) in a unified format, enabling the lightweight model to quickly read, calculate, and identify them.

[0050] The generated high-dimensional feature vectors are input into a pre-trained lightweight model. The model, using built-in feature matching rules and learned knowledge, outputs classification results, including known threat classification results and pending confirmation results. If the high-dimensional feature vector highly matches the known threat feature library trained on the model (such as features related to common port scanning, ransomware, and Distributed Denial of Service (DDoS) attacks), the specific type of the threat is directly determined. If the high-dimensional feature vector has a low match with known threat features (or some features match but there are differences), and the type cannot be directly determined, it can be marked as a pending confirmation sample. A heavyweight model (large model) can then determine the variant identification result of the pending confirmation sample. This could be a variant of a known threat or a completely new, unknown threat (collectively referred to as the variant identification result). The variant identification result is then fed back to the lightweight model. The model, through an incremental learning mechanism, only updates the parameters related to that variant (without retraining the entire model), incorporating the unique features of the variant into its own threat feature library.

[0051] S103: Based on the initial alarm data, the heavy model is used to identify the authenticity of alarms and determine the threat level, and output the confirmed threat event information; the threat event information indicates the alarm data and threat level corresponding to the threat event confirmed by the heavy model.

[0052] Here, "heavyweight model" (large model) refers to an artificial intelligence model with a large number of parameters, complex architecture, and strong semantic understanding and knowledge fusion capabilities. In specific implementation, heavyweight model can deeply analyze the context of the initial alarm (such as attack chain integrity, asset importance, and historical attack patterns), identify the authenticity of alarms, eliminate redundant information, and determine the threat level (such as high / medium / low risk); finally, it outputs clear threat event information, indicating the confirmed alarm data and the corresponding threat level.

[0053] In some embodiments, when using a heavy-duty model to verify the authenticity of alarms and determine threat levels, and output confirmed threat event information, the following process may be performed using the heavy-duty model:

[0054] Based on the alarm data, natural language understanding technology is used to analyze the alarm context and generate alarm semantic features. Based on the alarm semantic features and stored historical attack patterns, the integrity of the attack chain, asset importance, and the matching degree of historical attack patterns are judged to generate alarm authenticity assessment results. Based on the alarm authenticity assessment results, redundant information is removed and the threat level is determined, and the threat event information is output.

[0055] Here, the heavy-duty model utilizes Natural Language Understanding (NLU) technology to parse unstructured information in alarm data (such as alarm descriptions, triggering conditions, and associated log text), transforming scattered context into standardized alarm semantic features (such as triggering scenario: port 445 access, asset type: financial server). Based on these alarm semantic features, and combined with historical attack patterns stored in the knowledge graph (such as the complete attack chain of EternalBlue, ransomware, etc.), the model conducts analysis from three key dimensions: attack chain integrity (whether the current alarm can form a complete attack chain with other related behaviors, rather than an isolated event), asset importance (whether the affected asset is a core business asset, rather than a test machine or decommissioned device), and historical attack pattern matching degree (whether the current alarm features are consistent with the behavioral logic and technical means of known real attacks in the knowledge graph). Based on the authenticity assessment results, redundant information such as false alarms and duplicate alerts are first eliminated. Then, the threat level is determined based on the comprehensive score of attack chain integrity, asset importance, and pattern matching. Finally, threat event information containing real alert data, threat level, and core judgment basis is output, providing a clear basis for subsequent source tracing, evidence collection, response and handling.

[0056] To address the judgment bias caused by insufficient information in a single model call, a progressive analysis and call mechanism can be adopted based on the above implementation method. This mechanism improves the comprehensiveness and accuracy of heavy model judgment by identifying information gaps, iteratively supplementing information, and focusing on precise judgment. Specifically, it can include the following process:

[0057] Based on the alarm data, an initial heavy model call is executed, outputting a list of information to be supplemented. Based on the list of information to be supplemented, corresponding information is supplemented from the asset database (used to store static and dynamic information of all network assets within the enterprise), the threat intelligence database (used to store global or regional threat information from public channels, business intelligence platforms, and industry-shared sources), and the historical event database (used to store security incidents, alarm handling records, remediation verification results, etc. that have occurred within the enterprise), and a second heavy model call is executed to generate preliminary assessment results and suspicious information. Based on the suspicious information, information supplementation and heavy model calls are iteratively executed until the iteration termination condition is met, at which point the threat event information is output.

[0058] Here, on the first call, initial alarm data is input into the heavyweight model. The model quickly analyzes the existing information and outputs a list of information to be supplemented. For example, if the initial alarm only mentions abnormal traffic to a certain asset, the model will determine that key information such as traffic protocol type, target port, and asset business type is missing, clarifying the direction for subsequent supplementation. On the second call, a preliminary assessment is performed and suspicious information is output. Specifically, based on the list of information to be supplemented, corresponding information is extracted from the asset database (retrieving asset business type and operating system), threat intelligence database (matching known threats corresponding to traffic characteristics), and historical event database (querying past attack records of the asset). The heavyweight model is called again, and it combines the supplemented information to complete the preliminary assessment (e.g., "possibly a Server Message Block (SMB) protocol vulnerability scan"), while outputting unresolved suspicious information. Subsequent calls to supplement suspicious information, call the heavyweight model, and generate new suspicious information repeat the process, each time supplementing more precise details (e.g., payload characteristics, asset vulnerability patch status), allowing the assessment to gradually focus. When the iteration termination conditions are met (such as all doubts are resolved, information is supplemented to fully cover the core elements, and the preset number of iterations is reached), the final threat event information is output.

[0059] In some embodiments, when determining the attack chain integrity, asset importance, and historical attack pattern matching degree based on alarm semantic features and historical attack patterns to generate an alarm authenticity assessment result, similar attack chains can be retrieved from a knowledge graph based on the alarm semantic features to generate an attack chain candidate set; based on the attack chain candidate set, the stage matching degree between the current alarm sequence and the standard attack chain is calculated to generate an attack chain integrity score; based on the attack chain integrity score and the business importance of the affected assets, the threat level is comprehensively determined to generate an alarm authenticity assessment result.

[0060] Here, firstly, based on the generated semantic features of the alert (such as attack protocol, trigger port, and behavioral characteristics), standard attack chains with similar characteristics (such as the complete chain of "port scanning, vulnerability exploitation, command execution, and file encryption" in the EternalBlue attack) are retrieved from the knowledge graph. This forms a candidate set of attack chains (i.e., several known attack chains most relevant to the current alert), providing a reference for the current alert and avoiding unfounded subjective judgments. For each standard attack chain in the candidate set, the current alert sequence (such as port 445 access → abnormal system process startup) is compared with the stage matching of the standard attack chain (such as whether it covers the critical stages of "vulnerability detection → attack execution"). The stage matching degree is calculated, and an attack chain integrity score is generated (e.g., matching 3 critical stages earns 80 points, matching only 1 stage earns 30 points). The higher the score, the more likely the current alert is to be part of a real attack, rather than an isolated event. By combining the attack chain integrity score with the business importance of the affected assets (e.g., core transaction systems have a weight of 100%, while ordinary office terminals have a weight of 50%), a risk score is calculated using a preset algorithm (e.g., weighted summation) to determine the threat level (e.g., a score ≥80 indicates high risk, 60-79 indicates medium risk, and <60 indicates low risk). The final alarm authenticity assessment result includes both qualitative conclusions of whether it is a true or false alarm and quantitative results of the threat level, providing accurate input for subsequent processes.

[0061] In this embodiment, the lightweight model and the heavy model are used in conjunction. To further improve operational efficiency, after generating initial alarm data and before the heavy model is used to verify the authenticity of alarms and determine the threat level, a comprehensive alarm risk score can be determined based on the initial alarm data. When the comprehensive alarm risk score is higher than a preset threshold, the heavy model is invoked. Based on the judgment results of the heavy model, alarm authenticity tags and newly added threat features can be synchronized back to the lightweight model to update the feature library and rule library of the lightweight model. In addition, the computing power allocation ratio between the lightweight model and the heavy model can be dynamically adjusted based on real-time business load and alarm volume to achieve optimized computing power configuration.

[0062] Specifically, after the lightweight and heavyweight models, a comprehensive risk score is calculated based on multi-dimensional information from alerts (such as threat signature matching degree, importance of affected assets, and correlation with historical attacks). The heavyweight model is only triggered when the score exceeds a preset threshold (e.g., 80 points for core assets and 60 points for ordinary terminals). This avoids all alerts consuming the heavyweight model's computing power, allowing the heavyweight model to focus on high-risk, high-value alerts (such as unknown threat alerts targeting financial servers), while the lightweight model handles the recording and basic processing of low-risk alerts (such as routine port scan alerts from test terminals). After the heavyweight model completes alert authenticity verification and threat level determination, it synchronizes the alert authenticity tags and newly added threat features back to the lightweight model, thereby updating the lightweight model's feature and rule bases. This implementation method allows the generalization ability of the lightweight model to continuously improve, while the judgment pressure on the heavyweight model gradually decreases, achieving co-evolution of both. In addition, by monitoring business load (such as server CPU / memory utilization) and alarm volume (such as the number of alarms per hour) in real time, the computing power ratio of the two types of models is dynamically adjusted. For example, during the daytime business peak (alarm volume surges, up to 100,000 alarms per hour), 60% of the computing power is allocated to the lightweight model to ensure real-time noise reduction and alarm generation efficiency; during the nighttime maintenance period (alarm volume drops sharply, up to 10,000 alarms per hour), 70% of the computing power is allocated to the heavy model, enabling it to deeply analyze historical alarms and explore potential attack correlations (such as cross-day attack chain reconstruction), thereby maximizing the overall system performance with limited hardware resources and taking into account both real-time and in-depth analysis needs.

[0063] S104: Based on the threat event information, perform risk management, obtain information on affected assets and match source tracing and evidence collection tools, and generate a standardized evidence collection report.

[0064] In practical implementation, based on the threat event information output by the heavy-duty model, risk handling can be automatically executed. This includes invoking response tools to adjust firewall policies, isolate endpoints, or scan for malicious files, generating handling results. Here, based on the key threat information corresponding to the threat event, response tools are invoked to perform immediate handling: adjusting firewall policies can block the attack source, preventing continued penetration; isolating infected endpoints can cut off lateral movement paths, preventing attackers from spreading to core business assets; and scanning for malicious files can eliminate local threats, preventing malicious code from further damaging data or control systems, thereby minimizing the impact of the attack on business. Furthermore, because risk handling is triggered by automated processes, it can greatly improve security operation response efficiency and reduce the cost of manual intervention.

[0065] In addition, by calling the asset management platform interface, detailed information such as the Internet Protocol (IP) address, operating system, and business line of the affected assets is obtained. Based on the asset information and threat event information, source tracing tools such as memory forensics and file integrity monitoring are accurately matched to collect evidence such as process snapshots and network connection records. After large-scale model correlation analysis, a standardized forensic report with unified format and complete information is generated to provide accurate basis for vulnerability remediation.

[0066] In some embodiments, obtaining information about affected assets and matching forensic tools to generate a standardized forensic report may include: based on the threat event information, calling the asset management platform interface to obtain the IP address, operating system, deployment location, and business line information of the affected assets; based on the IP address, operating system, deployment location, and business line information of the affected assets, as well as the threat characteristics corresponding to the alarm data in the threat event information, matching memory forensic tools and / or file integrity monitoring tools and distributing them to the affected assets to generate forensic data; and based on the forensic data, using a heavy-duty model to perform clue association and attack path reconstruction to generate the standardized forensic report.

[0067] Here, based on the threat event information (including threat type, scope of impact, etc.) output by the heavyweight model, the asset management platform interface is invoked to extract full information of the affected assets, including IP address (for locating asset location), operating system (for compatibility with subsequent tools), deployment location (for clarifying physical / network deployment scenarios), and business line (for determining asset importance). Based on the information of the affected assets and the threat characteristics in the threat events (such as malicious code injection or data tampering), targeted memory forensics tools (capturing real-time malicious processes, non-implied attack commands, and other easily lost evidence) and / or file integrity monitoring tools (detecting key file modification / deletion records) are matched and automatically distributed to the target assets for forensic analysis, generating forensic data containing information such as processes, network connections, and file hashes. This forensic data is input into the heavyweight model, and through the model's clue correlation capabilities, key attacker behavior information is reconstructed, including lateral movement paths (such as penetration from a terminal to a core server) and privilege escalation processes (such as from ordinary user to administrator privileges). Based on the reconstruction results, core information such as attack entry points (e.g., exploit ports), scope of damage (e.g., affected business systems), and residual traces (e.g., malicious files, registry modification records) are integrated to generate a standardized forensic report with a unified structure and standardized content.

[0068] In the above embodiments, matching memory forensics tools or file integrity monitoring tools based on the IP address, operating system, deployment location, and business line information of the affected asset, as well as threat characteristics, may include: querying the forensics tool matching rule base based on the attack type in the threat characteristics to generate a list of applicable tools; selecting compatible forensics tools based on the list of applicable tools and the operating system type of the affected asset to generate a tool deployment plan; and automatically distributing the forensics tools to the affected asset and executing forensics tasks based on the tool deployment plan to generate the forensics data.

[0069] Here, by extracting core attack types from threat characteristics (such as data tampering and malicious code injection), a pre-defined forensics tool matching rule base is queried (such as malicious code injection - memory forensics tools, data tampering - file integrity monitoring tools) to generate a list of applicable tools. From this list, tools compatible with the operating system type of the affected assets (such as Windows, Linux, and dedicated database systems) can be selected. For example, a dedicated memory forensics tool is adapted for Windows servers, and a corresponding version of a file integrity monitoring tool is matched for Linux terminals, generating a tool deployment plan (including tool type, deployment path, execution permissions, etc.). According to the tool deployment plan, without manual intervention, the forensics tools are automatically distributed to the affected assets, and forensics tasks are triggered simultaneously: the memory forensics tool captures malicious processes, attack commands, network connection status, etc. in memory in real time; the file integrity monitoring tool detects modification / deletion / addition records in system configuration files, database backup files, and critical business files. The final generated forensics data comprehensively covers attack-related traces, providing core material for subsequent attack path reconstruction.

[0070] In the above embodiments, the standardized forensic report is generated by using a heavy-duty model to correlate clues and reconstruct attack paths. Specifically, this may include: extracting process information, network connection information, file modification records, and registry modification records based on the forensic data to generate a set of forensic elements; analyzing the attacker's lateral movement path and privilege escalation process using a heavy-duty model based on the set of forensic elements to generate an attack timeline; and integrating attack entry point, damaged area, and residual trace information based on the attack timeline to generate the standardized forensic report.

[0071] Here, four core elements are extracted from the forensic data: process information (such as malicious processes that are abnormally started and their privilege levels), network connection information (such as connection records between the attack source IP and the target IP, communication protocols, and ports), file modification records (such as tampered system files, newly added malicious files and their hash values), and registry modification records (such as maliciously tampered system registry entries), forming a set of forensic elements. The heavy-duty model performs deep correlation analysis on this set of forensic elements, focusing on reconstructing two key behaviors: first, the attacker's lateral movement path (such as penetrating from terminal A through a vulnerability to server B, and then laterally spreading to database C); second, the privilege escalation process (such as gaining administrator privileges from ordinary user privileges through a privilege escalation vulnerability, and then controlling the entire asset). These behaviors are integrated chronologically to generate an attack timeline (including the occurrence time, operation content, and related elements of each attack step). Based on the attack timeline, the attack entry point (such as the exploited vulnerability port and the attack source IP), the scope of damage (such as the list of affected assets, business systems, and data types), and residual traces (such as uncleaned malicious files, registry modification records, and process remnants) are automatically integrated. The final standardized forensic report has a unified structure and standardized content, including both evidence details (such as file hash values ​​and process IDs) and attack logic (such as attack source → entry point → lateral movement → privilege escalation → destructive behavior), which can be directly used for subsequent stages such as vulnerability remediation plan formulation and attack liability determination.

[0072] S105: Based on the aforementioned standardized forensic report, perform vulnerability remediation.

[0073] In practice, based on the standardized forensic report, on the one hand, response tools can be invoked to automatically execute some security operation measures, and on the other hand, the vulnerability information in the report (such as the corresponding Common Vulnerabilities and Exposures (CVE) number, attack path, scope of impact, etc.) can be synchronized to the security team. The security team members can then develop targeted remediation plans based on the report details and carry out vulnerability remediation.

[0074] In some embodiments, the execution vulnerability remediation can be performed according to the following steps:

[0075] For the vulnerability information in the standardized forensics report, extract the common vulnerability disclosure CVE number and remediation recommendation, generate a vulnerability remediation task based on the CVE number and remediation recommendation, and issue the vulnerability remediation task to perform the vulnerability remediation operation.

[0076] Here, the core information of the exploited vulnerability is extracted from the standardized forensic report: the common CVE number (standardized vulnerability identifier) ​​and vulnerability details. Then, official remediation recommendations (such as patch installation and configuration adjustments) are retrieved from the vulnerability knowledge base. Based on this information, a structured vulnerability remediation task is generated, clearly defining the remediation content, responsible persons, and time limits, and then issued for execution, achieving a transition from temporary handling to fundamental resolution.

[0077] In the above embodiments, invoking the response tool to perform firewall policy adjustments, endpoint isolation, or malicious file removal may include: adding blacklist rules to the firewall management interface based on the attack source IP address in the standardized forensic report to block the attack source's access; invoking the endpoint management system to perform network isolation operations based on the infected host identifier in the standardized forensic report to cut off lateral movement paths; and invoking endpoint protection software to perform file removal based on the malicious file hash value in the standardized forensic report to generate the processing execution result.

[0078] Here, by extracting the attack source IP address from the standardized forensic report, a blacklist rule is directly added via the firewall management interface, thereby blocking the IP address from accessing the internal network. Based on the infected host identifier (such as hostname and IP) in the report, a network isolation operation is performed by calling the endpoint management system, which can isolate the infected host from the normal business network. The malicious file hash value (a unique identifier of a malicious file) recorded in the report is extracted, and the endpoint protection software is called to perform targeted scanning and removal, thereby accurately deleting malicious files from the infected host.

[0079] In the above embodiments, extracting the common vulnerability disclosure CVE number and remediation recommendations, and generating a vulnerability remediation task based on the CVE number and remediation recommendations, may include: identifying the exploited vulnerability and extracting the CVE number based on the standardized forensic report, generating a vulnerability list; querying official remediation recommendations and patch information from the vulnerability knowledge base based on the vulnerability list, generating a remediation solution recommendation; and creating a remediation task in the vulnerability management center and assigning a responsible person based on the remediation solution recommendation, thereby generating the vulnerability remediation task.

[0080] First, the vulnerabilities exploited in the attack are identified from the standardized forensic report, and their corresponding universal CVE numbers are extracted. CVE numbers are globally unified standardized vulnerability identifiers that uniquely correspond to a specific vulnerability. A clear vulnerability list is generated based on the CVE numbers, clearly defining the targets for remediation and avoiding vulnerability confusion. Next, based on the CVE numbers in the vulnerability list, the vulnerability knowledge base is consulted to retrieve officially released remediation recommendations (such as installing corresponding patches, adjusting system configurations, and disabling redundant functions) and patch download addresses, generating a suggested remediation plan. The suggested remediation plan is then entered into the vulnerability management center, creating a formal vulnerability remediation task, specifying the remediation deadline, responsible department / personnel, and issuing a task notification.

[0081] In some embodiments, to address the risk of false fixes in vulnerability remediation, a remediation effectiveness verification step can be added. This involves generating proof-of-concept (POC) code and conducting penetration testing to ensure that the vulnerability is completely fixed. Specifically, this includes the following processes:

[0082] Based on the remediation plan completed by the vulnerability remediation task, a verification feasibility prototype POC code is generated through a heavy model; based on the POC code, a penetration testing tool is invoked to simulate an attack scenario and generate test execution results; based on the test execution results, the remediation effect is determined, and if the remediation effect indicates that there is residual risk, the vulnerability remediation operation is re-executed.

[0083] Here, based on the remediation plan completed by the vulnerability remediation task (such as patch installation and configuration adjustment), the heavy-duty model automatically generates a Proof of Concept (POC) code. This code simulates the attack logic of an attacker exploiting the original vulnerability and is only used to verify whether the vulnerability can still be exploited; it does not have actual destructive capabilities. By calling penetration testing tools, the POC code is used as an attack simulation payload to launch a simulated attack on the remediated affected assets in a secure isolated environment. Based on the attack success rate of the penetration test (such as whether the vulnerability was successfully exploited) and the system response (such as whether the attack was intercepted and no abnormal behavior), the effectiveness of the vulnerability remediation is determined. If there is residual risk (such as a successful attack and the vulnerability still being exploitable), the process returns to the vulnerability remediation stage for re-execution; if the test passes, the vulnerability is confirmed to be completely remediated.

[0084] Furthermore, in the above embodiments, calling a penetration testing tool to simulate an attack scenario and generate test execution results may include: configuring the penetration testing target as a patched affected asset based on the simulated attack payload, and generating a test configuration; executing a penetration test in a secure isolation environment based on the test configuration, and recording the attack success rate and system response; and analyzing whether the vulnerability can still be exploited based on the attack success rate and system response, and generating the test execution results.

[0085] Here, the generated Proof-of-Concept (POC) code (attack simulation payload) serves as the core, clearly defining the penetration test objectives, the affected assets for which vulnerabilities have been patched, and configuring test parameters (such as attack ports, test duration, and execution permissions) to generate a standardized test configuration. In an independent environment isolated from the business network, the penetration test is executed according to the test configuration, recording the attack success rate (e.g., whether the POC code successfully triggers the vulnerability and gains privileges) and system response (e.g., whether the asset intercepts the attack, whether logs record anomalies, and whether the business operates normally) in real time. Based on the recorded attack success rate and system response data, it is determined whether the original vulnerability can still be exploited. If the attack success rate is 0 and the system can effectively intercept and respond normally, it indicates that the vulnerability has been completely patched; if the attack success rate is >0 or the system exhibits an abnormal response, it indicates that residual risk exists. This implementation method ensures that the vulnerability patching effect is verifiable, guaranteeing the continuity and reliability of security protection.

[0086] like Figure 2The diagram shows the system architecture of the network security operation scheme according to an embodiment of this disclosure. The data acquisition layer, composed of a full-traffic probe and a log acquisition probe, serves as the raw data source for the entire scheme. The full-traffic probe is responsible for collecting raw network layer data (such as TCP / UDP sessions, HTTP requests, malicious payloads, etc.), providing basic material for subsequent threat identification based on traffic dimensions. The log acquisition probe is responsible for collecting raw host layer data (such as system logs, application logs, security device alarms, etc.), supplementing asset-side behavior and anomaly records. The Artificial Intelligence (AI) model layer includes a lightweight model execution module and a heavyweight model execution module. The lightweight model execution module undertakes real-time, lightweight, and rapid analysis tasks, while also performing data preprocessing and preliminary noise reduction to ensure low-latency basic threat identification. The heavyweight model execution module undertakes deep and complex decision-making tasks, handling unconfirmed samples that the small model cannot determine, and performing in-depth analysis such as reconstructing attack chains. The two systems interact through two-way collaboration: the lightweight model synchronizes preliminary processing results to the large model for in-depth analysis, while the heavyweight model feeds back analysis results (such as alarm tags and new threat features) to the lightweight model to update the rule base, achieving complementary capabilities in real-time detection and in-depth decision-making. The business function layer is the implementation layer for security operations, including an asset management platform, a vulnerability management center, source tracing and evidence collection tools, and a response and handling engine. The asset management platform provides information such as the IP address, operating system, and business line of affected assets, providing basic asset-level data for source tracing, evidence collection, and vulnerability remediation. The vulnerability management center is responsible for creating vulnerability remediation tasks and assigning responsibility, serving as the task management carrier for the closed-loop vulnerability remediation process. The source tracing and evidence collection tools match evidence collection tools based on AI analysis results, execute evidence collection tasks, and generate standardized evidence collection reports. The response and handling engine performs emergency operations such as firewall policy adjustments, endpoint isolation, and malicious file scanning to quickly control threat spread.

[0087] like Figure 3 As shown, this disclosure provides a network security operation device 300, including:

[0088] Data acquisition module 31 is used to acquire the running data to be processed, wherein the running data is obtained by preprocessing network traffic data and log data;

[0089] The lightweight model running module 32 is used to process the running data using a lightweight model and generate initial alarm data.

[0090] The heavy model operation module 33 is used to identify the authenticity of alarms and determine the threat level based on the initial alarm data through the heavy model, and output confirmed threat event information; the threat event information indicates the alarm data and threat level corresponding to the threat event confirmed by the heavy model;

[0091] The report generation module 34 is used to perform risk disposal based on the threat event information, obtain information on affected assets and match source tracing and evidence collection tools, and generate a standardized evidence collection report;

[0092] Repair module 35 is used to perform vulnerability repair based on the standardized forensic report.

[0093] The specific implementation process of the functions and roles of each unit in the above-mentioned device can be found in the implementation process of the corresponding steps in the above-mentioned network security operation method, and will not be repeated here.

[0094] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this disclosure according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0095] Based on the same technical concept, this disclosure also provides an electronic device 400, referring to... Figure 4 The diagram shown is a schematic representation of the structure of an electronic device according to an exemplary embodiment of this disclosure, comprising:

[0096] The processor 410, memory 420, and bus 430 are included. The memory 420 is used to store execution instructions and includes main memory 421 and external memory 422. The main memory 421, also known as internal memory, is used to temporarily store the operation data in the processor 410 and the data exchanged with external memory 422 such as hard disk. The processor 410 exchanges data with external memory 422 through main memory 421.

[0097] In this embodiment, the memory 420 is specifically used to store application code that executes the scheme of this disclosure, and its execution is controlled by the processor 410. That is, when the electronic device 400 is running, the processor 410 communicates with the memory 420 through the bus 430, or the processor 410 communicates with the memory 420 through other means, so that the processor 410 executes the application code stored in the memory 420, thereby executing the steps of the network security operation method described in any of the foregoing embodiments.

[0098] The memory 420 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0099] Processor 410 may be an integrated circuit chip with signal processing capabilities. The aforementioned processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this disclosure. The general-purpose processor can be a microprocessor or any conventional processor.

[0100] It is understood that the structures illustrated in the embodiments of this disclosure do not constitute a specific limitation on the electronic device 400. In other embodiments of this disclosure, the electronic device 400 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0101] This disclosure also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the network security operation method described in the above-described method embodiments. The storage medium may be a volatile or non-volatile computer-readable storage medium.

[0102] This disclosure also provides a computer program product, which stores a computer program. When the computer program is run by a processor, it executes the steps of the network security operation method provided in any of the above embodiments of this disclosure. For details, please refer to the above method embodiments, which will not be repeated here.

[0103] The aforementioned computer program product can be implemented through hardware, software, or a combination thereof. In one optional embodiment, the computer program product is specifically embodied in a computer storage medium, which can be a volatile or non-volatile computer-readable storage medium. In another optional embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0104] Furthermore, embodiments of the subject matter and functional operation described in this specification can be implemented in the following ways: digital electronic circuits, tangibly embodied computer software or firmware, computer hardware including the structures disclosed in this specification and their structural equivalents, or combinations thereof. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible, non-transitory program carrier for execution by a data processing apparatus or for controlling the operation of a data processing apparatus. Alternatively or additionally, program instructions may be encoded on artificially generated propagation signals, such as machine-generated electrical, optical, or electromagnetic signals, which are generated to encode information and transmit it to a suitable receiving device for execution by the data processing apparatus. The computer storage medium may be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or combinations thereof.

[0105] The processing and logic flows described in this specification can be executed by one or more programmable computers that execute one or more computer programs to perform corresponding functions by operating on input data and generating output. The processing and logic flows can also be executed by dedicated logic circuits—such as field-programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs), and the device can also be implemented as dedicated logic circuits.

[0106] Suitable computers for executing computer programs include, for example, general-purpose and / or special-purpose microprocessors, or any other type of central processing unit. Typically, the central processing unit receives instructions and data from read-only memory and / or random access memory. The basic components of a computer include a central processing unit for implementing or executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices for storing data, such as disks, magneto-optical disks, or optical disks, or the computer will be operatively coupled to such mass storage devices to receive data from or transfer data to them, or both. However, a computer is not required to have such devices. Furthermore, a computer can be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device such as a Universal Serial Bus (USB) flash drive, to name a few.

[0107] Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, such as semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., internal hard disks or removable disks), magneto-optical disks, and CD-ROM and DVD-ROM disks. Processors and memory may be supplemented by or incorporated into dedicated logic circuitry.

[0108] While this specification contains numerous specific implementation details, these should not be construed as limiting the scope of any invention or the scope of the claims, but rather are primarily intended to describe features of specific embodiments of a particular invention. Certain features described in the various embodiments herein may also be implemented in combination in a single embodiment. Conversely, various features described in a single embodiment may also be implemented separately in various embodiments or in any suitable sub-combination. Furthermore, while features may function in certain combinations as described above and even initially claimed in this way, one or more features from a claimed combination may be removed from that combination in some cases, and a claimed combination may refer to a sub-combination or a variation thereof.

[0109] Similarly, although the operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring these operations to be performed in the specific order shown or sequentially, or requiring all illustrated operations to be performed to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system modules and components in the above embodiments should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0110] Thus, specific embodiments of the subject matter have been described. Other embodiments are within the scope of the appended claims. In some cases, the actions recited in the claims may be performed in a different order and still achieve the desired result. Furthermore, the processes depicted in the drawings are not necessarily shown in a specific order or sequence to achieve the desired result. In some implementations, multitasking and parallel processing may be advantageous.

[0111] The above description is merely a preferred embodiment of this disclosure and is not intended to limit this disclosure. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A network security operation method, characterized in that: include: Obtain the operational data to be processed, which is obtained by preprocessing network traffic data and log data; The runtime data is processed using a lightweight model to generate initial alarm data; Based on the initial alarm data, the authenticity of alarms and the threat level are determined through a heavy model, and the confirmed threat event information is output. The threat event information indicates the alarm data and threat level corresponding to the threat event confirmed by the heavy model; wherein, the heavy model has more parameters than the lightweight model; Based on the threat event information, risk management is carried out, and information on affected assets and matching traceability and evidence collection tools are obtained to generate a standardized evidence collection report; Based on the standardized forensic report, perform vulnerability remediation. The acquisition of affected asset information and matching of source tracing and evidence collection tools, and the generation of standardized evidence collection reports, include: Based on the threat event information, obtain the IP address, operating system, deployment location, and business line information of the affected assets; Based on the IP address, operating system, deployment location, and business line information of the affected assets, as well as the threat characteristics corresponding to the alarm data in the threat event information, memory forensics tools and / or file integrity monitoring tools are matched and distributed to the affected assets to generate forensic data. Based on the forensic data, the standardized forensic report is generated by using a heavy-duty model to correlate clues and reconstruct attack paths. The vulnerability remediation process includes: extracting the Common Vulnerability Disclosure (CVE) number and remediation recommendations from the vulnerability information in the standardized forensics report; generating a vulnerability remediation task based on the CVE number and remediation recommendations; and issuing the vulnerability remediation task to perform the vulnerability remediation operation. The step of generating the standardized forensic report by associating clues and reconstructing attack paths using a heavy-duty model includes: Based on the evidence data, process information, network connection information, file modification records, and registry modification records are extracted to generate an evidence element set. Based on the forensic element set, the attacker's lateral movement path and privilege escalation process are analyzed using a heavy-duty model to generate an attack timeline; Based on the attack timeline, information on the attack entry point, the scope of damage, and residual traces is integrated to generate the standardized forensic report.

2. The method according to claim 1, characterized in that, Obtain the runtime data to be processed, including: The system collects TCP traffic, UDP traffic, and HTTP session data using a full-traffic probe to generate raw network layer data. Additionally, it collects system logs, application logs, and device alarm logs using a log collection probe to generate raw host layer data. Based on the original data from the network layer and the original data from the host layer, data format standardization and field mapping are performed to obtain preprocessed runtime data.

3. The method according to claim 1, characterized in that, The runtime data is processed using a lightweight model to generate initial alarm data, including: Based on the operational data, threat features are extracted and incremental learning is performed to generate threat classification results and variant identification results. Based on the threat classification results and variant identification results, false alarm filtering and duplicate alarm removal are performed to generate alarm data after preliminary noise reduction; Based on the alarm data after preliminary noise reduction, multi-source log correlation analysis is performed to obtain the initial alarm data.

4. The method according to claim 3, characterized in that, Based on the operational data, threat features are extracted and incremental learning is performed to generate threat classification results and variant identification results, including: Based on the operational data, attack payload features, traffic statistics features, and time-series behavior features are extracted to generate a high-dimensional feature vector. The high-dimensional feature vector is input into a pre-trained lightweight model to determine the known threat classification results and the samples to be confirmed. Obtain the variant identification result corresponding to the sample to be confirmed, and update the lightweight model parameters through incremental learning based on the variant identification result corresponding to the sample to be confirmed.

5. The method according to claim 3, characterized in that, Based on the alarm data after preliminary noise reduction, multi-source log correlation analysis is performed to obtain the initial alarm data, including: Based on the alarm data after preliminary noise reduction, the source IP address, destination IP address and time window information involved in the alarm are extracted to generate related query conditions; Based on the aforementioned correlation query conditions, relevant log records are retrieved from the network layer raw data and the host layer raw data to generate a correlation log set; Based on the associated log set, the behavior sequence before and after the alarm is analyzed and isolated alarms are removed to obtain the initial alarm data.

6. The method according to claim 1, characterized in that, The heavyweight model is used to distinguish between genuine and false alarms and determine the threat level, outputting confirmed threat event information. This includes performing the following processes through the heavyweight model: Based on the alarm data, alarm semantic features are generated by analyzing the alarm context information; Based on the alarm semantic features and the stored historical attack patterns, the integrity of the attack chain, the importance of the asset, and the matching degree of the historical attack patterns are judged to generate an alarm authenticity assessment result. Based on the alarm authenticity assessment results, redundant information is removed and the threat level is determined, and the threat event information is output.

7. The method according to claim 6, characterized in that, When the heavy-duty model performs alarm authenticity verification and threat level determination, it adopts a progressive analysis and invocation mechanism, including: Based on the alarm data, perform the first heavy model call and output a list of information to be supplemented. Based on the list of information to be supplemented, corresponding information is supplemented from the asset database, threat intelligence database and historical event database, and a second heavy model call is executed to generate preliminary judgment results and suspicious information. Based on the suspicious information, iteratively perform information supplementation and heavy model invocation until the iteration termination condition is met, at which point the threat event information is output.

8. The method according to claim 1, characterized in that, The risk handling process includes: based on the threat event information, invoking response tools to perform firewall policy adjustments, endpoint isolation, or malicious file removal, and generating handling execution results.

9. The method according to claim 8, characterized in that, The method further includes: Based on the remediation plan completed by the aforementioned vulnerability remediation task, a verification feasibility verification prototype POC code is generated through a heavy model; Based on the POC code, a penetration testing tool is invoked to simulate an attack scenario and generate test execution results. Based on the test results, the repair effect is determined. If the repair effect indicates that there is a residual risk, the vulnerability repair operation is re-executed.

10. A network security operation device, characterized in that: include: The data acquisition module is used to acquire the operational data to be processed, which is obtained by preprocessing network traffic data and log data; The lightweight model execution module is used to process the execution data using the lightweight model and generate initial alarm data. The heavy model running module is used to identify the authenticity of alarms and determine the threat level based on the initial alarm data through the heavy model, and output confirmed threat event information; The threat event information indicates the alarm data and threat level corresponding to the threat event confirmed by the heavy model; wherein, the heavy model has more parameters than the lightweight model; The report generation module is used to perform risk management based on the threat event information, obtain affected asset information, match source tracing and forensic tools, and generate a standardized forensic report. When obtaining affected asset information and matching source tracing and forensic tools to generate a standardized forensic report, the report generation module is used to: obtain the IP address, operating system, deployment location, and business line information of the affected assets based on the threat event information; and match memory forensic tools and / or file integrity monitoring tools based on the IP address, operating system, deployment location, and business line information of the affected assets, as well as the threat characteristics corresponding to the alarm data in the threat event information, and distribute the results to... For affected assets, forensic data is generated. Based on the forensic data, a heavy-duty model is used to correlate clues and reconstruct attack paths, generating the standardized forensic report. When generating the standardized forensic report using the heavy-duty model to correlate clues and reconstruct attack paths, the following steps are performed: based on the forensic data, process information, network connection information, file modification records, and registry modification records are extracted to generate a set of forensic elements; based on the set of forensic elements, the heavy-duty model is used to analyze the attacker's lateral movement path and privilege escalation process, generating an attack timeline; based on the attack timeline, attack entry point, damaged area, and residual trace information are integrated to generate the standardized forensic report. The remediation module is used to perform vulnerability remediation based on the standardized forensic report. When performing vulnerability remediation, the remediation module is used to: extract the common vulnerability disclosure CVE number and remediation suggestion from the vulnerability information in the standardized forensic report, generate a vulnerability remediation task based on the CVE number and remediation suggestion, and issue the vulnerability remediation task to perform the vulnerability remediation operation.

11. An electronic device, characterized in that, The method includes a processor and a memory, the memory storing machine-readable instructions executable by the processor, the processor executing the machine-readable instructions stored in the memory, and when the machine-readable instructions are executed by the processor, the processor performs the steps of the network security operation method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, Includes instructions stored thereon, wherein, when the instructions are executed by a processor, the network security operation method as described in any one of claims 1-9 is performed.

Images