Web and API micro-model security protection system with double-layer architecture

Abstract

The application relates to the technical field of network security and application security, and discloses a double-layer architecture Web and API micro model security protection system, which comprises a control plane and a data plane. The control plane comprises a central security intelligence and arrangement engine, which is used for generating and managing a special micro model complex for API endpoints, Web interfaces or applet interfaces. The data plane is arranged on a necessary path of business traffic and comprises a special micro model complex composed of a parameter model, a behavior model, an identity model and a security micro model. A risk signal bus is arranged in the special micro model complex. The parameter model, the behavior model and the identity model respectively detect parameter characteristics, calling behavior characteristics and identity characteristics of a request and output risk signals. The risk signal bus correlates and fuses the risk signals to obtain comprehensive risk information. The security micro model determines an access control decision based on the comprehensive risk information according to reinforcement learning. The application can realize multi-dimensional risk collaborative detection and dynamic access control.

Description

Technical Field

[0001] This invention relates to the fields of network security and application security technology, and in particular to a two-tier architecture Web and API micro-model security protection system. Background Technology

[0002] In the current cloud-native and microservice architecture, web services, API interfaces, and mini-programs have become important carriers for enterprise data interaction and business operations. For these services, existing security protection mainly relies on perimeter security devices such as WAF (Web Application Firewall) and WAAP (Web Application and API Protection), forming a traditional security protection system based on static signatures, stateless detection, and centralized rule-based protection.

[0003] Existing security devices such as WAF and WAAP typically pre-load known attack signatures, vulnerability signatures, and malicious request rules. By performing keyword matching and rule comparison on network traffic and request packets, they can detect and block common threats such as SQL injection, XSS, malicious crawlers, and general API attacks. This type of protection logic mainly relies on manual rule updates and static signature library iterations, lacking the ability to learn autonomously and adapt to business needs.

[0004] On the one hand, existing technologies mainly rely on static signature rules to independently detect individual requests, which is a stateless protection mode. It is difficult to record and analyze the context of API calls, business call chains, and the timing characteristics of user behavior. In microservice scenarios, there are usually linked calls and business process relationships between different APIs. Detecting only individual requests makes it difficult to identify business logic attacks such as API business logic bypass, unauthorized calls, timing anomalies, and parameter combination forgery.

[0005] On the other hand, existing protection primarily targets request messages and attack characteristics, resulting in a relatively singular protection dimension. It lacks sufficient correlation analysis of API parameter characteristics, user credentials, call behavior trajectories, and access scenario permissions, making it difficult to identify sophisticated threats such as credential theft, replay attacks, abnormal logins from different locations, and low-probability parameter anomalies. Furthermore, existing technologies typically employ a unified protection model, failing to configure corresponding dedicated protection capabilities for different API endpoints and attack scenarios, resulting in coarse-grained protection.

[0006] Furthermore, the threat signature databases in existing security devices typically rely on manual offline updates, making it difficult to detect new attack variants and new business vulnerabilities in a timely manner. Protection data between different devices or nodes are independent of each other, lacking a network-wide threat intelligence sharing mechanism, thus making it difficult to achieve autonomous analysis of new attack logic and synchronous updates of models or threat capabilities between different nodes.

[0007] The detection rules and identification models of existing protection equipment are usually manually configured and run in a fixed manner. When enterprises add new API interfaces, adjust business parameters, change call processes, or user behavior changes, the original static rules or identification models may not be able to adapt in a timely manner, resulting in missed or false alarms. This is because the existing technology lacks an automated MLOps operation and maintenance system and an online learning mechanism, making it difficult to continuously iterate models, optimize operating parameters, and adapt to business changes.

[0008] Meanwhile, security alerts generated by existing protection systems are usually only used to indicate attack behavior, lacking risk attribution and feature contribution analysis, and the alert noise is relatively large, making it difficult for security operations personnel to accurately identify real threats from a large number of alerts; in addition, existing technologies are not capable of automatically identifying assets such as shadow APIs and zombie APIs, and it is also difficult to provide the development side with accurate risk or vulnerability location information, thereby increasing the cost of security operations and R&D security management.

[0009] Therefore, existing Web and API security protection technologies still have problems such as insufficient ability to identify business logic attacks, single protection dimensions, insufficient threat intelligence updates and sharing capabilities, lack of adaptive protection models, and insufficient alarm attribution capabilities. Summary of the Invention

[0010] The purpose of this invention is to address the shortcomings of existing technologies by proposing a two-tier architecture Web and API micromodel security protection system.

[0011] To achieve the above objectives, the present invention adopts the following technical solution:

[0012] A two-tier architecture Web and API micro-model security protection system, the system comprising: a control plane and a data plane;

[0013] The control plane includes a central security intelligence and orchestration engine for generating and managing proprietary micro-model complexes for API endpoints, web interfaces, or mini-program interfaces.

[0014] The data plane is set on the necessary path of business traffic and includes a dedicated micro-model composite, which includes a parameter model, a behavior model, an identity model and a security micro-model. A risk signal bus is set inside the dedicated micro-model composite.

[0015] The parameter model, behavior model, and identity model detect the parameter features, call behavior features, and identity features of the request, respectively, and output risk signals. The risk signal bus correlates and fuses the risk signals to obtain comprehensive risk information. The security micro-model is an access decision agent based on reinforcement learning, used to determine access control decisions based on the comprehensive risk information.

[0016] Preferably, the control plane and the data plane communicate via a bidirectional asynchronous long-connection dual-channel separation architecture. The dual channels include a control and management distribution channel and a data reporting channel. The control and management distribution channel is used to distribute incremental package of model parameters, lightweight model inference files, protection policy files, feature template library and global threat intelligence to the data plane. The data reporting channel is used to send back traffic samples, risk scores, decision feedback and device heartbeats to the control plane.

