Maas platform model secure deployment method and system

Abstract

The application relates to artificial intelligence security technology and discloses a Maas platform model security deployment method and system. The method comprises the following steps: calculating a network attack risk coefficient according to an IDS alarm score and a WAF interception event frequency; calculating a host attack risk coefficient according to a container runtime exception event number and a number of honeypot triggering times; calculating threat fitting degrees based on a number of model API requests in a unit time, a request parameter exception score, the network attack risk coefficient and the host attack risk coefficient; calculating a data sensitivity factor according to a data sensitivity level; and calculating a target security audit log sampling rate based on a global minimum reference sampling rate, the threat fitting degrees and the data sensitivity factor and adjusting a current sampling rate. The application realizes fusion evaluation of multi-source security data, dynamically adjusts the security audit log sampling rate according to a real-time threat environment and a data sensitivity degree, guarantees complete recording of key events, optimizes system resource consumption, and improves adaptive security protection capability of the MaaS platform.

Description

Technical Field

[0001] This invention pertains to artificial intelligence security technology, and particularly relates to a method and system for secure deployment of Maas platform models. Background Technology

[0002] With the rapid development of artificial intelligence (AI) technology, the Model-as-a-Service (MaaS) model has become the core architecture for enterprises to provide intelligent capabilities to internal and external users. MaaS platforms encapsulate trained machine learning models into standardized API interfaces, enabling various applications to easily call model services, significantly reducing the application threshold and deployment complexity of AI technology. However, while this open API service architecture enhances convenience, it also introduces multi-layered security vulnerabilities. Model API interfaces are directly exposed to the network environment, making them highly susceptible to malicious request attacks, including but not limited to parameter injection attacks, distributed denial-of-service attacks, and theft or reverse engineering of the models themselves. Simultaneously, the underlying infrastructure supporting the MaaS platform, especially containerized runtime environments and host systems, continuously faces security threats such as vulnerability exploitation, privilege escalation attacks, and covert verification and calculation programs, which may compromise the integrity and availability of model services.

[0003] Current security protection systems primarily rely on intrusion detection systems (IDS) to monitor abnormal network traffic, web application firewalls (Web Application Firewalls) to filter malicious HTTP requests, container runtime security monitoring tools to detect abnormal process behavior, and honeypot technology to lure potential attackers. While these mechanisms can identify local risks within their respective domains, the alert data they generate is scattered across independent monitoring systems, lacking an effective correlation analysis framework and a unified risk quantification standard. For example, there is no mathematical correlation between the frequency of alert events reported by IDS and the abnormal requests blocked by Web Application Firewalls, making it impossible to accurately assess the overall risk level at the network layer. Similarly, the isolated processing of abnormal events at container runtimes and honeypot trigger records makes it difficult to comprehensively assess the threat posture at the host level. Furthermore, security audit logs, as a crucial basis for post-incident traceability, generally employ a fixed sampling rate mechanism for collection. This static strategy wastes significant storage resources and computational overhead during low-risk periods, while during high-risk periods, insufficient sampling leads to the omission of critical attack evidence, failing to achieve dynamic matching of security protection resources with the real-time threat environment. Existing technologies have failed to establish a risk assessment model that integrates multi-source security data from the network layer, host layer, and application layer, and also lack a mechanism to adaptively adjust the audit log sampling rate based on comprehensive risk quantification results, resulting in significant blind spots for MaaS platforms when dealing with complex and ever-changing network attacks. Summary of the Invention

[0004] The purpose of this invention is to provide a secure deployment method and system for Maas platform models, aiming to solve the above-mentioned problems.

[0005] This invention is implemented as follows: a secure deployment method for a Maas platform model, the method comprising: Based on the obtained IDS alarm scores and WAF interception event frequency, a network attack risk coefficient representing the overall attack risk level at the network layer is calculated. Based on the number of abnormal events during container runtime and the number of honeypot triggers, calculate and obtain the host attack risk coefficient, which represents the overall attack risk level at the host level; Based on the number of requests received by the model API per unit time, the abnormal score of request parameters, the network attack risk coefficient, and the host attack risk coefficient, the threat fit degree, which represents the degree of matching between the current request and the overall threat environment of the system, is calculated and obtained. Based on the obtained data sensitivity level, calculate the data sensitivity factor representing the privacy sensitivity level of the data processed by the model; Based on the global minimum baseline sampling rate, threat fit, and data sensitivity factor, the target security audit log sampling rate is calculated and obtained, and the current security audit log sampling rate is adjusted to the target security audit log sampling rate.

[0006] As a further aspect of the present invention, the process for calculating and obtaining the network attack risk coefficient is as follows: Obtain IDS alarm score and WAF interception event frequency; The IDS alarm score is obtained by comparing the current IDS alarm score with the maximum IDS alarm score. The WAF interception event frequency index is obtained by comparing the current WAF interception event frequency with the maximum threshold of WAF interception event frequency and then using the min function to limit the upper limit of the ratio to 1. Based on the IDS alarm index and WAF interception event frequency index, a probability merging method is used to calculate the network attack risk coefficient. When either the IDS alarm index or the WAF interception event frequency index approaches 1, the overall risk coefficient approaches 1.

[0007] As a further aspect of the present invention, the calculation and acquisition process for the host attack risk coefficient is as follows: Get the number of runtime exceptions and honeypot triggers for the container; The ratios of the current number of abnormal events and the number of honeypot triggers during container runtime are compared with the maximum thresholds for the number of abnormal events and the number of honeypot triggers during container runtime, respectively. After using the min function to limit the upper limit of the ratio to 1, the abnormal event index and the honeypot trigger count index are obtained. Based on the abnormal event index and the honeypot trigger frequency index, a host attack risk coefficient is calculated using a weighted summation method. Both the abnormal event index and the honeypot trigger frequency index are positively correlated with the host attack risk coefficient.

[0008] As a further aspect of the present invention, the calculation and acquisition process for the threat fit is as follows: Obtain the number of requests received by the model API per unit time, the abnormal score of request parameters, the network attack risk coefficient, and the host attack risk coefficient; The absolute value of the difference between the number of requests received by the model API per unit time and the historical baseline rate is compared with the historical baseline rate to obtain the relative deviation of the request rate. The ratio of the relative deviation of the request rate to the maximum allowable multiple of the call frequency deviation is calculated, and the upper limit of the ratio is limited to 1 by the min function to obtain the call frequency deviation. The larger value between the network attack risk coefficient and the host attack risk coefficient is taken as the background risk coefficient. Based on the call frequency deviation and the abnormal score of request parameters, the request abnormality coefficient is calculated using a non-complementary probability merging method. Substitute the background risk coefficient and the request anomaly coefficient into the formula. Obtain threat fit ,in, Background risk coefficient, This is the request exception coefficient.

[0009] As a further aspect of the present invention, ,when When the value approaches 0, it indicates low background risk and no anomalies in the request itself. When the value approaches 1, it indicates that the background risk is high or the request is abnormally serious.

