Network security dynamic early warning method and system based on big data analysis

Abstract

The application discloses a network security dynamic early warning method and system based on big data analysis, and relates to the technical field of network security.The method comprises the following steps: obtaining network operation data and generating a security event sequence; merging a risk unit sequence based on the continuous relationship of adjacent security events; accumulating a situation evolution sequence based on the continuation relationship of the risk unit in each monitoring period and performing change identification; generating a risk propagation chain sequence based on the connection relationship between the risk units, combining the change identification result to output an early warning sequence; and recursively updating the next period operation data.The application can unify multi-source heterogeneous data into structured security events, realize continuous description of risk activities, situation trend identification and propagation chain construction through continuous relationship merging, continuation relationship accumulation and connection relationship chaining, and improve the real-time performance, continuity and interpretability of dynamic early warning in a big data scenario by combining an incremental update mechanism.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to a dynamic early warning method and system for network security based on big data analysis. Background Technology

[0002] In recent years, with the widespread application of cloud computing, big data, the Internet of Things, and mobile internet, network scale has continued to expand, business models have become increasingly complex, and network boundaries have become blurred. Various network attack methods are showing a trend towards concealment, persistence, and interconnectedness. For example, attacks targeting critical businesses often do not occur as single events, but rather occur continuously in multiple stages, including scanning and probing, credential attempt, privilege acquisition, lateral movement, and data theft. These attacks leave scattered traces across multiple data sources, such as network traffic, access behavior, authentication behavior, and device operating status. Against this backdrop, how to promptly detect the continuity and evolution of risky activities within massive amounts of heterogeneous operational data, and how to achieve dynamic early warning before the risk spreads, has become a crucial technical challenge in network security protection.

[0003] Currently, Chinese invention patent application CN119603076A discloses a method and system for network security early warning based on big data. This method collects multiple types of data, including network traffic, user behavior, system logs, and hardware status data. It then calculates indicators based on these data, including network attack risk indicators, user data anomaly risk indicators, system security risk indicators, and hardware failure risk indicators. Furthermore, it comprehensively calculates a network security risk indicator, and finally presets a network security early warning threshold. The comprehensive indicator is then compared to this threshold, and the comparison result determines whether an early warning mechanism is triggered, generating corresponding early warning information. However, this related technology does not fully consider the continuous correlation between multi-source security data over time. It typically summarizes and compares anomalies from different sources as independent indicators or isolated alarms, making it difficult to group continuous activities between adjacent events into risk units that can characterize the process. It also makes it difficult to recursively accumulate the continuity of risk activities over the monitoring cycle, thus lacking an effective characterization of continuous, intermittent, and multi-stage risk evolution. Furthermore, many related technologies use fixed thresholds to trigger judgments on comprehensive indicators, resulting in warning results that are biased towards static assessments. This makes it difficult to output characteristics of risk changes over time, such as growth, decline, fluctuations, or turning points. It also makes it difficult to establish the propagation chain of risk across sources, targets, and behaviors, leading to deficiencies in the interpretability, localization, and support for decision-making in warning information. Meanwhile, in scenarios with continuously generated large-scale data, the lack of a recursive incremental update mechanism often necessitates repeated calculations of historical data, easily resulting in high computational costs and reduced timeliness of warnings. Summary of the Invention

[0004] The technical problem solved by this invention is that existing technologies are difficult to perform unified structured and temporally correlated analysis on multi-source heterogeneous operational data generated by target networks in big data scenarios. They are also difficult to identify the continuous relationship between adjacent security events and to group fragmented events into risk units that can characterize the continuous risk activity process. Furthermore, they are difficult to recursively accumulate risk units based on the continuity relationship in the monitoring cycle dimension to form a situation evolution sequence and identify situation change characteristics such as growth, decline, stabilization, continuous growth, continuous decline, fluctuation, and turning point. At the same time, they are difficult to construct a risk propagation chain based on the connection relationship between risk units and output a warning sequence with temporal trend significance by combining the situation change identification results. Moreover, they lack a recursive update mechanism for the next monitoring cycle, resulting in insufficient real-time performance, continuity, and interpretability of warnings.

[0005] To address the aforementioned technical problems, the present invention provides the following technical solution: Firstly, a dynamic early warning method for network security based on big data analysis, comprising the following steps: Step S1: Obtain the operational data generated by the target network in each monitoring period, perform unified structural processing on the operational data, and generate a sequence of security events according to the time of occurrence. Step S2: Based on the continuous relationship between adjacent security events in the security event sequence, perform merging processing to generate a risk unit sequence; Step S3: Based on the continuity relationship of the risk unit sequence in each monitoring period, perform cumulative processing to generate a situation evolution sequence, and identify changes in the situation evolution sequence to obtain the change identification result; Step S4: Generate a risk propagation chain sequence based on the connection relationship between risk unit sequences, and output an early warning sequence in combination with the change identification results; Step S5: Receive the operational data for the next monitoring cycle, and recursively update the security event sequence, risk unit sequence, situation evolution sequence, risk propagation chain sequence, and early warning sequence to obtain the updated security event sequence, updated risk unit sequence, updated situation evolution sequence, updated risk propagation chain sequence, and updated early warning sequence.

[0006] As a preferred embodiment of the network security dynamic early warning method based on big data analysis described in this invention, step S1 specifically includes: Step S11: Obtain the operational data generated by the target network during the current monitoring period; The operational data includes traffic records, access records, authentication records, and device records; Step S12: Parse the fields of traffic records, access records, authentication records and device records to extract source identifier, behavior identifier, object identifier, occurrence time and status identifier; Step S13: Map the source identifier, behavior identifier, object identifier, occurrence time and status identifier to their positions according to the preset field structure, generate a unified record unit, and generate a corresponding security event based on each unified record unit; Step S14: Sort the security events according to their occurrence time, and organize the sorted security events into a security event sequence.

[0007] As a preferred embodiment of the network security dynamic early warning method based on big data analysis described in this invention, the processing logic of step S12 is as follows: Read field information from traffic records, access records, authentication records, and device records, and based on preset field mapping rules, parse the field information into source identifier, object identifier, behavior identifier, occurrence time, and status identifier; The processing logic for the preset field mapping rules is as follows: Read the communication address field, communication port field, protocol field, and transmission time field from the traffic record, and parse the initiating address in the communication address field into the source identifier, parse the receiving address in the communication address field into the object identifier, parse the combination of the protocol field and the communication port field into the behavior identifier, and parse the transmission time field into the occurrence time; Read the access subject field, access target field, access action field, and access time field from the access record, and parse the access subject field into a source identifier, the access target field into an object identifier, the access action field into a behavior identifier, and the access time field into the time of occurrence. Read the authentication subject field, authentication object field, authentication result field, and authentication time field from the authentication record, and parse the authentication subject field into a source identifier, the authentication object field into an object identifier, the authentication result field into a status identifier, the authentication time field into the time of occurrence, and the authentication action category into a behavior identifier; Read the device number field, running object field, running status field and recording time field from the device record, and parse the device number field into a source identifier, the running object field into an object identifier, the running status field into a status identifier, the recording time field into the occurrence time, and the device action field into a behavior identifier; The parsed source identifier, behavior identifier, object identifier, occurrence time, and status identifier are mapped to their corresponding fields.

[0008] As a preferred embodiment of the network security dynamic early warning method based on big data analysis described in this invention, step S2 specifically includes: Step S21: Read the current security event and the next security event in the security event sequence according to the order of arrangement; Step S22: Extract the source identifier, behavior identifier, object identifier, and occurrence time of the current security event, and extract the source identifier, behavior identifier, object identifier, and occurrence time of the next security event; Step S23: Determine whether the current security event and the next security event satisfy a continuity relationship; The continuity relationships include source continuity relationships, object continuity relationships, behavior connection relationships, and temporal adjacency relationships; Step S24: When the current security event and the next security event satisfy the continuity relationship, the current security event and the next security event are grouped into the same event group, and the next security event after the next security event is read. Steps S22 to S24 are repeated until the continuity relationship is no longer satisfied. Step S25: Sequentially integrate the occurrence sequence, duration, and involved objects of each safety event within the event group to generate corresponding risk units; Step S26: Repeat steps S21 to S25 according to the reading order of the security event sequence to organize each risk unit into a risk unit sequence according to the generation order.

[0009] As a preferred embodiment of the network security dynamic early warning method based on big data analysis described in this invention, step S3 specifically includes: Step S31: Read the current risk units belonging to the current monitoring period in the risk unit sequence according to the monitoring cycle order; Step S32: Within the preset backtracking range prior to the current monitoring period, find the preceding risk unit that satisfies the continuity relationship with the current risk unit, and read the preceding situation value corresponding to the preceding risk unit; The preset backtracking range is the previous four monitoring cycles of the current monitoring cycle; The continuity relationships include source identifier continuity relationships, object identifier continuity relationships, and behavioral trajectory connection relationships; Step S33: The current unit value of the current risk unit is recursively accumulated with the previous situation value of the previous risk unit to generate the current situation value corresponding to the current monitoring period. Step S34: Organize the current situation values ​​into a situation evolution sequence according to the monitoring cycle order; Step S35: Read the previous and next situation values ​​corresponding to adjacent monitoring periods in the situation evolution sequence, and calculate the situation change. Step S36: Read the continuous situational change data in the order of the monitoring cycle, identify the direction of change and the continuous state of change, and generate change identification results; The change identification results include growth change indicators, decline change indicators, stable change indicators, continuous growth indicators, continuous decline indicators, fluctuation change indicators, and turning point change indicators.

[0010] As a preferred embodiment of the network security dynamic early warning method based on big data analysis described in this invention, the processing logic of step S33 is as follows: Step S331: Read the number of events, duration, number of objects, and number of status changes corresponding to the current risk unit within the current monitoring period, and calculate the current unit value based on the number of events, duration, number of objects, and number of status changes; Step S332: Read the preceding situation value corresponding to the preceding risk unit that has a continuity relationship with the current risk unit in the previous monitoring period; Step S333: Determine if the preceding risk unit exists; If the preceding risk unit exists, execute step S334; If the current risk unit does not exist, the current unit value is determined as the current situation value; Step S334: Read the number of interval periods between the previous risk unit and the current risk unit, and generate a decreasing coefficient based on the number of interval periods; Step S335: The current unit value and the previous situation value are recursively accumulated according to the decreasing coefficient to generate the current situation value; Step S336: Write the current situation value into the situation evolution sequence position corresponding to the current monitoring period.

