Threat assessment and attack source banning method and system for security log event

Threat scores are calculated by multiplying device type weights and event severity coefficients, and the sum of threat scores within a sliding time window and the upper M quantile are used as dynamic blocking thresholds. This solves the problem of insufficient blocking accuracy in cross-device log events and achieves efficient and accurate threat assessment and blocking.

CN121333743APending Publication Date: 2026-01-13BEIJING YOUTEJIE INFORMATION TECH
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202511625145.5
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-11-07
Publication Date
2026-01-13

AI Technical Summary

Technical Problem

Existing technologies lack the ability to uniformly quantify threat scores and dynamically adjust blocking thresholds for security log events across vendors and devices, resulting in insufficient blocking accuracy. This is especially true in complex and ever-changing network attack scenarios, where missed or false blocking is likely to occur.

Method used

Threat scores are calculated by multiplying device type weights and event severity level coefficients, and then accumulated within a sliding time window. Combined with the M quantile as a dynamic blocking threshold, unified quantitative assessment and adaptive blocking across device logs are achieved.

Benefits of technology

It improves the accuracy of blocking, reduces the false alarm rate, enables a more comprehensive assessment of the threat level of IPs, and ensures that high-threat IPs are prioritized through adaptive adjustments, thereby improving overall operational efficiency.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121333743A_ABST
    Figure CN121333743A_ABST
Patent Text Reader

Abstract

The invention discloses a threat assessment and attack source banning method and system for security log events, and the method comprises the steps: obtaining log events from a plurality of heterogeneous security devices, and determining a target log event matched with a predefined attack event type; based on the product of the equipment type weight corresponding to the target log event and the event type severity level coefficient, determining the threat score of the target log event, and accumulating the threat scores of all target log events belonging to the same first attack source IP in the current preset sliding time window to obtain the comprehensive threat score of the first attack source IP; determining the upper M quantiles of the comprehensive threat scores of all attack source IPs in the current preset sliding event window as a dynamic banning threshold, wherein M is greater than or equal to 3; and if the comprehensive threat score of the first attack source IP is greater than or equal to the dynamic banning threshold, triggering a banning process of the first attack source IP. Therefore, the upper M quantiles are adopted as the dynamic banning threshold value, and the banning standard is automatically adjusted based on the current attack situation.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of network and information security technology, and in particular to a method and system for threat assessment and attack source blocking of security log events. Background Technology

[0002] As enterprise IT architectures become more cloud-based and complex, various types and vendors of security devices (such as Web Application Firewalls (WAF), Intrusion Prevention Systems (IPS), and Intrusion Prevention Systems (IDS)) are widely deployed at network boundaries and within the network. These devices continuously generate massive amounts of security log events with heterogeneous formats.

[0003] Currently, mainstream technical solutions for automated threat response based on such logs generally employ a blocking decision mechanism that relies on manually preset static thresholds. This means that whether to block an event depends on whether its score exceeds a pre-defined fixed threshold. However, this fixed-threshold-based decision-making rule is too simplistic and rigid when dealing with complex and ever-changing network attack scenarios, lacking the ability to dynamically adjust based on the overall attack intensity.

[0004] Therefore, how to dynamically adjust the blocking threshold based on the real-time attack situation and improve the accuracy of blocking when implementing unified threat quantification scoring across vendors and devices is a key research topic for those skilled in the art. Summary of the Invention

[0005] Firstly, this application provides a method for threat assessment and attack source blocking of security log events. The method includes: acquiring log events from multiple heterogeneous security devices; determining target log events matching predefined attack event types; determining a threat score for the target log event based on the product of the device type weight and the event type severity coefficient corresponding to the target log event, wherein the device type weight is related to the detection reliability and importance of the security device source of the log event, and the event type severity coefficient is related to the severity of the event type of the log event; accumulating the threat scores of all target log events belonging to the same first attack source IP within a current preset sliding time window to obtain a comprehensive threat score for the first attack source IP, wherein the first attack source IP is the attack source IP corresponding to any log event belonging to the target log event; determining the upper M quantile of the comprehensive threat score of all attack source IPs within the current preset sliding event window as a dynamic blocking threshold, wherein the upper M quantile is used to indicate the presence of attacks in the comprehensive threat score of all attack source IPs within the current preset sliding event window. The proportion data is less than the upper M quantile, and there is... The weighted data is greater than or equal to the upper M quantile, where M is an integer greater than or equal to 3; if the comprehensive threat score of the first attack source IP is determined to be greater than or equal to the dynamic blocking threshold, the blocking process for the first attack source IP is triggered.

[0006] The threat assessment and attack source blocking method for security log events provided in this application employs, on the one hand, the upper M quantile as a dynamic blocking threshold, enabling the system to automatically adjust blocking standards based on the current attack situation, thus resolving the technical shortcomings of static thresholds in missing or mistakenly blocking attacks when attack intensity fluctuates. Furthermore, through adaptive adjustment, high-threat IPs are prioritized for processing, improving overall operational efficiency.

[0007] On the other hand, by calculating the threat score through the product of device type weight and event severity level coefficient, a unified quantitative assessment of logs from different security devices is achieved, overcoming the problem of inconsistent threat assessment caused by device heterogeneity in traditional solutions.

