A method and device for network security situation awareness

Abstract

This application relates to the field of network situational awareness technology, and discloses a method and device for network security situational awareness. The method includes: identifying regulatory entities and collecting abnormal events; identifying interactive and operational behaviors as risk characteristics; constructing a first risk identification model and deploying it on an edge terminal; collecting the type and sensitivity attributes of the regulatory entities; dynamically forming regulatory assistance pairs based on the attributes; generating a second risk identification model by weighted averaging of the parameters of the first model based on the regulatory assistance pairs and deploying it in the cloud; real-time interactive data is preferentially screened by the cloud-based second model; if a risk is identified, a structured report is generated and distributed; if not identified, it is reviewed by the first model at the edge terminal. This application achieves distributed intelligent perception with cross-domain collaboration and data not leaving the domain, solving the model bias and centralized delay problems caused by insufficient samples of a single entity, and significantly improving detection accuracy, response efficiency, and collaborative defense capabilities in low-sample scenarios.

Description

Technical Field

[0001] This application relates to the field of network situational awareness technology, and more specifically, to a network security situational awareness method and apparatus. Background Technology

[0002] With the continuous improvement of informatization and networking, various regulatory entities (such as government systems, industry regulatory platforms, and critical infrastructure networks) face increasingly complex cybersecurity risks, making cybersecurity situational awareness technology an important technical means to ensure cybersecurity. Current cybersecurity situational awareness solutions typically collect and analyze data such as network traffic, interactive behavior, and system operation logs to identify potential anomalies and security risks.

[0003] However, in practical applications, network security situation awareness generally faces the problem of difficulty in obtaining abnormal data. Most data in the network operation state is normal behavior data, and the sample size is small, so it cannot cover all types of abnormal data. Furthermore, some high-risk abnormal events are sudden and covert, making it difficult to record them completely in the early stages, which further exacerbates the problem of insufficient abnormal data samples.

[0004] There is currently no effective solution to the aforementioned technical problems. Summary of the Invention

[0005] This application provides a network security situation awareness method and apparatus to at least solve the technical problem that network security situation awareness methods are singular and cannot comprehensively reflect the network security situation.

[0006] According to one aspect of the embodiments of this application, a network security situation awareness method is provided, including:

[0007] Identify the regulatory entities responsible for network security situational awareness and acquire abnormal network security events within those regulatory entities;

[0008] Identify risk characteristics in the abnormal events, wherein the risk characteristics include at least interactive behavior characteristics and operational behavior characteristics, the interactive behavior characteristics are used to reflect the communication patterns between regulatory entities, and the operational behavior characteristics are used to reflect the operation mode of the user terminal to be sensed;

[0009] A first risk identification model is constructed based on the aforementioned risk characteristics, and the first risk identification model is deployed on the edge terminal of the regulatory entity.

[0010] Obtain the attribute data of the regulated entity, wherein the attribute data includes at least the type of the regulated entity and the sensitivity of the regulated entity;

[0011] A regulatory assistance pair is constructed based on the attribute data, wherein the regulatory assistance pair includes multiple regulatory entities that assist each other, and the regulatory entities in the regulatory assistance pair can use the first risk identification model of the other party to process their own interaction data.

[0012] Based on the aforementioned regulatory assistance and the first risk identification model, a second risk identification model is generated and deployed on a cloud server;

[0013] After the regulatory entity collects the interactive data sent by the user terminal, it inputs the interactive data into the second risk identification model for risk identification.

[0014] If the interactive data contains risk characteristics, the cloud server generates a risk report based on the risk characteristics and sends it to the regulatory entity; if the interactive data does not contain risk characteristics, the interactive data is input into the first risk identification model for risk identification verification.

[0015] Optionally, determining the regulatory entity for network security situation awareness and acquiring abnormal network security events within the regulatory entity includes:

[0016] Obtain the impact range of each of the aforementioned abnormal events;

[0017] Based on the scope of impact of the abnormal event, a risk level corresponding to the abnormal event is generated;

[0018] A risk label is generated based on the risk level, and the risk label is added to the abnormal event.

[0019] Optionally, constructing the first risk identification model based on the risk characteristics includes:

[0020] The risk features are labeled using a preset terminal to obtain the risk feature labeling results;

[0021] A training set is generated based on the risk feature annotation results, wherein each regulatory entity corresponds to a training set, and the training set is used to reflect the network environment in which the regulatory entity is located and the corresponding security risk features.

[0022] The first risk identification model is constructed based on the training set.

[0023] Optionally, the method further includes:

[0024] An inspection set is generated based on the risk feature annotation results;

[0025] The first risk identification model is trained based on the inspection set, and the model parameters of the first risk identification model are extracted. The model parameters include weight coefficients and / or risk judgment threshold parameters.

[0026] Optionally, generating a second risk identification model based on the regulatory assistance pair and the first risk identification model includes:

[0027] The model parameters in the regulatory assistance pair are weighted and averaged to obtain the average parameters, wherein the model parameters in the regulatory assistance pair are the model parameters of the first risk identification model corresponding to each regulatory entity in the regulatory assistance pair;

[0028] The average parameters are written into the first risk identification model to obtain the second risk identification model.

[0029] Optionally, the method further includes:

[0030] Determine the adjustment rules for the regulatory assistance pair, wherein the adjustment rules include adjusting the regulatory assistance pair according to time or risk events;

[0031] After adjusting the regulatory assistance pair based on the aforementioned adjustment rules, the average parameter is updated.

[0032] Based on the average parameters of the regulatory assistance pair, a corresponding regulatory assistance lookup table is generated.

[0033] Optionally, after the regulatory entity collects the interaction data sent by the user terminal, inputting the interaction data into the second risk identification model for risk identification includes:

[0034] Obtain multi-source metrics of the interaction data, wherein the multi-source metrics include the initiating device and service type of the interaction data;