[0011] As a preferred embodiment of the network security dynamic early warning method based on big data analysis described in this invention, step S4 specifically includes: Step S41: Read the current risk unit and the next risk unit in the risk unit sequence according to the arrangement order; Step S42: Extract the source identifier, object identifier, behavior trajectory, and end time of the current risk unit, and extract the source identifier, object identifier, behavior trajectory, and start time of the next risk unit; Step S43: Determine whether the current risk unit and the next risk unit satisfy the connection relationship; The connection relationships include source connection relationships, object connection relationships, behavior connection relationships, and time connection relationships; Step S44: When the current risk unit and the next risk unit satisfy the connection relationship, connect the current risk unit and the next risk unit to the same propagation chain group, and continue to read the next risk unit after the next risk unit. Repeat steps S42 to S44 until the connection relationship is no longer satisfied. Step S45: Arrange the risk units within the propagation chain group according to the connection order to generate the corresponding risk propagation chain; Step S46: Repeat steps S41 to S45 according to the reading order of the risk unit sequence, and write each generated risk propagation chain into the risk propagation chain sequence in sequence. Step S47: Read the change identification results corresponding to each risk propagation chain, generate corresponding early warning icons according to the arrangement order of the risk propagation chains, and organize the early warning icons into an early warning sequence according to the generation order.

[0012] As a preferred embodiment of the network security dynamic early warning method based on big data analysis described in this invention, the processing logic of step S47 is as follows: Step S471: Read the change identification results corresponding to the current risk propagation chain according to the arrangement order of the risk propagation chain sequence; Step S472: When the change identification result includes a continuous growth indicator, generate a first warning indicator; Step S473: When the change identification result includes both growth change identifier and fluctuation change identifier, or only includes growth change identifier and does not include fluctuation change identifier, a second warning identifier is generated. Step S474: When the change identification result includes a stable change indicator, a third early warning indicator is generated; Step S475: When the change identification result includes a falling change indicator, a continuous falling change indicator, or a turning change indicator, a fourth warning indicator is generated. Step S476: Write the first warning identifier, the second warning identifier, the third warning identifier, or the fourth warning identifier into the warning sequence position corresponding to the current risk transmission chain; Step S477: Continue reading the change identification results corresponding to the next risk propagation chain, and repeat steps S472 to S476 until the risk propagation chain sequence reading is completed.

[0013] As a preferred embodiment of the network security dynamic early warning method based on big data analysis described in this invention, step S5 specifically includes: Step S51: Receive the operation data for the next monitoring cycle, perform unified structure processing on the operation data, and generate new security events; Step S52: Write the newly added security events sequentially to the end of the security event sequence according to their occurrence time to obtain the updated security event sequence; Step S53: Read the new security events starting from the end of the updated security event sequence, and perform a merge process based on the continuity relationship to obtain new risk units. Write the new risk units sequentially to the end of the risk unit sequence to obtain the updated risk unit sequence. Step S54: Read the newly added risk units starting from the end of the updated risk unit sequence, and perform recursive accumulation and change identification processing based on the continuation relationship to obtain the new situation value and the new change identification result. Write the new situation value into the end of the situation evolution sequence in sequence to obtain the updated situation evolution sequence. Step S55: Starting from the end of the updated risk unit sequence, read the newly added risk units, perform connection processing based on the connection relationship to obtain the newly added risk propagation chain and the newly added early warning identifier, write the newly added risk propagation chain to the end of the risk propagation chain sequence in sequence, and write the newly added early warning identifier to the end of the early warning sequence in sequence to obtain the updated risk propagation chain sequence and the updated early warning sequence.

[0014] The network security dynamic early warning system based on big data analysis includes a data processing module, a unit generation module, a situation identification module, a link early warning module, and a recursive update module. The data processing module is used to acquire the operational data generated by the target network in each monitoring period, perform unified structural processing on the operational data, and generate a sequence of security events according to the time of occurrence. The unit generation module is used to perform merging processing based on the continuous relationship between adjacent security events in the security event sequence to generate a risk unit sequence; The situation identification module is used to perform cumulative processing based on the continuity relationship of the risk unit sequence in each monitoring period, generate a situation evolution sequence, and identify changes in the situation evolution sequence to obtain change identification results. The link early warning module is used to generate a risk propagation chain sequence based on the connection relationship between risk unit sequences, and output an early warning sequence in combination with the change identification results; The recursive update module is used to receive the operating data of the next monitoring cycle and recursively update the security event sequence, risk unit sequence, situation evolution sequence, risk propagation chain sequence and early warning sequence to obtain the updated security event sequence, updated risk unit sequence, updated situation evolution sequence, updated risk propagation chain sequence and updated early warning sequence.

[0015] The beneficial effects of this invention are as follows: This invention unifies the parsing of traffic records, access records, authentication records, and device records into a security event sequence with source identifiers, behavior identifiers, object identifiers, occurrence times, and status identifiers, enabling direct temporal correlation between different data sources under the same semantic structure; furthermore, it generates a risk unit sequence based on the continuous relationship between adjacent security events, compressing a large amount of repetitive and scattered alarm information into continuous risk activity units with time boundaries and behavioral trajectories, facilitating rapid identification of continuous behaviors such as scanning—brute force—login—lateral movement in actual combat; and finally, it recursively accumulates the risk units based on the continuity relationship in the monitoring cycle dimension to form a situation evolution sequence. The output change identification results enable early warnings to no longer rely on single-point threshold triggers, but directly reflect the trend characteristics of risks such as growth, decline, stabilization, continuous growth / decline, fluctuation, and turning points, thereby achieving earlier and more continuous dynamic early warnings. At the same time, based on the connection relationship between risk units, a risk propagation chain sequence is generated and combined with the change identification results to output an early warning sequence, so that the early warning results can be mapped to specific propagation links and evolution stages, improving the alarm location and response direction. In addition, incremental processing for the next monitoring cycle is achieved by recursively updating each sequence at the end, avoiding full recalculation and significantly improving the real-time performance and continuous operation capability of network security dynamic early warning in big data scenarios. Attached Figure Description

[0016] Figure 1 A flowchart illustrating the steps of a network security dynamic early warning method based on big data analysis, as provided in one embodiment of the present invention; Figure 2 This is a basic flowchart of a network security dynamic early warning system based on big data analysis, provided as an embodiment of the present invention. Detailed Implementation

[0017] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0018] Example 1, referring to Figure 1 It provides a dynamic early warning method for cybersecurity based on big data analysis, including the following steps: Step S1: Obtain the operational data generated by the target network in each monitoring period, perform unified structural processing on the operational data, and generate a sequence of security events according to the time of occurrence. Step S2: Based on the continuous relationship between adjacent security events in the security event sequence, perform merging processing to generate a risk unit sequence; Step S3: Based on the continuity relationship of the risk unit sequence in each monitoring period, perform cumulative processing to generate a situation evolution sequence, and identify changes in the situation evolution sequence to obtain the change identification result; Step S4: Generate a risk propagation chain sequence based on the connection relationship between risk unit sequences, and output an early warning sequence in combination with the change identification results; Step S5: Receive the operational data for the next monitoring cycle, and recursively update the security event sequence, risk unit sequence, situation evolution sequence, risk propagation chain sequence, and early warning sequence to obtain the updated security event sequence, updated risk unit sequence, updated situation evolution sequence, updated risk propagation chain sequence, and updated early warning sequence.

[0019] In specific implementation, step S1 includes: Step S11: Obtain the operational data generated by the target network during the current monitoring period; The operational data includes traffic records, access records, authentication records, and device records; Step S12: Parse the fields of traffic records, access records, authentication records and device records to extract source identifier, behavior identifier, object identifier, occurrence time and status identifier; Step S13: Map the source identifier, behavior identifier, object identifier, occurrence time and status identifier to their positions according to the preset field structure, generate a unified record unit, and generate a corresponding security event based on each unified record unit; Step S14: Sort the security events according to their occurrence time, and organize the sorted security events into a security event sequence.

[0020] Specifically, the system collects, parses, unifies and structures the multi-source operational data within the target network using the current monitoring period as the time window, and generates a security event sequence. The period length Δ of the monitoring period can be pre-configured during the system deployment phase, for example, configured as 5 minutes or 10 minutes. The system defines the current monitoring period as [T0, T0+Δ), where T0 is the start time of the current period. This start time can be generated by the system clock aligned to the hour or by a sliding window mechanism advancing in fixed steps.

[0021] Operational data generated within the current monitoring period is obtained by interfacing with the target network's existing log / traffic infrastructure. Specifically, traffic records are generated from NetFlow / IPFIX records output by network probes or border devices, session logs or five-tuple logs generated by IDS / NGFW; access records are generated from access audit logs output by web servers, application gateways, API gateways, or database auditing systems; authentication records are generated from login authentication logs output by AD / LDAP / SSO / RADIUS or host security logs; and device records are generated from operational status and alarm logs exported by firewalls, switches, routers, hosts, or security devices via Syslog, SNMP Trap, or local logs. To ensure the constraint of "generated within the current monitoring period," the system uses the time field of each record as a filtering condition, writing records whose occurrence time falls within [T0, T0+Δ) into the weekly pending processing queue; in streaming implementations, window segmentation can be performed by timestamp using message queues (e.g., Kafka); in offline / near real-time implementations, data can be retrieved by time conditions through log storage (e.g., HDFS / object storage / ES / relational database).

[0022] The system parses fields from traffic records, access records, authentication records, and device records to extract source identifiers, behavior identifiers, object identifiers, occurrence time, and status identifiers. In this embodiment, a field mapping configuration is pre-established during the system deployment / access phase. This configuration is permanently saved as a configuration file or database table and can be maintained through the operations and maintenance interface. The core of the configuration is to uniformly map the original fields from different data sources to a unified semantic field set: {source identifier source_id, behavior identifier behavior_id, object identifier object_id, occurrence time event_time, status identifier status_id}. For example, for traffic records, the field mapping configuration resolves the initiating address in the communication address field to the source identifier `source_id`, the receiving address in the communication address field to the object identifier `object_id`, concatenates the protocol field and the communication port field as "protocol / port" or generates the behavior identifier `behavior_id` using hash encoding, and resolves the transmission time field to the event time `event_time`. Since traffic records typically do not carry explicit result status, the status identifier `status_id` is set to null or "unknown". For access records, the field mapping configuration resolves the access subject field to the source identifier `source_id`, the access target field (such as URL, resource ID, table name, etc.) to the object identifier `object_id`, the access action field (such as GET / POST / SELECT / UPLOAD, etc.) to the behavior identifier `behavior_id`, and the access time field to the event time `event_time`. The status identifier can be obtained from the HTTP status. Fields such as status codes and audit conclusions are parsed and returned as null if missing. For authentication records, the field mapping configuration parses the authentication subject field as source_id, the authentication object field as object_id, the authentication action category (e.g., login, ticket application, password modification) as behavior_id, the authentication time field as event_time, and the authentication result field (success / failure / locked, etc.) as status_id. For device records, the field mapping configuration parses the device number field as source_id, the running object field (e.g., interface, process, policy, module, etc.) as object_id, the device action field or event type field as behavior_id, the record time field as event_time, and the running status field (normal / abnormal / alarm level, etc.) as status_id. Through this configurable field parsing method, the system can extract five types of fields from records from different sources at runtime according to the same semantic set, laying the foundation for subsequent unified structuring.

