Knowledge graph-based network threat intelligence automatic correlation analysis method and system

Abstract

The application provides a kind of network threat intelligence automatic association analysis method and system based on knowledge graph, belongs to data processing technical field, specifically includes: multi-source heterogeneous data fusion module maps original intelligence data into standardized triple data, dynamic graph construction module receives standardized triple data, constructs and continuously updates threat knowledge graph;Correlation reasoning engine is executed on the threat knowledge graph for automatic association reasoning, blocking processing module, and according to the reasoning result and the knowledge graph of the user's identification processing, the blocking processing of user access is carried out, and the network security is improved.

Description

Technical Field

[0001] This invention belongs to the field of data processing technology, and in particular relates to an automated correlation analysis method and system for network threat intelligence based on knowledge graphs. Background Technology

[0002] To identify and handle abnormal access and attack behaviors, an increasing number of enterprises are configuring systems for this purpose. Specifically, these systems analyze user access behavior and generate corresponding network security control policies based on the analysis results. However, they have the following drawbacks: 1. Existing technical solutions fail to utilize multiple network threat intelligence sources for updating and reasoning about threat knowledge graphs, making it difficult to accurately and reliably identify abnormal access and attack behaviors in real time.

[0003] 2. Simply relying on the updated inference results of threat knowledge graphs to identify and block abnormal access and attack behaviors may result in the blocking of access for some normal users. Therefore, determining how to identify users whose knowledge graphs are updated based on their own access behaviors, and determining the management method for deploying blocking modules based on the updated knowledge graph results for different users, in order to ensure network security while minimizing the impact on user access behavior, has become an urgent technical problem to be solved.

[0004] Therefore, there is an urgent need for an automated correlation analysis method and system for network threat intelligence based on knowledge graphs. Summary of the Invention

[0005] To achieve the objectives of this invention, the following technical solution is adopted: Specifically, this application provides an automated correlation analysis system for network threat intelligence based on knowledge graphs, which includes: The multi-source heterogeneous data fusion module is configured to obtain raw intelligence data from multiple public or private network threat intelligence sources and map the raw intelligence data into standardized triplet data. The dynamic graph construction module is connected to the multi-source heterogeneous data fusion module and is configured to receive the standardized triplet data, construct and continuously update the threat knowledge graph. An association reasoning engine, connected to the dynamic graph construction module, is configured to perform automated association reasoning on the threat knowledge graph; The blocking processing module blocks user access based on the reasoning results and the knowledge graph of the identified users. It determines the deployment strategy of the blocking processing module by utilizing the updated processing results of the identified users and the knowledge graphs of different identified users. It also determines the deployment management method of the blocking processing module based on the update status of the identified users in the blocked users during the usage period and the correlation of changes in access traffic in different time periods.

[0006] Furthermore, the raw intelligence data includes at least structured threat intelligence, unstructured threat reports, and semi-structured logs.

[0007] Furthermore, the standardized triplet data follows a subject-predicate-object expression format.

[0008] Furthermore, the dynamic graph construction module supports an incremental update mechanism with timestamps and generates a version identifier for each update of the threat knowledge graph, forming time-aware graph version management.

[0009] Furthermore, based on the reasoning results and the knowledge graph of the identified user, user access is blocked, specifically including: Based on the reasoning results, users with access risks are identified, and when the access behavior of the users with access risks does not conform to their own knowledge graph, the access of the users with access risks is blocked.

[0010] Furthermore, if the access behavior of a user with access risk does not belong to the access IP address and access terminal of the user with access risk, then it is determined that the access behavior of the user with access risk does not conform to its own knowledge graph.

[0011] Secondly, this application provides a knowledge graph-based automated correlation analysis method for network threat intelligence, applied to the aforementioned knowledge graph-based automated correlation analysis system for network threat intelligence, specifically including: S1 determines the blocked user data of the enterprise in different time periods based on the blocked user data in different time periods, identifies the users of the enterprise who are being processed based on the blocked user data in different time periods, and determines the deployment strategy of the blocking processing module by using the updated processing results of the knowledge graph of the identified users and different identified users. S2 uses the deployment strategy to determine the usage period of the blocking processing module. Based on the usage period and the blocked user data in different usage periods, when it is determined that the deployment strategy can be optimized, proceed to the next step. S3 determines the management method for the blocking processing module based on the update status of the identified users during the usage period and the correlation of changes in access traffic in different time periods.

[0012] Furthermore, the blocked user data includes the number of blocked users in different time periods.

[0013] Furthermore, the method for determining the management mode of the blocking processing module is as follows: Based on the updated data of the identified users among the blocked users during the usage period, the proportion of the identified users among the blocked users is determined, and the proportion of the identified users among the blocked users is used as the proportion of updated users. Based on the changes in access traffic in different time periods, the dates on which the access traffic in the time period exceeds a preset multiple of the daily average access traffic are determined, and the dates on which the access traffic exceeds a preset multiple of the daily average access traffic are used as the dates on which the access traffic in the time period is required to be blocked. The deployment and management method of the blocking processing module is determined based on the updated user ratio and the correlation between the blocking usage demand dates in different time periods.

[0014] The beneficial effects of this invention are as follows: By acquiring raw intelligence data from multiple public or private network threat intelligence sources and continuously updating the threat knowledge graph based on the mapping of the raw intelligence data, the system achieves automatic extraction from multiple network threat intelligence sources and automatic updating of the threat knowledge graph, ensuring the reliability and accuracy of identifying dangerous behaviors.

[0015] Based on the user data identified and processed, as well as the updated knowledge graph of these users, the impact on users' normal access behavior when the blocking module is deployed is determined. Specifically, the more users identified and processed, and the more complete the knowledge graph update, the more effective the blocking module's blocking process will be. In this case, when the blocking module uses the knowledge graph's inference results for blocking, users will be filtered based on the knowledge graph, such as their access terminal or IP address, before being blocked. If a user belongs to an access terminal or IP address, no blocking is necessary, as the impact of the blocking module is relatively low. The deployment strategy for the blocking module is determined based on its impact level, ensuring the reliability of blocking abnormal access behavior while minimizing the impact on users' normal access behavior.

[0016] Based on the updated data of identified users among the blocked users and the correlation between the blocking usage requirement dates for different time periods, the deployment requirements of the blocking processing module are determined. The more identified users among the blocked users, the less impact the blocking processing module will have on normal user access, even if deployed. Furthermore, the higher the correlation between the blocking usage requirement dates for different time periods, the higher the correlation of abnormal fluctuations in access traffic during those time periods, and the higher the demand for deploying the blocking processing module. By utilizing the impact on normal user access and the correlation of abnormal fluctuations in access traffic across different time periods, the deployment management method for the blocking processing module is determined. This not only minimizes the impact on the normal access of different users but also further ensures the reliability and efficiency of the blocking processing module.

[0017] Other features and advantages will be set forth in the following description, and the objects and other advantages of the invention are realized and obtained through the structures particularly pointed out in the description and the drawings.

[0018] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0019] The above and other features and advantages of the present invention will become more apparent from a detailed description of exemplary embodiments thereof with reference to the accompanying drawings.

[0020] Figure 1 This is a framework diagram of a knowledge graph-based automated correlation analysis system for network threat intelligence. Figure 2 This is a flowchart of a knowledge graph-based automated correlation analysis method for network threat intelligence. Figure 3 This is a flowchart illustrating the method for identifying and processing users within a company's user base. Figure 4 This is a flowchart illustrating the method for determining the deployment strategy of the blocking processing module. Detailed Implementation

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

