Interface risk detection method, device, equipment, medium and product

Abstract

The invention provides an interface risk detection method and device, equipment, a medium and a product, which can be applied to the technical field of artificial intelligence and the field of financial science and technology. The method comprises the following steps: determining to-be-detected traffic information of a target interface in a to-be-detected time period; determining a first traffic baseline according to historical traffic information of the target interface within a first duration before the to-be-detected time period; determining a first baseline deviation degree between the to-be-detected traffic information and the first traffic baseline; under the condition that the first baseline deviation degree is greater than a first deviation degree threshold value, determining a second traffic baseline according to historical traffic information of the target interface within a second duration before the to-be-detected time period, and determining a second baseline deviation degree between the to-be-detected traffic information and the second traffic baseline; the first duration is smaller than the second duration; determining the interface risk degree of the target interface according to the second baseline deviation degree; the interface risk degree is positively correlated with the second baseline deviation degree.

Description

Technical Field

[0001] This application relates to the fields of artificial intelligence technology and fintech, specifically to an interface risk detection method, apparatus, equipment, medium, and product. Background Technology

[0002] In current business systems, business interfaces often play a crucial role. Specifically, they receive requests from external devices, perform corresponding processing, and provide feedback responses. For example, for an information access request, the business interface needs to perform operations such as authentication, information query, and information feedback, and then return the requested information to the requesting party to complete the request response.

[0003] However, the business interface itself has potential security risks, which may cause the business system to malfunction. For example, if the business interface receives a sudden increase in request traffic, it may lose request traffic due to insufficient storage space; if the business interface receives a large number of invalid requests, it may consume excessive resources.

[0004] Currently, risks to business interfaces can usually only be detected manually, by analyzing information such as traffic logs of the business interfaces. This method is relatively inefficient. Summary of the Invention

[0005] In view of the above problems, embodiments of this application provide an interface risk detection method, apparatus, device, medium, and product, which can improve the efficiency of risk detection for business interfaces.

[0006] According to a first aspect of this application, an interface risk detection method is provided, comprising: determining traffic information to be detected for a target interface during a detection period; determining a first traffic baseline based on historical traffic information of the target interface within a first duration prior to the detection period; determining a first baseline deviation degree between the traffic information to be detected and the first traffic baseline; if the first baseline deviation degree is greater than a first deviation degree threshold, determining a second traffic baseline based on historical traffic information of the target interface within a second duration prior to the detection period, and determining a second baseline deviation degree between the traffic information to be detected and the second traffic baseline; wherein the first duration is less than the second duration; determining the interface risk level of the target interface based on the second baseline deviation degree; wherein the interface risk level is positively correlated with the second baseline deviation degree.

[0007] According to an embodiment of this application, the method further includes: based on a pre-trained anomaly detection model, detecting traffic anomaly information for the traffic information to be detected, and determining the degree of anomaly risk of the traffic anomaly information; the step of determining the interface risk degree of the target interface based on the degree of deviation from the second baseline includes: determining the interface risk degree of the target interface based on the degree of deviation from the second baseline and the degree of anomaly risk; the determined interface risk degree is positively correlated with the degree of anomaly risk.

[0008] According to an embodiment of this application, determining the interface risk level of the target interface based on the second baseline deviation includes any one of the following: determining the interface risk level of the target interface based on the first baseline deviation and the second baseline deviation; determining the interface risk level of the target interface based on the second baseline deviation when the second baseline deviation is greater than a second deviation selection threshold; and determining the interface risk level of the target interface based on the first baseline deviation when the second baseline deviation is less than or equal to the second deviation selection threshold.

[0009] According to an embodiment of this application, the traffic information includes request information, and the method further includes: determining first abnormal request information based on the first traffic baseline in the traffic information to be detected, and determining a first request risk level of the first abnormal request information; the deviation between the first abnormal request information and the first traffic baseline is greater than a first request deviation threshold; determining the interface risk level of the target interface based on the second baseline deviation includes: determining the interface risk level of the target interface based on the second baseline deviation and the first request risk level; the interface risk level is positively correlated with the first request risk level.

[0010] According to an embodiment of this application, the traffic information includes request information, and the method further includes: when the deviation of the second baseline is greater than a second deviation abnormality threshold, determining second abnormal request information based on the second traffic baseline in the traffic information to be detected, and determining a second request risk level of the second abnormal request information; the deviation between the second abnormal request information and the second traffic baseline is greater than a second request deviation threshold; determining the interface risk level of the target interface based on the second baseline deviation includes: determining the interface risk level of the target interface based on the second baseline deviation and the second request risk level; the interface risk level is positively correlated with the second request risk level.

[0011] According to an embodiment of this application, determining the interface risk level of the target interface based on the degree of deviation from the second baseline includes: determining the interface risk level of the target interface based on the degree of deviation from the second baseline and at least one of the following: the business impact scope and business importance of the target interface; the interface risk level is positively correlated with the business impact scope of the target interface; the interface risk level is positively correlated with the business importance of the target interface.

[0012] According to an embodiment of this application, determining a first traffic baseline based on the historical traffic information of the target interface within a first duration prior to the detection period includes: determining a first historical traffic time sequence based on a sliding window for the historical traffic information of the target interface within the first duration prior to the detection period; and determining a first traffic baseline based on the first historical traffic time sequence. Determining a second traffic baseline based on the historical traffic information of the target interface within a second duration prior to the detection period includes: determining a second historical traffic time sequence based on a sliding window for the historical traffic information of the target interface within the second duration prior to the detection period; and determining a second traffic baseline based on the second historical traffic time sequence.

[0013] According to embodiments of this application, the method further includes at least one of the following: when the second baseline deviation is greater than a second deviation root cause threshold, determining the baseline deviation root cause based on the traffic information to be detected and / or the code semantics of the target interface; when the interface risk level is greater than a preset interface risk threshold, determining the interface risk root cause based on the traffic information to be detected and / or the code semantics of the target interface.

[0014] According to a second aspect of this application, an interface risk detection device is provided, comprising: an information module for determining traffic information to be detected of a target interface during a detection period; a first module for determining a first traffic baseline based on historical traffic information of the target interface within a first duration prior to the detection period; and determining a first baseline deviation degree between the traffic information to be detected and the first traffic baseline; and a second module for determining a second traffic baseline based on historical traffic information of the target interface within a second duration prior to the detection period, and determining a second baseline deviation degree between the traffic information to be detected and the second traffic baseline, provided that the first baseline deviation degree is greater than a first deviation degree threshold; the first duration is less than the second duration; and the interface risk level of the target interface is determined based on the second baseline deviation degree; the interface risk level is positively correlated with the second baseline deviation degree.

[0015] According to a third aspect of this application, an electronic device is provided, comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0016] According to a fourth aspect of this application, a computer-readable storage medium is also provided, on which a computer program or instructions are stored, wherein the computer program or instructions, when executed by a processor, implement the steps of the above-described method.

[0017] According to a fifth aspect of this application, a computer program product is also provided, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method. Attached Figure Description

[0018] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0019] Figure 1 This illustration schematically depicts an application scenario of an interface risk detection method according to an embodiment of this application.

[0020] Figure 2 The flowchart of an interface risk detection method according to an embodiment of this application is illustrated schematically;

[0021] Figure 3 This schematic diagram illustrates a structural block diagram of an interface risk detection device according to an embodiment of this application;

