A risk assessment method, apparatus and electronic device

Abstract

This application discloses a risk assessment method, apparatus, and electronic device. The method includes: acquiring a set of traffic logs and an event log set output by a system to be analyzed over a continuous period of N hours; calculating a traffic event index and an abnormal request index corresponding to each source IP address based on the traffic log set and the event log set; determining a behavioral risk index corresponding to each source IP address based on the traffic event index and the abnormal request index corresponding to each source IP address; and assessing the risk of the corresponding source IP address based on the behavioral risk index. The technical solution provided by this application enables risk assessment of source IP addresses, effectively mitigating the uncertainty caused by data quality and timeliness issues in external intelligence data, and effectively improving the effectiveness and accuracy of the risk assessment results for source IP addresses.

Description

Technical Field

[0001] This application relates to the field of network and information security technology, and in particular to a risk assessment method, apparatus and electronic device. Background Technology

[0002] Internet Protocol (IP) addresses are used to track and identify every device on a network. However, because IP addresses can be spoofed or misused, malicious actors can use them to carry out a range of malicious activities, such as distributed denial-of-service (DDoS) attacks, spam distribution, and malware propagation. Furthermore, legitimate IP addresses can also become part of botnets through infection, unintentionally participating in cyberattacks.

[0003] To protect network security, risk assessments can be conducted on source IP addresses to identify potential threats and thus prevent them from escalating.

[0004] Current IP risk assessment methods mainly utilize relevant information about the source IP address, such as its location, associated contrasting domains, and associated threat intelligence, to assess the risk of the source IP address.

[0005] However, the network environment is constantly changing, and the network attack strategies and techniques of criminals are also constantly evolving, which makes the validity period of source IP address information uncertain. As a result, the accuracy of the IP risk assessment method based on source IP address information is low.

[0006] For example, once a normal source IP address is gained control by criminals, they can use that source IP address to carry out a series of malicious activities in a very short time. However, the updates of the relevant information of the source IP address are delayed, which leads to the risk assessment results using the relevant information of the source IP address not matching the actual situation.

[0007] Furthermore, the accuracy of the aforementioned IP risk assessment methods also depends on the quality of the data source. However, the inconsistent quality of data sources also contributes to the low accuracy of IP risk assessment methods.

[0008] For example, the data used in IP risk assessment comes from threat intelligence information from different vendors, but the threat intelligence information from different vendors may contain incomplete records or even erroneous data, which may lead to deviations in the risk assessment results of the source IP address.

[0009] Therefore, the above-mentioned IP risk assessment method is affected by the timeliness and data quality of the relevant information of the source IP address, resulting in low accuracy of the risk assessment results of the source IP address. Summary of the Invention

[0010] This application provides a risk assessment method, apparatus, and electronic device to improve the accuracy of IP risk assessment. The specific implementation scheme is as follows:

[0011] Firstly, this application provides a risk assessment method, the method comprising:

[0012] Obtain a set of traffic logs and an event log set output by the system to be analyzed for a continuous period of N hours; wherein, the event logs in the event log set are logs of attack events; both the traffic log set and the event log set include the source Internet Protocol IP address; N is a positive number;

[0013] Based on the traffic log set and the event log set, calculate the traffic event index and abnormal request index corresponding to each source IP address; wherein, the traffic event index is a parameter reflecting the correlation between traffic and attack events, and the abnormal request index is a parameter reflecting the correlation between traffic and abnormal requests.

[0014] Based on the traffic event index and the abnormal request index corresponding to each source IP address, a behavioral risk index corresponding to each source IP address is determined, and the risk of the corresponding source IP address is assessed based on the behavioral risk index.

[0015] Through the above-described embodiments, risk assessment analysis is performed using a set of traffic logs for N consecutive hours output by the system to be analyzed and a set of event logs including attack events. In other words, this embodiment uses real-time source IP address data for analysis, that is, it is based on real traffic and attack data. After the system to be analyzed outputs log data, the risk assessment result of the corresponding source IP address will be obtained immediately within N hours at the latest. This avoids the problem of expired information related to the source IP address (such as traffic log data and event log data) and the quality problem of information related to the source IP address, thereby solving the timeliness and quality problems of data and making the risk assessment result of the source IP address more accurate.

[0016] Furthermore, the above-mentioned application embodiments utilize traffic logs and event logs related to the source IP address, analyze the correlation between traffic and events (such as attack events) (i.e., traffic event index), and analyze the correlation between traffic and abnormal requests (i.e., abnormal request index), and then fuse the traffic event index and the abnormal request index to achieve a comprehensive consideration from the perspectives of both events (such as attack events) and abnormal requests, thereby making the risk assessment results of the source IP address more credible and more accurate.

[0017] In one possible implementation, the step of calculating the traffic event index and abnormal request index corresponding to each source IP address based on the traffic log set and the event log set includes:

[0018] Using the source IP address as the grouping condition, the traffic logs in the traffic log set are divided into multiple traffic log subsets, and the event logs in the event log set are divided into multiple event log subsets;

[0019] Based on each subset of traffic logs and each subset of event logs, calculate the proportion of traffic events and the relevance of traffic events corresponding to the corresponding source IP address; and based on each subset of event logs, calculate the richness of event types corresponding to the corresponding source IP address. Then, combine the proportion of traffic events, the relevance of traffic events, and the richness of event types to obtain the traffic event index corresponding to the corresponding source IP address; and

[0020] For each subset of traffic logs, calculate the percentage of abnormal requests, the relevance of abnormal requests, and the richness of response code types corresponding to the source IP address. Then, combine the percentage of abnormal requests, the relevance of abnormal requests, and the richness of response code types to obtain the abnormal request index corresponding to the source IP address.

[0021] Through the above application embodiments, the traffic logs in the traffic log set and the event logs in the event log set are grouped by the source IP address as the grouping condition, so as to facilitate better subsequent analysis of the data corresponding to the source IP address (such as the traffic log subset and the event log subset) to obtain the corresponding behavioral risk index.

[0022] Then, by combining the proportion of traffic events, the relevance of traffic events, and the richness of event types calculated from the subset of traffic logs and the subset of event logs, the traffic event index of the corresponding source IP address is obtained. This allows for a comprehensive evaluation of IP attack behavior from the perspective of the distribution of attack events in the traffic, making the determination of the traffic event index more accurate.

[0023] Simultaneously, by combining the percentage of abnormal requests, the relevance of abnormal requests, and the richness of response code types calculated from a subset of traffic logs, an abnormal request index for the corresponding source IP address is obtained. This allows for a comprehensive evaluation of IP attack behavior from the perspective of the distribution of abnormal requests in the traffic, making the determination of this abnormal request index more accurate. Furthermore, by comprehensively evaluating IP attack behavior from both the perspective of the distribution of attack events in the traffic and the perspective of the distribution of abnormal requests in the traffic, the resulting behavioral risk index for the source IP address becomes even more accurate.

[0024] In one possible implementation, calculating the proportion of traffic events corresponding to the corresponding source IP address based on each of the traffic log subsets and each of the event log subsets includes:

[0025] Within each time window, determine the number of traffic logs in the traffic log subset corresponding to each source IP address, and the number of event logs in the corresponding event log subset; wherein, the length of the time window is a preset duration;

[0026] The ratio of the sum of the number of event logs and the first preset value to the sum of the number of traffic logs and the first preset value is used as the proportion of sub-traffic events of the corresponding source IP address within the corresponding time window.

[0027] The average of the proportions of the multiple sub-traffic events corresponding to each source IP address is taken as the proportion of the corresponding traffic event.

[0028] Through the above-described embodiments, the proportion of sub-traffic events for the corresponding source IP address is determined by the ratio of the sum of the number of event logs corresponding to the source IP address and a first preset value within each time window to the sum of the number of traffic logs and the first preset value. This allows for the understanding of the distribution of attack events within the traffic based on the sub-traffic event proportion, facilitating a better understanding of IP-based behavioral attacks. Furthermore, when calculating the ratio between the number of event logs and the number of traffic logs, a first preset value is added to both, avoiding a denominator of 0 and ensuring that both the number of event logs and the number of traffic logs can increase simultaneously, thus making the calculated sub-traffic event proportion more accurate. The average of the sub-traffic event proportions within each time window is then used to determine the traffic event proportion corresponding to the corresponding source IP address. This ensures that the final traffic event proportion takes into account the impact of time on the traffic event proportion, further improving the accuracy of the traffic event proportion and contributing to the accuracy of the traffic event index obtained based on the traffic event proportion.

[0029] In one possible implementation, calculating the relevance of the traffic event corresponding to the source IP address based on each of the traffic log subsets and each of the event log subsets includes:

[0030] For each source IP address, based on the proportion of sub-traffic events corresponding to two adjacent time windows, calculate the change in the event proportion corresponding to the time window; and calculate the average of the multiple event proportion changes corresponding to each source IP address to obtain the average event proportion change for the corresponding source IP address; and

[0031] Determine the maximum percentage change in the proportion of events corresponding to each source IP address;

[0032] The difference between the second preset value and the ratio of the average event percentage change to the maximum event percentage change is used as the relevance of the traffic event corresponding to the source IP address.

[0033] By combining the proportion of sub-traffic events with the above-mentioned application embodiments, the magnitude of change in the proportion of events is analyzed to obtain the corresponding traffic event correlation. Thus, the correlation between traffic and attack events can be known based on the traffic event correlation, so as to better understand IP behavior attacks and make the traffic event correlation more accurate, thereby helping to make the traffic event index obtained based on the traffic event correlation more accurate.

[0034] In one possible implementation, calculating the event type richness corresponding to the source IP address for each subset of event logs includes:

[0035] For each source IP address, determine the total number of event logs and the number of logs corresponding to each event type identifier ID in the corresponding event log subset;

[0036] The event type richness corresponding to the source IP address is calculated based on the ratio between the sum of the number of logs corresponding to each event type ID and the third preset value, and the sum of the total number of event logs and the third preset value.

[0037] Through the above-described embodiments, the event type richness is calculated by dividing the sum of the number of logs corresponding to each determined event type ID by a third preset value by the sum of the total number of event logs by the third preset value. This allows for a better understanding of the event types within the traffic, facilitating a more accurate assessment of IP-related attacks and making the event type richness more precise. Consequently, the traffic event index derived from event type richness becomes more accurate. Furthermore, when calculating the ratio between the number of logs corresponding to each event type ID and the total number of event logs, a third preset value is added to both. This avoids a denominator of 0 and ensures that both the number of logs corresponding to each event type ID and the total number of event logs can increase simultaneously, further enhancing the accuracy of the event type richness.