[0022] Example 1 like Figure 1 As shown, this application provides an automated correlation analysis system for network threat intelligence based on knowledge graphs, specifically including: The multi-source heterogeneous data fusion module is configured to obtain raw intelligence data from multiple public or private network threat intelligence sources and map the raw intelligence data into standardized triplet data. Specifically, the raw intelligence data refers to threat-related information from multiple public or private intelligence sources that has not yet undergone standardized format processing, including structured threat intelligence, unstructured threat reports, and semi-structured logs. Structured threat intelligence refers to intelligence data stored in a fixed field format, such as CVE vulnerability records and STIX format intelligence; unstructured threat reports refer to threat analysis reports and security bulletins existing in natural language text format; and semi-structured logs refer to system logs and access logs that have some fixed formats but whose fields are not entirely consistent.

[0023] Assuming an enterprise simultaneously accesses multiple threat intelligence sources, including public threat intelligence platforms and private internal security logs, the multi-source heterogeneous data fusion module collects raw data from each intelligence source, performs format parsing, field extraction, and semantic alignment processing on intelligence data of different formats, and maps all types of raw intelligence data into standardized triplet data that follow the subject-predicate-object expression form.

[0024] This module eliminates format differences in multi-source heterogeneous data through unified standardization processing. Its significance lies in providing consistent and semantically standardized basic data for subsequent knowledge graph construction, ensuring that threat information from different intelligence sources can be correlated and analyzed within the same knowledge graph framework, thereby improving the integrity and reliability of threat intelligence fusion.

[0025] Suppose that the enterprise accesses 6 threat intelligence sources, including 3 public intelligence sources (threat intelligence platform A, CVE database B, security bulletin C) and 3 private intelligence sources (enterprise firewall logs D, endpoint detection logs E, internal security report F).

[0026] The multi-source heterogeneous data fusion module collects raw intelligence data from six intelligence sources: 240 STIX-formatted structured intelligences from threat intelligence platform A, 180 vulnerability records from CVE database B, 120 unstructured threat report texts from security bulletins C, 8,000 semi-structured log data from enterprise firewall logs D, 5,000 semi-structured log data from endpoint detection logs E, and 60 unstructured reports from internal security reports F.

[0027] After performing format parsing and field extraction on the above data, all raw intelligence data is mapped into standardized triple data, following the subject-predicate-object expression format. For example, the CVE-2024-XXXX vulnerability record is mapped to the triple (vulnerability CVE-2024-XXXX, impact, component OpenSSL 3.0); abnormal access records in firewall logs are mapped to the triple (IP address 192.168.XX, initiator, abnormal port scanning behavior). After fusion processing, a total of 12,600 standardized triple data entries are generated and output to the dynamic graph construction module.

[0028] The dynamic graph construction module is connected to the multi-source heterogeneous data fusion module and is configured to receive the standardized triplet data, construct and continuously update the threat knowledge graph. The threat knowledge graph refers to a graph-structured data model where nodes represent threat entities (such as IP addresses, vulnerabilities, malware, attackers, etc.) and directed edges represent threat relationships between entities. It is used to systematically express the entity relationship network in network threat intelligence. The timestamped incremental update mechanism refers to attaching timestamp information to each newly added or updated triplet data, incrementally integrating new data into the existing graph, rather than reconstructing the entire graph. The version identifier refers to a unique marker generated for each graph update operation, used to distinguish graph versions at different times, forming a time-aware graph version management system.

[0029] Assuming the multi-source heterogeneous data fusion module continuously outputs standardized triplet data, the dynamic graph construction module performs incremental processing on newly received triplet data: it adds graph nodes to new entities and updates graph edges of existing entities. Each update operation is accompanied by a timestamp and a version identifier is generated, thereby maintaining the historical version sequence of the graph.

[0030] This module enables the continuous and dynamic evolution of the threat knowledge graph through a timestamped incremental update and version management mechanism. Its significance lies in enabling the graph to reflect the latest threat situation in real time, while retaining historical states through version management, supporting retrospective analysis of threat evolution trends, thereby providing a timely and historically complete graph data foundation for the correlation inference engine.

[0031] The dynamic graph construction module receives 12,600 standardized triplet data from the multi-source heterogeneous data fusion module and performs graph construction processing.

[0032] In the initial construction phase, 3,800 entity nodes (including 1,200 IP address nodes, 680 vulnerability nodes, 420 malware nodes, 300 attacker nodes, and 1,200 other threat entity nodes) were extracted from 12,600 triple data entries, and 8,200 relationship edges were extracted to construct an initial version of the threat knowledge graph (version identifier V20260423-001, timestamp 2026-04-23T00:00).

[0033] During the incremental update phase, new triplet data is received every hour. Taking the first update as an example, 380 new triplet data entries are received, including 120 new entity nodes and 260 new relation edges. The dynamic graph construction module performs graph node addition operations on the 120 new entity nodes and graph edge addition operations on the 260 new relation edges. Each update record is appended with a timestamp (2026-04-23T01:00). This update generates version identifier V20260423-002.

[0034] The updated graph contains 3,920 entity nodes and 8,460 relation edges. The version management record has accumulated two versions, and it supports historical state backtracking between V20260423-001 and V20260423-002, which is then output to the association reasoning engine.

[0035] An association reasoning engine, connected to the dynamic graph construction module, is configured to perform automated association reasoning on the threat knowledge graph; The aforementioned association reasoning refers to the process of automatically discovering implicit threat relationships and inferring potential threat risks based on known entity relationships in a threat knowledge graph, through graph traversal, path analysis, and association rule matching. The aforementioned automated association reasoning refers to a reasoning processing method in which the system automatically completes the matching of reasoning rules and the generation of reasoning conclusions without human intervention.

[0036] Assuming that the threat knowledge graph has recorded that an IP address has a communication relationship with known malware, the association reasoning engine discovers through graph path analysis that the IP address is also associated with jump nodes in multiple historical attack events. Then, it automatically infers that the IP address has a high access risk, generates the corresponding reasoning result, and outputs it to the blocking processing module.

[0037] This module enables the proactive discovery of hidden threat relationships by performing automated correlation reasoning on the threat knowledge graph. Its significance lies in integrating scattered threat intelligence fragments into a systematic basis for threat judgment through graph correlation, thereby significantly improving the depth and accuracy of threat identification and providing reliable reasoning support for subsequent blocking processing.

[0038] The association reasoning engine receives the threat knowledge graph (current version V20260423-002, containing 3920 entity nodes and 8460 relationship edges) output by the dynamic graph construction module and performs automated association reasoning processing.

[0039] The correlation inference engine performs inference processing on all 1200 IP address nodes in the graph. Taking a certain batch of inference as an example, multi-hop path analysis is performed on the IP address nodes in the graph, identifying 86 IP address nodes directly associated with known malware communication records, 142 IP address nodes associated with historical attack event jump nodes within two hops, and 65 IP address nodes associated with high-risk vulnerability exploitation behavior. After deduplication and merging, a total of 218 IP address nodes with access risks are inferred, generating 218 inference results. Each inference result includes information such as the risky IP address, risk type, associated path length, and association confidence level, which are output to the blocking processing module as the basis for user access blocking processing.

[0040] The blocking processing module blocks user access based on the reasoning results and the knowledge graph of the identified users. It determines the deployment strategy of the blocking processing module by utilizing the updated processing results of the identified users and the knowledge graphs of different identified users. It also determines the deployment management method of the blocking processing module based on the update status of the identified users in the blocked users during the usage period and the correlation of changes in access traffic in different time periods.

[0041] The knowledge graph for user identification and processing refers to a graph data structure that records the historical access IP addresses and access terminals of users whose average daily access duration and access frequency meet the screening criteria. This data is used to distinguish between normal and abnormal access behavior of identified and processed users. The blocking process refers to the operation of rejecting the access requests of users whose access behavior is determined to pose an access risk by inference results, when their access behavior does not conform to the knowledge graph (i.e., the access behavior does not fall within the range of their historical access IP addresses and access terminals). The deployment strategy refers to a strategy scheme that determines the time periods for deploying the blocking module based on the proportion of identified and processed users and the matching factors constructed from their knowledge graph. The deployment management method refers to the management rules that dynamically adjust the conditions for the full deployment of the blocking module based on the correlation between the updated user proportion and changes in access traffic.