[0008] On the other hand, by accumulating threat scores for the same IP within a sliding time window, persistent, low-frequency compound attacks can be effectively identified, significantly reducing the false positive rate compared to detection methods based on single events. Accumulating scores for each event based on its device weight and severity level allows for a more comprehensive assessment of the IP's threat level.

[0009] In some possible implementations, M is set to 4, and determining the upper M quantile of the comprehensive threat score of all attack source IPs within the current preset sliding event window as the dynamic blocking threshold includes: determining a sample set based on the non-zero comprehensive threat score of all attack source IPs within the current preset sliding time window, wherein the elements in the sample set are arranged in ascending order according to the threat score value; based on the formula: The position pos of the upper quartile is determined, where n is the number of elements in the sample set; if pos is an integer, the comprehensive threat score of the sample set relative to the position pos is used as the upper quartile; if pos is not an integer, linear interpolation is used based on the formula: Determine the upper quartile. , wherein The integer part of pos, the The decimal part of pos is used; the upper quartile is used as the dynamic blocking threshold.

[0010] This approach achieves several advantages. First, it uses the upper quartile (Q3) as the threshold benchmark to ensure that the system always focuses on the most dangerous 25% of attack sources. Second, it uses the formula pos=(3*n+1) / 4 to determine the position of the upper quartile, avoiding the influence of extreme values ​​on the threshold. Third, it uses linear interpolation to handle non-integer positions, improving the accuracy of threshold calculation.

[0011] In some possible implementations, acquiring log events from multiple heterogeneous security devices includes: collecting raw security log events from the multiple heterogeneous security devices; performing field standardization processing on the raw security log events, mapping similar semantic fields in logs from different sources to unified field names; and mapping the event names of target log events in the log events of each security device to standardized general event type names based on a predefined event type mapping table, wherein the event type mapping table is used to represent the correspondence between specific log events of different security devices for the same attack behavior and standard event type names.

[0012] This approach addresses two key challenges. First, by standardizing fields and mapping event types, it solves the technical challenge of semantic heterogeneity in logs from multiple vendors. Second, the event type mapping table, as a configurable resource, enables the system to quickly adapt to new security devices without modifying the core code, thus reducing maintenance costs.

[0013] In some possible implementations, the plurality of heterogeneous security devices include a web application firewall (WAF), an intrusion prevention system (IPS), and an intrusion prevention system (IDS). The device type weight corresponding to log events originating from the WAF is a first weight, the device type weight corresponding to log events originating from the IPS is a second weight, and the device type weight corresponding to log events originating from the IDS is a third weight. The first weight is greater than the second weight, and the second weight is greater than the third weight.

[0014] This approach, using a weighted ranking of WAF > IPS > IDS, quantifies the differences in detection reliability among various security devices, accurately reflecting the detection precision and confidence level of each type of device. This allows alarms from high-reliability devices to receive higher weight, improving the accuracy of the scoring. Furthermore, prioritizing devices with high detection precision avoids excessive influence from alarms from low-reliability devices on decision-making, reducing unnecessary blocking operations while ensuring security effectiveness.

[0015] In some possible implementations, the log event types include high-risk event types, medium-risk event types, and low-risk event types. The severity coefficient of the event type corresponding to the high-risk event type is the first coefficient, the severity coefficient of the event type corresponding to the medium-risk event type is the second coefficient, and the severity coefficient of the event type corresponding to the low-risk event type is the third coefficient. The first coefficient is greater than the second coefficient, and the second coefficient is greater than the third coefficient.

[0016] This approach, by setting coefficients for high-risk > medium-risk > low-risk, accurately reflects the actual degree of harm of different attack behaviors, enabling serious attacks to receive higher threat scores and ensuring that key threats are prioritized for handling.

[0017] In some possible implementations, the process of triggering the blocking of the first attack source IP includes: issuing a blocking instruction for the first attack source IP to a preset boundary security device through a standardized application programming interface. The blocking instruction includes the first attack source IP address, the blocking action, the blocking duration, and the blocking reason.

[0018] This approach offers two advantages. First, by standardizing API interfaces, it unifies the method of issuing blocking commands to different perimeter security devices, resolving the issue of heterogeneous interfaces across multiple vendors and improving system integration. Second, the blocking commands contain complete information such as IP address, action, duration, and reason, ensuring accuracy and traceability in execution.

[0019] In some possible implementations, after triggering the blocking process against the first attack source IP, the method further includes: writing the comprehensive threat score details that triggered the blocking instruction, dynamic blocking threshold information, the blocking instructions related to this blocking process, and the blocking result as audit logs into an index storage system to form a feedback loop for the blocking operation. This approach records the entire blocking decision process through audit logs, providing a data foundation for subsequent analysis and optimization (e.g., detailed scoring details and threshold information provide key data for optimizing weighting coefficients and threshold algorithms), forming a complete operational closed loop from execution to feedback to optimization.