[0023] According to the preset field structure, the source identifier, behavior identifier, object identifier, occurrence time, and status identifier are mapped to their positions to generate unified record units, and corresponding security events are generated based on each unified record unit. In this embodiment, the preset field structure is specifically set as the data structure template of the unified record unit. Its field slots are fixed during the system initialization phase. For example, the unified record unit contains and stores in a fixed order: source_id, behavior_id, object_id, event_time, and status_id, and may include extended fields such as record_type (record type) and raw_ref (original record location information) without changing the slots and meanings of the core five-tuple. The location mapping is executed as follows: After parsing the S12 fields, the system writes the parsed source_id to the source_id slot of the unified record unit, behavior_id to the behavior_id slot, object_id to the object_id slot, event_time to the event_time slot, and status_id to the status_id slot. When a record of a certain type is missing a status identifier or other fields, it is filled with null or default values ​​according to a preset default strategy, thereby ensuring that all unified record units have a consistent structure. Subsequently, the system constructs a security event object using the unified record unit and the event number event_id generated within the current period. The event_id can be generated by hashing a combination of source identifier, object identifier, behavior identifier, and occurrence time, or it can be generated by a distributed ID generator. At the same time, raw_ref is written to the security event so that the original log can be traced back when necessary. The preset default strategy refers to a set of fallback processing rules pre-configured by the system when deploying or connecting to the data source. It is used to generate a structurally complete unified record unit and security event even if there are situations such as missing fields, empty field values, abnormal field formats, parsing failure, or failure to hit the mapping rule in the original record during the field parsing and location mapping process in steps S12 and S13. For example, when the status identifier cannot be obtained, the status identifier is set to UNKNOWN or an empty value; when the time of occurrence cannot be parsed, the log reception time is used instead or the record is discarded and marked according to the rules; when the behavior identifier cannot be merged, it is rolled back to the original action value or classified as OTHER; when there are multiple candidate fields with the same semantics, the valid field is selected according to the preset priority.Addressing the common issues of incompleteness and inconsistency in multi-source heterogeneous logs in real-world network environments, this system can prevent security events from being unstructured due to missing fields, resulting in broken event sequences and failures in merging subsequent continuous relationships, recursively probing continuation relationships, and forming chains of connection relationships. This improves the integrity and availability of security event sequences, enhances the continuity and stability of risk units, situational evolution, and risk propagation chains, and allows the system to adapt to new data sources or field changes primarily by adjusting configurations without modifying subsequent core algorithms, thereby improving overall project feasibility and the real-time nature of dynamic early warnings.

[0024] Using the event time (event_time) as the sorting key, all security events generated within the current monitoring period are sorted sequentially. When events with the same event time exist, the source identifier, object identifier, or event number can be used as a secondary sorting key to ensure stable sorting. After sorting, the system writes the sorted security events into a security event sequence. The security event sequence can be implemented as a time-appended serialized storage structure (e.g., stored in a time-series database, ES index, or partitioned file), and the end position of the current period is recorded at the end of the sequence for subsequent steps to merge adjacent security events based on their continuity and for incremental appending and recursive updates when the next monitoring period arrives. Through the above implementation method, S1 can unify heterogeneous operational data into a structurally consistent, time-ordered security event sequence before entering the subsequent continuous / continuous / connected determination, thereby ensuring that the calculation base for subsequent risk unit generation, situation evolution recursion, and propagation chain early warning is consistent and reusable.

[0025] Traditional approaches often involve log sources operating independently with inconsistent fields. Cross-source correlation relies heavily on manual rule alignment or single-point alarm statistics, resulting in high correlation costs, poor scalability, and difficulty in stable reuse. This application unifies heterogeneous data into comparable security event quintuples by pre-setting a field structure and serializes it by time sequence. This allows continuous relationships to be merged, extension relationships to be recursively deduced, and connecting relationships to be chained and run on the same data structure. This reduces the complexity of repeatedly writing correlation logic for different log types, improves the consistency and scalability of cross-source behavior chain identification, and also provides conditions for S5's terminal incremental recursive updates, making the system more suitable for real-time or near-real-time dynamic early warning in big data / streaming scenarios.

[0026] In specific implementation, the processing logic of step S12 is as follows: Read field information from traffic records, access records, authentication records, and device records, and based on preset field mapping rules, parse the field information into source identifier, object identifier, behavior identifier, occurrence time, and status identifier; The processing logic for the preset field mapping rules is as follows: Read the communication address field, communication port field, protocol field, and transmission time field from the traffic record, and parse the initiating address in the communication address field into the source identifier, parse the receiving address in the communication address field into the object identifier, parse the combination of the protocol field and the communication port field into the behavior identifier, and parse the transmission time field into the occurrence time. Read the access subject field, access target field, access action field, and access time field from the access record, and parse the access subject field into a source identifier, the access target field into an object identifier, the access action field into a behavior identifier, and the access time field into the time of occurrence. Read the authentication subject field, authentication object field, authentication result field, and authentication time field from the authentication record, and parse the authentication subject field into a source identifier, the authentication object field into an object identifier, the authentication result field into a status identifier, the authentication time field into the time of occurrence, and the authentication action category into a behavior identifier; Read the device number field, running object field, running status field and recording time field from the device record, and parse the device number field into a source identifier, the running object field into an object identifier, the running status field into a status identifier, the recording time field into the occurrence time, and the device action field into a behavior identifier; The parsed source identifier, behavior identifier, object identifier, occurrence time, and status identifier are mapped to their corresponding fields.

[0027] Specifically, when deploying to access the target network, the system establishes field dictionaries and mapping configurations for traffic records, access records, authentication records, and device records. These mapping configurations are stored as preset field mapping rules in the configuration center or database and are loaded and used by the parsing module at runtime. The mapping configuration includes at least the record type identifier, the original field name (or JSON path, regular expression extraction expression, log key name), the unified semantic field name, and the necessary combination / conversion functions. This enables the system to parse original fields from different sources and in different formats into unified source identifiers, object identifiers, behavior identifiers, occurrence time, and status identifiers without modifying subsequent algorithms. When reading field information, the system first determines the record type based on the source channel, tag, log header type code, or field set characteristics of the input record. When the original record is structured data (such as JSON, KV, NetFlow / IPFIX fields), the field value is read directly by field name or path. When the original record is unstructured text (such as some Syslog), the target field is extracted according to the pre-configured regular expression template or delimiter template. Fields that fail to be extracted are set to empty according to the default strategy and the parsing confidence is recorded to ensure that the process can continue to execute.

[0028] For traffic records, the communication address field in this embodiment can be a combination of the initiating address and receiving address fields. The system resolves the initiating address to a source identifier (source_id) and the receiving address to an object identifier (object_id). The source identifier and object identifier are not limited to the IP string itself. This embodiment allows for further standardization processing, such as unified and standardized representation for IPv4 / IPv6, removal of port appended characters, and mapping private network addresses to asset IDs based on asset ledgers, to reduce association breaks caused by multiple representations of the same entity. The communication port field in this embodiment can simultaneously include the source port (src_port) and the destination port (dst_port). If both exist, the destination port (dst_port) is used preferentially for behavior identifier generation (because the destination port better represents service behavior). If only a single port field exists, that port field is used directly. The protocol field can be a transport layer protocol field such as TCP / UDP / ICMP or an application layer protocol identification field. In this embodiment, the protocol field and the communication port field are combined and parsed into a behavior identifier. Specifically, this means generating a behavior_id according to a preset combination function. For example, it can use string concatenation "protocol:dst_port" (such as TCP:22, TCP:445, UDP:53) or use an enumeration mapping table to map common combinations to standard behavior codes (such as TCP:22 mapped to SSH_CONNECT, TCP:3389 mapped to RDP_CONNECT). When the mapping table cannot be matched, it falls back to the general form "protocol:port" to ensure complete coverage. In this embodiment, the transmission time field can be start_time, end_time, or a single timestamp field. If both start and end times exist, start_time is taken as the occurrence time event_time, and end_time can be used for subsequent continuous span calculations. The system uniformly converts them to a standard timestamp format (such as UTC milliseconds or ISO8601) and corrects them according to the time zone configuration when inconsistent device time zones are detected, thereby ensuring the consistency of cross-source sorting. Since traffic records typically do not carry explicit success / failure semantics, this embodiment allows the status identifier status_id to be set to empty or unknown, or to map action fields (allow / deny / reset) to status identifiers when the traffic source is an IDS / firewall session log, in order to increase the amount of information in the status dimension.

[0029] For access records, the access subject field can be a user account, session ID, client IP, or a combination thereof. When both an account and IP exist, this embodiment prioritizes using the account as the source identifier (source_id) and retains the IP as an extended attribute in the original reference field to avoid the same user being split into different source entities under different IPs. When no account exists, the client IP is used as the source identifier. The access target field can be a URL, URI, interface name, resource ID, database / table name, or file path. This embodiment normalizes these parameters and uses them as the object identifier (object_id). For example, irrelevant parameters are removed from the URL or it is templated (e.g., / user / 123 / profile is normalized to / user / {id} / profile) to reduce the interference of high cardinality parameters on the association. The access action field can be an HTTP method (GET / POST / PUT / DELETE), a business action code (QUERY / EXPORT / UPLOAD), or a permission operation (READ / WRITE). This embodiment maps these to a behavior identifier (behavior_id). If the action field is too granular, this embodiment allows further mapping to a coarser-grained behavior category according to a preset action merging rule to improve cross-system consistency. Pre-defined action merging rules refer to a system that pre-determines a set of mapping rules for action standardization and merging before runtime, especially when access / operation actions from different data sources have inconsistent granularity, naming inconsistencies, or even a large value space (high cardinality). This merges the original action values ​​into fewer, more semantically stable behavior identifier (behavior_id) categories, ensuring that subsequent continuous relationship judgments, recursive relationship deductions, and chaining are not fragmented due to overly granular action values ​​or different system names. This is typically fixed in the form of a configurable mapping table or rule set (configuration file / database table / configuration center). At runtime, the parsing module matches and replaces the original action fields according to these rules: first, merging by exact match (original action value = a string or event code); if no exact match is found, merging by pattern match (regular expression / prefix / template); if still no match is found, it falls back to the default class (e.g., OTHER / UNKNOWN) or retains the original value and marks it as unmerged, facilitating subsequent rule additions, reducing the cardinality of behavior identifiers, improving cross-source consistency, and ensuring seamless behavior connection / trajectory continuity. The connection is more stable; without losing key security semantics, it reduces the problem of the same attack phase being split into multiple discontinuous chains due to overly detailed action fields, thus making subsequent risk unit merging, situational deduction, and propagation chain construction more reliable; the access time field is parsed as the event_time and normalized according to a unified time zone; if the access record has fields such as response code, access result, and audit conclusion, this embodiment can map them to status identifier status_id (e.g., 2xx / success, 4xx / failure, 5xx / abnormal), and set to empty if they do not exist.

