Network security data association analysis method

Abstract

The invention provides a network security data association analysis method, and belongs to the technical field of network security. The method comprises the following steps: collecting multi-source heterogeneous log data representing the current security condition of a network; labeling the sub-data of the multi-source heterogeneous log data according to preset business logic to generate log data labels in a uniform format; based on a preset association analysis rule, performing feature rule matching on the log data tag to obtain an alarm matching result; and generating a corresponding prompt alarm event according to the alarm matching result in combination with a preset event classification library. Through unified tagging of multi-source heterogeneous logs and intelligent association analysis based on service logic, the alarm number is significantly reduced, the alarm accuracy is improved, and security events having actual influences on network security are accurately identified.

Description

Technical Field

[0001] This application belongs to the field of network security technology, specifically relating to a network security data correlation analysis method. Background Technology

[0002] Currently, network security protection systems generally deploy various security devices and logging systems, such as firewalls, intrusion detection systems (IDS), and endpoint detection and response (EDR), generating massive amounts of multi-source and heterogeneous network security data. This data includes network traffic logs, host system logs, security alarm logs, application access logs, and authentication logs, which are stored independently, have different formats, and lack effective correlation and integration.

[0003] Traditional security analysis methods often rely on a single data source for isolated rule matching or threshold alerts, resulting in a large number of low-value, repetitive, and even contradictory raw alerts, which are difficult to accurately reflect the true attack intent and security posture. Summary of the Invention

[0004] To address at least one of the technical problems existing in the background technology, this application provides a network security data correlation analysis method. By unifying the labeling of multi-source heterogeneous logs and conducting intelligent correlation analysis based on business logic, it significantly reduces the number of alarms, improves alarm accuracy, and accurately identifies security events that have a real impact on network security.

[0005] The technical solution adopted in this application is as follows: This application provides a network security data correlation analysis method, including: Collect multi-source heterogeneous log data that represents the current security status of the network, including network traffic logs and host operating system logs; According to the preset business logic, each sub-data of the multi-source heterogeneous log data is tagged to generate log data tags in a unified format. The business logic includes asset importance identification rules, user and permission identification rules, security event classification and severity rating rules, and data source and context association rules. Based on preset association analysis rules, feature rule matching is performed on the log data tags to obtain alarm matching results. The feature rule matching adopts at least one of regular expressions, keyword matching, behavior pattern matching or threshold trigger condition matching. Based on the alarm matching results and in conjunction with a preset event classification library, a corresponding prompt alarm event is generated.

[0006] According to the network security data correlation analysis method provided in this application embodiment, firstly, multi-source heterogeneous log data is collected as samples, comprehensively covering various security data sources such as network traffic, host logs, security device alarms, application access records, and identity authentication information, providing a complete input foundation for subsequent deep correlation and avoiding analysis blind spots caused by data silos; secondly, the original logs are structurally labeled based on preset business logic, transforming non-standardized log content into unified format data with semantic tags such as asset importance, user role, permission level, event type, and severity. This not only achieves log standardization and semantic enhancement but also introduces business context (such as CMDB assets). The method integrates information, user group policies, and threat intelligence to enable subsequent analysis to "understand the business impact." Secondly, it utilizes pre-defined correlation analysis rules to perform feature rule matching on tagged logs, combining regular expressions, keywords, behavioral patterns, and threshold triggers. It supports complex rules for statistical types (such as high-frequency failed logins) and sequence types (such as scanning followed by Webshell access), enabling accurate identification of combined events with attack intent or abnormal behavioral patterns from massive amounts of tagged data, significantly improving the intelligence and adaptability of detection. Finally, it generates alert events using a structured event classification library. This library integrates knowledge such as event type, severity level, MITRE ATT&CK mapping, handling suggestions, and SOAR scripts, ensuring that alerts not only have high confidence but also directly guide response and handling, thereby significantly reducing the number of invalid alerts and improving security operation efficiency. Overall, this method achieves efficient and accurate transformation from raw logs to high-value security events through a closed-loop process of "data fusion—semantic tagging—intelligent correlation—knowledge-driven alerting."

[0007] According to one embodiment of this application, the step of tagging each sub-data of the multi-source heterogeneous log data according to preset business logic to generate log data tags in a unified format specifically involves: The sample is subjected to field extraction using a preset regular expression matching rule library. Each rule in the rule library includes a rule ID, applicable log source type, regular expression, list of fields to be extracted, and field mapping relationship. Map the extracted raw fields to standardized field names; The standardized fields are enriched with external system information, including asset information in the configuration management database (CMDB), user group information in the identity management system, or external threat intelligence data. Based on the enriched information, log data is dynamically tagged with asset type, criticality level, user role, permission level, network area, or session identifier.

[0008] According to one embodiment of this application, the association analysis rules include statistical association rules and sequence association rules; The statistical association rules are used to detect whether the number of times a specific behavior of the same subject occurs within a preset time window exceeds a threshold. The sequence association rule is used to detect whether multiple different types of log events occur in a specified order within a preset time window; The statistical association rules are matched using the sequenceCount function, and the sequence association rules are matched using the windowFunnel function.

[0009] According to one embodiment of this application, the step of generating a corresponding prompt alarm event based on the alarm matching result and in conjunction with a preset event classification library specifically includes: Determine the corresponding event type ID based on the alarm matching results; Based on the event type ID, query the event classification library to obtain the alarm description, severity level, confidence level, scope of impact, MITRE ATT&CK technical ID, CVE number, threat intelligence reference and handling suggestions associated with the event type ID, and generate a prompt alarm event containing alarm ID, alarm type, alarm level, alarm description and alarm handling suggestions.

[0010] According to one embodiment of this application, it also includes: Execute tiered alarm notifications based on the alarm level of the alarm event; High-risk alarms are pushed in real time via SMS, email, or instant messaging tools; medium-risk alarms are pushed to the security management platform and recorded in the system log; and low-risk alarms are stored only in the local log library and are periodically summarized to generate reports.

[0011] According to one embodiment of this application, the Network traffic originates from switches, routers, or NetFlow exporters; The host and operating system logs are sourced from Windows Event Log or Linux syslog; The multi-source heterogeneous data also includes: Security device alarm logs originate from IDS, IPS, firewalls, or web application firewalls; Application access logs originate from HTTP servers or database auditing systems; Identity and access management authentication logs, originating from LDAP, AD, or VPN devices; Terminal detection and response (EDR) data; External threat intelligence data, including malicious IPs, domain names, or file hashes; Industry-specific business system logs, originating from financial or industrial control systems.