[0020] Secondly, this application also provides a threat assessment and attack source blocking system for security log events, the system comprising: The data acquisition module is used to acquire log events from multiple heterogeneous security devices; The log matching module is used to identify target log events that match predefined attack event types; The threat scoring module is used to determine the threat score of the target log event based on the product of the device type weight and the event type severity coefficient corresponding to the target log event. The device type weight is related to the detection reliability and importance of the security device source of the log event, and the event type severity coefficient is related to the severity of the event type of the log event. The threat scoring module is also used to accumulate the threat scores of all target log events belonging to the same first attack source IP within the current preset sliding time window to obtain the comprehensive threat score of the first attack source IP, where the first attack source IP is the attack source IP corresponding to any log event belonging to the target log event. The dynamic blocking threshold calculation module is used to determine the upper M quantile of the comprehensive threat score of all attack source IPs within the current preset sliding event window as the dynamic blocking threshold. The upper M quantile is used to indicate the presence of attacks in the comprehensive threat score of all attack source IPs within the current preset sliding event window. The proportion data is less than the upper M quantile, and there exists The proportion data is greater than or equal to the upper M quantile, where M is an integer greater than or equal to 3; The blocking execution module is used to trigger an automatic blocking process for the first attack source IP when it is determined that the comprehensive threat score of the first attack source IP is greater than the dynamic blocking threshold.

[0021] Thirdly, this application also provides a threat assessment and attack source blocking device for security log events, including a unit for performing any of the threat assessment and attack source blocking methods for security log events in the first aspect.

[0022] Fourthly, this application also provides a computer storage medium that can store multiple instructions, which are adapted to be loaded by a processor and executed by the threat assessment and attack source blocking method for any of the security log events in the first aspect.

[0023] Fifthly, embodiments of this application also provide a computer program product containing instructions that, when the computer program product is run on an electronic device, cause the electronic device to execute any of the security log events threat assessment and attack source blocking methods in the first aspect.

[0024] In a sixth aspect, embodiments of this application also provide a chip module, including a transceiver component and a chip, wherein the chip is used to perform any of the security log events threat assessment and attack source blocking methods in the first aspect.

[0025] It is understood that the aforementioned threat assessment and attack source blocking devices, systems, computer storage media, computer programs, computer program products, and chip systems for security log events are all used to execute the method shown in any implementation of the first aspect of the embodiments of this application. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects in the corresponding methods, and will not be repeated here. Attached Figure Description

[0026] Figure 1 This is a flowchart illustrating a method for threat assessment and attack source blocking of security log events provided in an embodiment of this application. Figure 2 This is a schematic flowchart of a method for obtaining raw security log events and performing standardized processing according to an embodiment of this application; Figure 3 This is a flowchart illustrating a process for issuing blocking commands to high-threat attack source IPs and recording audits, as provided in an embodiment of this application. Figure 4 This is a schematic diagram of the architecture of a security log event threat assessment and attack source blocking system provided in an embodiment of this application; Figure 5 This is a schematic diagram of a security log event threat assessment and attack source blocking device provided in an embodiment of this application. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described below in conjunction with the accompanying drawings.

[0028] It should be noted that this application embodiment uses an electronic device as an example to illustrate the execution subject of the threat assessment and attack source blocking method for security log events provided in this application. This electronic device can also be understood as the threat assessment and attack source blocking device or system for security log events shown in this application embodiment. In this application embodiment, the electronic device can be a microprocessor or computer for executing program code, etc. Any electronic device that can be used to execute the method provided in this application embodiment is within the protection scope of this application embodiment, and this application does not impose any limitations. For example, the electronic device can be a desktop computer, a laptop, a mobile terminal, a 32-bit microprocessor, or a 64-bit microprocessor, etc., and this application embodiment does not limit this.

[0029] Please see Figure 1 , Figure 1 This document presents a flowchart illustrating a method for threat assessment and attack source blocking of security log events, as provided in an embodiment of this application. Figure 1 As shown, the threat assessment and attack source blocking method for this security log event includes the following steps: S101, the electronic device acquires log events from multiple heterogeneous security devices.

[0030] As an example, step S101 specifically includes: S1011 collects raw security log events from multiple heterogeneous security devices.

[0031] Specifically, electronic devices access raw log streams from various security devices at the enterprise boundary and within the enterprise in real time through data caching services, building a high-throughput, low-latency data pipeline.

[0032] S1012 performs field standardization processing on the original security log events, mapping similar semantic fields in logs from different sources to unified field names.

[0033] During log stream processing, electronic devices perform field standardization on logs, mapping similar semantic fields from logs from different sources to unified field names. For example, the fields that need to be standardized, and the standardized field names and data types, are including but not limited to those shown in Table 1 below.

[0034] Table 1 S1013, based on a predefined event type mapping table, maps the event names of specific log events in the log events of each security device to standardized general event type names.

[0035] In this embodiment, the event type mapping table is used to represent the correspondence between specific log events of different security devices for the same attack behavior and standard event type names. Specifically, after the electronic device unifies the field name "event_type" in step S1012, it further processes the specific values ​​in this field. Different names used by different devices for the same attack behavior are mapped to a unified, standard attack type name.

[0036] As an example, the original event names of the device and the event type names after standardization mapping are including, but not limited to, those shown in Table 2 below.

[0037] Table 2 S102, the electronic device determines a target log event that matches a predefined attack event type.

[0038] As an example, the electronic device determines that the target log event matches the predefined attack event type, including but not limited to: if the electronic device determines that the event type name of the reference log event after normalization mapping matches the event type name recorded in the above event type mapping table, then the reference log event is determined to belong to the target log event.