[0010] As a further aspect of the present invention, the calculation and acquisition process of the data sensitivity factor is as follows: Obtain the data sensitivity level; The data sensitivity factor is obtained by comparing the difference between the current data sensitivity level and the minimum data sensitivity level with the maximum data sensitivity level. .

[0011] As a further aspect of the present invention, ,when When the value approaches 0, it indicates the lowest data sensitivity. When the value approaches 1, it indicates the highest data sensitivity.

[0012] As a further aspect of the present invention, the calculation and acquisition process for the target security audit log sampling rate is as follows: Obtain the global minimum baseline sampling rate, threat fit, and data sensitivity factor; The maximum value among the global minimum baseline sampling rate, threat fit, and data sensitivity factor is taken as the target security audit log sampling rate.

[0013] The present invention also provides a Maas platform model secure deployment system, the system being used to implement the Maas platform model secure deployment method, the system comprising: The network layer evaluation module is used to calculate and obtain the network attack risk coefficient, which represents the overall attack risk level at the network layer, based on the obtained IDS alarm score and WAF interception event frequency. The host layer assessment module is used to calculate the host attack risk coefficient, which represents the overall attack risk level at the host layer, based on the number of abnormal events during container runtime and the number of honeypot triggers. The threat identification module is used to calculate and obtain the threat fit degree, which represents the degree of matching between the current request and the overall threat environment of the system, based on the number of requests received by the model API and the abnormal score of the request parameters, as well as the network attack risk coefficient and the host attack risk coefficient, within a unit of time. The sensitivity quantification module is used to calculate the data sensitivity factor that represents the privacy sensitivity level of the data processed by the model, based on the acquired data sensitivity level. The sampling rate determination module is used to calculate the target security audit log sampling rate based on the global minimum baseline sampling rate, threat fit, and data sensitivity factor, and adjust the current security audit log sampling rate to the target security audit log sampling rate.

[0014] As a further aspect of the present invention, the process for calculating and obtaining the network attack risk coefficient is as follows: Obtain IDS alarm score and WAF interception event frequency; The IDS alarm score is obtained by comparing the current IDS alarm score with the maximum IDS alarm score. The WAF interception event frequency index is obtained by comparing the current WAF interception event frequency with the maximum threshold of WAF interception event frequency and then using the min function to limit the upper limit of the ratio to 1. Based on the IDS alarm index and WAF interception event frequency index, a probability merging method is used to calculate the network attack risk coefficient. When either the IDS alarm index or the WAF interception event frequency index approaches 1, the overall risk coefficient approaches 1.

[0015] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention quantifies and integrates multi-dimensional security information, including network layer, host layer, application layer, and data sensitivity, to construct a comprehensive risk index. This overcomes the limitations of traditional isolated alerts, making risk assessment more comprehensive and objective. Based on real-time threat relevance and data sensitivity factors, it adaptively adjusts the audit log sampling rate. In high-risk or high-sensitivity scenarios, it increases the sampling rate to ensure no key evidence is missed, while in low-risk scenarios, it reduces the sampling rate to decrease storage and computational overhead, achieving a dynamic balance between security protection and resource utilization. It can automatically optimize audit strategies according to changes in the threat landscape without manual intervention, significantly improving the response speed and proactive defense level of the MaaS platform against complex network attacks. Attached Figure Description

[0016] Figure 1 This is a flowchart of a secure deployment method for a Maas platform model provided by the present invention.

[0017] Figure 2 This invention provides a structural block diagram of a secure deployment system for a Maas platform model. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0019] In traditional MaaS platform security deployments, alerts from multiple security data sources are isolated and lack a unified risk quantification and assessment mechanism. Specifically, security events generated by intrusion detection systems, web application firewalls, container runtime security monitoring, and honeypot technologies cannot be effectively integrated, making it impossible to accurately assess the overall risk level faced by the model service. Furthermore, the sampling rate of security audit logs uses a fixed strategy and cannot be dynamically adjusted according to real-time risk changes. This can lead to the potential omission of critical security events during high-risk periods and the excessive consumption of storage and computing resources during low-risk periods, thus affecting system resource utilization and security event detection coverage.

[0020] For example, on a MaaS platform deploying an image recognition model, when an external attacker launches a combined model theft and denial-of-service attack, the intrusion detection system detects abnormal traffic patterns and generates alert scores, the web application firewall frequently blocks malicious parameter requests, but container runtime monitoring does not detect any process anomalies, and the honeypot is not triggered. The security operations center receives these scattered alerts and struggles to quickly determine the overall risk correlation between the network and host layers. In this scenario, the fixed sampling rate of security audit logs cannot adapt to the dynamic changes in attack intensity, resulting in some critical request parameter details not being recorded during peak attack periods, while an excessively high sampling rate during attack intervals causes unnecessary resource overhead.

[0021] If the above issues are not addressed, the security team will be unable to identify and respond to multi-dimensional collaborative attacks in a timely manner, increasing the risk of successful intrusion into the model service; incomplete or redundant security audit logs will weaken the ability to trace and collect evidence after an incident, affecting the root cause analysis of security incidents; overall, the platform's security situation awareness capabilities will be significantly constrained, potentially leading to serious consequences such as service interruptions or data breaches.

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

[0023] Figure 1 A flowchart illustrating a secure deployment method for a Maas platform model provided by the present invention. In one embodiment of the technical solution of the present invention, a secure deployment method for a Maas platform model is provided, the method comprising: Step S100: Based on the obtained IDS alarm score and WAF interception event frequency, calculate and obtain the network attack risk coefficient, which represents the overall attack risk level at the network layer. Step S200: Based on the number of abnormal events during container runtime and the number of honeypot triggers, calculate and obtain the host attack risk coefficient, which represents the overall attack risk level at the host level; Step S300: Based on the number of requests received by the model API per unit time, the abnormal score of request parameters, the network attack risk coefficient, and the host attack risk coefficient, calculate and obtain the threat fit degree, which represents the degree of matching between the current request and the overall threat environment of the system. Step S400: Based on the obtained data sensitivity level, calculate the data sensitivity factor representing the privacy sensitivity level of the data processed by the model; Step S500: Based on the global minimum baseline sampling rate, threat fit, and data sensitivity factor, calculate and obtain the target security audit log sampling rate, and adjust the current security audit log sampling rate to the target security audit log sampling rate; In the above content, a network attack risk coefficient, representing the overall attack risk level at the network layer, is calculated based on the obtained IDS alert score and WAF interception event frequency. The IDS alert score is a risk score generated by the Intrusion Detection System (IDS) based on the network anomalies or attack behaviors it detects. This score typically reflects the severity and urgency of the network attack; a higher score indicates a greater network attack risk. The WAF interception event frequency refers to the number of malicious requests or attack attempts intercepted by the Web Application Firewall (WAF) per unit of time. This frequency is an important indicator of the activity level of attacks at the Web application layer; a higher frequency indicates that the Web application faces more frequent attack threats.