[0017] Preferably, the risk signals adopt a unified structured message format, which includes a public association field, a model-private risk field, and an interpretability feature field. The risk signal bus uses a three-level association key to associate the risk signals. The first-level association key is a globally unique tracking identifier for the entire lifecycle of a single API request, used to aggregate risk signals corresponding to the same request. The second-level association key is used to batch aggregate time-series risk signals corresponding to the same interface and the same user. The third-level association key is used for cross-request risk association based on identity credentials and source IP.

[0018] Preferably, the risk signal bus is used to correct the original risk scores output by each model according to the model confidence weights of the parameter model, the behavior model, and the identity model; when the corrected risk scores of at least two models corresponding to the same request are greater than a preset risk threshold, a cross-penalty of multi-dimensional joint risk is superimposed, and a global comprehensive risk score is generated based on the risk score after superimposing the cross-penalty; the global comprehensive risk score, the risk sub-item information of each model, and the abnormal feature information are encapsulated into a fused feature vector and sent to the security micro-model.

[0019] Preferably, the central security intelligence and orchestration engine includes an MLOps model lifecycle management module; the MLOps model lifecycle management module is used to generate and assemble corresponding dedicated micro-model complexes based on the business profile matching algorithm combination formed by different API interface functions, parameter types and calling scenarios, and to determine the running parameters of each micro-model in the dedicated micro-model complex through hyperparameter automatic optimization; the MLOps model lifecycle management module is also used to incrementally update the dedicated micro-model complexes through online incremental learning based on the collected business traffic change data and normal behavior iteration data.

[0020] Preferably, the central security intelligence and orchestration engine includes a global threat intelligence internalization module; the global threat intelligence internalization module is used to analyze new attack logic, 0DAY variant attacks or customized business attacks based on the Transformer architecture and extract new threat features, and based on the federated learning framework, synchronize the new threat features and optimized model parameters to a dedicated micro-model composite of multiple nodes without leaving the user's private business data domain.

[0021] Preferably, the parameter model includes a Gaussian mixture model and a density-based noise application space clustering model. The Gaussian mixture model is used to model the normal distribution probability of numerical parameters and the joint distribution among multiple parameters. The density-based noise application space clustering model is used to convert the access subject information in the request traffic into behavioral feature vectors and perform density clustering on the behavioral feature vectors.

[0022] The behavioral model includes a graph neural network model and a variational autoencoder model. The graph neural network model is used to model the API call chain, and the variational autoencoder model is used to establish a baseline for request frequency, load size and timing characteristics and detect anomalies based on reconstruction error.

[0023] The identity model includes a single-class support vector machine model, which is used to learn the decision boundary of identity credential usage patterns based on normal identity authentication behavior data, and to identify abnormal identity invocation behavior based on the decision boundary.

[0024] Preferably, the security micro-model adopts the Q-Learning algorithm, which models access control as a Markov decision process, and takes a state vector including identity credibility, device security reputation, behavior score, access time, network environment, business scenario label and parameter anomaly score as input to determine one of the following access control decisions: allow, alarm, block or require multi-factor authentication.

[0025] Preferably, the central security intelligence and orchestration engine includes an interpretable AI module, which is used to perform risk attribution analysis and feature contribution quantification on security alarms based on the comprehensive risk information, and output alarm reports and risk location information.

[0026] This invention employs a two-layer intelligent protection architecture consisting of a control plane and a data plane. The control plane includes a central security intelligence and orchestration engine for centralized intelligent computing, model management, policy management, and threat intelligence processing. The data plane includes dedicated micro-model complexes for API endpoints, web interfaces, or mini-program interfaces, positioned on the essential paths of business traffic to perform real-time, low-latency security detection and access control. By combining the centralized intelligent computing capabilities of the control plane with the real-time detection and execution capabilities of the data plane, a two-layer collaborative protection architecture is formed, distinct from traditional static rule-based protection methods.

[0027] The dedicated micro-model complex includes a parameter model, a behavior model, an identity model, and a security micro-model, with a risk signal bus internally. The parameter model, behavior model, and identity model detect and output risk signals based on the parameter characteristics, call behavior characteristics, and identity characteristics of the request, respectively. The risk signal bus correlates and fuses the risk signals output by different models in real time to achieve cross-validation and comprehensive judgment of multi-dimensional risk information. The security micro-model determines access control decisions based on the fused comprehensive risk information, thus forming a multi-model collaborative security protection mechanism.

[0028] The central security intelligence and orchestration engine in the control plane processes business logic, interface functions, and parameter attributes corresponding to business traffic through data preprocessing and feature engineering, extracting parameter features, behavioral timing features, identity features, and access scenario features. Simultaneously, through the MLOps model lifecycle management module, it generates and assembles corresponding dedicated micro-model complexes based on different API business profile matching algorithm combinations, and determines the operating parameters of each micro-model through automatic hyperparameter optimization. During system operation, based on business traffic change data and normal behavior iteration data, it incrementally updates the dedicated micro-model complexes through online incremental learning, enabling the corresponding models to continuously adjust with business changes, thereby reducing the impact of model drift on detection results. Furthermore, it can be combined with a defense computing mechanism to defend against malicious hyperparameter search attacks.

[0029] The central security intelligence and orchestration engine also includes a global threat intelligence internalization module, which is used to analyze new attack logic, 0DAY variant attacks and customized business attacks based on the Transformer architecture, and extract corresponding new threat features. On this basis, based on the federated learning framework, without leaving the user's private business data domain, the new threat features and optimized model parameters are synchronized to the dedicated micro-model complex of multiple nodes, so that different nodes can continuously update the corresponding security protection capabilities according to new threats.

[0030] In one specific implementation, the plurality of nodes may include all nodes in the entire network, thereby synchronizing the novel threat features and optimized model parameters to the dedicated micro-model complex corresponding to all nodes in the entire network.

[0031] The security micro-model employs reinforcement learning algorithms to construct an access decision agent. It uses factors such as identity trustworthiness, device security reputation, behavior score, access time, network environment, business scenario tags, and parameter anomaly scores as input factors for access control decisions. Based on the current comprehensive risk information, it determines one access control decision: allow, alert, block, or require multi-factor authentication. By dynamically adjusting access control policies through reinforcement learning, it can replace fixed static access control rules, enabling access control to adaptively change according to different business scenarios and risk states.

