Network micro-isolation protection method, system and device based on zero trust architecture

Abstract

The application relates to the technical field of network security, and specifically discloses a network micro-isolation protection method, system and device based on a zero-trust architecture, which comprises the following steps: globally mining unknown business dependencies and determining priorities, dynamically predicting evolution of attack paths based on generative adversarial reasoning, analyzing attack path root causes and adaptively reinforcing micro-isolation strategies, verifying and optimizing the strategies, and deploying the strategies and monitoring the effects; by combining dynamic taint analysis with generative adversarial reasoning, two difficult problems of unknown business dependency identification and dynamic attack path prediction are solved, hidden dependencies formed by temporarily transmitting payment tokens through log service can be accurately found and evaluated, and attack surface blind spots can be eliminated; unknown threat paths that cannot be identified by traditional methods can be generated by using generative AI to simulate and reason in a sandbox how attackers combine and use such dependencies and Log4j variants and other zero-day vulnerabilities, so that forward-looking early warning is realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network security, and in particular to a network micro-isolation protection method, system and device based on a zero-trust architecture. BACKGROUND

[0002] The zero-trust architecture is a new generation of network security concept, which does not trust any access request inside or outside the network by default, and each access must be strictly authenticated and authorized. Network micro-isolation is a key technical means to implement the zero-trust architecture, which refines the security boundary to the level of a single workload, such as a container, a virtual machine or a process, and restricts east-west traffic through fine-grained access control policies to prevent attackers from moving laterally within the network.

[0003] Existing micro-isolation protection schemes usually rely on static policy configuration and known threat intelligence. These schemes collect application performance monitoring data, network flow logs and other information, combine predefined security policy rules, and control access behavior between services. Some schemes use historical attack patterns to model threats to identify potential attack paths.

[0004] However, the existing technology has some technical limitations. Taking the cloud-native order processing system of an e-commerce platform as an example, its core payment link involves multiple microservices such as payment services, risk control services and log services. Due to changes in business requirements, the log service may temporarily transmit debugging information containing user payment tokens to a non-standard port of the risk control service in a way that is not registered in the application performance monitoring, forming a hidden business dependency. First, since existing schemes rely too much on pre-defined known business dependencies, they cannot dynamically identify such hidden channels through data flow propagation, resulting in an actual attack surface much larger than the policy control surface. Once an attacker breaches the log service, they can use this unknown dependency as a stepping stone to directly access the risk control service, enabling covert lateral movement. Second, when a new variant of the Log4j vulnerability appears, since the vulnerability has not been publicly disclosed and there is no available patch, traditional attack path prediction methods based on known vulnerability libraries are completely ineffective. Attackers can combine the zero-day vulnerability with the aforementioned hidden dependency to build a complete attack chain from the log service to the risk control service and then to the payment service. However, existing static threat modeling cannot deduce such attack paths that include unknown vulnerabilities and dynamic tactics, resulting in serious lag and blind spots in the protection system when facing advanced persistent threats. There are deficiencies in identifying hidden cloud-native business dependencies and predicting dynamic attack paths, which cannot meet the core requirements of the zero-trust architecture of defaulting to distrust any access and fine-grained access control to limit lateral movement. SUMMARY

[0005] In order to solve the above technical problems, the application provides a network micro-isolation protection method, system and device based on a zero-trust architecture, which can accurately identify hidden business dependencies and predict dynamic attack paths to meet the core requirements of the zero-trust architecture.

[0006] To achieve the above object, the application provides the following technical scheme:

[0007] In one aspect of the application, a network micro-isolation protection method based on a zero-trust architecture is provided, which comprises:

[0008] Collecting multi-source data of a cloud-native environment and preprocessing to obtain a standardized business interaction dataset; based on dynamic taint analysis, identifying unknown business dependencies in the dataset that are not recorded, combining life cycle attributes, business scenario risk weights and real-time risk signals to score the unknown business dependencies in priority, and generating an unknown business dependency priority ranking table;

[0009] Based on the unknown business dependency priority ranking table and pre-collected threat intelligence data, a red teaming sandbox is constructed; wherein the red teaming sandbox includes an attack scenario generator based on a generative adversarial network, and a digital twin environment for deploying a production environment network topology and existing micro-isolation strategies;

[0010] In the sandbox, the attack scenario generator is used to generate and iteratively optimize attack paths, calculate the feasibility score and threat level score of each attack path, and filter out attack paths with scores not lower than the corresponding preset threshold to form a high-risk dynamic attack path list;

[0011] Extracting key elements from the list as variables, calculating the average causal effect of each variable on attack success, and determining variables with an average causal effect not lower than a preset causal threshold as core root causes; generating a micro-isolation reinforcement strategy for the core root causes;

[0012] Deploying the micro-isolation reinforcement strategy in the digital twin environment and re-performing red teaming deduction, verifying the effectiveness of the strategy by calculating the proportion of blocked attack paths; if the effectiveness is not up to standard, the strategy is adjusted until it is verified;

[0013] Deploying the verified micro-isolation reinforcement strategy to the cloud-native environment, monitoring the execution status of the strategy in real time, and periodically updating the monitoring data and new threat intelligence data as new inputs.

[0014] Optionally, the dynamic taint analysis to identify unknown business dependencies in the dataset comprises:

[0015] Marking business payloads containing sensitive information in the standardized business interaction dataset as initial taints;

[0016] Track the propagation path of the initial taint during inter-service interactions and mark all service nodes involved in its propagation;

[0017] The marked service nodes are compared with the known business dependency list, and the service dependencies that exist in the propagation path but are not recorded in the known business dependency list are regarded as unknown business dependencies.

[0018] Optionally, the construction of the attack and defense sandbox includes:

[0019] The production network topology of the cloud-native environment is replicated to the digital twin environment. The production network topology includes service identifiers, dependencies in the unknown business dependency priority sorting table, and existing micro-segmentation strategies.

[0020] In a digital twin environment, an attack component that supports simulating zero-day vulnerability exploitation logic is used as an attack scenario generator, and a defense component that integrates existing micro-segmentation strategies and includes eBPF execution points and a strategy execution engine is used as a discriminator to complete the construction of the attack and defense adversarial sandbox.

[0021] Optionally, the calculation of the feasibility score and threat level score of each attack path, and the selection of attack paths whose scores are not lower than the corresponding preset thresholds to form a list of high-risk dynamic attack paths includes: determining the feasibility score by weighting the vulnerability exploitation success rate, dependency reachability and defense avoidance success rate of each step in the attack path, and determining the threat level score by weighting the feasibility score with the target service importance weight and the data impact weight.

[0022] Collect attack paths with a feasibility score no lower than the first preset threshold and a threat level score no lower than the second preset threshold to form a list of high-risk dynamic attack paths.

[0023] Optionally, the key elements extracted from the list include: vulnerabilities, dependency reachability, lack of defense strategies, and authentication flaws.

[0024] Optionally, the generation of micro-segmentation hardening strategies for the core root cause includes: if the core root cause is attributed to an identity authentication defect, then generating an authentication enhancement strategy.

[0025] If the root cause is attributed to excessive dependency on permissions, an environment isolation policy is generated that includes deploying a dedicated sidecar proxy for the service to achieve routing isolation and traffic auditing.

[0026] If the root cause is attributed to vulnerability exploitation, a virtual patching strategy is generated to intercept malicious traffic by deploying an eBPF program.

[0027] Optionally, the verifying the effectiveness of the strategy includes: counting the number of attack paths blocked by the micro-isolation reinforcement strategy, and calculating the ratio of the number to the total number of paths in the high-risk dynamic attack path list to obtain the blocking rate of the strategy.

[0028] If the blocking rate of the strategy is not lower than a first preset blocking threshold, it is determined that the strategy verification is passed.

[0029] When the cloud-native environment contains serverless functions, the verifying step further includes:

[0030] Separately calculating the blocking rate of the attack paths for the serverless functions, and when the blocking rate is not lower than a second preset blocking threshold, it is determined that the strategy verification is passed.

