Method, device and system for risk identification and processing of network protocol addresses

Abstract

The application relates to a network protocol address risk identification and processing method, device and system. The method comprises the following steps: in response to a risk identification trigger event, obtaining a target network protocol address and a multi-source data set, and forming a risk identification analysis task; driving risk identification processing of the risk identification analysis task by a management agent intelligent agent; decomposing the risk identification analysis task into multiple subtasks by a planning agent intelligent agent, and distributing each subtask to an execution agent intelligent agent by the management agent intelligent agent; obtaining subtask execution results by executing the subtasks by the execution agent intelligent agent; generating a structured research and judgment report based on the subtask execution results by a reporting agent intelligent agent; checking the structured research and judgment report by a rule engine and generating a candidate work order for blocking; and executing a blocking operation on the target network protocol address in response to a confirmation instruction of an operation and maintenance personnel. The method can realize efficient analysis and disposal of high-risk network protocol addresses.

Description

Technical Field

[0001] This application relates to the field of network security technology, and in particular to a method, apparatus, system, computer equipment, computer-readable storage medium, and computer program product for identifying and processing network protocol addresses at risk. Background Technology

[0002] With the development of computer network technology, network security management is necessary to ensure computer network security. In network security management, identifying and handling risky network protocol addresses (such as IP addresses) is a crucial means of ensuring system security. Related technologies typically rely on preset rules for risk analysis and identification of IP addresses. However, identification methods based on fixed rules struggle to cope with complex and ever-changing attack patterns, and rule configuration depends on human experience, resulting in poor adaptability. Summary of the Invention

[0003] Based on this, it is necessary to provide a method, device, system, computer equipment, computer-readable storage medium, and computer program product that can automatically identify and handle IP address risks to improve the adaptability and compliance closed loop of IP address risk identification and handling.

[0004] Firstly, this application provides a method for risk identification and handling of network protocol addresses, the method including:

[0005] In response to a risk identification trigger event, the system acquires the target network protocol address and a multi-source dataset with time-series correlation within a sliding time window. The multi-source dataset includes log data and recorded intelligence records within the sliding time window. A risk identification analysis task is then generated based on the target network protocol address and the multi-source dataset.

[0006] The risk identification and analysis task is obtained by the management agent, the risk identification and analysis task is driven, and the risk identification and analysis task is sent to the planning agent.

[0007] By planning agent intelligence, the risk identification and analysis task is decomposed into multiple sub-tasks, and the agent intelligence to execute each sub-task is determined. Then, the agent intelligence to manage the agent intelligence distributes each sub-task to the corresponding agent intelligence.

[0008] One or more execution agent intelligent agents execute the corresponding subtasks respectively, and obtain the subtask execution results of each subtask respectively;

[0009] The report agent generates a structured analysis report based on the execution results of each subtask obtained by one or more execution agent agents;

[0010] The rule engine verifies the structured analysis report output by the report agent, and generates a blocking candidate work order if the verification result indicates that the target network protocol address is a blocking candidate.

[0011] In response to the maintenance personnel's confirmation instruction for the blocking candidate work order, the blocking operation is performed on the target network protocol address.

[0012] Based on the scheme of this application embodiment, upon receiving a risk identification trigger event, a risk identification analysis task is generated by acquiring the target network protocol address and a multi-source dataset with temporal correlation within a sliding time window. This task is then processed using a multi-agent collaborative analysis architecture to obtain a structured assessment report. Specifically, a management agent acquires the risk identification analysis task, drives the risk identification processing within the task, and sends the task to a planning agent. The planning agent decomposes the risk identification analysis task into multiple sub-tasks and determines the execution agent for each sub-task. The management agent distributes each sub-task to its corresponding execution agent. One or more execution agents execute their respective sub-tasks and obtain the execution results for each sub-task. A reporting agent generates a structured assessment report based on the execution results obtained by one or more execution agents. The management agent, planning agent, execution agent, and reporting agent... Each intelligent agent performs its specific function, enabling automated decomposition, parallel execution, and result aggregation of risk identification and analysis tasks. For the structured analysis report output by the reporting agent, the rule engine verifies the report and generates a blocking candidate work order. Only upon receiving confirmation from operations personnel is the blocking operation executed on the target network protocol address. This method can handle multiple analysis dimensions simultaneously, significantly improving analysis efficiency. Furthermore, by introducing a sliding time window mechanism to correlate log data and intelligence record data in a time sequence, the behavioral characteristics of the target network protocol address can be obtained more comprehensively, improving the accuracy of risk assessment. The structured analysis of risk identification and analysis tasks is completed through a multi-agent architecture of planning, assignment, parallel execution, and report aggregation. The rule engine verifies the results to form blocking candidate work orders, and manual confirmation by operations personnel serves as the final control measure. Ultimately, security policy facilities are linked to execute the blocking, achieving an efficient and compliant closed-loop analysis and handling of high-risk network protocol addresses.

[0013] In some optional embodiments, the data fields of the log data include: timestamp, client address, request method, request URI, HTTP status code, user agent, referencing page, and transfer volume;

[0014] The data fields of intelligence record data include: unique intelligence identifier, target IP or CIDR network segment, entry person identifier, entry time, source description, and risk summary text.

[0015] Based on this embodiment, the consistency and relevance of multi-source data are ensured through standardized data field definitions, providing a structured data foundation for subsequent intelligent analysis.

[0016] In some alternative embodiments, the sliding time window has a time window length of 2 hours.

[0017] Based on this, by setting the sliding time window length to 2 hours, we can capture enough behavioral samples for analysis without causing the data volume to be too large due to an excessively long time window, which would affect the analysis efficiency.

[0018] In some alternative embodiments, the method includes:

[0019] Upon receiving a trigger command generated based on user operation, it is determined that a risk identification trigger event has been received;

[0020] or;

[0021] According to the configured time period, the log data within the preset time window is aggregated and statistically analyzed to obtain the statistical analysis results. If it is determined whether there are abnormal statistical analysis results based on the statistical analysis results, a risk identification trigger event is received.

[0022] Based on this embodiment, risk identification trigger events can be triggered manually or automatically by aggregating and statistically analyzing log data. This means that it supports both proactive risk identification analysis and handling by operations and maintenance personnel and timely detection of potential risks through periodic automatic scanning, thus achieving an organic combination of proactive defense and reactive response.

[0023] In some alternative embodiments, the method further includes:

[0024] If, based on the statistical analysis results, it is determined whether there are two or more abnormal statistical analysis results, a risk identification trigger event is received.

[0025] Based on this embodiment, a risk identification trigger event is only determined to be received if there are more than two abnormal statistical analysis results based on the statistical analysis results. By setting multiple abnormal judgment conditions, the false alarm rate is reduced and frequent triggering caused by fluctuations in a single abnormal indicator is avoided.

[0026] In some optional embodiments, the results of anomaly statistical analysis include anomalies in access volume, response errors, and resource access patterns.

[0027] Among them, if the total number of requests for a single network protocol address within the sliding time window exceeds the preset request number threshold, it is determined that there is an abnormal access volume.

[0028] If the number of erroneous requests from the client exceeds the first threshold, or the number of erroneous requests from the server exceeds the second threshold, or the ratio of the number of erroneous requests from the client to the number of erroneous requests from the server is greater than a preset ratio, then a response error is determined to exist.

[0029] If the number of unique URIs exceeds a preset threshold, the number of times sensitive path prefixes are hit exceeds a preset threshold, or the proportion of large response downloads exceeds a preset proportion threshold, then an abnormal resource access pattern is identified.

[0030] Based on this embodiment, the anomaly statistical analysis results can include three types of anomaly statistical analysis results: abnormal access volume, abnormal response error, and abnormal resource access pattern. This allows for the assessment of the risk of the target network protocol address from three dimensions: access frequency, error rate, and access behavior pattern. This helps to identify different attack behaviors and improves the comprehensiveness and accuracy of the anomaly statistical analysis results.