[0042] Suppose the association reasoning engine infers that a user's access IP address poses an access risk. The blocking module first queries the user's knowledge graph. If the IP address and access terminal used for the current access both belong to historical access IP addresses and access terminals recorded in the user's knowledge graph, then the user's current access behavior is determined to be consistent with its own knowledge graph, and no blocking is performed. If the IP address or access terminal used for the current access does not belong to the records in the user's knowledge graph, then the access behavior is determined to be inconsistent with its own knowledge graph, and blocking is performed.

[0043] This module performs blocking by combining the inference results with the user knowledge graph of the identified user. Its significance lies in ensuring reliable blocking of abnormal access behavior while effectively reducing the false blocking rate of users identified by the constructed knowledge graph, thereby achieving a synergistic improvement in the accuracy of network threat blocking and the reliability of normal access protection.

[0044] The blocking processing module receives the inference results (access risk user records corresponding to 218 risky IP address nodes) output by the correlation inference engine, combines them with the user knowledge graph data (120 identified users, each of whom has recorded historical access IP addresses and access terminal information in their knowledge graph), and performs blocking processing.

[0045] During the current usage period T2, there were 1800 users accessing the site, of whom 90 were identified as having access risks based on inference results. The blocking module performed knowledge graph matching on each of the 90 risky users: 22 of them were identified users, and knowledge graph comparison was performed on these 22 users—18 of them had their current access IP address and access terminal both listed in their knowledge graph's historical records, so their access behavior was determined to match their own knowledge graph, and no blocking was performed; 4 of them had their current access IP address not listed in their knowledge graph's historical records, so their access behavior was determined to not match their own knowledge graph, and blocking was performed. The remaining 68 non-identified users were directly blocked.

[0046] Results of blocking during T2: A total of 72 users were blocked (4 users who were identified and processed + 68 users who were not identified and processed). The percentage of blocked users = 72 ÷ 1800 = 0.04. The percentage of blocked users who were identified and processed = 4 ÷ 72 ≈ 0.056.

[0047] Furthermore, the raw intelligence data includes at least structured threat intelligence, unstructured threat reports, and semi-structured logs.

[0048] Furthermore, the standardized triplet data follows a subject-predicate-object expression format.

[0049] Furthermore, the dynamic graph construction module supports an incremental update mechanism with timestamps and generates a version identifier for each update of the threat knowledge graph, forming time-aware graph version management.

[0050] Furthermore, based on the reasoning results and the knowledge graph of the identified user, user access is blocked, specifically including: Based on the reasoning results, users with access risks are identified, and when the access behavior of the users with access risks does not conform to their own knowledge graph, the access of the users with access risks is blocked.

[0051] Furthermore, if the access behavior of a user with access risk does not belong to the access IP address and access terminal of the user with access risk, then it is determined that the access behavior of the user with access risk does not conform to its own knowledge graph.

[0052] Example 2 Secondly, such as Figure 2 As shown, this application provides a knowledge graph-based automated correlation analysis method for network threat intelligence, applied to the aforementioned knowledge graph-based automated correlation analysis system for network threat intelligence, specifically including: The core objective of this embodiment is to analyze enterprise user blocking data to identify and process users and the construction status of their knowledge graphs. Based on the deployment strategy and usage time data of the blocking processing module, it determines the optimization conditions for the deployment strategy. Furthermore, based on the update status of identified and processed users among the blocked users and the correlation of access traffic changes in different time periods, it determines the deployment management method of the blocking processing module. Its core logic is to first identify the time periods with high blocking impact, determine the identified and processed users for whom a knowledge graph needs to be built, then dynamically determine the deployment strategy of the blocking processing module based on the proportion of identified and processed users and the matching degree of knowledge graph construction. After fully verifying the optimizability of the strategy, it further combines the correlation of abnormal access traffic fluctuations to determine the final deployment management method, thereby achieving a balance between ensuring the reliability of abnormal access blocking and reducing interference with normal access. The overall logic follows the process of "blocked user proportion analysis → identification and processing user determination → deployment strategy determination → optimization condition verification → deployment management method determination".

[0053] S1 determines the blocked user data of the enterprise in different time periods based on the blocked user data in different time periods, identifies the users of the enterprise who are being processed based on the blocked user data in different time periods, and determines the deployment strategy of the blocking processing module by using the updated processing results of the knowledge graph of the identified users and different identified users. Furthermore, the blocked user data includes the number of blocked users in different time periods.

[0054] Specifically, such as Figure 3 As shown, the method for determining users in the enterprise's user identification processing is as follows: In this embodiment, the impact of the blocking processing module on users' normal access behavior is determined based on the proportion of blocked users in different time periods. That is, the higher the proportion of blocked users, the more severe the blocking impact. Based on the blocking impact, the construction of the knowledge graph of users who need to perform their own access behavior is determined, which also lays the foundation for further reducing the impact of the blocking processing module on users' normal access behavior.

[0055] S11 uses blocked user data at different times to determine the proportion of blocked users at different times; The blocked user data refers to the recorded data generated by the blocking processing module when performing access blocking operations on enterprise users at different time periods, including information such as the number of blocked users and the blocking time. The blocked user ratio refers to the proportion of the number of blocked users to the total number of users accessing the platform during a specific time period.

[0056] If a company has users blocked during multiple time periods on a certain day, and the total number of users accessing the platform varies in each time period, then the number of blocked users in each time period is calculated and divided by the total number of users accessing the platform in that time period to obtain the proportion of blocked users in each time period.

[0057] This step quantifies the coverage of blocking behavior in different time periods, providing a data foundation for subsequent identification of abnormal periods of blocking impact. Its significance lies in establishing a time period distribution index system for blocking impact, thereby providing raw data support for the accurate identification and handling of users.

[0058] S12 uses the proportion of blocked users in the time period as the proportion of blocked users in the time period; The blocked user ratio refers to the proportion of users calculated in S11 that represents the degree of blocking impact during a specific period. It is the core metric for subsequent judgment on whether the blocking impact exceeds the standard.

[0059] If the number of blocked users in a certain period accounts for a certain percentage of the total number of users accessing the site in that period, then that percentage is directly used as the percentage of blocked users in that period, and is used for subsequent comparison and judgment with the percentage of blocked users threshold.

[0060] This step transforms the degree of blockade coverage in each time period into standardized indicators that can be directly compared through unified naming and formatting. Its significance lies in standardizing the assessment criteria for the degree of blockade impact in subsequent judgment processes and ensuring the consistency of indicator definitions.

[0061] S13 determines the users to be identified and processed based on the proportion of blocked users in different time periods.

[0062] Furthermore, if the proportion of blocked users in different time periods is not greater than the blocking user proportion threshold, then there is no need to identify and process users and to put them into the blocking processing module in real time.

[0063] The user blocking ratio threshold refers to a critical ratio value set based on the enterprise's tolerance for interference with normal access, used to determine whether the impact of blocking is significant.

[0064] Assuming the enterprise sets a fixed threshold for the proportion of blocked users, if the proportion of blocked users does not exceed this threshold in all time periods, then the impact of the blocking processing module on normal access behavior is determined to be within an acceptable range. Therefore, there is no need to build a knowledge graph for identifying and processing users, and the blocking processing module can be directly deployed in real time.

[0065] This step handles situations where the impact of blocking is within the normal range for all time periods. Its significance lies in avoiding unnecessary identification and processing of user building work when the overall impact of blocking is low, thereby simplifying the process and improving processing efficiency.