[0031] Optionally, the real-time monitoring of the execution state of the strategy includes: deploying an eBPF traffic monitoring probe to collect the execution log of the strategy, and additionally monitoring, for a serverless scenario, the function cold start success rate, the function call compliance rate, and the eBPF patch blocking rate.

[0032] In another aspect of the present application, a network micro-isolation protection system based on a zero-trust architecture is provided, which is implemented according to the method of any one of claims 1-8, and includes:

[0033] A business dependency intelligent perception module is configured to collect multi-source data of a cloud-native environment and pre-process the multi-source data to obtain a standardized business interaction dataset; based on dynamic taint analysis, unknown business dependencies not recorded in the dataset are identified, and priority scores of the unknown business dependencies are calculated in combination with life cycle attributes, business scenario risk weights, and real-time risk signals to generate an unknown business dependency priority ranking table;

[0034] An attack path simulation and deduction module is configured to construct a red teaming sandbox based on the unknown business dependency priority ranking table and pre-collected threat intelligence data; wherein the red teaming sandbox includes an attack scenario generator implemented based on a generative adversarial network, and a digital twin environment for deploying a production environment network topology and an existing micro-isolation strategy.

[0035] In the sandbox, the attack scenario generator is used to generate and iteratively optimize attack paths, calculate the feasibility scores and threat level scores of each attack path, and filter out attack paths with scores not lower than corresponding preset thresholds to form a high-risk dynamic attack path list.

[0036] A strategy generation module is configured to extract key elements from the list as variables, calculate the average causal effect of each variable on attack success, and determine variables with average causal effects not lower than a preset causal threshold as core root causes; and generate a micro-isolation reinforcement strategy for the core root causes.

[0037] The verification module is used to deploy micro-segmentation hardening strategies in a digital twin environment and re-perform attack and defense simulations. It verifies the effectiveness of the strategy by calculating the proportion of blocked attack paths. If the effectiveness does not meet the standard, the strategy is adjusted until the verification is successful.

[0038] The closed-loop monitoring module is used to deploy verified micro-segmentation hardening strategies to cloud-native environments, monitor the execution status of strategies in real time, and periodically iterate and update the strategies using monitoring data and newly added threat intelligence data as new inputs.

[0039] A third aspect of the present invention provides an electronic device including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of the network micro-segmentation protection method based on zero-trust architecture as described in any one of the first aspects.

[0040] The beneficial effects of this invention are:

[0041] Compared with existing technologies, the network micro-segmentation protection method based on zero-trust architecture provided in this application solves two major problems at the same time: identification of unknown business dependencies and prediction of dynamic attack paths by combining dynamic taint analysis with generative adversarial simulation. It can not only accurately discover and evaluate hidden dependencies such as payment tokens temporarily transmitted through log services, eliminating attack surface blind spots, but also use generative AI to simulate and deduce in a sandbox how attackers combine and exploit such dependencies with zero-day vulnerabilities such as Log4j variants to generate unknown threat paths that traditional methods cannot identify, thereby achieving proactive early warning.

[0042] This method possesses early warning and defense capabilities against unknown vulnerabilities and dynamic attack tactics. Through joint simulations using generative AI and adversarial sandboxes, it can model complete attack chains constructed by attackers exploiting zero-day vulnerabilities such as new Log4j variants, combined with discovered hidden dependencies. This dynamic attack path evolution prediction mechanism enables the system to discover and assess unknown threat paths that traditional methods cannot identify before real attacks occur.

[0043] This method achieves a shift in protection mode from passive response to proactive root cause immunity. By performing deep root cause analysis on predicted high-risk attack paths, it can pinpoint root causes such as authentication flaws or excessive reliance on privileges, and generate targeted micro-segmentation hardening strategies. Before deployment, the effectiveness of these strategies is validated and optimized in a sandbox environment to ensure that protective measures directly address the vulnerabilities, fundamentally eliminating security vulnerabilities, and forming an adaptive protection closed loop through continuous monitoring. Attached Figure Description

[0044] In order to more clearly illustrate the scheme in the present application, the drawings needed in the description of the embodiments of the present application will be briefly introduced as follows. Obviously, the drawings in the following description are some embodiments of the present application, and other drawings can also be obtained by those skilled in the art without creative labor on the basis of these drawings.

[0045] Figure 1 is a flow chart of the first embodiment of the present application;

[0046] Figure 2 is a system architecture diagram of the second embodiment of the present application;

[0047] Figure 3 is a structural schematic diagram of the third embodiment of the present application. DETAILED DESCRIPTION

[0048] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs; the terminology used in the description of the specification of the application is only for the purpose of describing specific embodiments and is not intended to limit the application; the terms "include" and "have" and any variations thereof in the specification and claims of the application and the above description of drawings are intended to cover non-exclusive inclusion.

[0049] Reference herein to "embodiments" means that the particular features, structures, or characteristics described in connection with the embodiments can be included in at least one embodiment of the present application. The appearance of this phrase in various places in the specification does not necessarily all refer to the same embodiment, nor is it necessarily mutually exclusive of other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0050] In order to enable those skilled in the art to better understand the scheme of the present application, the technical solutions in the embodiments of the present application will be described clearly and completely in conjunction with the drawings.

[0051] Embodiment one

[0052] As shown in Figure 1 , the network micro-isolation protection method based on zero trust architecture includes steps S101-S105:

[0053] S101, collect multi-source data of the cloud-native environment and pre-process to obtain a standardized business interaction dataset; based on dynamic taint analysis, identify unknown business dependencies in the dataset that are not recorded, combine life cycle attributes, business scenario risk weights, and real-time risk signals to prioritize the unknown business dependencies, and generate an unknown business dependency priority ranking table; S102, based on the unknown business dependency priority ranking table and pre-collected threat intelligence data, build an attack-defense confrontation sandbox; wherein the attack-defense confrontation sandbox includes an attack scenario generator based on a generative adversarial network, and a digital twin environment for deploying the production environment network topology and existing micro-isolation strategies;

[0054] In the sandbox, the attack scenario generator is used to generate and iteratively optimize attack paths, calculate the feasibility score and threat level score of each attack path, and filter out attack paths with scores not lower than the corresponding preset threshold to form a high-risk dynamic attack path list;

[0055] S103, extract key elements from the list as variables, calculate the average causal effect of each variable on attack success, and determine variables with an average causal effect not lower than a preset causal threshold as core root causes; generate a micro-isolation reinforcement strategy for the core root causes;

[0056] S104, deploy the micro-isolation reinforcement strategy in the digital twin environment and re-perform attack-defense confrontation deduction, and verify the effectiveness of the strategy by calculating the proportion of blocked attack paths; if the effectiveness is not up to standard, adjust the strategy until it is verified;

[0057] S105, deploy the verified micro-isolation reinforcement strategy to the cloud-native environment, monitor the execution status of the strategy in real time, and use the monitoring data and new threat intelligence data as new inputs for periodic iterative updates.

[0058] Optionally, the method of the present embodiment, through the following processing, collectively constitutes a specific scheme for implementing a zero-trust architecture:

[0059] Establish a dynamic and continuous trust evaluation basis: through global unknown business dependency dynamic mining and priority determination, use dynamic taint analysis technology to identify unknown data dependencies between all services, and dynamically prioritize based on life cycle, business scenario risk, and real-time risk signals; achieve default distrust and continuous monitoring of network internal access relationships, and change trust evaluation from static rules to dynamic calculation based on real-time context and data flow;

[0060] The core of implementing minimum access control: through attack path root cause analysis and micro-isolation policy adaptive reinforcement and policy verification and optimization, based on the root cause analysis of the attack path, the micro-isolation policy containing identity enhancement, environment isolation and virtual patch is generated, and the optimization is verified in the sandbox; Ensure that the final deployed policy follows the principle of least privilege, only grant the access necessary for service operation, and fundamentally shrink the attack surface;

[0061] Form an automated and adaptive policy closed loop: through dynamic attack path evolution prediction based on generative adversarial reasoning and policy deployment and effect monitoring, the attack path using zero-day vulnerabilities and unknown dependencies is predicted in advance using generative adversarial reasoning, and the verified policy is deployed to the production environment. Through real-time monitoring, an automated protection closed loop of continuous evaluation-policy generation-verification deployment-monitoring optimization is formed, realizing the core requirement of zero trust that is always verified.