[0038] In one possible implementation, the step of fusing the traffic event proportion, the traffic event relevance, and the event type richness to obtain the traffic event index corresponding to the source IP address includes:

[0039] For each source IP address, the product of the square root of the product of the relevance of the traffic event and the richness of the event type, and the product of the proportion of the traffic event, is used as the traffic event index corresponding to the source IP address.

[0040] By combining the relevance of traffic events, the richness of event types, and the proportion of traffic events in the above-described application embodiments, the accuracy of the calculated traffic event index is further improved, thereby helping to further improve the accuracy of the behavioral risk index based on the traffic event index.

[0041] In one possible implementation, calculating the percentage of abnormal requests corresponding to the source IP address for each subset of traffic logs includes:

[0042] For each source IP address, within each time window, the proportion of requests with multiple abnormal response codes is calculated, and the proportions of multiple abnormal response code requests are weighted and summed to obtain the sub-abnormal request proportion of the corresponding source IP address within the corresponding time window; wherein, the abnormal response code request proportion is obtained based on the number of abnormal traffic logs and the number of traffic logs; the abnormal traffic logs are traffic logs in the subset of traffic logs whose response codes are abnormal and whose times are within the corresponding time window;

[0043] For each source IP address, the average of the percentages of the sub-abnormal requests within each time window is taken as the percentage of abnormal requests corresponding to the source IP address.

[0044] Through the above application embodiments, the weighted sum of the proportions of multiple abnormal response codes within a time window is used to obtain the sub-abnormal request proportion of the corresponding source IP address within the corresponding time window. This allows for the understanding of the distribution of abnormal response codes in the traffic log subset based on the sub-abnormal request proportion, making the obtained sub-abnormal request proportion more accurate. Furthermore, the final abnormal request proportion corresponding to that source IP address is determined by averaging the sub-abnormal request proportions within different time windows. This ensures that the obtained abnormal request proportion takes into account the impact of time on the abnormal request proportion, thereby improving the accuracy of the abnormal request proportion and further enhancing the accuracy of the abnormal request index obtained based on the abnormal request proportion.

[0045] In one possible implementation, calculating the relevance of the abnormal request to the corresponding source IP address for each subset of traffic logs includes:

[0046] For each source IP address, based on the percentage of abnormal requests corresponding to each of two adjacent time windows, calculate the change in the percentage of abnormal requests for that time window; and calculate the average of the multiple percentage changes in the percentage of abnormal requests for each source IP address to obtain the average percentage change in the percentage of abnormal requests for that source IP address; and

[0047] Determine the maximum percentage change in abnormal requests corresponding to each source IP address;

[0048] The difference between the fourth preset value and the ratio of the average change in the proportion of abnormal requests to the maximum change in the proportion of abnormal requests is used as the abnormal request relevance corresponding to the source IP address.

[0049] Through the above application embodiments, combined with the proportion of sub-abnormal requests, the change range of the proportion of abnormal requests is analyzed to obtain the corresponding abnormal request relevance. Thus, the correlation of abnormal requests in traffic can be known based on the abnormal request relevance, so as to better understand IP behavior attacks and make the abnormal request relevance more accurate, thereby helping to make the abnormal request index obtained based on the abnormal request relevance more accurate.

[0050] In one possible implementation, calculating the response code type richness corresponding to the source IP address for each subset of traffic logs includes:

[0051] For each source IP address, determine the total number of traffic logs and the number of logs corresponding to each response code in the corresponding subset of traffic logs;

[0052] The response code type richness corresponding to the source IP address is calculated based on the ratio between the number of logs corresponding to each response code and the total number of traffic logs.

[0053] Through the above application embodiments, the response code type richness is calculated based on the ratio between the number of logs corresponding to each determined response code and the total number of determined traffic logs. This allows us to understand the response codes in the traffic based on the response code type richness, which helps to better understand IP behavior attacks and makes the response code type richness more accurate. This, in turn, helps to make the abnormal request index obtained based on the response code type richness more accurate.

[0054] In one possible implementation, the step of fusing the percentage of abnormal requests, the relevance of abnormal requests, and the richness of response code types to obtain the abnormal request index corresponding to the source IP address includes:

[0055] For each source IP address, the square root of the product of the corresponding abnormal request relevance and the response code type richness, and the product of the corresponding abnormal request proportion, are used as the abnormal request index corresponding to the source IP address.

[0056] By combining the above application embodiments with the relevance of abnormal requests, the richness of response code types, and the proportion of abnormal requests, the accuracy of the calculated abnormal request index has been further improved, thereby helping to further improve the accuracy of the behavioral risk index based on the abnormal request index.

[0057] In one possible implementation, determining the behavioral risk index corresponding to each source IP address based on the traffic event index and the abnormal request index corresponding to each source IP address includes:

[0058] Determine the target traffic event index weights and the target abnormal request index weights;

[0059] For each source IP address, the sum of the product of the corresponding traffic event index and the target traffic event index weight, and the product of the corresponding abnormal request index and the target abnormal request index weight, is used as the behavioral risk index corresponding to the source IP address.

[0060] Through the above application embodiments, based on the determined target traffic event index weight and target abnormal request index weight, the traffic event index and abnormal request index are weighted and summed, so that the behavioral risk index corresponding to the source IP address comprehensively considers the impact of the traffic event index and abnormal request index on IP risk, thereby making the behavioral risk index of the source IP address more accurate.

[0061] In one possible implementation, determining the target traffic event index weight and the target abnormal request index weight includes:

[0062] Acquire training data; wherein, the training data includes multiple historical traffic logs and multiple historical event logs;

[0063] For each source IP address in the multiple historical traffic logs and multiple historical event logs, malicious behavior and normal behavior are marked, and the behavior risk index mark value corresponding to the source IP address marked as malicious behavior is determined to be a fifth preset value, and the behavior risk index mark value corresponding to the source IP address marked as normal behavior is determined to be a sixth preset value; and

[0064] Initialize the event index weights and abnormal request index weights; based on the initialized event index weights and abnormal request index weights, calculate the historical behavior risk index corresponding to each source IP address in the multiple historical traffic logs and the multiple historical event logs;

[0065] Based on the historical behavior risk index and the corresponding behavior risk index label value corresponding to each source IP address in the multiple historical traffic logs and multiple historical event logs, the event index weight and the abnormal request index weight are iteratively trained to obtain the target event index weight and the target abnormal request index weight.

[0066] Through the above application embodiments, the target event index weight and the target abnormal request index weight are obtained by iterative training based on the event index weight and the abnormal request index weight. This makes the obtained target event index weight and the target abnormal request index weight the optimal target event index weight and the target abnormal request index weight at the current stage. As a result, the behavioral risk index obtained based on the target event index weight and the target abnormal request index weight is more accurate, and the accuracy of risk assessment of source IP addresses is further improved.

[0067] Secondly, this application also provides a risk assessment device, the device comprising:

[0068] The acquisition module is used to acquire a set of traffic logs and an event log set output by the system to be analyzed for a continuous period of N hours; wherein, the event logs in the event log set are logs of attack events; both the traffic log set and the event log set include the source Internet Protocol IP address; N is a positive number;

[0069] The calculation module is used to calculate the traffic event index and abnormal request index corresponding to each source IP address based on the traffic log set and the event log set; wherein, the traffic event index is a parameter reflecting the correlation between traffic and attack events, and the abnormal request index is a parameter reflecting the correlation between traffic and abnormal requests.

[0070] The processing module is used to determine the behavioral risk index corresponding to each source IP address based on the traffic event index and the abnormal request index corresponding to each source IP address, and to assess the risk of the corresponding source IP address based on the behavioral risk index.

[0071] In one possible implementation, the calculation module is specifically configured to: divide the traffic logs in the traffic log set into multiple traffic log subsets and the event logs in the event log set into multiple event log subsets, using the source IP address as the grouping condition; calculate the traffic event proportion and traffic event relevance corresponding to each source IP address based on each traffic log subset and each event log subset; calculate the event type richness corresponding to each source IP address based on each event log subset; and fuse the traffic event proportion, traffic event relevance, and event type richness to obtain the traffic event index corresponding to the corresponding source IP address; and calculate the abnormal request proportion, abnormal request relevance, and response code type richness corresponding to each source IP address based on each traffic log subset; and fuse the abnormal request proportion, abnormal request relevance, and response code type richness to obtain the abnormal request index corresponding to the corresponding source IP address.

[0072] In one possible implementation, the calculation module is further configured to determine, within each time window, the number of traffic logs in the traffic log subset corresponding to each source IP address, and the number of event logs in the corresponding event log subset; wherein, the length of the time window is a preset duration; the ratio of the sum of the number of event logs and a first preset value to the sum of the number of traffic logs and the first preset value is used as the proportion of sub-traffic events for the corresponding source IP address within the corresponding time window; and the average value among the proportions of multiple sub-traffic events corresponding to each source IP address is used as the proportion of the corresponding traffic event.

[0073] In one possible implementation, the calculation module is further configured to, for each source IP address, calculate the change magnitude of the event proportion corresponding to the corresponding time window based on the proportion of sub-traffic events corresponding to each of two adjacent time windows; calculate the average value among the multiple event proportion change magnitudes corresponding to each source IP address to obtain the average event proportion change magnitude corresponding to the corresponding source IP address; determine the maximum event proportion change magnitude corresponding to each source IP address; and use the difference between the second preset value and the ratio of the average event proportion change magnitude to the maximum event proportion change magnitude as the relevance of the traffic event corresponding to the corresponding source IP address.

[0074] In one possible implementation, the calculation module is further configured to, for each source IP address, determine the total number of event logs and the number of logs corresponding to each event type identifier ID in the corresponding event log subset; and calculate the event type richness corresponding to the corresponding source IP address based on the ratio between the sum of the number of logs corresponding to each event type ID and a third preset value and the sum of the total number of event logs and the third preset value.

[0075] In one possible implementation, the calculation module is further configured to, for each source IP address, multiply the square root of the product of the corresponding traffic event relevance and the event type richness by the corresponding traffic event proportion, as the traffic event index corresponding to the corresponding source IP address.