[0022] Figure 4 A block diagram schematically illustrates an electronic device suitable for implementing an interface risk detection method according to an embodiment of this application. Detailed Implementation

[0023] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0024] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0025] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0026] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0027] In current business systems, business interfaces often play a crucial role. Specifically, they receive requests from external devices, perform corresponding processing, and provide feedback responses. For example, for an information access request, a business interface needs to perform authentication, information query, and information feedback operations, returning the requested information to the requesting party to complete the request response. However, business interfaces themselves have potential security risks, which may cause the business system to malfunction. For instance, if the business interface receives a sudden increase in request traffic, it may experience request traffic loss due to insufficient storage space; if it receives a large number of invalid requests, it may consume excessive resources. Currently, risks associated with business interfaces are typically detected manually, using information such as traffic logs, which is relatively inefficient.

[0028] To address the aforementioned technical problems, embodiments of this application provide an interface risk detection method. In this method, traffic information of the target interface (referred to as the target interface for ease of description) can be obtained for detection. Specifically, automatic detection can be performed using machine learning models (large models, etc.) to determine the risks of the business interface and improve the efficiency of interface risk detection.

[0029] Furthermore, standards for risk detection can be dynamically developed for the target interface. Specifically, a traffic baseline can be determined based on historical traffic information for the target interface. This baseline can include various aspects of historical traffic information, such as the changing patterns of historical traffic, the distribution of request types, the distribution of request-response results, high-frequency request types, high-frequency request parameters, and high-frequency request-response results. The traffic baseline can characterize the basic situation of historical traffic information and thus serve as a standard to detect any abrupt changes in the recent traffic information of the target interface. If the detection determines that the recent traffic information of the target interface differs significantly from the traffic baseline, it can be determined that there is an abrupt change in the recent traffic information of the target interface, thereby identifying a certain level of risk at the target interface. Specific examples of such abrupt changes include: a significant difference between the request type distribution in recent traffic information and the historical request type distribution; a much higher number of requests in recent traffic information than the maximum number of requests in historical traffic; and a much higher request frequency in recent traffic information than the maximum request frequency in historical traffic.

[0030] By establishing a dynamic traffic baseline based on the historical traffic information of the target interface, it is possible to automatically detect the risks of the target interface based on its condition, thereby improving the efficiency and accuracy of interface risk detection.

[0031] In the above method, to further improve the efficiency of interface risk detection, a traffic baseline can be initially determined based on limited historical traffic information, specifically, a traffic baseline based on recent historical traffic information within a short period. If the recent traffic information of the target interface deviates little from this traffic baseline, the target interface can be determined to have a low risk, eliminating the need for subsequent risk detection operations and improving the efficiency of interface risk detection. If the recent traffic information of the target interface deviates significantly from this traffic baseline, the target interface can be determined to have a high risk. To improve the accuracy of interface risk detection, more historical traffic information can be obtained to determine another traffic baseline, specifically, based on historical traffic information over a longer period. If the recent traffic information of the target interface deviates significantly from this traffic baseline, the target interface can be determined to have a high risk. If the recent traffic information of the target interface deviates little from this traffic baseline, the target interface can be determined to have a relatively low risk.

[0032] Therefore, by combining the recent traffic information of the target interface with the deviation between the two determined traffic baselines, the risk of the target interface can be determined, thereby improving the efficiency and accuracy of risk detection for the target interface.

[0033] In the methods described above, determining the specific risks of a target interface can be further enhanced by incorporating more information. Specifically, this includes anomaly information from the target interface's recent traffic data (such as invalid traffic consuming excessive resources or sudden spikes and drops in traffic), abnormal request information from the target interface's recent traffic data (such as successful unauthorized requests or invalid requests frequently initiated by the same party), the business impact scope of the target interface, and the business importance of the target interface. By increasing the amount and dimensions of the information provided, the accuracy and comprehensiveness of interface risk assessment can be improved.

[0034] In addition to the methods described above, if the target interface is determined to be high-risk, further root cause analysis can be performed. Specifically, machine learning models, such as large-scale models, can be used to analyze the recent traffic information or code semantics of the target interface to identify the causes of high risk. Alternatively, other information can be combined with root cause analysis, such as abnormal request information in the recent traffic data of the target interface. Root cause analysis can improve the accuracy and comprehensiveness of interface risk detection, facilitating subsequent remediation of the target interface, enhancing its security, and reducing its risk.

[0035] It should be noted that the interface risk detection method and apparatus provided in the embodiments of this application can be applied to the fields of artificial intelligence technology and fintech. For example, for financial institutions such as banks, the interface risk detection method provided in the embodiments of this application can be used to detect potential risks in the developed business interfaces, facilitating remediation. The interface risk detection method and apparatus provided in the embodiments of this application can also be applied to any field other than fintech. For business interfaces in any field, the interface risk detection method provided in the embodiments of this application can be used for risk detection, and the application field of the interface risk detection method and apparatus provided in the embodiments of this application is not limited.

[0036] As used in this paper, the term "model" refers to a model that learns the relationship between inputs and outputs from training data, enabling it to generate corresponding outputs for a given input after training. Model generation can be based on machine learning techniques. Deep learning is a machine learning algorithm that processes inputs and provides corresponding outputs using multiple layers of processing units. A neural network model is an example of a deep learning-based model. In this paper, "model" may also be referred to as a "machine learning model," "learning model," "machine learning network," or "learning network," and these terms are used interchangeably.

[0037] It's important to note that the term "neural network" can refer to a machine learning network based on deep learning. A neural network processes input and provides corresponding output, typically consisting of an input layer, an output layer, and one or more hidden layers between them. Neural networks used in deep learning applications often include many hidden layers, increasing the network's depth. The layers of a neural network are connected sequentially, so that the output of the previous layer serves as the input to the next layer. The input layer receives the input to the neural network, while the output layer's output becomes the final output. Each layer of a neural network includes one or more nodes (also called processing nodes or neurons), each processing the input from the layer above.

[0038] It should be understood that machine learning generally includes three phases: training, testing, and application (also known as inference). In the training phase, a given model is trained using a large amount of training data, iteratively updating parameter values ​​until the model can consistently generate inferences that meet the expected goals from the training data. Through training, the model can be considered to have learned the relationship between inputs and outputs (also known as the input-output mapping) from the training data. The parameter values ​​of the trained model are determined. In the testing phase, test inputs are applied to the trained model to test whether it can provide the correct output, thus determining the model's performance. In the application phase, the model can be used to process actual inputs based on the trained parameter values ​​to determine the corresponding output.

[0039] In one or more embodiments described herein, the term "large model" can refer to a deep learning model with a large number of model parameters, which can include hundreds of millions, tens of billions, hundreds of billions, trillions, or even tens of trillions of model parameters. Large models can also be called foundational models or basic models. They are pre-trained using large-scale unlabeled corpora to produce pre-trained models with hundreds of millions of parameters. Such models can adapt to a wide range of downstream tasks and have good generalization ability, such as large language models and multimodal pre-trained models. It should be understood that in practical applications, large models only require a small number of samples to fine-tune the pre-trained model before being applied to different tasks. Large models can be widely used in natural language processing, computer vision, and other fields. Specifically, they can be applied to computer vision tasks such as visual question answering, image captioning, and image generation, as well as natural language processing tasks such as text-based sentiment classification, text summarization, and machine translation. Major application scenarios for large models can include digital assistants, intelligent robots, search, online education, office software, e-commerce, and intelligent design.