[0062] In the above step S101, the purpose is to explain the global unknown business dependency dynamic mining and priority determination: collect multi-source data of cloud native environment and perform data cleaning and standardization to obtain standardized business interaction data set, identify unknown business dependencies based on dynamic taint analysis, combine life cycle attribute, business scenario risk weight and real-time risk signal, and perform three-dimensional dynamic priority scoring on unknown business dependencies to generate unknown business dependency priority ranking table.

[0063] Further, the unknown business dependency is an implicit dependency that actually exists in the cloud native environment and has data interaction or service call relationship, but is not recorded in the known business dependency list by the application performance monitoring system; The step of identifying unknown business dependencies based on dynamic taint analysis includes: marking the load containing sensitive data in the standardized business interaction data set as an initial taint; Track the propagation path of the initial taint in cross-service interaction and mark the taint associated services; Compare the known dependency list recorded by the application performance monitoring, and determine the taint associated services that do not appear in the known dependency list as unknown business dependencies; The integration object of the three-dimensional dynamic priority scoring includes interaction frequency, corrected data sensitivity score, life cycle attenuation coefficient, business scenario risk weight and real-time risk adjustment coefficient.

[0064] Step 1.1: Data collection and preprocessing: Collect multi-source data of cloud native environment, and perform data cleaning and data standardization to ensure data availability.

[0065] The collected data sources include:

[0066] Application Performance Monitoring (APM) data: covers service call link information, interface interaction frequency and data transmission volume;

[0067] Service mesh data: contains cross-service communication protocols, communication IP ports, and data payloads collected by Sidecar agents;

[0068] Infrastructure monitoring data: contains container Pod life cycle status, resource occupation, and access logs of virtual machines or serverless functions.

[0069] Application performance monitoring is a tool for monitoring application service call links and performance indicators, and its data comes from agents deployed in each service. Service mesh is an architecture for managing cross-service communication through Sidecar agents, and its data comes from traffic interception logs of Sidecars.

[0070] Data preprocessing includes:

[0071] Data cleaning: invalid data such as timeout failed call logs and format error data payloads are removed;

[0072] Data standardization: different sources of service identification are unified into service unique identification, such as based on Kubernetes namespace and service name generation, and interaction frequency is unified into call times per unit time.

[0073] The output after processing is a standardized business interaction dataset, containing fields: service unique identification, target dependency identification, interaction frequency, communication protocol, data payload, tracking identification, and collection timestamp.

[0074] Step 1.2: Unknown business dependency identification: based on dynamic taint analysis (DTA), identify APM-unrecorded hidden dependencies, i.e. unknown business dependencies, from the standardized business interaction dataset.

[0075] Dynamic taint analysis is a technique that marks sensitive data, i.e. taint, and traces its propagation path to identify data-related services. The core logic is data flow, i.e. dependency relationship, and the data source is the standardized business interaction dataset, which is used for unknown dependency list generation. Its core role is: in a cloud-native environment, when APM tools do not record the direct call relationship between services, by tracing the indirect flow of sensitive data between services, such as A service data flowing through middleware to B service, hidden dependencies not covered by APM are identified, ensuring that there is no omission in business dependency mining.

[0076] Initial taint is a sensitive data carrier marked for tracing, automatically identified and generated by data de-identification rules, and used as the starting point for subsequent taint propagation tracing.

[0077] The execution process includes:

[0078] Taint source marking: mark the payloads containing sensitive data in the standardized business interaction dataset as initial taint. The marking rule is based on data de-identification rules, such as using regular expressions to match personal identification information data;

[0079] Taint propagation tracking: tracking the propagation path of initial taint in cross-service interactions, when data marked as taint is transmitted to target service through communication protocol, the target service is marked as taint-associated service;

[0080] Unknown dependency screening: comparing the known dependency list recorded by APM, the services in taint-associated services that do not appear in the known list are determined as unknown business dependencies.

[0081] The output after processing is the unknown business dependency list, which includes the fields: unknown dependency identification, associated source service identification, interaction frequency, de-identified data payload and communication protocol.

[0082] Step 1.3: dependency life cycle annotation: based on the interaction timing characteristics of the unknown business dependency list, the life cycle attributes of each unknown dependency are automatically annotated, and the life cycle attenuation coefficient (LAC) is calculated to solve the priority misjudgment problem of temporary dependency and long-term dependency.

[0083] The life cycle attribute determination rules are as follows:

[0084] Temporary dependency: continuous access time is not more than 72 hours, and interaction frequency fluctuates with business events, for example, starting 2 hours before big promotion and stopping 1 hour after big promotion;

[0085] Periodic dependency: continuous access time ≥7 days, and interaction frequency presents fixed period, for example, third-party data backup interface at 3-4 am every day, with a period of 24 hours;

[0086] Long-term dependency: continuous access time ≥30 days, and interaction frequency fluctuation is not more than 10%, for example, daily log reporting interface.

[0087] The life cycle attenuation coefficient LAC is calculated by using piecewise function:

[0088] Temporary dependency: , where: T 剩余 is the time length from the current time of temporary dependency to the predicted stop time, for example, if temporary dependency is expected to stop after 2 hours, T 剩余 =2; T 总周期 is the total time length from the start to the predicted stop of temporary dependency, for example, if the total time length of temporary dependency during big promotion is 6 hours, T 总周期 =6, T 剩余 and T 总周期 are obtained by business event schedule or access trend prediction, if the predicted value is abnormal, LAC defaults to 0.5;

[0089] Periodic dependency: non-active period LAC=0.8, active period LAC=1.0;

[0090] Long-term dependency: LAC = 0.8 when there is no abnormal access, and LAC = 1.0 when there is sensitive data transmission in the near future.

[0091] LAC is a coefficient for quantifying the impact of dependency timeliness on risk, with a value range of 0.2-1.0. The higher the value, the higher the dependency on the current risk. The calculation is based on the life cycle attribute of the dependency and the real-time access state.

[0092] The output after processing is a list of unknown dependencies with life cycle labels, which adds life cycle attributes and life cycle attenuation coefficient values to the original fields.

[0093] Step 1.4: Business scenario risk weight binding: based on the tracking identifier in the unknown dependency list with life cycle labels, associate the business link label in APM, and bind the business scenario risk weight (BSW), while calculating the modified data sensitivity score DSS, to solve the risk misjudgment problem of the same dependency in different scenarios.

[0094] Step 1.4.1: Business link label association: match the business link record in APM through the tracking identifier, get the business scenario that the dependency belongs to, such as payment link, log link, and operation and maintenance link.

[0095] Step 1.4.2: Determine BSW: based on industry safety standards such as PCI DSS payment safety standard and GDPR data protection standard, preset the weight matrix, which includes business scenario, BSW, and data sensitivity weight correction coefficient K. BSW is used for business scenario risk weighting, and K is used for data sensitivity score correction. The specific content is as follows:

[0096] Payment and transaction link: BSW = 1.5, K = 1.5.

[0097] User data link: BSW = 1.2, K = 1.2.

[0098] Log monitoring link: BSW = 0.8, K = 0.8.

[0099] Operation and maintenance link: BSW = 0.5, K = 0.5.

[0100] Step 1.4.3: DSS correction: sensitive data identification is performed on the data payload in the unknown dependency list with life cycle labels, such as matching personal identity information or financial data based on the data loss prevention engine DLP. The initial DSS score is set according to the data type, with personal identity information data getting full marks and non-sensitive data getting three marks.

[0101] Corrected DSS = initial DSS x correction coefficient K corresponding to the business scenario.

[0102] DLP engine is a tool for identifying sensitive information such as ID number and credit card number in data, and its data source is DLP rule library, such as regular expression feature library.

[0103] After processing, the unknown dependency list with scene weight is output, and new fields are added: business scene label, BSW value and corrected DSS value.

[0104] Step 1.5: Three-dimensional dynamic priority scoring: integrate interaction frequency, corrected DSS, LAC and BSW, introduce real-time risk adjustment coefficient RAC, build three-dimensional scoring model, and calculate priority score PS of each unknown dependency.

