Anomaly detection method, model training method, and related apparatus

Abstract

An anomaly detection method, a model training method, and a related apparatus, which are applied to the technical field of computers. In the present application, features of current and historical API invocation requests of a user are extracted to obtain a combined traffic feature, and a first model and the combined traffic feature are used to analyze whether the current API invocation request of the user is anomalous. The combined traffic feature can reflect, from a digital perspective, features of a plurality of API invocation requests in a combination, enabling the first model to more accurately analyze whether the current API invocation request of the user is anomalous. In the model training method, features are extracted from a plurality of sample API invocation sequences, and these features and the ground truth intent of each sample API invocation sequence are used to train the first model. Since service execution is typically implemented by invoking a plurality of APIs, the first model can better learn a dependency relationship between API invocation requests by learning the features of the sample API invocation sequences, thereby improving detection accuracy of the first model.

Description

An anomaly detection method, model training method, and related apparatus

[0001] This application claims priority to Chinese Patent Application No. 202510112277.1, filed on January 22, 2025, entitled "An anomaly detection method, model training method and related apparatus", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of computer technology, and in particular to an anomaly detection method, a model training method, and related apparatus. Background Technology

[0003] In today's rapidly evolving digital and cloud service landscape, Application Programming Interfaces (APIs) have become a core bridge for interaction and data exchange between systems. However, API services are susceptible to abnormal API calls, which can lead to extremely serious consequences. For example, when an API call goes wrong, sensitive data from business systems (such as user information, financial records, or business secrets) may be leaked, causing data security issues. Furthermore, APIs can be further misused to perform unauthorized operations, triggering a chain reaction of service interruptions, data tampering, and even business crashes, ultimately damaging the business system.

[0004] If unauthorized API access can be detected in a timely manner, countermeasures can be taken to prevent data breaches and system security risks. However, current API anomaly detection methods are generally inefficient. For example, some solutions can only detect abnormal states after abnormal API access has occurred, while others rely mainly on manual analysis, which is both time-consuming and inefficient, and fails to meet practical needs.

[0005] Therefore, how to improve the efficiency of detecting abnormal API calls is a problem that this application urgently needs to solve. Summary of the Invention

[0006] This application provides an anomaly detection method, a model training method, and related apparatus, which can extract combined traffic features based on a user's current API call request and historical API call requests, analyze the combined traffic features using a first model, and thereby detect whether the user's current API call request is abnormal, thereby improving the real-time performance and accuracy of detecting abnormal API calls.

[0007] Firstly, this application provides an anomaly detection method. This method is applied to an anomaly detection device, which handles user requests to call application programming interface (API) systems within a business system. The business system provides multiple APIs for user calls. Optionally, the anomaly detection device is one of the access control node services through which access traffic passes, including but not limited to cloud service or microservice API gateways, firewalls, load balancers, etc. Optionally, this method can be implemented by hardware and / or software modules of the anomaly detection device. For example, this method is applied to an API gateway and implemented by software and hardware modules within the API, handling user requests to call application programming interface (API) systems within the business system. For ease of description, the following explanation uses the anomaly detection device as the execution entity.

[0008] The anomaly detection method includes: an anomaly detection device acquiring a first API call request from a first user, extracting features from the first API call request and at least one historical API call request to obtain combined traffic features. The anomaly detection device then uses a first model to obtain detection results based on the combined traffic features.

[0009] The first API call request is used to request a call to a first API, which is one of the aforementioned APIs. At least one historical API call request refers to a call request made by the first user to at least one API before the first API call request occurred, and at least one API is one of the aforementioned APIs. The detection result is used to indicate whether the first API call request is abnormal, and the first model is a pre-trained model.

[0010] Typically, abnormal API calls by users unfold gradually, as attackers often use multiple steps or requests to make multiple API calls to achieve their malicious goals. For example, an attacker might first obtain basic information through a normal request, then gradually expand their access privileges to the system, ultimately achieving their malicious objective. In such cases, analyzing a single API call request might fail to detect abnormal API behavior in a timely manner, and the system might even malfunction by the time abnormal API calls are discovered. At this point, unauthorized API access has already caused damage to the system, and handling the anomaly is too late. Furthermore, users may access less frequently used API resources during normal API calls. Analyzing only a single API call request could lead to misjudging normal operations as abnormal behavior. In short, judging whether an API call request is abnormal solely by analyzing the user's current API call request is rather one-sided.

[0011] In the above solution, the anomaly detection device analyzes whether the user's current API call is abnormal by combining the user's current API call with historical API call requests. It can more comprehensively analyze whether the API call request is abnormal by combining the context of the current user API request, and can accurately detect abnormal API calls, which helps to improve the security and stability of the system.

[0012] Building upon this, this application extracts features from the user's current and historical API call requests to obtain combined traffic features. These combined traffic features digitally reflect the characteristics of multiple combined API call requests. Furthermore, the access control node utilizes the first model and combined traffic features to analyze whether the user's current API call requests are abnormal. This allows for a more comprehensive analysis of whether any anomalies have occurred in the user's current API call requests, timely detection of unauthorized behavior, and increased accuracy in anomaly detection. This application utilizes the first model to analyze combined traffic features, resulting in higher anomaly detection efficiency and more accurate results.

[0013] In one possible implementation of the first aspect, the anomaly detection method further includes: when the detection result indicates that the first API call request is abnormal, the anomaly detection device performs an anomaly control operation on the first API call request. Exemplarily, the anomaly control operation includes one or more of the following: approving the first API call request, rejecting the first API call request, or outputting status indication information, whereby the status indication information is used to indicate the detection result.

[0014] In the above implementation, the anomaly detection device performs corresponding operations on the first API call based on the detection results, which can increase the security and stability of the system.

[0015] For example, if the first API call request is abnormal, the access control node can perform an interception operation (i.e., reject the first API call request). At this time, the first API call request will not be able to access the business system, thereby increasing the security and stability of the system.

[0016] In some possible implementations, after granting the first API call request, other operations can still be performed on it to avoid impacting the business system should the first API call request indeed be in an abnormal state. For example, the core operations of the first API call request can be delayed, such as marking it as "pending review." As another example, a verification mechanism can be added to the first API call request, and the corresponding operations can only be performed after confirming the legitimacy of the first API call request.

[0017] For example, in some solutions, the security requirements of the business system itself are reduced, or there are further control processes for abnormal calls. In this case, the access control node can also make a request through this first API call. It can be seen that the exception control operation can be flexibly designed according to business needs.

[0018] For example, anomaly detection devices can perform alarm operations (i.e., output status indication information) to respond to security events in real time.

[0019] Furthermore, anomaly detection operations can be a combination of allowing, blocking, and alarming. For example, when the detection result indicates that the first API call request is a low-risk anomaly, the anomaly detection device can perform a "allow + alarm" operation on the first API call request. As another example, when the detection result indicates that the first API call request is a high-risk anomaly, the anomaly detection device can perform a "block + alarm" operation on the first API call request. In this way, the anomaly detection device can perform targeted anomaly control operations on the first API call request based on the specific anomaly status information indicated by the detection result, which helps to improve both the overall security of the system and the user experience.

[0020] In some cases, when the detection result indicates that the first API call request is normal, the anomaly detection device can directly access the first API call request.

[0021] In another possible implementation of the first aspect, the anomaly detection method further includes: the anomaly detection device acquiring first configuration information input by the management user, the first configuration information being used to indicate the processing operation corresponding to the detection result.

[0022] In the above implementation, the operation performed on the first API call request when an anomaly is detected is user-configurable. Since different business scenarios may have significantly different processing operations for API call requests, the management user can pre-set the processing operations for the API call request, allowing for personalized settings based on actual needs. For example, the operations that the management user can set include, but are not limited to, one or more of the following: allowing the first API call request, allowing the first API call request while simultaneously outputting status indication information, rejecting the first API call request, or rejecting the first API call request while simultaneously outputting status indication information. This approach makes the processing of the first API call request more flexible, contributing to a better user experience.

[0023] In another possible implementation of the first aspect, before performing feature extraction on the first API call request and at least one historical API call request to obtain combined traffic features, the anomaly detection method further includes: the anomaly detection device acquiring an activation indication from the management user input, the activation indication being used to instruct the detection of whether the user's current API call request is abnormal based on the user's current API call request and historical API call requests.

[0024] In the above implementation, the anomaly detection method is activated by the management user, who can choose whether to enable the anomaly detection method based on the actual situation of the business system. In this way, the management user can set the anomaly detection method according to the actual situation, which helps to improve the adaptability of the anomaly detection method and the business system, and enhances the user experience.

[0025] In another possible implementation of the first aspect, the historical API calls used to combine with the current API call meet preset conditions, so that the combination sequence of API calls can have stronger correlation and improve the accuracy of anomaly detection.

[0026] As one possible implementation, at least one historical API call request must have occurred within a first time period. The first time period is the length of time from a specific moment until the current API call request occurs. In other words, the first time period covers a continuous time interval preceding the current API request, and all API call requests occurring within this interval can be considered relevant historical records, with at least one call request falling within this first time period.

[0027] Since short-term API call requests are more correlated, extracting features from the first API call request and at least one historical API call request within the first time period before the first API call request results in more accurate combined traffic features, which helps the first model obtain accurate detection results based on the combined traffic features.

[0028] Optionally, the first time period is defined by the management user. This allows the management user to set the conditions that historical API calls must meet in conjunction with the current API call, based on actual needs. This helps improve the adaptability of anomaly detection methods and business systems, and enhances the user experience.

[0029] As another possible implementation, at least one historical API call request must meet a preset condition regarding the number of API calls. A single request may appear normal, but abnormal behavior may only be exposed when combined with the preceding and following call context. In actual implementation, there may be fewer API calls over a period of time, followed by an abnormal API call request only after a certain interval. In this case, limiting the number of at least one historical API call request can extract more accurate combined traffic characteristics, thereby ensuring more accurate detection of abnormal states in current API call requests.

[0030] Optionally, the preset condition for the number of API call requests in at least one historical API call request is defined by the management user. In this way, the management user can set the conditions that historical API calls combined with the current API call must meet according to the actual situation, which can improve the adaptability of anomaly detection methods and business systems and enhance user experience.

[0031] In the above implementation, users can define the occurrence time of at least one historical API call request, or define the number of at least one historical API call requests. In this way, administrators can set the conditions that historical API calls combined with the current API call must meet according to actual needs, which helps improve the adaptability of anomaly detection methods and business systems, and enhances the user experience.

[0032] In another possible implementation of the first aspect, combined traffic features are used to describe the statistical characteristics of a combined API call sequence. The combined API call sequence includes multiple API call requests arranged chronologically, each API call including a first API call request and at least one historical API call request.

[0033] In the above implementation, combined traffic features are used to describe the statistical characteristics of the combined API call sequence, such as the number of times the first API and the second API are called, the frequency of calling the first API and the second API, and the number of times the second API is called before the first API. Since combined traffic features can represent not only the individual behavioral characteristics of the first API call request and at least one historical API call request, but also the behavioral characteristics of the first API call request and at least one historical API call request in a combined form, the first model can obtain more comprehensive feature input, thereby enabling the first model to output more accurate detection results.

[0034] In another possible implementation of the first aspect, the combined traffic features include static features and / or dynamic features. Static features are used to describe statistical features at the granularity of a single API call record, and are used to extract path-related features and parameter-related features. Dynamic features are used to describe statistical features at the granularity of dynamic combined calls to multiple APIs.