[0076] In one possible implementation, the calculation module is further configured to, for each source IP address, calculate the proportion of multiple abnormal response code requests within each time window, and perform a weighted summation of the multiple abnormal response code request proportions to obtain the sub-abnormal request proportion of the corresponding source IP address within the corresponding time window; wherein, the abnormal response code request proportion is obtained based on the number of abnormal traffic logs and the number of traffic logs; the abnormal traffic logs are traffic logs in the subset of traffic logs whose response codes are abnormal response codes and whose times are within the corresponding time window; for each source IP address, the average value among the sub-abnormal request proportions corresponding to each of the time windows is taken as the abnormal request proportion corresponding to the corresponding source IP address.

[0077] In one possible implementation, the calculation module is further configured to, for each source IP address, calculate the change magnitude of the abnormal request proportion corresponding to the corresponding time window based on the proportion of sub-abnormal requests corresponding to two adjacent time windows; calculate the average value among the multiple abnormal request proportion change magnitudes corresponding to each source IP address to obtain the average abnormal request proportion change magnitude corresponding to the corresponding source IP address; determine the maximum abnormal request proportion change magnitude corresponding to each source IP address; and use the difference between the fourth preset value and the ratio of the average abnormal request proportion change magnitude to the maximum abnormal request proportion change magnitude as the abnormal request relevance corresponding to the corresponding source IP address.

[0078] In one possible implementation, the calculation module is further configured to, for each source IP address, determine the total number of traffic logs and the number of logs corresponding to each response code in the corresponding subset of traffic logs; and calculate the response code type richness corresponding to the corresponding source IP address based on the ratio between the number of logs corresponding to each response code and the total number of traffic logs.

[0079] In one possible implementation, the calculation module is further configured to, for each source IP address, multiply the square root of the product of the corresponding abnormal request relevance and the response code type richness by the corresponding abnormal request proportion, as the abnormal request index corresponding to the corresponding source IP address.

[0080] In one possible implementation, the processing module is specifically used to determine the target traffic event index weight and the target abnormal request index weight; for each source IP address, the sum of the product of the corresponding traffic event index and the target traffic event index weight, and the product of the corresponding abnormal request index and the target abnormal request index weight, is used as the behavioral risk index corresponding to the corresponding source IP address.

[0081] In one possible implementation, the processing module is further configured to acquire training data; wherein the training data includes multiple historical traffic logs and multiple historical event logs; mark each source IP address in the multiple historical traffic logs and multiple historical event logs as either malicious or normal behavior, and determine that the behavior risk index mark value corresponding to the source IP address marked as malicious behavior is a fifth preset value, and the behavior risk index mark value corresponding to the source IP address marked as normal behavior is a sixth preset value; initialize event index weights and abnormal request index weights; calculate the historical behavior risk index corresponding to each source IP address in the multiple historical traffic logs and multiple historical event logs based on the initialized event index weights and abnormal request index weights; iteratively train the event index weights and abnormal request index weights based on the historical behavior risk index corresponding to each source IP address in the multiple historical traffic logs and multiple historical event logs and the corresponding behavior risk index mark value, to obtain the target event index weights and the target abnormal request index weights.

[0082] Thirdly, this application provides an electronic device, comprising:

[0083] Memory, used to store computer programs;

[0084] When the processor executes the computer program stored in the memory, it implements the steps of the risk assessment method described above.

[0085] Fourthly, this application provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the risk assessment method described above.

[0086] For the various aspects of the second to fourth aspects mentioned above, and the technical effects that each aspect may achieve, please refer to the above description of the technical effects that can be achieved for the first aspect or the various possible solutions in the first aspect, which will not be repeated here. Attached Figure Description

[0087] Figure 1 A schematic diagram of a traditional IP risk assessment method provided in the embodiments of this application;

[0088] Figure 2 A flowchart illustrating a risk assessment method provided in this application embodiment;

[0089] Figure 3 A schematic diagram illustrating the processing steps of the risk assessment method provided in the embodiments of this application;

[0090] Figure 4A schematic diagram of a risk assessment device provided in an embodiment of this application;

[0091] Figure 5 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0092] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The specific operational methods in the method embodiments can also be applied to the device embodiments or system embodiments. It should be noted that in the description of this application, "multiple" is understood as "at least two". "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. A connected to B can represent: A and B directly connected, and A and B connected through C. Furthermore, in the description of this application, terms such as "first" and "second" are used only for distinguishing the purpose of description and should not be construed as indicating or implying relative importance or order.

[0093] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0094] Traditional IP risk assessment methods such as Figure 1 As shown, firstly, IP features are extracted from the IP address database and access logs, and then a feature matrix is ​​constructed using these features. Next, the IP risk level (such as the risk level of the source IP address) is determined through matrix calculations. Then, IP risk is labeled based on the IP risk level, thereby enabling risk assessment of the source IP address. In other words, risk assessment is performed using relevant information from IP addresses.

[0095] However, traditional IP risk assessment methods are affected by the timeliness and data quality of information related to the source IP address, resulting in low accuracy of risk assessment results for the source IP address.

[0096] Currently, the World Wide Web (WW) is the primary network exposure surface application. Attacks on WW applications via the Hypertext Transfer Protocol (HTTP) are the main attack method used by criminals. Most of the abnormal behaviors of criminals can be recorded in the HTTP logs. Therefore, by analyzing the relevant HTTP log data, the risk assessment of the source IP address can be carried out in real time and efficiently.

[0097] Therefore, this application proposes a risk assessment method that utilizes a continuous N-hour traffic log set output by the system under analysis and an event log set including attack event logs to calculate the traffic event index and abnormal request index corresponding to each source IP address. Then, based on these indexes, a behavioral risk index is determined for the corresponding source IP address, thereby assessing the risk of that source IP address. This approach comprehensively considers the risk behavior of source IP addresses from both event (e.g., attack events) and abnormal request perspectives, resulting in higher reliability and greater accuracy in the risk assessment results. Furthermore, the risk assessment analysis is performed using a set of traffic logs for N consecutive hours output by the system to be analyzed and a set of event logs including attack events. In other words, this embodiment uses real-time source IP address data for analysis, that is, it is based on real traffic and attack data. After the system to be analyzed outputs log data, the risk assessment result of the corresponding source IP address will be obtained immediately within N hours at the latest. This avoids the problem of the source IP address's related information (such as traffic log data and event log data) being outdated and the quality problem of the source IP address's related information, thereby solving the timeliness and quality problems of the data and making the risk assessment result of the source IP address more accurate.

[0098] The risk assessment method proposed in this application can be applied to security systems that primarily support parsing HTTP protocol traffic, such as full-traffic security analysis systems and network intrusion detection systems, to improve the accuracy and effectiveness of IP address threat intelligence extraction.

[0099] Reference Figure 2 The diagram shown is a flowchart of a risk assessment method provided in an embodiment of this application. The method includes:

[0100] S201, Obtain the set of traffic logs for N consecutive hours output by the system to be analyzed and the set of event logs to be analyzed.

[0101] Where N is a positive number.

[0102] S202, based on the traffic log set and the event log set, calculate the traffic event index and abnormal request index corresponding to each source IP address.

[0103] S203. Based on the traffic event index and abnormal request index corresponding to each source IP address, determine the behavioral risk index corresponding to each source IP address, and assess the risk of the corresponding source IP address based on the behavioral risk index.

[0104] In this embodiment of the application, the traffic logs in the traffic log set include: Session Identifier (ID), Time, Source IP Address, Destination IP Address, Request Uniform Resource Locator (URL), Request Header, Request Body, Response Header, Response Body, Response Code, and other field information.

[0105] The event logs in the above event log collection include: session ID, time, source IP, destination IP, request URL, request header, request body, response header, response body, response code, event type ID, event level, event description, and other information.

[0106] The traffic logs mentioned above can be raw Hypertext Transfer Protocol (HTTP) traffic logs. The event logs mentioned above can be HTTP attack event logs.

[0107] Therefore, after the system outputs traffic logs for analysis, a detection tool is used to check whether the traffic log is an attack event. If so, the traffic log is saved as an event log, thus obtaining a collection of event logs.

[0108] The system to be analyzed can be a network traffic analysis device, but it is not limited to that.

[0109] After obtaining the traffic log set and the event log set, the traffic event index and abnormal request index corresponding to each source IP address are calculated based on the traffic log set and the event log set.

[0110] Specifically, firstly, based on the source IP address, the traffic logs in the traffic log set are divided into multiple traffic log subsets, and the event logs in the event log set are divided into multiple event log subsets. Thus, based on the source IP address, a corresponding traffic log subset and an event log subset can be determined.

[0111] The above multiple traffic log subsets can be represented by {FlowSet(IP1), FlowSet(IP2), FlowSet(IP3)...}, where FlowSet(IP1) represents the traffic logs included when the source IP address is IP1, that is, the traffic log subset corresponding to the source IP address is IP1.

[0112] The aforementioned subsets of event logs can be represented as {EventSet(IP1), EventSet(IP2), EventSet(IP3)...}. Here, EventSet(IP1) represents the event logs included when the source IP address is IP1; that is, the subset of event logs corresponding to the source IP address IP1.

[0113] Then, based on each subset of traffic logs and each subset of event logs, the traffic event index and abnormal request index corresponding to the source IP address are calculated.

[0114] Taking a source IP address as an example, the specific process of determining the traffic event index corresponding to that source IP address based on the traffic log subset and event log subset can be as follows:

[0115] Based on the subset of traffic logs and the subset of event logs corresponding to the source IP address, the proportion of traffic events, the relevance of traffic events, and the richness of event types corresponding to that source IP address are calculated. Then, the proportion of traffic events, the relevance of traffic events, and the richness of event types are combined to obtain the traffic event index corresponding to that source IP address, thereby making the traffic event index more accurate.

[0116] The aforementioned percentage of traffic events can be determined using the following calculation method:

[0117] First, within each time window, determine the number of traffic logs in the traffic log subset corresponding to the source IP address, and the number of event logs in the corresponding event log subset. The length of this time window is a preset duration, denoted by Δt.

[0118] Since the duration of the traffic log subset is no greater than N, it can be divided into n time windows based on the time window principle. Here, n = N / Δt. Assuming the start time of the traffic log subset is t0, the sliding of this time window is based on t... i =t i-1 The time window is adjusted by adding Δt. That is, the 0th time window is (t0, t0+Δt), and the 1st time window is (t0+Δt, t1+Δt).

