Network security alarm log intelligent research and judgment method, terminal device and storage medium

Abstract

The application discloses a network security alarm log intelligent research and judgment method, a terminal device and a storage medium. Alarm information is collected by an SIEM system and key fields are extracted, and associated logs are collected based on a time window and an IP pool and data cleaning is completed. Then, a log stream containing statistical characteristics is constructed through template processing. In combination with the construction of a knowledge graph, security enhancement information is injected into the log stream. Through security vertical field large model knowledge distillation and multi-scene LoRA fine-tuning, lightweight deployment of a single base multi-module is realized. Step-by-step reasoning is adopted to complete the generation of attack chains, risk levels and disposal suggestions. Finally, through dynamic updating and module iteration, the research and judgment accuracy is continuously improved. The scheme can significantly reduce the alarm false alarm rate, adapt to the hardware conditions of small and medium-sized enterprises, balance the research and judgment accuracy and the timeliness of response, and greatly improve the efficiency of security operation and maintenance.

Description

Technical Field

[0001] This invention relates to the field of network security alarm log technology, and in particular to a method for intelligent analysis of network security alarm logs, a terminal device, and a storage medium. Background Technology

[0002] Cyberspace has become a core infrastructure supporting the operation of critical sectors. With the explosive growth of mobile applications and IoT terminals, the scale of network security alarm logs has grown exponentially. Large enterprises generate more than 5 million alarm logs per day, while medium-sized enterprises can generate more than 1 million. These logs include various types of information such as firewall blocking, intrusion detection (IDS) alarms, and abnormal host behavior.

[0003] These logs have become the core data carrier for perceiving network threats and locating security risks. Although technical tools can detect threats, operations analysts still need to rely on human judgment to verify alerts. This process involves complex situational analysis and experience-based judgment, leading to workload and fatigue.

[0004] With the development of AI technology, alarm log analysis has gradually shifted towards AI-driven approaches. Currently, the main application scenarios primarily employ two methods: traditional machine learning and deep learning methods, represented by Large Language Models (LLM). Machine learning methods are widely used due to their high efficiency; however, poor interpretability and insufficient generalization are inherent problems. While LLM possesses strong comprehensive analytical capabilities and judgment accuracy, and can achieve even higher-precision content recognition after vertical domain fine-tuning, its high deployment and training costs make it unaffordable for many small and medium-sized enterprises. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to provide a method, terminal device and storage medium for intelligent analysis of network security alarm logs, which addresses the shortcomings of the existing technology, thereby reducing the false alarm rate and improving the analysis accuracy.

[0006] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is: an intelligent analysis method for network security alarm logs, comprising the following steps:

[0007] S1. Receive alarm information generated by the SIEM system and extract key information from the alarm information;

[0008] S2. Based on the key alarm information, collect log sets from the log server, collect relevant logs for the corresponding IP within a specified time period, and form a log sequence;

[0009] S3. The collected log sequence is divided into different subsequences according to time interval and IP address, and the log feature information of the subsequences is extracted to construct a log stream sequence;

[0010] S4. Enhance the security information of the log stream sequence by adding network location and security vulnerability information to the log stream sequence;

[0011] S5. Query the host information and security vulnerability information involved in the log stream in the knowledge graph, and input the log stream with enhanced security information into the large model for discrimination; the large model is deployed in the form of a single base model and multiple LoRa modules;

[0012] S6. Based on the log stream after security information enhancement, construct prompt words step by step, call different LoRa modules for analysis, enhance the analysis results before generation, call the MITRE ATT&CK model to further analyze the attack stage and root cause, and output a comprehensive analysis report.

[0013] By using S2 and S3, relevant logs for the corresponding IP within a specified time period are collected to form a log sequence, which is then divided into different sub-sequences to construct a log stream sequence. By analyzing the log stream sequence, this invention can identify log chains with temporal, behavioral patterns, and causal relationships, and filter out isolated noise lacking contextual support, thereby significantly reducing false alarms.

[0014] By combining S4 and S5, external context such as network location, host information, and security vulnerability information is added to the original alerts, avoiding simple matching based solely on signatures or rules. For example, an IP accessing a port might trigger an alert in itself. However, with the enhancement, if the IP belongs to a legitimate internal server and the target host is known to have a security vulnerability related to the alert, the host profile from the knowledge graph allows the large-scale model to more accurately determine whether it is a genuine attack attempt or a normal internal traffic or compliance scan. This cross-validation of multi-dimensional information greatly improves the accuracy of the judgment and effectively eliminates false alarms caused by insufficient background information.

[0015] In step S5, different LoRA modules can be fine-tuned for specific security logs. Step-by-step invocation means that the LoRA module can be used first to identify the attack type, and then the base model can be used to analyze the combined impact. This professional and modular approach ensures the depth and professionalism of the analysis results, improving the accuracy of the analysis.