[0039] As another example, the electronic device determines that the target log event matches a predefined attack event type, including but not limited to: the electronic device determining that the reference log event belongs to the target log event if it confirms that the original event name of the reference log event is included in the preset attack event type name. For example, the preset attack event type name includes: the cross-site scripting attack event type name of the log event originating from WAF, the XSS attack event type name of the log event originating from IDS, the SQLi / SQL Injection attack event type name of the log event originating from WAF, and the Command Exec attack event type name of the log event originating from IPS.

[0040] S103, the electronic device determines the threat score of the target log event based on the device type weight and event type severity level coefficient of the target log event.

[0041] In this embodiment of the application, the device type weight and the event type severity level coefficient are customizable. The device type weight is related to the detection reliability and importance of the security device source of the log event, and the event type severity level coefficient is related to the severity of the event type of the log event.

[0042] In some possible implementations, the aforementioned heterogeneous security devices include, but are not limited to, web application firewalls (WAF), intrusion prevention systems (IPS), and intrusion detection systems (IDS). Among them, the device type weight corresponding to log events from WAF is the first weight, the device type weight corresponding to log events from IPS is the second weight, and the device type weight corresponding to log events from IDS is the third weight. The first weight is greater than the second weight, and the second weight is greater than the third weight.

[0043] For example, the weight of the WAF device (first weight) is 1.0, the weight of the IPS device (second weight) is 0.8, and the weight of the IDS device (third weight) is 0.6.

[0044] In some possible implementations, the log event types include high-risk, medium-risk, and low-risk event types. The severity coefficient for the high-risk event type is a first coefficient, the severity coefficient for the medium-risk event type is a second coefficient, and the severity coefficient for the low-risk event type is a third coefficient. The first coefficient is greater than the second coefficient, and the second coefficient is greater than the third coefficient. For example, the high-risk event level coefficient (first coefficient) is 500, the medium-risk event level coefficient (second coefficient) is 100, and the low-risk event level coefficient (third system) is 10.

[0045] In this embodiment of the application, single event Threat scores satisfy the following formula 1, where, and These are the device type weight and event type severity level coefficient for the current event, respectively.

[0046] S104, the electronic device accumulates the threat scores of all target log events belonging to the same first attack source IP within the current preset sliding time window to obtain the comprehensive threat score of the first attack source IP.

[0047] In this embodiment of the application, the first attack source IP can be the attack source IP corresponding to any log event belonging to the target log event.

[0048] In this embodiment of the application, the comprehensive threat score of the first attack source IP (e.g., referred to as ip1) The following formula 2 is satisfied, where R is the number of target log events belonging to the same attack source IP (ip1) within the current preset time window. The threat score for the i-th event within the current preset sliding time window.

[0049] For example, the preset sliding time window can be a preset duration prior to the current time. The preset duration can include, but is not limited to, 5 minutes, 10 minutes, 15 minutes, and 30 minutes, and the specific value can be designed based on different business scenarios. In some possible implementations, the electronic device can also dynamically adjust the preset duration based on the current attack intensity, system load, and business sensitivity. For example, when the current attack intensity is high and the attack is intense, the sensitivity can be increased, that is, if the attack intensity of the previous period (the dynamic blocking threshold of the previous period) is determined to be greater than a preset fixed threshold, the preset duration can be reduced (e.g., from the default duration of 10 minutes to 5 minutes). For example, when the current load is high, the calculation frequency should be reduced, that is, if the current load is determined to be greater than a preset maximum load, the preset duration can be increased (e.g., from the default duration of 10 minutes to 15 minutes).

[0050] S105, the electronic device determines the upper M quantile of the comprehensive threat score of all attack source IPs within the current preset sliding event window as the dynamic blocking threshold, where M is an integer greater than or equal to 3.

[0051] In this embodiment, the upper M quantile is used to indicate the presence of [a specific threat] in the overall threat score of all attack source IPs within the current preset sliding event window. The proportion data is less than the upper M quantile, and there exists The weighted data is greater than or equal to the upper M quantile. Specifically, the upper M quantile is the value at the pos percentile position after the comprehensive threat scores of all attack source IPs in the current preset sliding event window are arranged from smallest to largest. This pos is related to M and n, where n is the number of non-zero comprehensive threat scores of all attack source IPs.

[0052] In some possible implementations, step S105 specifically includes: determining a sample set based on the non-zero comprehensive threat scores of all attack source IPs within the current preset sliding time window, wherein the elements in the sample set are arranged in ascending order according to the threat score values; determining the position pos of the upper N quantile based on formula 3 below, where n is the number of elements in the sample set; when pos is an integer, using the comprehensive threat score of the sample set relative to the pos position as the upper N quantile; when pos is not an integer, using linear interpolation based on formula 4 below to determine the upper N quantile. , among which, among which, It is the integer part of pos (rounded down). The decimal part of pos; the upper N quantiles As a dynamic blocking threshold.

[0053] As an example, with M set to 4, step S105 specifically includes: determining a sample set based on the non-zero comprehensive threat scores of all attack source IPs within the current preset sliding time window, with elements in the sample set arranged in ascending order of threat score values; determining the upper quartile position pos based on the following formula 5, where n is the number of elements in the sample set; when pos is an integer, using the comprehensive threat score of the sample set relative to the pos position as the upper quartile; when pos is not an integer, using linear interpolation based on the above formula 4 to determine the upper quartile. ; the upper quartile As a dynamic blocking threshold.