[0032] The central security intelligence and orchestration engine also includes an interpretability AI module, which is used to perform risk attribution analysis and feature contribution quantification on security alarms corresponding to comprehensive risk information, and output alarm reports and risk location information. This enables security alarms to be associated with relevant abnormal parameters, abnormal call behaviors, abnormal identity characteristics and other risk sources, thereby improving the interpretability, traceability and location of security risks, and providing risk analysis basis for security operations and R&D remediation.

[0033] In addition, the central security intelligence and orchestration engine can combine the security big model to identify assets of Web business, API business and mini-program business, complete asset inventory, sensitivity classification and interface profile construction, and identify shadow APIs and zombie APIs. On this basis, it generates corresponding exclusive micro-model complexes and security protection strategies according to the business profiles of different business assets and API endpoints, thereby realizing the continuous management of Web business, API business and mini-program business assets and their security strategies.

[0034] The beneficial effects of this invention are as follows:

[0035] This application uses behavioral modeling and API call chain modeling to continuously analyze the call path, timing relationship and behavioral characteristics of API requests. It can identify attack behaviors that are difficult to identify by traditional static rules, such as business logic bypass, covert tampering and abnormal calls. This breaks through the limitations of traditional stateless signature matching and static rule detection, and improves the ability to identify complex attacks on the API business logic layer and 0DAY attacks.

[0036] This application utilizes the MLOps model lifecycle management module within the central security intelligence and orchestration engine to generate and manage corresponding dedicated micro-model complexes based on the business profiles of different APIs. By combining automatic hyperparameter optimization and online incremental learning, the system continuously updates the operating parameters of each micro-model based on changes in business traffic and normal behavior iteration data. This enables the system to adaptively adjust to changes in business iteration and user behavior, reducing the impact of model solidification, rule lag, and model drift on detection results. Simultaneously, a defense computing mechanism enhances the system's ability to protect against computationally intensive attacks such as malicious hyperparameter searches.

[0037] This application uses parameter models, behavior models, and identity models to detect risks based on parameter features, call behavior features, and identity features, respectively. It then uses a risk signal bus to correlate and fuse the risk signals output by different models. Finally, a security micro-model determines access control decisions based on comprehensive risk information, achieving collaborative protection across multiple dimensions of parameters, behavior, identity, and access control. This reduces false positives and false negatives caused by relying on a single detection dimension and improves the comprehensive judgment capability against complex and covert attack behaviors.

[0038] This application uses a global threat intelligence internalization module based on the Transformer architecture to analyze new attack logic, 0DAY variant attacks, and customized business attacks, and extract new threat features. At the same time, combined with a federated learning framework, the new threat features and optimized model parameters are synchronized to a dedicated micro-model composite on multiple nodes without leaving the user's private business data domain. This improves the efficiency of updating and synchronizing new threat information and reduces the lag caused by traditional reliance on manual updates of the feature library and isolated protection of single nodes.

[0039] This application identifies shadow APIs and zombie APIs by performing asset identification, interface profiling, and asset sensitivity classification for Web, API, and mini-program businesses. Combined with parameter-level anomaly localization, risk attribution analysis of interpretable AI, and feature contribution quantification, it provides alarm reports and risk localization information for security operations and R&D remediation, thereby improving the efficiency of SOC operations and DevSecOps R&D remediation. It can also provide a basis for corresponding asset classification and risk recording for compliance management such as PCI-DSS and GDPR.

[0040] The security micro-model in this application adopts the Q-Learning algorithm, which models access control as a Markov decision process. Based on status information such as identity credibility, device security reputation, behavior score, access time, network environment, business scenario label, and parameter anomaly score, it dynamically determines access control decisions such as allowing, alarming, blocking, or requiring multi-factor authentication. This improves the adaptability to complex and dynamic business access scenarios compared to fixed static permission rules, and ensures normal business access while achieving security protection.

[0041] This application performs closed-loop processing of business traffic data, user privacy data, and interface sensitive data locally. A dedicated micro-model complex deployed on the local data plane completes real-time detection, risk assessment, and access control, while the local control plane completes model management and iteration. This ensures that the original business data does not need to leave the domain or be uploaded to the cloud, thereby reducing the risk of data leakage and cross-border transmission caused by the external transmission of the original business data. It is suitable for application scenarios with high requirements for data localization and data not leaving the domain. Attached Figure Description

[0042] Figure 1 This is a schematic diagram of the overall architecture of the Web and API micro-model security protection system with a two-layer architecture according to the present invention. Detailed Implementation

[0043] In order to provide a clearer understanding of the technical features, objectives and beneficial effects of the present invention, the technical solution of the present invention will now be described in detail below, but it should not be construed as limiting the scope of implementation of the present invention.

[0044] In one embodiment, this invention proposes a two-tier architecture Web and API micro-model security protection system, comprising a control plane and a data plane. The control plane includes a central security intelligence and orchestration engine, serving as the system's global scheduling and intelligent computing center. Deployed within the device's internal management process space, it does not participate in real-time traffic detection and is primarily used for performing non-real-time intelligent computing, model management, threat intelligence internalization, and data preprocessing, while providing model, policy, and threat intelligence support to the data plane. The central security intelligence and orchestration engine includes a data preprocessing and feature engineering module, an MLOps model lifecycle management module, and a global threat intelligence internalization module.

[0045] The data plane, serving as the real-time protection execution component for business traffic, is deployed within the data forwarding process space of the device and is configured on the essential paths of business traffic via bridge or reverse proxy. The data plane includes dedicated micro-model composites for API endpoints, Web interfaces, or mini-program interfaces. These dedicated micro-model composites include parameter models, behavioral models, identity models, and security micro-models. Each dedicated micro-model composite contains a risk signal bus for transmitting and integrating risk signals between the various models.