[0035] Risk identification is performed on the interactive data based on the second risk identification model and the multi-source indicators;

[0036] After identifying the risk characteristics through the risk identification process, the rules for handling the risk characteristics are determined.

[0037] The device initiating the interaction data is adjusted based on the aforementioned processing rules.

[0038] Optionally, if the interactive data contains risk characteristics, the cloud server generates a risk report based on the risk characteristics and sends it to the regulatory entity, including:

[0039] The summary of the interaction data and the risk characteristics are written into a preset template to generate the risk report;

[0040] Record the time when the risk report was generated;

[0041] The risk reports are sorted according to their generation time to generate a report chain;

[0042] Traverse the reporting chain, extract the evolution path of risk features from the reporting chain, and send the evolution path of risk features to the edge terminal of the regulatory entity.

[0043] Optionally, if no risk characteristics are found in the interaction data, inputting the interaction data into the first risk identification model for risk identification verification includes:

[0044] The interactive data and the output of the second risk identification model are input into the first risk identification model, wherein the output of the first risk identification model includes the risk assessment result and confidence information of the interactive data.

[0045] According to another aspect of the embodiments of this application, a network security situation awareness device is also provided, comprising:

[0046] The module is configured to identify the regulatory entity for network security situation awareness and acquire abnormal network security events in the regulatory entity.

[0047] The first identification module is configured to identify risk characteristics in the abnormal event, wherein the risk characteristics include at least interactive behavior characteristics and operational behavior characteristics, the interactive behavior characteristics are used to reflect the communication pattern between regulatory entities, and the operational behavior characteristics are used to reflect the user's own operation mode.

[0048] The first construction module is configured to construct a first risk identification model based on the risk characteristics and deploy the first risk identification model on the edge terminal of the regulatory entity.

[0049] The acquisition module is configured to acquire attribute data of the regulatory entity, wherein the attribute data includes at least the type of the regulatory entity and the sensitivity of the regulatory entity;

[0050] The second construction module is configured to construct a regulatory assistance pair based on the attribute data, wherein the regulatory assistance pair includes multiple regulatory entities that assist each other, and the regulatory entities in the regulatory assistance pair can use the other party's first risk identification model to process their own interaction data.

[0051] The generation module is configured to generate a second risk identification model based on the regulatory assistance pair and the first risk identification model, and deploy the second risk identification model on a cloud server;

[0052] The second identification module is configured to input the interactive data sent by the user terminal into the second risk identification model for risk identification after the regulatory entity collects the interactive data.

[0053] The judgment module is configured such that if risk characteristics exist in the interaction data, the cloud server generates a risk report based on the risk characteristics and sends it to the regulatory entity; if no risk characteristics exist in the interaction data, the interaction data is input into the first risk identification model for risk identification verification.

[0054] According to another aspect of the embodiments of this application, a network security situation awareness system is also provided, including a cloud server and an edge terminal, wherein the edge terminal is located in a supervisory entity, and the cloud server is configured as follows:

[0055] After the regulatory entity collects the interactive data sent by the user terminal, it uses a second risk identification model to identify risks in the interactive data.

[0056] The edge terminal is configured as follows:

[0057] After determining that there are no risk features in the interaction data through the second risk identification model, the interaction data is reviewed for risk identification through the first risk identification model.

[0058] The first risk identification model is constructed based on the risk characteristics of abnormal events perceived by the regulatory entity, and the second risk identification model is constructed based on the attribute data of the regulatory entity and the first risk identification model.

[0059] According to another aspect of the embodiments of this application, a non-volatile storage medium is also provided, the non-volatile storage medium including a stored program, wherein, when the program is running, it controls the device where the non-volatile storage medium is located to execute any of the above-described network security situation awareness methods.

[0060] According to another aspect of the embodiments of this application, a computer device is also provided, the computer device including a processor, the processor being used to run a program, wherein the program executes any of the above-described network security situation awareness methods during runtime.

[0061] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements any of the above-described network security situation awareness methods.

[0062] The network security situation awareness method and apparatus provided in this application identify regulatory entities and collect abnormal events; identify interactive and operational behaviors as risk characteristics; construct a first risk identification model and deploy it on an edge terminal; collect the type and sensitivity attributes of the regulatory entities; dynamically form regulatory assistance pairs based on the attributes; generate a second risk identification model based on the regulatory assistance pairs and the first risk identification model and deploy it in the cloud; real-time interactive data is preferentially screened by the cloud-based second model; if a risk is identified, a structured report is generated and distributed; if not identified, it is reviewed by the first model on the edge terminal. This application achieves distributed intelligent perception with cross-domain collaboration and data not leaving the domain, solving the model bias and centralized delay problems caused by insufficient samples of a single entity, and significantly improving the detection accuracy, response efficiency, and collaborative defense capabilities in low-sample scenarios. Attached Figure Description

[0063] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0064] Figure 1 A hardware structure block diagram of a computer terminal for implementing a network security situation awareness method is shown.

[0065] Figure 2 This is a flowchart illustrating a network security situation awareness method provided according to an embodiment of this application;

[0066] Figure 3 This is another flowchart illustrating a network security situation awareness method provided according to an embodiment of this application;

[0067] Figure 4 This is a structural block diagram of a network security situation awareness system provided according to an embodiment of this application;

[0068] Figure 5 This is a structural block diagram of a network security situation awareness device provided according to an embodiment of this application. Detailed Implementation

[0069] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0070] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0071] According to an embodiment of this application, a method embodiment for network security situation awareness is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0072] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware structure block diagram of a computer terminal for implementing a network security situational awareness method is shown. Figure 1 As shown, the computer terminal 10 may include one or more processors (shown as 102a, 102b, ..., 102n in the figure) (the processor may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0073] It should be noted that the aforementioned one or more processors and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10. As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0074] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the network security situation awareness method in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the network security situation awareness method of the aforementioned application. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor, and these remote memories can be connected to the computer terminal 10 via a network. Examples of the aforementioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0075] The display can be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10.