[0030] For authentication records, the authentication subject field is typically a user account, terminal name, or a combination thereof. In this embodiment, it is parsed as a source identifier (source_id), and information such as domain name, tenant, and hostname can be concatenated in a standardized manner to form a globally unique subject identifier (e.g., domain\username). The authentication object field is typically an authentication service, domain controller, application system, or resource. In this embodiment, it is parsed as an object identifier (object_id) and can be mapped to an asset ID using an asset ledger. The authentication result field has explicit semantics such as success / failure / lock. In this embodiment, it is mapped as a status identifier (status_id), and the result codes from different systems are unified into a unified enumeration (e.g., SUCCESS, FAIL, LOCKED, EXPIRED) according to a preset result code mapping table. The authentication time field is parsed as the event time (event_time) and formatted uniformly. Specifically, the authentication action category is parsed into a behavior identifier: if the authentication record directly provides an action category field, such as logon_type, event_action, or auth_type, it is directly read and converted to behavior_id according to the action mapping table, such as LOGIN, LOGOUT, TGT_REQUEST, or PASSWORD_CHANGE; if the authentication record only provides an event ID or message template without an action field, it is inferred from the preset event ID to action category mapping table. For example, Windows event 4624 is mapped to LOGIN_SUCCESS, and 4625 is mapped to LOGIN_FAIL, thus ensuring that the source of the authentication action category is clear and executable. To uniformly convert authentication result fields, access result fields, or device running status fields from different source logs into the status identifier required by this application, the system pre-establishes and stores a result code mapping table during the deployment initialization phase. The result code mapping table can be stored in a configuration file or a database. The result code mapping table at least includes the record type, original field name, matching method, matching content, and corresponding unified status identifier. When the system executes step S12, it first reads the corresponding result field according to the record type, then matches it according to the result code mapping table and outputs the status identifier. The matching order can be set to perform exact matching first, and then containment / keyword matching. When the result field is missing or no mapping rule is hit, the status identifier is set to UNKNOWN or a null value, so as to ensure that the result expressions of different systems can be normalized and used for subsequent risk unit calculation and situation inference.

[0031] The preset result code mapping table is shown in Table 1; Table 1; ; For device records, the device number field can be the device serial number, host ID, agent_id, or device management IP. In this embodiment, it is parsed as the source identifier (source_id) and can be further mapped to the device asset ID in the CMDB to achieve unified identification across logs. The running object field can be the interface name, process name, policy ID, module name, port, or rule number. In this embodiment, it is parsed as the object identifier (object_id) and common formats are standardized, such as unifying interface Gi0 / 1 and GigabitEthernet0 / 1. The running status field can be UP / DOWN, NORMAL / ALARM, or CPU high / memory high. In this embodiment, it is mapped as the status identifier (status_id) and unified into a finite set according to a preset status mapping table, such as NORMAL, WARNING, CRITICAL, and DOWN.

[0032] The preset state mapping table is shown in Table 2; Table 2; ; The record time field is parsed as the occurrence time (event_time) and formatted uniformly. In this embodiment, the possible implementation method for parsing the device action field as a behavior identifier is specified as follows: If fields such as event_type, operation, and action exist in the device log, they are directly read as action fields and mapped to behavior_id, such as INTERFACE_FLAP, POLICY_CHANGE, PROCESS_START, and PROCESS_STOP; if no explicit action field exists, the action category can be inferred based on the log level, message template keywords, or alarm codes according to keyword / alarm code mapping rules, thus making the acquisition path of the "device action field" clear and reproducible.

[0033] After all four types of records have completed field parsing, the parsed source identifier, behavior identifier, object identifier, occurrence time, and status identifier are matched to their corresponding fields. The five types of fields are then filled into fixed slots in the unified record unit. During initialization, the system predefines the field structure template for the unified record unit, for example, including source_id, behavior_id, object_id, event_time, and status_id in a fixed order or with a fixed key set. At runtime, source_id is written to the source identifier slot, behavior_id to the behavior identifier slot, object_id to the object identifier slot, event_time to the occurrence time slot, and status_id to the status identifier slot. For missing fields, null values / unknown are filled according to a preset default strategy, and the source type and parsing confidence of the field are recorded for subsequent quality control.

[0034] In specific implementation, step S2 includes: Step S21: Read the current security event and the next security event in the security event sequence according to the order of arrangement; Step S22: Extract the source identifier, behavior identifier, object identifier, and occurrence time of the current security event, and extract the source identifier, behavior identifier, object identifier, and occurrence time of the next security event; Step S23: Determine whether the current security event and the next security event satisfy a continuity relationship; The continuity relationships include source continuity relationships, object continuity relationships, behavior connection relationships, and temporal adjacency relationships; Step S24: When the current security event and the next security event satisfy the continuity relationship, the current security event and the next security event are grouped into the same event group, and the next security event after the next security event is read. Steps S22 to S24 are repeated until the continuity relationship is no longer satisfied. Step S25: Sequentially integrate the occurrence sequence, duration, and involved objects of each safety event within the event group to generate corresponding risk units; Step S26: Repeat steps S21 to S25 according to the reading order of the security event sequence to organize each risk unit into a risk unit sequence according to the generation order.

[0035] Specifically, reading the security event sequence according to the order of occurrence means that the security event sequence has been sorted according to the order of occurrence in step S14. The system reads the security events in this order, and determines the currently read security event as the current security event, and determines the next security event in the security event sequence as the next security event. When multiple security events occur at the same time, in order to ensure the stability of the reading order, it is preferable to further sort them according to the source identifier, object identifier, or security event identifier information during the sorting in step S14, so that the adjacency relationship of "current security event / next security event" is consistent in each run.

[0036] Continuity relationships include source continuity relationships, object continuity relationships, behavior continuity relationships, and temporal adjacency relationships. In this embodiment, all of these are determined using directly executable judgment methods. Source continuity relationships are used to characterize whether adjacent security events are initiated by the same source entity. In this embodiment, the system compares the source identifier of the current security event with the source identifier of the next security event for consistency. If they are the same, it is determined that the source continuity relationship is satisfied. Considering that different data sources may have different representations of the same source entity, this embodiment preferably performs unified format processing on the source identifier in the field parsing stage of step S12 before comparison. For example, account-type source identifiers are uniformly represented by uppercase and lowercase letters and field prefixes, and address-type source identifiers are uniformly represented by standardized addresses, thereby reducing the break in continuity relationships caused by differences in representation of the same source. Object continuity is used to characterize whether adjacent security events point to the same object entity. In this embodiment, the system compares the object identifier of the current security event with the object identifier of the next security event. If they are the same, the system determines that the object continuity is satisfied. When the object identifier is an access target field and contains variable parameters, in order to avoid the same resource being misjudged as different objects due to different parameters, this embodiment prefers to normalize the object identifier before comparison. For example, irrelevant variable parameters are removed from the access target field or it is templated according to preset rules, so that the same resource can still correspond to the same object identifier under different request parameters. Behavioral continuity is used to characterize whether the behaviors of adjacent security events belong to the same type of continuous behavior or are in a connectable behavior stage. In this embodiment, the method of determining whether the behavior identifiers are the same or can be merged is adopted: when the behavior identifier of the current security event is the same as the behavior identifier of the subsequent security event, it is determined that the behavioral continuity relationship is satisfied; when the two are different but can be merged into the same behavior category under the preset action merging rules, it is also determined that the behavioral continuity relationship is satisfied. At the same time, in order to adapt to the situation where there are phased changes in behavior in multi-stage attacks or operation and maintenance operations, this embodiment can also use pre-configured behavioral continuity rules to determine the continuity of behavior identifiers. For example, scanning behavior and subsequent brute-force behavior, brute-force behavior and subsequent authentication failure / authentication success behavior, and authentication success behavior and subsequent permission change or policy change behavior are set as connectable, so that the same continuous activity can still be correctly merged when the behavior changes.Temporal adjacency is used to limit the reasonable range of adjacent security events belonging to the same continuous activity in time. In this embodiment, when the time interval between the occurrence time of the subsequent security event and the occurrence time of the current security event is not greater than a preset temporal adjacency threshold, it is determined that the temporal adjacency relationship is satisfied. The preset temporal adjacency threshold is preferably set in the range of 10 seconds to 30 minutes, wherein in interactive attack or high-frequency event scenarios, it is preferably 30 seconds to 10 minutes to avoid the threshold being too large, causing irrelevant events to be merged, and at the same time, to avoid the threshold being too small, causing the same activity to be fragmented. In low-frequency operation and maintenance or configuration change scenarios, it is preferable to take 10 minutes to 30 minutes to cover reasonable waiting and intervals in the operation chain. Based on the determination of the above four types of relationships, this embodiment preferably combines the source continuity relationship, object continuity relationship and behavior connection relationship for comprehensive judgment under the premise that the temporal adjacency relationship is established, so as to balance the completeness and accuracy of merging. For example, in this embodiment, the determination condition of satisfying the continuity relationship is that the temporal adjacency relationship is established and the behavior connection relationship is established, and at least one of the source continuity relationship and object continuity relationship is established, thereby avoiding the mis-merging of unrelated events simply because they are close in time.

[0037] When a current security event and a subsequent security event satisfy a continuity relationship, the system groups them into the same event group and uses the subsequent security event as the new current security event to continue reading the next security event, repeating steps S22 to S24 until the continuity relationship with the next security event is no longer satisfied. The resulting event group contains a set of security events that are continuous in terms of source, object, behavior, and time. In step S25, the system sequentially integrates the occurrence order, duration, and involved objects of each security event within the event group to generate a risk unit: In this embodiment, the occurrence order is determined by the order in which the security events within the event group occur; the start time of the risk unit is the earliest occurrence time within the event group, the end time of the risk unit is the latest occurrence time within the event group, and the duration of the risk unit is the length of time between the start time and the end time, thus giving the time boundary of the continuous activity; the integration of involved objects is preferably based on the order of appearance of object identifiers within the event group to form an object trajectory, or based on the deduplicated object identifiers to form a set of involved objects, so as to simultaneously take into account process sequence information and coverage information. Furthermore, to correspond with the data requirements of subsequent steps S3 and S4, this embodiment preferably generates behavioral trajectories when generating risk units. The behavioral trajectories are obtained by sequentially extracting and organizing the behavioral identifiers of security events within an event group according to their occurrence order, thereby reflecting the behavioral evolution process of the continuous activity. Simultaneously, the risk unit preferably records the number of events, the number of objects, and the number of state changes. The number of events refers to the number of security events within the event group, the number of objects refers to the number of object identifiers in the set of involved objects, and the number of state changes refers to the number of times the state identifiers of adjacent security events within the event group changed or the cumulative number of changes in the state identifier values ​​within the event group. This allows for quantitative evaluation and recursive accumulation processing of the risk unit in subsequent steps. Since the generation of event groups is constrained based on continuous relationships, the source identifiers of security events within the event group are usually consistent. Therefore, the source identifier of the risk unit is selected from the source identifiers of security events within the event group, and together with the behavioral trajectory, involved objects, start time, end time, and duration, constitutes the content of the risk unit. In step S26, the system repeats the above merging and integration process according to the reading order of the security event sequence, and organizes each risk unit into a risk unit sequence according to the generation order, thereby providing a structured, low-noise input with process semantics for subsequent situation evolution calculation and risk propagation chain construction based on the monitoring cycle.