[0024] Based on the number of abnormal events during container runtime and the number of honeypot triggers, a host attack risk coefficient, representing the overall attack risk level at the host level, is calculated. The number of abnormal events during container runtime refers to the number of abnormal behaviors or events detected by the container runtime monitoring system in a containerized environment. These abnormal events may include abnormal process startup, file system tampering, and network connection anomalies, reflecting the security status inside the container. The number of honeypot triggers refers to the number of times a honeypot deployed in the system is probed or attacked by attackers. A honeypot is a security decoy system used to attract, detect, and analyze attack behavior; its trigger count can serve as an indicator of host-level attacks or probes.

[0025] Based on the number of requests received by the model API per unit time, the request parameter anomaly score, and the network attack risk coefficient and host attack risk coefficient, a threat fit degree, representing the degree of matching between the current request and the overall system threat environment, is calculated. Call frequency deviation refers to the degree of deviation between the actual call frequency of the model API and its historical baseline call frequency. Abnormal call frequency deviations may indicate denial-of-service attacks, abuse, or abnormal business requests. The request parameter anomaly score is a score evaluating the degree of anomaly of the request parameters received by the model API after analysis. This score identifies potential malicious requests or attack payloads by detecting anomalies in parameter format, value range, semantics, etc. Threat fit degree is a quantitative indicator representing the degree of matching between the current request and the overall system threat environment. This indicator comprehensively considers the anomalies of the request itself (such as call frequency deviation and request parameter anomaly score) and the background risks at the network and host levels of the system to determine the potential threat level of the request.

[0026] Based on the acquired data sensitivity level, a data sensitivity factor is calculated to characterize the privacy sensitivity level of the data processed by the model. The data sensitivity level refers to the degree of sensitivity of the data processed by the model in terms of privacy and security. This level is typically classified according to the data content (such as whether it contains personally identifiable information, financial data, trade secrets, etc.). A higher level indicates more sensitive data, requiring a higher level of protection. The data sensitivity factor is a quantitative representation of the data sensitivity level. This factor converts the abstract data sensitivity level into a numerical value, facilitating calculation and application in risk assessment and strategy adjustment.

[0027] Based on the global minimum baseline sampling rate, threat relevance, and data sensitivity factors, the target security audit log sampling rate is calculated and adjusted to the target rate. The global minimum baseline sampling rate refers to the lowest sampling rate that security audit logs should maintain under any circumstances. This baseline rate ensures that a sufficient amount of audit logs can be collected even when system risk is at its lowest to meet compliance and basic traceability requirements. The target security audit log sampling rate is the ideal sampling rate dynamically calculated based on the overall risks faced by the current system, used to guide the collection of security audit logs. This sampling rate aims to achieve refined management of security audits, avoiding resource waste or omission of critical information. The security audit log sampling rate refers to the proportion of all available log events selected for recording when collecting security audit logs. By adjusting this sampling rate, the use of storage and processing resources can be optimized while ensuring the effectiveness of security audits.

[0028] In existing technologies, security audit logs are typically collected using a fixed sampling rate, and multi-source security alerts are often isolated, lacking a unified risk quantification and assessment mechanism. For example, traditional MaaS platforms may simply maintain a constant log sampling rate based solely on the number of alerts from IDS or WAF. When faced with multiple overlapping threats as described above, a fixed sampling rate can lead to two extremes: if the sampling rate is too low, crucial attack evidence may be missed, making effective tracing and response impossible; if the sampling rate is too high, it results in a significant waste of storage and computing resources during low-risk periods.

[0029] This embodiment constructs a comprehensive indicator, "threat fit," by integrating multi-dimensional information such as network attack risk coefficient, host attack risk coefficient, request anomaly coefficient, and data sensitivity factors. This enables a dynamic and quantitative assessment of the overall risks faced by the MaaS platform model services. Compared to the isolated alarm information processing methods in existing technologies, this multi-source data fusion risk assessment mechanism provides a more comprehensive and accurate risk view.

[0030] This embodiment further proposes the following process for calculating and obtaining the network attack risk coefficient: Obtain IDS alert scores and WAF interception event frequency. An IDS alert score is a quantitative indicator assigned by an Intrusion Detection System (IDS) to potential attacks or anomalies identified after analyzing network traffic or system behavior based on its detection rules and algorithms. This score typically reflects the severity or confidence level of the alert. It can be obtained in real-time through the API provided by the IDS system or extracted from IDS logs using log parsing tools. The WAF interception event frequency refers to the number of times a Web Application Firewall (WAF) successfully intercepts malicious requests or attack attempts per unit of time. This frequency is an important indicator of the attack pressure faced by a web application. It can be obtained periodically through the statistical interface provided by the WAF management platform or by aggregating and statistically analyzing the security logs generated by the WAF.

[0031] The IDS alarm index is obtained by comparing the current IDS alarm score with the maximum IDS alarm score. This step aims to convert the original IDS alarm score into a dimensionless index between 0 and 1, thereby eliminating differences in dimensions and numerical ranges between different IDS systems or different alarm types. This ratio directly reflects the relative position of the current alarm score within historical or preset maximum values, providing standardized input for subsequent risk fusion calculations. This can be achieved through a simple division operation: IDS Alarm Index = Current IDS Alarm Score / Maximum IDS Alarm Score. The maximum IDS alarm score refers to the highest possible value the IDS alarm score can reach within a specific time window or historical data, used to normalize the current IDS alarm score. This maximum value can be set based on statistical analysis of historical operational data or preset by security experts based on experience.

[0032] The WAF interception event frequency index is obtained by comparing the current WAF interception event frequency with the maximum threshold for WAF interception event frequency, and then using a min function to limit the ratio to an upper limit of 1. The purpose of this step is to standardize the original WAF interception event frequency into an index between 0 and 1, so that it can be calculated uniformly with other risk indicators. By comparing it with the maximum threshold, the relative level of the current interception frequency can be quantified. Using a min function to limit the ratio to an upper limit of 1 ensures that even in extreme cases (such as when the interception frequency far exceeds the maximum threshold), the resulting index will not exceed 1, maintaining its reasonableness as a risk probability or intensity indicator. This can be achieved by setting the WAF interception event frequency index to min(1, current WAF interception event frequency / maximum threshold for WAF interception event frequency). The maximum threshold for WAF interception event frequency refers to the upper limit value at which the WAF interception event frequency is considered abnormally high or saturated within a specific time window or historical data, used to normalize the current WAF interception event frequency. This maximum threshold can be dynamically adjusted based on the baseline frequency during normal system operation combined with security policies, or set as the highest interception frequency the system can withstand.