[0040] Figure 1 The illustration depicts an application scenario of an interface risk detection method according to an embodiment of this application. For example... Figure 1As shown, application scenario 100 according to an embodiment of this application may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables. For example, a user can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 through the network 104 to receive or send information, etc.

[0041] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be electronic devices such as smartphones, wearable devices, personal computers, intelligent voice interaction devices, smart home appliances, intelligent vehicles, in-vehicle terminals, aircraft, unmanned vending terminals, and extended reality devices. Extended reality devices can include virtual reality devices, augmented reality devices, and mixed reality devices. A client application for the target application can be installed and run on the terminal devices. This target application can include, but is not limited to, financial transaction applications, payment applications, shopping applications, web browser applications, search applications, instant messaging tools, email clients, and social media platform software (these are just examples). Furthermore, this application embodiment does not limit the form of the target application, and it can include, but is not limited to, applications, mini-programs, etc., installed on the terminal devices, and can also be in the form of web pages.

[0042] Server 105 can be a server providing various services, such as a backend management server supporting websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process received user requests and other data, and feed back the processing results (such as web pages, information, or data obtained or generated based on user requests) to the terminal devices. Server 105 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. Specifically, it can be a cloud server providing basic cloud computing services such as cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks, and big data. Server 105 can be the backend server for the aforementioned target application, used to provide backend services to the client of the target application.

[0043] It should be noted that the interface risk detection method provided in this application embodiment can generally be executed by server 105 and / or terminal devices 101-103. Correspondingly, the interface risk detection device provided in this application embodiment can generally be set in server 105 and / or terminal devices 101-103.

[0044] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0045] Figure 2 A flowchart illustrating an interface risk detection method according to an embodiment of this application is shown. Figure 2 As shown, an interface risk detection method 200 according to an embodiment of this application may include steps S210 to S230.

[0046] In step S210, the traffic information to be detected for the target interface during the detection period is determined.

[0047] In step S220, a first traffic baseline is determined based on the historical traffic information of the target interface within a first time period before the detection period; the degree of deviation between the traffic information to be detected and the first traffic baseline is determined.

[0048] In step S230, if the deviation of the first baseline is greater than the first deviation threshold, the second traffic baseline is determined based on the historical traffic information of the target interface within a second time period before the detection period, and the deviation of the second baseline between the traffic information to be detected and the second traffic baseline is determined; the first time period is less than the second time period; the interface risk level of the target interface is determined based on the deviation of the second baseline; the interface risk level is positively correlated with the deviation of the second baseline.

[0049] This method can dynamically determine the traffic baseline based on the historical traffic information of the target interface, and automatically perform interface risk detection by combining the traffic information to be detected of the target interface, which can improve the efficiency, real-time performance and accuracy of interface risk detection.

[0050] The embodiments of this application do not limit the target interface. Optionally, the target interface can be any business interface that needs to be risk-detected, specifically any business interface in any business system. For example, the target interface can be an interface that implements login authentication, an interface that implements information access, or an interface that implements database query functions, etc. It is understood that the above method flow explains the determination of the interface risk level for a single target interface. The risk level of different interfaces in the target business system (any business system) can be determined separately, and the overall system risk level of the target business system can be determined by combining the interface risk levels of different interfaces.

[0051] The embodiments of this application do not limit the time period to be detected. Optionally, the time period to be detected can be a time period of a preset duration before the current time, or any time period that requires risk detection.

[0052] The embodiments of this application do not limit the traffic information to be detected. Optionally, the traffic information to be detected may include at least one of the following: request-related information received by the target interface (number of requests received by the target interface, request reception frequency, request parameters, request type distribution, etc.), result-related information of the target interface in response to the requests (response result type distribution, response result parameters, etc.), traffic log information of the target interface, etc.

[0053] Optionally, regarding the above method, if the deviation from the first baseline is less than or equal to a first deviation threshold, the interface risk level of the target interface can be determined based on the deviation from the first baseline. The interface risk level can be positively correlated with the deviation from the first baseline. It is understood that if the deviation from the first baseline is small, the interface risk of the target interface can be determined to be low, eliminating the need to determine a second traffic baseline, thereby improving the efficiency of interface risk detection.

[0054] The embodiments of this application do not limit the first flow baseline and the second flow baseline.

[0055] Optionally, a first traffic baseline is determined based on the historical traffic information of the target interface within a first duration prior to the detection period. Specifically, the first traffic baseline can be determined solely based on the historical traffic information of the target interface within the first duration prior to the detection period, or it can be determined based on the historical traffic information of the target interface within a first duration prior to the end of the detection period. It is understood that the historical traffic information used to determine the first traffic baseline may include the traffic information to be detected. Correspondingly, the historical traffic information used to determine the second traffic baseline may also include the traffic information to be detected.

[0056] In a specific example, the period to be detected could be the time period of the target interface one hour prior to the current time. Correspondingly, a first traffic baseline can be determined based on the historical traffic information of the target interface within the 24 hours prior to the current time, and a second traffic baseline can be determined based on the historical traffic information of the target interface within the 30 days prior to the current time. It is understood that the historical traffic information used to determine the second traffic baseline includes the historical traffic information used to determine the first traffic baseline, and contains more information than the historical traffic information used to determine the first traffic baseline. The accuracy of the second traffic baseline can be higher than that of the first traffic baseline. Therefore, even if the deviation between the traffic information to be detected and the first traffic baseline exceeds a threshold, a more accurate and comprehensive second traffic baseline can be used for a second comparison, improving the accuracy and comprehensiveness of interface risk detection.

[0057] Optionally, the traffic baseline can include various aspects of historical traffic information, such as the changing patterns of historical traffic, the number of requests in historical traffic, the request frequency in historical traffic, the distribution of request types in historical traffic, the distribution of request response results in historical traffic, high-frequency request types in historical traffic, high-frequency request parameters in historical traffic, and high-frequency request response results in historical traffic. The traffic baseline can serve as a standard to determine whether the traffic information to be detected has undergone a sudden change compared to historical traffic information.

[0058] The embodiments of this application do not limit the method of determining the first flow baseline and the second flow baseline.

[0059] Optionally, a first traffic baseline and a second traffic baseline can be extracted from historical traffic information according to preset rules; alternatively, a first traffic baseline and a second traffic baseline can be generated based on historical traffic information using a pre-trained baseline generation model (such as a large model or other machine learning model).

[0060] Optionally, historical traffic information can be preprocessed, specifically by using a sliding window for serialization to extract temporal variation features from the historical traffic information. Therefore, optionally, a first traffic baseline is determined based on the historical traffic information of the target interface within a first time period prior to the detection period. This can specifically include: determining a first historical traffic time series based on a sliding window for the historical traffic information of the target interface within the first time period prior to the detection period; and determining the first traffic baseline based on the first historical traffic time series. Optionally, a second traffic baseline is determined based on the historical traffic information of the target interface within a second time period prior to the detection period. This can specifically include: determining a second historical traffic time series based on a sliding window for the historical traffic information of the target interface within the second time period prior to the detection period; and determining the second traffic baseline based on the second historical traffic time series. This embodiment can facilitate the extraction of temporal variation features from historical traffic information through serialization processing, improving the efficiency and accuracy of traffic baseline generation.