[0105] The three-dimensional scoring model includes a dynamic weight adjustment model, which is a statistical model based on historical security events. The weight is automatically updated every month to ensure that the score fits the actual risk. The specific rules of the dynamic weight adjustment model are as follows:

[0106] If there are ≥2 data leakage events in the past 3 months, the sensitivity weight will be increased from 0.6 to 0.7, and the frequency weight will be decreased from 0.4 to 0.3.

[0107] If the Serverless function cold start failure rate ≥5%, the frequency weight will be increased by 0.1, with a maximum of 0.4. The cold start failure rate calculation benchmark is: daily statistics, calculation period is the previous 24 hours. The cold start failure judgment standard is: the time from function trigger request to successful response is more than 5 seconds or resource initialization error occurs during startup.

[0108] On the 1st of each month, the previous month's security event logs are automatically extracted, such as leakage events recorded by the security information event management system (SIEM) and cold start failures recorded by APM. The weight adjustment range is calculated by event frequency x impact range to ensure that the weight update fits the actual risk changes.

[0109] Step 1.5.1: Calculate frequency score FS: based on the interaction frequency in the unknown dependency list with scene weight, use linear normalization to map the frequency to 0-10 points;

[0110] FS=(current frequency-minimum frequency) / (maximum frequency-minimum frequency)x10, if the minimum frequency is equal to the maximum frequency, FS takes the value 5. Frequency refers to the interaction frequency of a single service, i.e. the number of calls per unit time. The minimum frequency and maximum frequency are extracted from the interaction frequency of the entire data set.

[0111] Step 1.5.2: Calculate real-time risk adjustment coefficient RAC: based on real-time risk signals of dependencies collected by eBPF probes, such as response delay anomaly, return data format error and associated business failure rate increase. Set the RAC value range to 0.4-1.8, and the specific value rules are as follows:

[0112] No abnormality: RAC = 0.8; Mild abnormality: RAC = 1.2; Severe abnormality: RAC = 1.8; Long-term no abnormality, no risk signal for 7 consecutive days: RAC = 0.4.

[0113] The quantitative basis for RAC abnormality determination is:

[0114] Response delay abnormality: Based on the average response delay of the same period in the past 7 days, if the current delay is 20% higher than the reference and lasts for 5 minutes, it is determined to be a mild abnormality; if it is 50% higher and lasts for 3 minutes, it is determined to be a severe abnormality;

[0115] Correlation service failure rate abnormality: Based on the average failure rate in the past 24 hours, if the failure rate rises from 0.1% to 5% and lasts for 2 minutes, it is determined to be a severe abnormality; if it rises to 2% and lasts for 5 minutes, it is determined to be a mild abnormality;

[0116] Data format error: If there are ≥10 times of return data format mismatch within 1 minute, such as missing JSON fields, it is determined to be a mild abnormality; ≥30 times is a severe abnormality, and all abnormality determination data come from real-time kernel logs collected by eBPF probes.

[0117] eBPF probe is a dynamic tracing tool running in Linux kernel, which can collect real-time data such as network response, data format, and service failure rate of the service, and the data source is the kernel-level tracking log.

[0118] Step 1.5.3: Calculate three-dimensional dynamic: first calculate the basic risk based on frequency + corrected sensitivity, then adjust through BSW, LAC and RAC triple coefficients, and finally get PS:

[0119] ; Where: frequency weight and sensitivity weight are weight values output by the dynamic weight adjustment model, and the sum of frequency weight and sensitivity weight is 1, the initial default value is frequency weight = 0.4, sensitivity weight = 0.6; PS value range 0-25 points, the higher the score, the higher the risk.

[0120] After processing, output the unknown service dependency priority ranking table in descending order of PS score, containing fields: unknown dependency identifier, PS score and each calculation parameter, such as FS, corrected DSS, BSW, LAC and RAC.

[0121] Step S102 is intended to make a dynamic attack path evolution prediction based on a generative adversarial deduction, and specifically includes: collecting threat intelligence data, training an attack scenario generator, constructing a red teaming sandbox containing a digital twin environment and capable of simulating a zero-day vulnerability attack scenario, generating an initial attack path in the sandbox and iteratively optimizing it through red teaming deduction, calculating the feasibility score and threat level score of each attack path, and screening to obtain a high-risk dynamic attack path list according to the scores.

[0122] Further, the step of constructing the red teaming sandbox containing the digital twin environment includes: replicating the network topology of the production environment, the network topology containing service identification, dependency relationships in the unknown business dependency priority ranking table, and existing micro-isolation strategies; deploying simulation attack components and defense components, the attack components supporting simulation zero-day exploit logic, and the defense components including eBPF execution points and micro-isolation strategy execution engines; constructing generator modules and discriminator modules for adversarial deduction, the generator modules accessing the attack scenario generator, and the discriminator modules integrating existing micro-isolation strategies and defense components.

[0123] Further, the step of screening to obtain the high-risk dynamic attack path list includes: calculating the feasibility score by the product sum of the exploit success rate, the dependency reachability and the defense evasion success rate of each step in the attack path, calculating the threat level score by the product of the feasibility score and the target service importance weight, and the data impact degree weight, and including the attack paths with the feasibility score ≥ a preset threshold and the threat level score ≥ a preset threshold in the high-risk dynamic attack path list.

[0124] Step 2.1: threat intelligence data preprocessing and generative AI model training: collect multi-source threat intelligence data, and after preprocessing, train an attack scenario generator based on the Transformer architecture, so that it has the ability to generate logically consistent unknown attack scripts.

[0125] Step 2.1.1: threat intelligence data collection:

[0126] Structured data: MITRE ATT&CK framework containing tactical and technical TTPs and attack steps, CVE vulnerability library containing vulnerability numbers, exploit conditions and impact ranges, and historical attack reports containing attack chain links and target services;

[0127] Unstructured data: forum discussions containing attacker tactics sharing, security research papers containing new attack technologies, and description documents of vulnerability exploitation tools PoCExp.

[0128] Step 2.1.2: threat intelligence data preprocessing:

[0129] Structured processing: converting unstructured data into structured fields of attack steps, target services, dependency relationships, and vulnerability types.

[0130] Labeling and alignment: aligning attack steps with MITRE ATT&CK tactic labels, such as T1078 Identity Deception T1204 User Execution, and aligning target services with dependency identification from the Unknown Business Dependency Priority List.

[0131] Step 2.1.3: Transformer attack scenario generator training: The attack scenario generator is a generative AI model that uses a Transformer model with an encoder-decoder architecture. The input is the current network topology and business dependency weights, which include service identification, dependency relationships, and existing protection strategies. The output is an attack script that includes attack targets, attack steps, exploited vulnerabilities or dependencies, and expected results.

[0132] Training process: The pre-processed threat intelligence data is used as the training set, and the cross-entropy loss function is used to optimize the model. The goal is to generate new attack scripts that conform to attack logic and have not appeared in the training set, such as combining known TTPs and hypothetical vulnerabilities to create attack paths.

[0133] After processing, the trained Transformer attack scenario generator is output, which has the ability to generate attack scripts containing unknown vulnerabilities and new TTPs.

[0134] Step 2.2: Building a red teaming sandbox: Based on the digital twin environment, a red teaming sandbox is built, including a generative adversarial network (GAN) composed of a generator and a discriminator, which is used to simulate a real red teaming environment.

[0135] Step 2.2.1: Building a digital twin environment:

[0136] Reproducing the network topology of the production environment: including service identification, dependency relationships from the Unknown Business Dependency Priority List, existing micro-segmentation strategies, and infrastructure types, including containers, Pods, virtual machines, and Serverless;

[0137] Deploying simulation attack and defense components: Attack components are simulation attackers that can execute proof-of-concept code or exploit code; defense components include eBPF (extended Berkeley Packet Filter) execution points, intrusion detection systems, and micro-segmentation policy execution engines. In the Serverless scenario, eBPF execution points are deployed in the function runtime kernel. The function runtime kernel is a lightweight kernel provided by cloud vendors for functions. In Serverless platforms that support custom runtime environments or kernel tuning, eBPF programs can be loaded into the function runtime environment through specific interfaces or plugin mechanisms provided by cloud vendors to achieve traffic interception and anomaly detection.