[0046] In this implementation, the parameter model, behavior model, identity model, and security micro-model are deployed in parallel and independently, and are linked through a risk signal bus to perform stateful, real-time, and low-latency detection of business traffic. Each model can initially be a model trained, optimized, and adapted for API application protection based on general application data. After the system is deployed to a specific customer or industry, it continuously learns from actual business traffic, gradually forming a dedicated model that matches the business characteristics and changes of the corresponding API. Thus, the same type of model can form corresponding dedicated model instances based on the actual business data of each API endpoint when facing different API endpoints. The MLOps model lifecycle management module generates and manages corresponding dedicated micro-model complexes based on the business profiles of different APIs, and continuously updates each micro-model within them.

[0047] The control plane and data plane communicate via a dual-channel, separate architecture with bidirectional asynchronous long connections. The two channels are physically or logically isolated and do not interfere with each other. The dual channels include a control and management distribution channel and a data reporting channel. The control and management distribution channel is used to push incremental packages of model parameters, lightweight model inference files, protection policy files, feature template libraries, and global threat intelligence unidirectionally from the control plane to the data plane, and provides high reliability and retransmission guarantees. The data reporting channel is used to asynchronously transmit traffic samples, risk scores, decision feedback, and device heartbeats back from the data plane to the control plane.

[0048] The incremental model parameter package can include incremental weight parameters corresponding to GMM, DBSCAN, GNN, VAE, One-Class SVM, and RL-Q tables. These are not complete model files, but rather difference parameters formed after online learning iterations. Lightweight model inference files can be in ONNX format. Complete inference models are distributed during major version iterations, while incremental parameters are synchronized during routine updates. Protection strategy files include hierarchical access control policies generated based on reinforcement learning, scenario-based handling rules, MFA trigger conditions, and temporary IP blacklists. The feature template library includes parameter regularization baselines, business API link topology templates, normal identity credential feature templates, and risk feature extraction rules. Global threat intelligence includes malicious IPs, malicious accounts, and known attack payload features, used to assist various models in pre-emptive risk matching.

[0049] For the same API endpoint, the system can generate multiple security protection policy versions based on continuous learning and access control decision-making processes. For example, V1, V2, V3, and V4 represent security protection policy versions formed at different learning or iteration stages for the same API endpoint, rather than corresponding to different API endpoints. Each API endpoint can form its own dedicated protection policy based on its own business traffic, risk changes, and model learning results. Reinforcement learning and Q-Learning are used for access control decisions in the security micro-model, which is a dedicated micro-model composite in the data plane. The control plane manages, updates, and distributes relevant model parameters and policies to the data plane through the MLOps model lifecycle management module.

[0050] The data preprocessing and feature engineering module is located in the control plane and provides data support for the training of various models. This module first uses an unsupervised clustering algorithm to denoise business traffic, eliminating invalid and duplicate traffic while retaining valid business traffic. Then, it uses a large security model to label the business logic, interface functions, and parameter attributes corresponding to the business traffic. Based on the labeled data, it extracts parameter features, behavioral temporal features, identity features, and access scenario features of API requests, constructing an API feature vector space to provide feature data for the generation, training, and anomaly detection of dedicated micro-model complexes.

[0051] The MLOps model lifecycle management module matches appropriate algorithm combinations based on the business profiles of different APIs. These business profiles include interface functions, parameter types, and calling scenarios. Based on the matching results, it generates and assembles corresponding dedicated micro-model complexes, and automatically optimizes hyperparameters to determine the operating parameters of each micro-model within the complex. During system operation, the MLOps model lifecycle management module continuously collects business traffic change data and normal behavior iteration data, and incrementally updates the dedicated micro-model complexes through online incremental learning, ensuring that each micro-model continuously adjusts to changes in business requirements. This module can also be used in conjunction with a defense computing mechanism to defend against malicious hyperparameter search attacks.

[0052] The global threat intelligence internalization module is used to analyze new attack logic, 0DAY variant attacks, and customized business attacks based on the Transformer architecture, and extract new threat features from them. At the same time, based on the federated learning framework, without leaving the user's private business data domain, it synchronizes new threat features and optimized model parameters to a dedicated micro-model composite on multiple nodes, so that the protection capabilities of different nodes can be continuously updated with new threats.

[0053] A risk signal bus is located within a dedicated micro-model complex to enable real-time correlation between risk signals output from the parameter model, behavior model, and identity model, forming comprehensive risk information for the security micro-model to make access control decisions. The risk signals employ a unified structured message format; in one specific implementation, the structured message uses JSON format and includes a public association domain, a model-private risk domain, and an interpretability feature domain.

[0054] The risk signal bus employs a three-level association key to correlate risk signals output by different models. The first-level association key is a globally unique tracking identifier for the entire lifecycle of a single API request. Risk signals output by the parameter model, behavior model, and identity model corresponding to the same request carry the same globally unique tracking identifier. The risk signal bus groups and aligns multi-dimensional risk data corresponding to the same request based on this globally unique tracking identifier. The second-level association key is used to batch aggregate time-series risk signals corresponding to the same interface and the same user, supporting API link modeling for behavior models and credential cycle statistics for identity models. The third-level association key is used for cross-request risk correlation at the identity credential and source IP dimensions to identify persistent abnormal behaviors across requests, such as credential reuse and IP brute-force attacks.

[0055] The risk signal bus further corrects the original risk scores (0-100) output by each model based on the model confidence weights of the parameter model, behavioral model, and identity model. In one specific implementation, the risk score after single-model correction satisfies:

[0056]

[0057] in, For the corrected risk score, The model confidence weights are assigned to the corresponding models and are dynamically updated based on the historical detection accuracy of the corresponding models. This is the original risk score output by the corresponding model.

[0058] When at least two model outputs corresponding to the same API request show high risk (e.g., a corrected risk score greater than 50), a cross-penalty coefficient is applied. In one specific implementation, the risk score after joint cross-penalization of multiple risk signals satisfies:

[0059]

[0060] in, , and These are risk scores corrected using parametric models, behavioral models, and identity models, respectively. This represents the number of models that triggered high-risk conditions in the current request. This represents the cross-penalty coefficient.

[0061] A global comprehensive risk score in the range of 0 to 100 is generated based on the risk score after superimposed cross-penalty. The global comprehensive risk score, the risk sub-item information of each model and the abnormal feature information are encapsulated into a fusion feature vector and sent to the security micro-model. At the same time, it is sent to the central security intelligence and orchestration engine for risk attribution and interpretability analysis.

[0062] The parameter model is used to detect the parameter characteristics of API requests. Inputs to the parameter model can include the URL path and path parameters, QueryString parameter key-value pairs, HTTP header information such as Content-Type, Accept, and Authorization, the request body in JSON, XML, or PlainText format, and the raw payload content. The parameter model can automatically learn the data type, length range, regular expression format, and enumerated values ​​of each API parameter, and model the normal distribution probability of numerical parameters and the correlation between multiple parameters to identify anomalies such as abnormal parameter values, illegal parameter combinations, parameter tampering, and implicit parameter overreach.

[0063] The parametric models include Gaussian mixture models and density-based noise application space clustering models. Gaussian mixture models are used for multimodal modeling of the normal distribution probability of numerical parameters and correlation modeling of the joint distribution of multiple parameters to identify anomalous deviations in parameter values ​​from their statistical distributions and illegal parameter combinations. Density-based noise application space clustering models convert access subject information in request traffic into behavioral feature vectors including access frequency, operation type distribution, and time intervals. Clustering is then performed based on the density of these behavioral feature vectors to distinguish between normal dense clusters and isolated outliers. The parametric models can output parameter-level anomaly scores, anomaly parameter location information, anomaly types, and associated parameter combination relationship information. Anomaly parameter location information can correspond to specific field paths, anomaly types can include numerical probability anomalies, illegal parameter combinations, data type violations, and out-of-bounds enumeration values, and associated parameter combination relationship information can include associated parameter combination relationship chains.

[0064] The behavioral model is used to detect API call behavior. Its inputs may include source IP address, geolocation information, User-Agent information, Referer, request timestamp, request time interval, API call context, single request load size, and access frequency within a unit time window. By learning the normal user call trajectory over a long period, the behavioral model forms a user access journey and business call baseline, and compares the call chain, timing sequence, access frequency, and load characteristics of real-time requests with this baseline.

[0065] The behavioral model includes a graph neural network (GNN) model and a variational autoencoder (VAE) model. The GNN model models the API call chain as a directed graph structure, where API endpoints are nodes and call order relationships are edges. It identifies call behaviors that deviate from the normal path by learning the topological patterns of normal user access journeys. The VAE model establishes a baseline based on request frequency, load distribution, and timing characteristics, and identifies abnormal requests that deviate from normal traffic patterns based on reconstruction errors. The behavioral model can output behavioral-level anomaly scores, deviation types, information on deviated link nodes, and quantitative information on the deviation from the normal baseline. The deviation types can include abnormal path jumps, timing violations, frequency exceeding limits, and load characteristic deviations.

[0066] The identity model is used to detect identity features in API requests. Its inputs can include cookies, session IDs, JWT tokens, OAuth AccessTokens, RefreshTokens, user device fingerprints, login geographic information, timestamps, and historical authentication records. Among them, JWT tokens can include declaration fields such as issuance time, expiration time, issuer, and audience. User device fingerprints can include information such as operating system version, screen resolution, and font list.

[0067] The identity model includes a single-class support vector machine (SVM) model, which is trained using only normal identity authentication behavior data. It learns the decision boundary of legitimate identity credential usage patterns in a high-dimensional feature space. This decision boundary can be a hypersphere or a hyperplane. The anomaly types can include login from a different location, credential replay, device fingerprint mismatch, abnormal issuance cycle, and password brute-force features. Its training features can include the issuance cycle, refresh frequency, logout mode, device fingerprint consistency, and login geographic location time sequence patterns of JWTs or Tokens. When the corresponding identity authentication behavior deviates from the decision boundary, it is identified as an abnormal identity invocation behavior, thereby detecting risks such as credential theft, credential replay, abnormal login from a different location, password brute-force, and credential stuffing. The identity model can output an identity-level anomaly score, anomaly credential identifier, anomaly type, and credential risk level.

[0068] The security micro-model is a reinforcement learning-based access decision agent used to determine access control decisions based on comprehensive risk information. It employs the Q-Learning algorithm, modeling access control as a Markov decision process, and takes a state vector as input, including identity trustworthiness, device security reputation, behavior score, access time, network environment, business scenario label, and parameter anomaly score. Identity trustworthiness can be derived from real-time scoring by the identity model; device security reputation can be determined based on matching scores from a historical device fingerprint database; behavior score can be derived from the real-time output of the behavior model; business scenario label can correspond to business scenarios such as payment transactions, data export, and configuration modification; and parameter anomaly score can be derived from the parameter model.

[0069] The security micro-model determines access control decisions based on the Q-value corresponding to the current state vector. These decisions include allowing, alerting, blocking, or requiring multi-factor authentication. The reinforcement learning reward function balances security and business continuity, providing positive rewards for correctly blocking malicious requests and negative rewards for mistakenly blocking legitimate requests, thus continuously adjusting the access control policy. The security micro-model can also output decision confidence, policy execution action codes, and a summary of the decision rationale. This summary can include a ranking of the contributions of each dimension factor.

[0070] The central security intelligence and orchestration engine also includes an interpretable AI module, which performs risk attribution analysis and feature contribution quantification on security alarms corresponding to comprehensive risk information, and outputs alarm reports and risk location information, so that security alarms can be associated with specific abnormal parameters, abnormal call chains, abnormal identity characteristics and corresponding risk sources.