[0033] Based on the IDS alarm index and WAF interception event frequency index, a probability merging method is used to calculate the network attack risk coefficient. When either the IDS alarm index or the WAF interception event frequency index approaches 1, the overall risk coefficient approaches 1. Specifically, the calculation method is as follows: substitute the IDS alarm index and the WAF interception event frequency index into the formula... Obtain the network attack risk coefficient This step combines the standardized IDS alert index and the WAF interception event frequency index using a fusion calculation formula to obtain a unified network attack risk coefficient. This formula employs a non-linear fusion method, which can more accurately reflect the cumulative effect of overall network risk when both network attack indicators exist simultaneously or when one of them significantly increases. For example, when either index approaches 1, the network attack risk coefficient will rapidly approach 1, indicating that the network faces a serious threat. ,when When the value approaches 0, it indicates an extremely low risk of network attacks and a secure network environment. When the value approaches 1, it indicates an extremely high risk of network attack, meaning the network is under serious attack or threat. This refers to the IDS alarm index. This is the frequency index of events intercepted by the WAF.

[0034] This embodiment employs a series of logically rigorous steps to accurately quantify network-level attack risks. First, the system acquires IDS alert scores and WAF interception event frequencies, which are raw data reflecting network security posture. To eliminate differences in units and numerical ranges among these raw data and enable effective fusion calculations, the system further acquires the maximum IDS alert score and the maximum threshold for WAF interception event frequency. Subsequently, by comparing the current IDS alert score with the maximum IDS alert score, an IDS alert index is generated, which standardizes the severity of IDS alerts to a range of 0 to 1. Similarly, the current WAF interception event frequency is compared with the maximum WAF interception event frequency threshold, and a min function is used to limit the upper limit of the ratio to 1, thereby obtaining the WAF interception event frequency index. This index is also standardized to a range of 0 to 1, effectively avoiding the excessive influence of extremely high-frequency data on risk assessment. Finally, these two standardized indices are substituted into a specific fusion formula. This formula cleverly combines two independent risk indicators non-linearly, so that when either indicator increases, the overall network attack risk coefficient rises. Both will increase accordingly, especially when both are high simultaneously, the risk coefficient will rapidly approach 1, thus more sensitively and accurately reflecting the comprehensive attack threats faced by the network. This refined calculation process ensures that the network attack risk coefficient assessment results have higher reliability and interpretability, providing a solid foundation for subsequent threat fit calculations, thereby improving the accuracy and effectiveness of the entire Maas platform model security deployment method.

[0035] Through the above technical solution, this embodiment provides a standardized and quantitative method for calculating network attack risk coefficients. This method normalizes IDS alert scores and WAF interception event frequencies and employs a specific fusion formula, overcoming the problems of inconsistent original data dimensions and large differences in numerical ranges. This avoids risk assessment distortions that may result from simple aggregation or averaging. This refined calculation method makes the network attack risk coefficient assessment results more accurate, objective, and comparable, more realistically reflecting the overall attack risk level at the network layer. This not only provides high-quality input for subsequent threat fit calculations but also significantly improves the sensitivity and effectiveness of the Maas platform model security deployment method in identifying and responding to network threats, ensuring that the adjustment of the security audit log sampling rate can more accurately match the actual network security situation.

[0036] This embodiment further proposes the following process for calculating and obtaining the host attack risk coefficient: This section describes the acquisition of the number of runtime anomalies and honeypot triggers within a containerized environment. The runtime anomaly count refers to the number of unexpected or suspicious behaviors detected during runtime. These anomalies can include, but are not limited to, unauthorized process startup, tampering with critical files or configurations, abnormal network connection attempts, and resource abuse. This can be obtained through real-time monitoring and log analysis by a runtime security agent deployed on the container host or inside the container, or by collecting security audit logs from an integrated container orchestration platform. The honeypot trigger count refers to the number of times a honeypot deployed in the system has been probed, accessed, or exploited by attackers. A honeypot is a security trapping system designed to simulate a real service or system, attract attackers, and record their behavior to identify potential attack activities. The honeypot trigger count can be obtained through the honeypot system's own logging function. For example, when an attacker attempts to connect to a specific port of the honeypot, access a simulated service of the honeypot, or execute a specific command, the honeypot will record and report a trigger event.

[0037] The current number of runtime exceptions and honeypot triggers are compared to the maximum thresholds for runtime exceptions and honeypot triggers, respectively. A min function is then used to limit the ratio to a maximum of 1, yielding the exception event index and honeypot trigger count index. The min function ensures that the calculated index value will not exceed 1. Limiting the upper limit to 1 ensures that the index value in the subsequent risk coefficient calculation formula remains within a certain range. This ensures that the final calculated host attack risk coefficient is also within the specified range. Within a reasonable range, avoid distorting the risk coefficient due to extreme values. The anomaly event index reflects the severity or activity of anomalies during container runtime; a higher value indicates more frequent or severe anomalies, and a greater risk to the host. The honeypot trigger frequency index reflects the activity of the honeypot being probed or exploited by attackers; a higher value indicates a higher frequency of honeypot triggers, and a greater potential attack risk to the host.

[0038] The maximum threshold for the number of runtime anomalies in a container refers to the upper limit of the range considered "normal" or "acceptable" within a specific time window. This threshold can be derived based on historical data statistical analysis, for example, by taking the 95th or 99th percentile of the number of anomalies over a past period; it can also be set by security experts based on experience or industry best practices; or it can be dynamically adjusted through machine learning models to adapt to changes in system behavior. The maximum threshold for the number of honeypot triggers refers to the upper limit of the range considered "normal" or "acceptable" within a specific time window. Similar to the maximum threshold for the number of runtime anomalies in a container, this threshold can be based on statistical analysis of historical honeypot trigger data, for example, by setting it as a multiple of the historical average number of triggers; it can also be manually set by security operations personnel based on the honeypot deployment strategy and expected results; or it can be dynamically adjusted through adaptive algorithms based on environmental changes.

[0039] Based on the anomaly event index and the honeypot trigger frequency index, a weighted summation method is used to calculate the host attack risk coefficient. Both the anomaly event index and the honeypot trigger frequency index are positively correlated with the host attack risk coefficient. Specifically, the calculation method involves substituting the anomaly event index and the honeypot trigger frequency index into the formula. Obtain the host attack risk coefficient , ,when When the value approaches 0, it indicates that the host layer risk is extremely low, the container runs without exceptions, the honeypot has not been triggered, and the host environment is secure. When the value approaches 1, it indicates an extremely high risk at the host layer, meaning that the number of abnormal events and honeypot triggers during container runtime is very high, and the host is under attack or probe. The weights of the abnormal events are in the range of 0-1. This weight is used to measure the relative importance of abnormal events during container runtime in calculating the host attack risk coefficient. This weight can be configured by security policy makers based on business sensitivity, attack surface analysis, and risk preferences, or it can be optimized through machine learning methods, combining historical attack data and risk assessment results. This is an index of abnormal events. This represents the honeypot trigger frequency index.