[0016] Step S6 calls the MITRE ATT&CK model to further analyze the attack phases and root causes, and performs pre-generation enhancements before generating the report to ensure that the final comprehensive analysis report contains all key information (original logs, knowledge graph information, LoRA assessment results, ATT&CK mapping), guaranteeing the report's comprehensiveness, logic, and credibility.

[0017] The specific implementation process of step S1 includes:

[0018] The SIEM system monitors Syslog and firewall information in real time. Syslog is deployed in a distributed manner on the network to monitor logs from various systems and services as well as traffic logs provided by the firewall.

[0019] The SIEM system sets relevant rules, triggers the generation of alarm information after detecting anomalies, and records the time of occurrence, end time, source IP address, and destination IP address of the network attack. After receiving the alarm information, key information is extracted.

[0020] In step S2, an IP address pool is established using the attack source IP address and the attack destination IP address. The corresponding logs within the time window are selected by traversing the IP pool, and a log sequence based on IP grouping is established by sorting by time.

[0021] The time window is {t1-te, t2+te}, where t1 is the attack start time, t2 is the attack end time, te is the log quantity evaluation extension time within the time period ta, and ta is the attack duration.

[0022] In step S3, the specific construction process of a single log stream in the log stream sequence includes:

[0023] Iterate through the timestamps of log entries in the log sequence and group logs that are longer than a set time interval.

[0024] The logs are templated using a log template extraction method to obtain a set of templates. Save the template sequence number and parameter value. At this time, the log sequence is represented by log sequence grouping by time interval, which is represented by log template sequence number and parameter value.

[0025] The number of logs, template distribution, and duration of each log sequence are counted to form log sequence attributes, which constitute a single log stream.

[0026] In step S5, the training process of the large model includes:

[0027] The log sequences are input into the teacher model in batches to generate soft labels that include threat type probability distribution, risk level weight, and root cause analysis.

[0028] A predetermined proportion of samples in the log sequence are labeled with hard tags;

[0029] Construct a log sequence attribute-soft label-hard label ternary dataset to obtain the distillation dataset; the log sequence attributes include the number of logs in a single log sequence, template distribution, and duration;

[0030] The distillation dataset is used as input to the student model to train the student model, resulting in the trained student model.

[0031] All logs in the log pool are templated, and the templated logs are used as input to the trained student model to fine-tune the trained student model.

[0032] Normal datasets or abnormal datasets are constructed using different categories of log data. These normal datasets or abnormal datasets are then used as inputs to a fine-tuned student model. The fine-tuned student model is then subjected to LoRa fine-tuning to form different LoRa modules.

[0033] In the field of cybersecurity, professional, high-quality alert labeling, especially involving root cause analysis and risk level assessment, is extremely time-consuming and relies heavily on experienced experts. Knowledge distillation enables student models to learn efficiently with fewer hard labels and a large number of soft labels, significantly reducing reliance on large-scale expert-annotated data. The probability distribution provided by the labels helps student models better understand and handle ambiguous, boundary-case log sequences, improving the model's generalization ability in the face of novel, unseen attacks.

[0034] Template-based self-supervised fine-tuning involves inputting templated logs into the model for fine-tuning. This trains the model to understand the core events / actions of the logs—the semantics of the templates—rather than being distracted by dynamic parameters. This is equivalent to performing a security-domain-specific pre-training or self-supervised learning process on the student model before downstream security tasks, enabling it to better capture the syntactic and semantic relationships between different log templates and laying the foundation for subsequent accurate analysis.

[0035] LoRA modular fine-tuning overcomes the performance bottleneck of a single general-purpose model when facing various complex scenarios in the security field, enabling specialized models for specific tasks and significantly improving the analysis accuracy for particular tasks. Simultaneously, only a large base model and multiple lightweight LoRA weights need to be stored. This greatly reduces the deployment memory / storage requirements. At runtime, the model's functionality can be quickly changed by loading or switching different LoRA weights without loading multiple large model instances. This allows the system to flexibly respond to new threats or add new analysis types. During LoRA fine-tuning, the original knowledge of the base model is preserved, effectively avoiding catastrophic omissions that may occur during task-specific fine-tuning.

[0036] The loss function of the student model Represented as: ;in, Represents cross-entropy loss, For student model prediction results, Classification error of hard labels For hyperparameters, KL divergence is used to measure the distribution of the teacher model output. Student model distribution The difference is expressed by the formula: , where i is the sample number in the distillation dataset.

[0037] Also includes:

[0038] When there are changes in the network environment or adjustments to the network security logs, the enhanced security information log stream can be updated as needed, or the Lora module can be added or removed.

[0039] As an inventive concept, the present invention also provides a terminal device, including a memory, a processor, and a computer program stored in the memory; the processor executes the computer program to implement the steps of the above method.

[0040] As an inventive concept, the present invention also provides a computer-readable storage medium having a computer program / instructions stored thereon; when the computer program / instructions are executed by a processor, they implement the steps of the above-described method.