[0138] Step 2.2.2: Construction of a generative adversarial network (GAN):

[0139] Generator: Access the trained Transformer attack scenario generator. The function is to generate diversified attack scripts, with the goal of breaking through the defense of the discriminator.

[0140] Discriminator: Integrate existing micro-segmentation policies and defense components. The function is to evaluate the feasibility of attack scripts, i.e., whether they can break through defenses and identify weak points in defenses. The goal is to resist attacks from the generator.

[0141] Interaction logic: The generator injects attack scripts into the sandbox, and the discriminator simulates defense. The discriminator feeds back to the generator whether the attack was successful or failed, and the generator optimizes the attack script based on the feedback, forming a closed loop.

[0142] The output after processing is a runnable attack-defense sandbox, containing a digital twin environment, a generator, and a discriminator, with the ability to perform attack-defense deduction.

[0143] Step 2.3: Attack path generation and adversarial deduction: In the attack-defense sandbox, start the adversarial game between the generator and the discriminator, generate and iteratively optimize dynamic attack paths, covering zero-day vulnerabilities and attacker dynamic tactics.

[0144] Step 2.3.1: Initial attack path generation: The generator generates 10-20 initial attack paths based on the network topology and business dependency weights of the digital twin environment, such as exploiting a hypothetical Log4j variant vulnerability → compromising the log service → exploiting the dependency between the log service and the payment service → laterally moving to the payment service; Serverless scenario generation path, such as exploiting Serverless function cold start vulnerability → injecting malicious code → exploiting the dependency between the function and the payment service → stealing payment data.

[0145] Serverless function cold start vulnerability is a security risk that may exist in the isolation policy bypass or mirror verification of the Serverless environment during cold start. The data source is the latest threat intelligence.

[0146] Step 2.3.2: Discriminator defense simulation: The discriminator performs defense simulation on each attack path, checking whether each step in the path triggers existing micro-isolation policies such as port interception, mutual Transport Layer Security (mTLS) authentication, and eBPF execution point detection as abnormal.

[0147] mTLS is an encryption protocol based on traditional Transport Layer Security (TLS) that adds client identity authentication. Both parties of communication need to verify each other's digital certificate, which comes from the PKI certificate system, to ensure the legality of service identity and the encryption of communication content. In micro-isolation, it is used to prevent identity spoofing attacks, such as attackers pretending to be legitimate services to initiate calls. Its core role is to provide identity and data double security protection for cross-service communication. The data source is the certificate file deployed on the server and client.

[0148] Step 2.3.3: Feedback and path optimization: The discriminator feeds back the attack failure reasons to the generator, such as being intercepted by mTLS in step 2.3.2. The generator adjusts the attack path based on the feedback, such as replacing step 2.3.2 with identity spoofing to bypass mTLS. Serverless scenario optimization path, such as adjusting malicious code injection to low and slow code injection every hour to evade detection.

[0149] Step 2.3.4: Iterative deduction: Repeat the first three steps for 50-100 iterations until the generator generates a stable attack path that can break through the discriminator's defense and is logically consistent.

[0150] Dynamic attack path: The attack chain generated by the generator and optimized by adversarial deduction, including attack targets such as payment services, attack steps such as vulnerability exploitation and lateral movement, dependencies such as the association between log services and payment services, and methods to evade defenses, used for feasibility assessment.

[0151] Low and slow attack is a stealthy attack method that evades anomaly detection thresholds by performing long-term, low-frequency operations such as stealing 1 piece of data per day. The data source is the tactical optimization logic of the generator, used for attack path diversity generation.

[0152] After processing, output the list of dynamically optimized attack paths, including fields: attack path identification, attack target service identification, attack steps in order, utilization of dependency identification, evaded defense measures, and applicable environment container virtual machine Serverless.

[0153] Step 2.4: Attack path feasibility and threat level assessment: for each path in the dynamic attack path list, calculate the feasibility score FS path and the threat level score TLScore, filter the high-risk paths.

[0154] Step 2.4.1: Calculate the feasibility score FS path :

[0155] ;

[0156] Where: n is the number of steps included in the attack path;

[0157] S 漏洞利用 is the success rate of exploit, valued between 0 and 1, determined based on the type of vulnerability and the availability of PoC, such as known vulnerability: S 漏洞利用 = 0.8 points, assume zero-day vulnerability: S 漏洞利用 = 0.5 points, with PoC: S 漏洞利用 = 0.9 points, no PoC: S 漏洞利用 = 0.4 points;

[0158] S 依赖可达 is the dependency reachability of the current service to the target service, valued between 0 and 1, determined based on the PS score of the unknown business dependency priority table, such as PS ≥ 15 points: S 依赖可达 = 0.9 points, PS < 10 points: S 依赖可达 = 0.3 points;

[0159] S 防御规避 is the success rate of evading defense measures, valued between 0 and 1, determined based on the evasion method, such as bypassing mTLS: S 防御规避 = 0.7 points, evading intrusion detection systems: S 防御规避 = 0.6 points.

[0160] FS path ≥ 3 points is determined as high feasibility, 2-3 points is determined as medium feasibility, and < 2 points is determined as low feasibility.

[0161] Step 2.4.2: Calculate the threat level score TLScore:

[0162] TLScore = FS path × W 目标服务 × W 数据影响 ; Where:

[0163] W 目标服务 is the importance weight of the target service, based on the business scenario, payment service 1.5 points, user data service: W 目标服务 = 1.2 points, log service: W 目标服务 = 0.8 points.

[0164] W 数据影响 The impact on data should the attack path succeed, based on data sensitivity settings, to steal payment data: W 数据影响 =1.5 points, stealing non-sensitive logs: W 数据影响 =0.4 points.

[0165] Threat level assessment: A TLScore of ≥4 is considered an extremely high threat, 3-4 is considered a high threat, and <3 is considered a low to medium threat.

[0166] The processed output is a list of high-risk dynamic attack paths, filtered by: a feasibility score threshold of 3 points, a threat level score threshold of 4 points, and FS (Firmware Attack Path). path ≥3 points and TLScore≥4 points; the high-risk dynamic attack path list includes the following fields: attack path identifier, FS path TLScore, attack targets, core exploit dependencies and applicable environments.

[0167] Step 103 also includes defining key elements in high-risk dynamic attack paths as variables and constructing a causal graph based on a structural causal model; calculating the causal effect of each variable on the success of the attack using a backdoor adjustment formula; identifying variables with causal effects not lower than a preset threshold as core root causes; prioritizing core root causes according to the number of attack paths they affect; and generating a corresponding list of micro-isolation hardening strategies for core root causes.

[0168] Furthermore, the key elements are those directly related to the success of the attack, including vulnerability existence, dependency reachability, lack of defense strategy, and identity authentication defects. The list of micro-segmentation hardening strategies generated for the core root causes includes: for the core root cause of identity authentication defects, generating enhancement strategies including remote verification processes of trusted platform modules; for the core root cause of excessive dependency on permissions, generating environment isolation strategies including dedicated sidecar proxy routing and traffic auditing; and for the core root cause of vulnerability exploitation, generating virtual patch strategies including interception by extended Berkeley packet filter programs.

[0169] Step 3.1: Root Cause Analysis of Attack Paths: Based on the Structural Causal Model (SCM), analyze the core root causes, i.e., non-surface reasons, for each path in the list of high-risk dynamic attack paths.

[0170] SCM is an analysis tool based on causal logic. Compared with traditional log-based surface-level root cause localization, its core value lies in: quantifying the causal effects between variables, such as the direct impact of authentication flaws on attack success, eliminating correlation interference, such as the time correlation between high log service access volume and attack occurrence, and accurately locating the core non-surface root cause of the attack, such as authentication flaws rather than surface-level vulnerability exploitation.

[0171] Step 3.1.1: SCM model construction:

[0172] Variable definition: Define key elements in the attack path as variables, X1 as vulnerability existence, X2 as dependency reachability, X3 as defense strategy absence, X4 as identity authentication defect, and Y as attack success.