[0040] This embodiment proposes a systematic host attack risk coefficient calculation process in the Maas platform model security deployment method to accurately assess the overall attack risk at the host level. The process first obtains the real-time number of abnormal events during container runtime and the number of honeypot triggers as raw input for potential threats at the host level. To transform this raw data into comparable and quantifiable risk indicators, the system further obtains preset maximum thresholds for the number of abnormal events during container runtime and the number of honeypot triggers. These thresholds serve as benchmarks for standardizing the raw event counts. Specifically, the current number of abnormal events during container runtime and the number of honeypot triggers are each compared to their corresponding maximum thresholds to obtain a preliminary risk ratio. To ensure these ratios are within a reasonable range and to avoid numerical overflow in extreme cases, the system uses a min function to limit the upper limit of the ratio to 1, thereby generating a standardized abnormal event index. Honeypot trigger frequency index Both indices range from 0 to 1, intuitively reflecting the risk level of their respective indicators. Subsequently, to comprehensively consider risk information from these two different sources, the system introduced an anomaly event weight. This weighting allows security policies to adjust the relative importance of container runtime anomalies and honeypot trigger counts in the final risk assessment based on actual circumstances. Ultimately, the standardized anomaly index will be... Honeypot trigger frequency index Substitute into the weighted average formula This allows for the calculation of the host attack risk coefficient. This coefficient, also ranging from 0 to 1, comprehensively and quantitatively characterizes the overall attack risk level at the host level. When When the value approaches 0, it indicates that the host environment is secure and the risk of attack is extremely low; when... When the value approaches 1, it indicates that the host is under severe attack or probe, posing an extremely high risk. Through this refined calculation process, this embodiment provides an accurate and reliable host attack risk assessment for the secure deployment method of the Maas platform model, thereby supporting subsequent threat fit calculations and dynamic adjustment of the security audit log sampling rate, enabling security deployment strategies to respond more accurately to the threat landscape at the host level.

[0041] Through the above technical solution, this embodiment provides a quantitative and configurable method for calculating host attack risk coefficients, solving the technical problem of how to accurately and standardizedly assess host-level attack risks in the secure deployment of Maas platform models. This method standardizes two key indicators—the number of abnormal events during container runtime and the number of honeypot triggers—and introduces adjustable abnormal event weights, making the calculation of the host attack risk coefficient more refined and flexible. This not only more accurately reflects the real threat situation faced by the host, avoiding misjudgments that may result from simple counting, but also allows for adjusting the relative importance of various indicators according to different security strategies and business needs, thus making the risk assessment results more consistent with actual scenarios. Ultimately, this precise host attack risk coefficient provides a more reliable input for the secure deployment method of Maas platform models, thereby optimizing the calculation of threat fit and guiding the dynamic adjustment of the security audit log sampling rate, effectively improving the overall security protection capabilities and resource utilization efficiency of the Maas platform.

[0042] This embodiment further proposes the following process for calculating and obtaining threat fit: This metric retrieves the number of requests received by the model API per unit time, request parameter anomaly scores, network attack risk coefficients, and host attack risk coefficients. The number of requests received by the model API per unit time refers to the total number of requests received by the model API endpoint within a preset time window (e.g., per second, per minute, or every 5 minutes). This metric is fundamental data for measuring the frequency and load of model service calls, used to assess normal fluctuations and abnormal deviations in request traffic, thereby assisting in identifying potential denial-of-service attacks, malicious crawling, or business abuse. It can be obtained in real-time through the monitoring and statistics functions of the API gateway, or through periodic analysis and aggregation of model API access logs. In containerized or cloud-native environments, it can also be obtained using telemetry data from service mesh or API call count metrics provided by cloud monitoring services. The request parameter anomaly score refers to the degree of anomaly of parameters in model API requests. Anomaly parameters may include illegal values, values ​​out of range, maliciously injected content, or parameter combinations inconsistent with historical patterns. This score can be obtained by validating the parameters of each request using predefined rules regarding the legal range, type, and format of parameters, and assigning corresponding anomaly scores based on the degree of violation. Alternatively, machine learning models, such as anomaly detection algorithms (e.g., IsolationForest, One-ClassSVM), can be used to learn from historical request parameters, identify parameter patterns significantly different from normal patterns, and generate anomaly scores accordingly. The network attack risk coefficient is a quantitative indicator representing the overall attack risk level at the network level; a higher value indicates a greater attack risk to the network environment. The host attack risk coefficient is a quantitative indicator representing the overall attack risk level at the host level; a higher value indicates a greater attack risk to the host environment.

[0043] The absolute value of the difference between the number of requests received by the model API per unit time and the historical baseline rate is compared with the historical baseline rate to obtain the relative deviation of the request rate. This step is used to quantify the degree of deviation of the current request frequency from the normal level. The historical baseline rate refers to the average or typical number of requests per unit time when the model API is operating normally. It is a reference standard for measuring whether the current request frequency is abnormal. This rate can be obtained by collecting the request logs of the model API over a long period of time, statistically analyzing the average request rate for different time periods (such as hours, days, and weeks), and updating it periodically. Alternatively, a dynamic baseline learning algorithm can be used to adaptively adjust and update the baseline rate based on the actual operation of the API to adapt to seasonal or trend changes in business volume.

[0044] The call frequency deviation is obtained by comparing the relative deviation of the request rate with the maximum allowable multiple of the call frequency deviation, and then using a min function to limit the ratio to a maximum of 1. This step quantifies the degree of deviation of the current request frequency from the normal level. The maximum allowable multiple of the call frequency deviation refers to the maximum multiple of the relative deviation of the request rate allowed when calculating the call frequency deviation. It is used to limit the upper limit of the deviation and prevent extreme outliers from having an excessive impact on the calculation results. This multiple can be preset with a fixed value based on business experience or security policies. For example, the maximum allowable relative deviation of the request rate is 5 times the baseline rate. Alternatively, a reasonable upper limit can be determined by statistical analysis of historical data. For example, the 99th percentile of the historical relative deviation of the request rate can be used as the maximum allowable multiple.

[0045] The larger of the network attack risk coefficient and the host attack risk coefficient is taken as the background risk coefficient; the background risk coefficient is an indicator that comprehensively reflects the overall security status of the current network environment and host environment, and is used to assess the macro threat background of the request.

[0046] Based on call frequency deviation and request parameter anomaly score, a non-complementary probability merging method is used to calculate the request anomaly coefficient; specifically, the calculation method is as follows: substitute the call frequency deviation and request parameter anomaly score into the formula. Get the request exception coefficient The request anomaly coefficient is an indicator that comprehensively reflects the degree of anomaly of a single request, combining the deviation of the request's call frequency and the anomaly score of the request parameters. Among these, For call frequency deviation, Scoring for abnormal request parameters; Substitute the background risk coefficient and the request anomaly coefficient into the formula. Obtain threat fit Threat fit is a quantitative indicator that represents the degree to which the current request matches the overall threat environment of the system. A high fit means that the request is highly relevant to the current high-risk environment or that the request itself is exceptionally serious. ,when When the value approaches 0, it indicates low background risk and no abnormality in the request itself; the request is highly likely to be normal behavior. When the value approaches 1, it indicates a high background risk or an abnormally serious request, suggesting the request is highly likely to be an attack and requires close auditing. Background risk coefficient, This is the request exception coefficient.