[0041] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0042] 1. This invention utilizes RAG technology and knowledge injection large model to analyze network security alarm log data. It can deeply analyze alarm-related logs and alarm information, and further explore network security behavior through time extension. Compared with traditional methods, it greatly improves the accuracy of alarm judgment, thereby significantly reducing false alarms and helping network security operation and maintenance personnel to more accurately judge alarm information.

[0043] 2. This invention employs a knowledge distillation method and a single-base, multi-LoRa module deployment approach, enabling lightweight operation and meeting the hardware requirements of small and medium-sized enterprises. Simultaneously, the efficient operation of a small-scale, high-model architecture further improves response time, balancing accuracy and timeliness, and effectively enhancing the efficiency of security operations and maintenance. Attached Figure Description

[0044] Figure 1 This is a flowchart illustrating the intelligent analysis of network security alarm logs based on a knowledge-enhanced large model, as described in an embodiment of the present invention.

[0045] Figure 2 This is a schematic diagram illustrating the fine-tuning and deployment of the large model in an embodiment of the present invention;

[0046] Figure 3 This is a comparative diagram of ablation experiments using the LoRA module in an embodiment of the present invention;

[0047] Figure 4This is a comparative diagram of the ablation experiment of the RAG module in an embodiment of the present invention. Detailed Implementation

[0048] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0049] In this document, the terms "first," "second," and other similar words are not intended to imply any order, quantity, or importance, but are merely used to distinguish different elements. The terms "one," "a," and other similar words are not intended to indicate the existence of only one of the stated things, but rather that the description refers only to one of the stated things, which may have one or more. The terms "comprising," "including," and other similar words are intended to indicate a logical relationship, not a spatial relationship. For example, "A includes B" means that logically B belongs to A, not that spatially B is located inside A. Furthermore, the meanings of the terms "comprising," "including," and other similar words should be considered open-ended, not closed. For example, "A includes B" means that B belongs to A, but B does not necessarily constitute all of A; A may also include other elements such as C, D, and E.

[0050] Example 1

[0051] This embodiment provides an intelligent analysis method for network security alarm logs based on a knowledge-enhanced large model, which specifically includes the following steps:

[0052] Step S1: The SIEM system is located in the network and monitors Syslog and firewall information in real time. Syslog is deployed in a distributed manner in the network, monitoring logs from various systems and services as well as traffic logs provided by the firewall. The SIEM system sets relevant rules, and triggers the generation of alarm information after detecting anomalies, recording information such as the time of occurrence and end of the network attack, source IP address, and destination IP address. After receiving the alarm, key information is extracted.

[0053] Step S2: Based on the collected alarm information, firstly, set the collection window according to the attack time. Specifically, with the attack start time as t1 and the attack end time as t2, obtain the attack duration ta = t2 - t1. Estimate the extended time te based on the length of ta and the number of logs within the ta time period, and finally determine the time window as {t1 - te, t2 + te}. Establish an IP address pool based on the attack source IP address and the attack destination IP address. By traversing the IP pool, select the corresponding logs within the time window and establish a log sequence grouped by IP address according to time.

[0054] In some embodiments, this step first preprocesses the raw logs, defines the log format according to requirements, merges duplicate logs, and performs preliminary data cleaning.

[0055] Due to the complexity of log sources, log formats are often heterogeneous, requiring further information extraction to obtain log data with unified fields and a clear structure, which is then output in JSON format.

[0056] Step S3: For the obtained log sequence, firstly, iterate through the timestamps of the log entries and group logs with timestamps greater than a certain time interval. Next, use a log template extraction method to template the logs, obtaining a template set. The template ID and parameter values ​​are saved. At this point, the log sequence is represented as a log sequence group grouped by time intervals, represented by the log template sequence number and parameter value. Finally, the number of logs, template distribution, duration, and other information of each individual log sequence are counted to form log sequence attributes, which constitute a single log stream. From this, log streams corresponding to different IPs and time windows are output.

[0057] In some embodiments, the time interval is set to 10 seconds, a setting that has proven effective in experiments. Template extraction methods typically employ the Drain3 algorithm or regular expressions. When there are few log types, regular expressions are more direct and efficient. However, in most cases, the log types are complex, and the Drain3 algorithm can effectively extract templates for different log types and automatically generate a set of log templates with serial numbers. In some scenarios, both the Drain3 algorithm and regular expressions are used simultaneously; in this case, the regular expression templates need to be manually added to the template set.

[0058] Step S4: Perform information statistics on each computer in the network topology where SIEM is located, store the information according to host domain, record inter-domain device information in different host domains, and ensure that the location information of the host in the entire network topology can be obtained through inter-domain devices during retrieval; collect the relevant vulnerability information based on all computer information and service information in the network topology, and establish a complete device-vulnerability mapping table.

[0059] In some embodiments, the recorded relevant information mainly includes host IP address, host operating system, host service software, host domain address, inter-domain device function, and inter-domain device model;

[0060] The acquired host information is standardized to obtain the corresponding CPE information. The CVE vulnerability database is queried based on the CPE information to return the corresponding vulnerabilities, thus obtaining a complete network topology vulnerability database.