[0066] Additionally, it is understandable that if there is a period in which the proportion of blocked users is greater than the threshold for the proportion of blocked users, the following steps are taken: determine whether the proportion of blocked users in different periods is greater than the threshold for the proportion of blocked users. If so, determine that the users identified and processed are those whose average daily access time is greater than the preset time threshold. If not, determine that the users identified and processed are those whose average daily access time is greater than the preset time threshold and who have access behavior on different dates.

[0067] The preset duration threshold refers to the daily average access duration threshold set based on user access activity levels, used to filter high-frequency users. The identified and processed users refer to the high-frequency user group that meets the screening criteria and for whom an access behavior knowledge graph needs to be constructed.

[0068] If the proportion of blocked users exceeds the threshold during certain time periods, and if the threshold is exceeded in all time periods, then only the average daily access time exceeding the threshold will be used as the screening criterion for identifying and processing users; if the threshold is exceeded only in certain time periods, then in addition to the average daily access time exceeding the threshold, users will also be required to have access behavior on different dates in order to further screen stable and high-frequency users.

[0069] This step determines the scope of users to be identified and processed based on the differences in the time period when the blocking impact exceeds the standard. Its significance is that when the blocking impact exceeds the standard across the board, it covers all users with high duration to minimize the risk of false blocking; when only some time periods exceed the standard, it narrows the scope of users to be identified and processed to the most stable high-frequency users, thereby achieving a balance between the protection scope and the construction cost.

[0070] This embodiment, through the execution of steps S11 to S13, achieves a systematic quantitative analysis of the blocking behavior of enterprises at different time periods, and determines the scope of users to be identified and processed by constructing a knowledge graph. The core value is reflected in two aspects: First, by calculating the proportion of blocked users in different time periods, it accurately identifies the time periods with higher blocking impact, providing data support for the screening of users to be identified and processed; Second, through multi-level judgment logic, it realizes the flexibility and adaptability of the selection of the scope of users to be identified and processed, ensuring that a reasonable scope of user protection can be determined under different blocking distribution conditions.

[0071] Suppose a company divides a day into 8 time periods (T1 to T8), blocks a user ratio threshold of 0.05 (i.e. 5%), and sets a preset duration threshold of 2 hours / day.

[0072] In S11 to S12, the percentage of users blocked in each time period is as follows: T1 is 0.03, T2 is 0.07, T3 is 0.09, T4 is 0.04, T5 is 0.06, T6 is 0.02, T7 is 0.08, and T8 is 0.03.

[0073] In S13, since the proportion of blocked users was greater than 0.05 in four time periods—T2 (0.07), T3 (0.09), T5 (0.06), and T7 (0.08)—there were periods exceeding the limit, so it was necessary to identify and process the users. Since not all time periods exceeded the limit, the process proceeded to the "No" branch: Users identified for processing were defined as those with an average daily access time of more than 2 hours and who exhibited access behavior on different dates. After screening, 120 users from this company met the criteria and were identified as users to be processed.

[0074] It is understood that the update processing result of the knowledge graph of the identified user includes the access IP address and access terminal of the identified user.

[0075] Specifically, such as Figure 4 As shown, the method for determining the deployment strategy of the blocking processing module is as follows: In this embodiment, based on the user data and the update results of the knowledge graph of the identified users, the impact on the normal access behavior of users once the blocking processing module is put into use is determined. That is, the more users are identified and the more complete the update of the knowledge graph of the identified users is, the more likely the blocking processing module will block the users when it uses the reasoning results of the knowledge graph. The identified users are filtered based on the knowledge graph, such as the access terminal or access IP address, before the blocking processing is performed. Once the user belongs to the access terminal or access IP address, there is no need for blocking processing. At this time, the impact of the blocking processing module is low. The strategy for putting the blocking processing module into use is determined based on the impact of the blocking processing module. This ensures the reliability of blocking abnormal access behavior while reducing the impact on the normal access behavior of users.

[0076] S21 uses the identified user data to determine the proportion of identified users among the enterprise's users, and uses the proportion of identified users among the enterprise's users as the proportion of identified users. The user data being identified and processed refers to a comprehensive dataset containing information such as the number of users identified and processed, access duration, and access date. The user identification ratio refers to the proportion of the number of users identified and processed to the total number of enterprise users, used to characterize the coverage of the identified and processed users.

[0077] Assuming the total number of enterprise users is a certain number, and the users to be identified and processed are a portion of them, then the proportion of users to be identified and processed is the number of users to be identified and processed divided by the total number of enterprise users.

[0078] This step provides basic parameters for determining subsequent deployment strategies by quantifying the coverage of identified users. Its significance lies in evaluating the potential for knowledge graph construction to improve the blocking effect, thereby providing a basis for strategy selection.

[0079] It is understandable that if the proportion of identified users is less than the preset user proportion threshold, the blocking processing module will be activated during the period with the highest average daily access traffic.

[0080] The preset user ratio threshold refers to the critical ratio value used to determine whether the coverage of identified and processed users has reached the knowledge graph-assisted blocking trigger condition. The preset ratio refers to the proportional standard used to determine the range of time periods in which blocking processing is implemented.

[0081] If the proportion of identified users is lower than the preset user proportion threshold, it is determined that the effect of knowledge graph-assisted blocking is limited, and the blocking processing module is directly selected to deal with the period with the highest daily average access traffic.

[0082] This step directly determines the time period for intervention when the coverage of identified and processed users is insufficient. Its significance lies in the fact that when the number of identified and processed users is small, the impact of the auxiliary blocking processing based on the user's knowledge graph is limited. In this case, the high-traffic period is directly deployed to ensure effective coverage of the blocking processing during the most critical period.

[0083] It is also understood that if the number of identified users is not less than the preset user ratio threshold, then the process proceeds to step S22.

[0084] S22 determines the construction matching factor of the knowledge graph of the identification processing user based on the update processing results of the knowledge graph of different identification processing users; The update processing result of the knowledge graph refers to the recording and updating of access behavior characteristics such as the access IP address and access terminal of the identified users. The construction matching factor is a quantitative indicator used to measure the completeness of the knowledge graph construction, determined by multiplying the sum of the number of access IP addresses and access terminals of the identified users by a preset ratio factor.

[0085] Suppose that a certain user's current knowledge graph has recorded multiple access IP addresses and multiple access terminals. Multiply the sum of the two by a preset scaling factor to obtain the user's matching factor.

[0086] This step quantifies the completeness of each user knowledge graph used for identification and processing, providing a data foundation for judging the overall quality of the knowledge graph construction. Its significance lies in objectively reflecting the coverage of the user knowledge graph of identification and processing with the actual access behavior characteristics by constructing matching factors, thereby providing support for the scientific selection of deployment strategies.

[0087] Understandably, based on the matching factors for the construction of knowledge graphs of different identification and processing users, it is determined whether the average value of the matching factors for the construction of knowledge graphs of different identification and processing users is less than the preset matching factor threshold. If so, the blocking processing module is put into operation during the period with the highest daily average access traffic in a preset proportion. If not, the process proceeds to step S23.

[0088] The preset matching factor threshold refers to the critical average value used to determine whether the overall construction quality of the user knowledge graph reaches the standard for assisting in blocking applications.

[0089] If the average value of the matching factors constructed by each user in the identification and processing is lower than the preset matching factor threshold, it is determined that the overall construction quality of the knowledge graph is insufficient, and the blocking processing module is directly selected for several time periods with the highest daily access traffic; if the average value is not lower than the threshold, it is transferred to S23 for fine-grained strategy determination.

[0090] This step constructs a quality judgment strategy path based on the overall knowledge graph. Its significance lies in avoiding the risk of false blocking caused by using an incomplete knowledge graph to assist in blocking judgment when the overall quality of the knowledge graph does not meet the standards, thus ensuring the basic reliability of the blocking process.