[0035] In the above implementation, static features mainly reflect the path-related features and parameter-related features of the API call sequence, while dynamic features mainly reflect the features of combined API calls. Parameter-related features include one or more of the following: the number of parameters, uniqueness, proportion, standard deviation, or mean. Path-related features include one or more of the following: the number of paths, depth, uniqueness, proportion, standard deviation, mean, the number of paths containing a specified character, or the proportion of paths containing a specified character.

[0036] When an API is invoked normally, its parameter-related and path-related characteristics should generally meet a reasonable standard. Abnormal parameter-related and path-related characteristics may indicate a risk of unauthorized access, such as an unexpected number or proportion of parameters. Similarly, dynamic combination calls between APIs should also conform to normal operation. If unreasonable combinations occur in dynamic API calls, it indicates a possible abnormal API call. For example, calling the first API should not allow calling the second API. If, in actual implementation, calling the first API followed by calling the second API occurs, it indicates an abnormal API call has occurred. Thus, by training the first model to understand the parameter-related and path-related characteristics of APIs, the first model can more accurately identify malicious requests and output more accurate detection results.

[0037] In another possible implementation of the first aspect, path-related features include one or more of the following: the number of unique paths, the total number of paths, the number of times consecutive paths appear, the average length of paths, the standard deviation of path lengths, the average depth of paths, the standard deviation of path depths, the proportion of paths with uniqueness, the proportion of paths with depths satisfying the first condition, the number and / or proportion of paths containing specified characters, etc. Parameter-related features include one or more of the following: the number of unique parameters, the total number of parameters in the access sequence, the average number of parameters, or the standard deviation of the number of parameters, etc.

[0038] Dynamic characteristics include the number and / or proportion of subsequences in the API call sequence that satisfy the execution of a target operation combination. The target operation combination includes one or more of the following: executing the first operation before the second operation, executing the third operation K times consecutively, and the resource path of the first accessed URL being different from the resource path of the later accessed URL.

[0039] In the above implementation, the static and dynamic characteristics of the API are related to specific business scenarios. For example, in the first business scenario, the number of unique paths calling the first API is fixed at a first value. If, during actual implementation, the number of unique paths calling the first API is greater than or less than the first value, it indicates that an anomaly has occurred in the calling of the first API in the first business scenario. Thus, by learning the traffic characteristic information under specific business scenarios, the first model can output detection results that are more consistent with the specific business scenario.

[0040] In another possible implementation of the first aspect, the first model is trained using combined traffic features corresponding to multiple sample API call sequences and the intent ground truth of multiple sample API call sequences. The sample API call sequence includes multiple sample API call requests arranged in chronological order of occurrence. The intent ground truth of a sample API call sequence is used to indicate whether the intent of a sample API call sequence is abnormal.

[0041] In the above implementation, the first model is pre-trained based on the combined traffic features corresponding to multiple sample API call sequences and the ground truth values ​​of the intent for each sample API call sequence. By pre-training based on the combined traffic features and ground truth values ​​of multiple sample API call sequences, the first model can learn richer contextual information and call patterns. This enables the first model to better understand the correlation and intent between different sample API call sequences, thereby improving the processing and judgment capabilities of the first model.

[0042] In another possible implementation of the first aspect, the multiple sample API call sequences are generated using a large language model (LLM), API description information, and user intent information.

[0043] In the above implementation, the sample API call sequence is generated by LLM based on the description information and user intent information of multiple APIs. The API description information includes the API parameters, and the user intent information includes the user's normal and abnormal intent information when calling the API. Since LLM has powerful data processing and learning capabilities, it can fully utilize the API description information and user intent information to generate a relatively comprehensive sample API call sequence, thus providing the first model with abundant training samples for pre-training.

[0044] Secondly, this application provides a model training method, which is implemented by a device with data processing capabilities, such as a computing device. Optionally, the computing device is a model training apparatus, and the method is implemented by software modules and / or hardware models of the model training apparatus. For ease of description, the following description uses a model training apparatus as the execution entity.

[0045] The model training method includes: a model training device acquiring a user traffic dataset; the model training device extracting features from multiple sample API call sequences in the user traffic dataset to obtain combined traffic features corresponding to each sample API call sequence; and the model training device training a first model using the combined traffic features corresponding to each sample API call sequence and the ground truth values ​​of the intent of each sample API call sequence. The user traffic dataset includes multiple sample API call sequences and their intent ground truth values. Each sample API call sequence includes multiple sample API call requests arranged in chronological order. The intent ground truth value of a sample API call sequence indicates whether the intent of that sequence is anomalous. The first model outputs intent detection results for the user API call sequences based on the combined traffic features, and these results indicate whether the predicted intent of the user API call sequences is anomalous.

[0046] In the above implementation, the user traffic dataset includes multiple sample API call sequences. Since business operations often require calls to multiple APIs, learning only the features of a single API call would be incomplete and could potentially lead to poor learning performance of the first model. However, by comprehensively analyzing the call patterns of multiple APIs when completing a business task or implementing a function, the first model can learn the dependencies between API call requests, thereby more accurately analyzing any abnormal states of the user's current API call requests.

[0047] In another possible implementation of the second aspect, the model training method further includes: a model training device acquiring API description information of the business system. The model training device utilizes LLM to generate a preliminary API access sequence based on the API description information and user intent information. The API description information includes functional descriptions of multiple APIs and parameter fields of multiple APIs. Based on the preliminary API access sequence, the model training device obtains a sample API call sequence. Based on the API description information and user intent information, prompt words are constructed. The model training device utilizes LLM to obtain a user traffic dataset based on the prompt words. The preliminary API access sequence includes multiple empty access sequences, where the values ​​of the API parameter fields are undefined. The values ​​of the API parameter fields in the API call sequence are defined. The user intent information includes at least one normal user intent and / or at least one abnormal user intent.

[0048] In the above implementation, the generation of the user traffic dataset relies on sample API call sequences, which primarily reflect the characteristics of APIs and the dependencies between APIs when APIs are called according to positive and negative user intentions. Both the user traffic dataset and the sample API call sequences are generated using LLM. For example, LLM generates API call sequences with empty API parameter fields (i.e., preliminary API access sequences) based on API description information and user intention prompts. Alternatively, LLM generates user traffic data using prompts and API access sequences. Due to LLM's powerful data processing and learning capabilities, it can generate more comprehensive and accurate API access sequences and user traffic datasets. In this way, the construction of the user traffic dataset can more comprehensively cover both normal and abnormal user behaviors, allowing the first model to be trained more thoroughly and thus improving its robustness and generalization ability.

[0049] In another possible implementation of the second aspect, the model training device extracts features from multiple sample API call sequences in the user traffic dataset to obtain combined traffic features corresponding to the multiple sample API call sequences, including: the model training device uses feature configuration information to extract features from multiple sample API call sequences in the user traffic dataset to obtain combined traffic features corresponding to the multiple sample API call sequences, wherein the feature configuration information is used to indicate the features to be extracted.

[0050] In the above implementation, combining traffic feature extraction based on feature configuration information can ensure that the extracted features are highly relevant to specific analysis objectives and business needs. This can reduce the interference of irrelevant features and extract key features closely related to API request patterns, user behavior, etc., thereby improving the training efficiency and accuracy of the model and enhancing the model's anomaly detection capability.

[0051] In another possible implementation of the second aspect, the feature configuration information includes at least one user-defined feature.

[0052] In the above implementation, the feature configuration information is defined by the user. Thus, the first model can be trained to meet the user's needs, and consequently, the method for detecting abnormal API calls can better meet the user's requirements.

[0053] In another possible implementation of the second aspect, the model training method further includes: the model training device determining recommended extraction features based on the user traffic dataset, the recommended extraction features being used to prompt the user for recommended extraction features.

[0054] In the above implementation, the recommended extracted features are key traffic feature information, and users can construct combined traffic features based on the recommended extracted features. In this way, combined traffic features can be extracted according to user needs, so the first model can be trained according to user needs, and consequently, the abnormal API call detection method can better meet user needs.

[0055] Thirdly, this application provides an anomaly detection device, which includes an acquisition module and a detection module, wherein:

[0056] The acquisition module acquires a first API call request from a first user. This first API call request requests a first API, which belongs to multiple APIs. The detection module extracts features from the first API call request and at least one historical API call request to obtain combined traffic features. The at least one historical API call request is a call request made by the first user to at least one API before the first API call request occurred, and the at least one API belongs to multiple APIs. The detection module uses a first model based on the combined traffic features to obtain a detection result. The detection result indicates whether the first API call request is abnormal. The first model is a pre-trained model.

[0057] In one possible implementation of the third aspect, the detection module is further configured to: perform an exception control operation on the first API call request if the detection result indicates that the first API call request is abnormal, wherein the exception control operation includes one or more of the following:

[0058] The status indication information is used to indicate the detection result by making a first API call request, rejecting the first API call request, or outputting status indication information.

[0059] In another possible implementation of the third aspect, the acquisition module is further configured to: acquire first configuration information input by the management user, the first configuration information being used to indicate the processing operation corresponding to the detection result.

[0060] In another possible implementation of the third aspect, the acquisition module is further configured to: acquire an activation indication for managing user input, the activation indication being used to indicate whether the user's current API call request is abnormal based on the user's current API call request and historical API call requests.

[0061] In another possible implementation of the third aspect, combined traffic features are used to describe the statistical characteristics of a combined API call sequence. The combined API call sequence includes multiple API call requests arranged chronologically, each API call including a first API call request and at least one historical API call request.

[0062] In another possible implementation of the third aspect, the combined traffic features include static features and / or dynamic features. Static features are used to describe statistical features at the granularity of a single API call record, and are used to extract path-related features and parameter-related features. Dynamic features are used to describe statistical features at the granularity of dynamic combined calls of multiple APIs.

[0063] In another possible implementation of the third aspect, the first model is trained using combined traffic features corresponding to multiple API call sequences and the intent truth values ​​of multiple API call sequences. The API call sequence includes multiple API call requests arranged in chronological order of occurrence. The intent truth value of an API call sequence is used to indicate whether the intent of an API call sequence is abnormal.

[0064] Fourthly, this application provides a model training apparatus, which includes an acquisition module and a training module, wherein:

[0065] The acquisition module is used to acquire user traffic datasets, which include multiple sample API call sequences and intent truth values ​​of multiple sample API call sequences. The sample API call sequences include multiple sample API call requests arranged in chronological order of occurrence. The intent truth value of an API call sequence is used to indicate whether the intent of a sample API call sequence is abnormal.

[0066] The training module is used to: extract features from multiple sample API call sequences in the user traffic dataset, obtaining combined traffic features corresponding to each sample API call sequence. Using the combined traffic features and ground truth intent values ​​of the multiple sample API call sequences, a first model is trained. This first model outputs intent detection results for the user API call sequences based on the combined traffic features. These intent detection results indicate whether the predicted intent of the user API call sequences is abnormal.

[0067] In one possible implementation of the fourth aspect, the acquisition module is further configured to acquire API description information of the business system, which includes functional descriptions of multiple APIs and parameter fields of multiple APIs.

[0068] The training module is also used to: generate preliminary API access sequences based on API description and user intent information using LLM. These preliminary API access sequences include multiple empty access sequences, where the values ​​of the API parameter fields are undefined. Based on the preliminary API access sequences, sample API call sequences are obtained, where the values ​​of the API parameter fields are defined. Based on the API description and user intent information, prompt words are constructed, where the user intent information includes at least one normal user intent and / or at least one abnormal user intent. Finally, using LLM, a user traffic dataset is obtained based on the API call sequences and prompt words.