[0071] During system operation, the system first automatically scans all web, API, and mini-program services across the network. It then leverages the feature engineering capabilities of the security big data model to identify and model assets, completing asset inventory, sensitivity classification, and interface profiling. This automatically identifies shadow APIs and zombie APIs. Subsequently, the MLOps model lifecycle management module in the control plane combines business profile matching algorithms for each interface, determines operating parameters, and generates corresponding dedicated micro-model composites, which are then deployed to the data plane. When business traffic passes through the data plane, the parameter model, behavior model, and identity model perform real-time detection based on parameter features, call behavior features, and identity features, respectively. Risk signals are sent to the risk signal bus for correlation and fusion. The security micro-model then determines appropriate access control decisions based on the resulting comprehensive risk information.

[0072] During continuous operation, traffic samples, risk scores, and decision feedback from the data plane are transmitted back to the control plane through the data reporting channel. The MLOps model lifecycle management module performs online incremental updates to the dedicated micro-model complex based on business traffic change data and normal behavior iteration data. For new attack samples, the global threat intelligence internalization module extracts the corresponding new threat features and updates model parameters and global threat intelligence in conjunction with federated learning. The interpretability AI module further performs risk attribution analysis and feature contribution quantification based on comprehensive risk information, and outputs alarm reports and risk location information, thus forming a closed-loop processing process from real-time detection, risk fusion, access control to model updates and risk attribution.

[0073] In this implementation, business traffic data, user privacy data, and interface sensitive data are processed in a closed loop locally. Real-time detection, risk assessment, and access control are performed by a dedicated micro-model composite deployed on the local data plane, and model management and iteration are performed by the local control plane. The original business data does not leave the domain and does not need to be uploaded to the cloud.

[0074] The specific implementation of the present invention will be described in detail below with reference to specific embodiments.

[0075] Example 1: This example illustrates the security protection process of a power trading platform subjected to an order-grabbing attack using an external script. A provincial power trading center has opened an API platform with the order submission interface POST / api / v1 / transaction / order, allowing market participants such as power generation companies and electricity sales companies to submit electricity trading orders. Attackers use automated external scripts to simulate normal user browser behavior. By randomizing the User-Agent and request intervals, and automatically bypassing CAPTCHAs, they submit a large number of low-priced electricity purchase orders in batches the moment the trading window opens, in order to seize market share. The attack request parameters conform to the API specification, and the access frequency is designed not to trigger traditional threshold alarms, making it difficult for traditional WAF or API security gateways based on URL, User-Agent, and access frequency to distinguish between external scripts and normal users.

[0076] For the above request, the parameter model, the identity model, and the behavior model are detected in parallel.

[0077] The parameter model obtains a complete HTTP request, where the request method is POST, the request path is / api / v1 / transaction / order, and the request body is a JSON-formatted order parameter, including the declared electricity volume, declared electricity price, delivery period, and trading instrument. The Gaussian mixture model calculates the joint probability distribution of numerical parameters such as declared electricity price and declared electricity volume. Normal market participants' quotations typically show electricity prices fluctuating slightly with the market benchmark price, and declared electricity volume is related to the company's historical production capacity. In the 10 consecutive orders submitted by this attack script, the declared electricity price was always the market minimum price, and the declared electricity volume was always the maximum declared amount. The joint probability density of this parameter combination in the Gaussian mixture model is lower than the 1st percentile of normal training data, thus forming an abnormal joint parameter distribution. The density-based noise application space clustering model converts access subject information such as historical transaction frequency, quotation strategy distribution, and delivery period preference corresponding to the same enterprise account into behavioral feature vectors and compares them with historical dense clusters. The account's historical trading activity involved manual quoting from 9:00 to 11:00 on weekdays, averaging 2-3 transactions per day. However, this time, 10 orders were submitted consecutively at a millisecond-level speed the instant the trading window opened, thus appearing as an isolated outlier in the feature space. The parameter model outputs a parameter-level anomaly score of 78, with anomaly types including joint parameter distribution anomaly, quotation pattern deviation, and time density anomaly.

[0078] The identity model retrieves identity credentials such as the OAuth AccessToken, enterprise digital certificate, and API key from the request, and uses a single-class support vector machine model to compare the current credential usage characteristics with the decision boundary of normal identity credential usage patterns. The credential usage characteristics include the historical call time distribution of the enterprise certificate, IP address location, and API key rotation cycle. Although the current credential itself is legal and valid, not expired or revoked, it generates a millisecond-level burst of calls when the transaction window opens, significantly deviating from the account's historical manual operation pattern and falling outside the decision boundary learned by the single-class support vector machine model. The identity model outputs an identity-level anomaly score of 65, with anomaly types including call timing pattern anomalies and operation density deviations.

[0079] The behavioral model obtains the complete API call chain of the account, including querying market information via GET / api / v1 / market / price before the transaction, submitting an order via POST / api / v1 / transaction / order, and querying the order status via GET / api / v1 / transaction / status. The graph neural network model compares the current call path with the legitimate user access journey. The normal manual trading path involves querying market information, submitting one order, checking the order status after a few minutes of manual operation, and then ending the transaction. In contrast, this call path involves submitting 10 orders consecutively after querying market information, with the interval between adjacent order requests being less than 50ms, followed by checking the order status. The order submission phase exhibits a millisecond-level continuous pattern, and its distance from the normal call path in the graph neural network embedding space exceeds the normal range. The variational autoencoder model further detects temporal features, specifically, the generation of 10 orders within the first 500ms after the trading window opens, with a relatively even distribution of request intervals, differs from the temporal features formed by normal manual operations, resulting in a reconstruction error significantly higher than the normal traffic baseline. The behavioral model outputs a behavioral-level anomaly score of 85, with anomaly types including call rhythm anomalies, timing pattern deviations, and transaction density exceeding limits.