[0119] The above-mentioned calculation method for the number of traffic logs is as follows: Taking a time window as an example, such as (t0, t0+Δt), where t0 is the start time of the traffic log subset. Within the (t0, t0+Δt) time window, the session IDs of the traffic logs with times within the (t0, t0+Δt) time window in the traffic log subset corresponding to the source IP address are deduplicated. The number of deduplicated session IDs is then used to determine the number of traffic logs within the (t0, t0+Δt) time window.

[0120] For example, the traffic logs of the traffic log subset FlowSet(IP1) corresponding to IP1 within the time window of (t0, t0+Δt) include: traffic log A, traffic log B, traffic log C, traffic log D, and traffic log E, and the session ID of traffic log A is 001, the session ID of traffic log B is 002, the session ID of traffic log C is 003, the session ID of traffic log D is 001, and the session ID of traffic log E is 001.

[0121] Since the session IDs of traffic logs A, D, and E are all 001, it is determined that traffic logs A, D, and E belong to the same traffic log. Therefore, by deduplicating these three traffic logs, the deduplicated session IDs are 001, 002, and 003, respectively. Consequently, the number of traffic logs in the traffic log subset FlowSet(IP1) corresponding to IP1 within the time window of (t0, t0+Δt) is 3.

[0122] The calculation method for the number of event logs is the same as that for the number of traffic logs. That is, within each time window, the session IDs in the event log subset corresponding to the source IP address are deduplicated, and the number of deduplicated session IDs is used to determine the number of event logs in the corresponding time window.

[0123] Then, the ratio of the sum of the number of event logs and the first preset value to the sum of the corresponding number of traffic logs and the first preset value is used as the proportion of sub-traffic events for that source IP address within the corresponding time window. This makes the calculation of the sub-traffic event proportion more accurate, thus making the traffic event proportion based on the sub-traffic event proportion more accurate. This process can be expressed by the following formula:

[0124]

[0125] Among them, PE v This represents the percentage of sub-traffic events for the source IP address within the corresponding time window; CntEvent(IP) represents the number of event logs for the source IP address within the corresponding time window; CntFlow(IP) represents the number of traffic logs for the source IP address within the corresponding time window; θ1 represents the first preset value. This first preset value can be 0.01.

[0126] In this embodiment of the application, the proportion of the aforementioned sub-traffic events is greater than or equal to a seventh preset value and less than or equal to an eighth preset value. The seventh preset value can be 0, and the eighth preset value can be 1, that is, PE v ∈[0, 1]. The above

[0127] Using the above method, after calculating the proportion of sub-traffic events for the source IP address within each time window, the average of the proportions of sub-traffic events for each time window is taken as the proportion of traffic events corresponding to the source IP address, as shown in the following formula:

[0128]

[0129] Where PE represents the average percentage of sub-traffic events for a source IP address within each time window, and also represents the percentage of traffic events corresponding to that source IP address; n represents the number of time windows; PE vi This indicates the percentage of sub-traffic events for the source IP address within the i-th time window.

[0130] The relevance of the aforementioned traffic events can be determined using the following calculation method:

[0131] For the source IP address, calculate the change in the proportion of events corresponding to the corresponding time window based on the proportion of sub-traffic events corresponding to the two adjacent time windows.

[0132] In this embodiment of the application, the change in the event proportion is the magnitude of the change in the proportion of sub-traffic events between two adjacent time windows within a unit of time.

[0133] Therefore, the above calculation of the change in the event proportion corresponding to the corresponding time window based on the proportion of sub-traffic events corresponding to each of two adjacent time windows can be summarized as follows:

[0134] Calculate the absolute value of the difference between the proportions of sub-traffic events corresponding to two adjacent time windows, and use the ratio of this absolute value to the length of the time window as the magnitude of the change in the event proportion within the corresponding time window. This makes the calculated magnitude of the change in the event proportion more accurate, thus making the correlation of traffic events based on this magnitude of the event proportion more precise. The calculation process for this magnitude of the change in the event proportion can be shown in the following formula:

[0135]

[0136] Where ME represents the change in the proportion of events originating from the source IP address between the (i-1)th and ith time windows; PE v(i-1) This represents the percentage of sub-traffic events originating from the source IP address within the (i-1)th time window.

[0137] Next, the average of the changes in the proportion of multiple events corresponding to the source IP address is calculated to obtain the average change in the proportion of events corresponding to that source IP address. This integrates the changes in the proportion of events within various time windows, which helps to further improve the accuracy of traffic event correlation. The calculation process for this average change in the proportion of events can be shown in the following formula:

[0138]

[0139] in, This indicates the change in the average percentage of events corresponding to the source IP address.

[0140] At the same time, determine the maximum percentage change of events corresponding to that source IP address.

[0141] Due to PE v The value range of PE is: v If ∈[0,1], then PE v The maximum value is 1, PE v The minimum value is 0, and therefore the maximum value of the change in the event percentage (i.e., the maximum change in the event percentage) is:

[0142]

[0143] Where max(ME) represents the maximum percentage change of the event corresponding to the source IP address.

[0144] Furthermore, the difference between the average change in the proportion of events corresponding to the same source IP address and the maximum change in the proportion of events is taken as the relevance of the traffic events corresponding to the source IP address. This second preset value can be 1. This process can be illustrated by the following formula:

[0145]

[0146] CE = 1 - ME norm

[0147] Where CE represents the relevance of the traffic event corresponding to the source IP address; ME norm This represents the ratio of the average event percentage change to the maximum event percentage change corresponding to the source IP address, and also represents the normalized average event percentage change; 1 represents the second preset value.

[0148] The richness of the above event types can be determined in the following way:

[0149] Within the subset of event logs corresponding to the source IP address, determine the total number of event logs and the number of logs corresponding to each event type ID.

[0150] In this embodiment of the application, the specific method for determining the total number of event logs is the same as the specific method for calculating the number of event logs mentioned above. Both are determined based on the number of deduplicated session IDs, and will not be repeated here.

[0151] The method for determining the number of logs corresponding to each event type ID can be as follows: First, group the event log subsets corresponding to the source IP address based on the event type ID, so that each event type ID corresponds to a sub-event log subset. Then, within the sub-event log subset corresponding to the event type ID, determine the number of logs in the sub-event log subset corresponding to that event type ID based on the deduplicated session ID, thus obtaining the number of logs corresponding to that event type ID.

[0152] Next, the event type richness corresponding to the source IP address is calculated based on the ratio between the sum of the number of logs corresponding to each event type ID and the third preset value, and the sum of the total number of event logs and the third preset value.

[0153] Specifically, first, the ratio between the sum of the number of logs corresponding to each event type ID and the third preset value, and the sum of the total number of event logs and the third preset value, is calculated. Then, the squares of these ratios are summed. The difference between the ninth preset value and this summed value is taken as the event type richness corresponding to the source IP address, thus making the event type richness more accurate. The ninth preset value can be 1. This process can be illustrated by the following formula:

[0154]

[0155] Where KE represents the richness of event types corresponding to the source IP address; EventID j This represents the event type ID in the event log subset corresponding to the source IP address; EventSet(IP) represents the event log subset corresponding to the source IP address; Cnt(EventID) j This indicates that in the subset of event logs corresponding to the source IP address, the event type ID equals the EventID. j The number of logs, i.e., EventID j The corresponding number of logs; SumCntEvent(IP) represents the total number of event logs in the event log subset corresponding to the source IP address; θ3 represents the third preset value, which can be 0.01, but is not limited to this.

[0156] In this embodiment of the application, the specific fusion method for obtaining the traffic event index corresponding to the source IP address by fusing the proportion of traffic events, the correlation of traffic events, and the richness of event types can be as follows:

[0157] The product of the square root of the product of the relevance of traffic events corresponding to the source IP address and the richness of event types, and the corresponding proportion of traffic events, is used as the traffic event index corresponding to that source IP address, thus making the determined traffic event index more accurate. This process can be represented by the following formula:

[0158]

[0159] Here, IE represents the traffic event index corresponding to the source IP address. Therefore, this traffic event index is a parameter reflecting the correlation between traffic and attack events.

[0160] Taking a source IP address as an example, the specific process of determining the abnormal request index corresponding to that source IP address based on the subset of traffic logs can be as follows:

[0161] Based on the subset of traffic logs corresponding to the source IP address, the percentage of abnormal requests, the relevance of abnormal requests, and the richness of response code types corresponding to that source IP address are calculated. Then, the percentage of abnormal requests, the relevance of abnormal requests, and the richness of response code types are combined to obtain the abnormal request index corresponding to that source IP address, thereby making the abnormal request index more accurate.

[0162] The percentage of abnormal requests mentioned above can be determined in the following way:

[0163] First, within each time window, calculate the percentage of requests with multiple abnormal response codes corresponding to the source IP address, and then perform a weighted sum of these percentages to obtain the percentage of sub-abnormal requests for that source IP address within the corresponding time window. The length of this time window is the same as the length of the time window in the aforementioned process for calculating the percentage of traffic events, and can both be Δt.

[0164] In this embodiment of the application, the percentage of multiple abnormal response code requests includes a first abnormal response code request percentage, a second abnormal response code request percentage, a third abnormal response code request percentage, and a fourth abnormal response code request percentage.

[0165] The percentage of requests with the first exception response code is the percentage of requests corresponding to the first exception response code. The first exception response code is a response code that starts with 3, such as 301, 302, 303, 304, etc.

[0166] The percentage of requests with the second exception response code is the percentage of requests corresponding to the second exception response code. This second exception response code is a response code that starts with 4, such as 401, 402, 403, 404, etc.

[0167] The percentage of requests with the third exception response code is the percentage of requests corresponding to the third exception response code. This third exception response code is a response code that starts with 5, such as 501, 502, 503, 504, etc.

[0168] The percentage of requests with the fourth exception response code is the percentage of requests corresponding to the fourth exception response code. This fourth exception response code is an extended exception response code, such as 102, 104, etc. This extended response code can be adjusted according to the specific application.

[0169] The specific calculation process for the proportion of requests with the first exception response code mentioned above can be described as follows:

[0170] First, determine the first exception response code set. This first exception response code set includes all first exception response codes, such as Code3Set{300,301,302…399}.

[0171] Then, from the traffic log subset corresponding to the source IP address, extract the traffic logs whose time is within the corresponding time window and whose response code belongs to the first abnormal response code in the first abnormal response code set. This traffic log is the abnormal traffic log. The extracted traffic log (i.e., abnormal traffic log) is saved as the first abnormal response code traffic log set, such as FlowCode3Set(IP1).