[0069] In another possible implementation of the fourth aspect, the training module is further configured to: use feature configuration information to extract features from multiple sample API call sequences in the user traffic dataset, thereby obtaining combined traffic features corresponding to the multiple sample API call sequences respectively, wherein the feature configuration information is used to indicate the features to be extracted.

[0070] In another possible implementation of the fourth aspect, the training module is further configured to: determine recommendation extraction features based on the user traffic dataset, the recommendation extraction features being used to prompt the user for recommended extraction features.

[0071] Fifthly, this application provides a computing device, which includes a processor and a memory, the memory storing a computer program, and the processor being used to invoke the computer program stored in the memory to implement the method of the first aspect of claim, or to implement the method of the second aspect.

[0072] Sixthly, this application provides a computing device cluster, comprising at least one computing device, each computing device including a processor and a memory. The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, causing the computing device cluster to perform the method of the first aspect, or to perform the method of the second aspect of claim.

[0073] In a seventh aspect, this application provides a readable storage medium, characterized in that it includes computer program instructions, which, when executed by a cluster of computing devices, enable the cluster of computing devices to perform the method of the first aspect, or to perform the method of the second aspect.

[0074] Eighthly, this application provides a computer program product containing instructions, characterized in that, when the instructions are run by a cluster of computing devices, they cause a device including a processor to perform the method of the first aspect, or to perform the method of the second aspect.

[0075] The beneficial effects of the technical solutions provided in aspects three to eight of this application can be referred to the beneficial effects of the technical solutions in aspects one or two, and will not be repeated here. Attached Figure Description

[0076] The accompanying drawings used in the description of the embodiments will be briefly introduced below.

[0077] Figure 1 is a schematic diagram of the architecture of an anomaly detection system provided in an embodiment of this application;

[0078] Figure 2 is a flowchart illustrating an anomaly detection method provided in an embodiment of this application;

[0079] Figure 3 is a flowchart illustrating a model training method provided in an embodiment of this application;

[0080] Figure 4 is a flowchart illustrating another anomaly detection method provided in an embodiment of this application;

[0081] Figure 5 is a functional schematic diagram of an access control node provided in an embodiment of this application;

[0082] Figure 6 is a flowchart illustrating another model training method provided in an embodiment of this application;

[0083] Figure 7 is a detailed schematic diagram of the embodiment in Figure 6;

[0084] Figure 8 is a flowchart illustrating a combination of anomaly detection method and model training method provided in an embodiment of this application;

[0085] Figure 9 is a schematic diagram of an anomaly detection device provided in an embodiment of this application;

[0086] Figure 10 is a schematic diagram of a model training device provided in an embodiment of this application;

[0087] Figure 11 is a schematic diagram of the structure of a computing device provided in an embodiment of this application;

[0088] Figure 12 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of this application;

[0089] Figure 13 is a schematic diagram of another computing device cluster provided in an embodiment of this application. Detailed Implementation

[0090] Before introducing the embodiments of this application, the terminology that may be used in the embodiments of this application will be introduced first.

[0091] 1. A model, also known as an artificial intelligence (AI) model or machine learning model, is a set of functions and parameters learned after training on training data. It is used to perform specific tasks, such as prediction, classification, or other data processing tasks.

[0092] 2. Large language models (LLMs) refer to "large parameter" models trained using massive amounts of data and powerful computing capabilities. Large models typically possess high versatility and generalization ability, and can be applied to fields such as natural language processing, image recognition, and speech recognition. For example, large models include large language models, multimodal large models, or basic large models. Through their large number of parameters, deep network structures, and extensive pre-training capabilities, large models can capture complex data patterns and exhibit superior performance across multiple domains. Large models can not only understand and generate natural language but also process complex visual and multimodal information, adapting to various and ever-changing application scenarios.

[0093] 3. A prompt is an instruction or text snippet given to the model when interacting with an artificial intelligence system. In some solutions, prompts act as a bridge between the user and the model, guiding the model to generate corresponding output by clearly defining the task objective and context. The design of prompts has a significant impact on the model's behavior and results, determining the depth and accuracy of the model's understanding of a specific problem. Depending on the application requirements, prompts can be simple instructions or complex contextual descriptions, and can be applied to a variety of tasks, from basic queries to high-level reasoning.

[0094] 4. An Application Programming Interface (API) is a set of rules and protocols that define interactions between software components. APIs allow different software applications or systems to communicate, share data and functionality, and are typically implemented through a set of functions, methods, classes, or protocols. APIs are an indispensable part of modern software development, providing powerful functionality and flexibility. The working principle of an API is primarily that the client sends a request to the server (usually a Hypertext Transfer Protocol request, containing the required operations and parameters). After receiving the request, the server processes it and finally returns the result to the client in a predefined format. For example, API types include, but are not limited to, one or more of the following: web APIs, framework APIs, operating system APIs, database APIs, or hardware APIs. Further examples include common use cases for APIs such as data acquisition and processing (e.g., retrieving data from remote servers via APIs, such as weather information, news, stock data, etc.), extending functionality through third-party services (e.g., extending application functionality through payment interfaces, social media logins, map services, etc.), or performing automated tasks (e.g., using APIs for batch data processing).

[0095] 5. A control access node is a node in a system architecture or network used to manage and control access permissions to specific resources, services, or data. It is typically located within the system's network architecture, acting as an intermediary between user requests and system resources. Its responsibilities include authentication (verifying the requester's identity, such as through usernames, passwords, tokens, fingerprints, or facial recognition), authorization (determining whether the requester has permission to access specific resources or perform an operation after successful authentication), auditing (recording user behavior, such as whether the first user accessed the first resource at the first moment and whether that behavior was legal), and traffic control (controlling whether requested traffic passes through). For example, a control access node can be one of the following network devices: an API gateway, a load balancer, a firewall, or a security gateway.

[0096] The system and business scenarios of the embodiments of this application are described below. It should be noted that the system architecture and business scenarios described in this application are for the purpose of making the technical solutions of this application clearer, and do not constitute a limitation on the technical solutions provided in this application. Those skilled in the art will know that with the evolution of system architecture and the emergence of new business scenarios, the technical solutions provided in this application are also applicable to similar technical problems.

[0097] Please refer to Figure 1. Figure 1 is a schematic diagram of the architecture of an anomaly detection system provided in an embodiment of this application. The anomaly detection system 10 includes an anomaly detection device 101, which can be used to process API call requests from a first user 102.

[0098] In this context, the first user 102 is the requester of the API call service. Optionally, the first user can be at least one of the following: an application, a real user, a third-party system, an automation tool, or a microservice. For example, the first user can be a front-end application that calls the first API using a front-end programming language. Another example is a human user who triggers the first API call request by clicking a button in a browser.

[0099] The anomaly detection device 101 is a device with data processing capabilities. In some solutions, the anomaly detection device is used to handle user API call requests. For example, the anomaly detection device 101 can approve or reject user API call requests. The aforementioned API may be provided by a business system. In this case, the business system can provide multiple APIs for users to call. When a user initiates an API call request, the call request first passes through the anomaly detection device 101, which processes the API call request and then executes corresponding control operations based on the processing result. In some solutions, the anomaly detection device is also referred to as a control access node.

[0100] In some cases, the anomaly detection device 101 has at least one hardware and / or at least one software module. Optionally, the processing of user API call requests is implemented by the hardware and / or software modules of the anomaly detection device 101. Exemplarily, the anomaly detection device is one of the access control node services through which access traffic passes, including but not limited to API gateways, firewalls, load balancers, etc., for cloud services or microservices.

[0101] Optionally, the anomaly detection device 101 deploys a first model, or the anomaly detection device 101 has the ability to invoke the first model, which is used to analyze whether a user's API call request is abnormal. The first model is a pre-trained model. Optionally, the first model is pre-trained by another device and then deployed in the anomaly detection device 101, for example, pre-trained by a model training device and then deployed in the anomaly detection device 101. Further optionally, the first model can be pre-trained and deployed in another device for the anomaly detection device 101 to invoke. For example, the first model is trained by a model training device and then deployed on a server, and the anomaly detection device 101 invokes the first model deployed on the server.

[0102] In today's digital development context, APIs have become an important bridge for system interaction and data exchange. However, with the increasing complexity of application scenarios and the growing number of interfaces, abnormal API access issues are not only reflected in single interfaces, but more often in the case of combined API calls. Furthermore, the abnormal access behavior caused by combined API calls is more complex and more difficult to detect.

[0103] In multi-API combined calls, attackers may exploit differences in permission configurations, logical vulnerabilities, or data flow inconsistencies between multiple interfaces through legitimate API call paths to perform unauthorized operations or access sensitive data across interfaces. This type of attack is difficult to detect through permission verification or behavioral analysis of a single interface. For example, one interface might allow a user to obtain basic information, while another interface is used to update permission configurations. If an attacker uses a combined path of calling these interfaces to operate the system in an unexpected manner, it could lead to unauthorized access, data tampering, or leakage of sensitive information.

[0104] Existing technical solutions are effective at handling abnormal access to single APIs, but lack effective solutions for abnormal access caused by combined API calls. For example, some solutions rely on Identity and Access Management (IAM) and API gateway mechanisms, typically performing independent authentication and authorization for each API call. While this approach effectively prevents unauthorized access to a single API, it fails to protect against combined calls across multiple APIs. Other solutions rely on analyzing historical access logs to detect unauthorized access. While this method can detect anomalies in combined API calls, it lacks timeliness. Still other solutions rely on API documentation and manual analysis of combined API call vulnerabilities; however, due to frequent updates to API documentation and the diversity of API call combinations, manual analysis is not only inefficient but also lacks real-time detection capabilities. Finally, some solutions rely on live network traffic data, such as mirrored or historical traffic data, to train models and analyze anomalies. This method is suitable for existing services and systems but is not applicable to new services, new APIs, or rapidly changing system scenarios.

[0105] In view of this, this application provides an anomaly detection method that, by combining a user's historical API call requests and utilizing a first model, analyzes whether the user's current API call request is abnormal, and promptly detects anomalies caused by multiple API combined calls. Furthermore, this application also provides a model training method that uses the combined traffic features corresponding to multiple sample API call sequences and the ground truth intent values ​​of the multiple sample API call sequences to train the first model.

[0106] The system architecture and application background provided by the embodiments of this application have been described above. The method provided by the embodiments of this application will be described below.

[0107] Please refer to Figure 2, which is a flowchart illustrating an anomaly detection method provided in an embodiment of this application. Optionally, this method can be applied to an anomaly detection system, such as the anomaly detection system shown in Figure 1, for example, the method is implemented by the anomaly detection device 101 shown in Figure 1. In some schemes, the anomaly detection device is also referred to as a control access node. For ease of understanding, the following description uses the anomaly detection device as the executing entity.

[0108] The anomaly detection method shown in Figure 2 may include multiple steps from S201 to S203. It should be understood that, for ease of description, this embodiment uses the sequence of steps S201 to S203, and is not intended to limit the execution to this specific order. This embodiment does not limit the order, execution time, or number of executions of the one or more steps described above. Steps S201 to S203 are as follows:

[0109] Step S201: The anomaly detection device obtains the first API call request from the first user.

[0110] The anomaly detection device handles user API call requests to the business system. For example, the anomaly detection device can approve or reject a first user's first API call request. Further, the anomaly detection device can verify the legitimacy of the first API call request, for example, through authentication or permission verification. It should be understood that in specific implementations, this device may have other names, such as access control node, API gateway, load balancer, firewall, or security gateway.