[0047] This embodiment first obtains the historical baseline rate and the maximum allowable multiple of call frequency deviation, and monitors the number of requests received by the model API per unit time in real time. By comparing the current number of requests with the historical baseline rate, the relative deviation of the request rate is calculated, and further combined with the maximum allowable multiple of call frequency deviation, the call frequency deviation is obtained through amplitude limiting. Simultaneously, the system obtains request parameter anomaly scores to assess the degree of anomaly of the request parameters themselves. In terms of macro-environmental risk assessment, the system obtains the aforementioned network attack risk coefficient and host attack risk coefficient, and selects the larger value as the background risk coefficient to ensure sensitivity to any high-risk level. Subsequently, the call frequency deviation and request parameter anomaly scores are substituted into the fusion formula. Calculate the request exception coefficient This coefficient comprehensively reflects the degree of abnormality of the request itself. Ultimately, the background risk coefficient... and request exception coefficient Substituted into the fusion formula The threat fit was calculated. This fusion process cleverly combines macro-environmental risks with micro-level request anomalies, making threat assessments for each request more comprehensive and accurate. When the threat fit is... When the value approaches 1, it indicates a high background risk or an abnormally serious request, suggesting the request is highly likely to be an attack and requires close auditing; when... When the value approaches 0, it indicates that the background risk is low and the request itself is not abnormal, and the request is very likely to be normal behavior.

[0048] Through the above technical solution, this embodiment organically combines macro-level system environment risks (network attack risk coefficient and host attack risk coefficient) with micro-level request anomalies (call frequency deviation and request parameter anomaly score). This combination makes the threat assessment of each request more refined and accurate, avoiding misjudgments or omissions that may result from relying solely on overall environment risks. By comprehensively considering background risks and request anomalies, this embodiment can more effectively identify requests that are highly relevant to the current high-risk environment or that have serious anomalies themselves, thereby providing a more targeted basis for subsequent security audit log sampling and significantly improving the efficiency and accuracy of Maas platform model security deployment.

[0049] This embodiment further proposes the following process for calculating and obtaining data sensitivity factors: Data sensitivity levels are determined by the degree of harm that data may cause to individuals, organizations, or society in the event of leakage, misuse, or unauthorized access. These levels can be manually labeled according to preset classification criteria, such as categorizing data into "Public," "Internal," "Restricted," "Confidential," and "Top Secret," assigning a numerical value to each level. Alternatively, Natural Language Processing (NLP) technology can be used to analyze the data content, identify sensitive information (such as ID numbers, bank card numbers, and health information), and automatically assign sensitivity levels based on the identification results.

[0050] The data sensitivity factor is obtained by comparing the difference between the current data sensitivity level and the minimum data sensitivity level with the maximum data sensitivity level. This step transforms discrete or qualitative data sensitivity levels into a continuous, standardized quantification factor between 0 and 1, facilitating subsequent mathematical calculations and risk assessment. This can be achieved through linear normalization, mapping the original sensitivity levels to... Intervals. Piecewise functions or nonlinear mappings can also be used, and nonlinear normalization can be performed based on the actual risk weights of different sensitivity levels to more accurately reflect the differences in sensitivity levels. ,when When the value approaches 0, it indicates the lowest data sensitivity, meaning it does not involve personal privacy or sensitive information. A value close to 1 indicates the highest data sensitivity, involving highly sensitive information that requires enhanced protection. The minimum data sensitivity level refers to the numerical value corresponding to the lowest sensitivity level within a preset data sensitivity level system. For example, if the sensitivity level ranges from 0 to 5, with 0 representing the lowest sensitivity, the minimum data sensitivity level can be set to 0. Alternatively, based on actual business needs, data that does not involve any personal privacy or sensitive information can be defined as having the lowest sensitivity, and a baseline value can be assigned to it. The maximum data sensitivity level refers to the numerical value corresponding to the highest sensitivity level within a preset data sensitivity level system. For example, if the sensitivity level ranges from 0 to 5, with 5 representing the highest sensitivity, the maximum data sensitivity level can be set to 5. Alternatively, based on the definitions of highly sensitive personal information (such as biometric data, health data, and financial data) in laws and regulations (such as GDPR and CCPA), data involving such information can be defined as having the highest sensitivity, and an upper limit value can be assigned to it.

[0051] This embodiment obtains the current data sensitivity level of the data processed by the model and standardizes it by combining a preset minimum and maximum data sensitivity level. Specifically, it first calculates the difference between the current data sensitivity level and the minimum data sensitivity level, reflecting the degree of improvement in current data sensitivity relative to the lowest sensitivity baseline. Then, it ratios this difference to the maximum data sensitivity level, thereby normalizing the original data sensitivity levels, which may have different dimensions or ranges, into a dimensionless data sensitivity factor between 0 and 1. This data sensitivity factor This method can intuitively and quantitatively represent the level of data privacy sensitivity, where a value close to 0 indicates extremely low sensitivity, and a value close to 1 indicates extremely high sensitivity. Through this standardized calculation method, the data sensitivity factor... It can be effectively integrated with other risk factors (such as threat fit and global minimum baseline sampling rate) to jointly determine the final target security audit log sampling rate, ensuring that the Maas platform can fully consider the privacy sensitivity of the data itself when conducting security audits, thereby achieving more refined and targeted security protection.

[0052] Through the above technical solution, this embodiment provides a standardized and quantitative method for assessing data privacy sensitivity levels, ensuring that data sensitivity factors accurately reflect the privacy risks of the data processed by the model. This quantitative processing allows data of different types and sensitivities to be uniformly included in the scope of security audit strategies, avoiding insufficient auditing of sensitive data or excessive auditing of non-sensitive data. This is achieved by normalizing data sensitivity factors to... The range allows for effective integration with other risk factors, thus considering not only network and host attack risks but also the privacy sensitivity of the data itself when calculating the target security audit log sampling rate. This improves the efficiency and security of audit resource allocation and ensures the compliance and security of the Maas platform when processing data of different sensitivities.

[0053] This embodiment further proposes the following process for calculating and obtaining the target security audit log sampling rate: The system obtains the global minimum baseline sampling rate, threat fit, and data sensitivity factor. The global minimum baseline sampling rate refers to the minimum log sampling percentage that must be guaranteed under all circumstances. Its purpose is to ensure that even when the system is judged to be low-risk, there is still basic audit data available for analysis, preventing the complete omission of potential subtle anomalies due to over-optimization. This baseline value can be preset based on compliance requirements, industry standards, or the system administrator's experience. For example, it can be set to 0.01 (i.e., 1%), indicating that at least 1% of logs will be audited, or set to 0.05 (i.e., 5%) to meet more stringent audit requirements. Threat fit characterizes the degree to which the current request matches the overall threat environment of the system. Its purpose is to quantify the potential threat level of a single request or operation, thereby guiding the audit system to conduct a more detailed review of high-risk requests. Threat fit can be a value between 0 and 1, where 0 indicates that the request does not match the threat environment (low risk), and 1 indicates that the request matches the threat environment very well (high risk). The data sensitivity factor characterizes the privacy sensitivity level of the data processed by the model. Its purpose is to reflect the value of the data itself and the risk of leakage, ensuring more rigorous auditing of operations involving sensitive data. The data sensitivity factor is typically a value between 0 and 1, where 0 indicates the data is not sensitive and 1 indicates the data is highly sensitive.