[0172] Next, calculate the number of logs in the first abnormal response code traffic log set (i.e., the number of abnormal traffic logs). The calculation method for this number of logs is the same as the calculation method for the number of traffic logs mentioned above, and will not be repeated here.

[0173] Next, the ratio between the sum of the number of logs in the first abnormal response code traffic log set (i.e., the number of abnormal traffic logs corresponding to the first abnormal response code) and the tenth preset value, and the sum of the number of traffic logs and the tenth preset value, is used as the proportion of requests for the first abnormal response code, thus making the proportion of requests for the first abnormal response code more accurate. This process can be represented by the following formula:

[0174]

[0175] Where Q1 represents the percentage of requests with the first abnormal response code from the source IP address within the corresponding time window; CntFlowCode3(IP) represents the number of logs in the first abnormal response code traffic log set (i.e., the number of abnormal traffic logs corresponding to the first abnormal response code); θ 10 This represents the tenth preset value, which can be 0.01.

[0176] In the embodiments of this application, the calculation process of the proportion of the second abnormal response code request, the proportion of the third abnormal response code request, and the proportion of the fourth abnormal response code request is the same as the calculation process of the proportion of the first abnormal response code request, and will not be repeated here.

[0177] Specifically, in calculating the proportion of requests for the second exception response code, the determined set of second exception response codes includes all second exception response codes, such as Code4Set{400,401,402…499}. In calculating the proportion of requests for the third exception response code, the determined set of third exception response codes includes all third exception response codes, such as Code5Set{500,501,502…599}. In calculating the proportion of requests for the fourth exception response code, the determined set of fourth exception response codes includes all fourth exception response codes, such as CodeXSet{102,104…}.

[0178] The above weighted summation of the proportions of multiple abnormal response codes yields the proportion of sub-abnormal requests from the source IP address within the corresponding time window, as shown in the following formula:

[0179] PC v = w1×Q1+w2×Q2+w3×Q3+w4×Q4

[0180] Among them, PC v Q1 represents the percentage of sub-abnormal requests from the source IP address within the corresponding time window; Q2 represents the percentage of second abnormal response code requests from the source IP address within the corresponding time window; Q3 represents the percentage of third abnormal response code requests from the source IP address within the corresponding time window; Q4 represents the percentage of fourth abnormal response code requests from the source IP address within the corresponding time window; w1 represents the weight of the percentage of first abnormal response code requests, where w1∈[0,1] and the default value is 0.15; w2 represents the weight of the percentage of second abnormal response code requests, where w2∈[0,1] and the default value is 0.5; w3 represents the weight of the percentage of third abnormal response code requests, where w3∈[0,1] and the default value is 0.3; w4 represents the weight of the percentage of fourth abnormal response code requests, where w4∈[0,1] and the default value is 0.05.

[0181] The weights w1, w2, w3, and w4 mentioned above can be adjusted according to the system situation, but the sum of w1, w2, w3, and w4 is 1, that is, w1 + w2 + w3 + w4 = 1.

[0182] Using the above method, after calculating the proportion of abnormal requests for each source IP address within each time window, the average of the proportions of abnormal requests for each source IP address is taken as the proportion of abnormal requests for that source IP address, as shown in the following formula:

[0183]

[0184] Where PC represents the average percentage of abnormal requests from a source IP address within each time window, and also represents the percentage of abnormal requests corresponding to that source IP address; PC vi This indicates the percentage of sub-abnormal requests corresponding to the source IP address within the i-th time window.

[0185] The relevance of the above-mentioned abnormal requests can be determined in the following way:

[0186] First, for the source IP address, calculate the change in the percentage of abnormal requests for the corresponding time window based on the percentage of abnormal requests for each of the two adjacent time windows.

[0187] In this embodiment of the application, the change in the percentage of abnormal requests is the magnitude of the change in the percentage of abnormal requests between two adjacent time windows within a unit of time.

[0188] Therefore, the above calculation of the change in the proportion of abnormal requests for the corresponding time window based on the proportion of sub-abnormal requests for each of two adjacent time windows can be summarized as follows:

[0189] Calculate the absolute value of the difference between the percentages of sub-abnormal requests corresponding to two adjacent time windows, and use the ratio of this absolute value to the duration of the time window as the magnitude of change in the percentage of abnormal requests within the corresponding time window. This makes the calculated magnitude of change in the percentage of abnormal requests more accurate, thus making the abnormal request relevance obtained based on this magnitude of change more precise. The calculation process for this magnitude of change in the percentage of abnormal requests can be shown in the following formula:

[0190]

[0191] Where MC represents the change in the proportion of abnormal requests from the corresponding source IP address between the (i-1)th and ith time windows; PC v(i-1) This represents the percentage of sub-abnormal requests for the corresponding source IP address within the (i-1)th time window.

[0192] Next, the average of the changes in the proportion of multiple abnormal requests corresponding to a source IP address is calculated to obtain the average change in the proportion of abnormal requests corresponding to that source IP address. This integrates the changes in the proportion of abnormal requests within various time windows, which helps to further improve the accuracy of abnormal request correlation. The calculation process for this average change in the proportion of abnormal requests can be shown in the following formula:

[0193]

[0194] in, This indicates the change in the average percentage of abnormal requests corresponding to the source IP address.

[0195] At the same time, determine the maximum percentage change in the proportion of abnormal requests corresponding to the source IP address.

[0196] Due to PC v The range of values ​​for PC is: v If ∈[0,1], then PC v The maximum value is 1, PC v The minimum value is 0, and therefore the maximum value of the change in the percentage of abnormal requests (i.e., the maximum change in the percentage of abnormal requests) is:

[0197]

[0198] Where max(MC) represents the maximum percentage change in the proportion of abnormal requests corresponding to the source IP address.

[0199] Furthermore, the fourth preset value, the difference between the ratio of the average change in the proportion of abnormal requests corresponding to the same source IP address and the ratio of the largest change in the proportion of abnormal requests, is used as the abnormal request relevance corresponding to the source IP address. This fourth preset value can be 1. This process can be illustrated by the following formula:

[0200]

[0201] CC = 1 - MC norm

[0202] Where CC indicates the relevance of the abnormal request corresponding to the source IP address; MC norm This represents the ratio of the average percentage change in the proportion of abnormal requests corresponding to the source IP address to the maximum percentage change in the proportion of abnormal requests, and also represents the normalized average percentage change in the proportion of abnormal requests; 1 represents the fourth preset value.

[0203] The richness of the above response code types can be determined in the following way:

[0204] Within the subset of traffic logs corresponding to the source IP address, determine the total number of traffic logs and the number of logs corresponding to each response code.

[0205] In this embodiment of the application, the specific method for determining the total number of traffic logs is the same as the specific method for calculating the number of traffic logs, which is determined based on the number of deduplicated session IDs, and will not be repeated here.

[0206] The above method for determining the number of logs corresponding to each response code can be as follows: First, group the traffic log subsets corresponding to the source IP address based on the response code, so that each response code corresponds to a sub-traffic log subset. Then, within the sub-traffic log subset corresponding to the response code, determine the number of logs in the sub-traffic log subset corresponding to that response code based on the deduplicated session ID, thereby obtaining the number of logs corresponding to that response code.

[0207] Next, the response code type richness corresponding to the source IP address is calculated based on the ratio between the number of logs corresponding to each response code and the total number of traffic logs.

[0208] Specifically, first, the ratio between the number of logs corresponding to each response code and the total number of traffic logs is calculated. Then, the squares of these ratios are summed, and the eleventh preset value, along with this summed value, is used as the response code type richness corresponding to the source IP address, thus making the response code type richness more accurate. This eleventh preset value can be 1. The process can be illustrated by the following formula:

[0209]

[0210] Where KC represents the richness of response code types corresponding to the source IP address; code k This represents the response codes in the subset of traffic logs corresponding to the source IP address; all represents all response codes; Cnt(code) k This indicates that in the subset of traffic logs corresponding to the source IP address, the response code is equal to 'code'. k The number of logs; SumCntFlow(IP) represents the total number of traffic logs in the subset of traffic logs corresponding to the source IP address.

[0211] In this embodiment of the application, the specific fusion method for obtaining the abnormal request index corresponding to the source IP address by combining the abnormal request ratio, abnormal request relevance, and response code type richness can be as follows:

[0212] The square root of the product of the relevance of abnormal requests corresponding to the source IP address and the richness of response code types, multiplied by the corresponding proportion of abnormal requests, is used as the abnormal request index corresponding to the source IP address, thus making the determined abnormal request index more accurate. This process can be represented by the following formula:

[0213]

[0214] Here, IC represents the abnormal request index corresponding to the source IP address. Therefore, this abnormal request index is a parameter reflecting the correlation between traffic and abnormal requests, which are the traffic corresponding to abnormal response codes.

[0215] Therefore, the traffic event index and abnormal request index corresponding to each source IP address can be calculated using the above method.

[0216] Furthermore, after calculating the traffic event index and abnormal request index corresponding to each source IP address in step S202, the behavioral risk index corresponding to the source IP address is determined based on the traffic event index and abnormal request index.

[0217] Specifically, firstly, the weights of the target traffic event index and the target abnormal request index are determined. Then, for each source IP address, the sum of the product of the corresponding traffic event index and the target traffic event index weight, and the sum of the product of the corresponding abnormal request index and the target abnormal request index weight, is used as the behavioral risk index for that source IP address. This ensures that the behavioral risk index for the source IP address considers the impact of both the traffic event index and the abnormal request index on IP behavioral risk, thus making the behavioral risk index for the source IP address more accurate.

[0218] Taking the time period (t0, t0+N) as an example, the specific process for determining the behavioral risk index corresponding to a source IP address during this process can be illustrated by the following formula:

[0219] RiskIndex(IP, t0) = ω E ×IE+ω C ×IC

[0220] Where RiskIndex(IP, t0) represents the behavioral risk index of the source IP address within the time period (t0, t0+N); ω E ω represents the target traffic event index weight; C This represents the target abnormal request index weight.

[0221] In this embodiment of the application, the target traffic event index weight and the target abnormal request index weight can be determined by iterative training of the traffic event index weight and the abnormal request index weight.

[0222] Specifically, the first step is to acquire training data. This training data includes multiple historical traffic logs and multiple historical event logs. Then, each source IP address in the multiple historical traffic logs and multiple historical event logs is labeled as exhibiting malicious or normal behavior.