[0091] S23 determines the deployment strategy of the blocking processing module based on the proportion of identified users and the construction matching factor of the knowledge graph of different identified users.

[0092] It should be noted that S231 determines whether there are any users whose matching factor is less than the preset matching factor threshold. If so, proceed to step S232. If not, the blocking processing module is activated during the period with the highest daily average access traffic and during the period when the number of users whose access traffic is higher than the target number of users.

[0093] The number of users for target identification and processing refers to the minimum number of users identified and processed within a certain period of time that meets the knowledge graph-assisted blocking trigger condition.

[0094] Assuming that the matching factor of all identified and processed users is not less than the preset matching factor threshold, it is determined that there are no low-quality knowledge graph users. The blocking processing module is deployed simultaneously during several periods of the highest daily access traffic and during periods when the number of daily identified and processed users reaches or exceeds the target number of identified and processed users.

[0095] This step determines a broad investment period when the overall knowledge graph construction quality is good. Its significance lies in the fact that when the knowledge graphs of all identification and processing users have been fully constructed, blocking processing can be simultaneously deployed during high-traffic periods and periods when identification and processing users are concentrated, so as to achieve comprehensive blocking coverage during critical periods.

[0096] Additionally, it should be noted that S232 determines the identification matching value based on the ratio of identified users and the average value of the matching factors for constructing the knowledge graph of different identified users. It then determines whether the identification matching value is greater than a preset matching threshold. If so, the blocking processing module is activated during the period with the highest average daily access traffic, which is within the preset ratio. If the ratio of blocked users among the users accessing the system on the specified date is less than the preset user ratio, the blocking processing module is activated during the period when the average number of identified users among the users accessing the system is greater than the target number of identified users. Otherwise, the blocking processing module is activated during the period with the highest average daily access traffic, which is within the preset ratio.

[0097] The identification matching value is constructed by using the identification user ratio and the average value of the matching factors built from the knowledge graph, and is used to evaluate the overall reliability of knowledge graph-assisted blocking. The user ratio preset value is a critical ratio value used to determine whether the blocking user ratio is within an acceptable range, thereby deciding whether to extend the investment period.

[0098] If the identified matching value is greater than the preset matching threshold, in addition to deploying the blocking processing module during certain periods of the highest daily average access traffic, if the proportion of blocked users among the users accessing the system on that day is less than the preset user proportion, then additional blocking processing modules will be deployed during periods when the daily average number of identified and processed users reaches or exceeds the target number of identified and processed users; if the identified matching value is not greater than the preset matching threshold, then it will only be deployed during certain periods of the highest daily average access traffic.

[0099] This step determines whether to extend the investment period by identifying matching values. Its significance lies in the fact that when the overall reliability of knowledge graph-assisted blocking is high and the impact of blocking on the same day is controllable, the investment period can be appropriately extended to further improve the coverage of blocking while ensuring the reliability of blocking.

[0100] This embodiment, through the execution of steps S21 to S23, achieves dynamic determination of the deployment strategy for the blocking processing module based on the identification and processing of user data and the quality of knowledge graph construction. Its core value is reflected in three aspects: First, through multi-level judgment logic, it realizes the flexibility and adaptability of strategy selection; second, through the quantitative calculation of matching factors and identification matching values, it ensures the objectivity and scientific nature of strategy selection; and third, through the design of differentiated deployment time periods, it achieves an effective balance between the breadth of blocking processing coverage and the risk of interference with normal access.

[0101] Assume the total number of enterprise users is 2400, the number of users to be identified and processed is 120, the preset user ratio threshold is 0.04, the preset matching factor threshold is 3, the preset ratio is 20% (i.e., the top 20% of the daily average access traffic, for a total of 2 time periods), the target number of users to be identified and processed is 15, the preset user ratio is 0.03, the preset matching threshold is 0.30, and the preset ratio factor is 0.5.

[0102] In S21, the user identification ratio = 120 ÷ 2400 = 0.05. Since 0.05 ≥ 0.04, proceed to step S22.

[0103] In step S22, the matching factor for each identified user is calculated: the sum of the number of accessing IP addresses and the number of accessing terminals multiplied by 0.5. Assuming that out of 120 users, 105 have a matching factor ≥ 3, 15 have a matching factor < 3, and the average is 3.2 ≥ 3, proceed to step S23.

[0104] In step S231, there are 15 users whose matching factor is less than 3, so proceed to step S232.

[0105] In S232, the identification matching value = 0.05 × 3.2 = 0.16. Since 0.16 < 0.30 (preset matching threshold), it is determined that the identification matching value is not greater than the preset matching threshold, and the deployment strategy is determined to be: the blocking processing module is only deployed during the top 20% of the daily average access traffic periods (T2, T3).

[0106] S2 uses the deployment strategy to determine the usage period of the blocking processing module. Based on the usage period and the blocked user data in different usage periods, when it is determined that the deployment strategy can be optimized, proceed to the next step. Specifically, determining whether the aforementioned deployment strategy can be optimized includes: In this embodiment, the proportion of blocking duration on different dates is determined based on the usage time period. The comprehensiveness of the blocking processing module's usage is then determined based on this proportion; a higher proportion of blocking duration indicates greater comprehensiveness. Combined with blocked user data from different usage time periods, the impact of the blocking processing module on normal access behavior after update processing is determined; a higher proportion of blocked users indicates a greater impact. Using both comprehensiveness and impact, it is determined whether the deployment strategy can be optimized. If the comprehensiveness is high and the impact is low, optimization of the deployment strategy is possible, meaning that deploying more time periods will not severely impact overall access traffic. This lays the foundation for further improving the comprehensiveness of the blocking processing module's usage.

[0107] S31 determines the duration percentage of the blocking processing module's usage period on different dates based on the usage period, and uses the duration percentage of the blocking processing module's usage period on different dates as the blocking duration percentage. The usage period refers to the set of time periods during which the blocking processing module is actually used according to the usage strategy determined in S2. The blocking duration percentage refers to the proportion of the actual usage time of the blocking processing module to the total daily usage time on a specific date.

[0108] If a company divides a day into multiple time periods, and the blocking processing module is used in some of these time periods, then the percentage of blocking time on a given day is the total duration of the time periods in which the module is used divided by the total duration of the day.

[0109] This step quantifies the coverage of the blocking processing module's usage time, providing basic parameters for subsequent judgments on the comprehensiveness of its use. Its significance lies in assessing the time-period coverage of the existing deployment strategy, thereby providing a basis for decision-making regarding the optimization of processing conditions.

[0110] S32 determines the proportion of blocked users in different usage periods based on the blocked user data in different usage periods; The blocked user data refers to the number of blocked users and the total number of accessing users recorded during the actual period when the blocking processing module is in use. The blocked user ratio during the usage period refers to the proportion of blocked users to the total number of accessing users during a specific usage period, reflecting the degree of interference of the blocking processing on normal user access.

[0111] Assuming the blocking processing module generates blocking records in multiple usage periods, the number of blocked users in each usage period is calculated and divided by the total number of users accessing the platform in that period to obtain the blocking user ratio for each usage period.

[0112] This step quantifies the degree of interference of the blocking on normal access during the usage period, providing data for subsequent judgment on whether optimization can be carried out. Its significance lies in identifying the blocking situations with a greater impact during the usage period, thereby ensuring the accuracy of the assessment of the prerequisites for optimization.

[0113] S33 determines whether the strategy can be optimized based on the percentage of blocking duration and the percentage of blocked users in different usage periods.

[0114] It should be noted that S331 determines whether the average proportion of blocked users in different usage periods after the blocking processing module updates is greater than the preset blocking user proportion threshold. If so, it is determined that the optimization processing of the usage strategy cannot be carried out. If not, it proceeds to step S332.