[0054] It should be noted that the formulas (Formulas 3 and 5) for calculating the position pos of the upper quartile shown in this article are merely examples. Other calculation methods can also be used, and this article does not limit them. For example, it can also be based on... The pos is determined, but this article does not impose any restrictions on it.

[0055] Understandably, with fixed thresholds, the static threshold may be too low during high-intensity attacks, leading to numerous false positives and negatives during low-intensity attacks, resulting in missed bans. This solution's dynamic blocking threshold method, through adaptive adjustment, prioritizes the handling of high-threat IPs, improving overall operational efficiency and mitigating the issues of false positives and negatives during low-intensity attacks, particularly regarding normal traffic or low-risk IPs.

[0056] In other possible implementations, to avoid false bans, a preset minimum attack threat score can be set. If the dynamic ban threshold for the current period is lower than this preset minimum attack threat score, then the preset minimum attack threat score is used as the dynamic ban threshold for the current period. For example, this approach can be applied to scenarios where, to ensure the integrity of security operations, the event type mapping table includes not only preset attack event types belonging to attack behaviors, but also other event types reflecting relatively healthy operations.

[0057] In other possible implementations, to avoid missed blocking, a preset high attack threat score can be set. If the dynamic blocking threshold for the current period is greater than the preset minimum attack threat score, then the preset high attack threat score is used as the dynamic blocking threshold for the current period. For example, this method can be applied to scenarios where a network-wide attack occurs. When the network suffers a large-scale, high-intensity attack, the threat scores of all attack source IPs are generally high, exceeding the preset high attack threat score, and therefore all of them are blocked.

[0058] S106, if the overall threat score of the first attack source IP is determined to be greater than or equal to the above dynamic blocking threshold, the blocking process for the first attack source IP is triggered.

[0059] In this embodiment, if the overall threat score of the first attack source IP is greater than or equal to the aforementioned dynamic blocking threshold, an automatic blocking process for the first attack source IP is triggered. If the overall threat score of the first attack source IP is less than the aforementioned dynamic blocking threshold, the blocking process for the first attack source IP is not triggered.

[0060] In some possible implementations, the electronic device triggers an automatic blocking process for the first attack source IP, specifically including: issuing a blocking instruction for the first attack source IP to a preset boundary security device through a standardized application programming interface (API). The preset boundary security device has the authority to directly discard data packets and / or interrupt the connection. The blocking instruction includes the first attack source IP address, the blocking action, the blocking duration, and the blocking reason.

[0061] As an example, such as Figure 3 As shown, the electronic device sends a blocking instruction to the preset boundary security device via API to target the first attack source IP. This includes: constructing a JSON format request containing the first attack source IP, blocking action, blocking duration, and blocking reason; and sending the blocking request to security devices such as firewalls (with protection layers of network and transport layers and protection objects of the entire network) via RESTful API.

[0062] Understandably, sending blocking requests to both the firewall and the WAF simultaneously reflects the concept of defense in depth. The firewall provides basic, broad-coverage network-layer protection, the WAF provides granular, specialized application-layer protection, and the IPS provides real-time, behavioral intrusion protection. This multi-layered, comprehensive blocking strategy ensures that even if one device fails, others can still provide protection. Establishing defenses at different levels increases the cost and difficulty for attackers.

[0063] Among some possible implementations, refer again Figure 3 After triggering the blocking process against the first attack source IP, the electronic device will also write the comprehensive threat score details of the blocking command, dynamic blocking threshold information, the blocking commands related to this blocking process, and the blocking result as audit logs into the index storage system to form a feedback loop for the blocking operation.

[0064] As an example, the feedback loop for blocking operations can be a closed loop of manual intervention. The comprehensive threat score details of the primary attack source IP can include the security device source, event type, and individual event threat score for each target log event that makes up the comprehensive threat score. The blocking command includes the specific blocking action and duration. Analysts can quickly locate and correct problems by auditing logs. For example, if it is found that a false alarm event from a certain IDS device caused the primary attack source IP to have a high threat score, the IP can be manually added to the whitelist, the block can be lifted, and the weight (W_d) of the IDS device can be reduced to prevent similar false alarms from triggering further blocking in the future. Additionally, the event type mapping table can be adjusted to remove false alarm events.

[0065] As another example, the feedback loop of the blocking operation can also be a machine learning and adaptive loop. In the machine learning model, the audit log is used as the training dataset. Specifically, the "scoring details" in the audit log is used as a feature, and "whether the blocking has been manually confirmed as effective" is used as a label. For example, the original event sequence includes: event1, 'device': 'WAF', 'severity': 'high', 'event_type': 'SQL Injection', label = 1 (where label = 1 indicates confirmed threat, label = 0 indicates false alarm, and label = 0.5 indicates uncertainty). The optimization objective is defined as automatically learning the optimal combination of weights W_d for each device type, severity level L_s for each event type, and M values ​​in the upper M quantile, so that the comprehensive threat score and dynamic blocking threshold can best predict the real threat. A loss function is also defined, which includes binary cross-entropy, false positive penalty (predicted as a threat when it is not actually a threat), and false negative penalty (predicted as a threat when it is actually a threat). Finally, the weights, coefficients, and M values ​​of the trained new model are deployed online to replace the old rules.