[0012] According to one embodiment of this application, the step of tagging each sub-data of the multi-source heterogeneous log data according to preset business logic to generate log data tags in a unified format further includes: Configure or modify the asset importance identification rules, user and permission identification rules, or security event classification rules through the graphical policy editor; Without restarting the data acquisition and analysis system, load the updated business logic rules and apply them to subsequent log processing procedures; Subscribe to external threat intelligence sources to automatically trigger the synchronous update of business logic rules when intelligence is updated.

[0013] According to one embodiment of this application, the event classification library is constructed in the following manner: Historical security incident data is manually labeled to form initial classification samples; Cluster analysis of samples was performed based on attack type, attack target, attack method, and scope of impact. Assign a unique event type ID to each cluster and populate it with the corresponding severity level, MITRE ATT&CK mapping, handling recommendations, and SOAR automation playbook ID to form a structured event classification library.

[0014] According to one embodiment of this application, the log data tags are written to a columnar database in real time after generation; The feature rule matching of the log data tags based on preset association analysis rules is specifically as follows: Log data tags are read periodically or in an event-driven manner from the columnar database; The association analysis rules are applied to aggregate and analyze log data tags to identify associated events consisting of multiple log events with shared attributes; The shared attributes include the same source IP, the same destination asset, the same attack payload, or the same time window.

[0015] According to one embodiment of this application, the triggering conditions for the statistical association rule include: A single source IP address initiates connection requests to more than 100 different destination ports within a preset time window; The same user ID fails authentication more than 10 times within 5 minutes; When any triggering condition is met, the corresponding behavior is determined to be an abnormal security event, and corresponding log data tags are generated for correlation analysis. The triggering conditions for the sequence-type association rule include: The same source asset showed port scan type log events and Webshell access type log events sequentially within a 30-minute time window; When the triggering condition of this sequence is met, it is determined that there is an intrusion attack chain behavior, and a corresponding prompt alarm event is generated. Attached Figure Description

[0016] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart illustrating the network security data association analysis method provided in an embodiment of this application. Detailed Implementation

[0017] To more clearly illustrate the overall concept of this application, a detailed explanation is provided below with reference to the accompanying drawings.

[0018] Many specific details are set forth in the following description to provide a thorough understanding of this application. However, this application may also be implemented in other ways different from those described herein. Therefore, the scope of protection of this application is not limited to the specific embodiments disclosed below. It should be noted that, unless otherwise specified, the embodiments of this application and the features thereof can be combined with each other.

[0019] In this application, unless otherwise expressly specified and limited, the "above" or "below" of the second feature can mean that the first and second features are in direct contact, or that the first and second features are in indirect contact through an intermediate medium. In the description of this specification, references to terms such as "an embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples.

[0020] like Figure 1 As shown in the figure, this application provides a network security data correlation analysis method, including: Step 100: Collect multi-source heterogeneous log data representing the current security status of the network. The multi-source heterogeneous data includes network traffic logs and host operating system logs.

[0021] Step 200: Tag each sub-data of multi-source heterogeneous log data according to the preset business logic to generate log data tags in a unified format. The business logic includes asset importance identification rules, user and permission identification rules, security event classification and severity rating rules, and data source and context association rules.

[0022] Step 300: Based on the preset association analysis rules, perform feature rule matching on the log data tags to obtain alarm matching results. Feature rule matching adopts at least one of the following methods: regular expression, keyword matching, behavior pattern matching, or threshold trigger condition matching.

[0023] Step 400: Based on the alarm matching results and in conjunction with the preset event classification library, generate the corresponding prompt alarm event.

[0024] In step 100, the system collects multi-source heterogeneous log data from various security devices and business systems in the network environment as analysis samples. This data includes, but is not limited to: network traffic / session logs (such as NetFlow, sFlow), host operating system logs (such as Windows Event Log, Linux syslog), security device alarm logs (such as firewall, IDS / IPS, WAF), application access logs (such as HTTP request logs, database audit logs), authentication logs (such as AD / LDAP login records), endpoint detection and response (EDR) data, and external threat intelligence (such as malicious IPs, domain name blacklists).

[0025] By comprehensively aggregating these scattered data sources, the system constructs a raw observation foundation covering all dimensions of the network. This step breaks through the limitations of "data silos" in traditional security analysis, providing complete and accurate input for subsequent cross-source correlation and avoiding missed reports or misjudgments due to missing information.

[0026] In step 200, the system performs structured processing and semantic tagging on the raw logs according to preset business logic, generating log data tags in a unified format. Specifically, firstly, key fields (such as source IP, destination port, user ID, event code, etc.) are extracted from the raw logs using a regular expression matching rule base, and then these fields are mapped to standardized names; subsequently, the fields are enriched with context by combining external system information (such as asset importance in CMDB, user roles in IAM, and reputation scores from threat intelligence platforms), and semantic tags such as "asset type: core database", "user role: domain administrator", "event type: brute force attack", and "network zone: DMZ" are dynamically added.