[0076] Figure 2 This is a flowchart illustrating the network security situation awareness method provided in the embodiments of this application, such as... Figure 2 As shown, the method includes the following steps:

[0077] Step S201: Identify the regulatory entity for network security situation awareness and obtain abnormal network security events in the regulatory entity.

[0078] The network security situation awareness method provided in this application embodiment is applied to a network security situation awareness system (hereinafter referred to as the system), such as Figure 4As shown, the system includes a cloud server and edge terminals, with the edge terminals deployed at each regulatory entity. In this step, the system's processor identifies the objects participating in situational awareness and security supervision, i.e., the regulatory entities. These entities can be government networks, industry private networks, or enterprise intranets, etc. The system acquires network security anomalies occurring within the regulatory entities. These anomalies include, but are not limited to, abnormal logins, abnormal access requests, abnormal command issuance, abnormal configuration changes, and abnormal data interactions. These events serve as the raw input for risk modeling, ensuring that the perception covers real threat scenarios and providing basic data support for subsequent feature extraction. The system's processor can be a standalone server or the processor of the aforementioned cloud server or edge terminal.

[0079] Step S202: Identify the risk characteristics in the abnormal event, wherein the risk characteristics include at least interactive behavior characteristics and operational behavior characteristics, the interactive behavior characteristics are used to reflect the communication patterns between regulatory entities, and the operational behavior characteristics are used to reflect the operation mode of the user terminal to be sensed.

[0080] In this step, based on the abnormal events obtained in step S201, the system extracts two core behavioral patterns from the abnormal events: interactive behavioral features reflect abnormal patterns at the network communication layer, such as high-frequency access to specific IPs, non-standard port communication, and abnormal protocol usage; operational behavioral features reflect abnormal operations of users or system accounts within the host, such as privilege escalation, batch export of sensitive files, and execution of high-risk commands outside of working hours. These two types of features together constitute a behavioral fingerprint, used to distinguish normal operations from potential attacks.

[0081] Step S203: Construct a first risk identification model based on the risk characteristics, and deploy the first risk identification model on the edge terminal of the regulatory entity.

[0082] In this step, each regulatory entity constructs its own primary risk identification model based on risk characteristics extracted from locally collected and manually labeled anomaly events, including interactive and operational behaviors. This model is trained using deep learning or machine learning algorithms, with training data derived entirely from the entity's internal network logs and security events, without involving raw data from other entities, ensuring data sovereignty and privacy compliance. After training, the model is directly deployed on the entity's local edge terminal, enabling localized and real-time risk identification. This deployment method effectively reduces reliance on the cloud, minimizes data transmission latency and bandwidth pressure, and allows the model to deeply adapt to the entity's unique network behavior baseline and security risk patterns. This significantly improves the accuracy and response capability for identifying local, covert, and low-frequency anomalies, providing a high-quality, differentiated local model foundation for subsequent parameter aggregation of cloud-based generalized models.

[0083] Step S204: Obtain the attribute data of the regulatory entity, wherein the attribute data includes at least the type of the regulatory entity and the sensitivity of the regulatory entity.

[0084] In this step, the system collects attribute data for each regulatory entity. This attribute data includes the entity's type and sensitivity information. The type characterizes the entity's business category, management level, or industry attribute, while the sensitivity reflects the importance and risk tolerance of the data, systems, or business involved, serving as the basis for building collaborative relationships. This attribute data is the core basis for constructing regulatory assistance pairs, used to intelligently match regulatory entities with similar business characteristics or risk levels. This enables precise grouping of model parameter aggregation, thereby improving the rationality and effectiveness of cross-domain knowledge fusion without sharing original data. It provides a reliable and traceable collaborative foundation for the generation of cloud-based generalized models.

[0085] Step S205: Construct a regulatory assistance pair based on the attribute data, wherein the regulatory assistance pair includes multiple regulatory entities that assist each other, and the regulatory entities in the regulatory assistance pair can use the first risk identification model of the other party to process their own interaction data.

[0086] In this step, based on attribute similarity, the system dynamically groups multiple regulatory entities into "regulatory assistance pairs." Assistance pairs can be regulatory entities of cooperating companies or other companies with friendly relationships. Members of an assistance pair can leverage each other's pre-trained first-risk identification model to analyze their own traffic without sharing original data. This achieves a collaborative detection mechanism that shares model knowledge and maintains physical data isolation, effectively compensating for insufficient individual samples.

[0087] Step S206: Based on the regulatory assistance pair and the first risk identification model, generate a second risk identification model and deploy the second risk identification model on a cloud server.

[0088] In this step, based on the regulatory assistance pair constructed in step S204, the system performs a weighted average fusion of the learnable parameters (including weight coefficients, judgment thresholds, feature importance, etc.) of the first risk identification model deployed by each regulatory entity, generating a second risk identification model with cross-domain generalization capabilities. The generated second model inherits the common risk identification experience of multiple entities within the assistance pair, effectively identifying high-frequency, cross-agency typical attack patterns, overcoming model bias caused by the scarcity of single-entity samples, and significantly improving the breadth and stability of the cloud's perception of the global network situation. Finally, this second risk identification model is uniformly deployed on the cloud server, serving as the core hub for initial risk screening and collaborative decision-making across the entire network. It provides efficient and consistent predictive basis for the edge terminal's review mechanism, achieving a collaborative perception closed loop with broad cloud coverage and in-depth edge analysis.

[0089] Step S207: After the regulatory entity collects the interactive data sent by the user terminal, it inputs the interactive data into the second risk identification model for risk identification.