[0066] As enterprise IT architectures become increasingly cloud-based and complex, they deploy various types and vendors of security devices (such as WAF, IDS / IPS, firewalls, etc.) at network boundaries and internally to defend against network attacks. These devices generate massive amounts of security log events with heterogeneous formats. The core challenge for security operations teams lies in how to uniformly analyze this scattered and semantically inconsistent information and achieve efficient and accurate automated threat response. Currently, mainstream security platforms or solutions have the following shortcomings: 1) Splunk (including SOAR / ES modules): It lacks a built-in, unified quantitative scoring model to comprehensively evaluate the global threat level of attack sources; its blocking decisions mostly rely on single rules based on fixed thresholds, failing to achieve adaptive thresholds that are dynamically adjusted based on the overall attack situation. 2) IBM QRadar: Its automatic blocking function heavily relies on plugins developed for specific devices, limiting its versatility; its blocking logic is usually based on statically configured thresholds and lacks the ability to calculate dynamic thresholds based on statistical quantiles. 3) Elastic Stack: It provides field standardization capabilities through ECS, but to achieve unified scoring across devices, dynamic threshold determination, and closed-loop linkage, a large amount of custom development is required, and it does not provide out-of-the-box complete capabilities. In summary, existing technologies have significant gaps in achieving unified threat quantification scoring across vendors and devices, and in using adaptive statistical thresholds for automated, network-wide blocking based on this scoring.

[0067] The threat assessment and attack source blocking method for security log events provided in this solution achieves a unified quantitative assessment of logs from different security devices by calculating the threat score through the product of device type weight and event severity level coefficient, thus overcoming the problem of inconsistent threat assessment caused by device heterogeneity in traditional solutions.

[0068] On the other hand, the upper M quantile is used as the dynamic blocking threshold, which enables the system to automatically adjust the blocking standard based on the current attack situation, thus solving the technical defect of static thresholds that may result in missed or false blocking when the attack intensity fluctuates.

[0069] On the other hand, by accumulating threat scores for the same IP within a sliding time window, persistent, low-frequency compound attacks can be effectively identified, significantly reducing the false positive rate compared to detection methods based on single events. Accumulating scores for each event based on its device weight and severity level allows for a more comprehensive assessment of the IP's threat level.

[0070] As an example, the following is a specific implementation example of the threat assessment and attack source blocking method for security log events provided in this application.

[0071] 1) Test environment configuration - Data caching service: Deploy a 3-node highly available message queue cluster; - Computing engine: 2 servers with 8 cores and 16GB RAM; - Index storage system: 3-node distributed cluster; - Target blocking devices: Next-generation firewalls and cloud WAFs from mainstream brands.

[0072] 2) Test data sample 【1】{src_ip: '192.168.10.8', device: 'WAF', event_type: 'SQLInjection', severity: 'high', timestamp: '2025-10-22T10:00:00Z'}; 【2】{src_ip: '192.168.10.8', device: 'IDS', event_type: 'XSS', severity: 'medium', timestamp: '2025-10-22T10:01:10Z'}; 【3】{src_ip: '10.0.0.5', device: 'IPS', event_type: 'Port Scan', severity: 'low', timestamp: '2025-10-22T10:01:45Z'}.

[0073] 3) Threat Score Calculation Process - 192.168.10.8: WAF high risk (1.0×500) + IDS medium risk (0.6×100) = 560 points; - 192.168.11.3: WAF high risk (500) + IDS medium risk (60) = 560 points; - 10.0.0.5: IPS low risk (0.8×10) = 8 points.

[0074] 4) Dynamic threshold determination Current window threat score dataset: [8, 35, 75, 120, 250, 310, 560, 560]; - Upper quartile Q3 position: (3×8+1) / 4 = 6.25; - Linear interpolation calculation: 310 + (560-310)×0.25 = 372.5; - Judgment result: Score 560 > 372.5, IPs 192.168.10.8 and 192.168.11.3 triggered a ban.

[0075] 5) Performance test results - Log processing throughput: peak 650,000 records / minute, average 480,000 records / minute; - End-to-end processing latency: 95th percentile latency 1.8 seconds, average latency 1.1 seconds; - Blocking accuracy: False block rate 1.7%, missed block rate 0.3%.

[0076] Conclusion: This invention proposes an innovative solution for comprehensive threat scoring and automated blocking based on real-time multi-source security logs. Through a unified log standardization method, a configurable threat scoring model, a dynamic threshold decision-making mechanism based on statistical quantiles, and a complete execution audit closed loop, it effectively addresses the shortcomings of existing technologies in cross-device threat correlation, comprehensive assessment, and adaptive response. Experimental results demonstrate that this solution significantly improves blocking accuracy while maintaining high processing performance, and can meet the complex network security protection needs of modern enterprises.