[0054] The maximum value among the global minimum baseline sampling rate, threat relevance, and data sensitivity factor is taken as the target security audit log sampling rate. The target security audit log sampling rate refers to the ideal log sampling ratio that the system should adjust to. Its function is to dynamically and adaptively adjust the granularity of log collection to optimize system resource consumption while ensuring the effectiveness of security audits. The calculation of this sampling rate aims to comprehensively consider various risk factors currently faced, ensuring that the sampling rate is increased when the risk is high and decreased when the risk is low.

[0055] This embodiment achieves dynamic and intelligent adjustment of the security audit log sampling rate for the Maas platform model by obtaining the global minimum baseline sampling rate, threat relevance, and data sensitivity factor, and selecting the maximum value as the target security audit log sampling rate. The core of this method is that it does not simply weight the various risk factors, but adopts a "maximum value" strategy. This means that as long as any dimension of risk (whether it's basic compliance requirements, the threat level of the current request, or the sensitivity of the processed data) reaches a high level, the system will correspondingly increase the audit log sampling rate. This mechanism ensures that in complex environments with multiple risk factors, the audit system can always operate in the most conservative and secure manner, i.e., "better to audit more than to audit less." For example, even if the threat relevance of the current request is not high, if the processed data is highly sensitive, or the minimum baseline sampling rate set by the system is already high, then the final sampling rate will be determined by these high-risk factors, thus avoiding the risk of insufficient overall audit strength due to a single low-risk factor. This design allows the audit strategy to flexibly adapt to the constantly changing threat landscape and data value, effectively balancing security assurance and resource consumption.

[0056] Through the above technical solution, this embodiment can dynamically and adaptively determine the target security audit log sampling rate based on the risk assessment results of three dimensions: global minimum baseline sampling rate, threat relevance, and data sensitivity factors. This "maximum value" strategy ensures that the audit intensity can be promptly increased when any risk dimension is high, avoiding the risk of diluting the overall audit intensity due to a single low-risk factor. This enables the Maas platform to maintain sufficient security audit coverage when facing complex and ever-changing network attacks, host anomalies, and sensitive data processing scenarios, effectively preventing potential security threats, while avoiding unnecessary full audits in low-risk situations. This optimizes the efficiency of system resource utilization and achieves an effective balance between security assurance and resource consumption.

[0057] like Figure 2 As shown, in a preferred embodiment of the technical solution of the present invention, the present invention also provides a Maas platform model secure deployment system, the system 10 comprising: The network layer evaluation module 11 is used to calculate and obtain the network attack risk coefficient, which represents the overall attack risk level at the network layer, based on the obtained IDS alarm score and WAF interception event frequency. The host layer evaluation module 12 is used to calculate and obtain the host attack risk coefficient, which represents the overall attack risk level at the host layer, based on the number of abnormal events during container runtime and the number of honeypot triggers. The threat identification module 13 is used to calculate and obtain the threat fit degree, which represents the degree of matching between the current request and the overall threat environment of the system, based on the number of requests received by the model API and the abnormal score of the request parameters, as well as the network attack risk coefficient and the host attack risk coefficient within a unit of time. Sensitivity quantification module 14 is used to calculate the data sensitivity factor representing the privacy sensitivity level of the data processed by the model based on the acquired data sensitivity level. The sampling rate determination module 15 is used to calculate and obtain the target security audit log sampling rate based on the global minimum baseline sampling rate, threat fit and data sensitivity factor, and adjust the current security audit log sampling rate to the target security audit log sampling rate.

[0058] The calculation and acquisition process for the network attack risk coefficient is as follows: Obtain IDS alarm score and WAF interception event frequency; The IDS alarm score is obtained by comparing the current IDS alarm score with the maximum IDS alarm score. The WAF interception event frequency index is obtained by comparing the current WAF interception event frequency with the maximum threshold of WAF interception event frequency and then using the min function to limit the upper limit of the ratio to 1. Based on the IDS alarm index and WAF interception event frequency index, a probability merging method is used to calculate the network attack risk coefficient. When either the IDS alarm index or the WAF interception event frequency index approaches 1, the overall risk coefficient approaches 1.

[0059] The system executes programs in memory through the processor to calculate network attack risk coefficients based on the acquired IDS alarm scores and WAF interception event frequency; calculate host attack risk coefficients based on the acquired number of abnormal events during container runtime and honeypot triggering times; calculate threat fit based on call frequency deviation, request parameter anomaly scores, network attack risk coefficients, and host attack risk coefficients; calculate data sensitivity factors based on the acquired data sensitivity levels; and calculate the target security audit log sampling rate based on the global minimum baseline sampling rate, threat fit, and data sensitivity factors. Finally, it adjusts the current security audit log sampling rate to the target security audit log sampling rate.

[0060] The core innovation of this embodiment lies in combining network attack risk coefficient, host attack risk coefficient, call frequency deviation, request parameter anomaly score, and data sensitivity level in a quantitative fusion manner. This achieves dynamic assessment of the overall risk of the model service and adaptive adjustment of the security audit log sampling rate, thus optimizing resource utilization while ensuring the effectiveness of security auditing. Specifically, addressing the technical problems in the background technology of isolated multi-source security alarm information, lack of a unified risk quantification assessment mechanism, and difficulty in adaptively adjusting the security audit log sampling rate with risk changes, the system constructs a comprehensive indicator called threat fit. This indicator correlates network-level and host-level risk data with request behavior characteristics and introduces a data sensitivity factor to reflect the data privacy sensitivity level. Since threat fit characterizes the degree of matching between the current request and the overall threat environment of the system, a value close to 1 indicates that the request is highly likely to be an attack and requires focused auditing. The data sensitivity factor quantifies the degree of data privacy sensitivity; a value close to 1 indicates that the data involves highly sensitive information. Therefore, by taking the maximum value among the global minimum baseline sampling rate, threat fit, and data sensitivity factor as the target security audit log sampling rate, the system can automatically increase the sampling rate when the risk is high or the data sensitivity is high to ensure the capture of critical security events; and reduce the sampling rate when the risk is low to avoid wasting storage and computing resources.

[0061] Taking a real-world deployment scenario as an example, when the MaaS platform processes a financial transaction fraud detection model, if the network attack risk coefficient approaches 1 due to the increase in IDS alarm scores, the host attack risk coefficient approaches 1 due to the increase in the number of abnormal events during container runtime, the threat fit approaches 1 due to the increase in call frequency deviation and abnormal request parameter scores, and the data sensitivity factor approaches 1 due to the processing of highly sensitive transaction data, then the target security audit log sampling rate will be dynamically adjusted to close to 100%. At this point, the system can fully record security audit logs, providing a complete chain of evidence for attack tracing. Conversely, if all risk indicators approach 0, the sampling rate can be reduced to the global minimum baseline sampling rate, significantly reducing resource consumption. Through the above technical solution, this system effectively solves the problems of isolated security alarm information, lack of risk assessment mechanisms, and resource waste or omission of key events caused by fixed sampling rates in existing technologies, achieving refined and intelligent management of security audit strategies.

[0062] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A secure deployment method for a Maas platform model, characterized in that, The method includes: Based on the obtained IDS alarm scores and WAF interception event frequency, a network attack risk coefficient representing the overall attack risk level at the network layer is calculated. Based on the number of abnormal events during container runtime and the number of honeypot triggers, calculate and obtain the host attack risk coefficient, which represents the overall attack risk level at the host level; Based on the number of requests received by the model API per unit time, the abnormal score of request parameters, the network attack risk coefficient, and the host attack risk coefficient, the threat fit degree, which represents the degree of matching between the current request and the overall threat environment of the system, is calculated and obtained. Based on the obtained data sensitivity level, calculate the data sensitivity factor representing the privacy sensitivity level of the data processed by the model; Based on the global minimum baseline sampling rate, threat fit, and data sensitivity factor, the target security audit log sampling rate is calculated and obtained, and the current security audit log sampling rate is adjusted to the target security audit log sampling rate.

2. The secure deployment method for the Maas platform model according to claim 1, characterized in that, The process for calculating and obtaining the network attack risk coefficient is as follows: Obtain IDS alarm score and WAF interception event frequency; The IDS alarm score is obtained by comparing the current IDS alarm score with the maximum IDS alarm score. The WAF interception event frequency index is obtained by comparing the current WAF interception event frequency with the maximum threshold of WAF interception event frequency and then using the min function to limit the upper limit of the ratio to 1. Based on the IDS alarm index and WAF interception event frequency index, a network attack risk coefficient is calculated using a probability merging method. When either the IDS alarm index or the WAF interception event frequency index approaches 1, the overall risk coefficient approaches 1.

3. The secure deployment method for the Maas platform model according to claim 1, characterized in that, The process for calculating and obtaining the host attack risk coefficient is as follows: Get the number of runtime exceptions and honeypot triggers for the container; The abnormal event index and honeypot trigger count are obtained by comparing the current number of abnormal events and honeypot trigger counts of the container runtime with the maximum thresholds for the number of abnormal events and honeypot trigger counts, respectively, and then using the min function to limit the upper limit of the ratio to 1. Based on the abnormal event index and the honeypot trigger frequency index, a host attack risk coefficient is calculated using a weighted summation method. Both the abnormal event index and the honeypot trigger frequency index are positively correlated with the host attack risk coefficient.

4. The secure deployment method for the Maas platform model according to claim 1, characterized in that, The calculation and acquisition process for the threat fit is as follows: Obtain the number of requests received by the model API per unit time, the abnormal score of request parameters, the network attack risk coefficient, and the host attack risk coefficient; The absolute value of the difference between the number of requests received by the model API per unit time and the historical baseline rate is compared with the historical baseline rate to obtain the relative deviation of the request rate. The ratio of the relative deviation of the request rate to the maximum allowable multiple of the call frequency deviation is calculated, and the upper limit of the ratio is limited to 1 by the min function to obtain the call frequency deviation. The larger value between the network attack risk coefficient and the host attack risk coefficient is taken as the background risk coefficient. Based on the call frequency deviation and the abnormal score of request parameters, the request abnormality coefficient is calculated using a non-complementary probability merging method. Substitute the background risk coefficient and the request anomaly coefficient into the formula. Obtain threat fit ,in, Background risk coefficient, This is the request exception coefficient.

5. The secure deployment method for the Maas platform model according to claim 4, characterized in that, ,when When the value approaches 0, it indicates low background risk and no anomalies in the request itself. When the value approaches 1, it indicates that the background risk is high or the request is abnormally serious.

6. The secure deployment method for the Maas platform model according to claim 1, characterized in that, The calculation and acquisition process for the data sensitivity factor is as follows: Obtain the data sensitivity level; The data sensitivity factor is obtained by comparing the difference between the current data sensitivity level and the minimum data sensitivity level with the maximum data sensitivity level. .

7. The secure deployment method for the Maas platform model according to claim 6, characterized in that, ,when When the value approaches 0, it indicates the lowest data sensitivity. When the value approaches 1, it indicates the highest data sensitivity.

8. The secure deployment method for the Maas platform model according to claim 1, characterized in that, The calculation and acquisition process for the target security audit log sampling rate is as follows: Obtain the global minimum baseline sampling rate, threat fit, and data sensitivity factor; The maximum value among the global minimum baseline sampling rate, threat fit, and data sensitivity factor is taken as the target security audit log sampling rate.

9. A secure deployment system for a Maas platform model, characterized in that, The system is used to implement the secure deployment method for the Maas platform model as described in any one of claims 1 to 8, and the system includes: The network layer evaluation module is used to calculate and obtain the network attack risk coefficient, which represents the overall attack risk level at the network layer, based on the obtained IDS alarm score and WAF interception event frequency. The host layer assessment module is used to calculate the host attack risk coefficient, which represents the overall attack risk level at the host layer, based on the number of abnormal events during container runtime and the number of honeypot triggers. The threat identification module is used to calculate and obtain the threat fit degree, which represents the degree of matching between the current request and the overall threat environment of the system, based on the number of requests received by the model API and the abnormal score of the request parameters, as well as the network attack risk coefficient and the host attack risk coefficient, within a unit of time. The sensitivity quantification module is used to calculate the data sensitivity factor that represents the privacy sensitivity level of the data processed by the model, based on the acquired data sensitivity level. The sampling rate determination module is used to calculate the target security audit log sampling rate based on the global minimum baseline sampling rate, threat fit, and data sensitivity factor, and adjust the current security audit log sampling rate to the target security audit log sampling rate.

10. The Maas platform model secure deployment system according to claim 9, characterized in that, The process for calculating and obtaining the network attack risk coefficient is as follows: Obtain IDS alarm score and WAF interception event frequency; The IDS alarm score is obtained by comparing the current IDS alarm score with the maximum IDS alarm score. The WAF interception event frequency index is obtained by comparing the current WAF interception event frequency with the maximum threshold of WAF interception event frequency and then using the min function to limit the upper limit of the ratio to 1. Based on the IDS alarm index and WAF interception event frequency index, a network attack risk coefficient is calculated using a probability merging method. When either the IDS alarm index or the WAF interception event frequency index approaches 1, the overall risk coefficient approaches 1.

Images