[0090] In this step, after the regulatory entity collects real-time interactive data from users (such as remote login, API calls, and database queries), the system preprocesses the data, including data cleaning, format standardization, and key field extraction. The processed data is then input into the second risk identification model (generalization model) for preliminary verification to determine whether it contains risk characteristics. During this determination, the second risk identification model (generalization model) outputs the corresponding risk assessment result and confidence level information, which serves as the basis for subsequent refined identification, risk classification, or coordinated response at edge nodes. This model, trained based on cross-domain knowledge, features fast response speed and a wide recognition range. It can quickly filter high-confidence risk events, significantly reducing the continuous computational pressure on edge nodes and improving system throughput and real-time performance.

[0091] Step S208: If there are risk characteristics in the interaction data, the cloud server generates a risk report based on the risk characteristics and sends it to the regulatory entity; if there are no risk characteristics in the interaction data, the interaction data is input into the first risk identification model for risk identification verification.

[0092] In this step, the system performs risk identification on the interactive data. If the judgment result is yes, meaning that the real-time interactive data contains risk characteristics, the system writes the summary and risk characteristics of the real-time interactive data into a preset template, generates a risk report, including time, characteristics, level, and recommended actions, and sends the risk report to the regulatory entity for processing by the regulatory entity's network maintenance personnel. If the judgment result is no, meaning that the data does not contain risk characteristics, the system inputs the interactive data into the risk identification model for review and verification, and uses the risk identification model to further determine whether the real-time interactive data contains risk characteristics.

[0093] This application provides a network security situational awareness method that identifies regulatory entities and collects abnormal events; identifies interactive and operational behaviors as risk characteristics; constructs a first risk identification model and deploys it on an edge terminal; collects the type and sensitivity attributes of the regulatory entities; dynamically forms regulatory assistance pairs based on the attributes; generates a second risk identification model based on the regulatory assistance pairs and the first risk identification model and deploys it in the cloud; real-time interactive data is initially screened by the cloud-based second model; if a risk is identified, a structured report is generated and distributed; if not identified, it is reviewed by the first model on the edge terminal. This application achieves distributed intelligent perception with cross-domain collaboration and data not leaving the domain, solving the model bias and centralized delay problems caused by insufficient samples of a single entity, and significantly improving the detection accuracy, response efficiency, and collaborative defense capabilities in low-sample scenarios.

[0094] As an optional embodiment, in step S201, such as Figure 3 As shown, this can be achieved according to the following steps: determining the regulatory entity for network security situation awareness and obtaining abnormal network security events within the regulatory entity includes:

[0095] S2011, Obtain the impact range of each of the abnormal events;

[0096] S2012, Based on the impact range of the abnormal event, generate a risk level corresponding to the abnormal event;

[0097] S2013, Generate a risk label based on the risk level, and add the risk label to the abnormal event.

[0098] In steps S2011 to S2013, to achieve refined and structured risk identification of network security anomalies, thus laying the foundation for building a high-quality training set, after identifying the regulatory entity and acquiring the anomalies, the system further performs systematic risk labeling and structured enhancement of the anomalies through the following three sub-steps: First, the system acquires the impact range of each anomaly. For each network security anomaly, the system analyzes the scope of network assets affected, including the number of affected hosts, business systems, network areas, or service modules. For example, a lateral movement attack may involve 3 servers, 2 databases, and 1 application service, with an impact range of "3 hosts + 2 databases + 1 service". This range is automatically calculated through log association, topology mapping, and asset ledger matching, providing an objective basis for quantifying the severity of the event. Second, based on the scale and criticality of the impact range, the system automatically classifies the risk level into three levels: high, medium, and low. For example, events affecting the core scheduling system or involving the transmission of sensitive data are classified as "high," while isolated login failure events affecting only ordinary office terminals are classified as "low." The risk level determination rules are based on preset thresholds: ≥5 affected devices is high, 1–4 is medium, and 0 is low. This ensures a consistent and reproducible scoring standard, providing structured labeling for subsequent model training and manual annotation. Finally, the system writes the risk level into the label and inserts the label into the abnormal event as a link or note. This label serves as a supervisory signal for the model, guiding the first risk identification model to learn typical patterns of high-risk events, improving the efficiency of training set construction and labeling consistency, and achieving automated risk perception and grading.

[0099] As an optional embodiment, step S203 can be implemented according to the following steps: constructing the first risk identification model based on the risk characteristics includes:

[0100] S2031, The risk features are labeled using a preset terminal to obtain the risk feature labeling results;

[0101] S2032, A training set is generated based on the risk feature annotation results, wherein each regulatory entity corresponds to a training set, and the training set is used to reflect the network environment in which the regulatory entity is located and the corresponding security risk features;

[0102] S2033, Construct the first risk identification model based on the training set.

[0103] In this step, to enable each regulatory entity to build locally adaptable risk identification capabilities under the premise of data isolation, the system further refines the first risk identification model based on risk characteristics, realizing a complete closed-loop process from manual annotation to model training. The system grants annotation permissions for risk characteristics to preset terminals, which are either network maintenance personnel terminals or other professional terminals, allowing professionals to manually annotate risk characteristics based on unified annotation standards. The received annotation results are verified, deduplicated, and processed for consistency, and then integrated to generate a training set. Each regulatory entity corresponds to a training set, which reflects the actual network environment and security risk characteristics of the regulatory entity. Using deep learning algorithms, a risk identification model is created, capable of identifying risk characteristics.

[0104] Furthermore, the system divides the training set into a public set and a sensitive set. A sensitive dictionary composed of sensitive words is created. When sensitive words are present in the annotation results or risk features, the set of corresponding annotation results is defined as the sensitive set (a set of sensitive data), and the portion of the training set excluding the sensitive set is defined as the public set. A sharing platform for the training set is created. The public set is uploaded to the sharing platform, and the sensitive set is sent to edge nodes. The sharing platform allows authenticated users to annotate and share the training set, upload the public set to the sharing platform and grant access, and send the sensitive set to edge terminals for storage.