[0038] Compared to traditional methods that output alarms one by one for security events, simply count and aggregate events according to fixed time windows, or rely on manual experience to post-process multiple alarms, this application can automatically identify and merge multiple adjacent security events corresponding to the same continuous activity at the security event sequence level. This significantly reduces noise caused by repetitive and fragmented events, while retaining the time boundaries, scope of involved objects, and behavioral trajectory information of continuous activities. This allows subsequent step S3 to perform continuity relationship matching and situational inference at a more stable risk unit granularity, and step S4 to generate risk propagation chains and output warning sequences more reliably based on the connection relationships between risk units. In addition, during merging, only adjacent reading and judgment are required along the security event sequence. The processing is more suitable for online incremental processing in big data scenarios and naturally connects with the inference update mechanism of step S5, thereby improving the real-time performance and stability of dynamic warnings.

[0039] In specific implementation, step S3 includes: Step S31: Read the current risk units belonging to the current monitoring period in the risk unit sequence according to the monitoring cycle order; Step S32: Within the preset backtracking range prior to the current monitoring period, find the preceding risk unit that satisfies the continuity relationship with the current risk unit, and read the preceding situation value corresponding to the preceding risk unit; The preset backtracking range is the previous four monitoring cycles of the current monitoring cycle; The continuity relationships include source identifier continuity relationships, object identifier continuity relationships, and behavioral trajectory connection relationships; Step S33: The current unit value of the current risk unit is recursively accumulated with the previous situation value of the previous risk unit to generate the current situation value corresponding to the current monitoring period. Step S34: Organize the current situation values ​​into a situation evolution sequence according to the monitoring cycle order; Step S35: Read the previous and next situation values ​​corresponding to adjacent monitoring periods in the situation evolution sequence, and calculate the situation change. Step S36: Read the continuous situational change data in the order of the monitoring cycle, identify the direction of change and the continuous state of change, and generate change identification results; The change identification results include growth change indicators, decline change indicators, stable change indicators, continuous growth indicators, continuous decline indicators, fluctuation change indicators, and turning point change indicators.

[0040] Specifically, the monitoring period refers to the time window for segmenting the target network operation data. The system pre-sets the length of the monitoring period during the deployment initialization phase and divides the time axis into continuous period intervals according to this length. The monitoring period is determined by whether the start or end time of a risk unit falls within the current monitoring period interval, thereby ensuring that the risk units corresponding to each monitoring period can be stably collected.

[0041] The system searches for preceding risk units that satisfy the continuity relationship with the current risk unit within a preset backtracking range prior to the current monitoring period. The preset backtracking range is the four monitoring periods prior to the current monitoring period, corresponding to the segmented setting of the decreasing coefficient.

[0042] The continuity relationships include source identifier continuity relationships, object identifier continuity relationships, and behavior trajectory connection relationships. The source identifier continuity relationship characterizes whether the current risk unit and its predecessor risk unit originate from the same source entity. In this embodiment, the system performs a consistency comparison between the source identifier of the current risk unit and the source identifier of the candidate predecessor risk unit. If they are the same, the system determines that the source identifier continuity relationship is satisfied. To reduce continuity interruptions caused by representation differences of the same source in different log sources, the source identifier has been processed into a unified format before comparison in step S12 field parsing. The object identifier continuity relationship characterizes whether the current risk unit and its predecessor risk unit point to the same object entity. The system compares the object identifiers in the objects involved in the current risk unit with the object identifiers in the objects involved in the candidate predecessor risk unit. If they have the same object identifier, the system determines that the object identifier continuity relationship is satisfied. When the object identifier has a high cardinality or variable parameters, the object identifier has been normalized in step S12 field parsing before comparison, thereby improving the stability of object continuity judgment. The behavioral trajectory continuity relationship is used to characterize whether the behavioral trajectory of the current risk unit and the behavioral trajectory of the preceding risk unit constitute a continuity in security semantics. A "end-to-start continuity" processing method is used to determine the behavioral trajectory: the system reads the end behavior identifier of the preceding risk unit's behavioral trajectory and the start behavior identifier of the current risk unit's behavioral trajectory. If they are the same, the behavioral trajectory continuity relationship is satisfied. If the merged end behavior identifier and the merged start behavior identifier are different, but can be determined to be continuous according to the preset behavioral continuity rules, the behavioral continuity relationship is also satisfied; otherwise, the behavioral continuity relationship is not satisfied. The preset behavioral continuity rules are preferably pre-set in the form of a configuration table during the system initialization phase to describe reasonable continuity relationships between common security activity phases, thus avoiding the same continuous risk activity being split into unrelated segments due to changes in behavioral phases. When multiple candidate preceding risk units satisfying the continuity relationship exist in the previous monitoring period, the candidate with a higher degree of overlap in object identifier and a tighter behavioral trajectory continuity with the current risk unit is selected as the preceding risk unit, thereby improving the accuracy of recursive cumulative matching.

[0043] The system recursively accumulates the current unit value of the current risk unit with the previous situation value of the preceding risk unit to generate the current situation value corresponding to the current monitoring period. The recursive accumulation calculation is achieved by superimposing the current contribution with historical impact: the current situation value at least includes the current risk intensity reflected by the current unit value, while retaining the historical risk residual effect reflected by the preceding situation value. To avoid the historical situation from unreasonably dominating the current situation in the long term, a decreasing process is introduced for the preceding situation value, so that the historical impact of risk activities gradually weakens after a period of interruption, thus more closely resembling the decay law of real network risks over time. The strength of the decreasing process can be controlled by preset parameters, preferably ensuring that the historical impact decays significantly within three monitoring periods, balancing the ability to remember continuous attacks with the ability to quickly cool down ended events. If there is no preceding risk unit satisfying the continuity relationship in the previous monitoring period, the current unit value is directly determined as the current situation value to ensure that the situation evolution sequence can be established starting from newly emerging risk activities. In step S34, the system sequentially writes each current situation value into the situation evolution sequence and the corresponding position of the monitoring cycle according to the monitoring cycle order, so that the situation evolution sequence can continuously express the evolution process of risk intensity over time.

[0044] The situational evolution sequence reads the previous and next situational values ​​corresponding to adjacent monitoring periods and calculates the situational change. The situational change is calculated by the difference between the change of the next situational value and the previous situational value, that is, by comparing the size of the situational values ​​of two adjacent monitoring periods to obtain the change amplitude. When the dimensions of situational values ​​differ significantly between different networks or different stages, the change can also be normalized by using the relative change of the difference with respect to the previous situational value. The situational change is calculated as: Situational change = (next situational value - previous situational value) / previous situational value. This method of normalizing situational values ​​of different magnitudes by using relative change reduces the impact of dimensional differences on change identification. If the current situation value is zero, and the next situation value is greater than zero, then the situation change is assigned a value of positive infinity and directly identified as an increasing change indicator. If the subsequent situation value is also zero, the situation change is assigned a value of zero and identified as a stable change, in order to reduce the impact of dimensional differences on change identification. However, regardless of the method used, the goal is to reflect the characteristics of rising, falling, or nearly unchanged changes. To avoid misjudgment due to occasional small fluctuations, this embodiment preferably pre-sets a stability judgment threshold. The stability judgment threshold is preferably set as a certain percentage or a fixed small range of the previous situation value, preferably 5%. This is because this range can usually filter out small changes caused by jitter and discrete events, while still retaining sensitivity to the increase in real risk.

[0045] The system reads continuous trend changes sequentially according to the monitoring cycle, identifies the direction of change and the continuity of change, and generates change identification results. The direction of change is identified based on the directionality of the trend change: when the trend change is greater than the stability threshold, it is identified as an increasing trend; when the trend change is less than the negative stability threshold, it is identified as a decreasing trend; and when the trend change falls within the interval corresponding to the stability threshold, it is identified as a stable trend. The continuity of change is used to identify the persistence, volatility, and direction transition of the above directions over multiple monitoring cycles. This is achieved using continuous counting and direction sequences: when several consecutive monitoring cycles are identified as increasing trends, a continuous increasing trend is further generated; when several consecutive monitoring cycles are identified as decreasing trends, a continuous decreasing trend is further generated. The number of consecutive monitoring cycles for determining continuity is set to 3 to 5 monitoring cycles. Fewer than 3 cycles may easily misjudge short-term spikes as continuous trends, while more than 5 cycles may reduce the response speed to trend formation. The fluctuation indicator represents the alternation or frequent switching between growth and decline indicators over several consecutive monitoring periods. The number of directional switches is counted within a preset observation window. A fluctuation indicator is generated when the number of switches reaches a preset threshold. The preferred observation window is five monitoring periods to capture short-term fluctuations without oversensitivity. The turning point indicator represents a clear inflection point in the trend evolution, indicating a shift from growth to decline or vice versa. A turning point indicator is generated when the direction of change reverses between two adjacent monitoring periods, and the magnitude of the change exceeds the stability threshold, thus distinguishing trend reversal from general fluctuations. Through these identifications, the change identification results can provide a combination output of growth, decline, and stability indicators, along with their persistence, volatility, and turning point indicators, for each monitoring period, corresponding to the trend evolution sequence across monitoring periods.

[0046] Compared to traditional methods that only statically count the number of alarms in a single cycle or only display the situation value at a single point without considering cross-cycle continuation and historical residual effects, this application associates risk units across the monitoring cycle through continuation relationships and uses recursive accumulation to continuously express the current risk and historical risk residual effects in the situation value. This can more accurately depict the situation evolution process of continuous attacks, intermittent attacks, or gradually escalating attacks. At the same time, based on the situation evolution sequence, it further outputs change identification results, enabling the system to not only reflect the current level of risk, but also whether the risk is rising, falling, stable, continuously rising / falling, fluctuating, or undergoing a turning point. This provides a more time-series-meaning basis for subsequently outputting early warning sequences in conjunction with the risk propagation chain, improving the timeliness, continuity, and interpretability of dynamic early warnings.

[0047] In specific implementation, the processing logic of step S33 is as follows: Step S331: Read the number of events, duration, number of objects, and number of status changes corresponding to the current risk unit within the current monitoring period, and calculate the current unit value based on the number of events, duration, number of objects, and number of status changes; Step S332: Read the preceding situation value corresponding to the preceding risk unit that has a continuity relationship with the current risk unit in the previous monitoring period; Step S333: Determine if the preceding risk unit exists; If the preceding risk unit exists, execute step S334; If the current risk unit does not exist, the current unit value is determined as the current situation value; Step S334: Read the number of interval periods between the previous risk unit and the current risk unit, and generate a decreasing coefficient based on the number of interval periods; Step S335: The current unit value and the previous situation value are recursively accumulated according to the decreasing coefficient to generate the current situation value; Step S336: Write the current situation value into the situation evolution sequence position corresponding to the current monitoring period.

