A method and system for detecting abnormal API access behavior

By monitoring and analyzing cloud account API request data and using interquartile range to calculate the abnormal threshold range, the shortcomings of traditional methods in detecting abnormal API access behavior are solved, achieving efficient and accurate anomaly detection.

CN116668185BActive Publication Date: 2025-12-02HANGZHOU MORESEC TECH CO LTD
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
CN202310865396.5
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2023-07-13
Publication Date
2025-12-02
Estimated Expiration
2043-07-13

AI Technical Summary

Technical Problem

Traditional security measures are weak at monitoring abnormal access behavior at the API level, and cannot effectively detect abnormal API access behavior, threatening user privacy and data security.

Method used

By monitoring cloud account API request access data, grouping, statistically analyzing, sorting, and calculating interquartile ranges, the threshold range for different APIs called by each user is determined. The abnormal threshold is calculated using the interquartile range, and the threshold range is dynamically updated to detect abnormal access behavior.

Benefits of technology

It achieves high accuracy and low false positive rate in detecting abnormal API access behavior, with low detection time overhead and strong adaptability, providing a new approach to dynamic detection.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN116668185B_ABST
    Figure CN116668185B_ABST
Patent Text Reader

Abstract

This invention discloses a method and system for detecting abnormal API access behavior, relating to the field of network security technology. The method includes: monitoring cloud account API request access data, whereby the access data includes user ID, the name of the API accessed by the user, and the time the user accessed the API; statistically analyzing the access data according to a first preset time range to obtain a time statistics group; grouping the access data within the time statistics group by user ID to obtain one or more sub-user groups; sorting the access data of each sub-user group according to the frequency of access to the corresponding API within a second preset time range based on user ID and API name to obtain an access frequency sequence group; calculating the threshold range for different APIs called by each user based on the access frequency sequence group and a preset threshold, and determining the abnormal threshold based on the threshold range. This provides a new approach for detecting abnormal API access.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to a method and system for detecting abnormal API access behavior. Background Technology

[0002] With the rapid development of cloud-native technologies and the widespread adoption of cloud computing and web services, APIs (Application Programming Interfaces) have become a key component for data exchange and functional integration between applications. According to a Gartner report, 75% of enterprises use cloud-native containerized applications. Due to this shift in application architecture, while adhering to microservice-oriented design principles, issues such as functional componentization, a surge in the number of service APIs, and configuration complexity have arisen.

[0003] In recent years, API security issues have been on the rise. Malicious attackers may exploit APIs to steal sensitive information, disrupt system functions, or inject malicious code, seriously threatening user privacy and data security. Traditional security measures such as firewalls and intrusion detection systems (IDS) primarily focus on network-level security protection, with relatively weak monitoring of abnormal access behavior at the API level. However, API security is closely related to the overall security of the system; therefore, determining the presence of anomalies based on API access behavior is becoming increasingly important. Summary of the Invention

[0004] In order to overcome the shortcomings of at least one of the prior art, the present invention provides a method for detecting abnormal API access behavior.

[0005] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0006] A method for detecting abnormal API access behavior includes the following steps:

[0007] Monitor cloud account API request access data, including user ID, the name of the API accessed by the user, and the time the user accessed the API;

[0008] The access data is statistically analyzed based on the first preset time range to obtain time statistics groups;

[0009] The access data within the time statistics group is grouped by user ID to obtain more than one sub-user group;

[0010] For the access data of each sub-user group, sort the frequency of access to the corresponding API within the second preset time range according to the user ID and API name to obtain the access frequency sequence group;

[0011] The threshold range for each user's different API calls is calculated based on the access frequency sequence group and the preset threshold, and the abnormal threshold is determined based on the threshold range.

[0012] Preferably, the method for calculating the threshold range for different APIs called by each user based on the access frequency sequence group and a preset threshold includes:

[0013] Arrange the access frequency sequence groups in ascending order;

[0014] Calculate the first quartile and the third quartile data;

[0015] Calculate the interquartile range based on the first and third quartile data;

[0016] Calculate the range of outliers based on preset thresholds and interquartile ranges, and then calculate the API access threshold range.

[0017] Based on the above steps, the threshold range for each user's different API calls is calculated.