[0105] In the early training process of the first risk identification model, a training set is required. However, the training set will inevitably contain sensitive data. Therefore, in this embodiment, it is determined that the sensitive set can be effectively identified and isolated before the data enters the model training process. It is also preprocessed through desensitization, anonymization mapping, and other methods to eliminate direct dependence on the original sensitive information while retaining the key feature information of the data.

[0106] As an optional embodiment, step S203 can also be implemented according to the following steps:

[0107] S2034, Generate an inspection set based on the risk feature annotation results;

[0108] S2035, the first risk identification model is trained based on the inspection set, and the model parameters of the first risk identification model are extracted. The model parameters include weight coefficients and / or risk judgment threshold parameters.

[0109] In this step, the system generates an inspection set based on the risk feature annotation results. Using this inspection set, the risk identification model is trained. The completed risk identification model is then distributed and deployed to the edge terminals of the corresponding regulatory entities. These edge terminals can be edge servers or smart gateways, enabling them to perform network risk identification and analysis locally. This reduces reliance on central terminals, lowers data transmission latency and privacy risks, and provides a foundation for subsequent continuous training and model optimization based on local data. Model parameters are extracted from the risk identification model, including weight coefficients and judgment threshold parameters.

[0110] As an optional embodiment, step S206 can be implemented according to the following steps: generating a second risk identification model based on the regulatory assistance pair and the first risk identification model, including:

[0111] S2061, The model parameters in the regulatory assistance pair are weighted and averaged to obtain the average parameters, wherein the model parameters in the regulatory assistance pair are the model parameters of the first risk identification model corresponding to each regulatory entity in the regulatory assistance pair;

[0112] S2062, The average parameters are written into the first risk identification model to obtain the second risk identification model.

[0113] In this step, the system creates a corresponding weight value for each model parameter, performs a weighted average of the model parameters to obtain a set of average parameters, writes the average parameters into the initialized risk identification model, generates a generalized model, and deploys the generalized model to cloud nodes. Within the established regulatory assistance pairs, the system extracts all trainable parameters of the first risk identification model deployed locally by each entity, including neural network weights, bias terms, decision thresholds, etc. Based on indicators such as the quality of training data, sample representativeness, and historical detection accuracy of each entity, corresponding weight coefficients are assigned to each model. Then, all model parameters are weighted and averaged item by item to generate a unified set of average parameters. The average parameters generated in step S2061 are written into the corresponding positions in the first risk identification model to complete parameter initialization, resulting in the second risk identification model. This model is deployed in the cloud to receive real-time interactive data from various regulatory entities, achieving efficient and broad-coverage preliminary risk screening.

[0114] As an optional embodiment, step S2061 can be implemented according to the following steps:

[0115] S301, determine the adjustment rules for the regulatory assistance pair, wherein the adjustment rules include adjusting the regulatory assistance pair according to time or risk events;

[0116] S302, After adjusting the regulatory assistance pair based on the adjustment rules, update the average parameter;

[0117] S303, Based on the average parameters of the regulatory assistance pair, generate a corresponding regulatory assistance lookup table.

[0118] In this step, the assistance pair consists of two or more regulatory entities. The assistance pairs are not static; the system pre-sets dynamic adjustment rules for regulatory assistance pairs, supporting two triggering methods: time-driven and event-driven. Time-driven refers to reassessing the attribute similarity between entities at fixed intervals and automatically reorganizing the assistance pair. Event-driven refers to the system immediately triggering a reorganization mechanism when any member of the assistance pair experiences a high-risk event, removing it from the original assistance pair and rematching it with a new collaborating partner based on attribute data (type, sensitivity). After changes to the assistance pair structure, such as adding, deleting, or replacing members, the system immediately re-extracts the model parameters (weights, thresholds, etc.) of the first risk identification model for all members within the current assistance pair, and recalculates the weight coefficients based on the latest data quality, detection accuracy, sample size, and other indicators of each entity, performing a weighted average calculation to generate new average parameters. The system establishes a unique identifier for each regulatory assistance pair and stores the corresponding average parameters in a structured form in a regulatory assistance lookup table. The table fields include: assistance pair ID, member entity list, average parameter vector, generation timestamp, and adjustment reason.

[0119] As an optional embodiment, step S207 can be implemented according to the following steps: after the regulatory entity collects the interaction data sent by the user terminal, the interaction data is input into the second risk identification model for risk identification, including:

[0120] S2071, Obtain multi-source indicators of the interaction data, wherein the multi-source indicators include the initiating device and service type of the interaction data;

[0121] S2072, Risk identification is performed on the interactive data based on the second risk identification model and the multi-source indicators;

[0122] S2073, After determining the risk characteristics through the risk identification, determine the handling rules for the risk characteristics;

[0123] S2074, Adjust the device that initiated the interaction data based on the processing rules.

[0124] In this step, after the regulatory entity submits real-time interactive data to the cloud, the system collects multi-source indicators from the real-time interactive data. These multi-source indicators include at least the initiating device and the service type. When evaluating the real-time interactive data, in addition to using a risk identification model to determine risk characteristics, multi-source indicators should also be considered, including the initiating device and the service type of the real-time interactive data. Then, several handling rules are created, establishing a mapping between the handling rules and risk characteristics. After determining the risk characteristics, the corresponding handling rule is activated, and this handling rule is used to adjust the initiating device of the real-time interactive data; for example, the handling rule can be to isolate the initiating device. Finally, based on the handling rules matched in the previous step, the system automatically issues control commands to the regulatory entity's edge nodes or network control system (e.g., firewalls, zero-trust gateways, SDN controllers) to dynamically adjust the initiating device. Typical actions include: isolating device network access, forcibly removing identity authentication, restricting access permissions, and suspending business services.