[0115] The preset user blocking ratio threshold refers to the critical average ratio value used to determine whether the overall interference of the blocking processing module with normal access exceeds the standard.

[0116] If the average percentage of blocked users in each usage period exceeds the preset threshold for the percentage of blocked users, it is determined that the overall interference level of the blocking processing module is too high, and under the current conditions, there is no basis for further expansion of its use, and it is determined that optimization processing cannot be performed.

[0117] This step ensures that the optimization process is based on an overall assessment of the average blocked user ratio, and that the blocking interference is within an acceptable range. Its significance lies in avoiding hastily expanding the scope of use when the overall blocking interference is too high, thus preventing normal access from being further affected.

[0118] Additionally, it should be noted that S332 uses the usage period when the proportion of blocked users is greater than the preset threshold for the proportion of blocked users as the period of blocking impact. It determines whether the period of blocking impact exists on different dates. If not, it proceeds to step S333. If so, it is determined that the optimization process of the implementation strategy cannot be carried out.

[0119] The period of time during which the blocking effect occurs refers to the time period in which the proportion of blocked users exceeds a preset threshold.

[0120] If, in the records of past multiple dates, there are no periods of blocking influence on some dates, it is determined that the periods of blocking influence do not necessarily occur every day, and the process proceeds to S333 for further evaluation; if there are periods of blocking influence on every date, it is determined that the blocking interference is persistently significant and cannot be optimized.

[0121] This step assesses the persistence of the blocking interference by determining the date distribution of the blocking impact period. Its significance lies in distinguishing between occasional blocking impact and persistent blocking impact. Only when the blocking impact does not necessarily occur every day will the subsequent optimization condition verification proceed.

[0122] It also includes the following: S333 determines whether the proportion of blocking time on different dates is greater than the preset blocking time proportion threshold. If so, it determines that the strategy can be optimized and put into use. If not, it proceeds to the next step.

[0123] The preset blocking duration percentage threshold refers to a critical percentage value used to determine whether the current blocking processing module's usage duration coverage has reached a high level.

[0124] If the percentage of blocking time for each date exceeds the preset threshold, it is determined that the blocking processing module has a high coverage of usage time, the current strategy has good comprehensiveness, and the basic conditions for optimization are met. Therefore, optimization can be performed.

[0125] This step determines whether the coverage meets the standard by the percentage of blocking duration. Its significance is that when the time period coverage of the blocking processing module has reached a high level, it can be quickly determined that optimization processing can be carried out without the need for more complex comprehensive evaluation, thereby improving the efficiency of judgment.

[0126] S334 determines the matching coefficient for the deployment of the blocking processing module based on the proportion of blocking duration on different dates and the proportion of blocking impact periods on different dates. It then determines whether the matching coefficient for the deployment of the blocking processing module is greater than a preset matching coefficient threshold. If so, it is determined that the deployment strategy can be optimized; otherwise, it is determined that the deployment strategy cannot be optimized.

[0127] The percentage of periods affected by the blocking refers to the proportion of the number of periods affected by the blocking on a specific date to the total number of usage periods, reflecting the breadth of the blocking interference coverage on that date. The matching coefficient for deployment refers to a quantitative indicator that comprehensively reflects the relationship between the coverage of blocking duration and the percentage of periods affected by the blocking, and is used to evaluate the comprehensive conditions for optimization under the current usage situation.

[0128] The formula for calculating the matching coefficient is: Matching coefficient = Average percentage of blocking duration ÷ (1 + Average percentage of blocking impact period). Assuming the average percentage of blocking duration and the average percentage of blocking-affected time periods are both a certain value, the specific values ​​are substituted into the formula for calculation. If the result is greater than the preset matching coefficient threshold, it is determined that the comprehensive conditions meet the optimization requirements; otherwise, the conditions are deemed insufficient and optimization cannot be performed.

[0129] This step, through a comprehensive assessment of the comprehensiveness of the application and the distribution of interference, is significant because when the coverage during a given time period is insufficient but the interference is relatively concentrated, it allows for a comprehensive weighing of quantitative indicators to achieve an objective judgment on the feasibility of optimization, thereby achieving a precise balance between improving the comprehensiveness of the strategy and controlling interference.

[0130] This embodiment, through the execution of steps S31 to S34, achieves a systematic evaluation of the optimization conditions for the deployment strategy based on the proportion of blocking duration and the proportion of users blocked during the usage period. Its core value is reflected in two aspects: First, through multi-level progressive judgment logic, it ensures that optimization is only allowed when the blocking interference is controllable and the time period coverage has room for improvement, thus guaranteeing the robustness of the optimization decision; Second, through the comprehensive quantification of the deployment matching coefficient, it achieves an objective judgment of boundary situations, avoiding the one-sidedness of evaluation by a single indicator.

[0131] Assume the company has 8 time slots per day, with T2 and T3 currently in use (2 time slots in total). Each time slot lasts 3 hours, for a total of 24 hours per day. The preset thresholds for blocking user ratio are 0.05, blocking duration percentage are 0.40, and matching coefficient are 0.1.

[0132] In S31, the percentage of blocking time for each date = (3+3)÷24 = 0.25.

[0133] In S331, after the update process, T2 is 0.04, T3 is 0.06, the average value is 0.05, which is not greater than 0.05, so proceed to S332.

[0134] In S332, there exists a blocking period T3 (0.06 > 0.05), but not all dates have a blocking period (assuming that there are no blocking periods on 2 out of the last 5 days), so proceed to S333.

[0135] In S333, the blocking duration percentage is 0.25 < 0.40, which is not greater than the preset blocking duration percentage threshold, so proceed to S334.

[0136] In S334, the percentage of time periods affected by blocking is 1 ÷ 2 = 0.50 (one of the two usage periods is affected by blocking). The matching coefficient for deployment is 0.25 ÷ (1 + 0.50) = 0.25 ÷ 1.50 = 0.167. Since 0.167 is greater than 0.1, it is determined that the deployment strategy can be optimized.

[0137] S3 determines the management method for the blocking processing module based on the update status of the identified users during the usage period and the correlation of changes in access traffic in different time periods.

[0138] Specifically, the method for determining the management mode of the blocking processing module is as follows: In this embodiment, the deployment requirement of the blocking processing module is determined based on the updated data of the identified users among the blocked users and the correlation between the blocking usage requirement dates for different time periods. The more identified users among the blocked users, the less impact the blocking processing module will have on users' normal access, even if it is deployed. At the same time, the higher the correlation between the blocking usage requirement dates for different time periods, the higher the correlation between abnormal fluctuations in access traffic in different time periods, and the higher the demand for deploying the blocking processing module. By utilizing the degree of impact on users' normal access and the correlation between abnormal fluctuations in access traffic in different time periods, the deployment management method of the blocking processing module is determined. This not only minimizes the impact on the normal access of different users, but also further ensures the reliability and efficiency of the blocking processing module.

[0139] S41 uses the updated data of the identified users among the blocked users during the usage period to determine the proportion of the identified users among the blocked users, and uses the proportion of the identified users among the blocked users as the proportion of the updated users. The updated data for identified users refers to the records of instances where the blocking processing module mistakenly blocked users who had completed knowledge graph construction during the usage period. The updated user ratio refers to the proportion of blocked users who were identified users during the usage period, reflecting the impact of blocking processing on normal users who had already constructed the knowledge graph.

[0140] If the blocking module blocks multiple users during a certain usage period, and some of these users are identified and processed users, then the updated user percentage is the number of identified and processed users divided by the total number of blocked users during that period.

[0141] This step assesses the degree of interference of blocking processing on known legitimate users by quantifying the proportion of users identified and processed among the blocked users. The significance is that the lower the proportion of identified and processed users, the worse the effect of knowledge graph-assisted filtering and the higher the interference of blocking processing on normal access, thus providing a basis for determining the management method to be used.