[0111] A business system refers to a system that implements business functions. A business system can provide multiple APIs for users to call. For example, an external delivery business system is responsible for managing user orders, delivery status, refunds, and other services. Accordingly, this system can provide APIs for users to place food orders, view order status, and cancel orders.

[0112] The first user is the requester of the API call service. Optionally, the first user includes at least one of the following: an application, a real user, a third-party system, an automation tool, or a microservice. For example, the first user can be a front-end application that calls the first API using a front-end programming language. Another example is a human user who triggers the first API call request by clicking a button in a browser.

[0113] The first API call request is used to request a call to the first API, which is the user's current API call request. In some solutions, when the anomaly detection device receives the first API call request, the first user has not yet successfully called the first API. The anomaly detection device can be used to determine whether to approve the first API call request based on the detection result of the first API call request (described below).

[0114] Step S202: The anomaly detection device extracts features from the first API call request and at least one historical API call request to obtain combined traffic features.

[0115] Specifically, at least one historical API call request is a call request made by the first user to at least one API before the first API call request occurred. It can be seen that both the first API call request and at least one API call request were initiated by the first user. Since different users may call the same API for different intentions, distinguishing API traffic by user helps to differentiate whether an API call request is abnormal behavior based on the user's intent during subsequent analysis. Optionally, users can be distinguished by one or more of the following: account, user ID, or IP address.

[0116] In some possible implementations, the anomaly detection device records API traffic generated by user behavior on a user-by-user basis. For example, see Table 1, which illustrates an example of API traffic generated by a first user calling an API.

[0117] Table 1 Examples of API traffic generated by the first user's API call.

[0118] Table 1 reflects the parameter status, request time, and request data volume of the API called by the first user. API calls including the values ​​of the above parameters can also be referred to as API traffic. Among them, the API parameter status includes one or more of the following: API request method, request Uniform Resource Locator (URL), request body, or request headers.

[0119] In some possible implementations, at least one historical API call request is consecutive to the first API call request. In other words, there are no other API call requests in between the first and at least one historical API call request. Because of the strong correlation between consecutive API call requests, anomalies can be accurately detected. For example, the number of at least one historical API call requests is predefined as 5. The current API call occurred at 11:30. The timestamps of API call requests occurring between 11:10 and 11:30 are recorded as follows: 11:12, 11:15, 11:20, 11:24, 11:26, and 11:28. Therefore, the timestamps of the historical API calls included in the at least one historical API call request are: 11:15, 11:20, 11:24, 11:26, and 11:28.

[0120] In actual implementation, there are several possibilities for selecting at least one historical API call request. The following describes three possible designs.

[0121] Design 1: At least one historical API call request must have occurred within a first time period. The first time period is the length of time from a certain moment until the current API call request occurs. For example, if the current API call occurs at 10:30, and the first time period is 10 minutes, the timestamps of API call requests occurring between 10:20 and 10:30 are recorded as follows: 10:02, 10:05, and 10:07. Therefore, three API call requests occurred within the first time period preceding the current API call request.

[0122] Optionally, the first time period is defined by the managing user. For example, the managing user defines the first time period based on the specific business scenario. For instance, because the financial data management system requires strong security, the user designs the first time period to be relatively long, such as 10 minutes.

[0123] Design 2 requires that at least one historical API call request contains an API call request that meets the first preset condition. For example, at least one historical API call request contains more than 10 API call requests.

[0124] Optionally, the first preset condition is defined by the managing user. For example, if the managing user defines the number of historical API call requests as 10, then at least one API call request is one of 10 consecutive API call requests starting from a certain historical API call request until the occurrence of the first API call request. Alternatively, the managing user may define the number of at least one historical API call requests to be between 10 and 15, with the specific number determined based on the actual implementation.

[0125] Design 3: At least one historical API call request occurs within a time period, and the number of such requests satisfies a second preset condition. This second preset condition is that at least one historical API call request occurs within a first time period, and the number of historical API call requests is at most N (N is a positive integer). For example, if the first time period is within 10 minutes of the current API call request, N is 5, and the current API call occurs at 11:30, then 6 API call requests occurred between 11:20 and 11:30. Therefore, 5 of these API call requests can be selected as the aforementioned at least one historical API call request. As another example, if the first time period is within 10 minutes of the current API call request, N is 5, and the current API call occurs at 12:30, then 4 API call requests occurred between 12:20 and 12:30. These 4 API call requests are all considered as the aforementioned at least one historical API call request.

[0126] Optionally, the second preset condition is set by the administrator. For example, if more than N API call requests occur in the first time period, the administrator can define rules to select API call requests that occur in the first time period.

[0127] Combined traffic characteristics refer to the properties of a combination of a first API call request and at least one historical API call request. Optionally, combined traffic characteristics are used to describe the statistical characteristics of a combined API call sequence. For example, please refer to Table 2, which lists possible combinations of combined traffic characteristics.

[0128] Table 2 Examples of Combined Flow Characteristics

[0129] In this context, a combined API call sequence is a sequence formed by calling a first API and at least one historical API in a specific order. For example, a combined API call sequence may include, but is not limited to, combinations of multiple API calls such as logging in, modifying personal information, viewing a list of notification messages, viewing a list of all users, viewing specific space information, editing a personal information page, liking, and posting comments.

[0130] In some solutions, the first API call request and at least one historical API call request in a combined API call sequence do not need to be arranged in chronological order. This is because the detection of abnormal API behavior can focus on more than just the logical order of API calls. For example, in actual implementation, the number of API calls can also reflect abnormal API behavior.

[0131] The following describes some of the combined flow characteristics involved in the embodiments of this application.

[0132] In some possible implementations, combined traffic features include static and / or dynamic features. Static features are statistical features at the granularity of a single API call record, primarily used to describe path-related features and parameter-related features. Specifically, path-related features include one or more of the following: number of paths, depth, uniqueness, proportion, standard deviation, mean, number of paths containing a specified character, or proportion of paths containing a specified character, etc. Parameter-related features include one or more of the following: number of parameters, uniqueness, proportion, standard deviation, or mean, etc.

[0133] For example, please refer to Table 3, which lists several examples of static features.

[0134] Table 3 Examples of Static Features

[0135] Dynamic features are statistical characteristics at the granularity of dynamic combination calls of multiple APIs, mainly used to reflect the interaction patterns and temporal relationships between API calls. Specifically, dynamic features include the number and / or proportion of subsequences in the API call sequence that satisfy the execution of a target operation combination. The target operation combination includes one or more of the following: executing the first operation before the second operation, executing the third operation K times consecutively, or the resource path of the URL accessed first is different from the resource path of the URL accessed later, etc.

[0136] For example, please refer to Table 4, which lists several examples of dynamic features.

[0137] Table 4 Examples of Dynamic Features

[0138] As another example, see Table 5, which provides an example of a user invoking a composite API.

[0139] Table 5. An example of API combination calls.

[0140] Table 5 lists examples of online shopping application scenarios. As can be seen from Table 5, the user starts from " / user / login" and sequentially calls " / product / detail", " / cart / add", and " / order / checkout", forming a complete transaction behavior chain. This transaction chain is a type of dynamic characteristic. For example, if a user calls " / user / login" 10 times consecutively within one minute, or calls " / cart / add" 50 times in the same session, it may indicate an attack (such as brute-force login or malicious order placement).

[0141] By comprehensively analyzing static and dynamic features, a complete picture of API calls can be effectively constructed, thereby providing data support for anomaly detection of subsequent first API call requests.

[0142] In other possible implementations, the anomaly detection method is executed when one or more functions are activated. Optionally, the managing user inputs an activation instruction to the anomaly detection device, which instructs the detection of whether the user's current API call request is abnormal based on the user's current API call request and historical API call requests.

[0143] For example, the anomaly detection system supports an enhanced access control mode, allowing users to actively enable it as needed. The anomaly detection method shown in Figure 2 is implemented when the enhanced access control mode is enabled. Optionally, this enhanced mode also provides flexible access control options. For example, users can set the strictness of detection rules or control operations for API call requests detected as abnormal according to different application scenarios. For example, API call requests can be evaluated for their degree of abnormality; the higher the degree of abnormality, the higher the probability that the API call request is a malicious call. In financial systems, high-sensitivity rules can be enabled to strictly monitor users' trading behavior, such as rejecting API call requests with an abnormality level exceeding a certain low threshold. As another example, in ordinary applications, settings can be configured to perform anomaly control operations on abnormal API call requests when obvious anomalies occur, such as only rejecting APIs with an abnormality level exceeding a certain high threshold.

[0144] Step S203: The anomaly detection device uses the first model to obtain the detection result based on the combined flow characteristics.

[0145] The first model is a pre-trained model, such as an artificial intelligence model or a machine learning model. Optionally, the first model is trained using combined traffic features corresponding to multiple sample API call sequences and the ground truth values ​​of the intent of the multiple sample API call sequences. The sample API call sequences include multiple sample API call requests arranged in chronological order of occurrence, and the ground truth value of the intent of one sample API call sequence is used to indicate whether the intent of that sample API call sequence is abnormal. See the embodiments below for details on training the first model.

[0146] The detection result is used to indicate whether the first API call request is abnormal. For example, the detection result may include a first parameter; when the first parameter takes a first value, it indicates that the first API call request is abnormal, and when it takes a second value, it indicates that the first API call request is normal. Alternatively, the detection result may include a second parameter, which indicates the probability (or degree of abnormality) of the first API call request being abnormal. For example, the value range may be 0-100%, or from level one to level ten, and when the second parameter value is greater than or equal to a certain preset value (e.g., 70% or higher than level seven), it indicates that the first API call request is abnormal.

[0147] In some possible implementations, the LLM generates multiple API call sequences based on API description information and user intent information.

[0148] The API description information includes, but is not limited to, API endpoint description information, API endpoint path, request method, request body, and request headers. User intent information consists of the user's normal and abnormal behavioral intents, used to guide the large model in generating the API call sequence. For example, normal user behavioral intents include, but are not limited to, browsing the homepage, viewing received notifications, viewing personal information, and modifying personal information; abnormal user behavioral intents include, but are not limited to, unauthorized browsing of platform settings pages accessible only to administrators, unauthorized access to pages that remove a user from the system (accessible only to administrators), and unauthorized modification of posts or comments in a space not posted by the user themselves.

[0149] Because LLM can generate enough API call sequences, the first model has sufficient training data.

[0150] In other possible implementations, after obtaining the detection result, the anomaly detection device performs a control operation on the first API call request based on the detection result. For example, if the detection result indicates that the first API call request is normal, a release operation is performed on the first API call request. Alternatively, if the detection result indicates that the first API call request is abnormal, an anomaly control operation is performed on the first API call request. Exemplarily, the anomaly control operation may include at least one of the following: releasing the API call request (i.e., issuing a release), outputting status indication information (i.e., issuing an alarm), or rejecting the API call request (i.e., blocking).

[0151] The following section provides a detailed explanation of the possible designs for control operations.

[0152] Design 1: Based on the detection results, the anomaly detection device performs a single operation on the first API call request. For example, if the detection result indicates that the first API call request is normal, the anomaly detection device only performs a allow operation on the request, allowing the request to continue flowing to the target service. Conversely, if the detection result indicates that the first API call request is abnormal, the anomaly detection device only performs a deny operation on the request, directly preventing it from accessing the target service.