[0018] Preferably, the method for calculating the range of outliers based on a preset threshold and interquartile range, and for calculating the API access threshold range, includes: the first quartile data is denoted as q1, the third quartile data as q3, and the interquartile range as iqr;

[0019] Calculate the low threshold: low_thresh = q1 - thresh * iqr;

[0020] Calculate the high threshold: high_thresh = q3 + thresh * iqr.

[0021] Preferably, the method for determining the abnormal threshold based on the threshold range includes:

[0022] If a user's access frequency to a corresponding API is lower than a low threshold for several consecutive days, it is identified as a low-access-frequency API.

[0023] If the frequency of user access to a corresponding API exceeds a high threshold, it is determined that the API poses a security risk.

[0024] Preferably, the method also includes the step of periodically updating the threshold range.

[0025] Furthermore, a detection system for abnormal API access behavior is proposed, comprising the following structure:

[0026] The monitoring unit is used to monitor cloud account API request access data. The access data includes user ID, the name of the API accessed by the user, and the time when the user accessed the API.

[0027] The data grouping unit is used to statistically analyze access data according to a preset time range to obtain a time statistics group; the access data within the time statistics group is grouped by user ID to obtain one or more sub-user groups;

[0028] The data sorting unit sorts the access data of each sub-user group according to the frequency of accessing a specific API based on the user ID and API name, thus obtaining an access frequency sequence group.

[0029] The threshold calculation unit calculates the range of abnormal thresholds based on the access frequency sequence group and the preset threshold, and each API called by a user ID has a unique corresponding abnormal threshold or abnormal threshold range.

[0030] Preferably, the threshold calculation unit further includes:

[0031] The interquartile range calculation unit is used to calculate the first quartile data and the third quartile data based on the ascending order of the access frequency sequence group; and to calculate the interquartile range based on the first quartile data and the third quartile data.

[0032] The threshold interval calculation unit receives the interquartile range parameter and preset threshold output by the interquartile range calculation unit, calculates the threshold interval for each user's different API calls, and determines the abnormal threshold based on the threshold interval.

[0033] Preferred options also include:

[0034] The analysis module is used to analyze whether a user's access frequency to a corresponding API is lower than a low threshold for several consecutive days, and if so, it is determined to be a low-access-frequency API; if the user's access frequency to a corresponding API is higher than a high threshold, it is determined that the API has a security risk.

[0035] The beneficial effects of this invention are as follows: Compared with the prior art, this invention has the advantages of low detection time overhead, high detection accuracy, low false alarm, strong adaptability and robustness, and provides a new approach to dynamic detection of abnormal API access behavior. Attached Figure Description

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

[0037] Figure 1 This is the overall flowchart of the method for detecting abnormal API access behavior;

[0038] Figure 2This is a flowchart of one implementation method for detecting abnormal API access behavior;

[0039] Figure 3 It is a sequence of user access frequencies sorted in ascending order;

[0040] Figure 4 It is another user access frequency sequence group sorted in ascending order. Detailed Implementation

[0041] The present invention will be further described in detail below with reference to the embodiments. The following embodiments are explanations of the present invention, but the present invention is not limited to the following embodiments.

[0042] A method for detecting abnormal API access behavior.

[0043] Step 1: Monitor cloud account API request access data. Access data includes user ID, the name of the API accessed by the user, and the time the user accessed the API.

[0044] Step 2: Analyze the access data according to the preset time range to obtain time statistics groups;

[0045] Step 3: Group the access data within the time statistics group by user ID to obtain more than one sub-user group;

[0046] Step 4: For the access data of each sub-user group, sort the access frequency of the corresponding API according to the user ID and API name to obtain the access frequency sequence group.

[0047] Step 5: Calculate the threshold range for different APIs called by each user based on the access frequency sequence group and the preset threshold, and determine the abnormal threshold based on the threshold range.

[0048] The first step involves monitoring API request access data for various cloud platforms. The monitored access data includes three pieces of information: user ID, the name of the API accessed by the user, and the time the user accessed the API (Userid, api_name, time).

[0049] For example: The data D for cloud platform users calling APIs is D = {[userid_1,api_name_1,time_1], [userid_1,api_name_1,time_2], ..., [userid_i,api_name_j,time_k]}.

[0050] Where i represents the userid of a different user on the cloud platform, j represents the API name within the user's API access permissions, and k represents the time when the user called the API. Therefore, [userid_i, api_name_j, time_k] means that the user with userid_i called the API named api_name_j at time time_k. D represents the monitored dataset of user API requests.