[0061] By associating the vulnerability database with host information, a knowledge graph is formed, where nodes represent host attributes and vulnerability information, and edges represent the network topology relationships of the hosts.

[0062] Step S5: Query the host information and vulnerability information involved in the log stream in the knowledge graph, and input the enhanced log stream into the large model for discrimination.

[0063] To balance lightweight deployment of large models with accurate judgment, the large model is deployed in the form of a single base and multiple LoRa modules. The base model uses a small-parameter large model that is distilled from the large model in the vertical domain and fine-tuned with template knowledge. The LoRa modules are fine-tuned and optimized for different scenarios.

[0064] In some instances, the base model uses Qwen3-1.5b.

[0065] Fine-tuning methods for large models, such as Figure 2 As shown. The knowledge distillation dataset is generated using a large-scale cybersecurity vertical model as the teacher model. In some embodiments, the large-scale cybersecurity vertical model used is SecGPT. The log sequences aggregated by S2 are input into SecGPT in batches to generate soft labels containing "threat type probability distribution, risk level weight, and root cause analysis". For example, for the feature "IP=192.168.1.5, 3306 port connection failure 30 times / minute", SecGPT outputs the following soft labels:

[0066] Threat type distribution: such as MySQL brute-force attacks (60%), false positives for normal access (30%), and other attacks (10%).

[0067] Risk level: Medium (weight 0.7);

[0068] Root cause: such as "weak password protection".

[0069] Combined with manual review, 10% of the samples were labeled with hard labels (risk rating on a 10-point scale) to construct a triplet dataset of "statistical features-soft labels-hard labels", which constitutes the distillation dataset.

[0070] The student model Qwen3-1.5b was trained using the distillation dataset. For large-scale model distillation, a total loss function was employed, which was a weighted sum of cross-entropy loss and KL divergence. The specific method was as follows:

[0071] ;

[0072] in, Represents the cross-entropy loss, used to calculate the student model's prediction results. With artificial hard labels Classification error; KL divergence is used to measure the soft label output of the teacher model. Analysis of student model output The difference is expressed by the formula: Weight It is a hyperparameter that is optimized synchronously during training using a hyperparameter optimization algorithm.

[0073] To significantly improve model efficiency, this method uses a log template ID plus parameters instead of the original log information as input to the large model for the log stream generated by S3. Therefore, to ensure the template understands the meaning of the template ID and parameters, further fine-tuning is needed on the student model, which has already undergone knowledge distillation and possesses vertical domain knowledge.

[0074] Templates were used to construct a student model fine-tuning dataset by using all logs in the log pool.

[0075] The log template extraction process is as follows:

[0076] To address the structural characteristics of different log types, the system employs a differentiated parsing strategy to achieve efficient template generation.

[0077] In some instances, traffic logs generated by standardized firewall devices are extracted using a structured extraction technique based on regular expressions. By employing predefined pattern matching rules, key fields are precisely extracted from the raw log text. The extracted standardized fields include key dimensions such as timestamp, source / destination IP, action type, protocol type, port information, byte count, and packet count. This templated processing not only achieves data normalization but, more importantly, provides machine-readable structured data for subsequent statistical analysis.

[0078] In response to the diverse formats and high degree of unstructured nature of host logs, this system adopts the Drain3 algorithm to achieve intelligent parsing and template processing of host logs.

[0079] Drain3, as a high-efficiency online log parsing algorithm, groups similar logs into a unified template through clustering, effectively separating log parameters from the template.

[0080] Each host log entry is parsed into two parts by Drain3: a template identifier and a parameter list.

[0081] Template section: Represents the fixed structure and event types of the log;

[0082] Example: Process started: name={}, pid={}, user={};

[0083] Template ID: HOST_PROCESS_START_001;

[0084] Parameter section: Contains specific variable value information;

[0085] Parameter list: ['nginx', '1234', 'root'];

[0086] Parameter type detection: string, number, path, etc.

[0087] This separation mechanism allows the template to represent the semantic essence of the log, facilitating pattern recognition. At the same time, the parameters retain specific execution details, supporting fine-grained analysis.

[0088] To prevent overfitting or catastrophic forgetting during model fine-tuning, an upper limit is set on the number of generated logs, template IDs, and parameter data sets based on the number of templates; in some instances, this limit is 100,000 records. Then, the logs, template IDs, and parameter data sets are used to construct a fine-tuning dataset that maps template IDs and parameter data back to the original logs, and this dataset is divided into training and test sets. A log restoration task is then set up to fine-tune the large model.

[0089] To further enhance the model's judgment accuracy and achieve high-precision judgment under low resource conditions, while also considering multi-scenario adaptability, after distilling and fine-tuning the model, binary classification (normal / abnormal) datasets were constructed using different types of log data (such as firewall traffic logs, Apache service logs, MySQL service logs, Linux host logs, Windows security logs, etc.). LoRa fine-tuning was then performed on each dataset to form different LoRa modules. Since the structural features of different logs vary significantly, LoRa fine-tuning can guide the model to improve its feature attention to abnormal logs, thereby achieving the goal of accurate judgment. At the same time, due to the characteristics of low-rank LoRa fine-tuning, the training speed is fast and the deployment resource consumption is low, meeting the operation and maintenance needs of multiple scenarios under low resource conditions.