[0061] Understandably, by dynamically formulating a traffic baseline based on the historical traffic information of the target interface, the real-time performance and accuracy of the traffic baseline can be improved, making it more suitable for the target interface and increasing its adaptability to the target interface, thus facilitating the improvement of the accuracy of interface risk detection.

[0062] The embodiments of this application do not limit the specific methods for determining the degree of deviation of the first baseline and the degree of deviation of the second baseline. Optionally, relevant features in the traffic information to be detected can be extracted and compared with the first traffic baseline to determine the degree of deviation of the first baseline; alternatively, relevant features in the traffic information to be detected can be extracted and compared with the second traffic baseline to determine the degree of deviation of the second baseline. In a specific example, the request type distribution in the traffic information to be detected can be extracted and compared with the request type distribution in the first traffic baseline. If it is determined that the request type distribution has changed significantly, showing a large difference, specifically, an abnormal increase in a certain type of request, then the degree of deviation of the first baseline can be determined to be high. Optionally, a pre-trained machine learning model, such as a neural network model or a large model, can also be used to compare the input traffic baseline and the traffic information to be detected to predict and determine the degree of baseline deviation.

[0063] The above embodiments explain the first traffic baseline and the second traffic baseline. The following explains the determination of the interface risk level.

[0064] The embodiments of this application do not limit the specific method for determining the interface risk level of the target interface. On the one hand, they do not limit the information on which the interface risk level is determined, and on the other hand, they do not limit the specific operation for determining the interface risk level.

[0065] Optionally, the degree of interface risk can be determined by combining the previously determined deviations from the first baseline and / or the second baseline, or by combining attributes such as the business importance of the target interface itself. Specifically, determining the degree of interface risk can be done using a weighted summation method or by using machine learning models for prediction, such as pre-trained neural network models or large models.

[0066] The following provides several different embodiments for determining the risk level of an interface. It is understood that different embodiments can be combined with each other to comprehensively determine the risk level of an interface.

[0067] In an optional embodiment, anomaly detection can be performed on the traffic information to be detected, and the results of the anomaly detection can be used as information to determine the level of risk of the interface. Specific traffic anomalies can be abnormal changes in traffic or a high proportion of invalid traffic.

[0068] Optionally, the above method may further include: based on a pre-trained large-scale anomaly detection model, detecting traffic anomaly information for the traffic information to be detected and determining the degree of anomaly risk of the traffic anomaly information; determining the interface risk level of the target interface based on the degree of deviation from the second baseline, specifically including: determining the interface risk level of the target interface based on the degree of deviation from the second baseline and the degree of anomaly risk; the determined interface risk level is positively correlated with the degree of anomaly risk. This embodiment can combine the risk of traffic anomalies to determine interface risk, which can increase the amount and dimension of information on the basis of interface risk detection, and improve the accuracy and comprehensiveness of interface risk detection.

[0069] The embodiments of this application do not limit the types of traffic anomaly information and the methods for detecting it. Optionally, a large-scale anomaly detection model or other machine learning models can be used to detect various aspects of traffic anomaly information in the traffic information to be detected, such as abnormal traffic changes, abnormal traffic proportions, and abnormal traffic types. In a specific example, the target interface may be subjected to a traffic attack, specifically an attack on the target interface through a large amount of invalid traffic. The model can then be used to extract abnormal features, i.e., traffic anomaly information, from the traffic information to be detected. Alternatively, based on the large-scale anomaly detection model, semantic information can be extracted from the request and response information in the traffic information to be detected for anomaly detection to determine the traffic anomaly information. Of course, other methods for detecting traffic anomaly information can also be used. For example, based on a risk rule base or attack rule base, rule matching can be performed with the traffic information to be detected to determine traffic anomaly information that conforms to any risk rule or attack rule. Specifically, this could be high-frequency requests initiated by the same attacker, or request information that conforms to injection attack rules, etc.

[0070] The embodiments of this application do not limit the large-scale anomaly detection model and the model training method. Optionally, the large-scale anomaly detection model can be obtained by fine-tuning a general large-scale model. Specifically, training samples can be constructed based on traffic information labeled with traffic anomaly information for fine-tuning training of the large-scale anomaly detection model.

[0071] The embodiments of this application do not limit the method of determining the degree of anomaly risk. Optionally, an anomaly detection large-scale model or other machine learning models can be used to determine the degree of anomaly risk of traffic anomaly information. Specifically, this can be done by determining the severity of the traffic anomaly information or by determining the proportion of traffic information with anomalies in the traffic information to be detected, and thus determining the degree of anomaly risk accordingly. The degree of anomaly risk can be positively correlated with the severity of the traffic anomaly information or the proportion of traffic information with anomalies in the traffic information to be detected.

[0072] The embodiments of this application are not limited to the method of determining the interface risk level based on the degree of deviation from the second baseline and the degree of abnormal risk. Optionally, machine learning models such as neural network models can be used to predict and determine the interface risk level based on the input degree of deviation from the second baseline and the degree of abnormal risk; alternatively, the weighted sum between the degree of deviation from the second baseline and the degree of abnormal risk can be used to determine the interface risk level.

[0073] In one alternative embodiment, the degree of interface risk can be determined by combining the degree of deviation from the first baseline and the degree of deviation from the second baseline.

[0074] Optionally, the interface risk level of the target interface is determined based on the degree of deviation from the second baseline, including any one of the following: (1) determining the interface risk level of the target interface based on the degree of deviation from the first baseline and the degree of deviation from the second baseline; (2) determining the interface risk level of the target interface based on the degree of deviation from the second baseline when the degree of deviation from the second baseline is greater than the second deviation level selection threshold; and determining the interface risk level of the target interface based on the degree of deviation from the first baseline when the degree of deviation from the second baseline is less than or equal to the second deviation level selection threshold. This embodiment can combine the degree of deviation from the first baseline and the degree of deviation from the second baseline to determine the interface risk level, which can increase the amount and dimension of information on the basis of interface risk detection and improve the accuracy of interface risk detection.

[0075] It is understandable that, specifically, machine learning models such as neural network models can be used to predict and determine the degree of interface risk based on the degree of deviation from the first baseline and the degree of deviation from the second baseline; alternatively, the weighted sum between the degree of deviation from the first baseline and the degree of deviation from the second baseline can be used to determine the degree of interface risk.

[0076] If the traffic information to be detected deviates significantly from the second traffic baseline, interface risk detection can be performed by combining the deviations from the first and second baselines. Optionally, if the deviation from the second baseline exceeds a second deviation threshold, the interface risk level of the target interface can be determined based on the deviations from the first and second baselines.

[0077] If the traffic information to be detected deviates slightly from the second traffic baseline, since it has been determined that the traffic information to be detected deviates significantly from the first traffic baseline, interface risk detection can be performed based on the degree of deviation from the first baseline. Of course, interface risk detection can also be performed by combining the degree of deviation from the second baseline or other information.