[0153] Design 2: Based on the detection results, the anomaly detection device performs combined operations on the first API call request to provide a more flexible response strategy. For example, if the detection result indicates that the first API call request is normal, the anomaly detection device can simultaneously perform a grant operation and an alarm operation. The alarm operation can send a notification to the user or administrator and record this request as a reference sample, thereby improving the system's behavior model. For instance, when the detection result indicates that the first user's first call to the first API is normal, the business system, while allowing access, will also notify the first user that the request has successfully passed security verification, increasing interaction between the business system and the user and enhancing the user experience.

[0154] Optionally, the control operations performed on the first API call request are defined by the management user through first configuration information, which includes the control operations for the first API call request. For example, the first configuration information predefined by the management user includes: allowing the first API call request when the detection result indicates that the first API call request is normal; and intercepting the first API call request when the detection result indicates that the first API call request is abnormal. Alternatively, the management user can define the first configuration information according to specific business scenarios. For instance, in a financial data management platform, when the detection result indicates that the first API call request is normal, allowing the first API call request while outputting a prompt message to the management user; when the detection result indicates that the first API call request is abnormal, intercepting the first API call request while outputting a prompt message to the management user.

[0155] In the embodiment shown in Figure 2, the anomaly detection device extracts the combined traffic features of the user's current API call request and at least one historical API call request, and uses a first model to detect the combined traffic features to obtain the detection result of the user's current API call request. By combining historical API call requests to analyze whether the user's current API call request is abnormal, anomalies caused by multiple API combined calls can be detected in a timely manner, improving the efficiency of anomaly detection and enabling timely detection of anomalies caused by combined API calls.

[0156] The above-described anomaly detection method provided by the embodiments of this application, in conjunction with Figure 2, is illustrated below with reference to Figure 3, which is a flowchart of a model training method provided by the embodiments of this application.

[0157] Please refer to Figure 3, which is a flowchart illustrating a model training method provided in this application. Optionally, this method can be applied to a model training device. A model training device is a device with data processing capabilities used to train a first model. It is implemented, for example, by hardware and / or software modules of the model training device. For ease of description, the embodiment shown in Figure 3 will be described below using the model training device as the execution entity.

[0158] The model training method shown in Figure 3 may include multiple steps from steps S301 to S303. It should be understood that, for ease of description, the embodiments of this application are described in the order of steps S301 to S303, and are not intended to limit the execution to the above order. The embodiments of this application do not limit the order of the above one or more steps, the execution time, the number of times the steps are executed, etc.

[0159] Step S301: The model training device acquires the user traffic dataset. Specifically, the user traffic dataset includes multiple sample API call sequences and the intent truth values ​​of multiple sample API call sequences. The sample API call sequences reflect the APIs required by the business system when performing business operations. These APIs are provided by the business system to users for invocation. The intent truth values ​​of the sample API call sequences reflect whether the sample API call sequence represents an abnormal situation. Optionally, a true value indicates that the user behavior reflected by the sample API call sequence is abnormal, while a false value indicates that the user behavior reflected by the sample API call sequence is normal.

[0160] Optionally, the APIs provided by the business system can be obtained by capturing network traffic from users' historical API calls. For example, the objects of the captured traffic include, but are not limited to, at least one of the following: the business system's project functions, user interface (UI), existing traffic or project documentation, and project source code. Further, for the application scenario of the first model, historical traffic data under the same or similar application scenarios can also be captured. Still further, the APIs can be expanded based on the captured traffic. For example, based on the captured APIs, using a larger model, more APIs that users might use under this business system can be generated.

[0161] After obtaining the APIs that the business system can call, further analysis is conducted to obtain API description information. API description information mainly includes relevant API parameters. For example, API description information includes, but is not limited to, at least one of the following: API endpoint description information, API endpoint path, request method, request body, and request headers. Optionally, API description information can be API documentation.

[0162] In some possible implementations, the multiple sample API call sequences involved in the user traffic dataset are obtained by the LLM based on API description information and user intent information. The user intent information consists of the user's normal behavioral intent and abnormal behavioral intent, which is used to guide the large model to generate API call sequences. For example, the user's normal behavioral intent includes, but is not limited to, browsing the homepage, browsing received notifications, viewing personal information, and modifying personal information. The user's abnormal behavioral intent includes, but is not limited to, unauthorized browsing of platform settings pages that can only be accessed by administrators, unauthorized access to pages that can remove a user from the system, and unauthorized modification of posts or comments in a space that were not posted by the user.

[0163] In some cases, the LLM generates a preliminary API access sequence based on API description information and user intent information. This preliminary API access sequence includes multiple empty access sequences, where the parameter field values ​​of the API are undefined. For example, please refer to Table 6, which provides examples of preliminary API access sequences in embodiments of this application. Furthermore, sample API access sequences can also be obtained by user-defined preliminary API access sequences.

[0164] Table 6 Examples of Preliminary API Access Sequences

[0165] In some cases, LLM can directly generate sample API access sequences based on API description information and user intent information.