[0031] In some optional embodiments, the risk identification and analysis task includes: target network protocol address, trigger source type identifier, log-side reference information, and intelligence-side reference information;

[0032] Among them, the trigger source type identifier includes manual trigger, log rule trigger, or review and rerun trigger;

[0033] The log-side reference information includes access feature digests and searchable indexes. The access feature digests include request volume, status code distribution information, URI distribution digests, and the top N most accessed paths. The searchable indexes include query statements and log entry sampling identifiers.

[0034] The information referenced by the intelligence side includes: the identifier and summary fields of the intelligence record.

[0035] Based on this embodiment, the log-side reference information includes access feature summaries and searchable indexes, while the intelligence-side reference information includes the identifier and summary field of the intelligence record. By encapsulating the information in a structured manner, it not only contains complete contextual information but also avoids redundant transmission of a large amount of raw data through reference indexes or summaries, which helps improve data transmission efficiency and thus helps improve the efficiency of risk analysis.

[0036] In some alternative embodiments, the method further includes:

[0037] Based on the preset deduplication and merging rules, the risk identification and analysis task is deduplicated and merged.

[0038] The deduplication and merging rules include: merging risk identification and analysis tasks triggered multiple times for the same network protocol address within a preset time period into a single risk identification and analysis task; if the network protocol address in the risk identification and analysis task already has a task in the process of risk identification and analysis, or if there is an incomplete blocking candidate work order, temporarily suspending the triggering of the risk identification and analysis task or only logging the risk identification and analysis task; if the risk identification and analysis task is manually triggered, setting the priority of the risk identification and analysis task to the highest.

[0039] Based on this embodiment, by performing deduplication and merging processing on risk identification and analysis tasks using preset deduplication and merging rules, duplicate analysis of the same network protocol address can be avoided, saving computing resources. Specifically, for risk identification and analysis tasks that are manually triggered, their priority is set to the highest level, ensuring timely response to urgent manually triggered tasks.

[0040] In some optional embodiments, the method further includes: if the planning agent fails to decompose the risk identification and analysis task into multiple sub-tasks, performing multiple retries under the control of the management agent; if the number of retries exceeds the maximum number of retries, terminating the execution process of the risk identification and analysis task and recording the reason for failure.

[0041] Based on this embodiment, if the planning agent fails to decompose the risk identification and analysis task into multiple sub-tasks, multiple retries are performed under the control of the management agent. If the number of retries exceeds the maximum number of retries, the execution process of the risk identification and analysis task is terminated. This realizes a fault tolerance mechanism in the analysis process, improves the robustness of the system, and enables automatic recovery when encountering temporary errors, avoiding task loss due to occasional failures.

[0042] In some alternative embodiments, the method further includes:

[0043] The management agent writes each sub-task of a single objective into the planning memory and dispatches it to the corresponding execution agent. The execution results of the execution agent are written into the dialogue memory. The reporting agent generates a structured analysis report based on the complete dialogue history in the dialogue memory.

[0044] Based on this embodiment, by introducing planning memory and dialogue memory mechanisms, state sharing and context transfer among multiple agents such as management agent, planning agent, execution agent and reporting agent are realized, enabling the reporting agent to generate logically coherent judgment reports based on the complete analysis process.

[0045] Secondly, this application also provides a network protocol address risk identification and processing device, including:

[0046] The task triggering module is used to respond to risk identification triggering events, obtain the target network protocol address and the time-series correlation of multi-source datasets within the sliding time window. The multi-source datasets include log data and recorded intelligence record data within the sliding time window, and generate risk identification analysis tasks based on the target network protocol address and the multi-source datasets.

[0047] The multi-agent judgment module is used to obtain risk identification and analysis tasks through the management agent, drive the risk identification and analysis processing of the tasks, and send the risk identification and analysis tasks to the planning agent. The planning agent decomposes the risk identification and analysis tasks into multiple sub-tasks, determines the execution agent for each sub-task, and distributes each sub-task to the corresponding execution agent through the management agent. One or more execution agents execute the corresponding sub-tasks respectively, and obtain the execution results of each sub-task. The reporting agent generates a structured judgment report based on the execution results of each sub-task obtained by one or more execution agents.

[0048] The verification module is used to verify the structured analysis report output by the report agent through the rule engine, and generate a blocking candidate work order if the verification result shows that the target network protocol address is a blocking candidate.

[0049] The confirmation processing module is used to respond to the confirmation command from the operation and maintenance personnel for the blocking candidate work order and to perform the blocking operation on the target network protocol address.

[0050] Thirdly, this application also provides a network protocol address risk identification and processing system, including:

[0051] The task triggering module is used to respond to risk identification triggering events, obtain the target network protocol address and the time-series correlation of multi-source datasets within the sliding time window. The multi-source datasets include log data and recorded intelligence record data within the sliding time window, and generate risk identification analysis tasks based on the target network protocol address and the multi-source datasets.

[0052] The multi-agent device includes a management agent, a planning agent, one or more execution agents, and a reporting agent. The management agent acquires risk identification and analysis tasks, drives risk identification processing for these tasks, sends the risk identification and analysis tasks to the planning agent, and distributes one or more sub-tasks generated by the planning agent to the corresponding execution agents. The planning agent decomposes the risk identification and analysis tasks into multiple sub-tasks. The execution agents execute the corresponding sub-tasks and obtain the execution results of each sub-task. The reporting agent generates a structured analysis report based on the execution results of each sub-task obtained by one or more execution agents.

[0053] The verification module is used to verify the structured analysis report output by the report agent through the rule engine, and generate a blocking candidate work order if the verification result shows that the target network protocol address is a blocking candidate.

[0054] The confirmation processing module is used to respond to the confirmation command from the operation and maintenance personnel for the blocking candidate work order and to perform the blocking operation on the target network protocol address.

[0055] Fourthly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the network protocol address risk identification and processing method of any of the above embodiments.

[0056] Fifthly, this application also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the network protocol address risk identification and processing method of any of the above embodiments.

[0057] Sixthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the network protocol address risk identification and processing method of any of the above embodiments. Attached Figure Description

[0058] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0059] Figure 1 This is an application environment diagram of a network protocol address risk identification and processing method in one embodiment;

[0060] Figure 2 This is a flowchart illustrating a method for identifying and handling network protocol address risks in one embodiment;

[0061] Figure 3 This is a schematic diagram illustrating the interaction flow of a network protocol address risk identification and handling method in an application example.

[0062] Figure 4 This is a schematic diagram of the interaction process for a risk identification and handling method based on manually triggered network protocol addresses in an application example.

[0063] Figure 5 This is a schematic diagram of the interaction flow of a network protocol address risk identification and handling method that is automatically triggered based on log screening in an application example.

[0064] Figure 6 This is a schematic diagram of the interaction process for multi-agent coordination in an application example.

[0065] Figure 7 This is a schematic diagram of the interaction process for multi-agent coordination in an application example.

[0066] Figure 8 This is a structural block diagram of a network protocol address risk identification and processing device in one embodiment;

[0067] Figure 9 This is a block diagram of a network protocol address risk identification and processing system in one embodiment.

[0068] Figure 10 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0069] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0070] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0071] It should be noted that all information and data involved in this application (including but not limited to data used for analysis, stored data, and displayed data) are information and data authorized by the user or fully authorized by all parties, and the acquisition, transmission, storage, use, and processing of related data comply with the relevant provisions of national laws and regulations. Users can refuse content pushed to them or can easily refuse content pushes. In the embodiments of this application, certain existing solutions in the industry, such as software, components, and models, may be mentioned. These should be considered exemplary, and their purpose is merely to illustrate the feasibility of implementing the technical solution of this application, but does not mean that the applicant has already used or necessarily used such a solution.