[0080] The risk signal bus correlates and fuses the risk signals output by the parameter model, the identity model, and the behavior model. In this highly sensitive power trading scenario, the risk scores corresponding to the parameter model, identity model, and behavior model are 78, 65, and 85, respectively, and the model weights are dynamically adjusted according to the business scenario, with the behavior model weight adjusted to 0.35. In one specific fusion method, the comprehensive risk score is calculated as 0.20×78+0.35×65+0.35×85+0.10×80, where 80 is the initial score of the security micro-model, resulting in a comprehensive risk score of 76.1. Since the comprehensive risk score is greater than the preset high-risk threshold of 75, the current request is determined to be a high-risk request.

[0081] The security micro-model receives a fused feature vector and a business scenario label, where the business scenario label is "scene: power_trading" and the sensitivity level is S. The security micro-model employs the Q-Learning algorithm, querying the Q-value table based on the current state vector. For states corresponding to high behavioral anomalies, high parameter anomalies, and high-sensitivity business scenarios, the corresponding access control action is blocking and triggering manual review. Therefore, the security micro-model determines the access control decision for the current request as blocking, with a decision confidence level of 89%. The corresponding decision criteria include: the behavioral model detecting millisecond-level batch order submissions deviating from the normal manual trading rhythm when the trading window opens; the parameter model detecting scripted abnormal characteristics in the combination of quotation parameters; and a comprehensive risk score of 76.1, meeting the blocking conditions corresponding to a sensitive power trading scenario.

[0082] Example 2: In this example, the above-mentioned two-tier architecture Web and API micro-model security protection system is applied to the BIM collaboration platform in the construction industry to detect abnormal access and malicious file upload behavior to the BIM model file upload interface.

[0083] A large architectural design institute uses a cloud-based BIM collaboration platform. The platform provides a BIM model file upload and sharing API (POST / api / v1 / bim / model / upload), supporting designers to upload component model files in RFA format. An attacker obtained Azure storage credentials for a third-party Revit plugin and used the hard-coded plaintext access key and SAS token to upload a malicious RFA file to the shared library via the file upload API. This malicious RFA file exploits a remote code execution vulnerability in Autodesk Revit. When a designer loads this file, it may trigger an attack and lead to lateral movement within the internal network. Because the RFA file's format, size, and metadata conform to the platform specifications, traditional WAFs based on static signature rules struggle to identify this type of business-layer supply chain attack.

[0084] For the file upload request, the parameter model, identity model, and behavior model perform detection in parallel and output risk signals respectively.

[0085] The parameter model receives a POST request in multipart / form-data format, named / api / v1 / bim / model / upload. This request includes the binary content of the RFA file and metadata such as filename, version, author, and project ID. A Gaussian Mixture Model (GMM) models the joint distribution of file size, RFA version number, author ID, and project ID. Normally, RFA file size and version number are correlated with project stage. However, the current file's RFA version number is abnormally old, and the author ID does not match the project's historical participants; its joint probability density is significantly lower than the normal threshold.

[0086] Meanwhile, the density-based noise spatial clustering model DBSCAN converts the access subject information of the current upload request into a behavioral feature vector including historical upload frequency, upload time distribution, and file type distribution, and compares it with the dense clusters formed by historical normal business. This account's historical uploads typically occur during working hours, 2 to 3 times per week, while this upload of a single large file occurred in the early morning of Sunday, thus appearing as an isolated outlier in the feature space. The parametric model outputs a parametric-level anomaly score of 68, with anomaly types including "metadata joint distribution anomaly" and "isolated upload behavior."

[0087] The identity model, based on information such as the enterprise SSO token, device fingerprint, and IP address in the current request, uses a One-Class SVM model to compare the current designer account's login region, device, and active time period—these credential usage characteristics—with the decision boundary corresponding to normal identity authentication behavior. The current identity credentials themselves are valid (the account password is correct and the token has not expired), but the login IP address is located overseas, while the design institute does not have overseas business. Furthermore, the device fingerprint does not match historical records, and the access occurred during an inactive period. Therefore, the current credential usage characteristics fall outside the decision boundary. The identity model outputs an identity-level anomaly score of 85, with anomaly types including "login from a different location," "device fingerprint mismatch," and "access during an inactive period."

[0088] The behavioral model detects the call path of the current account, which includes login, a project list query (GET / api / v1 / project / list), and a file upload (POST / api / v1 / bim / model / upload). The graph neural network model (GNN) compares the current call path with the legitimate designer's access journey. The normal call path is: login → project list query → view project details → download or upload project-related files → log out; while the current call path is: login → project list query and traverse all projects → upload files to projects not belonging to this designer, thus clearly deviating from the normal business call path.

[0089] Meanwhile, the Variational Autoencoder (VAE) model detects temporal and load characteristics such as access during non-working hours and abnormal file sizes during file uploads, and the resulting reconstruction error is significantly higher than the baseline of normal business traffic. The behavioral model outputs a behavioral-level anomaly score of 79, with deviation types including "abnormal path jump," "project permission violation," and "temporal feature deviation."

[0090] The risk signal bus correlates and fuses the risk signals output by the parameter model, the identity model, and the behavior model. In this embodiment, the risk scores corresponding to the parameter model, identity model, and behavior model are 68, 85, and 79, respectively. Since the current BIM model is a core design asset, the weights of the identity model and behavior model are increased in the scenario-based risk calculation, with the parameter model having a weight of 0.20, the identity model having a weight of 0.30, and the behavior model having a weight of 0.30. This is combined with the initial safety micro-model score of 75 and its corresponding weight of 0.20 for comprehensive calculation.

[0091] 0.20×68+0.30×85+0.30×79+0.20×75=77.8.

[0092] The overall risk score is 77.8, which is greater than the preset high-risk threshold of 75. Therefore, the current request falls into the "high-risk" range. The risk signal bus forms a fused feature vector based on the overall risk score, the risk sub-item information of each model, and the abnormal feature information, and sends it as the overall risk information to the security micro-model.

[0093] The security micro-model receives the fused feature vector and the business scenario label, where the business scenario label is scene: "bim_upload", and the asset sensitivity level is S. The security micro-model uses the Q-Learning algorithm to query the Q-value table based on the state vectors corresponding to the current high identity anomaly, high behavior anomaly, and core design asset scenarios, and determines the access control decision as "block and trigger MFA verification".