[0078] Furthermore, the weighting of the first and second baseline deviations can be adjusted accordingly based on whether the second baseline deviation exceeds a threshold. Optionally, if the second baseline deviation exceeds a second deviation threshold, the weight of the second baseline deviation can be set to be greater than the weight of the first baseline deviation, and the interface risk level of the target interface can be determined based on the weighted sum of the first and second baseline deviations. Optionally, if the second baseline deviation is less than or equal to the second deviation threshold, the weight of the second baseline deviation can be set to be less than the weight of the first baseline deviation, and the interface risk level of the target interface can be determined based on the weighted sum of the first and second baseline deviations.

[0079] In one optional embodiment, abnormal request information deviating from the traffic baseline can be further detected and determined from request information in the traffic information (e.g., request content, request parameters, request semantic information, request response results, request response logs, etc.). Specifically, this includes invalid requests, unauthorized requests, or requests whose request parameters differ significantly from those in historical traffic. Interface risk detection is then performed based on the risk of these abnormal requests. It is understood that these abnormal requests may pose interface risks and could be abnormal requests sent by an attacker.

[0080] Optionally, the traffic information includes request information, and the above method flow may further include: determining first abnormal request information based on a first traffic baseline in the traffic information to be detected, and determining the first request risk level of the first abnormal request information; the deviation between the first abnormal request information and the first traffic baseline is greater than a first request deviation threshold; determining the interface risk level of the target interface based on the second baseline deviation, specifically including: determining the interface risk level of the target interface based on the second baseline deviation and the first request risk level; the interface risk level is positively correlated with the first request risk level. This embodiment can combine the first traffic baseline to detect the risk of abnormal requests for interface risk detection, which can increase the amount and dimension of information on the basis of interface risk detection and improve the accuracy of interface risk detection.

[0081] The embodiments of this application do not limit request information and abnormal request information. Optionally, request information may include at least one of the following: request content, request parameters, request semantic information, request response result, request response log, etc. Abnormal request information may specifically include, for example, information about invalid requests, request response results with errors, request response logs with errors, information about requests that successfully exceeded privileges, etc.

[0082] The embodiments of this application do not limit the method of determining abnormal request information. Optionally, the request information contained in the traffic information to be detected can be compared with a first traffic baseline (or a second traffic baseline) to determine abnormal request information that deviates from the first traffic baseline. The degree of deviation between the first abnormal request information and the first traffic baseline can be greater than a first request deviation threshold. Optionally, abnormal request information can also be determined from the traffic information to be detected by combining large-scale machine learning models.

[0083] The embodiments of this application do not limit the method of determining the risk level of a request. Optionally, machine learning models such as neural network models can be used to determine the risk level of abnormal request information. Specifically, the risk level can be determined based on attributes such as the severity, business impact, and business importance of the abnormal request information. The risk level of a request can be positively correlated with the severity, business impact, and business importance of the abnormal request information.

[0084] The embodiments of this application do not limit the specific method of determining the interface risk level based on the request risk level. Optionally, machine learning models such as neural network models can be used to predict and determine the interface risk level based on the input second baseline deviation level and request risk level (first request risk level); alternatively, the weighted sum between the second baseline deviation level and request risk level (first request risk level) can be used to determine the interface risk level.

[0085] Accordingly, abnormal request information deviating from the second traffic baseline can be determined. Optionally, in the traffic information to be detected, second abnormal request information is determined based on the second traffic baseline, and the second request risk level of the second abnormal request information is determined; the deviation between the second abnormal request information and the second traffic baseline is greater than a second request deviation threshold; based on the deviation from the second baseline, the interface risk level of the target interface is determined, which may specifically include: determining the interface risk level of the target interface based on the deviation from the second baseline and the second request risk level; the interface risk level is positively correlated with the first request risk level. The explanation of this embodiment can be found in the explanations of other embodiments.

[0086] In one optional embodiment, if the deviation from the second baseline is higher than a threshold, the target interface can be determined to have a high risk, and abnormal request information can be extracted accordingly to facilitate interface risk detection based on more comprehensive information. Conversely, if the deviation from the second baseline is lower than the threshold, abnormal request information can be left undetermined, improving the efficiency of interface risk detection.

[0087] Therefore, optionally, the traffic information includes request information, and the above method flow may further include: when the deviation of the second baseline is greater than the second deviation abnormality threshold, determining the second abnormal request information in the traffic information to be detected based on the second traffic baseline, and determining the second request risk level of the second abnormal request information; the deviation between the second abnormal request information and the second traffic baseline is greater than the second request deviation threshold; determining the interface risk level of the target interface based on the deviation of the second baseline, specifically including: determining the interface risk level of the target interface based on the deviation of the second baseline and the second request risk level; the interface risk level is positively correlated with the second request risk level. This embodiment can detect the risk of abnormal requests in conjunction with the second traffic baseline for interface risk detection, which can increase the amount and dimension of information on the basis of interface risk detection, improve the accuracy of interface risk detection, and improve the efficiency of interface risk detection by setting operation branches based on whether the deviation of the second baseline is greater than the threshold. For a detailed explanation of this embodiment, please refer to the explanation of other embodiments.

[0088] In one optional embodiment, the risk level of the target interface can be determined by combining the attribute information of the target interface itself. It is understood that if the target interface is a high-importance business interface, such as an authentication interface or a sensitive data access interface, the risk level of the interface can be increased accordingly.

[0089] Therefore, optionally, the interface risk level of the target interface is determined based on the degree of deviation from the second baseline. Specifically, this can include determining the interface risk level of the target interface based on the degree of deviation from the second baseline and at least one of the following: the business impact scope and business importance of the target interface; a positive correlation between the interface risk level and the business impact scope of the target interface; and a positive correlation between the interface risk level and the business importance of the target interface. This embodiment can combine the business impact scope and business importance of the target interface for interface risk detection, which can increase the amount and dimension of information on the basis for interface risk detection and improve the accuracy of interface risk detection.

[0090] The embodiments of this application do not limit the method for determining the business impact scope and importance of the target interface. Optionally, the business impact scope and importance of the target interface can be comprehensively determined based on information about the business to which the target interface belongs, such as the number of related businesses, the importance of the business, and the importance of related businesses. In a specific example, if the target interface needs to be called by multiple other businesses, it can be determined that the business impact scope of the target interface is large. If the target interface has a high risk, it may affect multiple businesses that call the target interface, thereby correspondingly increasing the risk level of the target interface.

[0091] The above embodiments are explained in relation to determining the degree of interface risk. Optionally, root cause analysis of interface risks can also be performed.

[0092] The embodiments of this application do not limit the specific method and process of root cause analysis. Optionally, root cause analysis can be performed on baseline deviations or on high-risk target interfaces. The specific information used for root cause analysis is also not limited; it can be the traffic information to be detected, or traffic anomaly information, abnormal request information, or other information within the traffic information to be detected. Root cause analysis can also be performed in conjunction with the code semantics of the target interface, specifically the code logic semantics information of the target interface that processes received requests.

[0093] Optionally, the above method may further include at least one of the following: (1) if the second baseline deviation is greater than the second deviation root cause threshold, determine the baseline deviation root cause based on the traffic information to be detected and / or the code semantics of the target interface; (2) if the interface risk level is greater than the preset interface risk threshold, determine the interface risk root cause based on the traffic information to be detected and / or the code semantics of the target interface. This embodiment can automatically determine the baseline deviation root cause and the interface risk root cause, realize automatic root cause analysis, and improve the comprehensiveness and accuracy of interface risk detection.