[0051] The data examples are shown in the table below:

[0052] Userid API name time 1882022890282517 ListUsers 2023-06-15T02:43:07Z 1882022890282517 CreateGroup 2023-06-15T02:44:10Z 1882022890282517 GetVerificationInfo 2023-06-15T02:49:41Z 1882022890282512 LookupEvents 2023-06-16T03:47:03Z 1882022890282511 GetUserMFAInfo 2023-06-16T03:47:05Z 1882022890282518 ListGroups 2023-06-16T03:47:05Z

[0053] In step two, the access data is statistically analyzed according to the first preset time range to obtain time statistics groups.

[0054] In this embodiment, the first preset time range is one day, that is, one day is used as a time window to statistically analyze the access data and obtain access data that includes the access time, which is the time statistics group mentioned above.

[0055] Since the unit of time is days, only the year, month, and day are retained for convenient subsequent statistical calculations; (the unit of time can be determined according to the needs of specific application scenarios).

[0056] The processed data is shown in the table below:

[0057] Userid API name time 1882022890282517 ListUsers 2023-06-15 1882022890282517 CreateGroup 2023-06-15 1882022890282517 GetVerificationInfo 2023-06-15 1882022890282512 LookupEvents 2023-06-16 1882022890282511 GetUserMFAInfo 2023-06-16 1882022890282518 ListGroups 2023-06-16

[0058] Step 3: Group the access data within the time statistics group by user ID to obtain more than one sub-user group; specifically, group the access data preprocessed in Step 2 according to userid, with the same userid forming a sub-user group.

[0059] Step 4: For the access data of each sub-user group, sort the frequency of access to the corresponding API within the second preset time range according to the user ID and API name to obtain the access frequency sequence group;

[0060] Specifically, the implementation involves using the userid and api_name as the key to count the frequency of a user's daily access to a specific api_name over a 30-day period, forming an access frequency sequence group. In this embodiment, the second preset time range is 30 days.

[0061] For example: Suppose that the following data was detected regarding user access to the API over the past 30 days: userid={1,2,3,……,i}, api_name={a,b,c,……,j}, time={date1,date2,date3,……,datek}.

[0062] The above dataset is grouped according to the same userid. The grouped data is as follows:

[0063] userid is 1: {(a, date1), (a, date2), (b, date1),..., (api_j, datek)};

[0064] userid is 2: {(d, date1), (e, date2), (a, date1),..., (api_j, datek)};

[0065] userid is 3: {(c,date1),(f,date2),(a,date1),...,(api_j,datek)};

[0066] For data within a group, using userid + api_name as the key, we calculate the frequency of each user's daily access to a specific api_name over 30 days, forming an access frequency sequence group. Taking userid 1 as an example: {1-a:date1}, {1-a:date2}, {1-b:date1}, ..., {1-api_j:datek}, where {1-a:date1} indicates that user 1 called API_a on date1. The frequency of user 1's daily API calls is then calculated and denoted as [f1, f2, f3, ..., fn], where fn represents the number of times user 1 called API_a on day n.

[0067] Step 5: Calculate the threshold range for different APIs called by each user based on the access frequency sequence group and the preset threshold, and determine the abnormal threshold based on the threshold range.

[0068] This embodiment proposes a preferred calculation method, including the following steps:

[0069] 1) Arrange the access frequency sequence groups in ascending order, such as... Figure 3 and Figure 4 , is a reference to the access frequency sequence group after ascending order.

[0070] 2) Calculate the first quartile and the third quartile;

[0071] 3) Calculate the interquartile range based on the first and third quartile data;

[0072] 4) Calculate the range of outliers based on preset thresholds and interquartile ranges, and calculate the API access threshold range;

[0073] 5) Calculate the threshold range for each user's different API calls based on the above steps.

[0074] The first quartile, third quartile, and interquartile range (IQR) are statistical terms. The first quartile represents 25% of the data in a dataset, providing information about the distribution of 25% of the data and revealing the lower bounds of the data. The third quartile represents 75% of the data, providing information about the upper bounds of the data and revealing the upper bounds of the data. The IQR describes the dispersion of the dataset. The IQR provides information about 50% of the data's dispersion; a higher IQR indicates more dispersed values, while a lower IQR indicates more concentrated data.