[0048] Specifically, the system first directly reads the number of events, duration, number of objects, and number of state changes from the current risk unit, and converts these four indicators into comparable quantitative scores. Then, it weights and synthesizes the four scores according to preset weights to obtain the current unit value. The conversion of quantitative scores preferably uses a segmented assignment method to avoid the unreasonable dominance of any one indicator by differences in the scale of different indicators. For example, the number of events, used to characterize the intensity of risk activities, is preferably mapped to scores from low to high within intervals, i.e., the more events, the higher the score. The duration, used to characterize the persistence of risk activities, is mapped to scores within intervals from seconds to minutes to hours, i.e., the longer the duration, the higher the score. The number of objects, used to characterize the scope of influence, is mapped to scores within intervals from few to many objects involved, i.e., the more objects, the higher the score. The number of state changes, used to characterize the instability or abnormal recurrence of states, is mapped to scores within intervals from few to many changes, i.e., the more changes, the higher the score. In terms of weighting, considering that the number of events and the number of objects reflect intensity and scope respectively, the duration reflects persistence, and the number of state changes reflects abnormal fluctuation characteristics, the weights of the number of events, duration, and number of objects are higher than the weight of the number of state changes, and the sum of each weight is 1. The weight of the number of events is set at 0.35, reflecting the density and intensity of the current risk activity, which is usually most sensitive to the rise in risk, so a higher weight is preferred. The weight of duration is set at 0.25, reflecting the persistence of risk activity, which can suppress misjudgments caused by short-term surges, so a medium-to-high weight is preferred. The weight of the number of objects is set at 0.25, reflecting the scope of influence and the degree of horizontal expansion, which, together with the number of events, characterizes the scale of risk, so a medium-to-high weight is preferred. The weight of the number of state changes is set at 0.15, reflecting abnormal recurrence or unstable state, but it is greatly affected by different data source recording methods. Too high a weight may amplify noise, so a lower weight is preferred. The reason is that the first three items are more stable and better represent the scale characteristics of risk activities, while the number of state changes is easily affected by differences in collection or system recording methods, and too high a weight may amplify noise. The current unit value can simultaneously reflect the comprehensive level of the current risk unit in terms of density, persistence, scope of influence and state fluctuation, and facilitates comparability across different monitoring periods and different data sources.

[0049] The system generates a decreasing coefficient based on the number of interval periods. It reads the number of interval periods between the monitoring period of the preceding risk unit and the monitoring period of the current risk unit. The larger the interval period, the more discontinuous the two are in time, and the weaker the influence of the preceding situation value on the current situation should be. Therefore, the decreasing coefficient is preferably set to decrease monotonically with the number of interval periods, and its value is between 0 and 1. In this embodiment, a segmented decreasing method is used to generate the decreasing coefficient: when the number of interval periods is 1, the decreasing coefficient is 1 to fully inherit the historical influence of the adjacent period; when the number of interval periods is 2, the decreasing coefficient is preferably 0.75 to reflect partial inheritance after a brief interruption; when the number of interval periods is 3, the decreasing coefficient is preferably 0.5; when the number of interval periods is greater than or equal to 4, the decreasing coefficient is preferably 0.3, so that the historical situation after a long interruption retains only a weak residual effect on the current situation. If the decreasing is too slow, historical risks will remain for a long time, making it difficult for the situation to decline; if the decreasing is too fast, intermittent continuous attacks will appear as multiple fragments in the situation evolution sequence, which is not conducive to trend identification. The current situation value is generated by recursively accumulating the current unit value and the previous situation value using a decreasing coefficient. Specifically, when a previous risk unit exists, the system uses the current unit value of the current monitoring period as the new contribution, and the previous situation value of the previous risk unit after being weakened by the decreasing coefficient as the historical contribution. The current situation value is obtained by weighted summation of the new contribution and the historical contribution, and its calculation formula is as follows: ; in, This represents the current situation value. The new contribution for this period calculated for the current risk unit. This is a decreasing coefficient, and its value is set in segments based on the number of periods between the current risk unit and the previous risk unit, in order to reflect the pattern of historical impact decaying over time. The current situation value corresponds to the preceding risk unit; this ensures that the situation evolution sequence reflects both the intensity of newly occurring risks within the current period and maintains a continuous expression of risks from previous periods. When no preceding risk unit exists, the system directly determines the current unit value as the current situation value, allowing for the establishment of a new situation evolution starting from the current monitoring period. To prevent the situation value from increasing indefinitely under prolonged continuous activity, an upper limit constraint or normalization is applied to the current situation value, making the situation changes and change identification in subsequent steps S35 and S36 more stable and interpretable. Finally, step S336 writes the generated current situation value into the situation evolution sequence position corresponding to the current monitoring period, ensuring that the situation evolution sequence is continuously updated in the order of the monitoring period and can be used for subsequent change identification and early warning output.

[0050] In specific implementation, step S4 includes: Step S41: Read the current risk unit and the next risk unit in the risk unit sequence according to the arrangement order; Step S42: Extract the source identifier, object identifier, behavior trajectory, and end time of the current risk unit, and extract the source identifier, object identifier, behavior trajectory, and start time of the next risk unit; Step S43: Determine whether the current risk unit and the next risk unit satisfy the connection relationship; The connection relationships include source connection relationships, object connection relationships, behavior connection relationships, and time connection relationships; Step S44: When the current risk unit and the next risk unit satisfy the connection relationship, connect the current risk unit and the next risk unit to the same propagation chain group, and continue to read the next risk unit after the next risk unit. Repeat steps S42 to S44 until the connection relationship is no longer satisfied. Step S45: Arrange the risk units within the propagation chain group according to the connection order to generate the corresponding risk propagation chain; Step S46: Repeat steps S41 to S45 according to the reading order of the risk unit sequence, and write each generated risk propagation chain into the risk propagation chain sequence in sequence. Step S47: Read the change identification results corresponding to each risk propagation chain, generate corresponding early warning icons according to the arrangement order of the risk propagation chains, and organize the early warning icons into an early warning sequence according to the generation order.

[0051] Specifically, the connection relationships include source connection relationships, object connection relationships, behavior connection relationships, and time connection relationships. Source connection relationships characterize whether two adjacent risk units are triggered by the same source entity or have continuous control paths. The system compares the source identifier of the current risk unit with the source identifier of the next risk unit for consistency; if they match, the source connection relationship is satisfied. Considering that source identifiers may come from different data sources and have different representations, the source identifiers are formatted in a unified way during field parsing in step S12 before comparison to reduce link breaks caused by splitting the same source. Object connection relationships characterize whether risk propagation points to the same object or extends from the current object to the next object. The system compares the object identifier of the current risk unit with the object identifier of the next risk unit; if they match, the object connection relationship is satisfied. When multiple object identifiers are integrated during risk unit generation, the object identifier of the next risk unit belonging to the object involved in the current risk unit is used as one of the conditions for the establishment of the object connection relationship. This supports propagation scenarios where a specific object is hit first, and then extended to related resources of that object, and avoids misconnection of different objects based solely on temporal proximity. Behavioral continuity is used to characterize whether the behavioral trajectory of the current risk unit is semantically continuous with that of the next risk unit. It employs an end-to-start continuity approach: the system reads the end behavior identifier of the current risk unit's behavioral trajectory and the start behavior identifier of the next risk unit's behavioral trajectory. Before comparison, a preset action merging rule is used to merge the end and start behavior identifiers respectively. If the merged end behavior identifier is the same as the merged start behavior identifier, the behavioral continuity is satisfied; otherwise, it is deemed not to satisfy the behavioral continuity relationship. Temporal continuity is used to determine whether the current risk unit and the next risk unit are temporally continuous. For example, if the interval between the start time of the next risk unit and the end time of the current risk unit does not exceed a preset threshold, the temporal continuity is satisfied; otherwise, it is deemed not to satisfy the temporal continuity relationship.

[0052] When the current risk unit and the next risk unit satisfy the connection relationship, the current risk unit and the next risk unit are connected to the same propagation chain group, and the process continues to read the next risk unit after the next risk unit and repeat the judgment until the connection relationship is no longer satisfied. Connecting to the same propagation chain group is achieved by appending and recording risk units in the propagation chain group in the order of reading, and simultaneously recording the connection order between risk units, so that a connection order from early to late is naturally formed within the propagation chain group. The implementation method of "arranging the links of each risk unit in the propagation chain group according to the connection order to generate the corresponding risk propagation chain" in step S45 is as follows: Since the propagation chain group is formed by connecting each risk unit one by one according to the connection relationship during the reading of the risk unit sequence, this embodiment preferably uses the order in which the risk units are added to the propagation chain group as the link arrangement order. The first risk unit added is determined as the starting risk unit of the risk propagation chain, and the last risk unit added is determined as the ending risk unit of the risk propagation chain, thereby generating a risk propagation chain that can reflect the sequence of propagation process. When there are cases in the propagation chain group where the start time is the same, which may cause the addition order to be unstable, the risk units in the propagation chain group are stably sorted according to the start time and end time, and then the links are arranged according to the sorting result to ensure that the risk propagation chain generation result is consistent. In step S46, each risk propagation chain is sequentially written into the risk propagation chain sequence. In step S47, the change identification results corresponding to each risk propagation chain are read to generate an early warning identifier and written into the early warning sequence. The change identification results corresponding to the risk propagation chain are preferably taken from the change identification results obtained in step S3 of the end risk unit of the risk propagation chain, so that the early warning identifier reflects the situational change characteristics of the risk propagation chain at the current stage and maintains a clear correspondence.

[0053] Compared to traditional methods that only provide isolated warnings for single alarms or individual risk units, or simply connect alarms based on time proximity, this application imposes multi-dimensional constraints on risk unit connections through source connection relationships, object connection relationships, behavioral connection relationships, and temporal connection relationships. This ensures the temporal rationality of the propagation chain while improving the semantic consistency and interpretability of the connections, reducing false alarms caused by misconnection of unrelated risk units, and minimizing missed alarms caused by the fragmentation of multi-stage activities due to object expansion or behavioral stage changes. Furthermore, it associates the risk propagation chain with the change identification results to generate a warning sequence, so that the warning output not only indicates the existence of a propagation chain, but also reflects the growth, decline, stabilization, continuity, volatility, and turning point of its corresponding situation, thereby improving the continuity, timeliness, and engineering usability of dynamic warnings.