[0094] Specifically, if the deviation of the second baseline is determined to be greater than a threshold, it can be determined that there is a significant difference between the traffic information to be detected and the historical traffic information, thus allowing for the identification of the root cause of the baseline deviation and the execution of root cause analysis. If the deviation of the second baseline is determined to be less than or equal to the second deviation root cause threshold, baseline deviation root cause analysis may not be performed.

[0095] If the risk level of an interface is determined to be greater than a preset interface risk threshold, the target interface can be identified as having a high risk level. This allows for the identification of the root causes of the interface risk and the execution of a root cause analysis. If the risk level of an interface is determined to be less than or equal to the preset interface risk threshold, root cause analysis can be skipped.

[0096] The embodiments of this application do not limit the specific method for determining the root cause of baseline deviation, nor do they limit the specific method for determining the root cause of interface risk. Optionally, the root cause of baseline deviation or the root cause of interface risk can be predicted and determined based on machine learning models such as large models or neural network models. Specifically, a pre-trained root cause analysis large model or root cause prediction model can be used to predict and determine the root cause of baseline deviation or the root cause of interface risk based on the input traffic information to be detected or the code semantics of the target interface.

[0097] The embodiments of this application do not limit the information used for root cause analysis. Optionally, at least one of the following information can be determined as the basis for root cause analysis: traffic information to be detected, code semantics of the target interface, traffic anomaly information, abnormal request information, and business information of the target interface, etc.

[0098] In a specific example, using the traffic information to be detected as the basis for baseline deviation root cause analysis allows for the easy identification of traffic information deviating from the traffic baseline (either the first or second baseline). This enables the extraction of features from this traffic information for further baseline deviation root cause analysis. The specific identified baseline deviation root cause might be an attack on the target interface, fluctuations in service traffic, or network failures.

[0099] In another specific example, using the code semantics of the target interface as the basis for root cause analysis of interface risks allows for the easy identification of the target interface's business processing logic based on its code semantics. This, in turn, identifies the specific logic within the business processing logic that leads to the interface risk, pinpointing the code content related to the risk. Specific root causes of interface risks might include: missing security authentication logic for traffic, missing protection logic for traffic fluctuations, and missing defense logic against traffic attacks.

[0100] Optionally, in order to improve the accuracy of the information used in root cause analysis and reduce the amount of data, traffic information and request information that deviate from the traffic baseline in the traffic information to be detected, or the part of the code semantics in the target interface used to process the traffic information to be detected, can be filtered out to determine the root cause of baseline deviation or the root cause of interface risk.

[0101] In one alternative embodiment, after determining the root cause of baseline deviation or interface risk, corresponding remedial measures can be implemented based on the determined root cause. For example, this may include generating recommendations for remediating the root cause of baseline deviation or interface risk, or performing operations to remediate the root cause of baseline deviation or interface risk.

[0102] For ease of understanding, this application also provides an application embodiment.

[0103] This embodiment provides an interface risk identification method based on traffic logs and a large model, aiming to address the technical bottlenecks of traditional solutions in terms of accuracy and identification of novel attacks. Specifically, this embodiment improves the ability to identify risks such as abnormal semantic parameters and abuse of business logic by combining a large model and interface call behavior analysis. At the same time, by utilizing risk knowledge base matching analysis, it significantly improves the accuracy and coverage of risk detection.

[0104] (1) Data acquisition layer.

[0105] The data acquisition layer is responsible for extracting basic information such as interface path, parameter structure, request transaction initiation time, and authentication method from the interface traffic. The specific specifications are as follows.

[0106] Interface path collection: Record the complete Uniform Resource Locator (URL) path, including protocol type, domain name, port and resource path, ensuring that the original format and dynamic values ​​of the path parameters are captured.

[0107] Parameter Structure Parsing: Request Parameters: Extract parameters from the Uniform Resource Locator (URL), request headers, and request body, distinguishing between required and optional parameters, and recording the data type of each parameter (e.g., string, number). Response Parameters: Parse the response headers and response body, focusing on the status code, returned data format, and key business fields.

[0108] Authentication method record: Clearly collect authentication type, token location and validity period information to ensure that authentication failure scenarios are marked.

[0109] Data integrity verification: The correlation between request and response pairs is marked by timestamps, and the hash values ​​of the request and response bodies are verified to prevent data modification or loss during the collection process.

[0110] The collected data will serve as input for subsequent real-time analysis and model inference layers, ensuring the accuracy and timeliness of risk identification.

[0111] (2) Real-time analysis and sliding time window analysis layer.

[0112] The real-time processing flow of request and response logs first captures the original request and response data through the traffic acquisition component, and then performs standardized parsing. To ensure the timeliness of the analysis, a sliding analysis is performed by selecting a shorter specific time window (within 24 hours) to monitor the interface traffic logs in real time, compare historical data, monitor rate limiting, and detect anomalies.

[0113] Key fields are extracted from the interface traffic logs, including the interface path, request headers / body, response status code, and response content. The aforementioned time window calculation engine processes each log entry, and the feature extraction module identifies abnormal behavior patterns, such as high-frequency access to unconventional parameters and abnormal responses to sensitive data. The risk feature extraction method comprises two dimensions: first, matching known attack characteristics based on a rule engine, i.e., matching and verifying the interface path, parameter structure, and authentication method using a risk knowledge base, and outputting risk assessment results; second, for interface business logic risks, a dynamic baseline is formed through time windows and historical comparisons (corresponding to the first traffic baseline in the above method embodiment), analyzing deviations in historical access behavior to the same interface (such as parameter combination mutation detection).

[0114] Through real-time analysis and sliding time window layer analysis, the suspicious request response characteristics are synchronized to the model inference layer for in-depth analysis, forming a risk assessment closed loop.

[0115] (3) Model inference layer.

[0116] The large model inference layer uses semantic analysis technology to parse the natural language content in the request and response logs. This serves two purposes: first, to establish potential attack semantic patterns; and second, to combine historical access data and complete request and response characteristics to form a normal business baseline.

[0117] For attacks identified by the "real-time analysis and sliding time window analysis layer," further analysis is conducted using a large model. For interfaces identified by the "real-time analysis and sliding time window analysis layer" as having business logic risks, a longer time window (e.g., 30 days) is formed based on the analysis results for further analysis and reasoning. Based on the longer time window sliding analysis, a dynamic business baseline (corresponding to the second traffic baseline in the above method embodiment) is formed. At the same time, using the newly formed business baseline, the baseline deviation data is determined based on information such as the parameter structure of the complete request response. By comparing the degree of deviation between the real-time request and the baseline, it is determined whether there is any abuse of business logic.

[0118] (4) Risk scoring system.

[0119] The risk scoring system uses a dynamic weighted algorithm to quantitatively assess multi-dimensional risk characteristics, ultimately outputting a risk value in the range of 1-100. The calculation model includes the following core elements.

[0120] Known attack characteristics risk weight: The initial score is assigned based on the matching degree of the predefined threat types (such as injection attacks, unauthorized access, etc.) in the risk knowledge base. The higher the matching degree, the higher the base score. The score is assigned from 0 to 50 points according to the degree of matching with the known predefined rules.

[0121] Real-time and time window analysis results: Business baseline deviation coefficient: The final weighting is based on contextual factors such as authentication method strength and interface sensitivity level, with a coefficient range of 0.8-1.2.