[0125] As an optional embodiment, step S208 can be implemented according to the following steps: if there are risk characteristics in the interactive data, the cloud server generates a risk report based on the risk characteristics and sends it to the regulatory entity, including:

[0126] S2081, Write the summary of the interaction data and the risk characteristics into a preset template to generate the risk report;

[0127] S2082, Record the generation time of the risk report;

[0128] S2083, Sort the risk reports according to their generation time to generate a report chain;

[0129] S2084, Traverse the reporting chain, extract the evolution path of the risk characteristics from the reporting chain, and send the evolution path of the risk characteristics to the edge terminal of the regulatory entity.

[0130] In steps S2081 to S2084, to achieve traceability, analyzability, and continuous optimization of situational awareness for risk events, after identifying risk characteristics in the cloud, the system constructs a complete closed-loop analysis chain of "single-point alarm—time-series aggregation—trend tracing" by generating structured risk reports, organizing report chains in a time sequence, and dynamically analyzing evolution paths. First, when the cloud-based second risk identification model determines that risk characteristics exist in the interactive data, the system automatically extracts the structured summary of the interactive data and the specific risk characteristics identified by the model, filling them into a preset standardized risk report template. Second, the system records the generation time of the risk reports and sorts them according to their generation time from earliest to latest, generating a report chain, where the report chain is a collection of risk reports arranged in a time sequence. Finally, the system traverses the report chain, extracts the evolution path of the risk characteristics, and uploads it to the edge nodes. The system traverses and parses each report chain to determine the occurrence sequence, triggering conditions, and correlations of each risk feature, and generates an evolution path. The evolution path reflects the entire process of risk from initial signs and continuous spread to possible escalation or reduction, and is uploaded to the edge terminal.

[0131] As an optional embodiment, step S208 can also be implemented according to the following steps: if there are no risk features in the interaction data, inputting the interaction data into the first risk identification model for risk identification verification, including:

[0132] S2085, the interactive data and the output of the second risk identification model are input into the first risk identification model, wherein the output of the first risk identification model includes the risk determination result and confidence information of the interactive data.

[0133] In this step, after the cloud-based second risk identification model performs preliminary verification of the real-time interactive data, if no clear risk characteristics are identified (i.e., it is judged as risk-free or with low confidence), the system will not directly allow the interaction. Instead, it will initiate a local review mechanism: the original content of the interactive data (including multi-source indicators) along with the output of the second model, including its risk assessment conclusion, confidence score, and the weights of the features used, will be pushed as input to the first risk identification model deployed locally by the regulatory entity for a second review. This mechanism achieves a dual guarantee of "cloud-based coarse screening and edge-based fine judgment," effectively compensating for the shortcomings of generalized models in local adaptability while ensuring system response efficiency.

[0134] Through the above steps, this application provides an AI-based network security situational awareness method. It adopts a "cloud-edge collaboration, dual-model verification" architecture. The edge terminal deploys a locally dedicated first risk identification model, trained on real anomaly data from the unit, ensuring privacy and security. The cloud aggregates model parameters from multiple regulatory entities, dynamically constructs auxiliary pairs based on attributes, and performs weighted averaging to generate a second risk identification model with stronger generalization capabilities, achieving cross-domain collaborative awareness with "unchanged data and shared knowledge." When the cloud's initial screening finds no risk, the edge terminal automatically triggers local model verification, forming a "cloud judgment + edge verification" dual verification mechanism, effectively reducing false positives and false negatives. Simultaneously, by constructing a risk reporting chain and evolution path, it achieves temporal tracing and trend analysis of attack behavior. Combined with dynamic auxiliary pair adjustments and parameter comparison tables, it ensures continuous adaptive updates of the model, realizing cross-regulatory entity knowledge sharing without data sharing, a closed-loop cloud-edge collaboration for risk identification, and temporal tracing and situational evolution tracking of attack behavior. This effectively improves the generalization ability, response speed, and collaborative accuracy of anomaly detection in low-sample environments.

[0135] According to an embodiment of this application, a network security situation awareness device for implementing the above-described network security situation awareness method is also provided. Figure 5 This is a structural block diagram of a network security situation awareness device provided according to an embodiment of this application, such as... Figure 5 As shown, the network security situation awareness device includes:

[0136] The determination module 51 is configured to determine the regulatory entity for network security situation awareness and acquire abnormal network security events in the regulatory entity.

[0137] The first identification module 52 is configured to identify risk characteristics in the abnormal event, wherein the risk characteristics include at least interactive behavior characteristics and operational behavior characteristics, the interactive behavior characteristics are used to reflect the communication pattern between regulatory entities, and the operational behavior characteristics are used to reflect the user's own operation mode.

[0138] The first construction module 53 is configured to construct a first risk identification model based on the risk characteristics and deploy the first risk identification model on the edge terminal of the regulatory entity.

[0139] The acquisition module 54 is configured to acquire attribute data of the regulatory entity, wherein the attribute data includes at least the type of the regulatory entity and the sensitivity of the regulatory entity;

[0140] The second construction module 55 is configured to construct a regulatory assistance pair based on the attribute data, wherein the regulatory assistance pair includes multiple regulatory entities that assist each other, and the regulatory entities in the regulatory assistance pair can use the other party's first risk identification model to process their own interaction data.

[0141] The generation module 56 is configured to generate a second risk identification model based on the regulatory assistance pair and the first risk identification model, and deploy the second risk identification model on a cloud server;

[0142] The second identification module 57 is configured to input the interactive data sent by the user terminal into the second risk identification model for risk identification after the regulatory entity collects the interactive data.