[0223] In this embodiment, before marking each source IP address in multiple historical traffic logs and multiple historical event logs as either malicious or normal behavior, the multiple historical traffic logs and multiple historical event logs can first be divided into a historical traffic log set and a historical event log set, each with a time length of N. Then, each source IP address in the multiple historical traffic log set and the multiple historical event log set is marked as either malicious or normal behavior. For example, a source IP address exhibiting normal behavior is marked as an IP address exhibiting malicious behavior. w Mark the source IP address of the malicious behavior as an IP address. b The set of source IP addresses for normal behavior is: {IP w1 IP w2 IP w3 The set of source IP addresses for malicious behavior is: IP... b {IP b1 IP b2 IP b3 , ...}.

[0224] Next, the risk index value corresponding to the source IP address marked as malicious behavior is determined to be the fifth preset value, and the risk index value corresponding to the source IP address marked as normal behavior is determined to be the sixth preset value. The fifth preset value can be 1, and the sixth preset value can be 0. That is, RiskIndex(IP b ) = 1, RiskIndex(IP b2 ) = 1, RiskIndex(IP b3 RiskIndex(IP) = 1, ... w1 ) = 0, RiskIndex(IP w2 ) = 0, RiskIndex(IP w3 ) = 0, ...

[0225] Then, initialize the event index weights and the abnormal request index weights. For example, set the initial value of the event index weight to 0.5 and the initial value of the abnormal request index weight to 0.5.

[0226] Then, based on the initialized event index weights and abnormal request index weights, calculate the historical behavior risk index corresponding to each source IP address in multiple historical traffic log sets and multiple historical event log sets.

[0227] The calculation process of this historical behavior risk index is the same as the calculation process of the behavior risk index of the source IP address within the time period (t0, t0+N). The specific calculation process of the historical traffic event index and the historical abnormal request index corresponding to the source IP address in the historical risk index calculation process is the same as the specific calculation process of the traffic event index and the abnormal request index corresponding to the source IP address in the aforementioned step S202, and will not be repeated here.

[0228] Furthermore, based on the historical behavior risk index and corresponding behavior risk index label value corresponding to each source IP address in multiple historical traffic logs and multiple historical event logs (e.g., if the source IP address is marked as malicious behavior, the behavior risk index label value is 1; if the source IP address is marked as normal behavior, the behavior risk index label value is 0), the event index weight and abnormal request index weight are iteratively trained to obtain the target event index weight and target abnormal request index weight.

[0229] However, it should be noted that during the training process of the event index weights and abnormal request index weights, when the historical behavior risk index corresponding to the source IP address is calculated for the first time, ω E With ω C The initial event index weights and abnormal request index weights can be used for calculation, and the event index weights and abnormal request index weights obtained during the training process can be used for subsequent calculations.

[0230] In this embodiment, the loss function used in the iterative training process of the event index weight and the abnormal request index weight can be the cross-entropy loss function, the mean squared error loss function, etc., and the specific loss function can be selected according to the specific application scenario.

[0231] The iterative optimization algorithm used in the iterative training process of the event index weight and the abnormal request index weight can be gradient descent algorithm, stochastic gradient descent algorithm, etc., and the specific iterative optimization algorithm can be selected according to the specific application scenario.

[0232] The aforementioned historical behavioral risk index can represent the predicted value calculated in the loss function, while the behavioral risk index marker value (such as the fifth preset value and the sixth preset value) can represent the actual value in the loss function.

[0233] Furthermore, after calculating the behavioral risk index corresponding to each source IP address, the risk associated with the corresponding source IP address can be assessed based on this behavioral risk index.

[0234] Since the behavioral risk index can represent the degree of abnormality of the source IP address's behavior within the time period to be analyzed (e.g., (t0, t0+N)), the larger the value of the behavioral risk index, the more abnormal the behavior of the source IP address and the higher the potential risk.

[0235] Optionally, the behavioral risk index can be compared with the risk index threshold to classify the risk level of the corresponding source IP address.

[0236] For example, if the behavioral risk index is determined to be less than the first risk index threshold, then the risk level of the corresponding IP address is determined to be low.

[0237] If the behavioral risk index is determined to be greater than or equal to the first risk index threshold and less than the second risk index threshold, then the risk level of the corresponding IP address is determined to be medium risk.

[0238] If the behavioral risk index is determined to be greater than or equal to the second risk index threshold, then the corresponding IP address is determined to be of high risk level.

[0239] The threshold for the first risk index is lower than the threshold for the second risk index.

[0240] Furthermore, in this embodiment, if the duration of multiple traffic logs and event logs output by the system to be analyzed exceeds N, the multiple traffic logs and event logs are first divided into multiple sets of traffic logs and multiple sets of event logs, each with a duration of N (or not greater than N). This ensures that the duration of each set of traffic logs and each set of event logs does not exceed N, thus better addressing the timeliness issue of the data. Then, for each set of traffic logs and each set of event logs, steps S201-S203 are executed to obtain the corresponding behavioral risk index of the source IP address. Finally, the maximum value of the behavioral risk index for the same source IP address among the multiple sets of traffic logs and multiple sets of event logs is taken, and this maximum value is used as the behavioral risk index of the corresponding source IP address during the time period to be analyzed.

[0241] For example, the duration of multiple traffic logs and event logs output by the system to be analyzed is 3N. These multiple traffic logs and event logs are then divided into three sets: the first set of traffic logs and the first set of event logs have times within the time interval (t0, t0+N); the second set of traffic logs and the second set of event logs have times within the time interval (t0+N, t0+2N); and the third set of traffic logs and the third set of event logs have times within the time interval (t0+2N, t0+3N). Then, for each set of traffic logs and each set of event logs, the behavioral risk index of each source IP address is obtained through the aforementioned steps S201-S203.

[0242] If the source IP address of IP1 exists in all three traffic log sets and the event log set, then three behavioral risk indices will be calculated for this IP1: RiskIndex(IP1, t0), RiskIndex(IP1, t0+N), and RiskIndex(IP1, t0+2N). The maximum value among these three behavioral risk indices will then be used as the behavioral risk index for the source IP1 address within the analyzed time period. This makes the behavioral risk index for the source IP1 address more accurate, and using the maximum value among multiple behavioral risk indices can minimize false positives for IP1's behavioral risks, thereby improving network security.

[0243] However, it should be noted that in the aforementioned training process, after dividing multiple historical traffic logs and multiple historical event logs into sets of historical traffic logs and historical event logs with a time length of N according to N, when calculating the historical behavior risk index corresponding to each source IP address, the historical behavior risk index calculated in each time period (such as the time period (t0, t0+N) and the time period (t0+N, t0+2N)) is a sample value corresponding to the source IP address. All of these need to be input into the iterative optimization algorithm to train the traffic event index weight and the abnormal request index weight. It is not necessary to take the maximum value of the historical behavior risk index corresponding to the same source IP address in multiple time periods (such as the time period (t0, t0+N) and the time period (t0+N, t0+2N)).

[0244] In summary, the risk assessment method proposed in this application utilizes a traffic log set and an event log set (i.e., a set of attack event logs) to calculate the proportion of events (i.e., attack events) in the traffic (i.e., the traffic event proportion). It further analyzes the magnitude of the event proportion variable to obtain the traffic event correlation. Combined with the distribution of various events in the event log set, it analyzes the richness of event types. Finally, it integrates the traffic event proportion, traffic event correlation, and event type richness to calculate the traffic event index corresponding to the source IP address. This makes the traffic event index more accurate and enables a comprehensive evaluation of IP attack behavior from the perspective of the distribution of attack events in the traffic.

[0245] Furthermore, by utilizing a traffic log set, the proportion of abnormal response codes in the traffic from the source IP address is analyzed (i.e., the proportion of abnormal requests). The trend of abnormal response code changes (i.e., the magnitude of changes in the proportion of abnormal requests) is further analyzed to obtain the relevance of abnormal requests. The distribution of various response codes in the traffic log set is further analyzed to obtain the richness of response code types. Then, the proportion of abnormal requests, the relevance of abnormal requests, and the richness of response code types are integrated to calculate the abnormal request index corresponding to the source IP address. This makes the abnormal request index more accurate and enables a comprehensive evaluation of IP attack behavior from the perspective of the distribution of abnormal requests in the traffic.

[0246] By combining the calculated traffic event index and abnormal request index, the behavioral risk index corresponding to the source IP address is calculated. This allows for a comprehensive evaluation of IP attack behavior from the perspective of abnormal request distribution in traffic, and the corresponding behavioral risk index is calculated, making the behavioral risk index more accurate.

[0247] Furthermore, this application embodiment utilizes a set of traffic logs output by the system to be analyzed for N consecutive hours and a set of event logs including logs of attack events to perform risk assessment analysis. This avoids the problem of expired information related to the source IP address (such as traffic log data and event log data) and the quality problem of information related to the source IP address, thereby solving the timeliness and quality problems of data and making the risk assessment results of the source IP address more accurate.

[0248] Furthermore, in this embodiment of the application, based on the above steps S201-S203, an IP behavior risk model can be constructed. The IP behavior risk model includes a traffic event analysis module that calculates the traffic event index corresponding to the source IP address using the method in step S202 above, an abnormal request analysis module that calculates the abnormal request index corresponding to the source IP address, and a fusion module that merges the traffic event index and the abnormal request index in step S203 above.

[0249] like Figure 3 As shown, the IP behavior risk model includes an abnormal request analysis module, a traffic event analysis module, and a fusion module.

[0250] First, in the data preprocessing module, the multiple historical HTTP raw traffic logs and multiple historical HTTP attack event logs in the training data are divided into multiple sets of historical HTTP raw traffic logs and sets of historical HTTP attack event logs, each with a time length of N (or no greater than N). Then, for each set of historical HTTP raw traffic logs and each set of historical HTTP attack event logs, the subsequent steps are performed.

[0251] Based on the source IP address, the historical HTTP raw traffic log set and the historical HTTP attack event log set are grouped to obtain multiple historical HTTP raw traffic log subsets and multiple historical HTTP attack event log subsets.

[0252] Furthermore, in the training preprocessing module, each source IP address in multiple subsets of historical HTTP raw traffic logs and multiple subsets of historical HTTP attack event logs is marked as either exhibiting malicious or normal behavior. The behavior risk index value corresponding to a source IP address marked as exhibiting malicious behavior is determined to be 1, while the behavior risk index value corresponding to a source IP address marked as exhibiting normal behavior is determined to be 0. Additionally, the event index weights and abnormal request index weights are initialized to 0.5.

[0253] Then, in the abnormal request analysis module, for each source IP address, based on the corresponding subset of historical HTTP raw traffic logs, the corresponding abnormal request ratio, abnormal request relevance, and response code type richness are analyzed and calculated. The abnormal request ratio, abnormal request relevance, and response code richness are then integrated to obtain the abnormal request index corresponding to the source IP address.

[0254] Meanwhile, in the traffic event analysis module, for each source IP address, based on the corresponding subset of historical HTTP raw traffic logs and subset of historical HTTP attack event logs, the corresponding traffic event percentage, traffic event relevance, and event type richness are analyzed and calculated. Then, the traffic event percentage, traffic event relevance, and event type richness are integrated to obtain the traffic event index corresponding to the source IP address.

[0255] Next, in the fusion module, the corresponding historical behavior risk index is calculated based on the traffic event index and abnormal request index corresponding to each source IP address, as well as the event index weight and abnormal request index weight.

[0256] Then, in the training module, based on the historical behavioral risk index and the behavioral risk index label value, the event index weight and the abnormal request index weight are iteratively trained to obtain the target event index weight and the target abnormal request index weight, thereby realizing the training of the IP behavioral risk model. The trained model is the target IP behavioral risk model.

[0257] Finally, in the evaluation module, the logs to be analyzed from the system under analysis (such as raw HTTP traffic logs and HTTP attack event logs) are preprocessed by the data preprocessing module to obtain multiple subsets of raw HTTP traffic logs and HTTP attack event logs. These subsets are then input into the target IP behavior risk model. The abnormal request analysis module, traffic event analysis module, and fusion module within the target IP behavior risk model process these subsets to obtain a behavior risk index corresponding to each source IP address. This behavior risk index allows for risk assessment of the source IP address.

[0258] By utilizing traffic and event log data related to source IP addresses, and analyzing the correlation between traffic and events (such as traffic event index) and abnormal request patterns (such as abnormal request index) within the source IP addresses, an IP behavior risk model was constructed. This model enables real-time assessment of source IP addresses, enhances the adaptability of the IP behavior risk model to different system environments, and effectively compensates for the uncertainty caused by data quality and timeliness issues in external intelligence data. It avoids interference from the quality of external intelligence data sources, improves the universality and accuracy of the IP behavior assessment model, and ultimately enhances the effectiveness of source IP address risk assessment results, providing a data foundation for building a high-quality threat intelligence database for IP.

[0259] Based on the same inventive concept, this application also provides a risk assessment device, such as... Figure 4 The diagram shown is a structural schematic of a risk assessment device provided in this application. The device includes:

[0260] The acquisition module 401 is used to acquire a set of traffic logs and an event log set output by the system to be analyzed for a continuous period of N hours; wherein, the event logs in the event log set are logs of attack events; both the traffic log set and the event log set include the source Internet Protocol IP address; N is a positive number;

[0261] The calculation module 402 is used to calculate the traffic event index and abnormal request index corresponding to each source IP address based on the traffic log set and the event log set; wherein the traffic event index is a parameter reflecting the correlation between traffic and attack events, and the abnormal request index is a parameter reflecting the correlation between traffic and abnormal requests.

[0262] The processing module 403 is used to determine the behavioral risk index corresponding to each source IP address based on the traffic event index and the abnormal request index corresponding to each source IP address, and to assess the risk of the corresponding source IP address based on the behavioral risk index.

[0263] In one possible implementation, the calculation module 402 is specifically configured to: divide the traffic logs in the traffic log set into multiple traffic log subsets and the event logs in the event log set into multiple event log subsets, using the source IP address as the grouping condition; calculate the traffic event proportion and traffic event relevance corresponding to each source IP address based on each traffic log subset and each event log subset; calculate the event type richness corresponding to each source IP address based on each event log subset; and fuse the traffic event proportion, traffic event relevance, and event type richness to obtain the traffic event index corresponding to the corresponding source IP address; and calculate the abnormal request proportion, abnormal request relevance, and response code type richness corresponding to each source IP address based on each traffic log subset; and fuse the abnormal request proportion, abnormal request relevance, and response code type richness to obtain the abnormal request index corresponding to the corresponding source IP address.

[0264] In one possible implementation, the calculation module 402 is further configured to determine, within each time window, the number of traffic logs in the traffic log subset corresponding to each source IP address, and the number of event logs in the corresponding event log subset; wherein, the length of the time window is a preset duration; the ratio of the sum of the number of event logs and a first preset value to the sum of the number of traffic logs and the first preset value is used as the proportion of sub-traffic events of the corresponding source IP address within the corresponding time window; and the average value among the proportions of multiple sub-traffic events corresponding to each source IP address is used as the proportion of the corresponding traffic event.

[0265] In one possible implementation, the calculation module 402 is further configured to, for each source IP address, calculate the change magnitude of the event proportion corresponding to the corresponding time window based on the proportion of sub-traffic events corresponding to each of two adjacent time windows; calculate the average value among the multiple event proportion change magnitudes corresponding to each source IP address to obtain the average event proportion change magnitude corresponding to the corresponding source IP address; and determine the maximum event proportion change magnitude corresponding to each source IP address; and use the difference between the second preset value and the ratio of the average event proportion change magnitude to the maximum event proportion change magnitude as the relevance of the traffic event corresponding to the corresponding source IP address.

[0266] In one possible implementation, the calculation module 402 is further configured to, for each source IP address, determine the total number of event logs and the number of logs corresponding to each event type identification code ID in the corresponding event log subset; and calculate the event type richness corresponding to the corresponding source IP address based on the ratio between the sum of the number of logs corresponding to each event type ID and a third preset value and the sum of the total number of event logs and the third preset value.

[0267] In one possible implementation, the calculation module 402 is further configured to, for each source IP address, multiply the square root of the product of the corresponding traffic event relevance and the event type richness by the corresponding traffic event proportion, as the traffic event index corresponding to the corresponding source IP address.

[0268] In one possible implementation, the calculation module 402 is further configured to, for each source IP address, calculate the proportion of multiple abnormal response code requests within each time window, and perform a weighted summation of the multiple abnormal response code request proportions to obtain the sub-abnormal request proportion of the corresponding source IP address within the corresponding time window; wherein, the abnormal response code request proportion is obtained based on the number of abnormal traffic logs and the number of traffic logs; the abnormal traffic logs are traffic logs in the subset of traffic logs whose response codes are abnormal response codes and whose times are within the corresponding time window; for each source IP address, the average value among the sub-abnormal request proportions corresponding to each of the time windows is taken as the abnormal request proportion corresponding to the corresponding source IP address.

[0269] In one possible implementation, the calculation module 402 is further configured to, for each source IP address, calculate the change magnitude of the abnormal request proportion corresponding to the corresponding time window based on the proportion of sub-abnormal requests corresponding to each of two adjacent time windows; calculate the average value among the multiple abnormal request proportion change magnitudes corresponding to each source IP address to obtain the average abnormal request proportion change magnitude corresponding to the corresponding source IP address; and determine the maximum abnormal request proportion change magnitude corresponding to each source IP address; and use the difference between the fourth preset value and the ratio of the average abnormal request proportion change magnitude to the maximum abnormal request proportion change magnitude as the abnormal request relevance corresponding to the corresponding source IP address.

[0270] In one possible implementation, the calculation module 402 is further configured to, for each source IP address, determine the total number of traffic logs and the number of logs corresponding to each response code in the corresponding subset of traffic logs; and calculate the response code type richness corresponding to the corresponding source IP address based on the ratio between the number of logs corresponding to each response code and the total number of traffic logs.

[0271] In one possible implementation, the calculation module 402 is further configured to, for each source IP address, multiply the square root of the product of the corresponding abnormal request relevance and the response code type richness by the corresponding abnormal request proportion, as the abnormal request index corresponding to the corresponding source IP address.

[0272] In one possible implementation, the processing module 403 is specifically used to determine the target traffic event index weight and the target abnormal request index weight; for each source IP address, the sum of the product of the corresponding traffic event index and the target traffic event index weight, and the product of the corresponding abnormal request index and the target abnormal request index weight, is used as the behavioral risk index corresponding to the corresponding source IP address.

[0273] In one possible implementation, the processing module 403 is further configured to acquire training data; wherein the training data includes multiple historical traffic logs and multiple historical event logs; mark each source IP address in the multiple historical traffic logs and multiple historical event logs as either malicious or normal behavior, and determine that the behavior risk index mark value corresponding to the source IP address marked as malicious behavior is a fifth preset value, and the behavior risk index mark value corresponding to the source IP address marked as normal behavior is a sixth preset value; initialize event index weights and abnormal request index weights; calculate the historical behavior risk index corresponding to each source IP address in the multiple historical traffic logs and multiple historical event logs based on the initialized event index weights and abnormal request index weights; iteratively train the event index weights and abnormal request index weights based on the historical behavior risk index corresponding to each source IP address in the multiple historical traffic logs and multiple historical event logs and the corresponding behavior risk index mark value, to obtain the target event index weights and the target abnormal request index weights.

[0274] Based on the same inventive concept, this application also provides an electronic device that can realize the functions of the aforementioned risk assessment device. (Refer to...) Figure 5 The aforementioned electronic devices include:

[0275] At least one processor 501 and a memory 502 connected to at least one processor 501. In this embodiment, the specific connection medium between the processor 501 and the memory 502 is not limited. Figure 5 The example shown is the connection between processor 501 and memory 502 via bus 500. Bus 500 is... Figure 5 The connections between other components are indicated by thick lines and are for illustrative purposes only, not as limiting information. The Bus 500 can be divided into address bus, data bus, control bus, etc., for ease of representation. Figure 5 The term 501 is represented by a single thick line, but this does not imply that there is only one bus or one type of bus. Alternatively, the processor 501 can also be called a controller; there is no restriction on the name.

[0276] In this embodiment, memory 502 stores instructions executable by at least one processor 501. By executing the instructions stored in memory 502, at least one processor 501 can perform the risk assessment method described above. Processor 501 can implement... Figure 4 The functions of each module in the device shown.

[0277] The processor 501 is the control center of the device. It can connect to various parts of the control device through various interfaces and lines. By running or executing instructions stored in memory 502 and calling data stored in memory 502, the processor can perform various functions and process data, thereby monitoring the device as a whole.

[0278] In one possible design, processor 501 may include one or more processing units. Processor 501 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may also not be integrated into processor 501. In some embodiments, processor 501 and memory 502 may be implemented on the same chip; in some embodiments, they may also be implemented on separate chips.

[0279] Processor 501 can be a general-purpose processor, such as a central processing unit (CPU), digital signal processor, application-specific integrated circuit, field-programmable gate array or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the risk assessment method disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0280] Memory 502, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory 502 may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic memory, magnetic disk, optical disk, etc. Memory 502 can be any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited thereto. In the embodiments of this application, memory 502 can also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0281] By designing and programming the processor 501, the code corresponding to the risk assessment method described in the foregoing embodiments can be embedded into the chip, enabling the chip to execute it during operation. Figure 2 The steps of the risk assessment method in the illustrated embodiment are as follows. How to design and program the processor 501 is a technique well-known to those skilled in the art and will not be described further here.