[0027] The asset importance identification rules are used to automatically identify network assets (such as IP addresses, hostnames, domain names, service ports, etc.) in logs and label them with "importance" based on their criticality within the business system. The criteria for this judgment include: IP / Network Segment Attribution: For example, if the source or destination IP belongs to a network segment marked as "Core Database Cluster" in CMDB (such as 10.10.0.0 / 24), it will be automatically marked as asset_criticality: High; Hostname or Service Characteristics: If the hostname contains "db-prod" or the service port is 1521 (Oracle's default port), it will be marked as asset_type: Database, criticality: High; External System Integration: By calling the Configuration Management Database (CMDB) API, information such as the business affiliation, department, and SLA level of the asset can be dynamically obtained to achieve accurate labeling.

[0028] User and permission identification rules are used to parse user identity information from logs and label users based on their roles and permission levels to distinguish between ordinary users and privileged accounts. Typical implementations include: Username matching: If the username is "admin", "root", "sa", etc., it is marked as user_role: administrator, permission_level: privilege; User group affiliation: By connecting to LDAP / AD, if the user belongs to a high-privilege group such as "Domain Admins" or "Security Operators", the privileged_user: true label is automatically assigned; Login context analysis: If a domain administrator account logs in from a non-company IP (such as an overseas proxy) through a VPN, the login_anomaly: true label is additionally assigned.

[0029] Security incident classification and severity rating rules perform preliminary categorization and risk assessment of original alerts or suspicious behaviors, filtering out noise and highlighting real threats. Its working methods include: Based on signature / rule matching: If the IDS alert signature ID is "2001001" (representing Log4j RCE), it is classified as event_type: remote code execution, severity: critical; Based on threat intelligence: If the destination IP in the log appears in the malicious C2 list, it is marked as event_type: malicious communication, severity: high; Based on abnormal behavior: If an internal host initiates DNS tunnel communication to the outside (high-frequency small packet queries), it is classified as event_type: data leakage attempt, severity: medium; Dynamic escalation mechanism: If the attack target is a high-critical-level asset, even if the original vulnerability CVSS score is medium, the event severity can be escalated to "high".

[0030] Data source and context association rules assign source identifiers and session contexts to logs, acting as a "glue" for cross-source associations. Specifically, these include: Data source labeling: Logs from the core firewall are labeled with data_source: FW-core, network_zone: DMZ; logs from EDR are labeled with data_source: EDR, endpoint_id: WIN-ABC123; Session-level association: All logs (such as requests and responses) of the same TCP stream are assigned the same session_id; User behavior chaining: The entire process logs of the same user from login, application access to logout are associated with user_session_id.

[0031] For example, when a Windows security log shows that user "admin" has failed to log in consecutively, the system not only extracts the username and the number of failures, but also tags it as a "privileged account" based on its group "Domain Admins", and initially marks it as a "high-risk authentication anomaly" based on the frequency of failures.

[0032] Transforming messy raw logs into structured, labeled data rich in business semantics enables subsequent analysis to "understand asset value" and "identify behavioral context," significantly improving the relevance and accuracy of alerts.

[0033] In step 300, the system performs feature rule matching on the tagged log data based on preset association analysis rules to identify potential security threats. The matching methods are flexible, supporting regular expressions (for payload feature identification), keyword matching (such as SQL injection keywords), behavioral pattern matching (such as access to sensitive resources outside of working hours), and threshold triggering conditions (such as exceeding the limit for the number of connected ports per unit time). Association analysis rules are divided into two categories: statistical rules (such as "the same user fails authentication more than 10 times within 5 minutes") use the `sequenceCount` function to aggregate frequency; sequence rules (such as "a port scan occurs first, followed by Webshell access within 30 minutes") use the `windowFunnel` function to detect event timing logic.

[0034] For example, if an internal network host initiates connections to more than 100 different ports within 60 seconds, the system will trigger the "port scan" statistics rule; if the host subsequently accesses a URL containing "eval($_POST['cmd'])", the sequence rule will be further triggered, and it will be judged as an attack chain behavior.

[0035] By mining complex behaviors with attack intent from isolated incidents, it can effectively identify advanced persistent threats (APTs) or lateral movement attacks that are difficult to detect with traditional single-point detection, significantly reducing false alarm rates and improving threat detection depth.

[0036] In step 400, the event classification library is a knowledge base that predefines a unique event type ID for each type of security event and associates it with the event name, severity level (such as "high", "medium", "low"), confidence level, scope of impact, MITRE ATT&CK technical number (such as T1190), CVE vulnerability number, threat intelligence reference, natural language alert description and specific handling suggestions (such as "block the source IP, check the target server logs, start the incident response playbook_block_ip").

[0037] For example, when a behavior matching the sequence "Webshell upload + command execution" is detected, the system automatically queries the classification library to obtain the corresponding event type "WEB_ATTACK_WEBSHELL", and fills in information such as its high-risk level, ATT&CK IDT1505.003, and handling suggestions, and finally generates a complete alarm containing alarm ID, type, level, description and operation instructions.

[0038] Transforming technical detection results into understandable and actionable security operation instructions not only improves the readability and credibility of alerts, but also provides structured input for automated responses (such as SOAR linkage), greatly improving the security team's analysis efficiency and response speed.

[0039] According to the network security data correlation analysis method provided in this application embodiment, firstly, multi-source heterogeneous log data is collected as samples, comprehensively covering various security data sources such as network traffic, host logs, security device alarms, application access records, and identity authentication information, providing a complete input foundation for subsequent deep correlation and avoiding analysis blind spots caused by data silos; secondly, the original logs are structurally labeled based on preset business logic, transforming non-standardized log content into unified format data with semantic tags such as asset importance, user role, permission level, event type, and severity. This not only achieves log standardization and semantic enhancement but also introduces business context (such as CMDB assets). The method integrates information, user group policies, and threat intelligence to enable subsequent analysis to "understand the business impact." Secondly, it utilizes pre-defined correlation analysis rules to perform feature rule matching on tagged logs, combining regular expressions, keywords, behavioral patterns, and threshold triggers. It supports complex rules for statistical types (such as high-frequency failed logins) and sequence types (such as scanning followed by Webshell access), enabling accurate identification of combined events with attack intent or abnormal behavioral patterns from massive amounts of tagged data, significantly improving the intelligence and adaptability of detection. Finally, it generates alert events using a structured event classification library. This library integrates knowledge such as event type, severity level, MITRE ATT&CK mapping, handling suggestions, and SOAR scripts, ensuring that alerts not only have high confidence but also directly guide response and handling, thereby significantly reducing the number of invalid alerts and improving security operation efficiency. Overall, this method achieves efficient and accurate transformation from raw logs to high-value security events through a closed-loop process of "data fusion—semantic tagging—intelligent correlation—knowledge-driven alerting."

[0040] In some embodiments of this application, each sub-data of multi-source heterogeneous log data is tagged according to preset business logic to generate log data tags in a unified format, specifically as follows: The sample is processed by a pre-defined regular expression matching rule library. Each rule in the rule library contains a rule ID, applicable log source type, regular expression, list of fields to be extracted, and field mapping relationship. Map the extracted raw fields to standardized field names; Context enrichment of standardized fields is performed by combining external system information, including asset information in the Configuration Management Database (CMDB), user group information in the Identity Management System, or external threat intelligence data. Based on the enriched information, log data is dynamically tagged with asset type, criticality level, user role, permission level, network area, or session identifier.

[0041] In the process of structuring multi-source heterogeneous logs, the system first applies a pre-defined regular expression matching rule base to extract fields from the original log samples. This rule base is organized in a highly configurable manner. Each rule includes a rule ID (e.g., "FW_ASA_302013"), the applicable log source type (e.g., "cisco_asa_firewall"), the regular expression used to parse the log text, a list of fields to be extracted (e.g., source IP, destination port, event code, etc.), and field mapping relationships (mapping the extracted original field names to standardized field names uniform within the system). For example, for a Cisco ASA firewall log "%ASA-6-302013: Built outbound TCP connection...", the system accurately extracts information such as src_ip and dst_port by matching the corresponding rule, and maps them to the standardized fields "sip" and "dport", thereby achieving semantic alignment of logs from different vendors and in different formats.

[0042] Subsequently, the system extracts and standardizes the fields and performs context enrichment with external system information. This process is crucial for enhancing the semantic value of the logs: the system proactively queries the Configuration Management Database (CMDB) to confirm whether the IP addresses involved in the logs belong to core business servers and obtains their asset type (e.g., "Oracle database") and criticality level (e.g., "high"); simultaneously, it calls the identity management system (e.g., Active Directory) to verify the user account's group membership and determine whether it is a "domain administrator" or "privileged operations and maintenance personnel"; in addition, it connects to an external threat intelligence platform to check whether the source IP appears in the known malicious IP list. For example, when the logs show an access request from IP "203.0.113.5", if this IP is marked as a C2 server by threat intelligence, the system automatically adds the "malicious_source" label to it; if the target IP "192.168.1.10" is marked as "financial system database" in the CMDB, it is labeled "asset_criticality: high".

[0043] Finally, based on the enriched and comprehensive information described above, the system dynamically generates a set of structured semantic tags for each log entry, including but not limited to asset type, criticality level, user role, permission level, network area (such as "internal core area" or "DMZ area"), or session identifier (used to associate multiple logs of the same user or the same TCP stream). These tags not only describe the attributes of the log itself, but also incorporate business context and security situation awareness.

[0044] On the one hand, it realizes the transformation from "raw logs" to "security event units rich in business semantics", providing a high-quality and comparable data foundation for subsequent correlation analysis. On the other hand, it avoids misjudgment caused by lack of context in traditional solutions (such as misjudging normal administrator operations as abnormal behavior), greatly improving the accuracy and interpretability of alarms. At the same time, it supports priority sorting by asset importance or user permissions, enabling security operation resources to focus on truly high-risk events.

[0045] In some embodiments of this application, the association analysis rules include statistical association rules and sequence association rules; Statistical association rules are used to detect whether the number of times a specific behavior of the same subject occurs within a preset time window exceeds a threshold; Sequence-based association rules are used to detect whether multiple different types of log events occur in a specified order within a preset time window; Statistical association rules are calculated using the `sequenceCount` function, while sequence-based association rules are calculated using the `windowFunnel` function.

[0046] The association analysis rules in this application are divided into statistical association rules and sequence association rules. These two types target different types of attack behavior patterns, jointly constructing a multi-dimensional detection capability for complex threats. The core of statistical association rules lies in frequency anomaly detection, which determines whether the number of times the same entity (e.g., source IP, user ID, host asset) performs a specific action exceeds a set threshold within a preset time window (e.g., 5 minutes, 1 hour). Its implementation relies on the efficient time-series aggregation function `sequenceCount`, which can quickly count the frequency of events meeting certain conditions in large-scale log tag streams. For example, a rule can be defined as: "The same user ID fails authentication more than 10 times within 5 minutes." The system uses `sequenceCount` to group and count all logs marked "login failed" by user ID. Once the threshold is triggered, it is determined to be a brute-force attack. This type of rule is particularly suitable for detecting attacks with obvious quantitative characteristics, such as scanning, brute-force attacks, and high-frequency requests.

[0047] In contrast, sequence-based association rules focus on the temporal logic of the attack phase, identifying whether multiple different types of security events occur sequentially within a specified time window (e.g., 30 minutes) according to a preset attack chain order. This is implemented using the `windowFunnel` function, which efficiently detects whether an event sequence occurs in a specific order within a sliding time window, even if other unrelated events occur in between. For example, a typical sequence rule can be defined as: "The same source asset first experiences a 'port scan' event, followed by a 'Webshell access' event within 30 minutes." When an internal network host A is first recorded to initiate connections to multiple ports (labeled `event_type: port_scan`), and then accesses a URL containing a malicious payload (labeled `event_type: webshell_access`), the `windowFunnel` function will identify this "reconnaissance → exploit" attack chain pattern and determine it as a high-risk intrusion. This type of rule can effectively capture multi-stage composite attacks such as APT attacks and lateral movement attacks, compensating for the shortcomings of single-point detection.

[0048] The two types of rules described above are: statistical rules, which excel at detecting anomalous behaviors where "quantitative changes lead to qualitative changes," offering rapid response and high computational efficiency; and sequence rules, which excel at reconstructing the attacker's tactical intent and revealing the complete attack path hidden behind isolated events. The combination of these two types covers both high-frequency, simple attacks and low-frequency, complex attacks. Furthermore, leveraging high-performance analysis functions such as `sequenceCount` and `windowFunnel`, the system can perform real-time or near-real-time correlation calculations on massive amounts of log tag data, balancing accuracy and performance. Ultimately, this detection mechanism, based on behavioral patterns rather than single signatures, significantly reduces false positives, improves the ability to generalize detection of unknown or variant attacks, and provides more insightful alerts for security operations.

[0049] In some embodiments of this application, a corresponding alert event is generated based on the alarm matching result and a preset event classification library, specifically as follows: Determine the corresponding event type ID based on the alarm matching results; Based on the event type ID, query the event classification library to obtain the alarm description, severity level, confidence level, scope of impact, MITRE ATT&CK technical ID, CVE number, threat intelligence reference and handling suggestions associated with the event type ID, and generate a prompt alarm event containing alarm ID, alarm type, alarm level, alarm description and alarm handling suggestions.

[0050] The key to generating high-quality alerts lies in transforming the raw "matching results" into security alerts with business semantics and actionable capabilities. This process relies on a structured event classification library. Specifically, when the correlation analysis module outputs an alert matching result (e.g., "A certain IP was detected to initiate a large number of port connections in a short period of time"), the system first automatically maps it to a unique event type ID (such as "NETWORK_PORT_SCAN" or "1002") based on the rules or behavioral patterns matched by the result. This ID serves as an index for querying the pre-built event classification library—a structured database integrating security knowledge and operational experience.

[0051] The event classification library pre-configures rich contextual information for each event type ID, including a natural language alert description (e.g., "Detected full port scanning behavior from an external IP, possibly in the pre-attack reconnaissance stage"), severity level (e.g., "medium" or "high"), confidence level (reflecting the reliability of rule matching, e.g., "high" indicates support from multiple sources), scope of impact (e.g., "may lead to asset exposure and service information leakage"), standardized threat framework identifier (e.g., MITRE ATT&CK technical ID "T1046 - Network Service Scanning"), associated vulnerability number (e.g., applicable CVE), cited threat intelligence (e.g., the source IP has been marked as a scanner node by multiple intelligence platforms), and the most critical handling recommendations (e.g., "1. Block the source IP at the perimeter firewall; 2. Check if the scanned host has any unauthorized open services; 3. Enable deep network traffic inspection"). For example, if the matching result corresponds to an SQL injection attempt, the system can query the classification database by the event type ID "WEB_SQLI_ATTACK", automatically fill in its ATT&CK ID as "T1190", the severity level as "high", and attach specific web application hardening suggestions.

[0052] Finally, the system assembles the above information into a well-structured and complete alert event, including an alert ID (globally unique), alert type (e.g., "network scan"), alert level, detailed description, and actionable processing suggestions.

[0053] This knowledge-based alert generation mechanism fundamentally changes the traditional low-information alert model of security devices that only output "rule ID + raw logs," allowing security analysts to quickly understand the nature and risks of an event without manually consulting documents or piecing together context. Furthermore, standardized severity levels and handling recommendations support automated tiered responses (such as automatically triggering SOAR scripts for high-risk alerts), significantly improving emergency response efficiency. More importantly, by integrating industry standards such as MITREATT&CK, this method incorporates isolated events into a globally applicable attack tactic framework, helping enterprises to reconstruct attack chains, hunt threats, and optimize defense systems, truly achieving a closed loop from "seeing alerts" to "understanding threats" and then to "effective handling."

[0054] In some embodiments of this application, it also includes: Execute tiered alarm notifications based on the alarm level of the alarm event; High-risk alarms are pushed in real time via SMS, email, or instant messaging tools; medium-risk alarms are pushed to the security management platform and recorded in the system log; and low-risk alarms are stored only in the local log library and are periodically summarized to generate reports.

[0055] This application further introduces a hierarchical alarm notification mechanism based on alarm levels to achieve accurate distribution and efficient response to security alarms. This mechanism automatically executes differentiated notification strategies based on the "alarm level" (usually divided into high-risk, medium-risk, and low-risk) contained in the alarm event, ensuring that critical threats are addressed promptly while avoiding interference from low-value information to operations and maintenance personnel. Specifically, when the system generates an alert event, it first analyzes its severity level: if it is a high-risk alert (such as detecting successful remote code execution using the Log4j vulnerability, or confirmed ransomware encryption activity), the system immediately pushes alerts in real time through multiple channels, including SMS, email, and enterprise-level instant messaging tools (such as DingTalk, WeChat Work, or Slack), ensuring that security personnel receive a strong reminder within seconds, thereby quickly initiating the emergency response process; if it is a medium-risk alert (such as suspicious port scanning, multiple failed authentication attempts, or other potential risk behaviors), it is pushed to a unified security management platform (such as SIEM or SOC console) for analysts to focus on during daily inspections, and is simultaneously recorded in the system audit log for traceability; and for low-risk alerts (such as known crawler access, rules triggered by internal test traffic, etc.), the system only stores them in the local log library without proactive notification, but instead generates analysis reports on a daily or weekly basis for long-term trend observation or rule optimization.

[0056] For example, when a server is detected to have been compromised by a Webshell that executes system commands (event type ID corresponding to "WEB_BACKDOOR_EXECUTION", severity level "high"), the system not only generates a structured alert but also immediately sends an SMS to the security team leader: "[High-risk alert] Webshell execution behavior detected at 192.168.10.50, please take immediate action!" A detailed link is also pushed to the company's WeChat group. If an employee fails to log in 5 times due to an incorrect password (judged as medium-risk), only a pending work order is displayed on the SOC platform, without disturbing off-duty personnel. As for regular HTTP requests from search engine crawlers that accidentally trigger XSS rules (low-risk), they are silently archived, and the end-of-month report only shows "127 low-risk false alarms were blocked / ignored this month".

[0057] This tiered notification mechanism significantly reduces alert fatigue for security operations personnel, preventing them from being overwhelmed by massive amounts of low-value information and allowing them to focus on truly high-risk events. Furthermore, it improves the timeliness of response to critical threats, achieving "second-level" delivery for high-risk events and buying valuable time to curb the spread of attacks. In addition, by routing alerts of different levels to different processing channels, it also optimizes the allocation of security operations resources—high-risk events go through emergency response procedures, medium-risk events are included in the routine analysis queue, and low-risk events are used for model optimization, thus constructing an efficient, orderly, and scalable closed-loop security alert management system.

[0058] In some embodiments of this application, Network traffic originates from switches, routers, or NetFlow exporters; Host and operating system logs, sourced from Windows Event Log or Linux syslog; Multi-source heterogeneous data also includes: Security device alarm logs originate from IDS, IPS, firewalls, or web application firewalls; Application access logs originate from HTTP servers or database auditing systems; Identity and access management authentication logs, originating from LDAP, AD, or VPN devices; Terminal detection and response (EDR) data; External threat intelligence data, including malicious IPs, domain names, or file hashes; Industry-specific business system logs, originating from financial or industrial control systems.

[0059] Network traffic / session logs, such as streaming data generated by switches, routers, or NetFlow / sFlow exporters, record communication behaviors such as source / destination IP, port, protocol, byte count, and session duration, which can be used to identify DDoS, port scanning, or abnormal outbound connections; host and operating system logs, such as login, process creation, and permission change events in Windows Event Log, or system call and service status logs in Linux syslog, can reveal local privilege escalation, persistence, or malicious process activity; security device alarm logs, from IDS / IPS, next-generation firewalls (NGFW), or web application firewalls (WAF), contain known attack signature matching results (such as SQL injection, XSS rule triggering), threat levels, and payload fragments, providing direct evidence of threat detection; application access logs, such as HTTP request logs from Nginx / Apache or SQL statements recorded by database auditing systems, can accurately locate API abuse, unauthorized access, or data theft; identity and access management authentication logs, originating from LDAP, Active Directory, etc., can also be used to identify DDoS, port scanning, or abnormal outbound connections. Directory (AD) or VPN devices record detailed account login success / failure, multi-factor authentication status, source IP, and time, providing crucial evidence for detecting brute-force attacks, credential leaks, or abnormal logins. Endpoint detection and response (EDR) data, including process trees, file hashes, DLL loading, network connections, and behavioral characteristics (such as anti-debugging and memory injection), provides in-depth endpoint forensics for advanced threats (such as fileless attacks and lateral movement). External threat intelligence data, such as malicious IP addresses, known C2 domains, malicious file hashes (MD5 / SHA256), and their reputation scores provided by third-party platforms, is used to enrich and prioritize internal logs. Industry-specific business system logs, such as transaction logs in the financial industry and PLC instruction and process parameter change records in industrial control systems (ICS / SCADA), can identify direct disruptive behaviors to business logic (such as unauthorized equipment start / stop and control instruction tampering) in critical infrastructure scenarios.

[0060] By integrating the aforementioned multi-source heterogeneous data, this application constructs a security observation system covering the entire stack of "network-host-application-identity-terminal-service". This not only fills the blind spots of a single data source, but also provides a solid foundation for cross-dimensional correlation analysis (such as linking network scanning behavior with subsequent web attacks and terminal process creation), thereby significantly improving the ability to identify complex attack chains and the overall level of security situation awareness.

[0061] In some embodiments of this application, each sub-data of multi-source heterogeneous log data is tagged according to preset business logic to generate log data tags in a unified format, and the method further includes: Configure or modify asset importance identification rules, user and permission identification rules, or security event classification rules through the graphical policy editor; Without restarting the data acquisition and analysis system, load the updated business logic rules and apply them to subsequent log processing procedures; Subscribe to external threat intelligence sources to automatically trigger the synchronous update of business logic rules when intelligence is updated.

[0062] The process of structuring samples, extracting information, and tagging them according to preset business logic not only relies on static rules but also possesses high dynamic configurability and adaptability. Specifically, the system provides a graphical policy editor, allowing security operations personnel to flexibly configure or modify various core business logic rules through a visual interface (such as drag-and-drop forms, drop-down menus, or rule templates). These rules include asset importance identification rules (e.g., "servers within the IP range 192.168.10.0 / 24 are marked as 'core assets'"), user and permission identification rules (e.g., "accounts belonging to the 'Domain Admins' group are automatically assigned the 'privileged user' label"), and security event classification rules (e.g., "requests containing 'eval($_POST' and targeting .php files are classified as Webshell uploads"). This low-code or even no-code configuration method significantly lowers the barrier to rule maintenance, enabling non-developers to quickly respond to business changes or new threat scenarios.

[0063] More importantly, the system supports a hot-reload mechanism, meaning that updated business logic rules can be loaded in real time and immediately applied to subsequent log processing flows without interrupting log collection or restarting the analysis engine. For example, when a security team discovers a new attack payload, they can add a regular expression matching rule in the graphical editor, save it, and the system will take effect immediately without downtime deployment, ensuring continuous online and seamless evolution of protection capabilities. Furthermore, the system has intelligent linkage capabilities: by actively subscribing to external threat intelligence sources (such as MISP, VirusTotal, and commercial TI platforms), when a high-risk malicious IP, domain name, or file hash is added to the intelligence database, the system can automatically trigger a synchronous update of business logic rules—for example, adding the newly appearing C2 server IP to the "malicious source" tag rule, or automatically increasing the risk level of logs associated with that IP. This mechanism enables the entire tagging system to perceive and adapt to the external threat environment.

[0064] On the one hand, it significantly improves the agility and responsiveness of security operations, reducing rule adjustments from "hours" to "minutes," effectively addressing rapidly evolving attack methods. On the other hand, it ensures system availability and continuity, avoiding blind spots in security monitoring caused by frequent restarts. Simultaneously, through automatic linkage with threat intelligence, it achieves a shift from "passive defense" to "proactive immunity," ensuring that log tags are always integrated with the latest threat context, providing a more accurate and intelligent data foundation for subsequent correlation analysis. Overall, this mechanism constructs a configurable, hot-updateable, and self-learning dynamic tagging engine, a key support for achieving efficient and accurate network security data correlation analysis.

[0065] In some embodiments of this application, the event classification library is constructed in the following manner: Historical security incident data is manually labeled to form initial classification samples; Cluster analysis of samples was performed based on attack type, attack target, attack method, and scope of impact. Assign a unique event type ID to each cluster and populate it with the corresponding severity level, MITRE ATT&CK mapping, handling recommendations, and SOAR automation playbook ID to form a structured event classification library.

[0066] The event classification database is constructed using a combination of manual annotation, intelligent clustering, and knowledge injection to ensure accuracy, structure, and practical guidance value. First, the system manually annotates accumulated historical security event data (such as verified alerts from the past year). Senior security analysts assign semantic tags to each event, including attack type (e.g., brute-force attack, port scanning, webshell upload), attack target (e.g., database server, domain controller), attack method (e.g., exploiting CVE-2023-1234 vulnerability, using the Cobalt Strike tool), and impact scope (e.g., "information gathering only," "potentially causing data breaches," "has caused business disruption"). This forms a high-quality initial classification sample set. This step ensures the database's authority and business relevance, avoiding noise or bias that might be introduced by purely automated methods.

[0067] Subsequently, based on these labeled samples, the system performs cluster analysis in a multi-dimensional feature space, automatically grouping events with similar attack patterns, target objects, and impact consequences into the same cluster. For example, all events that are "SQL injection attempts targeting web applications, specifically the user login interface, which are unsuccessful but occur frequently" are clustered into one category; while events that are "successfully logging into the domain controller using RDP brute force and executing Mimikatz credential theft" form another high-risk cluster. Each cluster represents a typical threat scenario with clear behavioral boundaries and risk characteristics.

[0068] Finally, a unique event type ID (such as "AUTH_BRUTEFORCE_SUCCESS" or "WEB_SQLI_ATTEMPT") is assigned to each cluster, and structured metadata is populated by security experts. This metadata includes severity level (high / medium / low), MITREATT&CK technique mapping (such as T1110.003 - Brute Force: Password Spraying), associated CVE number (if applicable), standardized alert description template, actionable handling recommendations (such as "immediately disable account, reset password, check login session"), and the corresponding SOAR automation playbook ID (such as playbook_isolate_host_and_block_ip). These knowledge elements together constitute a structured event classification library that can be understood and invoked by machines.

[0069] Manual annotation ensures classification accuracy, while clustering enables efficient summarization of massive events, preventing rule explosion. Furthermore, the structured output (especially the binding of ATT&CK mapping and SOAR scripts) makes alerts not only "understandable" but also "automatically handled." In addition, this classification library possesses excellent scalability—newly emerging attack patterns can be continuously integrated into the system through new clusters, supporting long-term system evolution and truly achieving a security operation upgrade from "experience-driven" to "knowledge-driven."

[0070] In some embodiments of this application, log data tags are written to a columnar database in real time after generation; Based on preset association analysis rules, feature rule matching is performed on log data tags, specifically as follows: Periodically or event-driven, read log data labels from a columnar database; The association analysis rules are applied to aggregate and analyze the log data tags to identify associated events consisting of multiple log events with shared attributes; Shared attributes include the same source IP, the same destination asset, the same attack payload, or the same time window.

[0071] After log data tags are generated, they are written in real time to a high-performance columnar database (such as ClickHouse, Apache Doris, or similar time-series / analytic databases), which is optimized for high-speed writing and low-latency querying of massive amounts of structured logs. Using columnar storage not only significantly reduces storage space but also substantially improves the efficiency of aggregation, filtering, and scanning by fields (such as sip, event_type, user_id), providing a solid data foundation for subsequent complex correlation analysis.

[0072] Based on this, the system's correlation analysis process is specifically manifested as follows: periodically triggered (e.g., polling every 30 seconds) or driven by specific events (e.g., immediate activation when a certain type of high-risk log appears), it efficiently reads tagged log data from the columnar database; subsequently, it applies preset correlation analysis rules (including statistical and sequence rules) to this data, and performs multi-dimensional aggregation analysis on the log tags through SQL or a dedicated analysis engine (e.g., based on functions such as windowFunnel and sequenceCount), aiming to identify composite correlation events composed of multiple events scattered in different log records but with inherent logical connections. The core basis for this correlation is the shared attributes between logs—for example, if multiple logs have the same source IP (e.g., 203.0.113.45 initiating multiple abnormal behaviors in a short period of time), the same target asset (e.g., the core database server 192.168.10.50 continuously suffering different types of probes), the same attack payload (e.g., multiple users submitting requests containing the same malicious Base64 encoded string), or occur within the same time window (e.g., login failure, successful login, and sensitive file download occurring sequentially within 5 minutes), they are considered different links in a potential attack chain.

[0073] For example, when the system discovers from the columnar database that IP 10.20.30.40 first failed to authenticate with the SSH service 12 times between 14:00:00 and 14:05:00 (label: event_type=auth_fail, protocol=ssh), then successfully logged in at 14:05:10 (event_type=auth_success), and accessed the / etc / shadow file at 14:06:00 (event_type=file_access, file= / etc / shadow), although these logs come from different log sources (system logs + audit logs), they are identified by the association rules as a complete attack behavior of "successfully brute-forced and stealing credentials" because they share the "source IP" and "time window" attributes.

[0074] This mechanism leverages the high-performance analytical capabilities of columnar databases, enabling the system to quickly perform complex cross-source, cross-time, and cross-behavioral correlations in TB-level logs, breaking through the limitations of traditional streaming-based single-point matching. At the same time, the aggregation logic based on "shared attributes" allows the system to not only discover isolated anomalies but also reconstruct the attacker's tactical intent and action path, thereby outputting correlation alerts with high confidence and high contextual value, significantly improving the detection capabilities for complex attacks such as advanced persistent threats (APTs), lateral movement, and multi-stage penetration.

[0075] In some embodiments of this application, the triggering conditions for statistical association rules include: A single source IP address initiates connection requests to more than 100 different destination ports within a preset time window; The same user ID fails authentication more than 10 times within 5 minutes; When any triggering condition is met, the corresponding behavior is determined to be an abnormal security event, and corresponding log data tags are generated for correlation analysis. The triggering conditions for sequence-based association rules include: The same source asset showed port scan type log events and Webshell access type log events sequentially within a 30-minute time window; When the triggering condition of this sequence is met, it is determined that there is an intrusion attack chain behavior, and a corresponding prompt alarm event is generated.

[0076] Statistical association rules focus on anomalous changes in behavioral frequency. By setting clear quantitative thresholds and time windows, they enable efficient identification of typical automated attacks. For example, when the system detects a single source IP making connection requests to more than 100 different destination ports within a preset time window (e.g., 60 seconds), this behavior highly matches the characteristics of network scanning tools (e.g., Nmap, Masscan), and is very likely an attacker conducting asset probing or vulnerability reconnaissance. Similarly, if the same user ID fails authentication more than 10 times within 5 minutes, it significantly deviates from normal user operation patterns and is highly likely a brute-force or password spraying attack. Once either of these conditions is met, the system automatically marks the relevant log events as "abnormal security events" and generates log data tags with specific semantic labels (e.g., event_type: port_scan or event_type: brute_force_attempt), which serve as input units for subsequent higher-order association analysis. This type of threshold-based statistical rule is computationally efficient, has controllable false positives, and is suitable for large-scale real-time monitoring scenarios.

[0077] In contrast, sequence-based association rules focus on the temporal logic and causal relationships of multi-stage attack behaviors, aiming to reconstruct the attacker's complete tactical chain. A typical example is: within a 30-minute time window, the same source asset (such as the internal network host 192.168.5.20) first shows log events marked as "port scanning" (such as initiating a large number of SYN requests), followed by log events marked as "Webshell access" (such as sending an HTTP request containing eval($_POST['cmd']) to a web server). Although these two events may have limited risk when viewed individually, their occurrence in a short period of time in the order of "reconnaissance → exploitation" strongly suggests that the host has been compromised and is being used as a springboard for secondary attacks. When the system confirms the existence of this temporal pattern through sequence matching functions such as windowFunnel, it determines that an intrusion attack chain has been established. Instead of simply generating intermediate labels, it directly outputs a high-confidence alert event, which includes a description of the attack stages, risk level, and handling recommendations.

[0078] The design of the two types of triggering conditions embodies the "point-to-chain" defense-in-depth concept: statistical rules quickly capture single-point anomalies and build a basic threat profile; sequence rules, on the other hand, integrate context and temporal logic to identify complex attack intentions. Working together, they ensure both immediate response to high-frequency, simple attacks and deep perception of low-frequency, multi-stage advanced threats, thereby significantly improving the accuracy and coverage of overall security analysis.

[0079] For any parts not mentioned in this application, existing technologies may be used or referenced.

[0080] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0081] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for network security data correlation analysis, characterized in that, include: Collect multi-source heterogeneous log data that represents the current security status of the network, including network traffic logs and host operating system logs; According to the preset business logic, each sub-data of the multi-source heterogeneous log data is tagged to generate log data tags in a unified format. The business logic includes asset importance identification rules, user and permission identification rules, security event classification and severity rating rules, and data source and context association rules. Based on preset association analysis rules, feature rule matching is performed on the log data tags to obtain alarm matching results. The feature rule matching adopts at least one of regular expressions, keyword matching, behavior pattern matching or threshold trigger condition matching. Based on the alarm matching results and in conjunction with a preset event classification library, a corresponding prompt alarm event is generated.