[0122] Large-scale model semantic analysis correction: The request parameters and response content are semantically understood through the large-scale model. If abnormal semantic patterns are detected (such as abnormal response characteristics of sensitive data), the severity is increased by 5-25 points.

[0123] Business logic deviation: Compared with the historical normal access mode, the deviation of the current request parameter combination, call frequency and other characteristics is statistically analyzed. Each deviation increases by 0-15 points, and can be weighted in combination with the above business baseline deviation coefficient.

[0124] The risk classification criteria are as follows: Low risk (1-30): slight anomaly of a single feature, log observation is required; Medium risk (31-70): anomaly of multiple feature combinations, triggering real-time alarms; High risk (71-100): clearly matches known attack patterns or serious abuse of business logic, requiring immediate interception.

[0125] This embodiment can achieve at least the following beneficial effects.

[0126] (1) Significantly improve detection accuracy: By combining large models with the same interface call behavior analysis, the shortcomings of traditional rule matching methods can be effectively made up for, and multi-dimensional cross-validation can be achieved.

[0127] (2) Enhance the ability to identify new attacks: By utilizing the semantic analysis function of the large model inference engine, variant attacks that cannot be detected by traditional signature verification can be identified.

[0128] (3) Break through the bottleneck of business logic abuse detection: By establishing a risk knowledge base matching degree analysis and time window baseline analysis model, risk assessment with business context awareness can be achieved.

[0129] (4) Innovation of dynamic risk scoring system: A multi-factor weighted calculation model is used to generate risk values ​​of 1-100, and risk quantification is achieved through graded judgment standards.

[0130] (5) Knowledge base self-evolution mechanism: By continuously absorbing interface risk type data, a dynamically updated risk feature library is formed.

[0131] Based on the above method embodiments, embodiments of this application also provide an interface risk detection device. The following will be combined with... Figure 3 The device is described in detail.

[0132] Figure 3 The diagram illustrates a structural block diagram of an interface risk detection device according to an embodiment of this application.

[0133] like Figure 3 As shown, an interface risk detection device 300 in this embodiment includes: an information module 310, a first module 320, and a second module 330.

[0134] The information module 310 is used to determine the traffic information to be detected at the target interface during the detection period. In one embodiment, the information module 310 can be used to execute the steps S210 and related steps described above, which will not be repeated here.

[0135] The first module 320 is used to determine a first traffic baseline based on the historical traffic information of the target interface within a first time period before the detection period; and to determine the degree of deviation between the traffic information to be detected and the first traffic baseline. The first module 320 can be used to execute the steps S220 and related steps described above, which will not be repeated here.

[0136] The second module 330 is used to determine a second traffic baseline based on historical traffic information of the target interface within a second time period prior to the detection period, and to determine the degree of deviation between the traffic information to be detected and the second traffic baseline, when the first baseline deviation is greater than a first deviation threshold; the first time period is less than the second time period; and the interface risk level of the target interface is determined based on the degree of deviation of the second baseline; the interface risk level is positively correlated with the degree of deviation of the second baseline. The second module 330 can be used to execute the steps S230 and related steps described above, which will not be repeated here.

[0137] According to an embodiment of this application, the above-mentioned device further includes a traffic anomaly module, which is used to: detect traffic anomaly information based on a pre-trained anomaly detection model, and determine the anomaly risk level of the traffic anomaly information; the second module 330 is used to: determine the interface risk level of the target interface based on the deviation level of the second baseline and the anomaly risk level; the determined interface risk level is positively correlated with the anomaly risk level.

[0138] According to an embodiment of this application, the second module 330 is used to perform any of the following: (1) determining the interface risk level of the target interface based on the first baseline deviation level and the second baseline deviation level; (2) if the second baseline deviation level is greater than the second deviation level selection threshold, determining the interface risk level of the target interface based on the second baseline deviation level; if the second baseline deviation level is less than or equal to the second deviation level selection threshold, determining the interface risk level of the target interface based on the first baseline deviation level.

[0139] According to an embodiment of this application, the traffic information includes request information, and the above-mentioned device further includes a first request anomaly module, configured to: determine a first abnormal request information in the traffic information to be detected based on a first traffic baseline, and determine a first request risk level of the first abnormal request information; the deviation between the first abnormal request information and the first traffic baseline is greater than a first request deviation threshold; the second module 330 is configured to: determine the interface risk level of the target interface based on the second baseline deviation level and the first request risk level; the interface risk level is positively correlated with the first request risk level.

[0140] According to an embodiment of this application, the traffic information includes request information, and the above-mentioned device further includes a second request anomaly module, configured to: determine second abnormal request information in the traffic information to be detected based on the second traffic baseline when the second baseline deviation is greater than the second deviation anomaly threshold, and determine the second request risk level of the second abnormal request information; the deviation between the second abnormal request information and the second traffic baseline is greater than the second request deviation threshold; the second module 330 is configured to: determine the interface risk level of the target interface based on the second baseline deviation and the second request risk level; the interface risk level is positively correlated with the second request risk level.

[0141] According to an embodiment of this application, the second module 330 is used to: determine the interface risk level of the target interface based on the degree of deviation from the second baseline and at least one of the following: the business impact scope and business importance of the target interface; the interface risk level is positively correlated with the business impact scope of the target interface; the interface risk level is positively correlated with the business importance of the target interface.

[0142] According to an embodiment of this application, the first module 320 is used to: determine a first historical traffic time sequence based on a sliding window for the historical traffic information of the target interface within a first duration before the detection period; and determine a first traffic baseline based on the first historical traffic time sequence; the second module 330 is used to: determine a second historical traffic time sequence based on a sliding window for the historical traffic information of the target interface within a second duration before the detection period; and determine a second traffic baseline based on the second historical traffic time sequence.

[0143] According to an embodiment of this application, the above-mentioned apparatus further includes a root cause analysis module for performing at least one of the following: (1) when the second baseline deviation degree is greater than the second deviation degree root cause threshold, determining the baseline deviation root cause based on the traffic information to be detected and / or the code semantics of the target interface; (2) when the interface risk degree is greater than the preset interface risk threshold, determining the interface risk root cause based on the traffic information to be detected and / or the code semantics of the target interface.

[0144] According to embodiments of this application, any multiple modules among the information module 310, the first module 320, the second module 330, the traffic anomaly module, the first request anomaly module, the second request anomaly module, and the root cause analysis module can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules can be combined with at least some of the functions of other modules and implemented in one module. According to embodiments of this application, at least one of the information module 310, the first module 320, the second module 330, the traffic anomaly module, the first request anomaly module, the second request anomaly module, and the root cause analysis module can be at least partially implemented as hardware circuitry, such as a field-programmable gate array, a programmable logic array, a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit, or implemented in hardware or firmware by any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the information module 310, the first module 320, the second module 330, the traffic anomaly module, the first request anomaly module, the second request anomaly module, and the root cause analysis module can be implemented at least partially as a computer program module, which can perform corresponding functions when the computer program module is run.

[0145] The explanation of the above device embodiments can be found in the explanation of other embodiments, and any step in the above method embodiments can be executed by the corresponding module in the above device embodiments.

[0146] Figure 4 A block diagram schematically illustrates an electronic device suitable for implementing an interface risk detection method according to an embodiment of this application.