[0054] In specific implementation, the processing logic of step S47 is as follows: Step S471: Read the change identification results corresponding to the current risk propagation chain according to the arrangement order of the risk propagation chain sequence; Step S472: When the change identification result includes a continuous growth indicator, generate a first warning indicator; Step S473: When the change identification result includes both growth change identifier and fluctuation change identifier, or only includes growth change identifier and does not include fluctuation change identifier, a second warning identifier is generated. Step S474: When the change identification result includes a stable change indicator, a third early warning indicator is generated; Step S475: When the change identification result includes a falling change indicator, a continuous falling change indicator, or a turning change indicator, a fourth warning indicator is generated. Step S476: Write the first warning identifier, the second warning identifier, the third warning identifier, or the fourth warning identifier into the warning sequence position corresponding to the current risk transmission chain; Step S477: Continue reading the change identification results corresponding to the next risk propagation chain, and repeat steps S472 to S476 until the risk propagation chain sequence reading is completed.

[0055] Specifically, the first warning indicator indicates that the current risk propagation chain is in a state of continuous growth. The first warning indicator is generated when the change identification result includes a continuous growth indicator. The warning intensity corresponding to this first warning indicator is preferably the highest, indicating that the risks related to the risk propagation chain are continuously increasing over multiple monitoring periods and require priority handling. The second warning indicator indicates that the current risk propagation chain is in a state of both growth and fluctuation. The second warning indicator is generated when the change identification result includes both growth and fluctuation indicators. The second warning indicator indicates that the overall risk is showing an increasing trend but is accompanied by fluctuations, requiring continuous monitoring and consideration in conjunction with propagation. The chain is further analyzed; the third early warning indicator is used to indicate that the current situation corresponding to the risk propagation chain is in a stable early warning state. When the change identification result includes the stable change indicator, the third early warning indicator is generated. The third early warning indicator is used to indicate that the risk related to the risk propagation chain is not significantly changing in the short term and is suitable for continued monitoring. The fourth early warning indicator is used to indicate that the current situation corresponding to the risk propagation chain is in a declining or turning point early warning state. When the change identification result includes the declining change indicator, the continuous declining indicator, or the turning point indicator, the fourth early warning indicator is generated. The fourth early warning indicator is used to indicate that the risk related to the risk propagation chain is decreasing or has reached a trend inflection point, and can be used for downgrading or prompting review. To avoid the same change identification result triggering multiple early warning indicators simultaneously, resulting in non-unique outputs, the judgment and generation of early warning indicators are performed in the order of steps S472 to S475, so that the first early warning indicator has the highest priority, followed by the second, third, and fourth early warning indicators, thereby ensuring that each risk propagation chain corresponds to only one early warning indicator in the early warning sequence and that the meaning is clear.

[0056] The first, second, third, or fourth warning identifier is written to the warning sequence position corresponding to the current risk propagation chain. This is achieved using a writing method where the same sequence number corresponds to the risk propagation chain sequence number: the system reads the current risk propagation chain sequentially according to its arrangement, and uses the sequence number of the current risk propagation chain in the risk propagation chain sequence as its corresponding position in the warning sequence; after generating the first, second, third, or fourth warning identifier, the system writes the warning identifier to the position in the warning sequence that matches the specified sequence number, thus ensuring that the warning sequence and the risk propagation chain sequence maintain consistent arrangement order and correspond one-to-one. Specifically, the warning sequence can be a sequential storage structure: when the k-th risk propagation chain is read, the generated warning identifier is appended to the k-th position of the warning sequence; or the warning sequence can be a randomly writable storage structure: when the k-th risk propagation chain is read, the warning identifier is written to the k-th slot of the warning sequence. With this writing method, when outputting the early warning sequence, each risk propagation chain and its corresponding early warning identifier can be output simultaneously according to the sequence number, avoiding the problem of misalignment between the early warning identifier and the risk propagation chain.

[0057] In specific implementation, step S5 includes: Step S51: Receive the operation data for the next monitoring cycle, perform unified structure processing on the operation data, and generate new security events; Step S52: Write the newly added security events sequentially to the end of the security event sequence according to their occurrence time to obtain the updated security event sequence; Step S53: Read the new security events starting from the end of the updated security event sequence, and perform a merge process based on the continuity relationship to obtain new risk units. Write the new risk units sequentially to the end of the risk unit sequence to obtain the updated risk unit sequence. Step S54: Read the newly added risk units starting from the end of the updated risk unit sequence, and perform recursive accumulation and change identification processing based on the continuation relationship to obtain the new situation value and the new change identification result. Write the new situation value into the end of the situation evolution sequence in sequence to obtain the updated situation evolution sequence. Step S55: Starting from the end of the updated risk unit sequence, read the newly added risk units, perform connection processing based on the connection relationship to obtain the newly added risk propagation chain and the newly added early warning identifier, write the newly added risk propagation chain to the end of the risk propagation chain sequence in sequence, and write the newly added early warning identifier to the end of the early warning sequence in sequence to obtain the updated risk propagation chain sequence and the updated early warning sequence.

[0058] Specifically, the method for unifying the structure of operational data is consistent with step S1. After receiving operational data for the next monitoring cycle, the system parses the fields of traffic records, access records, authentication records, and device records, and extracts the source identifier, behavior identifier, object identifier, occurrence time, and status identifier based on preset field mapping rules. Then, it maps the positions of these fields according to the preset field structure, generating a unified record unit, and generating new security events based on this unified record unit. To ensure that new security events can still be generated even when real data has missing fields or inconsistent field formats, this embodiment also incorporates preset default strategies. For example, when a status identifier is missing or does not match the preset status mapping table, the status identifier is set to UNKNOWN or a null value. When the occurrence time parsing fails, the log reception time is preferably used as a substitute, and this record is recorded as belonging to the substitute time source. This ensures that new security events can be written into the security event sequence and participate in the subsequent judgment of continuous, continuation, and connection relationships.

[0059] New security events are sorted by their occurrence time and appended sequentially to the end of the security event sequence to obtain an updated security event sequence. When multiple new security events occur at the same time, to ensure a stable appending order, they are further sorted by source identifier, object identifier, or identifier information of the new security events. In step S53, new security events are read from the end of the updated security event sequence, and a merging process is performed based on continuity to obtain new risk units. The implementation method is as follows: the system takes the first new security event as the starting point, reads the previous security event near the end of the security event sequence (which may belong to the end of the previous monitoring period), and judges whether the two satisfy the continuity relationship judgment rule consistent with step S2. When the continuity relationship is satisfied, the new security event is merged into the event group with the previous security event, and the system continues to read the next new security event, repeats the continuity relationship judgment, and continuously expands the event group. When the continuity relationship is not satisfied, the new security event is used as the starting point of a new event group and the merging is restarted. After an event group is formed, the system sequentially integrates the occurrence order, duration, and involved objects of security events within the event group according to step S25 to generate new risk units. Specifically, the start time of the new risk unit is determined by the earliest occurrence time within the event group, the end time by the latest occurrence time, and the duration is determined by the time length between the start and end times. Object identifiers within the event group are integrated into an object identifier integration result according to their occurrence order, and behavioral identifiers within the event group are integrated into a behavioral trajectory according to their occurrence order. Simultaneously, information such as the number of events, the number of objects, and the number of state changes is recorded to ensure that the field meanings of the new risk units are consistent with those of existing risk units in the risk unit sequence and can be directly read by steps S3 and S4. Subsequently, the system appends the new risk units sequentially to the end of the risk unit sequence to obtain the updated risk unit sequence.

[0060] The implementation method for obtaining new situation values ​​and new change identification results based on the continuation relationship is as follows: The system reads new risk units starting from the end of the risk unit sequence and searches for preceding risk units that satisfy the continuation relationship within the previous monitoring period. If a preceding risk unit exists, its preceding situation value is read, along with the number of interval periods between the preceding risk unit and the new risk unit, and a decreasing coefficient is generated based on the number of interval periods. Subsequently, the system reads the number of events, duration, number of objects, and number of state changes corresponding to the new risk unit, and calculates the current unit value according to the configuration in step S331. Based on this, the current unit value and the preceding situation value are combined with the decreasing coefficient to perform recursive accumulation calculation to generate a new situation value, so that the new situation value simultaneously reflects the current risk intensity and historical residual effect. If no preceding risk unit exists, the current unit value is directly determined as the new situation value so that a new situation evolution can be established starting from the new risk unit. After generating the new situation value, the system appends the new situation value to the end of the situation evolution sequence and corresponds it to the monitoring period position to which the new risk unit belongs. The system then performs incremental processing on the change identification: it reads the previous situation value and the newly added situation value corresponding to the monitoring period in the situation evolution sequence, and calculates the situation change amount. In this embodiment, the situation change amount is obtained by comparing the change amplitude of the later situation value relative to the previous situation value, and the change direction is identified by combining it with a preset stability judgment threshold. Based on the direction sequence of continuous situation change amounts, the system further identifies the continuous change state and generates new change identification results. The new change identification results have the same meaning as step S36, including growth change identifier, decline change identifier, stable change identifier, continuous growth identifier, continuous decline identifier, fluctuation change identifier, and turning point change identifier.

[0061] The implementation method for obtaining new risk propagation chains and new early warning indicators based on the connection relationship is as follows: The system reads new risk units starting from the end of the risk unit sequence and determines the connection relationship with the risk unit at the end of the link corresponding to the end of the risk propagation chain sequence or with the immediately preceding risk unit in the risk unit sequence. If the connection relationship is satisfied, the system connects the new risk unit to the corresponding propagation chain group to form an extension of the new risk propagation chain. If the connection relationship is not satisfied, the system uses the new risk unit as the starting point of a new propagation chain group to generate a new new risk propagation chain. After the propagation chain group is formed, the system arranges the risk units in the propagation chain group according to the connection order in step S45 to generate a new risk propagation chain, and appends the new risk propagation chain to the end of the risk propagation chain sequence. Subsequently, the system reads the change identification result corresponding to the newly added risk propagation chain and generates a new warning identifier. The value range of the new warning identifier is consistent with that in step S47, including the first warning identifier, the second warning identifier, the third warning identifier, and the fourth warning identifier. The new change identification result corresponding to the end risk unit of the newly added risk propagation chain is used as the change identification result corresponding to the newly added risk propagation chain to ensure a clear correspondence and facilitate incremental updates. Then, the corresponding new warning identifier is generated according to the judgment order of steps S472 to S476, and the new warning identifier is appended to the end of the warning sequence to obtain the updated risk propagation chain sequence and the updated warning sequence.

[0062] Compared to traditional methods that recalculate all historical data in each monitoring cycle or statically output data based solely on single-cycle alarms, this application can incrementally process new data only from the end of the security event sequence, risk unit sequence, situation evolution sequence, risk propagation chain sequence, and early warning sequence. This reduces redundant calculations and storage read / write overhead, improving processing efficiency and real-time performance in big data scenarios. Furthermore, since new risk units, situation values, change identification results, risk propagation chains, and early warning identifiers are all generated using terms and structures consistent with existing sequences, the continuity and traceability of situation evolution and early warning output are guaranteed. This allows dynamic early warnings to be continuously and stably updated throughout the monitoring cycle and supports long-term operation.

[0063] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media containing computer-usable program code. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0064] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the protection scope of the present invention.

Claims