2. The network security data correlation analysis method according to claim 1, characterized in that, The step of tagging each sub-data of the multi-source heterogeneous log data according to preset business logic to generate log data tags in a unified format is as follows: The sample is subjected to field extraction using a preset regular expression matching rule library. Each rule in the rule library includes a rule ID, applicable log source type, regular expression, list of fields to be extracted, and field mapping relationship. Map the extracted raw fields to standardized field names; The standardized fields are enriched with external system information, including asset information in the configuration management database (CMDB), user group information in the identity management system, or external threat intelligence data. Based on the enriched information, log data is dynamically tagged with asset type, criticality level, user role, permission level, network area, or session identifier.

3. The network security data correlation analysis method according to claim 1, characterized in that, The association analysis rules include statistical association rules and sequence association rules; The statistical association rules are used to detect whether the number of times a specific behavior of the same subject occurs within a preset time window exceeds a threshold. The sequence association rule is used to detect whether multiple different types of log events occur in a specified order within a preset time window; The statistical association rules are matched using the sequenceCount function, and the sequence association rules are matched using the windowFunnel function.

4. The network security data correlation analysis method according to claim 1, characterized in that, The step of generating a corresponding alert event based on the alarm matching result and in conjunction with a preset event classification library is as follows: Determine the corresponding event type ID based on the alarm matching results; Based on the event type ID, query the event classification library to obtain the alarm description, severity level, confidence level, scope of impact, MITRE ATT&CK technical ID, CVE number, threat intelligence reference and handling suggestions associated with the event type ID, and generate a prompt alarm event containing alarm ID, alarm type, alarm level, alarm description and alarm handling suggestions.