[0147] like Figure 4As shown, an electronic device 1200 according to an embodiment of this application includes a processor 1201, which can perform various appropriate actions and processes according to a program stored in a read-only memory 1202 or a program loaded from a storage portion 1208 into a random access memory 1203. The processor 1201 may include, for example, a general-purpose microprocessor, an instruction set processor and / or an associated chipset and / or a dedicated microprocessor. The processor 1201 may also include onboard memory for caching purposes. The processor 1201 may include a single processing unit or multiple processing units for executing different steps of the method flow according to an embodiment of this application.

[0148] Random access memory 1203 stores various programs and data required for the operation of electronic device 1200. Processor 1201, read-only memory 1202, and random access memory 1203 are interconnected via bus 1204. Processor 1201 executes various steps of the method flow according to embodiments of this application by executing programs in read-only memory 1202 and / or random access memory 1203. It should be noted that the programs may also be stored in one or more memories other than read-only memory 1202 and random access memory 1203. Processor 1201 may also execute various steps of the method flow according to embodiments of this application by executing programs stored in said one or more memories.

[0149] According to embodiments of this application, the electronic device 1200 may further include an input / output interface 1205, which is also connected to the bus 1204. The electronic device 1200 may also include one or more of the following components connected to the input / output interface 1205: an input section 1206 including a keyboard, mouse, etc.; an output section 1207 including a cathode ray tube, liquid crystal display, etc., and a speaker, etc.; a storage section 1208 including a hard disk, etc.; and a communication section 1209 including a network interface card, such as a local area network card, modem, etc. The communication section 1209 performs communication processing via a network such as the Internet. A drive 1210 is also connected to the input / output interface 1205 as needed. A removable medium 1211, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 1210 as needed so that computer programs read from it can be installed into the storage section 1208 as needed.

[0150] Embodiments of this application also provide a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0151] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In embodiments of this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include the read-only memory 1202, and / or random access memory 1203, and / or one or more memories other than read-only memory 1202 and random access memory 1203 described above.

[0152] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the methods provided in the embodiments of this application.

[0153] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 1209, and / or installed from the removable medium 1211. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0154] In embodiments of this application, the computer program can be downloaded and installed from a network via communication section 1209, and / or installed from removable medium 1211. When the computer program is executed by processor 1201, it performs the functions defined in the system of this application embodiment. According to embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0155] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0156] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0157] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. An interface risk detection method, characterized in that, The method includes: Determine the traffic information to be detected for the target interface during the detection period; A first traffic baseline is determined based on the historical traffic information of the target interface within a first time period prior to the period to be detected; Determine the degree of deviation of the detected flow information from the first baseline; If the deviation of the first baseline is greater than the first deviation threshold, a second traffic baseline is determined based on the historical traffic information of the target interface within a second duration prior to the detection period, and the degree of deviation of the second baseline between the traffic information to be detected and the second traffic baseline is determined; the first duration is less than the second duration. The interface risk level of the target interface is determined based on the degree of deviation from the second baseline; the interface risk level is positively correlated with the degree of deviation from the second baseline.

2. The method according to claim 1, characterized in that, The method further includes: Based on a pre-trained large-scale anomaly detection model, anomaly information is detected for the traffic information to be detected, and the degree of anomaly risk of the traffic anomaly information is determined. The step of determining the interface risk level of the target interface based on the degree of deviation from the second baseline includes: The interface risk level of the target interface is determined based on the degree of deviation from the second baseline and the degree of abnormal risk; the determined interface risk level is positively correlated with the degree of abnormal risk.

3. The method according to claim 1, characterized in that, The determination of the interface risk level of the target interface based on the degree of deviation from the second baseline includes any one of the following: The interface risk level of the target interface is determined based on the degree of deviation from the first baseline and the degree of deviation from the second baseline. If the deviation from the second baseline is greater than the second deviation selection threshold, the interface risk level of the target interface is determined based on the deviation from the second baseline. If the deviation of the second baseline is less than or equal to the second deviation selection threshold, the interface risk level of the target interface is determined based on the deviation of the first baseline.

4. The method according to claim 1, characterized in that, The traffic information includes request information, and the method further includes: In the traffic information to be detected, a first abnormal request is determined based on the first traffic baseline, and a first request risk level of the first abnormal request is determined; the deviation between the first abnormal request and the first traffic baseline is greater than a first request deviation threshold. The step of determining the interface risk level of the target interface based on the degree of deviation from the second baseline includes: The interface risk level of the target interface is determined based on the degree of deviation from the second baseline and the risk level of the first request; the interface risk level is positively correlated with the risk level of the first request.

5. The method according to claim 1, characterized in that, The traffic information includes request information, and the method further includes: If the deviation from the second baseline is greater than the second deviation abnormality threshold, in the traffic information to be detected, a second abnormal request information is determined based on the second traffic baseline, and the second request risk level of the second abnormal request information is determined; the deviation between the second abnormal request information and the second traffic baseline is greater than the second request deviation threshold. The step of determining the interface risk level of the target interface based on the degree of deviation from the second baseline includes: The interface risk level of the target interface is determined based on the degree of deviation from the second baseline and the degree of risk of the second request; the interface risk level is positively correlated with the degree of risk of the second request.

6. The method according to claim 1, characterized in that, The step of determining the interface risk level of the target interface based on the degree of deviation from the second baseline includes: The interface risk level of the target interface is determined based on the degree of deviation from the second baseline and at least one of the following: the scope of business impact and business importance of the target interface; The degree of risk of the interface is positively correlated with the scope of business impact of the target interface; the degree of risk of the interface is positively correlated with the business importance of the target interface.

7. The method according to claim 1, characterized in that, The step of determining the first traffic baseline based on the historical traffic information of the target interface within a first time period prior to the detection period includes: Based on the historical traffic information of the target interface within a first time period prior to the detection period, a first historical traffic time series is determined using a sliding window; and a first traffic baseline is determined based on the first historical traffic time series. The step of determining the second traffic baseline based on the historical traffic information of the target interface within a second time period prior to the detection period includes: Based on the historical traffic information of the target interface within a second time period prior to the detection period, a second historical traffic time sequence is determined using a sliding window; and a second traffic baseline is determined based on the second historical traffic time sequence.

8. The method according to claim 1, characterized in that, The method further includes at least one of the following: If the second baseline deviation is greater than the second deviation root cause threshold, the baseline deviation root cause is determined based on the traffic information to be detected and / or the code semantics of the target interface; If the interface risk level is greater than a preset interface risk threshold, the root cause of the interface risk is determined based on the traffic information to be detected and / or the code semantics of the target interface.

9. An interface risk detection device, characterized in that, The device includes: The information module is used to determine the traffic information to be detected at the target interface during the detection period. The first module is used to determine a first traffic baseline based on the historical traffic information of the target interface within a first time period before the detection period; and to determine the degree of deviation of the traffic information to be detected from the first traffic baseline. The second module is used to determine a second traffic baseline based on historical traffic information of the target interface within a second time period before the detection period when the first baseline deviation is greater than a first deviation threshold, and to determine the second baseline deviation between the traffic information to be detected and the second traffic baseline; the first time period is less than the second time period; and to determine the interface risk level of the target interface based on the second baseline deviation level; the interface risk level is positively correlated with the second baseline deviation level.

10. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 8.

11. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 8.

12. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 8.

Images