[0072] Currently, in network security management, relevant organizations (such as financial institutions and government / enterprise intranets) generally rely on access layers (e.g., Nginx (a high-performance web server and access layer gateway)) to collect access log data, while also receiving intelligence records (e.g., high-risk IP intelligence) from regulatory agencies and higher-level units. These technologies typically employ manual assessment, rule matching, or single large-scale model analysis to evaluate the acquired data, which leads to problems such as delayed assessment, untraceable evidence, model illusions, and non-compliant handling. For example, there are several issues: First, intelligence and log data sources are fragmented: regulatory / parent bank intelligence can only be manually entered and cannot be integrated with automated log data, leading to incomplete analysis and untraceable conclusions. Second, the illusion of large models is uncontrollable: direct analysis of logs by a single large model can easily result in fabricated statistics, drifting conclusions, and the inability to verify key indicators. Third, non-compliant processing procedures: automatic blocking lacks manual gates, failing to meet operational and maintenance systems and financial regulatory compliance requirements. Fourth, low analysis efficiency: tasks are not broken down or executed in parallel, resulting in long analysis chains and high latency. Fifth, unclear evidence boundaries: the scope of evidence is chaotic, making auditing and review difficult. Sixth, imperfect triggering mechanisms: duplicate triggering, missed triggering, and chaotic priorities lead to wasted resources.

[0073] Based on this, embodiments of this application provide a method for identifying and handling network protocol addresses that is auditable, traceable, low-illusion, compliant and controllable, and features intelligent analysis and blocking linkage of high-risk network protocol addresses. The network protocol address risk identification and handling method provided in this application embodiment can be applied to, for example... Figure 1In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104 or located in the cloud or on other network servers. Terminal 102 or server 104 can respond to a risk identification trigger event to initiate a risk identification and processing process for network protocol addresses. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, projection devices, etc. Portable wearable devices can include smartwatches, smart bracelets, head-mounted devices, etc. Head-mounted devices can be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc. Server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0074] In one exemplary embodiment, such as Figure 2 As shown, a method for risk identification and handling of network protocol addresses is provided, which is applied to... Figure 1 Taking server 104 as an example, the explanation includes the following steps 201 to 207. Wherein:

[0075] Step 201: In response to the risk identification trigger event, obtain the target network protocol address and the multi-source dataset with time-series correlation within the sliding time window. The multi-source dataset includes log data and recorded intelligence record data within the sliding time window, and generate a risk identification analysis task based on the target network protocol address and the multi-source dataset.

[0076] A risk identification trigger event refers to an event that triggers the risk identification and processing of the network protocol address in this application, or an event that triggers the generation of a risk identification analysis task. As the starting point for the risk identification analysis task, it can trigger the subsequent risk identification and processing process for the network protocol address.

[0077] A sliding time window refers to a fixed, rolling time period (such as the last 1 hour, the last 2 hours, etc., which slides automatically over time and is not a fixed start and end date), only taking ordered data within the window period. The length of the sliding time window is unlimited; in some examples, it can be set to 2 hours, thus capturing enough behavioral samples for analysis without causing the data volume to become too large and affecting analysis efficiency due to an excessively long time window.

[0078] The specific data type of log data is not limited; for example, the log data in some examples can be log data.

[0079] Intelligence record data refers to intelligence data provided by higher-level departments or regulators. For example, regulators may release high-risk IPs or related notifications through portal websites and other channels, and higher-level agencies may provide relevant intelligence data to lower-level agencies.

[0080] Step 202: Obtain the risk identification and analysis task through the management agent, drive the risk identification processing of the risk identification and analysis task, and send the risk identification and analysis task to the planning agent.

[0081] An intelligent agent is a module with independent task execution capabilities. The management agent is an intelligent agent used to perform top-level scheduling and overall management. The risk identification and analysis task generated above can be input into the management agent. The management agent initiates the overall risk identification and analysis process for the risk identification and analysis task and sends the risk identification and analysis task to the planning agent.

[0082] Step 203: Decompose the risk identification and analysis task into multiple sub-tasks by planning the agent, determine the execution agent for each sub-task, and distribute each sub-task to the corresponding execution agent by managing the agent.

[0083] The planning agent is an intelligent agent used to decompose tasks. Based on the risk identification and analysis task issued by the management agent, it can break down the risk identification and analysis task into multiple independently executable sub-tasks, and determine the execution agent for each sub-task. The specific way the planning agent breaks down the risk identification and analysis task is not limited, as long as it can break down the risk identification and analysis task into multiple independently executable sub-tasks.

[0084] Step 204: Execute the corresponding subtasks through one or more execution agent intelligent agents, and obtain the subtask execution results of each subtask.

[0085] Step 205: Generate a structured analysis report by reporting agent based on the execution results of each subtask obtained by one or more execution agent agents.

[0086] Step 206: Verify the structured analysis report output by the report agent through the rule engine, and generate a blocking candidate work order if the verification result shows that the target network protocol address is a blocking candidate.

[0087] Step 207: In response to the operation and maintenance personnel's confirmation instruction for the blocking candidate work order, perform the blocking operation on the target network protocol address.

[0088] Based on the scheme of this application embodiment, upon receiving a risk identification trigger event, a risk identification analysis task is generated by acquiring the target network protocol address and a multi-source dataset with temporal correlation within a sliding time window. This task is then processed using a multi-agent collaborative analysis architecture to obtain a structured assessment report. Specifically, a management agent acquires the risk identification analysis task, drives the risk identification processing within the task, and sends the task to a planning agent. The planning agent decomposes the risk identification analysis task into multiple sub-tasks and determines the execution agent for each sub-task. The management agent distributes each sub-task to its corresponding execution agent. One or more execution agents execute their respective sub-tasks and obtain the execution results for each sub-task. A reporting agent generates a structured assessment report based on the execution results obtained by one or more execution agents. The management agent, planning agent, execution agent, and reporting agent are involved in this process. Each component performs its specific function, enabling automated decomposition, parallel execution, and result aggregation of risk identification and analysis tasks. For the structured analysis reports output by the reporting agent, the rule engine verifies these reports and generates blocking candidate work orders. Only upon receiving confirmation from operations personnel is the blocking operation executed on the target network protocol address. This method can handle multiple analysis dimensions simultaneously, significantly improving analysis efficiency. Furthermore, by introducing a sliding time window mechanism to correlate log data and intelligence records in a time sequence, the behavioral characteristics of the target network protocol address can be obtained more comprehensively, improving the accuracy of risk assessment. The structured analysis of risk identification and analysis tasks is completed through a multi-agent architecture of planning, assignment, parallel execution, and report aggregation. Blocking candidate work orders are generated through rule engine verification, and final control is achieved through manual confirmation by operations personnel. Ultimately, security policy facilities are linked to execute the blocking, realizing a closed loop for efficient, compliant, traceable, and low-illusion analysis and handling of high-risk network protocol addresses.

[0089] In some optional embodiments, the data fields of the log data include: timestamp, client address, request method, request URI, HTTP status code, user agent, referencing page, and transfer volume;

[0090] The data fields of intelligence record data include: unique intelligence identifier, target IP or CIDR network segment, entry person identifier, entry time, source description, and risk summary text.

[0091] Based on this embodiment, the consistency and relevance of multi-source data are ensured through standardized data field definitions, providing a structured data foundation for subsequent intelligent analysis.

[0092] The specific event type of the risk identification trigger event is not limited. In some optional embodiments, the method includes: upon receiving a trigger instruction generated based on a user operation, determining that a risk identification trigger event has been received. In some optional embodiments, the method includes:

[0093] According to the configured time period, the log data within the preset time window is aggregated and statistically analyzed to obtain the statistical analysis results. If it is determined whether there are abnormal statistical analysis results based on the statistical analysis results, a risk identification trigger event is received.

[0094] Accordingly, risk identification events can be triggered manually or automatically by aggregating and statistically analyzing log data. This means that it supports both proactive risk identification, analysis and handling by operations and maintenance personnel and timely detection of potential risks through periodic automatic scanning, thus achieving an organic combination of proactive defense and reactive response.

[0095] In some alternative embodiments, the method further includes:

[0096] If, based on the statistical analysis results, it is determined whether there are two or more abnormal statistical analysis results, a risk identification trigger event is received.