5. The network security data correlation analysis method according to any one of claims 1 to 4, characterized in that, Also includes: Execute tiered alarm notifications based on the alarm level of the alarm event; High-risk alarms are pushed in real time via SMS, email, or instant messaging tools; medium-risk alarms are pushed to the security management platform and recorded in the system log; and low-risk alarms are stored only in the local log library and are periodically summarized to generate reports.

6. The network security data correlation analysis method according to claim 1, characterized in that, The Network traffic originates from switches, routers, or NetFlow exporters; The host and operating system logs are sourced from Windows Event Log or Linux syslog; The multi-source heterogeneous data also includes: Security device alarm logs originate from IDS, IPS, firewalls, or web application firewalls; Application access logs originate from HTTP servers or database auditing systems; Identity and access management authentication logs, originating from LDAP, AD, or VPN devices; Terminal detection and response (EDR) data; External threat intelligence data, including malicious IPs, domain names, or file hashes; Industry-specific business system logs, originating from financial or industrial control systems.

7. The network security data correlation analysis method according to claim 2, characterized in that, The step of tagging each sub-data of the multi-source heterogeneous log data according to preset business logic to generate log data tags in a unified format also includes: Configure or modify the asset importance identification rules, user and permission identification rules, or security event classification rules through the graphical policy editor; Without restarting the data acquisition and analysis system, load the updated business logic rules and apply them to subsequent log processing procedures; Subscribe to external threat intelligence sources to automatically trigger the synchronous update of business logic rules when intelligence is updated.