[0173] Causal diagram construction: Draw a causal diagram based on attack-defense logic, such as X1→Y representing that vulnerability existence leads to attack success, X2→Y representing that dependency reachability assists attack success, and X4→X3 representing that identity authentication defect leads to defense strategy absence.

[0174] Step 3.1.2: Root cause analysis process:

[0175] Causal effect calculation: Calculate the causal effect of each variable on Y attack success using the backdoor adjustment formula, such as calculating the difference between P(Y=1|do(X4=1)) and P(Y=1|do(X4=0)), which represents the probability difference of attack success when identity authentication defect exists and does not exist.

[0176] Root cause determination: Determine variables with causal effect ≥ preset threshold 0.6 as core root causes, common root causes include: X4: A service's identity authentication for B service relies only on account password without TPM remote proof; X2: The dependency between log service and payment service is not limited by minimum permission.

[0177] TPM remote proof is a hardware-level identity authentication technology based on trusted platform module, which can verify the integrity of remote devices, and the data source is the trusted report of TPM chip.

[0178] Root cause priority sorting: Sort by the number of attack paths affected by the root cause in descending order, for example, an identity authentication defect affects 5 attack paths, with higher priority than a dependency permission problem that only affects 1 path.

[0179] Output core root cause list after processing, including fields: root cause identifier, root cause description, affected attack path identifier, causal effect value, and root cause priority.

[0180] Step 3.2: Micro-isolation reinforcement strategy generation: For each root cause in the core root cause list, generate corresponding micro-isolation reinforcement strategies, including strategy enhancement, environment isolation, and virtual patching, to ensure coverage of different root cause scenarios and adapt to Serverless environment.

[0181] Step 3.2.1: Strategy generation rules:

[0182] For the root cause of identity authentication defects, generate policy enhanced class policy. For example, before A service calls B service, forcibly insert TPM remote attestation process, B service verifies the firmware integrity of A service through TPM chip, and only allows communication after verification; In the Serverless scenario such as Serverless function authenticated only with API key, generate policy for Serverless function call, and forcibly verify the container image signature of the calling party plus TPM remote attestation before the call.

[0183] For the root cause of excessive dependence on permissions, generate environment isolation class policy. For example, route the communication traffic between the log service and the payment service to a dedicated Sidecar agent, which only allows the log service to transmit desensitized log identifiers to the payment service, prohibits the transmission of complete log content, and enables mTLS encryption and traffic auditing; In the Serverless scenario such as the log Lambda function accessing the payment database, generate policy for limiting the log Lambda to be triggered only by the log service through the function trigger whitelist, and only allowing access to the desensitized log table.

[0184] Function trigger whitelist is an access control function provided by cloud vendors, which only allows services in the whitelist to trigger functions to avoid unauthorized calls. Function trigger whitelist needs to be configured through the native API of the cloud vendor, such as AWS Lambda through the Resource-BasedPolicy interface, adding a Condition field in the policy document to specify the allowed trigger source service Principal. After configuration, the micro-isolation policy execution engine synchronizes the whitelist data every 30 seconds; When the Serverless function receives a call request, the engine intercepts the request in real time, checks whether the trigger source is in the whitelist, and blocks it directly if it is not in the list, and synchronizes the blocking log to the SIEM system for auditing.

[0185] For the root cause of vulnerability exploitation, generate virtual patching class policy. For example, write eBPF program, deploy in the kernel state of the target service, intercept and detect specific API call sequences that exploit the zero-day vulnerability, and block and alert immediately after discovery; In the Serverless scenario such as the existence of Serverless cold start vulnerability, generate policy for writing eBPF program and deploying it in the kernel of function runtime, intercepting abnormal image pull requests during cold start.

[0186] Step 3.2.2: Policy parameter configuration: Configure policy strictness based on PS score of unknown business dependency priority ranking table, for example, high-risk dependencies with PS≥15 points, policy enables two-factor authentication plus real-time auditing, and dependencies with PS<10 points enable basic mTLS; In the Serverless scenario, high-risk dependencies with PS≥15 points also enable two-factor authentication plus real-time auditing.

[0187] The micro-isolation reinforcement strategy list is output after processing, including fields: strategy identifier, corresponding root cause identifier, strategy type, strategy content, applicable dependency identifier, strategy strictness, applicable environment container virtual machine Serverless, and Serverless strategy type. The applicable dependency identifier comes from the unknown business dependency priority ranking table.

[0188] Step 104: Verify the effectiveness of the micro-isolation reinforcement strategy list in the digital twin environment of the attack-defense confrontation sandbox, adjust the strategy, and output the verified micro-isolation reinforcement strategy list.

[0189] Further, the verification of the effectiveness of the micro-isolation reinforcement strategy list includes: calculating the ratio of the number of blocked attack paths to the total number of high-risk attack paths as the strategy blocking rate, and determining that the blocking rate ≥ the preset blocking threshold as the standard for reaching the target.

[0190] Step 4.1: Strategy deployment: deploy the reinforcement strategy to the micro-isolation execution engine of the digital twin environment, such as Calico and Istio; Serverless scenario simulates strategy deployment through cloud vendor API.

[0191] Step 4.2: Attack-defense retest: re-run the confrontation deduction of step S102, the generator initiates attacks based on the original high-risk attack paths, and the discriminator verifies whether the strategy blocks the attacks; in the Serverless scenario, the generator initiates attacks based on the original Serverless attack paths, and the discriminator verifies whether the strategy blocks.

[0192] Step 4.3: Effectiveness evaluation: calculate the strategy blocking rate, i.e. the number of blocked attack paths divided by the total number of high-risk attack paths, and the preset blocking threshold is 95%. If the blocking rate ≥ 95%, it is determined to be effective, and if it is < 95%, it enters optimization; the Serverless scenario separately calculates the blocking rate of the Serverless path, and also takes ≥ 95% as the effective standard.

[0193] Step 4.4: Strategy optimization: for the unblocked attack paths, analyze the reasons and adjust the strategy. For example, the reason why a certain Serverless attack path is not blocked is that the eBPF program does not cover the function-specific call sequence, and the adjustment strategy is to update the eBPF program rules to cover this call sequence.

[0194] The verified micro-isolation reinforcement strategy list is output after processing, with the filtering condition being a blocking rate ≥ 95%, and the Serverless scenario also needs to satisfy a Serverless path blocking rate ≥ 95%, including fields: strategy identifier, final strategy content, blocking rate, Serverless path blocking rate, and applicable environment container virtual machine Serverless.

[0195] Step 105: Deploy the verified micro-isolation reinforcement strategy to the cloud-native network production environment, and ensure the strategy continues to be effective through real-time monitoring, forming a protective closed loop.

[0196] Further, the real-time monitoring includes: deploying eBPF traffic monitoring probes to collect policy execution logs, and accessing application performance monitoring and security information event management systems; for serverless function environments, additionally monitoring function cold start success rate, function call compliance rate, and eBPF patch blocking rate.

[0197] Step 5.1: Production deployment:

[0198] Container virtual machine environment: Through the API interface of the micro-isolation execution engine, deploy the strategy in batches to the corresponding services such as container Pod virtual machines in the production environment.

[0199] Serverless environment: Bind the strategy to the function through the cloud vendor API, such as updating the trigger whitelist and injecting eBPF programs.

[0200] Step 5.2: Real-time monitoring:

[0201] Deploy eBPF traffic monitoring probes: Collect policy execution logs, including the number of blocked attack traffic, source IP, and associated attack paths; in Serverless scenarios, additionally collect the number of blocked function calls and the source IP of the trigger.

[0202] Access APM and security information event management systems: Monitor the business failure rate after strategy deployment to ensure that the strategy does not affect normal business and attack event occurrence rate; in Serverless scenarios, additionally monitor the function cold start success rate and function call compliance rate, which is the number of calls that meet the policy divided by the total number of calls, with a target value of ≥99.9%.