[0142] It is understandable that if the proportion of updated users is less than the preset threshold for the proportion of updated users, then the number of users identified and processed among the blocked users is relatively small. Therefore, the management method for the use of the blocking processing module is determined to be the basic management method. That is, if the blocking processing module has not been used in the most recent preset time period, and there is a blocking usage requirement date in the most recent preset time period, then the blocking processing module will be used on the current date.

[0143] The preset update user percentage threshold refers to a critical percentage value used to determine whether the proportion of identified and processed users among blocked users reaches the threshold for triggering refined management. The basic management method refers to a standardized deployment decision-making method based on historically inactive periods and the date of blocking demand, adopted when identified and processed users are less affected. The preset time period refers to a time window used to statistically analyze historical usage. The date of blocking demand refers to a date when access traffic exceeds a preset multiple of the daily average access traffic.

[0144] If the percentage of users updating their accounts is lower than a preset threshold, the knowledge graph-assisted filtering is deemed ineffective, and a basic management approach is adopted. Under the basic management approach, if a period of time has not been used within the most recent preset time period, and there is a date within that period that would block usage requests, then the blocking processing module will be applied to that period on the current date.

[0145] This step employs a basic management approach when identifying and processing users with minimal interference. Its significance lies in determining whether to implement the system when the knowledge graph-assisted filtering is effective, based on simple historical gaps and demand conditions. This ensures coverage of critical demand periods while maintaining a simple and efficient management process.

[0146] It is also understood that if the percentage of updated users is not less than the preset threshold for the percentage of updated users, then proceed to step S42.

[0147] S42 determines the dates on which the access traffic during different time periods exceeds a preset multiple of the daily average access traffic based on the changes in access traffic during those time periods, and uses the dates on which the access traffic exceeds a preset multiple of the daily average access traffic as the dates on which the access traffic during those time periods is required to be blocked. The access traffic fluctuation refers to the actual access traffic records for different time periods on different dates. The date requiring blocking access refers to the date when the daily average access traffic exceeds a preset multiple within a specific time period, indicating that there is abnormal access activity on that date and during that time period, and there is a high demand for blocking access.

[0148] If the average daily access traffic for a certain period is a certain value, and the actual access traffic for that period on a certain day exceeds a preset multiple of the average daily access traffic (the preset multiple is above 1.1 and is determined according to the user settings), then that date will be designated as the date for blocking access during that period.

[0149] This step identifies dates with abnormally high access traffic and determines potential high-risk dates for each time period. Its significance lies in associating abnormal fluctuations in access traffic with blocking usage demands, thereby providing data support based on the actual risk distribution for determining subsequent usage management methods.

[0150] The above steps include the following: S421 Based on the data of blocked usage demand dates in the time period, determine the usage demand ratio of the time period by the proportion of the number of blocked usage demand dates in the most recent preset time period. The time period with the usage demand ratio greater than the preset demand ratio threshold is taken as the usage demand time period. Determine whether the proportion of the usage demand time period in the time period is greater than the preset time period proportion threshold. If so, determine that the usage management method of the blocking processing module is that as long as the proportion of blocked users in the previous date is below the first proportion threshold, all time periods in the current date are used. If not, proceed to step S422.

[0151] The "usage demand ratio" refers to the proportion of dates with usage blocking demand within a specific time period relative to the total number of dates, reflecting the historical frequency of access anomalies during that period. The "preset demand ratio threshold" is a critical percentage value used to determine whether a time period has a high usage blocking demand. The "usage demand period" refers to a period where the usage demand ratio is greater than the preset demand ratio threshold, i.e., a period with historically frequent access anomalies. The "preset period ratio threshold" is a critical percentage value used to determine whether the proportion of usage demand periods reaches the trigger condition for full implementation. The first ratio threshold is a critical value used to determine whether the proportion of blocked users on the previous date is within an acceptable range.

[0152] Assuming there are 8 time periods, within the most recent preset time period, the proportion of usage demand in some time periods exceeds a preset demand proportion threshold; these time periods are considered usage demand periods. If the proportion of usage demand periods to the total number of time periods exceeds the preset time period proportion threshold, it is determined that most time periods have high usage demand, and a comprehensive usage management approach is adopted; otherwise, proceed to S422 for refined judgment.

[0153] This step determines whether to adopt a full-scale deployment approach by assessing the coverage ratio during high-demand periods. Its significance lies in ensuring the comprehensive use of the blocking deployment module by adopting a one-time full-scale deployment approach when there is a high demand for blocking during most periods.

[0154] S422 determines whether there are dates requiring blocking use in all time periods except for the time periods when the blocking processing module is used in different dates. If yes, proceed to step S43. If no, determine that the blocking processing module is used in all time periods in the current date as long as the proportion of blocked users in the previous date is below the first proportion threshold and there are no dates in the recent preset time period where all time periods are used.

[0155] The period during which the blocking processing module is used on different dates refers to a period during which it is continuously used on all dates in the historical records, i.e., a fixed usage period. The preset period refers to a time window used to statistically analyze the comprehensive usage history.

[0156] Assuming the fixed usage periods are T2 and T3, if some of the remaining periods T1, T4 to T8 do not have dates requiring blocking usage, then it is determined to be a non-full coverage situation, and a full-scale deployment with additional conditions is adopted; if all remaining periods have dates requiring blocking usage, then the process proceeds to S43 for refined management.

[0157] This step determines the coverage of blocking usage demand during non-fixed time periods, distinguishing between situations requiring refined management and those where full deployment can be implemented with additional conditions. Its significance lies in the fact that when there are periods of no demand during non-fixed time periods, additional conditions can be set to limit the frequency of full deployment, thereby achieving a balance between full coverage and the risk of deployment blocking while reducing the risk of blocking.

[0158] S43 determines the deployment and management method of the blocking processing module based on the updated user ratio and the correlation between the blocking usage demand dates in different time periods.

[0159] Furthermore, based on the correlation between the blocking usage demand dates in different time periods, the percentage of time periods belonging to the blocking usage demand dates is determined. This percentage is used as the blocking demand time period percentage for that date. It is then determined whether there are any dates where the blocking demand time period percentage is greater than a preset demand time period percentage threshold. If so, the blocking processing module is configured to be used in all time periods of the current date if the percentage of blocked users in the previous date is below the first percentage threshold. Otherwise, the blocking processing module is configured to be used in all time periods of the current date if the percentage of blocked users in the previous date is below the first percentage threshold and the number of dates in the most recent preset time period where all time periods are used is less than the target date number.

[0160] The "blocking demand period ratio" refers to the proportion of time periods with blocking demand on a specific date out of all time periods, reflecting the concentration of multiple time periods experiencing simultaneous access anomalies within that date. The "preset demand period ratio threshold" is a critical proportion used to determine whether a date belongs to a high-risk date for multiple concurrent time periods. The "target date number" refers to the upper limit standard for the number of dates allowed for full utilization within the most recent preset time period.

[0161] If, in recent historical data, the percentage of blocking demand periods on certain dates exceeds the preset threshold, it indicates that multiple periods on these dates experience access anomalies simultaneously, posing a high overall risk. Therefore, full deployment will commence as long as the percentage of blocked users on the previous date is below the first threshold. If there are no such dates, full deployment can only proceed if the percentage of blocked users on the previous date meets the target and the number of fully deployed dates in the most recent preset period does not reach the target number of dates.

[0162] This step uses date-level analysis of the proportion of blocking demand periods to determine whether there are multiple high-risk dates with concurrent blocking. The significance is that when there are historically multiple high-risk dates with concurrent blocking, a more aggressive full-scale deployment strategy can be adopted to ensure blocking coverage on that day; otherwise, the historical frequency of full-scale deployment can be limited by the number of target dates. This ensures the reliability of blocking at critical moments while preventing the full-scale deployment strategy from being used too frequently, thereby causing excessive impact on users' normal access behavior.