[0097] Based on this embodiment, a risk identification trigger event is only determined to be received if there are more than two abnormal statistical analysis results based on the statistical analysis results. By setting multiple abnormal judgment conditions, the false alarm rate is reduced and frequent triggering caused by fluctuations in a single abnormal indicator is avoided.

[0098] In some optional embodiments, the results of the anomaly statistical analysis include anomalies in access volume, response errors, and resource access patterns.

[0099] Among them, if the total number of requests for a single network protocol address within the sliding time window exceeds the preset request number threshold, it is determined that there is an abnormal access volume.

[0100] If the number of erroneous requests from the client exceeds the first threshold, or the number of erroneous requests from the server exceeds the second threshold, or the ratio of the number of erroneous requests from the client to the number of erroneous requests from the server is greater than a preset ratio, then a response error is determined to exist.

[0101] If the number of unique URIs exceeds a preset threshold, the number of times sensitive path prefixes are hit exceeds a preset threshold, or the proportion of large response downloads exceeds a preset proportion threshold, then an abnormal resource access pattern is identified.

[0102] Based on this embodiment, the anomaly statistical analysis results can include three types of anomaly statistical analysis results: abnormal access volume, abnormal response error, and abnormal resource access pattern. This allows for the assessment of the risk of the target network protocol address from three dimensions: access frequency, error rate, and access behavior pattern. This helps to identify different attack behaviors and improves the comprehensiveness and accuracy of the anomaly statistical analysis results.

[0103] In some optional embodiments, the risk identification and analysis task includes: target network protocol address, trigger source type identifier, log-side reference information, and intelligence-side reference information;

[0104] Among them, the trigger source type identifier includes manual trigger, log rule trigger, or review and rerun trigger;

[0105] The log-side reference information includes access feature digests and searchable indexes. The access feature digests include request volume, status code distribution information, URI distribution digests, and the top N most accessed paths. The searchable indexes include query statements and log entry sampling identifiers.

[0106] The information referenced by the intelligence side includes: the identifier and summary fields of the intelligence record.

[0107] Based on this embodiment, the log-side reference information includes access feature summaries and searchable indexes, while the intelligence-side reference information includes the identifier and summary field of the intelligence record. By encapsulating the information in a structured manner, it not only contains complete contextual information but also avoids redundant transmission of a large amount of raw data through reference indexes or summaries, which helps improve data transmission efficiency and thus helps improve the efficiency of risk analysis.

[0108] In some alternative embodiments, the method further includes:

[0109] Based on the preset deduplication and merging rules, the risk identification and analysis task is deduplicated and merged.

[0110] The deduplication and merging rules include: merging risk identification and analysis tasks triggered multiple times for the same network protocol address within a preset time period into a single risk identification and analysis task; if the network protocol address in the risk identification and analysis task already has a task in the process of risk identification and analysis, or if there is an incomplete blocking candidate work order, temporarily suspending the triggering of the risk identification and analysis task or only logging the risk identification and analysis task; if the risk identification and analysis task is manually triggered, setting the priority of the risk identification and analysis task to the highest.

[0111] Based on this embodiment, by performing deduplication and merging processing on risk identification and analysis tasks using preset deduplication and merging rules, duplicate analysis of the same network protocol address can be avoided, saving computing resources. Specifically, for risk identification and analysis tasks that are manually triggered, their priority is set to the highest level, ensuring timely response to urgent manually triggered tasks.

[0112] In some optional embodiments, the method further includes: if the planning agent fails to decompose the risk identification and analysis task into multiple sub-tasks, performing multiple retries under the control of the management agent; if the number of retries exceeds the maximum number of retries, terminating the execution process of the risk identification and analysis task and recording the reason for failure.

[0113] Based on this embodiment, if the planning agent fails to decompose the risk identification and analysis task into multiple sub-tasks, multiple retries are performed under the control of the management agent. If the number of retries exceeds the maximum number of retries, the execution process of the risk identification and analysis task is terminated. This realizes a fault tolerance mechanism in the analysis process, improves the robustness of the system, and enables automatic recovery when encountering temporary errors, avoiding task loss due to occasional failures.

[0114] In some alternative embodiments, the method further includes:

[0115] The management agent writes each sub-task of a single objective into the planning memory and dispatches it to the corresponding execution agent. The execution results of the execution agent are written into the dialogue memory. The reporting agent generates a structured analysis report based on the complete dialogue history in the dialogue memory.

[0116] Based on this embodiment, by introducing planning memory and dialogue memory mechanisms, state sharing and context transfer among multiple agents such as management agent, planning agent, execution agent and reporting agent are realized, enabling the reporting agent to generate logically coherent judgment reports based on the complete analysis process.

[0117] Based on the above embodiments, the following references Figures 3 to 7 This will be explained in detail with a specific example.

[0118] During the execution of the scheme in the embodiments of this application, log data and intelligence record data are first obtained, and the log data may be Nginx log data.

[0119] In related embodiments, log data can be read automatically and continuously. For example, Nginx access layer logs can be collected in streaming, near real-time, or configurable batch processing mode, and the data in the Nginx access layer logs can be parsed, such as parsing into structured access record log data. The fields of the log data may include: timestamp, client IP (proxy chain normalization), request method, request URI (Uniform Resource Identifier, a string that uniquely identifies the location or name of a resource in a Uniform Resource Locator URL), HTTP status code, User-Agent / Referer, response size / transfer volume.

[0120] The obtained log data can be stored in a log retrieval system, a data lake, or an analytics storage system, while the memory / stream processing engine only retains the most recent time window's rolling aggregation results.

[0121] The intelligence record data obtained may include high-risk IP intelligence data. In related technical fields, regulators may publish high-risk IPs or related notifications through portal websites and other channels, and higher-level institutions may provide relevant intelligence data to lower-level institutions (e.g., group institutions may provide relevant intelligence data to their subsidiaries, or parent banks or bank holding groups may provide relevant intelligence data to their subsidiaries). Considering the potential risks of poor stability or low machine-readable accuracy when obtaining this intelligence record data through automatic pull interfaces, in the relevant embodiments of this application, the intelligence record data obtained by security or operations personnel can be copied, organized, and then manually entered to form intelligence record data. For example, it can be recorded as a logical entity called IntelRecord (high-risk intelligence record entity). In terms of specific technical implementation, it can be any method such as form, file import, or API submission, and this application embodiment does not make specific limitations.

[0122] Each intelligence record in the intelligence log data must contain at least the following information elements to support interpretation, citation, and auditing in subsequent processing:

[0123] A unique identifier for intelligence (such as intel_id, which can be generated by the system);

[0124] The target IP address or CIDR (Classless Inter-Domain Routing) network segment;

[0125] The person who entered the data and the time of entry;

[0126] Source information (such as regulatory website section, parent bank notification number, or attachment index, for tracing the source);

[0127] Risk summary text (a structured or semi-structured description of the key points to be copied).

[0128] In the relevant examples, a single intelligence record in the intelligence log data may also contain the following information elements: intelligence validity period, regulatory requirement processing time limit, risk level or tag, and other metadata. Among them, the time-related fields in the intelligence record (such as intelligence validity period, regulatory requirement processing time limit, etc.) can mainly serve management attributes such as notification timeliness, processing time limit, and whether it has expired; they do not replace the unified evidence time window for Nginx access behavior described below.

[0129] To strike a balance between computational cost, relevance of evidence, and interpretability, a unified time window strategy can be used to characterize the local access behavior represented by the obtained log data (e.g., Nginx-based log data) (also referred to as a unified evidence time window in related examples of this application). In a specific example, this could be as follows: Let the reference time for the actual triggering of the task or the initiation of the session be... Taking a preset time window of 2 hours as an example, the default is within the closed interval. Within this scope, access metrics aggregation, statistical feature extraction, and log sampling are performed on the target client IP, serving as the primary evidence range for the "log forensics" steps in multi-agent analysis, referred to as the two-hour evidence window.

[0130] The constraints on the duration of the preset time window include:

[0131] Consistent with clock synchronization: All-link parsing, aggregation, and session referencing use the same time zone and time synchronization to avoid cross-source time misalignment;

[0132] Decoupling from time-related fields in intelligence record data (also known as intelligence field decoupling): that is, the notification date, required completion time, etc. in intelligence record data are used for priority, handling SLA (Service Level Agreement), whether it has expired, and other policy judgments; whether there is an abnormal access pattern locally is still based on the Nginx structured record within the preset time window (e.g., within a two-hour evidence window).

[0133] It is understood that the specific duration of the preset time window can be adjusted based on the operation and maintenance strategy. For example, it can be set to 1 hour in some examples. In the relevant embodiments of this application, the preset time window duration can be set to the most recent consecutive 2 hours by default.

[0134] Determine whether a risk identification trigger event has been received. If a risk identification trigger event has been received, generate a risk identification analysis task.

[0135] In this embodiment, a risk identification trigger event refers to the generation of a risk identification analysis task when the risk identification trigger event occurs, thereby initiating or continuing a risk analysis process targeting a specified client IP (or a batch of IPs). In related examples, generating a risk identification analysis task means generating a risk identification analysis task (which may also be called an assessment task in some scenarios) that can be consumed by the multi-agent orchestration engine, thereby initiating or continuing a high-risk intelligent analysis process targeting a specified client IP (or a batch of IPs).

[0136] Among them, the risk identification trigger event can be configured according to actual technical needs, and can be configured in a way that is traceable from the source and decoupled from the specific persistence implementation. The specific way of configuring the trigger conditions is not specifically limited in this application embodiment.

[0137] In the relevant examples of this application, regardless of how the risk identification trigger event is set, the information of the generated risk identification analysis task shall at least include the following:

[0138] Target objects: These must include one or more client IPs to be analyzed.

[0139] Trigger source type identifier: used for auditing and policy routing (such as manual, log rules, review rerun, etc.);

[0140] Citation of evidence:

[0141] For the Nginx side: access feature summaries (such as request volume, status code distribution, URI distribution summary, Top-N paths, etc.) and / or searchable indexes pointing to the underlying logs (such as query statements, log entry sampling identifiers, etc.);

[0142] For the intelligence side: if it exists, it includes the identifier and summary fields of the corresponding intelligence record, so that subsequent intelligent agents do not have to rely on human verbal transmission of information.

[0143] In some examples, the triggering condition may include receiving a trigger command based on user action, i.e., manual triggering.

[0144] In manually triggered scenarios, in some examples, operations or security personnel can perform at least one operation within the unified processing or intelligence maintenance interface: specify the target IP and explicitly initiate an analysis. Upon receiving this operation from the user on the interface, the triggering condition is considered met, and in response to the trigger command, the following operations are automatically completed:

[0145] Perform aggregate statistics on the data of the target IP within a two-hour evidence window to generate an access feature summary;

[0146] If the IP address has both unexpired and recently entered intelligence records, then the corresponding IntelRecord key fields (identifier, summary, time-limited metadata) will be bound.

[0147] Based on the information obtained above, a risk identification and analysis task is generated, which encapsulates the above information and is submitted to the multi-agent orchestration process.

[0148] The scenarios in which triggering commands are issued manually are not limited. In some examples, it may be in situations where regulatory notices have just arrived, instructions from the parent bank are clear, immediate record-keeping and analysis are required, or automatic log rules have not yet been covered. In some examples, manual triggering may be used as a backup triggering scheme to serve as a fallback entry point when automatic triggering fails, which helps to improve the reliability of the risk identification system.

[0149] In some examples, the triggering condition can be an automatic triggering condition. For example, if log data is statistically analyzed according to a set time period, and the obtained statistical analysis results show abnormal results, it can be determined that the triggering condition is met.

[0150] For example, log data within a preset time window can be aggregated and statistically analyzed according to a configured time period, and the results can be used to determine whether there are any abnormal statistical analysis results. Some possible abnormal statistical analysis results may include:

[0151] Abnormal access volume: For example, the total number of requests from a single IP address within a two-hour window exceeds the dynamic baseline or a fixed threshold;

[0152] Response error exception: The number of client error (4xx) requests exceeds the first threshold, or the number of server error (5xx) requests exceeds the second threshold, or the ratio of the number of client error requests to the number of server error requests is greater than the preset ratio;

[0153] Abnormal resource access patterns: For example, the number of unique URIs (i.e., the number of deduplicated request URIs) exceeds the preset threshold, the number of times sensitive path prefixes are hit is greater than the preset threshold, and the proportion of large response downloads (i.e., the ratio of the number of requests with response body sizes exceeding the preset threshold to the total number of requests) exceeds the preset threshold.

[0154] In some examples, the presence of any one of the aforementioned abnormal statistical analysis results is sufficient to determine the existence of an anomaly and fulfill the triggering condition. In the embodiments of this application, an anomaly is considered to exist and the triggering condition is fulfilled only when two or more of the aforementioned abnormal statistical analysis results are present, thereby reducing false alarms caused by accidental fluctuations of a single indicator.

[0155] It is understandable that in practical technical applications, mechanisms triggered by statistical analysis results and those triggered manually can coexist. For example, when there are already pending intelligence records for the same IP, a screening hit can increase the task priority or merge evidence packages, but whether to generate a blocking recommendation is still determined by subsequent analysis and manual confirmation strategies.

[0156] Subsequently, the triggered risk identification and analysis tasks were deduplicated and merged.

[0157] In practical technical applications, since intelligence entry and log rule scanning may trigger the same target IP multiple times within a short period of time, deduplication and merging can be performed to reduce redundant arrangement and resource waste. In the embodiments of this application, deduplication / merging strategies can be configured on the implementation side. Specific deduplication / merging strategies may include, for example:

[0158] Merge based on proximity: The merge will be done in a preset time (e.g., ...). Multiple triggers on the same IP within a set time (minutes) are merged into one analysis session. In other words, risk identification and analysis tasks that are triggered multiple times on the same network protocol address within a preset time are merged into one risk identification and analysis task.

[0159] State awareness suppression: If the IP already has an ongoing analysis session or an incomplete manual processing work order, you can choose to postpone the new trigger or only record the audit event log. That is, if the network protocol address in the risk identification and analysis task already has a task in the process of risk analysis and identification, or has an incomplete blocking candidate work order, postpone the triggering of the risk identification and analysis task or only record the log of the risk identification and analysis task.

[0160] Priority coverage: Manual triggering can override or automatic triggering can be skipped to meet emergency response habits.

[0161] Based on the risk identification and analysis tasks generated by the aforementioned triggers, a complete and traceable task input can be formed. On this basis, intelligence interpretation, log forensics, conflict analysis, and conclusion merging can be performed on risk identification personnel. For example, a multi-agent orchestration engine can be set up and deployed, and the engine can perform intelligence interpretation, log forensics, conflict analysis, and conclusion merging based on the input risk identification and analysis tasks. The trigger itself does not directly generate a blocking action, thus connecting with the overall workflow of analysis—recommendation—manual confirmation—execution.

[0162] Taking the process of setting up and deploying a multi-agent orchestration engine as an example, it can be implemented based on a planning-execution-reporting framework. This framework determines role assignments and execution order, ensuring auditable task decomposition, traceable subtask status, and conclusion summarization based on the complete context rather than a single question-and-answer session. Some examples of multi-agent orchestration engines may include: a management agent, a planning agent, an execution agent, and a reporting agent.

[0163] In this system, the management agent acts as the team manager within the multi-agent orchestration engine. It is responsible for the entire lifecycle management of a risk identification and analysis task (also known as a judgment task), including but not limited to: receiving input from the risk identification and analysis task; maintaining session rounds and current objectives; performing cyclical control according to a predetermined maximum number of rounds; retrying according to a strategy up to the upper limit when planning fails; dispatching subtasks to designated execution agents (e.g., intelligence interpretation agent, log forensics agent, and indicator verification agent); scheduling multiple independent subtasks in parallel when necessary; and outputting the reason for failure and terminating the session in abnormal situations. The management agent can be used to ensure the convergence and repeatability of the planning-execution-summarization process in risk identification.