[0094] The security micro-model outputs an access control decision of "blocking and triggering MFA verification" with a decision confidence level of 91%. The corresponding decision basis includes: the identity model detected that the current account logged in from an overseas IP during non-working hours and the device fingerprint did not match; the behavior model detected that files were uploaded to unauthorized projects; the parameter model detected abnormal file metadata; the comprehensive risk score is 77.8, which meets the blocking conditions corresponding to the BIM core asset upload scenario.

[0095] Based on the access control decision, the data plane blocks the current file upload request and triggers secondary MFA verification for the corresponding account; if verification fails, the corresponding account is frozen. The RFA file can also be sent to a sandbox for dynamic analysis. The interpretable AI module in the central security intelligence and orchestration engine performs risk attribution analysis and feature contribution quantification based on the comprehensive risk information, and generates corresponding alarm reports and risk location information.

[0096] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A two-tier architecture Web and API micro-model security protection system, characterized in that, The system includes a control plane and a data plane; The control plane includes a central security intelligence and orchestration engine for generating and managing proprietary micro-model complexes for API endpoints, web interfaces, or mini-program interfaces. The data plane is set on the necessary path of business traffic and includes a dedicated micro-model composite, which includes a parameter model, a behavior model, an identity model and a security micro-model. A risk signal bus is set inside the dedicated micro-model composite. The parameter model, behavior model, and identity model detect the parameter features, call behavior features, and identity features of the request, respectively, and output risk signals. The risk signal bus correlates and fuses the risk signals to obtain comprehensive risk information. The security micro-model is an access decision agent based on reinforcement learning, used to determine access control decisions based on the comprehensive risk information.

2. The two-tier architecture Web and API micro-model security protection system according to claim 1, characterized in that, The control plane and the data plane communicate through a dual-channel separation architecture with bidirectional asynchronous long connections. The dual channels include a control and management distribution channel and a data reporting channel. The control and management distribution channel is used to distribute incremental package of model parameters, lightweight model inference files, protection policy files, feature template library and global threat intelligence to the data plane. The data reporting channel is used to send back traffic samples, risk scores, decision feedback and device heartbeats to the control plane.

3. The two-tier architecture Web and API micro-model security protection system according to claim 1, characterized in that, The risk signals adopt a unified structured message format, which includes a public association field, a model-private risk field, and an interpretability feature field. The risk signal bus uses a three-level association key to associate the risk signals. The first-level association key is a globally unique tracking identifier for the entire lifecycle of a single API request, used to aggregate risk signals corresponding to the same request. The second-level association key is used to batch aggregate time-series risk signals corresponding to the same interface and the same user. The third-level association key is used for cross-request risk association based on identity credentials and source IP.

4. The two-tier architecture Web and API micro-model security protection system according to claim 1, characterized in that, The risk signal bus is used to correct the original risk scores output by each model according to the model confidence weights of the parameter model, the behavior model, and the identity model. When the corrected risk scores of at least two models corresponding to the same request are greater than a preset risk threshold, a cross-penalty of multi-dimensional joint risk is superimposed, and a global comprehensive risk score is generated based on the risk score after superimposing the cross-penalty. The global comprehensive risk score, the risk sub-item information of each model, and the abnormal feature information are encapsulated into a fusion feature vector and sent to the security micro-model.

5. The two-tier architecture Web and API micro-model security protection system according to claim 1, characterized in that, The central security intelligence and orchestration engine includes an MLOps model lifecycle management module. This module generates and assembles corresponding dedicated micro-model complexes based on business profile matching algorithm combinations formed by different API interface functions, parameter types, and calling scenarios. It also automatically optimizes hyperparameters to determine the operating parameters of each micro-model within the dedicated micro-model complex. Furthermore, the module incrementally updates the dedicated micro-model complexes based on collected business traffic change data and normal behavior iteration data through online incremental learning.

6. The two-tier architecture Web and API micro-model security protection system according to claim 1, characterized in that, The central security intelligence and orchestration engine includes a global threat intelligence internalization module. This module is used to analyze new attack logic, 0DAY variant attacks, or customized business attacks based on the Transformer architecture and extract new threat features. Based on the federated learning framework, it synchronizes the new threat features and optimized model parameters to a dedicated micro-model composite on multiple nodes, without requiring user private business data to leave the domain.

7. The two-tier architecture Web and API micro-model security protection system according to claim 1, characterized in that, The parameter model includes a Gaussian mixture model and a density-based noise application space clustering model. The Gaussian mixture model is used to model the normal distribution probability of numerical parameters and the joint distribution among multiple parameters. The density-based noise application space clustering model is used to convert the access subject information in the request traffic into behavioral feature vectors and perform density clustering on the behavioral feature vectors. The behavioral model includes a graph neural network model and a variational autoencoder model. The graph neural network model is used to model the API call chain, and the variational autoencoder model is used to establish a baseline for request frequency, load size and timing characteristics and detect anomalies based on reconstruction error. The identity model includes a single-class support vector machine model, which is used to learn the decision boundary of identity credential usage patterns based on normal identity authentication behavior data, and to identify abnormal identity invocation behavior based on the decision boundary.

8. The two-tier architecture Web and API micro-model security protection system according to claim 1, characterized in that, The security micro-model adopts the Q-Learning algorithm to model access control as a Markov decision process. It takes a state vector, including identity credibility, device security reputation, behavior score, access time, network environment, business scenario label and parameter anomaly score, as input to determine one of the following access control decisions: allow, alarm, block or require multi-factor authentication.

9. The two-tier architecture Web and API micro-model security protection system according to claim 1, characterized in that, The central security intelligence and orchestration engine includes an interpretable AI module, which is used to perform risk attribution analysis and feature contribution quantification on security alarms based on the comprehensive risk information, and output alarm reports and risk location information.

Images