[0090] After knowledge distillation, template injection fine-tuning, and LoRa fine-tuning for multiple log types, the large model has acquired powerful analytical capabilities. Using a single-base, multi-LoRa deployment technique, the distilled and fine-tuned large model is used as the base model, its weights are frozen, and the LoRa module is invoked as needed.

[0091] Step S6: Based on the enhanced log stream from Step S4, to guide the model to output judgment results according to the logic of "step-by-step reasoning and evidence support," a structured prompt word template and a multi-round thinking chain (COT) analysis mechanism are designed. At the same time, based on the characteristics of the log stream, the log stream type is determined, and the corresponding LoRa module is called to quickly and accurately respond to different judgment needs. Finally, the judgment results are enhanced before generation, and the MITRE ATT&CK model is called to further analyze the attack stage and the root cause, and finally a comprehensive analysis report is output.

[0092] In some instances, cue word construction employs a four-round COT analysis: feature extraction → anomaly detection → cross-log correlation → comprehensive reporting. Specifically, the feature extraction and anomaly detection stages invoke different LoRa modules based on log stream characteristics for judgment, while the cross-log correlation and comprehensive reporting stages utilize the base model for analysis.

[0093] Feature extraction focuses on aligning significant behavioral tendencies exhibited by log streams based on log stream attributes and samples. For example, given basic statistics of input traffic / host logs, the model outputs a preliminary judgment on "whether there are anomalies," such as identifying the "high-frequency port scanning" feature in traffic log analysis.

[0094] Anomaly detection focuses on aligning log flow behavior with different stages of the ATT&CK model. For example, based on the first round of conclusions, it focuses on anomaly details such as "Which IPs exceeded the communication frequency limit? What are the common characteristics of the rejected connections?" The model outputs specific anomalous IPs and behavioral patterns.

[0095] Cross-log correlation focuses on retrieving dialogue history and performing joint analysis on different types of log streams to further uncover clues such as potential lateral movement and penetration attacks. For example, by linking traffic with host logs, it can determine whether "abnormal traffic triggers abnormal host processes? Can abnormal host processes be associated with specific network connections?" The model outputs a partial link of the attack chain.

[0096] The comprehensive analysis focuses on integrating the dialogue history, combining the conclusions of the first three rounds, conducting a comprehensive analysis according to the MITRA ATT&CK model, and providing countermeasures. It generates a standardized report that includes a "complete description of the attack chain, risk level, and defense recommendations," such as "Attack path: external IP → vulnerability intrusion → lateral movement → data theft, risk level: high risk, recommendation: block IP + upgrade vulnerability patches."

[0097] Step S7: When there are changes in the network environment or adjustments to network security logs, the knowledge base can be updated as needed, or LoRa modules can be added or deleted to avoid retraining the model and improve the efficiency of operation and maintenance updates.

[0098] In summary, by utilizing large-scale models to analyze network security alarm log data, we can deeply analyze the abnormal network security behaviors present in different log streams. Compared with traditional methods, this approach further delves into the deeper-level security anomalies that may be indicated by alarms, thereby significantly improving the accuracy of alarm analysis, reducing false alarm rates, and helping network security operations personnel to more accurately locate and resolve network security issues. Furthermore, by adopting a lightweight large-scale model and a single-base, multi-LoRa deployment architecture, along with knowledge enhancement and injection throughout the process, we can accurately and efficiently perform network security analysis and processing on alarm log data, meeting the dual requirements of real-time performance and accuracy for system operations and maintenance, and effectively improving the efficiency of security operations and maintenance.

[0099] This embodiment's method aggregates and analyzes log data (steps S2 and S3) to form a large model input sequence. Through model distillation, fine-tuning, and deployment of multiple LoRa modules, and through multiple rounds of analysis (four rounds of COT analysis), it achieves accurate discrimination and provides detailed reports and countermeasures. Compared with traditional large model-driven alarm log analysis methods, this embodiment can significantly reduce deployment and training costs while maintaining high-precision judgment.

[0100] To systematically verify the functional integrity, performance stability, and practical adaptability of the intelligent analysis system for network security alarm logs, the following sections were tested throughout the entire process. All test steps were designed based on actual network security operation and maintenance scenarios to ensure that the results truly reflect the application performance of various scenarios.

[0101] This embodiment of the system adopts a lightweight architecture design, with the core objective of lowering the deployment threshold and adapting to the hardware resource conditions of small and medium-sized security operations teams, while ensuring the efficiency of multi-model parallel inference. The deployment plan clarifies hardware requirements from two dimensions: "minimum availability" and "recommended optimization," and provides a standardized deployment process to ensure rapid implementation.

[0102] The system hardware requirements focus on balancing "graphics memory usage - inference efficiency", and the following configuration standards are formulated in combination with the model size.