[0077] This application also provides a security log event threat assessment and attack source blocking system, such as... Figure 4 As shown, the system includes: Data acquisition module 401 is used to acquire log data from multiple heterogeneous security devices; Log matching module 402 is used to determine target log events that match predefined attack event types; The threat scoring module 403 is used to determine the threat score of the target log event based on the product of the device type weight and the event type severity level coefficient corresponding to the target log event. The threat scoring module 403 is also used to accumulate the threat scores of all target log events belonging to the same first attack source IP within the current preset sliding time window to obtain the comprehensive threat score of the first attack source IP. The dynamic blocking threshold calculation module 404 is used to determine the upper M quantile of the comprehensive threat score of all attack source IPs within the current preset sliding event window as the dynamic blocking threshold. The blocking execution module 405 is used to trigger an automatic blocking process for the first attack source IP when it is determined that the comprehensive threat score of the first attack source IP is greater than the dynamic blocking threshold.

[0078] In some possible implementations, the aforementioned dynamic blocking threshold calculation module 404 is specifically used to determine a sample set based on the non-zero comprehensive threat score of all attack source IPs within the current preset sliding time window, wherein the elements in the sample set are arranged in ascending order according to the threat score value; based on the formula: The position pos of the upper quartile is determined; if pos is an integer, the comprehensive threat score of the sample set relative to the position pos is used as the upper quartile; if pos is not an integer, linear interpolation is used based on the formula: Determine the upper quartile. The upper quartile is used as the dynamic blocking threshold.

[0079] In some possible implementations, the data acquisition module 401 mentioned above specifically includes: The data caching module is used to collect raw security log events from the multiple heterogeneous security devices; The log standardization module is used to perform field standardization processing on the original security log events, mapping similar semantic fields in logs from different sources to unified field names; The index storage module is used to establish and maintain an event type mapping table. Based on the predefined event type mapping table, the event names of target log events in the log events of each security device are mapped to standardized general event type names. The event type mapping table is used to represent the correspondence between specific log events of different security devices for the same attack behavior and standard event type names.

[0080] In some possible implementations, the aforementioned blocking execution module 405 is specifically used to issue a blocking instruction for the first attack source IP to a preset boundary security device through a standardized application programming interface. The blocking instruction includes the first attack source IP address, the blocking action, the blocking duration, and the blocking reason.

[0081] In some possible implementations, the system also includes an audit and model optimization module 406, which writes the comprehensive threat score details that trigger the blocking command, dynamic blocking threshold information, blocking commands related to this blocking process, and blocking results as audit logs into the index storage system to form a feedback loop for the blocking operation.

[0082] This application also provides a threat assessment and attack source blocking device for security log events, including a unit for performing any of the above method embodiments for threat assessment and attack source blocking of security log events.

[0083] In the embodiments of this application, any of the implementation methods mentioned in the method embodiments are also applicable to the threat assessment and attack source blocking device or system for security log events provided in this application. For specific execution steps, please refer to the description of the foregoing method embodiments, which will not be detailed here.

[0084] Please refer to Figure 5This is a schematic diagram of the structure of a security log event threat assessment and attack source blocking device provided in an embodiment of this application, as shown below. Figure 5 As shown, the threat assessment and attack source blocking device 500 for security log events may include: at least one processor 501, such as a CPU, at least one communication interface 503, a memory 504, and at least one communication bus 502. The communication bus 502 is used to establish communication between these components. The communication interface 503 may optionally include a standard wired interface, a wireless interface (such as a Wi-Fi interface or a Bluetooth interface), etc. The memory 504 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 504 may also be at least one storage device located remotely from the aforementioned processor 501. Figure 5 As shown, the memory 504, which serves as a computer storage medium, may include an operating system, a network communication module, and program instructions.

[0085] exist Figure 5 In the security log event threat assessment and attack source blocking device 500 shown, the processor 501 can be used to load program instructions stored in the memory 504, and implement any of the above method embodiments.

[0086] It should be noted that the specific execution process can be found in the detailed description of the above method embodiments, and will not be elaborated here.

[0087] For specific execution steps, please refer to the description of the foregoing method embodiments, which will not be detailed here.

[0088] This application also provides a computer storage medium that can store multiple instructions. These instructions are adapted to be loaded and executed by a processor to perform the threat assessment and attack source blocking method for security log events provided in this application. For details of the execution process, please refer to the specific description of the method embodiments shown above, which will not be elaborated here.

[0089] This application also provides a computer program product containing instructions that, when run on an electronic device, cause the electronic device to execute the method steps of the method embodiments shown above.

[0090] This application also provides a chip module, including a transceiver component and a chip, wherein the chip is used to execute the method steps of the above-described method embodiments.

[0091] It is understood that the aforementioned threat assessment and attack source blocking system, device, computer storage medium, computer program, computer program product, and chip for security log events are all used to execute the method shown in any implementation of the corresponding aspect of the embodiments of this application. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects in the corresponding method, and will not be detailed here.

[0092] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it includes the processes of the embodiments of the above methods.

[0093] The term "at least one" in this application refers to one or more items. "More than one item" means two or more items. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship. Furthermore, it should be understood that although the terms "first," "second," etc., may be used to describe objects in this application, these objects should not be limited to these terms. These terms are only used to distinguish the objects from each other.

[0094] The terms “including” and “having” mentioned above, and any variations thereof, are intended to cover non-exclusive inclusion.