8. The network security data correlation analysis method according to claim 1, characterized in that, The event classification library is constructed in the following way: Historical security incident data is manually labeled to form initial classification samples; Cluster analysis of samples was performed based on attack type, attack target, attack method, and scope of impact. Assign a unique event type ID to each cluster and populate it with the corresponding severity level, MITRE ATT&CK mapping, handling recommendations, and SOAR automation playbook ID to form a structured event classification library.

9. The network security data correlation analysis method according to claim 2, characterized in that, The log data tags are written to the columnar database in real time after they are generated. The feature rule matching of the log data tags based on preset association analysis rules is specifically as follows: Log data tags are read periodically or in an event-driven manner from the columnar database; The association analysis rules are applied to aggregate and analyze log data tags to identify associated events consisting of multiple log events with shared attributes; The shared attributes include the same source IP, the same destination asset, the same attack payload, or the same time window.

10. The network security data correlation analysis method according to claim 3, characterized in that, The triggering conditions for the statistical association rules include: A single source IP address initiates connection requests to more than 100 different destination ports within a preset time window; The same user ID fails authentication more than 10 times within 5 minutes; When any triggering condition is met, the corresponding behavior is determined to be an abnormal security event, and corresponding log data tags are generated for correlation analysis. The triggering conditions for the sequence-type association rule include: The same source asset showed port scan type log events and Webshell access type log events sequentially within a 30-minute time window; When the triggering condition of this sequence is met, it is determined that there is an intrusion attack chain behavior, and a corresponding prompt alarm event is generated.

Images