[0143] The judgment module 58 is configured such that if there are risk characteristics in the interaction data, the cloud server generates a risk report based on the risk characteristics and sends it to the regulatory entity; if there are no risk characteristics in the interaction data, the interaction data is input into the first risk identification model for risk identification verification.

[0144] Optionally, the determining module 51 is further configured to:

[0145] Obtain the impact range of each of the aforementioned abnormal events;

[0146] Based on the scope of impact of the abnormal event, a risk level corresponding to the abnormal event is generated;

[0147] A risk label is generated based on the risk level, and the risk label is added to the abnormal event.

[0148] Optionally, the first building module 53 is further configured as follows:

[0149] The risk features are labeled using a preset terminal to obtain the risk feature labeling results;

[0150] A training set is generated based on the risk feature annotation results, wherein each regulatory entity corresponds to a training set, and the training set is used to reflect the network environment in which the regulatory entity is located and the corresponding security risk features.

[0151] The first risk identification model is constructed based on the training set.

[0152] Optionally, the generation module 56 is further configured to:

[0153] The model parameters in the regulatory assistance pair are weighted and averaged to obtain the average parameters, wherein the model parameters in the regulatory assistance pair are the model parameters of the first risk identification model corresponding to each regulatory entity in the regulatory assistance pair;

[0154] The average parameters are written into the first risk identification model to obtain the second risk identification model.

[0155] Optional. The second identification module 57 is also configured to:

[0156] Obtain multi-source metrics of the interaction data, wherein the multi-source metrics include the initiating device and service type of the interaction data;

[0157] Risk identification is performed on the interactive data based on the second risk identification model and the multi-source indicators;

[0158] After identifying the risk characteristics through the risk identification process, the rules for handling the risk characteristics are determined.

[0159] The device initiating the interaction data is adjusted based on the aforementioned processing rules.

[0160] Optionally, the determination module 58 is further configured to:

[0161] The summary of the interaction data and the risk characteristics are written into a preset template to generate the risk report;

[0162] Record the time when the risk report was generated;

[0163] The risk reports are sorted according to their generation time to generate a report chain;

[0164] Traverse the reporting chain, extract the evolution path of risk features from the reporting chain, and send the evolution path of risk features to the edge terminal of the regulatory entity.

[0165] Optionally, the determination module 58 is further configured to:

[0166] The interactive data and the output of the second risk identification model are input into the first risk identification model, wherein the output of the first risk identification model includes the risk assessment result and confidence information of the interactive data.

[0167] It should be noted that the aforementioned determining module 51, first identification module 52, first construction module 53, acquisition module 54, second construction module 55, generation module 56, second identification module 57, and judgment module 58 correspond to steps S201 to S208 in the embodiments. Multiple modules and their corresponding steps implement the same instances and application scenarios, but are not limited to the content disclosed in the above embodiments. It should also be noted that the aforementioned modules, as part of the device, can run on the computer terminal 10 provided in the embodiments.

[0168] According to embodiments of this application, a network security situation awareness system is also provided. Figure 4 This is a structural block diagram of a network security situation awareness system provided according to an embodiment of this application, such as... Figure 4As shown, the network security situation awareness system includes a cloud server and edge terminals, wherein the edge terminals are located in the supervisory entity, and the cloud server is configured as follows:

[0169] After the regulatory entity collects the interactive data sent by the user terminal, it uses a second risk identification model to identify risks in the interactive data.

[0170] The edge terminal is configured as follows:

[0171] After determining that there are no risk features in the interaction data through the second risk identification model, the interaction data is reviewed for risk identification through the first risk identification model.

[0172] The first risk identification model is constructed based on the risk characteristics of abnormal events perceived by the regulatory entity, and the second risk identification model is constructed based on the attribute data of the regulatory entity and the first risk identification model.

[0173] The network security situation awareness system described in this application comprises a cloud server and edge terminals deployed at various regulatory entities, forming a "cloud-edge collaborative" architecture. Each regulatory entity collects local network interaction data through its edge terminal and runs a first risk identification model trained based on its own abnormal events to perform local risk assessment. The cloud server aggregates model parameters uploaded by multiple edge terminals, constructs collaborative pairs based on the attributes of the regulatory entities (such as type and sensitivity), and generates a unified second risk identification model through weighted averaging, which is used for preliminary risk screening of all network interaction data. When the cloud determines that there is no risk, the edge terminal still calls the local first model for verification, realizing dual verification of "cloud initial screening and edge verification" to ensure identification accuracy, while ensuring that data does not leave the domain, thus constructing a secure, efficient, and evolvable distributed situation awareness system.

[0174] Embodiments of this application may provide a computer device. Optionally, in this embodiment, the computer device may be located in at least one of a plurality of network devices in a computer network. The computer device includes a memory and a processor.

[0175] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the network security situation awareness method and device in this application embodiment. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby realizing the aforementioned network security situation awareness method. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to a computer terminal via a network. Examples of the aforementioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0176] The processor can access information and applications stored in the memory via a transmission device to execute the steps of the aforementioned network security situation awareness method.

[0177] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a non-volatile storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0178] Embodiments of this application also provide a non-volatile storage medium. Optionally, in this embodiment, the aforementioned non-volatile storage medium can be used to store the program code executed by the network security situation awareness method provided in the above embodiments.

[0179] Optionally, in this embodiment, the non-volatile storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0180] Embodiments of this application also provide a computer program product, including a computer program. Optionally, in this embodiment, when the computer program is executed by a processor, it can implement the above-described network security situation awareness method.