[0203] Add Serverless-specific monitoring indicators: In addition to the function cold start success rate and function call compliance rate, add the eBPF patch blocking rate, which is the number of blocked abnormal requests divided by the number of requests that trigger detection rules, including zero-day vulnerability API call sequences and requests with risk features such as abnormal image pulling, to ensure that the indicators can truly reflect the blocking effect of eBPF patches on risk requests, rather than being disturbed by normal requests.

[0204] Function call compliance rate is an indicator to quantify the control effect of the strategy on Serverless function calls, with a value of 0-100%, calculated based on the number of calls that meet the policy divided by the total number of calls, with a target value of ≥99.9%. If the value is less than the threshold, trigger strategy optimization.

[0205] Policy iteration: Repeat steps 1-3 to update dependency priority, attack path, and reinforcement strategy based on new threat intelligence such as newly added CVE vulnerabilities and monitoring logs such as new attack attempts every week; Serverless scenario synchronously updates dependency priority, attack path, and reinforcement strategy.

[0206] After the above processing, the production environment protection effect is realized and the closed-loop output is formed.

[0207] Production environment protection effect: high-risk attack path blocking rate ≥ 95%, business normal operation rate ≥ 99.9%; Serverless scenario additionally meets function cold start success rate ≥ 99.5%, function call compliance rate ≥ 99.9%, and eBPF patch blocking rate ≥ 95%.

[0208] Closed-loop output: form a continuous protection closed loop of dependency update, path prediction, strategy optimization, and monitoring iteration, output a protection effect report every week, report new Serverless protection index chapter, including function cold start success rate, function call compliance rate and eBPF patch blocking rate, and also include dependency priority change, new attack path and strategy adjustment record, to drive continuous iteration of the process.

[0209] Embodiment two

[0210] Based on the same inventive concept as the network micro-isolation protection method based on the zero-trust architecture provided in the embodiments of the present application, the embodiments of the present application also provide a network micro-isolation protection system based on the zero-trust architecture. For the content in the system embodiment, if there is any unclear place, please refer to the corresponding content in the method embodiment.

[0211] As shown in Figure 2 , the network micro-isolation protection system based on the zero-trust architecture comprises:

[0212] The business dependency intelligent perception module 210 is configured to collect multi-source data of a cloud native environment and pre-process the multi-source data to obtain a standardized business interaction data set; based on dynamic taint analysis, unknown business dependencies in the data set that are not recorded are identified, and priority scores of the unknown business dependencies are calculated in combination with life cycle attributes, business scenario risk weights, and real-time risk signals to generate an unknown business dependency priority ranking table.

[0213] The attack path simulation and deduction module 220 is configured to construct an attack and defense confrontation sandbox based on the unknown business dependency priority ranking table and pre-collected threat intelligence data; wherein the attack and defense confrontation sandbox comprises an attack scenario generator based on a generative adversarial network, and a digital twin environment for deploying a production environment network topology and an existing micro-isolation strategy.

[0214] In the sandbox, the attack path is generated and iteratively optimized by the attack scenario generator, the feasibility score and threat level score of each attack path are calculated, and the attack paths with scores not lower than the corresponding preset threshold are screened out to form a high-risk dynamic attack path list;

[0215] The strategy generation module 230 is configured to extract key elements from the list as variables, calculate the average causal effect of each variable on attack success, and determine variables with an average causal effect not lower than a preset causal threshold as core root causes; and generate a micro-isolation reinforcement strategy for the core root causes;

[0216] The verification module 240 is configured to deploy the micro-isolation reinforcement strategy in the digital twin environment and re-perform attack-defense confrontation deduction, verify the strategy effectiveness by calculating the proportion of blocked attack paths, and adjust the strategy until the verification is passed if the effectiveness is not up to standard;

[0217] The closed-loop monitoring module 250 is configured to deploy the verified micro-isolation reinforcement strategy to the cloud-native environment, monitor the strategy execution state in real time, and periodically update the monitoring data and new threat intelligence data as new inputs for iterative updating.

[0218] Further, the business dependency intelligent perception module 210 includes a dynamic taint analysis unit and a three-dimensional dynamic priority scoring model, and the data collection objects thereof include an application performance monitoring system, a service mesh control plane, and an infrastructure monitoring tool; the dynamic taint analysis unit marks a load containing sensitive data as an initial taint and traces its propagation path to identify unknown dependencies; and the three-dimensional dynamic priority scoring model integrates interaction frequency, corrected data sensitivity score, life cycle decay coefficient, business scenario risk weight, and real-time risk adjustment coefficient for calculation.

[0219] The attack path simulation deduction module 220 includes an attack scenario generator and an attack-defense confrontation sandbox; the attack scenario generator is based on a Transformer architecture and trained using multi-source threat intelligence data; the digital twin environment of the attack-defense confrontation sandbox replicates the network topology, dependency relationship, and existing protection strategy of the production environment, and is integrated with a simulated attack component, an eBPF execution point, and a micro-isolation reinforcement strategy execution engine; and the screening logic selects attack paths with feasibility scores and threat level scores not lower than preset thresholds.

[0220] The strategy generation module 230 includes a root cause analysis unit and a strategy generation unit; the root cause analysis unit determines core root causes by calculating the causal effect of variables on attack success through a structural causal model; and the strategy generation unit generates micro-isolation reinforcement strategies including trusted platform module remote attestation, special sidecar proxy routing, and eBPF program interception for the three types of core root causes of identity authentication defects, excessive dependency permissions, and vulnerability exploitation;

[0221] The verification module 240 comprises a verification unit; the verification unit evaluates the strategy effectiveness by re-running the attack-defense deduction and calculating the strategy blocking rate;

[0222] The closed-loop monitoring module 250 comprises a deployment unit and a monitoring unit; the deployment unit distributes the strategy to the container, virtual machine and serverless environment through the application programming interface of the micro-isolation reinforcement strategy execution engine;

[0223] The monitoring unit collects the strategy execution log, business failure rate and attack event occurrence rate data by deploying the eBPF traffic probe and connecting the application performance monitoring and security information event management system, and drives the whole system to iteratively update based on the monitoring data and new threat intelligence.

[0224] Embodiment three

[0225] Based on the same inventive concept as the network micro-isolation protection method based on the zero-trust architecture provided in the embodiments of the present application, the electronic device provided in the embodiments of the present application is provided. For the content in the device embodiment, if there is any unclear place, the corresponding content in the method embodiment can be referred to.

[0226] As shown in Figure 3 An electronic device, comprising:

[0227] at least one processor 02; and

[0228] a memory 01 in communication with the at least one processor; wherein

[0229] The memory 01 stores instructions executable by the processor 02, and the instructions are used to be executed by the processor 02 to implement the network micro-isolation protection method based on the zero-trust architecture described above.

[0230] The electronic device comprises a memory 01, a processor 02 and a network interface 03 which are connected to each other through a system bus 04. It should be pointed out that only the electronic device with components 01-04 is shown in the figure, but it should be understood that it is not required to implement all the shown components, and more or less components can be alternatively implemented. Among them, those skilled in the art can understand that the computer device here is a device capable of automatically performing numerical calculation and information processing according to pre-set or stored instructions, and its hardware includes but is not limited to microprocessor, application specific integrated circuit, digital processor and embedded device, etc.

[0231] The electronic device can be a computer, a notebook computer and a cloud server, etc. The electronic device can interact with the user through a keyboard, a mouse and a touchpad, etc.

[0232] The memory 01 includes at least one type of readable storage medium, such as a hard disk, a multimedia card, a card-type memory, a random access memory, a magnetic memory, a magnetic disk, etc. The memory 01 can be an internal storage unit of the electronic device or an external storage device of the electronic device.

[0233] The processor 02 can be a central processing unit, a controller, a microcontroller, or other data processing chip. The processor 02 is generally used to control the overall operation of the electronic device.

[0234] The network interface 03 can include a wireless network interface or a wired network interface, and is generally used to establish a communication connection between the electronic device and other electronic devices.

[0235] It is apparent that the above-described embodiments are only some of the embodiments of the present application, and are not all-inclusive of the present application. The preferred embodiments of the present application are shown in the drawings, but the scope of the patent of the present application is not limited by the above-described embodiments. The present application can be implemented in many different forms, and conversely, the purpose of providing these embodiments is to make the disclosure of the present application more thorough and comprehensive. Although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art can modify the technical solutions described in the foregoing embodiments or equivalently replace some of the technical features. Any equivalent structure made by using the contents of the specification and drawings, directly or indirectly, in other related technical fields, is also within the scope of the patent protection of the present application.