[0166] In other possible implementations, the LLM constructs a user traffic dataset based on prompt words. These prompt words include those used to guide the LLM in generating normal user traffic and those used to guide it in generating abnormal user traffic. Specifically, the prompt word template includes, but is not limited to, the following information: API description of the target project, description of the anomaly detection mechanism (e.g., some APIs can only be accessed by management users), description of the behavioral characteristics of normal and abnormal users, description of general business scenarios (e.g., each normal or malicious user's API call sequence can contain some random normal behaviors), description of the LLM's task, specification of the traffic output format, and parameter filling requirements.

[0167] Step S302: The model training device extracts features from multiple sample API call sequences in the user traffic dataset to obtain combined traffic features corresponding to the multiple sample API call sequences.

[0168] Among them, the combined traffic characteristics mainly reflect the behavior characteristics of APIs when multiple API calls (i.e., sample API call sequences) are combined to achieve a certain function or a certain purpose.

[0169] In some possible implementations, the combined traffic characteristics include static and / or dynamic characteristics.

[0170] Static features are statistical features at the granularity of a single API call record, primarily used to describe path-related features and parameter-related features. Specifically, path-related features include one or more of the following: number of paths, depth, uniqueness, proportion, standard deviation, mean, number of paths containing a specified character, or proportion of paths containing a specified character, etc. Parameter-related features include one or more of the following: number of parameters, uniqueness, proportion, standard deviation, or mean, etc. See the preceding examples for specific examples.

[0171] In other possible implementations, the model training apparatus extracts combined traffic features based on feature configuration information, where the feature configuration information indicates the features to be extracted for each API. For example, the feature configuration information may indicate the number of unique API paths in the extracted combined APIs, the total number of paths, and the number of times the first operation is executed three consecutively. Optionally, the feature configuration information is user-defined, and the user can adjust the combined traffic features. For instance, the user can delete or add features included in the combined traffic features according to the business scenario.

[0172] Step S303: The model training device trains the first model using the combined traffic features corresponding to multiple sample API call sequences and the ground truth of intent for multiple sample API call sequences.

[0173] The first model is a pre-trained model, such as an artificial intelligence model or a machine learning model. It is used to output the intent detection result of the sample API call sequence based on the combined traffic features of the sample API call sequence. The intent detection result is used to indicate whether the predicted intent of the sample API call sequence is abnormal.

[0174] After obtaining the combined traffic features corresponding to multiple sample API call sequences, the model training device trains the first model based on the combined traffic features corresponding to multiple sample API call sequences and the ground truth values ​​of the intent of multiple sample API call sequences.

[0175] In the embodiment shown in Figure 3, the model training device extracts combined traffic features corresponding to multiple sample API call sequences. It then trains a first model using these combined traffic features and the ground truth values ​​of the intent of each sample API call sequence. This first model is used to detect whether a user's current API call is abnormal by combining the user's historical API call history. In this way, the first model can be fully trained, thereby improving the accuracy and efficiency of API call anomaly detection, and enabling timely detection of anomalies caused by combined API calls.

[0176] The anomaly detection method and model training method provided by the embodiments of this application have been described above with reference to Figures 2 and 3. The embodiments shown in Figures 2 and 3 include a variety of possible implementations. A specific anomaly detection method and model training method will be described below with reference to Figures 4 and 6. It should be understood that any logic or terminology not explained below can be found in the descriptions of Figures 2 or 3 above.

[0177] Please refer to Figure 4, which is a flowchart illustrating another anomaly detection method provided in an embodiment of this application. Optionally, this method can be applied to an anomaly detection system, such as the anomaly detection system shown in Figure 1. For example, this method is implemented by the anomaly detection device 101 shown in Figure 1.

[0178] The anomaly detection method shown in Figure 4 may include multiple steps from S401 to S405. It should be understood that, for ease of description, this embodiment describes the process in the order of steps S401 to S405. In actual implementation, it is not intended to limit the execution to the above order. This embodiment does not limit the order, execution time, or number of executions of one or more of the above steps.

[0179] Step S401: Control the access node to record API traffic generated by user behavior.

[0180] Specifically, the API traffic record includes the currently generated API traffic record. In this case, the currently generated API traffic record is regarded as the aforementioned first API call request, and the control access node can be regarded as the aforementioned anomaly detection device.

[0181] For example, the control access node monitors each user's interactions and records detailed API traffic generated by these interactions. These records include, but are not limited to, one or more of the following: API request timestamps, request types, incoming and outgoing data volumes, response times, and the source IP address of the request. For example, the control access node is applied to an open-source social networking software framework to handle API call requests within that framework. This framework supports user management, activity streams, notification systems, multilingual capabilities, and rich security settings, making it suitable for enterprises, educational institutions, interest groups, and non-profit organizations. Therefore, unauthorized access detection and protection are necessary when using this platform to prevent unauthorized users from accessing or modifying other users' private data, maintain system integrity, and enhance user trust in the platform's security.

[0182] Step S402: Control the access node to concatenate real-time API traffic + user traffic records within X minutes.

[0183] Specifically, real-time API traffic refers to a single API call that is currently generated. The anomaly detection device concatenates this traffic with user traffic records from the past X minutes to form combined user traffic, which facilitates subsequent feature extraction from the combined user traffic. The user traffic records from the past X minutes refer to the aforementioned historical API call requests.

[0184] For example, the anomaly detection device merges user traffic generated within 5 minutes (i.e., X = 5 minutes) of the user's current API call request to obtain combined user traffic within 5 minutes. Optionally, the specific value of X is defined by the management user. Specifically, before the control access node records the API traffic generated by user behavior, the management user pre-configures the generation time of the historical user traffic of the area concatenated with the current traffic. For example, the management user can define the value of X according to the specific application scenario. For example, in application scenarios such as finance, online shopping, and cloud storage, because these scenarios have high requirements for network security, the range of X can be designed to be larger, for example, defining X as 10.

[0185] In some cases, managing users requires enabling enhanced access control mode. In enhanced access control mode, the access control node executes step S402. Furthermore, this application can be combined with existing standalone API analysis schemes. For example, if the user has not enabled enhanced access control, the access control node performs access control only for the current standalone API call.

[0186] Step S403: Control the access node to extract user traffic behavior characteristics.

[0187] Specifically, the control access node extracts features from the combined user traffic to obtain user traffic behavior features, which are used to describe the statistical characteristics of the user's API call sequence within X minutes.

[0188] Optionally, user traffic behavior characteristics include dynamic characteristics and static characteristics. For a description of dynamic and static characteristics, please refer to the foregoing.

[0189] Step S404: Control the access node to obtain detection results based on the first model and user traffic behavior characteristics.

[0190] The first model is a pre-trained model, such as an artificial intelligence model or a machine learning model. It is used to analyze user traffic behavior characteristics and generate detection results indicating whether real-time API traffic (the user's current API call requests) is abnormal.

[0191] Specifically, after obtaining user traffic behavior characteristics, the control access node uses the first model to detect them, obtaining a detection result indicating whether the user's current API call request is abnormal. The first model is a pre-trained model used to detect whether the user's current API call request is abnormal.

[0192] Step S405: The control access node performs control operations on the user's current API call request based on the detection results.

[0193] The detection results are used to indicate whether abnormalities have occurred in real-time API traffic.

[0194] Specifically, after receiving the detection results, the control access node performs control operations on the user's current API call request based on the detection results. When the detection results indicate that the user's current API call request is normal, the user's current API call request is allowed. Optionally, while allowing the user's current API call request, a prompt message can also be output to the management user. This prompt message is used to inform the management user that the API call request is normal, thereby improving the user experience. When the detection results indicate that the user's current API call request is abnormal, the control access node performs abnormal control operations on it.

[0195] Anomaly control operations can take many forms, and the specific execution depends on the severity of the anomaly indicated by the detection results. For example, if the detection results indicate that the user's current API call request is completely malicious, the control access node can directly intercept it. Optionally, a prompt message can be output to the management user while performing the interception operation. On the other hand, if the detection results indicate that the user's current API call request is not malicious but has the potential to be malicious, the control access node can first allow the API call request and mark it for later observation. For instance, when a business system calls an API that has not been called before, the first model may detect that the API call request may be abnormal, so it can first allow it and then observe whether there is any possibility of further anomalies.

[0196] Optionally, the aforementioned control operations can be predefined by the management user. The management user can define specific control operations according to specific business scenarios, which can handle exceptions more effectively.

[0197] Figure 4 illustrates a specific anomaly detection method. This method concatenates a user's current API call request with user traffic over X minutes to obtain combined user traffic. Features are then extracted from this combined traffic, and a first model is used to detect these features. Based on the detection results, control operations are executed on the user's API call requests. This approach more effectively detects abnormal API calls and maintains the security of business systems.

[0198] In some possible designs, the anomaly detection scheme shown in the embodiments of this application can be combined with existing API call request anomaly detection schemes. For example, please refer to Figure 5, which is a functional schematic diagram of an access control node provided by an embodiment of this application. The terminology and logic of the embodiment shown in Figure 5 can be found in the anomaly detection methods shown in Figures 2 and / or 4.

[0199] Referring to Figure 5, the access control node, or access control point, includes an execution scheduling module, an access traffic record management module, a feature extraction module, and a user configuration management module.

[0200] The execution scheduling module can implement basic access control functions and / or enhanced access control functions for access traffic. The basic access control functions are implemented by the existing API call request anomaly detection scheme, and the enhanced access control functions are implemented by the scheme of the embodiment of this application.

[0201] The access traffic management module is used to record API access traffic from users. For example, it records the user's current API call requests.

[0202] The feature extraction module is used to extract traffic features, such as extracting features from the combined traffic formed by the user's current traffic and the traffic generated within X minutes. For the extracted features, the access node is controlled to analyze them using a detector (as shown in the first model of the embodiment of Figure 2 or Figure 3).

[0203] The user configuration management module is used to obtain and manage user configuration information. This information includes, but is not limited to, information on enabling enhanced access control mode, the value of X, and one or more of the effective mode. The effective mode refers to the processing operation for the user's current API traffic. For example, if the detection result indicates that the user's current API call request is normal, the module will allow the API call request; if the detection result indicates that the user's current API call request is abnormal, the module will block the API call request.

[0204] In some possible implementations, the access control node can use a basic access control scheme (an existing API call request anomaly detection scheme) or an enhanced access control scheme (the scheme in this application embodiment, such as the scheme shown in Figure 4) for the current API call request. For example, in actual implementation, when the user is not using enhanced access control, the control access node uses basic access control to perform anomaly detection on the user's current API call request. When the user is using enhanced access control, the control access node uses the scheme in this application embodiment to perform anomaly detection on the user's current API call request. In this way, the anomaly detection method provided by this application embodiment can adapt to more business scenarios and improve the detection efficiency of abnormal API calls.

[0205] Please refer to Figure 6, which is a schematic flowchart of another model training method provided in an embodiment of this application. Optionally, this method can be applied to a model training device.

[0206] The model training method shown in Figure 6 may include multiple steps from S601 to S605. It should be understood that, for ease of description, this application describes the process in the order of steps S601 to S605. In actual implementation, it is not intended to limit the execution to the above order. The embodiments of this application do not limit the order, execution time, or number of executions of one or more of the above steps.

[0207] Step S601: The model training device acquires user traffic data.

[0208] Specifically, the anomaly detection device acquires user traffic data using specific tools. For example, it may acquire user traffic data through a specific script gateway. Exemplarily, the model training device can directly obtain user traffic data by extracting existing traffic data. Even more exemplarily, the model training device can construct user traffic data by analyzing the project's functionality. Alternatively, the model training device can also construct user traffic data through reverse engineering of the UI interface. Still alternatively, the model training device can also construct user traffic data based on the project documentation by analyzing the source code.

[0209] Step S602: The model training device obtains API description information based on user traffic data.

[0210] Specifically, after obtaining user traffic data, the anomaly detection device extracts the description information of the relevant APIs. The API description information includes functional descriptions of multiple APIs and parameter fields for multiple APIs. The API description information mainly includes relevant API parameters; for example, it includes, but is not limited to, at least one of the following: API endpoint description information, API endpoint path, request method, request body, and request headers. Optionally, the API description information can be an API documentation document.

[0211] Step S603: The model training device constructs a user traffic dataset based on user intent prompts and using LLM.

[0212] Specifically, user intent information includes positive and negative user intent. Positive user intent includes a description of the user's core purpose in a normal business scenario, while negative user intent includes a description of the user's unauthorized purpose. For example, browsing the homepage or viewing personal information can be defined as positive user intent, while unauthorized browsing of platform settings pages accessible only to administrators or unauthorized access to pages that remove a user from the system can be defined as negative user intent. Based on user intent information, LLM generates sample API call sequences for normal user behavior and sample API call sequences for abnormal user behavior.

[0213] Optionally, LLM needs to utilize prompt words during the generation of sample API call sequences. These prompt words can be obtained based on user intent prompts and API descriptions. Prompt words may include, but are not limited to: a brief explanation of the permission detection mechanism and descriptions of the behavioral characteristics of normal and malicious users, descriptions of general business scenarios, descriptions of the large model's tasks, and specifications of the output format.

[0214] For example, please refer to Table 7, which is an example of the information contained in LLM prompts.

[0215] Table 7. Examples of possible prompt word information

[0216] As mentioned above, the sample API call sequence generated by LLM is simulated and does not represent real user traffic.

[0217] After generating the API call sequence, LLM then generates simulated sample API access traffic based on the sample API call sequence. Based on the user intent corresponding to each sample API call in the simulated sample API access traffic, a user traffic dataset is constructed.

[0218] Step S604: The model training device obtains combined traffic features based on the user traffic dataset.

[0219] Specifically, after obtaining the user traffic dataset, the model training device extracts features from the sample API call sequences in the user traffic dataset to obtain combined traffic features. The combined traffic features reflect the behavioral characteristics of each sample API call sequence. Among them, behavioral features include static features and dynamic features, and descriptions of static features and dynamic features can be found above.

[0220] Optionally, feature configuration information can be used to extract features from sample API call sequences in the user traffic dataset. The feature configuration information specifies the features to be extracted. Optionally, the feature configuration information can be generated by the LLM for recommendation analysis or set by the management user.

[0221] Step S605: The model training device trains the first model using the combined traffic features and the ground truth of user intent corresponding to the combined traffic features.

[0222] Specifically, this API traffic feature includes behavioral features of at least one sample API call sequence. Each sample API call sequence has a corresponding intent truth value, which reflects the normal or abnormal state of the sample API call sequence. The model training device uses the combined traffic features and the corresponding user intent truth values ​​to train the first model.

[0223] Figure 6 illustrates a specific anomaly detection method. Please refer to Figure 7, which is a detailed schematic diagram of the embodiment shown in Figure 6, and describes the process of the embodiment in Figure 6 in more detail. This method utilizes an LLM (Local Management Model) to construct a user traffic dataset for a specific business, extracts features from it, and uses the extracted features to train a first model. The first model is used to detect whether user API call requests are abnormal. In this way, the first model can be fully trained, improving the accuracy and efficiency of API call anomaly detection, and enabling timely detection of anomalies caused by combined API calls.

[0224] In some solutions, anomaly detection methods and model training methods are often used in combination. Please refer to Figure 8, which is a flowchart illustrating a combination of anomaly detection and model training methods provided in an embodiment of this application. The logic and technology of the embodiment shown in Figure 8 are consistent with the anomaly detection method shown in the embodiment of Figure 2, the model training method shown in the embodiment of Figure 3, the anomaly detection method shown in Figure 4, and the model training method shown in Figure 6. Therefore, the embodiment shown in Figure 8 will not be specifically explained here. The embodiment shown in Figure 8 can be applied to anomaly detection systems, such as the anomaly detection system shown in Figure 1, for example, the API traffic unauthorized access detection method implemented by the anomaly detection device 101 in Figure 1. Optionally, in actual implementation, the API traffic unauthorized access detection method and the API traffic unauthorized access detection method shown in Figure 8 can also be implemented by other devices.

[0225] The methods of the embodiments of this application have been described in detail above. The apparatus of the embodiments of this application is provided below. It should be understood that the module division of the apparatus (which may include a system) provided in this application is merely an exemplary illustration of one way to divide the structure of the apparatus. In practical applications, the structure of the apparatus may have other division methods. This application is equally applicable to apparatuses with other division methods but the same function. Furthermore, the apparatus name provided in this application is an exemplary name and can be replaced in specific implementations.

[0226] Please refer to Figure 9, which is a schematic diagram of an anomaly detection device provided in an embodiment of this application. The anomaly detection device 90 can be a standalone device (such as the anomaly detection device 101 shown in Figure 1) or a module within a standalone device, including hardware and / or software modules. This anomaly detection device 90 is used to implement the aforementioned anomaly detection methods, such as the anomaly detection methods shown in Figures 2 and 4. This anomaly detection device 90 can also implement the API traffic unauthorized access detection method shown in Figure 8.

[0227] The anomaly detection device 90 includes an acquisition module 901 and a detection module 902. The acquisition module 901 is used to perform operations such as acquiring data, for example, executing step S201. The detection module is used to perform operations such as feature extraction, utilization, and anomaly control, for example, executing steps S202 to S203.

[0228] In one possible implementation, the acquisition module 901 is used to acquire a first API call request from a first user.

[0229] The detection module 902 is used to extract features from the first API call request and at least one historical API call request to obtain combined traffic features, and to obtain detection results based on the combined traffic features using the first model.

[0230] In another possible implementation, the detection module 902 is further configured to perform an exception control operation on the first API call request if the detection result indicates that the first API call request is abnormal. The exception control operation includes one or more of the following: passing the first API call request, rejecting the first API call request, or outputting status indication information.

[0231] In another possible implementation, the acquisition module 901 is used to acquire first configuration information input by the management user.

[0232] In another possible implementation, the acquisition module 901 is used to acquire the activation indication of the management user input.

[0233] For details of the aforementioned possible implementations, please refer to the specific descriptions in the embodiments of the anomaly detection method above.

[0234] Please refer to Figure 10, which is a schematic diagram of a model training device provided in an embodiment of this application. The model training device 100 can be a standalone device or a module within a standalone device, including hardware and / or software modules. The model training device 100 is used to implement the aforementioned model training methods, such as the model training methods shown in Figures 3 and 6. The model training device can also implement the API traffic privilege escalation detector generation method shown in Figure 8.

[0235] The model training device 100 includes an acquisition module 1001 and a training module 1002. The acquisition module 1001 performs acquisition operations, such as executing step S301. The training module 1002 performs feature extraction, acquisition, utilization, training, based on, and generation operations, such as executing steps S302 to S303.

[0236] In one possible implementation, the acquisition module 1001 is used to acquire a user traffic dataset, and the training module 1002 is used to extract features from multiple sample API call sequences in the user traffic dataset to obtain combined traffic features corresponding to the multiple sample API call sequences and the ground truth of intent of the multiple sample API call sequences, and train a first model using the combined traffic features corresponding to the multiple sample API call sequences and the ground truth of intent of the multiple sample API call sequences.

[0237] In another possible implementation, the acquisition module 1001 is used to acquire API description information of the business system, and the training module 1002 is used to obtain sample API call sequences based on preliminary API access sequences, construct prompt words based on API description information and user intent information, and obtain user traffic datasets based on the prompt words using LLM.

[0238] In another possible implementation, the training module 1002 is used to extract features from multiple sample API call sequences in the user traffic dataset using feature configuration information, so as to obtain combined traffic features corresponding to the multiple sample API call sequences respectively.

[0239] In another possible implementation, the training module 1002 is used to determine the recommended extraction features based on the user traffic dataset.

[0240] The acquisition module 901 and detection module 902 in the aforementioned anomaly detection device 90, as well as the acquisition module 1001 and training module 1002 in the model training device 100, can all be implemented in software or hardware. For example, the implementation of the acquisition module 901 will be described below. Similarly, the implementation of the detection module 902, acquisition module 1001, and training module 1002 can refer to the implementation of the acquisition module 901.

[0241] As an example of a software functional unit, module 901 may include code running on a computing instance. A computing instance may include at least one of a physical host (computing device), a virtual machine, or a container. Further, the aforementioned computing instance may be one or more. For example, module 901 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed within the same region or in different regions. Further, the multiple hosts / virtual machines / containers used to run the code may be distributed within the same availability zone (AZ) or in different AZs, each AZ comprising one or more geographically proximate data centers. Typically, a region may include multiple AZs.

[0242] Similarly, multiple hosts / virtual machines / containers used to run this code can be distributed within the same Virtual Private Cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Communication between two VPCs within the same region, as well as between VPCs in different regions, requires a communication gateway to be set up within each VPC to enable interconnection between VPCs.

[0243] As an example of a hardware functional unit, the acquisition module 901 may include at least one computing device, such as a server. Alternatively, the acquisition module 901 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be implemented using a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.

[0244] The multiple computing devices included in the acquisition module 901 can be distributed in the same region or in different regions. Similarly, the multiple computing devices included in the acquisition module 901 can be distributed in the same Availability Zone (AZ) or in different AZs. Likewise, the multiple computing devices included in the acquisition module 901 can be distributed in the same Virtual Private Cloud (VPC) or in multiple VPCs. These multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0245] It should be noted that, in other embodiments, the acquisition module 901 can be used to execute any step in the anomaly detection method, and the detection module 902 can be used to execute any step in the anomaly detection method. The steps implemented by the acquisition module 901 and the detection module 902 can be specified as needed. By implementing different steps in the anomaly detection method through the acquisition module 901 and the detection module 902, all functions of the anomaly detection device are realized. Similarly, the acquisition module 1001 can be used to execute any step in the model training method, and the training module 1002 can be used to execute any step in the model training method. The steps implemented by the acquisition module 1001 and the training module 1002 can be specified as needed. By implementing different steps in the model training method through the acquisition module 1001 and the training module 1002, all functions of the model training device are realized.

[0246] This application also provides an anomaly detection system, including an anomaly detection device and a model training device.

[0247] An anomaly detection device is used to acquire the current API call request from a first user, extract features from the user's current API call request and at least one historical API call request to obtain combined traffic features, and use a first model to detect whether the user's current API call request is abnormal based on the combined traffic features.

[0248] The model training device is used to acquire user traffic datasets, extract features from multiple sample API call sequences in the user traffic datasets, and train the first model using the combined traffic features corresponding to the multiple sample API call sequences and the ground truth values ​​of the intent of the multiple sample API call sequences.

[0249] Both the anomaly detection device and the model training device can be implemented in software or hardware. For example, the implementation of the anomaly detection device will be described below. Similarly, the implementation of the model training device can refer to the implementation of the anomaly detection device.

[0250] As an example of a software functional unit, an anomaly detection device may include code running on a computing instance. This computing instance can be at least one of a physical host (computing device), a virtual machine, a container, or other computing devices. Furthermore, the aforementioned computing device may be one or more. For example, the anomaly detection device may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the application may be distributed within the same region or in different regions. The multiple hosts / virtual machines / containers used to run the code may be distributed within the same Availability Zone (AZ) or in different AZs, each AZ comprising one or more geographically proximate data centers. Typically, a region may include multiple AZs.

[0251] Similarly, multiple hosts / virtual machines / containers used to run this code can be distributed within the same VPC or across multiple VPCs. Typically, a VPC is set up within a single region. Communication between two VPCs within the same region, and between VPCs in different regions, requires a communication gateway to be set up within each VPC to enable interconnection between VPCs.

[0252] As an example of a hardware functional unit, an anomaly detection device may include at least one computing device, such as a server. Alternatively, the anomaly detection device may also be a device implemented using an ASIC or a PLD. The aforementioned PLD may be implemented using a CPLD, FPGA, GAL, or any combination thereof.

[0253] The anomaly detection device comprises multiple computing devices that can be distributed within the same region or in different regions. Similarly, the multiple computing devices can be distributed within the same Availability Zone (AZ) or in different AZs. Likewise, the multiple computing devices can be distributed within the same Virtual Private Cloud (VPC) or multiple VPCs. These multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0254] This application also provides a computing device. Please refer to Figure 11, which is a schematic diagram of the structure of a computing device provided in this application embodiment. The computing device 110 includes: a connection line 1101, a processor 1102, a memory 1103, and a communication interface 1104. The processor 1102, the memory 1103, and the communication interface 1104 communicate with each other via the connection line 1101. The computing device 110 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in the computing device 110.