1. A dynamic early warning method for network security based on big data analysis, characterized in that, Includes the following steps: Step S1: Obtain the operational data generated by the target network in each monitoring period, perform unified structural processing on the operational data, and generate a sequence of security events according to the time of occurrence. Step S2: Based on the continuous relationship between adjacent security events in the security event sequence, perform merging processing to generate a risk unit sequence; Step S3: Based on the continuity relationship of the risk unit sequence in each monitoring period, perform cumulative processing to generate a situation evolution sequence, and identify changes in the situation evolution sequence to obtain the change identification result; Step S4: Generate a risk propagation chain sequence based on the connection relationship between risk unit sequences, and output an early warning sequence in combination with the change identification results; Step S5: Receive the operational data for the next monitoring cycle, and recursively update the security event sequence, risk unit sequence, situation evolution sequence, risk propagation chain sequence, and early warning sequence to obtain the updated security event sequence, updated risk unit sequence, updated situation evolution sequence, updated risk propagation chain sequence, and updated early warning sequence.

2. The network security dynamic early warning method based on big data analysis as described in claim 1, characterized in that, Step S1 specifically includes: Step S11: Obtain the operational data generated by the target network during the current monitoring period; The operational data includes traffic records, access records, authentication records, and device records; Step S12: Parse the fields of traffic records, access records, authentication records and device records to extract source identifier, behavior identifier, object identifier, occurrence time and status identifier; Step S13: Map the source identifier, behavior identifier, object identifier, occurrence time and status identifier to their positions according to the preset field structure, generate a unified record unit, and generate a corresponding security event based on each unified record unit; Step S14: Sort the security events according to their occurrence time, and organize the sorted security events into a security event sequence.

3. The network security dynamic early warning method based on big data analysis as described in claim 2, characterized in that, The processing logic for step S12 is as follows: Read field information from traffic records, access records, authentication records, and device records, and based on preset field mapping rules, parse the field information into source identifier, object identifier, behavior identifier, occurrence time, and status identifier; The processing logic for the preset field mapping rules is as follows: Read the communication address field, communication port field, protocol field, and transmission time field from the traffic record, and parse the initiating address in the communication address field into the source identifier, parse the receiving address in the communication address field into the object identifier, parse the combination of the protocol field and the communication port field into the behavior identifier, and parse the transmission time field into the occurrence time; Read the access subject field, access target field, access action field, and access time field from the access record, and parse the access subject field into a source identifier, the access target field into an object identifier, the access action field into a behavior identifier, and the access time field into the time of occurrence. Read the authentication subject field, authentication object field, authentication result field, and authentication time field from the authentication record, and parse the authentication subject field into a source identifier, the authentication object field into an object identifier, the authentication result field into a status identifier, the authentication time field into the time of occurrence, and the authentication action category into a behavior identifier; Read the device number field, running object field, running status field and recording time field from the device record, and parse the device number field into a source identifier, the running object field into an object identifier, the running status field into a status identifier, the recording time field into the occurrence time, and the device action field into a behavior identifier; The parsed source identifier, behavior identifier, object identifier, occurrence time, and status identifier are mapped to their corresponding fields.

4. The network security dynamic early warning method based on big data analysis as described in claim 3, characterized in that, Step S2 specifically includes: Step S21: Read the current security event and the next security event in the security event sequence according to the order of arrangement; Step S22: Extract the source identifier, behavior identifier, object identifier, and occurrence time of the current security event, and extract the source identifier, behavior identifier, object identifier, and occurrence time of the next security event; Step S23: Determine whether the current security event and the next security event satisfy a continuity relationship; The continuity relationships include source continuity relationships, object continuity relationships, behavior connection relationships, and temporal adjacency relationships; Step S24: When the current security event and the next security event satisfy the continuity relationship, the current security event and the next security event are grouped into the same event group, and the next security event after the next security event is read. Steps S22 to S24 are repeated until the continuity relationship is no longer satisfied. Step S25: Sequentially integrate the occurrence sequence, duration, and involved objects of each safety event within the event group to generate corresponding risk units; Step S26: Repeat steps S21 to S25 according to the reading order of the security event sequence to organize each risk unit into a risk unit sequence according to the generation order.

5. The network security dynamic early warning method based on big data analysis as described in claim 4, characterized in that, Step S3 specifically includes: Step S31: Read the current risk units belonging to the current monitoring period in the risk unit sequence according to the monitoring cycle order; Step S32: Within the preset backtracking range prior to the current monitoring period, find the preceding risk unit that satisfies the continuity relationship with the current risk unit, and read the preceding situation value corresponding to the preceding risk unit; The preset backtracking range is the previous four monitoring cycles of the current monitoring cycle; The continuity relationships include source identifier continuity relationships, object identifier continuity relationships, and behavioral trajectory connection relationships; Step S33: The current unit value of the current risk unit is recursively accumulated with the previous situation value of the previous risk unit to generate the current situation value corresponding to the current monitoring period. Step S34: Organize the current situation values ​​into a situation evolution sequence according to the monitoring cycle order; Step S35: Read the previous and next situation values ​​corresponding to adjacent monitoring periods in the situation evolution sequence, and calculate the situation change. Step S36: Read the continuous situational change data in the order of the monitoring cycle, identify the direction of change and the continuous state of change, and generate change identification results; The change identification results include growth change indicators, decline change indicators, stable change indicators, continuous growth indicators, continuous decline indicators, fluctuation change indicators, and turning point change indicators.

6. The network security dynamic early warning method based on big data analysis as described in claim 5, characterized in that, The processing logic for step S33 is as follows: Step S331: Read the number of events, duration, number of objects, and number of status changes corresponding to the current risk unit within the current monitoring period, and calculate the current unit value based on the number of events, duration, number of objects, and number of status changes; Step S332: Read the preceding situation value corresponding to the preceding risk unit that has a continuity relationship with the current risk unit in the previous monitoring period; Step S333: Determine if the preceding risk unit exists; If the preceding risk unit exists, execute step S334; If the current risk unit does not exist, the current unit value is determined as the current situation value; Step S334: Read the number of interval periods between the previous risk unit and the current risk unit, and generate a decreasing coefficient based on the number of interval periods; Step S335: The current unit value and the previous situation value are recursively accumulated according to the decreasing coefficient to generate the current situation value; Step S336: Write the current situation value into the situation evolution sequence position corresponding to the current monitoring period.

7. The network security dynamic early warning method based on big data analysis as described in claim 6, characterized in that, Step S4 specifically includes: Step S41: Read the current risk unit and the next risk unit in the risk unit sequence according to the arrangement order; Step S42: Extract the source identifier, object identifier, behavior trajectory, and end time of the current risk unit, and extract the source identifier, object identifier, behavior trajectory, and start time of the next risk unit; Step S43: Determine whether the current risk unit and the next risk unit satisfy the connection relationship; The connection relationships include source connection relationships, object connection relationships, behavior connection relationships, and time connection relationships; Step S44: When the current risk unit and the next risk unit satisfy the connection relationship, connect the current risk unit and the next risk unit to the same propagation chain group, and continue to read the next risk unit after the next risk unit. Repeat steps S42 to S44 until the connection relationship is no longer satisfied. Step S45: Arrange the risk units within the propagation chain group according to the connection order to generate the corresponding risk propagation chain; Step S46: Repeat steps S41 to S45 according to the reading order of the risk unit sequence, and write each generated risk propagation chain into the risk propagation chain sequence in sequence. Step S47: Read the change identification results corresponding to each risk propagation chain, generate corresponding early warning icons according to the arrangement order of the risk propagation chains, and organize the early warning icons into an early warning sequence according to the generation order.

8. The network security dynamic early warning method based on big data analysis as described in claim 7, characterized in that, The processing logic for step S47 is as follows: Step S471: Read the change identification results corresponding to the current risk propagation chain according to the arrangement order of the risk propagation chain sequence; Step S472: When the change identification result includes a continuous growth indicator, generate a first warning indicator; Step S473: When the change identification result includes both growth change identifier and fluctuation change identifier, or only includes growth change identifier and does not include fluctuation change identifier, a second warning identifier is generated. Step S474: When the change identification result includes a stable change indicator, a third early warning indicator is generated; Step S475: When the change identification result includes a falling change indicator, a continuous falling change indicator, or a turning change indicator, a fourth warning indicator is generated. Step S476: Write the first warning identifier, the second warning identifier, the third warning identifier, or the fourth warning identifier into the warning sequence position corresponding to the current risk transmission chain; Step S477: Continue reading the change identification results corresponding to the next risk propagation chain, and repeat steps S472 to S476 until the risk propagation chain sequence reading is completed.

9. The network security dynamic early warning method based on big data analysis as described in claim 8, characterized in that, Step S5 specifically includes: Step S51: Receive the operation data for the next monitoring cycle, perform unified structure processing on the operation data, and generate new security events; Step S52: Write the newly added security events sequentially to the end of the security event sequence according to their occurrence time to obtain the updated security event sequence; Step S53: Read the new security events starting from the end of the updated security event sequence, and perform a merge process based on the continuity relationship to obtain new risk units. Write the new risk units sequentially to the end of the risk unit sequence to obtain the updated risk unit sequence. Step S54: Read the newly added risk units starting from the end of the updated risk unit sequence, and perform recursive accumulation and change identification processing based on the continuation relationship to obtain the new situation value and the new change identification result. Write the new situation value into the end of the situation evolution sequence in sequence to obtain the updated situation evolution sequence. Step S55: Starting from the end of the updated risk unit sequence, read the newly added risk units, perform connection processing based on the connection relationship to obtain the newly added risk propagation chain and the newly added early warning identifier, write the newly added risk propagation chain to the end of the risk propagation chain sequence in sequence, and write the newly added early warning identifier to the end of the early warning sequence in sequence to obtain the updated risk propagation chain sequence and the updated early warning sequence.

10. A network security dynamic early warning system based on big data analysis, which is applied to the network security dynamic early warning method based on big data analysis as described in any one of claims 1-9, characterized in that, It includes a data processing module, a unit generation module, a situation identification module, a link early warning module, and a recursive update module; The data processing module is used to acquire the operational data generated by the target network in each monitoring period, perform unified structural processing on the operational data, and generate a sequence of security events according to the time of occurrence. The unit generation module is used to perform merging processing based on the continuous relationship between adjacent security events in the security event sequence to generate a risk unit sequence; The situation identification module is used to perform cumulative processing based on the continuity relationship of the risk unit sequence in each monitoring period, generate a situation evolution sequence, and identify changes in the situation evolution sequence to obtain change identification results. The link early warning module is used to generate a risk propagation chain sequence based on the connection relationship between risk unit sequences, and output an early warning sequence in combination with the change identification results; The recursive update module is used to receive the operating data of the next monitoring cycle and recursively update the security event sequence, risk unit sequence, situation evolution sequence, risk propagation chain sequence and early warning sequence to obtain the updated security event sequence, updated risk unit sequence, updated situation evolution sequence, updated risk propagation chain sequence and updated early warning sequence.

Images