[0282] Based on the same inventive concept, embodiments of this application also provide a storage medium storing computer instructions that, when executed on a computer, cause the computer to perform the risk assessment method described above.

[0283] In some possible implementations, various aspects of the risk assessment method provided in this application may also be implemented in the form of a program product, which includes program code that, when the program product is run on a device, causes the control device to perform the steps in the risk assessment method according to the various exemplary embodiments of this application described above.

[0284] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0285] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0286] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0287] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0288] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A risk assessment method, characterized in that, include: Obtain a set of traffic logs and an event log set output by the system to be analyzed for a continuous period of N hours; wherein, the event logs in the event log set are logs of attack events; both the traffic log set and the event log set include the source Internet Protocol IP address; N is a positive number; Using the source IP address as the grouping condition, the traffic logs in the traffic log set are divided into multiple traffic log subsets, and the event logs in the event log set are divided into multiple event log subsets; Based on each of the traffic log subsets and event log subsets, the proportion of traffic events corresponding to the corresponding source IP address and the relevance of traffic events are calculated. Furthermore, based on each of the event log subsets, the richness of event types corresponding to the corresponding source IP address is calculated. These factors are then combined to obtain the traffic event index corresponding to the corresponding source IP address. The event type richness is a value calculated as the ratio of the total number of event logs in the event log subset to the number of logs corresponding to each event type identifier ID. The traffic event index is a parameter reflecting the correlation between traffic and attack events. For each subset of traffic logs, the percentage of abnormal requests, the relevance of abnormal requests, and the richness of response code types corresponding to the corresponding source IP address are calculated. The percentage of abnormal requests, the relevance of abnormal requests, and the richness of response code types are then combined to obtain the abnormal request index corresponding to the corresponding source IP address. The richness of response code types is a value calculated based on the ratio of the total number of traffic logs in the subset of traffic logs to the number of logs corresponding to each response code. The abnormal request index is a parameter reflecting the correlation between traffic and abnormal requests. Based on the traffic event index and the abnormal request index corresponding to each source IP address, a behavioral risk index corresponding to each source IP address is determined, and the risk of the corresponding source IP address is assessed based on the behavioral risk index.