[0181] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0182] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0183] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0184] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0185] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0186] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a non-volatile storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0187] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A network security situation awareness method, characterized in that, include: Identify the regulatory entities responsible for network security situational awareness and acquire abnormal network security events within those regulatory entities; Identify risk characteristics in the abnormal events, wherein the risk characteristics include at least interactive behavior characteristics and operational behavior characteristics, the interactive behavior characteristics are used to reflect the communication patterns between regulatory entities, and the operational behavior characteristics are used to reflect the operation mode of the user terminal to be sensed; A first risk identification model is constructed based on the aforementioned risk characteristics, and the first risk identification model is deployed on the edge terminal of the regulatory entity. Obtain the attribute data of the regulated entity, wherein the attribute data includes at least the type of the regulated entity and the sensitivity of the regulated entity; A regulatory assistance pair is constructed based on the attribute data, wherein the regulatory assistance pair includes multiple regulatory entities that assist each other, and the regulatory entities in the regulatory assistance pair can use the first risk identification model of the other party to process their own interaction data. Based on the aforementioned regulatory assistance and the first risk identification model, a second risk identification model is generated and deployed on a cloud server; After the regulatory entity collects the interactive data sent by the user terminal, it inputs the interactive data into the second risk identification model for risk identification. If the interactive data contains risk characteristics, the cloud server generates a risk report based on the risk characteristics and sends it to the regulatory entity; if the interactive data does not contain risk characteristics, the interactive data is input into the first risk identification model for risk identification verification.

2. The method according to claim 1, characterized in that, The process of identifying the regulatory entity for network security situation awareness and acquiring abnormal network security events within the regulatory entity includes: Obtain the impact range of each of the aforementioned abnormal events; Based on the scope of impact of the abnormal event, a risk level corresponding to the abnormal event is generated; A risk label is generated based on the risk level, and the risk label is added to the abnormal event.

3. The method according to claim 1, characterized in that, The construction of the first risk identification model based on the risk characteristics includes: The risk features are labeled using a preset terminal to obtain the risk feature labeling results; A training set is generated based on the risk feature annotation results, wherein each regulatory entity corresponds to a training set, and the training set is used to reflect the network environment in which the regulatory entity is located and the corresponding security risk features. The first risk identification model is constructed based on the training set.

4. The method according to claim 3, characterized in that, The method further includes: An inspection set is generated based on the risk feature annotation results; The first risk identification model is trained based on the inspection set, and the model parameters of the first risk identification model are extracted. The model parameters include weight coefficients and / or risk judgment threshold parameters.

5. The method according to claim 1, characterized in that, The step of generating a second risk identification model based on the regulatory assistance pair and the first risk identification model includes: The model parameters in the regulatory assistance pair are weighted and averaged to obtain the average parameters, wherein the model parameters in the regulatory assistance pair are the model parameters of the first risk identification model corresponding to each regulatory entity in the regulatory assistance pair; The average parameters are written into the first risk identification model to obtain the second risk identification model.

6. The method according to claim 5, characterized in that, The method further includes: Determine the adjustment rules for the regulatory assistance pair, wherein the adjustment rules include adjusting the regulatory assistance pair according to time or risk events; After adjusting the regulatory assistance pair based on the aforementioned adjustment rules, the average parameter is updated. Based on the average parameters of the regulatory assistance pair, a corresponding regulatory assistance lookup table is generated.

7. The method according to claim 1, characterized in that, After the regulatory entity collects the interaction data sent by the user terminal, it inputs the interaction data into the second risk identification model for risk identification, including: Obtain multi-source metrics of the interaction data, wherein the multi-source metrics include the initiating device and service type of the interaction data; Risk identification is performed on the interactive data based on the second risk identification model and the multi-source indicators; After identifying the risk characteristics through the risk identification process, the rules for handling the risk characteristics are determined. The device initiating the interaction data is adjusted based on the aforementioned processing rules.

8. The method according to claim 1, characterized in that, If the interactive data contains risk characteristics, the cloud server generates a risk report based on the risk characteristics and sends it to the regulatory entity, including: The summary of the interaction data and the risk characteristics are written into a preset template to generate the risk report; Record the time when the risk report was generated; The risk reports are sorted according to their generation time to generate a report chain; Traverse the reporting chain, extract the evolution path of risk features from the reporting chain, and send the evolution path of risk features to the edge terminal of the regulatory entity.

9. The method according to claim 1, characterized in that, If no risk characteristics are found in the interaction data, the interaction data is input into the first risk identification model for risk identification verification, including: The interactive data and the output of the second risk identification model are input into the first risk identification model, wherein the output of the first risk identification model includes the risk assessment result and confidence information of the interactive data.

10. A network security situation awareness device, characterized in that, include: The module is configured to identify the regulatory entity for network security situation awareness and acquire abnormal network security events in the regulatory entity. The first identification module is configured to identify risk characteristics in the abnormal event, wherein the risk characteristics include at least interactive behavior characteristics and operational behavior characteristics, the interactive behavior characteristics are used to reflect the communication pattern between regulatory entities, and the operational behavior characteristics are used to reflect the user's own operation mode. The first construction module is configured to construct a first risk identification model based on the risk characteristics and deploy the first risk identification model on the edge terminal of the regulatory entity. The acquisition module is configured to acquire attribute data of the regulatory entity, wherein the attribute data includes at least the type of the regulatory entity and the sensitivity of the regulatory entity; The second construction module is configured to construct a regulatory assistance pair based on the attribute data, wherein the regulatory assistance pair includes multiple regulatory entities that assist each other, and the regulatory entities in the regulatory assistance pair can use the other party's first risk identification model to process their own interaction data. The generation module is configured to generate a second risk identification model based on the regulatory assistance pair and the first risk identification model, and deploy the second risk identification model on a cloud server; The second identification module is configured to input the interactive data sent by the user terminal into the second risk identification model for risk identification after the regulatory entity collects the interactive data. The judgment module is configured such that if risk characteristics exist in the interaction data, the cloud server generates a risk report based on the risk characteristics and sends it to the regulatory entity; if no risk characteristics exist in the interaction data, the interaction data is input into the first risk identification model for risk identification verification.

Images