[0164] The planning agent, primarily used for task decomposition and agent assignment, takes natural language and / or structured context as input, combines intermediate conclusions obtained from historical dialogues with tool feedback, and generates a single subtask for the next step. Subtasks should ideally meet the following requirements: single objective, complete parameters, and executable under current information conditions, avoiding the stacking of multiple objectives into an unverifiable step.

[0165] There are no restrictions on how the agent generates subtasks. In some examples, subtasks can be generated by explicitly specifying them, such as by explicitly specifying the following information:

[0166] Execute the agent's name or role identifier (corresponding to the agent capability descriptions registered in the system);

[0167] Task objective description;

[0168] Task parameter payload (e.g., target IP, indicator snapshot identifier within the two-hour evidence window, intelligence record identifier, summary of log query conditions to be invoked, etc.).

[0169] When the planning agent determines that it has reached a definite conclusion on the user's problem / task objective, it can generate a sorting subtask for the reporting agent to transfer the responsibility of the final response to the reporting agent, so as to avoid outputting the final conclusion in advance without summarizing the evidence chain.

[0170] When the planning agent fails (for example), it can retry a limited number of times under the control of the management agent. If the number of retries exceeds the maximum number of retries, the execution process of this risk identification and analysis task will be terminated and the reason for failure will be recorded.

[0171] The subtasks generated by the planning agent can be dispatched by the management agent. Each subtask dispatched by the management agent corresponds to a plan item in the plan memory, which records the task identifier, title, executing agent, parameter content, and execution status. The execution status can be divided into three states: running, completed, and failed, but is not limited to these.

[0172] Among them, the planning agent can update the planning status of sub-tasks before and after dispatching sub-tasks, so that the judgment process of risk identification and analysis tasks can be visualized externally and audited internally, and can help locate failure links.

[0173] The execution agent is used to complete the specific sub-tasks assigned by the planning agent. The execution agents can be distinguished according to domain, etc., and multiple different types of execution agents can be set up. Some typical execution agents involved in the embodiments of this application may include, but are not limited to:

[0174] Intelligence interpretation agent: used to convert log data summaries and metadata into a list of structured threat hypotheses, urgency elements, and propositions that need to be verified on the log side;

[0175] Log Evidence Agent: Used to verify or refute propositions based on aggregated metrics and log sampling within a two-hour evidence window, and output evidence entries with reference indexes.

[0176] Indicator validation agent: Used to verify key statistics or perform consistency checks on outlier counts, reducing the risk of unverifiable results caused by relying solely on language model descriptions.

[0177] Among them, the execution agent can access the log retrieval system, indicator service or internal API through tools. The data obtained through tool calls can be structured data, so as to facilitate the entry of dialogue memory and report summary.

[0178] In the same planning round, when multiple subtasks are independent and have no sequential dependencies, the management agent can dispatch and execute these subtasks in parallel to shorten end-to-end analysis latency. For subtasks with dependencies (e.g., a subtask requiring intelligence field verification before log forensics), the planning agent can set the order of subtasks in the task sequence or use other methods to indicate the priority of each task. The management agent can then proceed based on this order or continue planning in a new round.

[0179] The report agent is used to merge the conclusions of each executing agent and output a structured result.

[0180] When the reporting agent and other execution agents appear in the same planning dimension, a delayed execution strategy can be adopted: the subtasks of other execution agents are completed first and written into the dialogue memory and historical messages, then the reporting agent generates the final output based on the complete historical dialogue ordered by round, thus avoiding premature output of the final conclusion before key evidence is complete. Understandably, if the planning agent explicitly indicates that only the reporting agent needs to organize the data, then the conditions for summarization are considered met, and the reporting agent can directly proceed to the reporting step.

[0181] The report agent can merge conclusions using a globally aggregated merging mechanism and then output structured data. For example, on the input side, the report agent obtains historical dialogues ordered by time or round, including planning outputs, intermediate conclusions from each executing agent, tool return summaries, and necessary original user / task descriptions. On the output side, it generates a comprehensive, maintenance-readable response and simultaneously generates machine-readable structured fields for subsequent rule validation and work order system integration. This merging mechanism differs from simple voting or hard-coded rule concatenation, emphasizing the traceability of the evidence chain within the dialogue sequence.

[0182] The specific field types of the structured fields output by the report agent are not limited; some examples may include, but are not limited to, the following field types:

[0183] Risk level or assessment label (e.g., low / medium / high / critical);

[0184] Evidence citation set: intelligence record identifiers, indicator snapshot identifiers, log sampling identifiers, etc.;

[0185] Conflict marker: Whether there is a conflict between intelligence and log evidence, and a brief description thereof;

[0186] Suggested action type: No action, continuous observation, or ban candidate (only a candidate, not to be taken directly);

[0187] Draft blocking recommendation: Target IP / CIDR, recommended duration, scope of action (e.g., inbound blocking only), exception description (draft level);

[0188] Manual gate marker: Indicates that the blocked path must be confirmed by operations and maintenance (can be fixed as true with global policy).

[0189] In some examples of embodiments of this application, the report agent can be configured with credibility constraints and output structured reports under the credibility constraints. The credibility constraints configured in some examples may include: prioritizing the use of indicator snapshots or tool return values ​​for accurate counts and statistical conclusions; prohibiting the fabrication of quantitative results that do not appear in the given materials; and outputting a message indicating insufficient information and guiding supplementary evidence collection subtasks or manual supplementation of intelligence fields if the materials are insufficient to answer the questions, but are not limited to these.

[0190] Based on the scheme of this application embodiment, the structured report output by the report agent does not directly execute the blocking of IP addresses, that is, it is not equivalent to the blocking execution instruction. In this application embodiment, the blocking can be determined based on the linkage mechanism of condition judgment → work order candidate → operation and maintenance confirmation → policy issuance.

[0191] In the process of condition determination, a hierarchical condition structure can be used. In the relevant examples of this application, a three-layer hierarchical structure can be used for determination. The three-layer hierarchical structure can include: a rule engine layer, a consistency verification layer, and an execution gate layer.

[0192] The rule engine layer, acting as a deterministic threshold, reads the structured reports and intelligence metadata, as well as key indicator snapshots, output by the report agent to determine whether entry into the ban ticket candidate pool is permitted. Some examples of the judgment rules may include:

[0193] There are intelligence records that have not expired and whose risk level has reached the threshold; or, the log-side rules reach a strong trigger condition within a two-hour evidence window; or, at the same time, mandatory rejection conditions are set, such as the target hitting the operation and maintenance whitelist (trusted partner exit, known CDN origin segment, etc.), missing evidence references, failure of key sub-tasks and failure to recover, etc.; if a rejection condition occurs, no blocking work order candidate shall be generated.

[0194] The consistency verification layer is used to implement consistency verification. The specific verification content may include, but is not limited to: verifying the completeness of structured fields and the legality of enumerations; verifying whether the blocking candidates are consistent with the output of the rule engine. If they are inconsistent, a secondary planning (limited number of times) or a record difference audit can be triggered.

[0195] The execution access control layer is used to generate blocking work orders. The execution access control layer is always in effect. Even if the rule engine layer and consistency verification layer pass the verification, the execution access control layer is prohibited from directly issuing blocking orders. It only generates or updates blocking work orders that are pending confirmation from operations and maintenance.

[0196] The policy facilities in the generated blocking work order can include the blocking linkage objects. Specific policy facilities can include, but are not limited to, firewall ACLs (Access Control Policies), WAF (Web Application Firewall) policies, cloud security groups, zero-trust gateways, etc. The linkage interface can be an API, command issuance, or work order-driven automated orchestration, but is not limited to these.

[0197] The blocking work order generated by the access control layer (i.e., the blocking work order that determines the link output meets the candidate conditions) can include the following information:

[0198] Associate the analysis of session identifiers with target IPs;