[0075] This embodiment uses interquartile range calculation to analyze the distribution of data, which is more conducive to learning about data with abnormal access frequency.

[0076] The method for calculating the range of outliers based on the preset threshold and interquartile range, and for calculating the API access threshold range, includes: the first quartile data is denoted as q1, the third quartile data as q3, the interquartile range as iqr, and the preset threshold as thresh.

[0077] Calculate the low threshold: low_thresh = q1 - thresh * iqr;

[0078] Calculate the high threshold: high_thresh = q3 + thresh * iqr.

[0079] The threshold parameter `thresh` is used to adjust the threshold for outliers. It's calculated by multiplying `thresh` by `iqr` to determine the boundary for outlier detection. While there's no fixed range for `thresh`, it's generally set between 0 and 5 based on experience. The value of `thresh` is chosen appropriately based on the data distribution and the specific needs of the problem. For example, when calculating the first quartile (denoted as `q1`), the third quartile (denoted as `q3`), and the interquartile range (denoted as `iqr`), the threshold is then determined based on the corresponding data.

[0080] This step provides a comprehensive understanding of the dataset's distribution based on the first and third quartiles, and the interquartile range reveals the degree of differentiation among the data points. These statistics are then used to learn useful information about the central and marginal parts of the dataset, ultimately outputting a more scientific and reasonable anomaly threshold range.

[0081] refer to Figure 2As shown, based on the above steps, a normal API access range [low_thresh, high_thresh] is obtained. If the user's call frequency is less than low_thresh or greater than high_thresh, it is considered an exception, and the corresponding exception handling operation is performed.

[0082] A preferred processing method is proposed, including:

[0083] If a user's access frequency to a corresponding API is lower than a low threshold for several consecutive days, it is identified as a low-access-frequency API.

[0084] If the frequency of user access to a corresponding API exceeds a high threshold, then the API is considered to pose a security risk.

[0085] As a preferred approach, this method has a learning function, which determines a periodic value based on the periodicity of user access behavior and updates the threshold range periodically.

[0086] Preferably, a 7-day interval is used. A 7-day interval provides a periodicity, and updating the threshold every 7 days allows for timely adaptation to data changes, reducing the risk of threshold invalidation due to data drift and improving the accuracy and precision of outlier thresholds. Of course, the update time can be adjusted according to project requirements.

[0087] After the above steps, each user has a unique customized threshold range for different API calls. Every seven days, the corresponding threshold range is updated by dynamically pulling 30 days of data from the current time point, which serves as the threshold range for the next detection of whether it is an abnormal API access behavior.

[0088] Example 2:

[0089] A system for detecting abnormal API access behavior includes the following structure:

[0090] The monitoring unit is used to monitor cloud account API request access data. The access data includes user ID, the name of the API accessed by the user, and the time when the user accessed the API.

[0091] The data grouping unit is used to statistically analyze access data according to a preset time range to obtain a time statistics group; the access data within the time statistics group is grouped by user ID to obtain one or more sub-user groups.

[0092] The data sorting unit sorts the access data of each sub-user group according to the frequency of accessing a specific API based on the user ID and API name, thus obtaining an access frequency sequence group.

[0093] The threshold calculation unit calculates the range of abnormal thresholds based on the access frequency sequence group and the preset threshold, and each API called by a user ID has a unique corresponding abnormal threshold or abnormal threshold range.

[0094] The analysis module is used to analyze whether a user's access frequency to a corresponding API is lower than a low threshold for several consecutive days, and if so, it is determined to be a low-access-frequency API; if the user's access frequency to a corresponding API is higher than a high threshold, it is determined that the API has a security risk.

[0095] The threshold calculation unit also includes:

[0096] The interquartile range calculation unit is used to calculate the first quartile data and the third quartile data based on the ascending order of the access frequency sequence group; and to calculate the interquartile range based on the first quartile data and the third quartile data.

[0097] The threshold interval calculation unit receives the interquartile range parameter and preset threshold output by the interquartile range calculation unit, calculates the threshold interval for each user's different API calls, and determines the abnormal threshold based on the threshold interval.

[0098] For other structures, please refer to Example 1 for a more detailed understanding; they will not be elaborated upon further in this article.