2. The method as described in claim 1, characterized in that, The step of calculating the proportion of traffic events corresponding to the corresponding source IP address based on each of the traffic log subsets and each of the event log subsets includes: Within each time window, determine the number of traffic logs in the traffic log subset corresponding to each source IP address, and the number of event logs in the corresponding event log subset; wherein, the length of the time window is a preset duration; The ratio of the sum of the number of event logs and the first preset value to the sum of the number of traffic logs and the first preset value is used as the proportion of sub-traffic events of the corresponding source IP address within the corresponding time window. The average of the proportions of the multiple sub-traffic events corresponding to each source IP address is taken as the proportion of the corresponding traffic event.

3. The method as described in claim 1, characterized in that, The step of calculating the relevance of traffic events corresponding to the source IP address based on each subset of traffic logs and each subset of event logs includes: For each source IP address, based on the proportion of sub-traffic events corresponding to two adjacent time windows, calculate the change in the event proportion corresponding to the time window; and calculate the average of the multiple event proportion changes corresponding to each source IP address to obtain the average event proportion change for the corresponding source IP address; and Determine the maximum percentage change in the proportion of events corresponding to each source IP address; The difference between the second preset value and the ratio of the average event percentage change to the maximum event percentage change is used as the relevance of the traffic event corresponding to the source IP address.

4. The method as described in claim 1, characterized in that, The step of calculating the event type richness corresponding to the source IP address for each subset of event logs includes: For each source IP address, determine the total number of event logs and the number of logs corresponding to each event type ID in the corresponding event log subset; The event type richness corresponding to the source IP address is calculated based on the ratio between the sum of the number of logs corresponding to each event type ID and the third preset value, and the sum of the total number of event logs and the third preset value.

5. The method as described in claim 1, characterized in that, The process of integrating the proportion of traffic events, the relevance of traffic events, and the richness of event types to obtain the traffic event index corresponding to the source IP address includes: For each source IP address, the product of the square root of the product of the relevance of the traffic event and the richness of the event type, and the product of the proportion of the traffic event, is used as the traffic event index corresponding to the source IP address.

6. The method as described in claim 1, characterized in that, The step of calculating the percentage of abnormal requests corresponding to the source IP address for each subset of traffic logs includes: For each source IP address, within each time window, the proportion of requests with multiple abnormal response codes is calculated, and the proportions of multiple abnormal response code requests are weighted and summed to obtain the sub-abnormal request proportion of the corresponding source IP address within the corresponding time window; wherein, the abnormal response code request proportion is obtained based on the number of abnormal traffic logs and the number of traffic logs; the abnormal traffic logs are traffic logs in the subset of traffic logs whose response codes are abnormal and whose times are within the corresponding time window; For each source IP address, the average of the percentages of the sub-abnormal requests within each time window is taken as the percentage of abnormal requests corresponding to the source IP address.

7. The method as described in claim 1, characterized in that, The step of calculating the relevance of abnormal requests to the corresponding source IP address based on each subset of traffic logs includes: For each source IP address, based on the percentage of abnormal requests corresponding to each of two adjacent time windows, calculate the change in the percentage of abnormal requests for that time window; and calculate the average of the multiple percentage changes in the percentage of abnormal requests for each source IP address to obtain the average percentage change in the percentage of abnormal requests for that source IP address; and Determine the maximum percentage change in abnormal requests corresponding to each source IP address; The difference between the fourth preset value and the ratio of the average change in the proportion of abnormal requests to the maximum change in the proportion of abnormal requests is used as the abnormal request relevance corresponding to the source IP address.

8. The method as described in claim 1, characterized in that, The step of calculating the response code type richness corresponding to the source IP address for each subset of traffic logs includes: For each source IP address, determine the total number of traffic logs and the number of logs corresponding to each response code in the corresponding subset of traffic logs; The response code type richness corresponding to the source IP address is calculated based on the ratio between the number of logs corresponding to each response code and the total number of traffic logs.

9. The method as described in claim 1, characterized in that, The abnormal request index corresponding to the source IP address is obtained by integrating the abnormal request ratio, the abnormal request relevance, and the response code type richness, including: For each source IP address, the square root of the product of the corresponding abnormal request relevance and the response code type richness, and the product of the corresponding abnormal request proportion, are used as the abnormal request index corresponding to the source IP address.

10. The method as described in claim 1, characterized in that, The step of determining the behavioral risk index corresponding to each source IP address based on the traffic event index and the abnormal request index corresponding to each source IP address includes: Determine the target traffic event index weights and the target abnormal request index weights; For each source IP address, the sum of the product of the corresponding traffic event index and the target traffic event index weight, and the product of the corresponding abnormal request index and the target abnormal request index weight, is used as the behavioral risk index corresponding to the source IP address.

11. The method as described in claim 10, characterized in that, The determination of the target traffic event index weight and the target abnormal request index weight includes: Acquire training data; wherein, the training data includes multiple historical traffic logs and multiple historical event logs; For each source IP address in the multiple historical traffic logs and multiple historical event logs, malicious behavior and normal behavior are marked, and the behavior risk index mark value corresponding to the source IP address marked as malicious behavior is determined to be a fifth preset value, and the behavior risk index mark value corresponding to the source IP address marked as normal behavior is determined to be a sixth preset value; and Initialize the event index weights and abnormal request index weights; based on the initialized event index weights and abnormal request index weights, calculate the historical behavior risk index corresponding to each source IP address in the multiple historical traffic logs and the multiple historical event logs; Based on the historical behavior risk index and the corresponding behavior risk index label value corresponding to each source IP address in the multiple historical traffic logs and multiple historical event logs, the event index weight and the abnormal request index weight are iteratively trained to obtain the target traffic event index weight and the target abnormal request index weight.

12. A risk assessment device, characterized in that, include: The acquisition module is used to acquire a set of traffic logs and an event log set output by the system to be analyzed for a continuous period of N hours; wherein, the event logs in the event log set are logs of attack events; both the traffic log set and the event log set include the source Internet Protocol IP address; N is a positive number; The calculation module is used to divide the traffic logs in the traffic log set into multiple traffic log subsets and the event logs in the event log set into multiple event log subsets, using the source IP address as the grouping condition; calculate the proportion of traffic events and the relevance of traffic events corresponding to the corresponding source IP address for each traffic log subset and each event log subset; calculate the richness of event types corresponding to the corresponding source IP address for each event log subset; and fuse the proportion of traffic events, the relevance of traffic events, and the richness of event types to obtain the traffic event index corresponding to the corresponding source IP address; and calculate the anomaly corresponding to the corresponding source IP address for each traffic log subset. The abnormal request index is obtained by combining the abnormal request ratio, abnormal request relevance, and response code type richness, and integrating these three factors to obtain the abnormal request index corresponding to the source IP address. The event type richness is a value calculated as the ratio of the total number of event logs in the event log subset to the number of logs corresponding to each event type ID. The response code type richness is a value calculated as the ratio of the total number of traffic logs in the traffic log subset to the number of logs corresponding to each response code. The traffic event index is a parameter reflecting the correlation between traffic and attack events, and the abnormal request index is a parameter reflecting the correlation between traffic and abnormal requests. The processing module is used to determine the behavioral risk index corresponding to each source IP address based on the traffic event index and the abnormal request index corresponding to each source IP address, and to assess the risk of the corresponding source IP address based on the behavioral risk index.

13. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, when executing a computer program stored in the memory, implements the method steps of any one of claims 1-11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method described in any one of claims 1-11.

Images