[0103] Table 1 Configuration Standards

[0104]

[0105] Note: The system does not support AMD GPUs, and you must ensure that the GPU supports CUDA 11.8 or above to avoid model loading failure.

[0106] The test dataset is built based on "controllable attack scenarios + real background traffic". It simulates five typical network attacks through the Cyberbit test range, while injecting normal office traffic to create noise, ensuring that the dataset covers the characteristics of "high noise, multiple scenarios, and large volume", which is consistent with the characteristics of actual operation and maintenance data.

[0107] Referring to the MITRE ATT&CK framework, five types of attack scenarios that enterprises frequently encounter are selected. For each scenario, clear attack steps and targets are designed to ensure that the logs have "attack chain integrity".

[0108] Table 2 Attack steps and targets for each scenario

[0109]

[0110] Alarm analysis capability is a direct reflection of the system's core value. This section focuses on three dimensions: "analysis accuracy, scenario adaptability, and inference efficiency." Through three levels of verification—basic analysis result statistics, comparative experiments with and without LoRA module, and multi-scenario performance testing—it quantitatively evaluates the system's log analysis capability for different attack scenarios. At the same time, it analyzes the effect of LoRA lightweight fine-tuning on improving model performance.

[0111] Based on log stream data from six attack scenarios, the system automatically outputs the number of alarms, risk level scores (0-5 for low risk, 5-8 for medium risk, and 9-10 for high risk), and the time taken to analyze a single alarm. It also combines manually labeled "real threat tags" to determine the achievement of the target (i.e., the alarm score matches the actual threat level and can accurately locate key links in the attack chain).

[0112] The specific statistical results are shown in Table 3 below.

[0113] Table 3 Statistical Results

[0114]

[0115] Based on the alarm analysis results, the situation is as follows:

[0116] 1) Real attack alert:

[0117] The scoring accurately reflects the actual threat level. In all scenarios, the scoring of the real attack alert precisely matches the threat level.

[0118] The core attack for web page tampering, Alert7 (malicious script upload), is rated 9 points (high risk), and Alert8 (web page tampering behavior) is rated 8 points (medium risk), which fully meet the actual risks of "Apache file upload vulnerability exploitation".

[0119] The core attack of the FTP database breach, Alert7 (which exploits a Proftpd vulnerability to gain privileges), is rated 9 (high risk), consistent with the deadly threat of "database data theft".

[0120] Alert1 (remote control Trojan implantation), a real attack targeting corporate espionage, is rated 8 points (medium risk), accurately corresponding to the risk of the "intrusion preparation before lateral movement" stage.

[0121] 2) Non-aggressive Alert:

[0122] The scores were significantly reduced to avoid overestimating non-attack alerts (those that did not achieve the attack objective or were mistakenly triggered by benign operations). All scores were controlled at low risk (≤5 points) or reasonable medium risk (no overestimation is considered high risk).

[0123] In the web page tampering incident, non-attacking Alert3 / 5 / 6 / 10 (port scan repeated alerts) were all rated 5 points (low risk), and none were falsely judged as 6 points or higher.

[0124] The non-attack Alert2 (port scan alert) without file attacks is rated 5 points (low risk), avoiding misjudgment of attack behavior.

[0125] The non-attack Alerts 1 / 4 / 5 / 6 (port scan alerts) for FTP data breach attacks all scored 5 points (low risk), and no incorrect judgments were found.

[0126] In the six scenarios, the accuracy rate of the real attack alert reached 100% (all six real attacks were correctly identified as medium to high risk), indicating that the system's ability to capture the core characteristics of attack behavior is reliable.

[0127] The false positives for Apache service shutdown (100% false positive rate for non-attack alerts) and enterprise spying attacks (100% false positive rate for non-attack alerts) stem from the ambiguity of log features in two scenarios: the former overlaps with brute-force attack features in SSH login failure logs, and the latter Windows host logs are not fully collected through Syslog, resulting in missing context.

[0128] The average accuracy rate of the six scenarios was 57.1%, providing a "baseline performance" reference for subsequent model comparison and ablation experiments.

[0129] To quantitatively verify the advantages of this embodiment in both the accuracy and efficiency of alarm analysis, four commonly used comparison models in the industry were selected: the general model GPT5-mini, the security-specific model Secgpt-1.5b, and the general model Qwen3-1.7b. Under the same hardware environment (NVIDIA RTX4090 GPU, Intel i7-13700K CPU) (GPT5 is not open source, so the test was conducted using API calls), a comparative experiment was carried out focusing on "scoring accuracy" and "time balance".

[0130] Experimental data focuses on the comparison of core models.

[0131] The real threat labels are manually labeled (real attack alerts must meet the criteria of "medium to high risk, score 5-10", and non-attack alerts must meet the criteria of "low risk, score ≤5").

[0132] The core data comparison is shown in Table 4.

[0133] Table 4 Comparison of Core Data

[0134]