Claims

1. A network micro-segmentation protection method based on a zero trust architecture, characterized in that, The method comprises: Collecting multi-source data of cloud native environment and preprocessing to obtain standardized business interaction dataset; based on dynamic taint analysis, identifying unknown business dependencies in the dataset that are not recorded, combining life cycle attributes, business scenario risk weights and real-time risk signals to score the unknown business dependencies in priority, and generating an unknown business dependency priority ranking table; Based on the unknown business dependency priority ranking table and the pre-collected threat intelligence data, a red teaming sandbox is constructed; wherein the red teaming sandbox includes an attack scenario generator based on a generative adversarial network, and a digital twin environment for deploying the production environment network topology and existing micro-segregation strategies; In the sandbox, the attack scenario generator is used to generate and iteratively optimize attack paths, calculate the feasibility score and threat level score of each attack path, and filter out attack paths with scores not lower than the corresponding preset threshold to form a high-risk dynamic attack path list; Extract key elements from the list as variables, calculate the average causal effect of each variable on attack success, and determine variables with an average causal effect not lower than a preset causal threshold as core root causes; micro-segregation reinforcement strategies are generated for the core root causes; Deploy the micro-segregation reinforcement strategies in the digital twin environment and re-perform red teaming deduction, and verify the effectiveness of the strategies by calculating the proportion of blocked attack paths; if the effectiveness is not up to standard, adjust the strategies until they pass the verification; Deploy the verified micro-segregation reinforcement strategies to the cloud native environment, monitor the execution status of the strategies in real time, and use the monitoring data and new threat intelligence data as new inputs for periodic iterative updates; The dynamic taint analysis includes: Marking business payloads containing sensitive information in the standardized business interaction dataset as initial taints; Tracking the propagation path of the initial taints during inter-service interaction, and marking all service nodes involved in the propagation; Compare the marked service nodes with the known business dependency list, and identify the inter-service dependency relationships in the propagation path that are not recorded in the known business dependency list as unknown business dependencies; The construction of the red teaming sandbox includes: Reproduce the production network topology of the cloud native environment to the digital twin environment, including service identification, dependency relationships in the unknown business dependency priority ranking table, and existing micro-segregation strategies; In the digital twin environment, the attack component supporting the simulation of zero-day exploit logic is used as the attack scenario generator, and the defense component integrating the existing micro-segregation strategies and containing the eBPF execution point and the strategy execution engine is used as the discriminator, to complete the construction of the red teaming sandbox; The computing of the feasibility score and the threat level score of each attack path, and screening out the attack paths with scores not lower than the corresponding preset threshold, to form a high-risk dynamic attack path list, includes: weighting and calculating the feasibility score based on the exploit success rate, dependency reachability and defense evasion success rate of each step in the attack path, and weighting and calculating the threat level score by weighting the feasibility score, target service importance weight and data impact degree weight; Collecting attack paths with feasibility scores not lower than a first preset threshold and threat level scores not lower than a second preset threshold to form a high-risk dynamic attack path list.

2. The method of claim 1, wherein, The key elements extracted from the list include: vulnerabilities, dependency reachability, defense strategy absence and identity authentication defects.

3. The method of claim 1, wherein, The micro-isolation reinforcement strategy generated for the core root cause includes: if the core root cause is attributed to identity authentication defects, generating an authentication enhancement type strategy; If the core root cause is attributed to excessive dependency permissions, an environment isolation type strategy containing deploying a special sidecar agent for the service to achieve routing isolation and traffic auditing is generated; If the core root cause is attributed to exploit, a virtual patch type strategy is generated by deploying an eBPF program to intercept malicious traffic.

4. The method of claim 1, wherein, The strategy effectiveness verification by calculating the proportion of blocked attack paths includes: counting the number of attack paths blocked by the micro-isolation reinforcement strategy, calculating the ratio of the number to the total number of paths in the high-risk dynamic attack path list, and obtaining the strategy blocking rate; If the strategy blocking rate is not lower than a first preset blocking threshold, the strategy verification is passed; When the cloud-native environment contains serverless functions, the verification step further includes: Separately calculating the blocking rate of attack paths against serverless functions, and when the blocking rate is not lower than a second preset blocking threshold, the strategy verification is passed.

5. The method of claim 1, wherein, The real-time monitoring of the strategy execution state includes: deploying eBPF traffic monitoring probes to collect strategy execution logs, and for serverless scenarios, additionally monitoring function cold start success rate, function call compliance rate and eBPF patch blocking rate.

6. A network micro-segmentation protection system based on a zero trust architecture, implemented according to the method of any one of claims 1-5, characterized in that, It includes: A business dependency intelligent perception module for collecting multi-source data of a cloud-native environment and preprocessing to obtain a standardized business interaction dataset; Based on dynamic taint analysis, unknown business dependencies not recorded in the dataset are identified, and priority scores are assigned to unknown business dependencies in combination with life cycle attributes, business scenario risk weights and real-time risk signals to generate an unknown business dependency priority ranking table; The dynamic taint analysis-based identification of unknown business dependencies not recorded in the dataset includes: Marking business payloads containing sensitive information in the standardized business interaction dataset as initial taints; Tracking the propagation path of the initial taints during service interaction, and marking all service nodes involved in the propagation; Comparing the marked service nodes with a known business dependency list, and taking the inter-service dependency relationships existing in the propagation path but not recorded in the known business dependency list as unknown business dependencies; The attack path simulation deduction module is configured to construct a red teaming sandbox based on the unknown business dependency priority ranking table and pre-collected threat intelligence data. The red teaming sandbox includes an attack scenario generator implemented based on a generative adversarial network and a digital twin environment for deploying a production environment network topology and an existing micro-segregation strategy. In the sandbox, the attack scenario generator is used to generate and iteratively optimize attack paths, calculate the feasibility scores and threat level scores of each attack path, and filter out attack paths with scores not lower than corresponding preset thresholds to form a high-risk dynamic attack path list. The construction of the red teaming sandbox includes: The production network topology of the cloud-native environment is copied to the digital twin environment. The production network topology includes service identifiers, dependency relationships in the unknown business dependency priority ranking table, and existing micro-segregation strategies. In the digital twin environment, an attack component supporting the simulation of zero-day exploit logic is used as the attack scenario generator, and a defense component integrating the existing micro-segregation strategy and including eBPF execution points and a policy execution engine is used as a discriminator to complete the construction of the red teaming sandbox. The strategy generation module is configured to extract key elements as variables from a list, calculate the average causal effect of each variable on attack success, and determine variables with average causal effects not lower than a preset causal threshold as core root causes. Micro-segregation reinforcement strategies are generated for the core root causes. The calculation of the feasibility scores and threat level scores of each attack path and the filtering of attack paths with scores not lower than corresponding preset thresholds to form a high-risk dynamic attack path list includes: calculating the feasibility scores based on the exploit success rate, dependency reachability, and defense evasion success rate of each step in the attack path, and calculating the threat level scores by weighting the feasibility scores, target service importance weights, and data impact degree weights. Attack paths with feasibility scores not lower than a first preset threshold and threat level scores not lower than a second preset threshold are collected to form a high-risk dynamic attack path list. The verification module is configured to deploy the micro-segregation reinforcement strategy in the digital twin environment and perform red teaming deduction again to verify the effectiveness of the strategy by calculating the proportion of blocked attack paths. If the effectiveness is not up to standard, the strategy is adjusted until the verification is passed. The closed-loop monitoring module is configured to deploy the micro-segregation reinforcement strategy that passes the verification to the cloud-native environment, monitor the execution status of the strategy in real time, and periodically update the monitoring data and new threat intelligence data as new inputs.

7. An electronic device, comprising: The computer program stored in the memory is executed by the processor to perform the steps of the network micro-segregation protection method based on the zero-trust architecture according to any one of claims 1 to 5.

Images