[0199] Two-hour evidence window start and end times and evidence citation index;

[0200] Intelligence record summary and identifier (if any);

[0201] Conclusion snapshot and rule engine judgment summary;

[0202] Recommended parameters to be blocked;

[0203] Work order status;

[0204] SLA / Regulatory deadline reminder (if any).

[0205] Once the access control layer generates a blocking work order, it can be added to the maintenance workbench queue for maintenance personnel to confirm.

[0206] If the operations and maintenance personnel confirm that the status is "confirmed," meaning that the operations and maintenance personnel have explicitly agreed to the blocking, then the parameters can be revised and the differences in the revisions can be recorded.

[0207] If the operations and maintenance personnel confirm that the status is rejected, they should record the rejection reason code.

[0208] If the operations and maintenance personnel confirm that the status is "submitted for execution," they will initiate the distribution to the policy facility.

[0209] If the execution is successful or fails, the receipt and the triggering of the failure compensation strategy will be recorded.

[0210] If the ban is lifted upon expiration or manually closed, the ban can be closed.

[0211] In this process, operations and maintenance personnel can complete approvals on an independent security operations platform, decoupling them from conversational assessments and making audits clearer. In some examples, steps requiring manual input can be inserted, treating operations and maintenance confirmation as an external message input for continued planning (consistent with the human-in-the-loop approach in some frameworks), thus achieving human-machine collaborative conversational confirmation. Throughout this process, the manually output information, along with other related information, is also recorded in the same work order audit record.

[0212] In the above process, the external policy distribution request is only generated after the operation and maintenance personnel confirm the blocking work order. In addition, the operator, time, parameters and equipment receipts are recorded throughout the process to meet the common traceability requirements of the financial industry.

[0213] If the operations and maintenance department refuses or requests supplementary evidence, a new assessment task input can be triggered (the trigger type can be marked as review), inheriting the version number of the historical evidence to achieve a re-run of the review.

[0214] The blocking policy will be automatically lifted upon expiration or a review and lifting process will be triggered, and the information will be written to the audit log.

[0215] During the above process, cases of false blocking, business impact, and missed judgment can be collected and used to adjust rule thresholds, sensitive path tables, prompt word constraints, and planning constraints to achieve feedback optimization.

[0216] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0217] Based on the same inventive concept, this application also provides a network protocol address risk identification and processing device for implementing the network protocol address risk identification and processing method described above. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations in one or more network protocol address risk identification and processing device embodiments provided below can be found in the limitations of the network protocol address risk identification and processing method described above, and will not be repeated here.

[0218] In one exemplary embodiment, such as Figure 8 As shown, a network protocol address risk identification and processing device is provided, including: a task triggering module 801, a multi-agent judgment module 802, a verification module 803, and a confirmation processing module 804, wherein:

[0219] The task triggering module 801 is used to respond to the risk identification triggering event, obtain the target network protocol address and the time-series correlated multi-source dataset within the sliding time window. The multi-source dataset includes log data and recorded intelligence record data within the sliding time window, and generates a risk identification analysis task based on the target network protocol address and the multi-source dataset.

[0220] The multi-agent judgment module 802 is used to obtain risk identification and analysis tasks through the management agent, drive risk identification processing of the risk identification and analysis tasks, and send the risk identification and analysis tasks to the planning agent; the planning agent decomposes the risk identification and analysis tasks into multiple sub-tasks, determines the execution agent for each sub-task, and distributes each sub-task to the corresponding execution agent through the management agent; one or more execution agents execute the corresponding sub-tasks respectively, and obtain the sub-task execution results of each sub-task; the reporting agent generates a structured judgment report based on the sub-task execution results obtained by one or more execution agents.

[0221] The verification module 803 is used to verify the structured analysis report output by the report agent through the rule engine, and generate a blocking candidate work order if the verification result shows that the target network protocol address is a blocking candidate.

[0222] The confirmation processing module 804 is used to respond to the confirmation command of the operation and maintenance personnel for the blocking candidate work order and to perform the blocking operation on the target network protocol address.

[0223] In some optional embodiments, the data fields of the log data include: timestamp, client address, request method, request URI, HTTP status code, user agent, referencing page, and transfer volume;

[0224] The data fields of intelligence record data include: unique intelligence identifier, target IP or CIDR network segment, entry person identifier, entry time, source description, and risk summary text.

[0225] In some alternative embodiments, the sliding time window has a time window length of 2 hours.

[0226] In some alternative embodiments, the task triggering module 801 is configured to determine that a risk identification trigger event has been received upon receiving a triggering instruction generated based on a user operation.

[0227] In some optional embodiments, the task triggering module 801 is used to perform aggregated statistical analysis on log data within a preset time window according to a configured set time period, obtain statistical analysis results, and determine whether a risk identification trigger event has been received if the statistical analysis results indicate whether there are abnormal statistical analysis results.

[0228] In some optional embodiments, the task triggering module 801 is further configured to determine that a risk identification triggering event has been received if it is determined based on the statistical analysis results that there are more than two abnormal statistical analysis results.

[0229] In some optional embodiments, the results of anomaly statistical analysis include anomalies in access volume, response errors, and resource access patterns.

[0230] The task triggering module 801 is used to determine an abnormal access volume when the total number of requests to a single network protocol address within a sliding time window exceeds a preset request number threshold; to determine a response error anomaly when the number of client-side erroneous requests exceeds a first threshold, or the number of server-side erroneous requests exceeds a second threshold, or the ratio of the number of client-side erroneous requests to the number of server-side erroneous requests is greater than a preset ratio; and to determine a resource access mode anomaly when the number of unique URIs exceeds a preset threshold, the number of times sensitive path prefixes are hit exceeds a preset threshold, or the proportion of large response downloads exceeds a preset proportion threshold.

[0231] In some optional embodiments, the risk identification and analysis task includes: target network protocol address, trigger source type identifier, log-side reference information, and intelligence-side reference information;

[0232] Among them, the trigger source type identifier includes manual trigger, log rule trigger, or review and rerun trigger;

[0233] The log-side reference information includes access feature digests and searchable indexes. The access feature digests include request volume, status code distribution information, URI distribution digests, and the top N most accessed paths. The searchable indexes include query statements and log entry sampling identifiers.

[0234] The information referenced by the intelligence side includes: the identifier and summary fields of the intelligence record.

[0235] In some optional embodiments, the task triggering module 801 is used to perform deduplication and merging processing on the risk identification and analysis task based on a preset deduplication and merging rule.

[0236] The deduplication and merging rules include: merging risk identification and analysis tasks triggered multiple times for the same network protocol address within a preset time period into a single risk identification and analysis task; if the network protocol address in the risk identification and analysis task already has a task in the process of risk identification and analysis, or if there is an incomplete blocking candidate work order, temporarily suspending the triggering of the risk identification and analysis task or only logging the risk identification and analysis task; if the risk identification and analysis task is manually triggered, setting the priority of the risk identification and analysis task to the highest.

[0237] In some optional embodiments, the multi-agent judgment module 802 is used to perform multiple retries under the control of the management agent when the planning agent fails to decompose the risk identification and analysis task into multiple sub-tasks. If the number of retries exceeds the maximum number of retries, the execution process of the risk analysis and identification task is terminated and the reason for failure is recorded.

[0238] In some optional embodiments, the multi-agent judgment module 802 is used to write each sub-task of a single objective into the planning memory and dispatch it to the execution agent corresponding to the sub-task through the management agent agent, and write the execution result of the execution agent into the dialogue memory, and generate a structured judgment report based on the complete dialogue history in the dialogue memory through the reporting agent agent.

[0239] Each module in the aforementioned network protocol address risk identification and processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of the computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0240] In one exemplary embodiment, such as Figure 9 As shown, a network protocol address risk identification and processing system is provided, including: a task triggering module 901, a multi-agent device 902, a verification module 903, and an confirmation processing module 904, wherein:

[0241] The task triggering module 901 is used to respond to the risk identification triggering event, obtain the target network protocol address and the time-series correlated multi-source dataset within the sliding time window. The multi-source dataset includes log data and recorded intelligence record data within the sliding time window, and generates a risk identification analysis task based on the target network protocol address and the multi-source dataset.

[0242] The multi-agent device 902 includes a management agent, a planning agent, one or more execution agents, and a reporting agent. The management agent acquires risk identification and analysis tasks, drives risk identification processing for these tasks, sends the risk identification and analysis tasks to the planning agent, and distributes one or more sub-tasks generated by the planning agent to the corresponding execution agents. The planning agent decomposes the risk identification and analysis tasks into multiple sub-tasks. The execution agents execute the corresponding sub-tasks and obtain the execution results of each sub-task. The reporting agent generates a structured analysis report based on the execution results of each sub-task obtained by one or more execution agents.

[0243] The verification module 903 is used to verify the structured analysis report output by the report agent through the rule engine, and generate a blocking candidate work order if the verification result shows that the target network protocol address is a blocking candidate.

[0244] The confirmation processing module 904 is used to respond to the confirmation command of the operation and maintenance personnel for the blocking candidate work order and to perform the blocking operation on the target network protocol address.

[0245] Each module in the aforementioned network protocol address risk identification and processing system can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module. The implementation method of the relevant modules in the aforementioned network protocol address risk identification and processing system can be the same as the implementation method in the aforementioned network protocol address risk identification and processing device.

[0246] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 10As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When executed by the processor, the computer program implements a method for risk identification and handling of network protocol addresses.

[0247] Those skilled in the art will understand that Figure 10 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0248] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the methods in the above embodiments.

[0249] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the methods described in the above embodiments.

[0250] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the methods described in the above embodiments.

[0251] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0252] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0253] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for risk identification and handling of network protocol addresses, characterized in that, The method includes: In response to a risk identification trigger event, the system acquires the target network protocol address and a multi-source dataset with time-series correlation within a sliding time window. The multi-source dataset includes log data and recorded intelligence record data within the sliding time window. A risk identification analysis task is then generated based on the target network protocol address and the multi-source dataset. The risk identification and analysis task is obtained through the management agent, the risk identification processing of the risk identification and analysis task is driven, and the risk identification and analysis task is sent to the planning agent. The planning agent decomposes the risk identification and analysis task into multiple sub-tasks, determines the execution agent for each sub-task, and distributes each sub-task to the corresponding execution agent through the management agent. One or more execution agent intelligent agents execute the corresponding sub-tasks respectively, and obtain the sub-task execution results of each sub-task respectively; A structured analysis report is generated by the reporting agent based on the execution results of each subtask obtained by one or more of the execution agents. The structured analysis report output by the report agent is verified by the rule engine, and a blocking candidate work order is generated if the verification result shows that the target network protocol address is a blocking candidate. In response to the confirmation instruction from the operations and maintenance personnel for the blocking candidate work order, a blocking operation is performed on the target network protocol address.

2. The method according to claim 1, characterized in that, The method includes: Upon receiving a trigger command generated based on user operation, it is determined that a risk identification trigger event has been received; or; According to the configured set time period, the log data within the preset time window is aggregated and statistically analyzed to obtain the statistical analysis results. If it is determined whether there are abnormal statistical analysis results based on the statistical analysis results, a risk identification trigger event is received.

3. The method according to claim 2, characterized in that, The abnormal statistical analysis results include abnormal access volume, abnormal response errors, and abnormal resource access patterns; Among them, if the total number of requests for a single network protocol address within the sliding time window exceeds the preset request number threshold, it is determined that there is an abnormal access volume. If the number of erroneous requests from the client exceeds the first threshold, or the number of erroneous requests from the server exceeds the second threshold, or the ratio of the number of erroneous requests from the client to the number of erroneous requests from the server is greater than a preset ratio, then a response error is determined to exist. If the number of unique URIs exceeds a preset threshold, the number of times sensitive path prefixes are hit exceeds a preset threshold, or the proportion of large response downloads exceeds a preset proportion threshold, then an abnormal resource access pattern is identified.

4. The method according to any one of claims 1 to 3, characterized in that, The risk identification and analysis task includes: target network protocol address, trigger source type identifier, log-side reference information, and intelligence-side reference information; The trigger source type identifier includes manual triggering, log rule triggering, or review rerun triggering; The log-side reference information includes an access feature digest and a searchable index. The access feature digest includes the number of requests, status code distribution information, URI distribution digest, and the top N paths with the most accesses. The searchable index includes the query statement and log entry sampling identifier. The intelligence-related reference information includes: the identifier and summary fields of the intelligence record.

5. The method according to any one of claims 1 to 3, characterized in that, The method further includes: Based on the preset deduplication and merging rules, the risk identification and analysis task is deduplicated and merged. The deduplication and merging rules include: merging risk identification and analysis tasks triggered multiple times for the same network protocol address within a preset time period into a single risk identification and analysis task; if the network protocol address in the risk identification and analysis task already has a task in the process of risk identification and analysis, or if there is an incomplete blocking candidate work order, temporarily suspending the triggering of the risk identification and analysis task or only recording the log of the risk identification and analysis task; if the risk identification and analysis task is a manually triggered task, setting the priority of the risk identification and analysis task to the highest.

6. The method according to any one of claims 1 to 3, characterized in that, The method further includes: The management agent writes each sub-task of a single objective into the planning memory and dispatches it to the execution agent corresponding to the sub-task. The execution result of the execution agent is written into the dialogue memory. The reporting agent generates the structured analysis report based on the complete dialogue history in the dialogue memory.

7. A device for risk identification and processing of network protocol addresses, characterized in that, The device includes: The task triggering module is used to respond to a risk identification triggering event, obtain the target network protocol address and the time-series correlated multi-source dataset within a sliding time window, the multi-source dataset including log data and recorded intelligence record data within the sliding time window, and generate a risk identification analysis task based on the target network protocol address and the multi-source dataset. A multi-agent judgment module is used to obtain the risk identification and analysis task through a management agent, drive the risk identification processing of the risk identification and analysis task, and send the risk identification and analysis task to a planning agent; the planning agent decomposes the risk identification and analysis task into multiple sub-tasks, determines the execution agent for each sub-task, and distributes each sub-task to the corresponding execution agent through the management agent; one or more execution agents execute the corresponding sub-tasks respectively, and obtain the sub-task execution results for each sub-task; and a reporting agent generates a structured judgment report based on the sub-task execution results obtained by one or more execution agents. The verification module is used to verify the structured analysis report output by the report agent through the rule engine, and generate a blocking candidate work order if the verification result shows that the target network protocol address is a blocking candidate. The confirmation processing module is used to respond to the confirmation instruction from the operation and maintenance personnel for the blocking candidate work order and to perform a blocking operation on the target network protocol address.

8. A network protocol address risk identification and processing system, characterized in that, The system includes: The task triggering module is used to respond to a risk identification triggering event, obtain the target network protocol address and the time-series correlated multi-source dataset within a sliding time window, the multi-source dataset including log data and recorded intelligence record data within the sliding time window, and generate a risk identification analysis task based on the target network protocol address and the multi-source dataset. A multi-agent device includes a management agent, a planning agent, one or more execution agents, and a reporting agent. The management agent acquires a risk identification and analysis task, drives risk identification processing for the task, sends the task to the planning agent, and distributes one or more sub-tasks generated by the planning agent to the corresponding execution agents. The planning agent decomposes the risk identification and analysis task into multiple sub-tasks. The execution agents execute the corresponding sub-tasks and obtain the execution results of each sub-task. The reporting agent generates a structured analysis report based on the execution results of each sub-task obtained by one or more execution agents. The verification module is used to verify the structured analysis report output by the report agent through the rule engine, and generate a blocking candidate work order if the verification result shows that the target network protocol address is a blocking candidate. The confirmation processing module is used to respond to the confirmation instruction from the operation and maintenance personnel for the blocking candidate work order and to perform a blocking operation on the target network protocol address.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images