[0163] This embodiment, through steps S41 to S43, dynamically determines the management method for deploying the blocking processing module based on the correlation between updated user proportion and access traffic changes. Its core value lies in three aspects: First, by evaluating the updated user proportion, the actual effect of knowledge graph-assisted filtering is quantified, providing a basis for selecting management methods. Second, by analyzing the proportion of blocking usage demand dates and blocking demand periods, abnormal access traffic is linked to blocking deployment decisions, achieving refined management based on actual risk distribution. Third, through the design of differentiated deployment conditions, while ensuring blocking coverage during critical periods, the frequency of full deployment is effectively controlled, achieving a dynamic balance between blocking reliability and normal access interference control.

[0164] Assume the enterprise has 8 time periods (T1-T8), the preset update user ratio threshold is 0.15, the preset time period is 30 days, the preset multiplier is 1.2, the preset demand ratio threshold is 0.40, the preset time period ratio threshold is 0.60, the first ratio threshold is 0.03, the preset demand time period ratio threshold is 0.50, the target date number is 5 days, and the preset time period is the most recent 30 days.

[0165] Assuming the current usage period is T2 and T3, the total number of blocked users during the usage period is 100, of which 18 users are identified and processed. The percentage of updated users = 18 ÷ 100 = 0.18 ≥ 0.15, proceed to step S42.

[0166] In S42, the access traffic data for each time period in the most recent 30 days is counted to determine the blocking usage requirement dates for each time period: T1 has 8 days, T2 has 15 days, T3 has 12 days, T4 has 11 days, T5 has 9 days, T6 has 7 days, T7 has 13 days, and T8 has 6 days.

[0167] In S421, the percentage of demand for each time period (number of demand days ÷ 30 days) is as follows: T1 = 0.27, T2 = 0.50, T3 = 0.40, T4 = 0.37, T5 = 0.30, T6 = 0.23, T7 = 0.43, and T8 = 0.20. Based on the preset demand percentage threshold of 0.40, the demand periods for use are T2 (0.50) and T7 (0.43), totaling one time period. The percentage of demand for use during this period = 2 ÷ 8 = 0.25, which is not greater than the preset time period percentage threshold of 0.60, so proceed to S422.

[0168] In S422, the fixed deployment periods are T2 and T3, and the remaining periods after removing them are T1, T4, T5, T6, T7, and T8. The percentage of no-demand days in T6 (0.23) and T8 (0.20) exceeds the limit, and there are unevenly distributed dates with blocking usage demand. The management method is determined as follows: if the percentage of blocked users is below 0.03 on the previous date, and there are no dates in the last 30 days where all periods are deployed, then all periods will be deployed on the current date.

[0169] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0170] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0171] The above description is merely one or more embodiments of this specification and is not intended to limit this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of one or more embodiments of this specification should be included within the scope of the claims of this specification.

Claims

1. A knowledge graph-based automated correlation analysis system for network threat intelligence, characterized in that, Specifically, it includes: The multi-source heterogeneous data fusion module is configured to obtain raw intelligence data from multiple public or private network threat intelligence sources and map the raw intelligence data into standardized triplet data. The dynamic graph construction module is connected to the multi-source heterogeneous data fusion module and is configured to receive the standardized triplet data, construct and continuously update the threat knowledge graph. An association reasoning engine, connected to the dynamic graph construction module, is configured to perform automated association reasoning on the threat knowledge graph; The blocking processing module blocks user access based on the reasoning results and the knowledge graph of the identified users. It determines the deployment strategy of the blocking processing module by utilizing the updated processing results of the identified users and the knowledge graphs of different identified users. It also determines the deployment management method of the blocking processing module based on the update status of the identified users in the blocked users during the usage period and the correlation of changes in access traffic in different time periods. The user identification process refers to users who meet the activity level screening criteria and whose access behavior knowledge graph needs to be constructed. Users with access risks are identified based on the reasoning results. When the access behavior of users with access risks does not conform to their own knowledge graph, the access of users with access risks is blocked. The method for determining the deployment strategy of the blocking processing module is as follows: By using user data for identification and processing, the proportion of identified and processed users among the enterprise's users is determined, and this proportion is taken as the identification user proportion. Based on the update processing results of the knowledge graphs of different identification processing users, the construction matching factor of the knowledge graph of the identification processing user is determined; The update processing result of the knowledge graph refers to the record and update status of the user's access behavior characteristics. Based on the proportion of identified users and the matching factors for constructing knowledge graphs of different identified users, the deployment strategy of the blocking processing module is determined, i.e., during which time periods the blocking processing module is deployed. The method for determining the management mode of the blocking processing module is as follows: Based on the updated data of the identified users among the blocked users during the usage period, the proportion of the identified users among the blocked users is determined, and the proportion of the identified users among the blocked users is used as the proportion of updated users. Based on the changes in access traffic in different time periods, the dates on which the access traffic in the time period exceeds a preset multiple of the daily average access traffic are determined, and the dates on which the access traffic exceeds a preset multiple of the daily average access traffic are used as the dates on which the access traffic in the time period is required to be blocked. Based on the updated user ratio and the correlation between the blocking usage demand dates for different time periods, the deployment and management method of the blocking processing module is determined; If the percentage of updated users is less than the preset threshold for the percentage of updated users, the management method for the blocking processing module is determined to be the basic management method. That is, if the blocking processing module has not been used in the most recent preset time period, and there is a blocking usage requirement date in the most recent preset time period, then the blocking processing module will be used on the current date.

2. The automated correlation analysis system for network threat intelligence based on knowledge graphs as described in claim 1, characterized in that, The raw intelligence data includes at least structured threat intelligence, unstructured threat reports, and semi-structured logs.

3. The automated correlation analysis system for network threat intelligence based on knowledge graphs as described in claim 1, characterized in that, The standardized triplet data follows a subject-predicate-object expression format.

4. The automated correlation analysis system for network threat intelligence based on knowledge graphs as described in claim 1, characterized in that, The dynamic graph construction module supports an incremental update mechanism with timestamps and generates a version identifier for each update of the threat knowledge graph, forming a time-aware graph version management.

5. The automated correlation analysis system for network threat intelligence based on knowledge graphs as described in claim 1, characterized in that, If the access behavior of a user with access risk does not belong to the access IP address and access terminal of the user with access risk, then it is determined that the access behavior of the user with access risk does not conform to its own knowledge graph.

6. A knowledge graph-based automated correlation analysis method for network threat intelligence, applied to the knowledge graph-based automated correlation analysis system for network threat intelligence as described in any one of claims 1-5, characterized in that, Specifically, it includes: Based on the blocking data, the blocked user data of the enterprise in different time periods is determined. Based on the blocked user data in different time periods, the identified users among the enterprise's users are identified and processed. The deployment strategy of the blocking processing module is determined by using the updated processing results of the knowledge graph of the identified and processed users and different identified and processed users. The usage period of the blocking processing module is determined using the aforementioned deployment strategy. Based on the usage period and the blocked user data in different usage periods, if it is determined that the deployment strategy can be optimized, proceed to the next step. The management method for the blocking processing module is determined based on the update status of the identified users during the usage period and the correlation of changes in access traffic in different time periods.

7. The automated correlation analysis method for network threat intelligence based on knowledge graphs as described in claim 6, characterized in that, The method for identifying users in the enterprise's user identification process is as follows: By analyzing user data from different time periods, the proportion of users blocked in different time periods can be determined. The proportion of blocked users during the specified time period is defined as the proportion of blocked users during the specified time period. Based on the proportion of blocked users in different time periods, the users among the users are identified and processed.

Images