[0095] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for threat assessment and attack source blocking of security log events, characterized in that, The method includes: Acquire log events from multiple heterogeneous security devices and identify target log events that match predefined attack event types; The threat score of the target log event is determined by multiplying the device type weight and the event type severity coefficient corresponding to the target log event. The device type weight is related to the detection reliability and importance of the security device source of the log event, and the event type severity coefficient is related to the severity of the event type of the log event. The threat scores of all target log events belonging to the same first attack source IP within the current preset sliding time window are accumulated to obtain the comprehensive threat score of the first attack source IP, where the first attack source IP is the attack source IP corresponding to any log event belonging to the target log event. The upper M quantile of the comprehensive threat score of all attack source IPs within the current preset sliding event window is determined as the dynamic blocking threshold. The upper M quantile is used to indicate whether any attack source IPs within the current preset sliding event window have a comprehensive threat score that is not present in the target IP's overall threat score. The proportion data is less than the upper M quantile, and there is... The proportion data is greater than or equal to the upper M quantile, where M is an integer greater than or equal to 3; If the overall threat score of the first attack source IP is determined to be greater than or equal to the dynamic blocking threshold, the blocking process for the first attack source IP is triggered.

2. The method as described in claim 1, characterized in that, The value of M is 4. Determining the upper M quantile of the comprehensive threat score of all attack source IPs within the current preset sliding event window as the dynamic blocking threshold includes: Based on the non-zero comprehensive threat score of all attack source IPs within the current preset sliding time window, a sample set is determined, and the elements in the sample set are arranged in ascending order according to the threat score value from smallest to largest. Based on the formula: Determine the position pos of the upper quartile, where n is the number of elements in the sample set; When pos is an integer, the combined threat score of the sample set relative to the pos position is taken as the upper quartile; When pos is not an integer, linear interpolation is used based on the formula: Determine the upper quartile. , wherein The integer part of pos, the The fractional part of pos; The upper quartile is used as the dynamic blocking threshold.

3. The method as described in claim 1 or 2, characterized in that, The acquisition of log events from multiple heterogeneous security devices includes: Collect raw security log events from the multiple heterogeneous security devices; The original security log events are subjected to field standardization processing, which maps similar semantic fields in logs from different sources to a unified field name; Based on a predefined event type mapping table, the event names of specific log events in the log events of each security device are mapped to standardized general event type names. The event type mapping table is used to represent the correspondence between specific log events of different security devices for the same attack behavior and standard event type names.

4. The method according to any one of claims 1-3, characterized in that, The multiple heterogeneous security devices include a web application firewall (WAF), an intrusion prevention system (IPS), and an intrusion prevention system (IDS). Among them, the device type weight corresponding to the log event originating from the WAF is the first weight, the device type weight corresponding to the log event originating from the IPS is the second weight, and the device type weight corresponding to the log event originating from the IDS is the third weight. The first weight is greater than the second weight, and the second weight is greater than the third weight.

5. The method according to any one of claims 1 to 4, characterized in that, The log events include high-risk, medium-risk, and low-risk event types. Wherein, the severity level coefficient of the event type corresponding to the high-risk event type is the first coefficient, the severity level coefficient of the event type corresponding to the medium-risk event type is the second coefficient, and the severity level coefficient of the event type corresponding to the low-risk event type is the third coefficient, wherein the first coefficient is greater than the second coefficient, and the second coefficient is greater than the third coefficient.

6. The method according to any one of claims 1 to 5, characterized in that, The process of triggering the blocking of the first attack source IP includes: A blocking instruction targeting the first attack source IP is issued to a preset boundary security device through a standardized application programming interface. The blocking instruction includes the first attack source IP address, the blocking action, the blocking duration, and the reason for the blocking.

7. The method according to any one of claims 1 to 6, characterized in that, After triggering the blocking process for the first attack source IP, the method further includes: The comprehensive threat score details that triggered the blocking command, the dynamic blocking threshold information, the blocking commands related to this blocking process, and the blocking results are written as audit logs into the index storage system to form a feedback loop for the blocking operation.

8. A threat assessment and attack source blocking system for security log events, characterized in that, The system includes: The data acquisition module is used to acquire log events from multiple heterogeneous security devices; The log matching module is used to identify target log events that match predefined attack event types; The threat scoring module is used to determine the threat score of the target log event based on the product of the device type weight and the event type severity coefficient corresponding to the target log event. The device type weight is related to the detection reliability and importance of the security device source of the log event, and the event type severity coefficient is related to the severity of the event type of the log event. The threat scoring module is also used to accumulate the threat scores of all target log events belonging to the same first attack source IP within the current preset sliding time window to obtain the comprehensive threat score of the first attack source IP, where the first attack source IP is the attack source IP corresponding to any log event belonging to the target log event. The dynamic blocking threshold calculation module is used to determine the upper M quantile of the comprehensive threat score of all attack source IPs within the current preset sliding event window as the dynamic blocking threshold. The upper M quantile is used to indicate the presence of attacks in the comprehensive threat score of all attack source IPs within the current preset sliding event window. The proportion data is less than the upper M quantile, and there exists The proportion data is greater than or equal to the upper M quantile, where M is an integer greater than or equal to 3; The blocking execution module is used to trigger an automatic blocking process for the first attack source IP when it is determined that the comprehensive threat score of the first attack source IP is greater than the dynamic blocking threshold.

9. A threat assessment and attack source blocking device for security log events, characterized in that, Includes a unit for performing the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program, which, when executed, performs the method according to any one of claims 1 to 7.