[0255] The connection line 1101 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, only one line is used in Figure 11, but this does not imply that there is only one bus or one type of bus. The connection line 1101 can include pathways for transmitting information between various components of the computing device 110 (e.g., processor 1102, memory 1103, and communication interface 1104).

[0256] The processor 1102 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0257] The memory 1103 may include volatile memory, such as random access memory (RAM). The processor 1102 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0258] The memory 1103 stores executable program code, and the processor 1102 executes the executable program code to implement the functions of the aforementioned acquisition module 901 and detection module 902, thereby realizing the anomaly detection method. That is, the memory 1103 stores instructions for executing the anomaly detection method.

[0259] Alternatively, the memory 1103 stores executable program code, which the processor 1102 executes to implement the functions of the aforementioned acquisition module 1001 and training module 1002, thereby realizing the anomaly detection method. That is, the memory 1103 stores instructions for executing the anomaly detection method.

[0260] The communication interface 1104 uses transceiver modules such as, but not limited to, network interface cards and transceivers to enable communication between the computing device 110 and other devices or communication networks.

[0261] This application also provides a computing device cluster. The computing device cluster includes at least one computing device, which may be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device in the computing device cluster may also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0262] Please refer to Figure 12, which is a schematic diagram of a computing device cluster provided in an embodiment of this application. As shown in Figure 11, the computing device cluster 120 includes at least one computing device 110. The memory 1103 of one or more computing devices 110 in the computing device cluster 120 may store instructions for executing the above-described anomaly detection method and / or model training method.

[0263] In some possible implementations, the memories 1103 of one or more computing devices 110 in the computing device cluster 120 may also store partial instructions for executing the aforementioned anomaly detection method and / or model training method. In other words, a combination of one or more computing devices 110 can jointly execute the aforementioned anomaly detection method and / or model training method. It should be noted that the memories 1103 of different computing devices 110 in the computing device cluster 120 may store different instructions, each used to execute a partial function of the code generation system.

[0264] In some possible implementations, one or more computing devices 110 in the computing device cluster 120 can be connected via a network, which can be a wide area network (WAN) or a local area network (LAN). Please refer to Figure 13, which is a schematic diagram of another computing device cluster structure provided in an embodiment of this application. Figure 13 exemplarily illustrates one possible implementation. As shown in Figure 13, computing device 110A and computing device 110B are connected via a network.

[0265] It should be understood that the functions of computing device 110A shown in Figure 12 can also be performed by multiple computing devices 110, and the functions of computing device 110B can also be performed by multiple computing devices 110. The specific deployment method can depend on business needs and the computing power of the computing devices.

[0266] Optionally, the anomaly detection device 101 shown in FIG1 may include the computing device 110 shown in FIG11 and / or the computing device cluster 120 shown in FIG12 (or FIG13).

[0267] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions capable of running on a computing device or stored on any available medium. When the computer program product runs on a computing device, it causes the computing device to execute the model and anomaly detection method and / or model training method described above.

[0268] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium capable of being stored by a computing device, or a data storage device such as a data center containing one or more available media. The aforementioned available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives), etc. The computer-readable storage medium includes instructions that instruct the computing device to execute the model and anomaly detection method and / or model training method described above.

[0269] In addition, a few additional points need to be made regarding this application:

[0270] I. The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of this application.

[0271] 2. Unless otherwise stated, “multiple” means two or more.

[0272] 3. Unless otherwise specified or in case of logical conflict, the terms and / or descriptions in different embodiments of this application are consistent and can be referenced by each other. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships.

[0273] IV. The various numerical designations used in this application are merely for descriptive convenience and are not intended to limit the scope of protection of this application. The magnitude of the serial numbers used in this application does not imply a sequential order of execution; the execution order of each process should be determined by its function and internal logic. For example, the terms "first," "second," "third," "fourth," and other various terminology (if present) in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. Such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein.

[0274] Furthermore, any embodiment or design described in this application as "exemplary" or "for example" should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner for ease of understanding.

[0275] V. The terms “comprising” and “having” and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device that includes a series of steps or modules is not necessarily limited to those steps or modules that are expressly listed, but may include other steps or modules that are not expressly listed or that are inherent to such process, method, product or device.

[0276] VI. In this application, "for indicating" can be understood as "enabling". "Enabling" can include direct enabling and indirect enabling. When describing information for enabling A, it can include whether the information directly enables A or indirectly enables A, but does not necessarily mean that the information carries A.

[0277] The information that enables the information is called the information to be enabled. In the specific implementation process, there are many ways to enable the information to be enabled, such as, but not limited to, directly enabling the information to be enabled, such as the information to be enabled itself or its index. It can also be indirectly enabled by enabling other information, where there is a relationship between the other information and the information to be enabled. It can also enable only a part of the information to be enabled, while the other parts are known or pre-agreed upon. For example, enabling specific information can be achieved by using a pre-agreed (e.g., protocol-defined) arrangement of various pieces of information, thereby reducing enabling overhead to some extent. Simultaneously, common parts of various pieces of information can be identified and enabled uniformly to reduce the enabling overhead caused by individually enabling the same information.