[0135] Analyzing Table 4, it can be clearly seen that this embodiment achieves accurate identification in all scenarios. However, in some scenarios, the score was set to 8 points because no real evidence of intrusion was found. At the same time, there are strong differences in the identification of non-real alarms.

[0136] Table 5 Statistical calculations of the accuracy, false alarm rate, and false negative rate of each model.

[0137]

[0138] Overall, this embodiment demonstrates a high degree of balance between alarm analysis accuracy and false alarm rate.

[0139] Testing the alarm analysis time of each model shows that this embodiment has significant advantages.

[0140] By integrating multiple LoRA and RAG models, the contradiction between the lack of domain knowledge in general models and the insufficient adaptation of special models to specific scenarios is resolved, and the accuracy is improved by 7.1%-18.2% compared with similar models.

[0141] LoRA's low-rank matrix update achieves a triangular balance of "precision-efficiency-resources", reducing memory usage by 87.1% and time consumption by 81.8% compared to full-scale fine-tuning.

[0142] With similar parameter counts, Qwen3-1.7b and SecGPT-1.5B have a false positive rate (52.8%) that is 2.1 times higher than Mine (25.0%) due to the lack of security domain optimization, proving the core proposition that "domain adaptation is more important than parameter count".

[0143] Based on the above data, the core performance indicators of the two models were calculated to further verify the value of LoRA fine-tuning. The results are as follows: Figure 3 As shown.

[0144] The LoRA module achieves "single-base multi-scenario adaptation" without compromising the security knowledge of the base model through the parameter efficient fine-tuning (PEFT) technology. This not only solves the maintenance cost problem of the traditional "one scenario, one model" approach, but also ensures real-time performance through lightweight computing. It is the core support for the system's "precise, efficient, and low-resource" characteristics.

[0145] RAG (Real-Agent Programming) links host vulnerability characteristics with network topology to achieve accurate identification. Without RAG information, the system scoring becomes unstable and accuracy drops significantly due to a lack of supporting knowledge. For example... Figure 4 As shown.

[0146] To ensure the model maintains scoring accuracy under concurrent multi-scenario conditions, the scoring fluctuation and resource consumption of six attack scenarios were tested under the recommended hardware configuration (NVIDIA RTX 4090 GPU, 64GB DDR5 memory). The results are shown in Table 6 below.

[0147] Analyze 100 duplicate log streams from the same attack scenario and calculate the standard deviation of the LoRA model score (the smaller the deviation, the more stable the system).

[0148] The standard deviation of the scores for all scenarios is <1.3, indicating that the LoRA-tuned model scores stably in repeated scenarios without any "random overestimation / underestimation", and its accuracy is reusable.

[0149] During testing, resource usage was monitored using NVIDIA-SMI and htop:

[0150] GPU memory usage is only 4.5GB after loading the LoRA model (including Qwen3-1.7b base + 3 LoRA modules), which is only 140% higher than the model without LoRA (3.2GB), and supports parallel analysis in multiple scenarios;

[0151] CPU utilization: The peak CPU logic core utilization was 18% (12 / 64 cores) during single-scenario analysis and 42% (27 / 64 cores) during multi-scenario concurrency, with no scoring delay caused by resource preemption;

[0152] Memory usage: The peak memory usage for log stream processing and model inference is 18.7GB, which is only 29.2% of the 64GB memory, leaving enough space for log storage and temporary computation.

[0153] Taking a web tampering attack scenario as an example, the system's average analysis time is only 15.49 seconds, which is 88.8% less than the basic model (139.18 seconds). The core reason is that the fine-tuned system selectively enables the CoT mode, only entering deep thinking in non-explicit discrimination states. At the same time, the dedicated LoRA module preloads scenario-based features, shortening the model's recognition time for key features.

[0154] Even for high-risk alerts, the processing time is still controllable. For high-risk alerts that require multiple rounds of reasoning (such as Alert7 and Alert8), the processing time is still controlled within 30 seconds. However, when using the basic model to process high-risk alerts, the processing time generally exceeds 200 seconds because the attack characteristics need to be relearned, which poses a risk of attack spread.

[0155] The LoRA module achieves the highest reduction in time (over 90%) for non-attack-based alerts (such as Alert3 and Alert6) because it can quickly match "low-risk feature templates" (such as port scans and recurring alarms) and complete the scoring without complex reasoning, further reducing the overall computational pressure on the system.

[0156] Table 6 Standard Deviation of LoRA Model Scores

[0157]

[0158] Example 2

[0159] Embodiment 2 of the present invention provides a terminal device corresponding to Embodiment 1 above. The terminal device can be a processing device for a client, such as a mobile phone, a laptop, a tablet computer, a desktop computer, etc., to execute the method of the above embodiments.

[0160] The terminal device in this embodiment includes a memory, a processor, and a computer program stored in the memory; the processor executes the computer program in the memory to implement the steps of the method in Embodiment 1 described above.

[0161] In some implementations, the memory may be high-speed random access memory (RAM), and may also include non-volatile memory, such as at least one disk storage device.