[0099] The above units may or may not be physically separate. The component shown as a unit can be one physical unit or multiple physical units, that is, it can be located in one place or distributed in multiple different places. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

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

[0101] If the integrated units described above are implemented as software functional units and sold or used as independent products, they can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of the present invention, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0102] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions within the technical scope disclosed in the present invention should be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for detecting abnormal API access behavior. Monitor cloud account API request access data, including user ID, the name of the API accessed by the user, and the time the user accessed the API; The access data is statistically analyzed based on the first preset time range to obtain time statistics groups; The access data within the time statistics group is grouped by user ID to obtain more than one sub-user group; For the access data of each sub-user group, sort the frequency of access to the corresponding API within the second preset time range according to the user ID and API name to obtain the access frequency sequence group; Calculate the threshold range for different APIs called by each user based on the access frequency sequence group and the preset threshold, and arrange the access frequency sequence group in ascending order; Calculate the first quartile and the third quartile data; Calculate the interquartile range based on the first and third quartile data; The range of outliers is calculated based on the preset threshold and interquartile range. The API access threshold interval is calculated. The first quartile data is denoted as q1, the third quartile data as q3, the interquartile range as iqr, and the preset threshold as thresh. Calculate the low threshold: low_thresh = q1 - thresh * iqr; Calculate the high threshold: high_thresh = q³ + thresh * iqr; Based on the above steps, the threshold range for each user's different API calls is calculated, and the abnormal threshold is determined based on the threshold range.

2. The method for detecting abnormal API access behavior according to claim 1, characterized in that, The method for determining the abnormal threshold based on a threshold range includes: If a user's access frequency to a corresponding API is lower than a low threshold for several consecutive days, it is identified as a low-access-frequency API. If the frequency of user access to a corresponding API exceeds a high threshold, it is determined that the API poses a security risk.

3. A method for detecting abnormal API access behavior according to any one of claims 1-2, characterized in that, It also includes the step of periodically updating the threshold range.

4. A system for detecting abnormal API access behavior, characterized in that, Includes the following structure: The monitoring unit is used to monitor cloud account API request access data. The access data includes user ID, the name of the API accessed by the user, and the time when the user accessed the API. The data grouping unit is used to statistically analyze the access data according to a first preset time range to obtain a time statistics group; and to group the access data within the time statistics group by user ID to obtain one or more sub-user groups. The data sorting unit sorts the access data of each sub-user group according to the frequency of access to the corresponding API within the second preset time range based on the user ID and API name, thus obtaining an access frequency sequence group. The threshold calculation unit calculates the threshold range for different APIs called by each user based on the access frequency sequence group and the preset threshold, and each API called by each user ID has a unique corresponding abnormal threshold or abnormal threshold range. The threshold calculation unit further includes: The interquartile range calculation unit is used to calculate the first quartile data and the third quartile data based on the ascending order of the access frequency sequence group; and to calculate the interquartile range based on the first quartile data and the third quartile data. The threshold interval calculation unit receives the interquartile range parameters output by the interquartile range calculation unit and, in conjunction with a preset threshold, calculates the API access threshold interval. The first quartile data is denoted as q1, the third quartile data as q3, the interquartile range as iqr, and the preset threshold as thresh. The low threshold is calculated as: low_thresh = q1 - thresh * iqr; the high threshold is calculated as: high_thresh = q3 + thresh * iqr. The threshold intervals for different APIs called by each user are calculated, and the abnormal threshold is determined based on the threshold intervals.

5. The API abnormal access behavior detection system according to claim 4, characterized in that, Also includes: The analysis module is used to analyze whether a user's access frequency to a corresponding API is lower than a low threshold for several consecutive days, and then judge it as a low access frequency API. If the frequency of user access to a corresponding API exceeds a high threshold, then the API is considered to pose a security risk.

6. A computer storage medium, characterized in that, It stores a computer program, which is invoked by a processor to implement a method for detecting abnormal API access behavior as described in any one of claims 1-3.

7. An electronic device, characterized in that, The system includes a memory and a processor, the memory being used to store one or more computer instructions, wherein the one or more computer instructions are executed by the processor to implement a method for detecting abnormal API access behavior as described in any one of claims 1-3.

Citation Information

Patent Citations

  • API access behavior detection method and device, equipment and storage medium

    CN115378739A