[0278] VII. In this application, "predefined" may include preconfiguration. For example, predefining certain information means that the information is calculated or received in advance before performing an action that uses the information. The "predefined" can be implemented by pre-storing corresponding codes, tables, or other means that can be used to indicate relevant information in the device (e.g., controller or vehicle). This application does not limit the specific implementation method.

[0279] 8. The term "storage" or "preservation" in this application can refer to storage in one or more memory devices. These memory devices can be separately configured or integrated into an encoder, decoder, processor, or communication device. Alternatively, some memory devices can be separately configured, while others can be integrated into a decoder, processor, or communication device. The type of memory can be any form of storage medium, and this is not limited.

Claims

1. An anomaly detection method, characterized in that, It is applied to an anomaly detection device, which is used to process user requests to call the application programming interface (API) of a business system. The business system provides multiple APIs for users to call. The method includes: Obtain a first API call request from a first user, the first API call request being used to request a call to a first API, the first API belonging to the plurality of APIs; Feature extraction is performed on the first API call request and at least one historical API call request to obtain combined traffic features. The at least one historical API call request is a call request made by the first user to at least one API before the first API call request occurred. The at least one API belongs to the plurality of APIs. Using the first model, based on the combined traffic features, a detection result is obtained. The detection result is used to indicate whether the first API call request is abnormal. The first model is a pre-trained model.

2. The method according to claim 1, characterized in that, The method further includes: If the detection result indicates that the first API call request is abnormal, an exception control operation is performed on the first API call request. The exception control operation includes one or more of the following: passing the first API call request, rejecting the first API call request, and outputting status indication information, wherein the status indication information is used to prompt the detection result.

3. The method according to claim 1 or 2, characterized in that, The method further includes: Obtain the first configuration information input by the management user, which is used to indicate the processing operation corresponding to the detection result.

4. The method according to any one of claims 1-3, characterized in that, Before performing feature extraction on the first API call request and at least one historical API call request to obtain combined traffic features, the method further includes: The system obtains an activation indication from the user's input, which is used to instruct the system to detect whether the user's current API call request is abnormal based on the user's current API call request and historical API call requests.

5. The method according to any one of claims 1-4, characterized in that, At least one historical API call request occurred within a first time period, which is defined by the management user; Alternatively, the number of API call requests in at least one historical API call request meets a preset condition, which is defined by the managing user.

6. The method according to any one of claims 1-5, characterized in that, The combined traffic features are used to describe the statistical characteristics of combined API call sequences; The combined API call sequence includes multiple API call requests arranged in chronological order of occurrence, and the multiple API calls include the first API call request and the at least one historical API call request.

7. The method according to any one of claims 1-6, characterized in that, The combined flow characteristics include static characteristics and / or dynamic characteristics. The static features are used to describe statistical features at the granularity of a single API call record. Static features are used to extract path-related features and parameter-related features. The dynamic features are used to describe statistical features at the granularity of dynamic combined calls of multiple APIs.

8. The method according to any one of claims 1-7, characterized in that, The combined flow characteristics include one or more of the following: The number of unique paths, the total number of paths, the number of consecutive repeated paths, the average length of paths, the standard deviation of path lengths, the average depth of paths, the standard deviation of path depths, the proportion of unique paths, the proportion of path depths that satisfy the first condition, the number and / or proportion of paths that include specified characters, the number of unique parameters, the total number of parameters in the access sequence, the average number of parameters, the standard deviation of the number of parameters, and the number and / or proportion of subsequences in the API call sequence that satisfy the combination of executing the target operation. The target operation combination includes one or more of the following: performing the first operation first and then the second operation, performing the third operation K times consecutively, and the resource path of the URL accessed first is different from the resource path of the URL accessed later, where K is a positive integer.

9. The method according to any one of claims 1-8, characterized in that, The first model is trained using the combined traffic features corresponding to multiple sample API call sequences and the intent ground truth of the multiple sample API call sequences. The sample API call sequence includes multiple sample API call requests arranged in chronological order of occurrence. The intent ground truth of a sample API call sequence is used to indicate whether the intent of the sample API call sequence is abnormal.

10. The method according to claim 9, characterized in that, The multiple sample API call sequences are generated by the Large Language Model (LLM) based on API description information and user intent information.

11. A model training method, characterized in that, The method includes: Obtain a user traffic dataset, which includes multiple sample API call sequences and intent truth values ​​of the multiple sample API call sequences. The sample API call sequences include multiple sample API call requests arranged in chronological order of occurrence. The intent truth value of a sample API call sequence is used to indicate whether the intent of the sample API call sequence is abnormal. Feature extraction is performed on multiple sample API call sequences in the user traffic dataset to obtain combined traffic features corresponding to the multiple sample API call sequences respectively; The first model is trained using the combined traffic features corresponding to the multiple sample API call sequences and the ground truth of the intent of the multiple sample API call sequences. The first model is used to output the intent detection result of the user API call sequence based on the combined traffic features of the user API call sequence. The intent detection result is used to indicate whether the predicted intent of the user API call sequence is abnormal.

12. The method according to claim 11, characterized in that, The method further includes: Obtain API description information from the business system, including functional descriptions of multiple APIs and parameter fields of the multiple APIs; Using LLM, a preliminary API access sequence is generated based on the API description information and user intent information. The preliminary API access sequence includes multiple empty access sequences, in which the values ​​of the API parameter fields are undefined. Based on the preliminary API access sequence, a sample API call sequence is obtained, wherein the values ​​of the parameter fields of the API in the sample API call sequence are defined; Based on the API description information and user intent information, prompt words are constructed, wherein the user intent information includes at least one normal user intent and / or at least one abnormal user intent; Using the LLM, the user traffic dataset is obtained based on the prompt words.

13. The method according to claim 11 or 12, characterized in that, The step of extracting features from multiple sample API call sequences in the user traffic dataset to obtain combined traffic features corresponding to each of the multiple sample API call sequences includes: Using feature configuration information, features are extracted from multiple sample API call sequences in the user traffic dataset to obtain combined traffic features corresponding to the multiple sample API call sequences. The feature configuration information is used to indicate the features to be extracted.

14. The method according to claim 13, characterized in that, The feature configuration information includes at least one user-defined feature.

15. The method according to any one of claims 11-14, characterized in that, The method further includes: Based on the user traffic dataset, recommendation extraction features are determined, which are used to prompt users for recommended extraction features.

16. An anomaly detection device, characterized in that, The anomaly detection device includes an acquisition module and a detection module, wherein: The acquisition module is used to acquire a first API call request from a first user, the first API call request is used to request to call a first API, and the first API belongs to the plurality of APIs; The detection module is used to extract features from the first API call request and at least one historical API call request to obtain combined traffic features. The at least one historical API call request is a call request made by the first user to at least one API before the first API call request occurred. The at least one API belongs to the plurality of APIs. The detection module is used to obtain a detection result based on the combined traffic features using the first model. The detection result is used to indicate whether the first API call request is abnormal. The first model is a pre-trained model.

17. The anomaly detection device according to claim 16, characterized in that, The detection module is also used for: If the detection result indicates that the first API call request is abnormal, an exception control operation is performed on the first API call request. The exception control operation includes one or more of the following: passing the first API call request, rejecting the first API call request, and outputting status indication information, wherein the status indication information is used to prompt the detection result.

18. The anomaly detection device according to claim 16 or 17, characterized in that, The acquisition module is also used for: Obtain the first configuration information input by the management user, which is used to indicate the processing operation corresponding to the detection result.

19. The anomaly detection device according to any one of claims 16-18, characterized in that, The acquisition module is also used for: The system obtains an activation indication from the user's input, which is used to instruct the system to detect whether the user's current API call request is abnormal based on the user's current API call request and historical API call requests.

20. The anomaly detection device according to any one of claims 16-19, characterized in that, The combined traffic features are used to describe the statistical characteristics of combined API call sequences; The combined API call sequence includes multiple API call requests arranged in chronological order of occurrence, including the first API call request and the at least one historical API call request.

21. The anomaly detection device according to any one of claims 16-20, characterized in that, The combined flow characteristics include static characteristics and / or dynamic characteristics. The static features are used to describe statistical features at the granularity of a single API call record. Static features are used to extract path-related features and parameter-related features. The dynamic features are used to describe statistical features at the granularity of dynamic combined calls of multiple APIs.

22. The anomaly detection device according to any one of claims 16-21, characterized in that, The first model is trained using the combined traffic features corresponding to multiple sample API call sequences and the intent ground truth of the multiple sample API call sequences. The sample API call sequence includes multiple sample API call requests arranged in chronological order of occurrence. The intent ground truth of a sample API call sequence is used to indicate whether the intent of the sample API call sequence is abnormal.

23. A model training device, characterized in that, The model training device includes an acquisition module and a training module, wherein: The acquisition module is used to acquire a user traffic dataset, which includes multiple sample API call sequences and intent truth values ​​of the multiple sample API call sequences. The sample API call sequence includes multiple sample API call requests arranged in chronological order of occurrence. The intent truth value of a sample API call sequence is used to indicate whether the intent of the sample API call sequence is abnormal. The training module is used for: Feature extraction is performed on multiple sample API call sequences in the user traffic dataset to obtain combined traffic features corresponding to the multiple sample API call sequences respectively; The first model is trained using the combined traffic features corresponding to the multiple sample API call sequences and the ground truth of the intent of the multiple sample API call sequences. The first model is used to output the intent detection result of the user API call sequence based on the combined traffic features of the user API call sequence. The intent detection result is used to indicate whether the predicted intent of the user API call sequence is abnormal.

24. The model training apparatus according to claim 23, characterized in that, The acquisition module is also used to acquire API description information of the business system, the API description information including functional descriptions of multiple APIs and parameter fields of the multiple APIs; The training module is also used for: Using LLM, a preliminary API access sequence is generated based on the API description information and user intent information. The preliminary API access sequence includes multiple empty access sequences, in which the values ​​of the API parameter fields are undefined. Based on the preliminary API access sequence, a sample API call sequence is obtained, wherein the values ​​of the parameter fields of the API in the sample API call sequence are defined; Based on the API description information and user intent information, prompt words are constructed, wherein the user intent information includes at least one normal user intent and / or at least one abnormal user intent; Using the LLM, the user traffic dataset is obtained based on the API call sequence and the prompt words.

25. The model training apparatus according to claim 23 or 24, characterized in that, The training module is also used for: Using feature configuration information, features are extracted from multiple sample API call sequences in the user traffic dataset to obtain combined traffic features corresponding to the multiple sample API call sequences. The feature configuration information is used to indicate the features to be extracted.

26. The model training apparatus according to any one of claims 23-25, characterized in that, The training module is also used for: Based on the user traffic dataset, recommendation extraction features are determined, which are used to prompt users for recommended extraction features.

27. A computing device, characterized in that, The computing device includes a processor and a memory, the memory storing a computer program, and the processor being configured to invoke the computer program stored in the memory to implement the method of any one of claims 1-10, or to implement the method of any one of claims 11-15.

28. A computing device cluster, characterized in that, The computing device cluster includes at least one computing device, and each computing device includes a processor and memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the method of any one of claims 1-10, or to perform the method of any one of claims 11-15.

29. A readable storage medium, characterized in that, The readable storage medium includes computer program instructions that, when executed by a cluster of computing devices, perform the method according to any one of claims 1-10, or perform the method according to any one of claims 11-15.

30. A computer program product containing instructions, characterized in that, When the instructions are executed by the computing device cluster, the apparatus including the processor performs the method of any one of claims 1-10, or performs the method of any one of claims 11-15.

Images