[0162] In other implementations, the processor can be any type of general-purpose processor, such as a central processing unit (CPU) or a digital signal processor (DSP), and there is no limitation here.

[0163] Example 3

[0164] Embodiment 3 of the present invention provides a computer-readable storage medium corresponding to Embodiment 1 above, on which a computer program / instructions are stored. When the computer program / instructions are executed by a processor, they implement the steps of the method of Embodiment 1 above.

[0165] A computer-readable storage medium can be a tangible device that holds and stores instructions for use by an instruction execution device. A computer-readable storage medium can be, for example, but not limited to, an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any combination thereof.

[0166] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. The solutions in the embodiments of this application can be implemented in various computer languages, such as the object-oriented programming language Java and the interpreted scripting language JavaScript.

[0167] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0168] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0169] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0170] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for intelligent analysis of network security alarm logs, characterized in that, Includes the following steps: S1. Receive alarm information generated by the SIEM system and extract key information from the alarm information; S2. Based on the key alarm information, collect log sets from the log server, collect relevant logs for the corresponding IP within a specified time period, and form a log sequence; S3. The collected log sequence is divided into different subsequences according to time interval and IP address, and the log feature information of the subsequences is extracted to construct a log stream sequence; S4. Enhance the security information of the log stream sequence by adding network location and security vulnerability information to the log stream sequence; S5. Query the host information and security vulnerability information involved in the log stream in the knowledge graph, and input the log stream with enhanced security information into the large model for discrimination; the large model is deployed in the form of a single base model and multiple LoRa modules; S6. Based on the log stream after security information enhancement, construct prompt words step by step, call different LoRa modules for analysis, enhance the analysis results before generation, call the MITRE ATT&CK model to further analyze the attack stage and root cause, and output a comprehensive analysis report.

2. The intelligent analysis method for network security alarm logs according to claim 1, characterized in that, The specific implementation process of step S1 includes: the SIEM system monitors Syslog and firewall information in real time. Syslog is deployed in a distributed manner in the network to monitor logs from various systems and services and traffic logs provided by the firewall. The SIEM system sets relevant rules, triggers the generation of alarm information after detecting anomalies, and records the time of occurrence, end time, source IP address, and destination IP address of the network attack. After receiving the alarm information, the key information is extracted.

3. The intelligent analysis method for network security alarm logs according to claim 1, characterized in that, In step S2, an IP address pool is established using the attack source IP address and the attack destination IP address. Logs corresponding to the time window are selected by traversing the IP pool and sorted by time to establish a log sequence grouped by IP. The time window is {t1-te, t2+te}, where t1 is the attack start time, t2 is the attack end time, te is the log quantity evaluation extension time within the time period ta, and ta is the attack duration.

4. The intelligent analysis method for network security alarm logs according to claim 1, characterized in that, In step S3, the specific construction process of a single log stream in the log stream sequence includes: Iterate through the timestamps of log entries in the log sequence and group logs that are longer than a set time interval. The logs are templated using a log template extraction method to obtain a set of templates. Save the template sequence number and parameter value. At this time, the log sequence is represented by log sequence grouping by time interval, which is represented by log template sequence number and parameter value. The number of logs, template distribution, and duration of each log sequence are counted to form log sequence attributes, which constitute a single log stream.

5. The intelligent analysis method for network security alarm logs according to claim 1, characterized in that, In step S5, the training process of the large model includes: The log sequences are input into the teacher model in batches to generate soft labels containing threat type probability distribution, risk level weight, and root cause analysis; a set proportion of samples in the log sequences are labeled as hard labels; a log sequence attribute-soft label-hard label ternary dataset is constructed to obtain the distillation dataset; the log sequence attributes include the number of logs in a single log sequence, template distribution, and duration; The distillation dataset is used as input to the student model to train the student model, resulting in the trained student model. All logs in the log pool are templated, and the templated logs are used as input to the trained student model to fine-tune the trained student model. Normal datasets or abnormal datasets are constructed using different categories of log data. These normal datasets or abnormal datasets are then used as inputs to a fine-tuned student model. The fine-tuned student model is then subjected to LoRa fine-tuning to form different LoRa modules.

6. The intelligent analysis method for network security alarm logs according to claim 5, characterized in that, The loss function of the student model Represented as: ;in, Represents cross-entropy loss, For student model prediction results, Classification error of hard labels For hyperparameters, KL divergence is used to measure the distribution of the teacher model output. Student model distribution The difference is expressed by the formula: , where i is the sample number in the distillation dataset.

7. The intelligent analysis method for network security alarm logs according to claim 1, characterized in that, Also includes: When there are changes in the network environment or adjustments to the network security logs, the enhanced security information log stream can be updated as needed, or the Lora module can be added or removed.

8. A terminal device, comprising a memory, a processor, and a computer program stored in the memory; characterized in that, The processor executes the computer program to implement the steps of the method according to any one of claims 1 to 7.

9. A computer-readable storage medium having a computer program / instructions stored thereon; characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method described in any one of claims 1 to 7.

Images