Monitoring vulnerability positioning and deep defense system based on attack and defense simulation

Abstract

The invention discloses a monitoring vulnerability positioning and deep defense system based on attack and defense simulation, which relates to the technical field of network security defense, and comprises the following steps: constructing an asset atlas, unifying vulnerability entries, configuration items and permission items as exposed objects, and constructing a security graph; generating a candidate exposure set under the triggering of vulnerability update, exposure surface change or alarm abnormity, and performing reachability and precondition preliminary screening; a verification microprobe is generated for the candidate exposed object, evidence collection is executed after the range and the speed are limited through a safety gate, and a minimum telemetering fingerprint is extracted through convergence telemetering; the difference before and after execution is assembled into a difference evidence packet, alarm-step alignment is completed, and candidate root cause objects and retest signatures are positioned; and solving a minimum repair set and generating deep defense under the constraint of budget and change windows, implementing effective verification and microprobe rerun regression, and refilling a template library, so that irrelevant exposure treatment can be reduced, and the consistency of root cause positioning and acceptance inspection is improved.

Description

Vulnerability Monitoring, Localization, and In-Depth Defense System Based on Attack and Defense Simulation Technical Field

[0001] This invention relates to the field of network security defense technology, specifically to a monitoring vulnerability location and defense-in-depth system based on attack and defense simulation. Background Technology

[0002] With the increasing prevalence of cloud adoption, microservices, and remote access for government and enterprise information systems, business systems are constantly operating in environments with multiple network domains, multiple identity systems, and multiple security control points. Asset size and access paths change rapidly with deployments, elastic scaling, and outsourced maintenance. Currently, technologies such as vulnerability scanning, configuration verification, compliance baselines, log auditing, and alerting platforms are widely used to generate risk lists, trigger work order assignments, and close the handling loop. Some organizations are incorporating attack and defense drills or automated adversarial simulations to verify the effectiveness of security controls. However, in daily operation and maintenance scenarios, operations such as application version changes, boundary policy adjustments, changes to cloud security groups and access control lists, and the granting and revocation of identity permissions often cause the mapping relationship between the exposure surface, control point, and alarm evidence to shift continuously: scanning and verification will generate a large number of vulnerability, configuration item, and permission item candidates, a considerable number of which do not have actual reachable or exploitable conditions under certain segmentation, proxy links, authentication methods, or intermediate protection strategies; monitoring-side alarms mostly appear as rule hits or abnormal behavior characteristics, and are difficult to reliably trace to specific exposed objects, triggering conditions, and effective mechanisms due to the influence of encrypted traffic, differences in collection point coverage, different rule calibers, and time delays.

[0003] Container orchestration, serverless computing, and third-party SaaS integration, coupled with short instance lifecycles and fragmented log chains, increase the difficulty of maintaining consistent evidence. Therefore, in the normal discovery-assignment-remediation-review process, the handling team needs manual reproduction, cross-system comparison, and experience-based inference to pinpoint the root cause. Remediation actions may also be repeatedly rolled back due to preconditions, lack of policy implementation, incomplete change coverage of all instances, or the existence of bypass paths. Furthermore, with limited change windows and cross-departmental collaboration, these factors lead to the continued retention of high-risk exposures, delaying remediation time, auditing, and business integrity. In the event of actual counter-intrusion activities, this increases the reach of the intrusion chain, lateral movement opportunities, and handling costs.

[0004] Therefore, the current technical challenge is: in the aforementioned production environment with multiple assets, multiple control points, and dynamic updates, how can we ensure that risk candidates and monitoring alarm evidence are auditably and reproducibly matched without introducing destructive verification behavior? This will enable us to accurately locate and verify the root causes of actually exploitable exposed objects, and avoid problems such as distorted priorities, rework, and risk backlog caused by unclear accessibility and effective conditions and difficulty in aligning alarm evidence. Summary of the Invention

[0005] (I) Technical Problems Solved To address the shortcomings of existing technologies, this invention provides a monitoring vulnerability location and defense-in-depth system based on attack and defense simulation. It generates verifiable micro-probes for candidate exposed objects, performs evidence collection after limiting the range and rate through a security gate, and aggregates telemetry data to extract the minimum telemetry fingerprint. It assembles the pre- and post-execution differentials into a differential evidence package, completes alarm-step alignment, and locates candidate root cause objects and retest signatures. Under budget and change window constraints, it solves for the minimum repair set and generates defense-in-depth, implements effectiveness verification and micro-probe rerun regression, and re-feeds the template library. This reduces irrelevant exposure handling and improves root cause location and acceptance consistency, thus solving the technical problems described in the background section.

[0006] (II) Technical Solution To achieve the above objectives, the present invention is implemented through the following technical solution: A monitoring vulnerability location and deep defense system based on attack and defense simulation, comprising: establishing an asset map, abstracting vulnerabilities, configuration items, and permission items as exposed objects, generating a candidate exposure set based on vulnerability updates, exposure surface changes, or alarm anomaly triggers, and performing initial screening for reachability and preconditions; generating verification micro probes for the candidate exposure set, the verification micro probes are used to verify the minimum steps of reachability, preconditions, and exploitation conditions and prohibit destructive payloads, executing within the range and rate constrained by a security gate and collecting telemetry to obtain a minimum telemetry fingerprint; generating a differential evidence package by combining the results before and after execution with the minimum telemetry fingerprint and performing alarm-step alignment to obtain an alignment score, and determining the candidate root cause object set and retest signature in conjunction with the asset map; determining a minimum repair set from the candidate root cause object set under budget and change window constraints, generating a temporary deep defense action set for the rest, performing repair effectiveness verification and retest signature corresponding micro probe rerun verification, and feeding back into the candidate exposure set generation and micro probe template library.

[0007] Furthermore, the asset graph is composed of asset nodes, service nodes, port nodes, dependency edges, identity and permission edges, and security policy edges. It also establishes a binding identifier between the exposed object and the service node. The binding identifier includes the asset identifier, service identifier, port number, and version identifier, so that the candidate exposure set can be grouped according to the binding identifier.

[0008] Furthermore, the system acquires probability scores, directory hit information, port open records, service launch records, security policy change records, and alarm / anomaly records. It then forms a candidate exposure set according to preset fusion rules, which include time-related constraints, same-origin constraints, and dependency constraints. The system also records the trigger source corresponding to each exposed object.

[0009] Furthermore, the accessibility and preliminary screening of preconditions includes performing network connectivity detection, port accessibility detection, and authentication entry availability verification on the exposed object, and structuring the detection results into a precondition vector and writing it into the candidate exposure set, while also writing the collection timestamp and evidence source identifier into the precondition vector.

[0010] Furthermore, the verification micro-probe generates an action chain based on the precondition vector. The action chain sequentially includes connectivity verification, authentication interaction, policy hit verification, and result collection steps. During the generation stage, the action chain is limited to only read-only requests and authentication requests, and the execution entry point and request parameter template are recorded for the action chain.

[0011] Furthermore, before executing the verification micro probe, the security gate writes the target range whitelist, concurrency limit, rate limit, execution window, resource budget limit, emergency stop condition, and rollback condition. During execution, it deducts and measures the resource budget, and triggers the emergency stop condition when the resource budget limit is reached.

[0012] Furthermore, the telemetry data collection includes network-side session metadata, terminal-side process chains, authentication events, and policy hit records. Fields are extracted according to the action sequence of the action chain to generate a minimum telemetry fingerprint. The minimum telemetry fingerprint includes session identifier, process identifier, account identifier, policy identifier, and action sequence number, and is stored in association with the action timestamp.

[0013] Furthermore, the differential evidence package includes a precondition vector, execution result, minimum telemetry fingerprint, alignment score, candidate root cause object set and retest signature, and completes alarm-step alignment with time window constraints, subject-object consistency constraints and fingerprint similarity constraints, forming a mapping relationship between alarm identifier and step identifier and outputting alignment label.

[0014] Furthermore, the candidate root cause object set is jointly determined by the differential fields of the differential evidence package and the dependency relationship of the asset graph. The candidate root cause object set is limited to configuration key, component version, policy ID and permission boundary, and a set of disposal actions corresponding to the retest signature is generated for the candidate root cause object set.

[0015] Furthermore, the minimum repair set is generated by the solver from the set of disposal actions under budget and change window constraints, and a temporary deep defense action set is generated for candidate root cause objects that do not enter the minimum repair set; the dual-channel regression verification includes repair effectiveness verification and retest signature corresponding verification microprobe rerun verification, and the verification results are fed back into the microprobe template library.

[0016] (III) Beneficial Effects This invention provides a monitoring vulnerability location and deep defense system based on attack and defense simulation, which has the following beneficial effects: By establishing an asset map, vulnerability entries, configuration items, and permission items are set as exposed objects. A candidate exposure set is generated by event triggering and the reachability and preconditions are initially screened. The objects to be dealt with are aligned with the exposed links established in the current network, and alarm noise is removed.

[0017] By generating confirmatory micro-probes for the candidate exposure set and defining the target range, rate concurrency, and execution window with a security gate, evidence collection actions can be executed under controlled conditions on the live network. This aggregates network-side, endpoint-side, identity, and policy telemetry data and extracts the minimum telemetry fingerprint to solidify evidence. By setting the pre- and post-execution differences as differential evidence packages and aligning alarms and steps, the alarm chain and action chain become a mapping. Finally, the candidate root cause object set and retest signature are output, and the localization results converge to specific configuration keys, component versions, policy IDs, or permission boundaries. By solving for the minimum remediation set under budget and change window constraints and configuring costs, execution windows, and rollback strategies for remediation actions, the remediation plan can be implemented in batches with clear rollback details.

[0018] By generating temporary deep defense action sets for short-term, unrepairable exposures and reusing verification micro-probes, the defense configuration corresponds to path blocking and forms an acceptable closed-loop handling mechanism. Dual-channel regression verification combines the verification of repair effectiveness with the retest signature-corresponding micro-probe rerun, feeding this data back into the candidate exposure set generation and micro-probe template library, achieving consistency across the risk triggering, evidence collection, location, and acceptance chain, as well as governance. Attached Figure Description

[0019] Figure 1 is a schematic diagram of the monitoring vulnerability location and deep defense system based on attack and defense simulation of the present invention; Figure 2 is a schematic diagram of the network / asset topology and asset map of the present invention; Figure 3 is a schematic diagram of the key data object / data structure of the present invention; Figure 4 is a diagram of the micro probe action chain pruning and dependency relationship of the present invention; Figure 5 is a timing diagram of the security gate and scheduling / emergency stop of the present invention; Figure 6 is a schematic diagram of DEB assembly and alarm alignment of the present invention. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] Please refer to Figures 1-6. This invention provides a monitoring vulnerability location and defense-in-depth system based on attack and defense simulation, including: Step 1, using asset mapping... Based on this, vulnerability entries, configuration items, and permission items are used as the exposure targets. And generate a candidate exposure set under event trigger conditions. and its precondition vector This provides an executable verification entry point and traceable judgment criteria for step two.

[0022] In production networks, the same risk phenomenon often spans software versions, network paths, identity permissions, and security policies. Using only a vulnerability number or a single alert rule as the object of handling can easily lead to cross-system contextualization. Taking this as an example, assets, relationships, and control constraints are represented as a single expression, eliminating the need for manually constructing semantics.

[0023] By fixing the multi-source information that the handling team relies on daily into computable structural objects, subsequent steps can be avoided by relying solely on static lists, which can lead to an overly broad range of candidates and difficulty in tracing back evidence.

[0024] Using the asset inventory as the entry point, each asset is first recorded with its stability identifier, network domain, exposed port, service and version information. Then, the asset, its upstream entry point, downstream dependencies, access control rules, authentication methods, and permission granting links are written into the same relationship set, thereby forming an asset graph. In formation During the process, the system does not treat security policies as annotation fields, but expresses the policies as constraints between assets, ports, and identity subjects, so that reachable and available permissions have traceable paths at the graph level.

[0025] Each piece of input information is marked with its source and time: assets come from configuration management records and cloud resource lists, ports and services come from runtime port inventories and application release lists, identities and permissions come from account directories and authorization approval records, and security policies come from firewalls, access control lists, and application-side access control configurations.

[0026] The system then abstracts vulnerability entries, configuration items, and permission items into a unified exposure object. Exposed object In addition to the risk itself, it also has an effective carrier pointing to (corresponding asset node, corresponding service node, and corresponding permission edge), and the effective condition profile field inherits the preceding precondition vector. .

[0027] Precondition vector An ordered set consisting of four assertions : Exposure surface assertion Port open status, service listening status, interface path reachability status; evidence sources include port inventory, service registry, and reverse proxy routing table; path assertion. : Does the path from the ingress network domain to the target asset satisfy the policy link? Does it cross segment boundaries? Does it require proxy redirection? Evidence sources include routing tables, segmentation policies, access control lists, and security group rules; authentication assertions. : Authentication method identifier, session establishment conditions, credential source type, evidence source application authentication configuration, identity directory policy, authentication fields in access logs; control point assertions Key factors include whether the policy is enabled, the policy issuance status, and the observability of policy hits. Evidence sources include policy control plane issuance records and hit records.

[0028] The system for each exposed object Generate a unique traceability identifier and link it to the asset map. Binding to the corresponding node or edge ensures that any subsequent step can be performed from... Let's return to its dependencies and control constraints.

[0029] When using it, through the asset map By placing risk items within the same semantic space as specific assets and control constraints, the exposed objects are made... It has stable pointers and traceable context; thus providing a structured foundation for subsequent triggering and filtering, and avoiding the loss of effective carriers and condition clues when candidate objects are passed across systems.

[0030] In frequently changing network environments, the challenge in risk management lies not in a lack of a list, but in the dispersed and inconsistent scale of trigger sources: vulnerability entries emphasize version exposure, change logs emphasize configuration differences, and alert logs emphasize behavioral indicators. Simply listing these three together can easily lead to too many triggers or the omission of critical ones. The solution is to unify the trigger sources to an interpretable trigger strength. And maintain its traceable composition so that subsequent screening and interpretation do not rely on empirical judgment.

[0031] The reasons requiring verification are solidified into verifiable, quantifiable combinations, making the generation mechanism of the candidate set interpretable and recalculated. Specifically, the system categorizes trigger sources into three types of inputs: vulnerability triggers, change triggers, and alarm triggers, and generates vulnerability risk quantities for each. Impact of the change Alarm aggregation Vulnerability risk level Driven by both the Exploit Probability Score (EPSS) and the Known Exploited Vulnerabilities Directory (KEV), the system uses EPSS to describe the likelihood of a vulnerability being exploited in the future, and KEV to describe existing exploit records of the vulnerability in the public directory. When reading the EPSS and KEV, the system does not directly replace internal assessments, but rather writes them as part of the triggering evidence. The source field.

[0032] Impact of the change Formed from change orders or configuration differences, the system breaks down the impact of changes into three categories: changes in exposure surfaces, changes in control constraints, and changes in identity and permissions, and applies these categories to the asset map. The change is located at the corresponding node or edge, thus controlling the impact of the change. With asset mapping Structure binding. Alarm aggregation volume. The data is generated by the monitoring platform and is not based on the number of alarms themselves. Instead, it uses the status flags of duplicate alarms on the same asset or the same access path, as well as alarms lacking an explainable root cause, as aggregation conditions to increase the alarm aggregation volume. It is closer to the scenarios that require verification.

[0033] Using saturation mapping function Inputs with different dimensions are unified into a finite interval, and a trigger strength is formed. : Where: Trigger strength : Used to represent the overall strength of verification triggered by a specific exposed object or asset path, with a value range of . ; Saturation mapping function : Used to interpret linear combinations as monotonically continuous functions with output over a finite interval, where the range of values ​​is . Its purpose is to prevent extreme values ​​from a single trigger source from dominating the overall triggering; its specific form is a logical mapping function. ,in The value is a real number; the vulnerability risk level. Used to carry trigger evidence for EPSS and KEV and to expose objects. Binding, value range is Impact of the change Used to carry the differences in three categories: exposure surface, control constraints, and identity permissions, and to integrate with the asset graph. Binding, value range is Its function is to reflect the degree to which the changes cause the effective conditions to drift; alarm aggregation volume Used to carry duplicate alarms and root cause missing markers along the same path and bind them to asset nodes or paths; the value range is [value range missing]. Vulnerability weight Used to adjust the level of vulnerability risk. In trigger strength The contribution, taking values Change weight Used to adjust the impact of changes In trigger strength The contribution in, with a value of Alarm weight Used to adjust alarm aggregation amount In trigger strength The contribution in, with a value of For each trigger strength The source of the formation method retains the entry version corresponding to EPSS and KEV, the setting fragment corresponding to the change difference, the rule identifier and time window corresponding to the alarm aggregation, to ensure that the triggering results are auditable.

[0034] Vulnerability risk level Collection and Construction: Collection Sources: Vulnerability database synchronization records, component version lists, EPSS scoring entries, KEV directory entries; Binding Method: Component identifier + version number + deployment service identifier, using vulnerability entries as the effective carrier to expose targets. Construction; Normalization rule: EPSS score is The range of values ​​is KEV hit marker is The value range is 0 or 1; then Pick , where the coefficient The range of values ​​is Its function is to regulate the contribution of sources and maintain interpretability.

[0035] Impact of the change Data collection and construction: Data sources: change orders, configuration difference records, cloud security group differences, access control list differences, and identity and permission differences; Difference extraction: Changes are broken down into three categories: exposure surface differences, control constraint differences, and identity and permission differences, and each is located in the asset graph. (Nodes / edges;) Normalization rule: Let the hit tags for the three types of differences be respectively... The value can be either 0 or 1; let the score for the range of influence of the difference be... The value range is (Obtained by mapping the change in the proportion of covered assets or the proportion of covered paths according to the rules); then ,in The range of values ​​is .

[0036] Alarm aggregation Data Collection and Construction: Data Sources: Alarm event streams from security information and event management platforms, network detection systems, and endpoint detection systems; Aggregation Key: The aggregation key is defined as the combination of target asset identifier, target service identifier, ingress network domain identifier, and rule identifier; Aggregation Window: A fixed-duration window or a variable-duration window is used to align the windows; Normalization Rule: The aggregation count mapping result within the window is set to... (The count can be mapped to a piecewise linear mapping) Let the root cause missing marker be... (Set to 1 if the alarm cannot be associated with a known change or known vulnerability entry) ,in Weight Additional constraints: and Its function is to The output is clearly defined as a compressed output after a convex combination.

[0037] When used, the intensity is triggered. By unifying the three types of trigger sources—vulnerabilities, changes, and alarms—into a single, verifiable trigger basis chain, we can avoid relying on a single list or alarm to drive candidate objects into subsequent verification. This provides an interpretable sorting for the generation of the candidate set, ensuring that the verification entry point for subsequent steps is consistent with the pace of business changes.

[0038] Trigger strength has been established Under the premise that all triggered objects are directly allowed to proceed to the subsequent verification, network segmentation, proxy links, authentication methods, and policy constraints will still cause a large number of candidate objects to fail, thus occupying the verification window and interfering with localization. Therefore, in step one, a structured initial selection of reachability and preconditions is performed to allow objects to enter the candidate set. The object has a clear verification entry point.

[0039] By pre-judging the likelihood of a statement's validity and minimizing the overhead on invalid paths for subsequent verification, subsequent micro-probes are executed only at interpretable entry points. This is achieved by the exposed object. In the asset map Starting from the effective carrier, the path unfolds along the entry point, dependency edge, and permission edge, forming a connection with the exposed object. The relevant access path candidate set is used, and security policy constraints and authentication constraints are superimposed on each path: security policy constraints describe whether the network and application layers can access the access, and authentication constraints describe whether the access subject can obtain credentials or permissions.

[0040] Instead of using the existence of a path as a sufficient condition, the initial screening condition is that the path constraint can be satisfied. This requires that, under the combination of policy rules, segmentation boundaries, and access control configurations, there exists a satisfyable entry path. The preconditions are broken down into four types of assertions and formed into a precondition vector. The four main assertions are: 1) Exposure surface assertion, describing whether a service port or interface is in an accessible, exposed state; 2) Path assertion, describing whether there are uncrossable segmentations or denial rules on the path from the ingress network domain to the target asset; 3) Authentication assertion, describing whether the authentication method, session establishment conditions, and credential source of the interface are compatible with the existing network identity system; and 4) Control point assertion, describing whether critical security policies impose constraints on the path and whether these constraints have recently changed. (This is a precondition vector.) Each assertion in each dimension stores the evidence pointing to it, ensuring that in the subsequent step two, when generating microprobes, the necessary steps can be selected according to the assertion dimension, rather than being executed in a generalized manner.

[0041] Exposure objects that do not satisfy the key assertion Marked as not meeting the conditions and temporarily excluded from the candidate set. At the same time, the triggering source and the reason for non-compliance are retained for reassessment when subsequent changes occur; for exposed objects that satisfy the assertion. The system will and They are encapsulated together to form input pairs that can be directly referenced in subsequent verification.

[0042] When using it, through the precondition vector By transforming reachability judgments from empirical descriptions into traceable assertion combinations, objects entering the candidate set have clear verification entry points. This reduces window occupancy caused by invalid candidates entering subsequent verification and provides a basis for selecting assertion dimensions for subsequent microprobe generation.

[0043] The output of Step 1 is a simple list, and the subsequent Step 2 still requires backfilling the context, leading to terminology drift and misidentification of objects, resulting in a discontinuity in the chain of evidence. Setting the candidate set output as a continuously referential encapsulated object allows Step 2 to directly read and generate verification micro-probes.

[0044] Maintain a unique mapping of data objects across steps to avoid the same exposed object having different names or referencing different things in different systems. Specifically, this involves using the exposed object... +Trigger Strength +Precondition Vector +The traceability identifier serves as the smallest encapsulation unit for candidates, and all candidates that meet the preconditions are grouped into a candidate exposure set. Traceability identifiers are used to point to the origin of... The source chain and the formation of the precondition vector The assertion evidence chain ensures that subsequent steps can trace back to the triggering cause and condition mechanism when outputting verification results. A consistent time stamp is attached to each candidate to characterize its chronological relationship with the change event and to set the starting point of the verification window for subsequent step two, preventing false negatives or false positives from entering verification before the change takes effect or the policy has been fully issued.

[0045] And simultaneously, a candidate exposure set Establishing a stable snapshot ensures that in the subsequent second step, even if the asset list remains unchanged, a verification loop can be completed using the same snapshot, thus guaranteeing the consistency of the evidence chain.

[0046] Use candidate exposure set The encapsulation output and traceability identifier consistency enable subsequent steps to reuse triggering criteria and precondition assertions in a semantic space, and reduce object misidentification and evidence breakage caused by cross-system backfilling, providing a continuous data chain for subsequent verification, alignment and positioning.

[0047] Step 2: Based on the candidate exposure set For each exposed object Generate a verifiable microprobe with the minimum necessary steps, and perform evidence collection and fingerprinting output under the constraints of a security gate, so that subsequent alarm alignment and root cause localization have a verifiable chain of on-site evidence.

[0048] In production networks, the verifiable entry points and observable evidence for the same type of exposed object vary across different assets, entry network domains, and authentication methods. Using a fixed script to cover all possible paths would lead to irrelevant actions, scattered evidence, and false triggering of security policies. Therefore, the precondition vector formed in step one... As the sole criterion for trimming, the microprobe action chain is linked to the exposed object. The mechanism for its effectiveness unfolds in the same direction and maintains traceability of input and output between actions.

[0049] By establishing accessibility and validity conditions as rules for constructing action chains, microprobes can generate stable evidence that can be used for subsequent alignment. Therefore, the action chain must start from... Starting from the assertion dimension, we will gradually implement it.

[0050] The system first starts from the candidate exposure set Reading and exposing objects Precondition vector of binding and in the asset map Mid-positioning The effective carrier node or effective carrier edge; the system will then apply the precondition vector. The assertions are fixed and decomposed into exposure surface assertions, path assertions, authentication assertions, and control point assertions. For each type of assertion, a matching verification action is selected. Then, the action chain is assembled in the order of entry point establishment, authentication interaction, control point observation, and conditional probing, so that the subsequent action explicitly depends on the output of the previous action. For example, the handshake status and service fingerprint output by the entry point establishment action are used as the target parameters of the authentication interaction action, the failure code or session status output by the authentication interaction action is used as the filtering condition of the control point observation action, and the policy hit record output by the control point observation action is used as the triggering premise of the conditional probing action.

[0051] Entry point establishment actions are limited to port connectivity detection and protocol handshake detection; authentication interaction actions are limited to controlled authentication requests and failure mode sampling; control point observation actions are limited to access control list hit record verification and policy issuance status verification; condition detection actions are limited to condition detection requests without destructive loads and response pattern sampling. The engineering implementation path for action selection can use decision tables, rule engines, or satisfiability solvers, and the action order is limited by an action pre-dependency table so that subsequent actions are not executed if dependencies are not satisfied.

[0052] System output and exposed objects A one-to-one correspondence of microprobe action chains, and retaining the relationship between the microprobe and the action chain. The mapping relationships between each assertion dimension and the pre-dependencies of actions ensure that subsequent evidence can point back to specific assertion dimensions and specific actions.

[0053] When using it, it is done through the precondition vector. By pruning the action chain, the microprobes cover only the necessary actions related to the mechanism of action, thereby reducing the evidentiary noise introduced by irrelevant actions. This enables step three to explain the source of evidence along the assertion dimension when constructing the DEB, ultimately supporting an auditable chain for root cause candidate inference.

[0054] Verification micro-probes run on production networks, but production links have limitations on the number of connections, request frequency, and execution window. Without unified boundary control, micro-probes may access the same connection through multiple services within a certain timeframe, or prematurely verify results before changes take effect. By using a security gate as a prerequisite for micro-probe execution, each run is conducted within auditable boundaries, while providing on-site logs for abnormal shutdowns and rollbacks.

[0055] Transforming executable access conditions and scheduling rules into actionable criteria for the production network reduces reliance on manual approvals and maintains execution consistency.

[0056] After receiving the generated micro-probe action chain, the target asset identifier is first matched with the asset map. The business tags are compared, and the trigger strength is determined accordingly. The system generates an execution order; it then performs whitelist verification, allowed time window verification, and concurrency limit verification on each target asset. Upon successful verification, the action chain is added to the execution queue. The scheduler uses a token bucket rate-limiting method to issue execution permits and ensures that the request issuance order and action chain order for the same target asset within the same time window are consistent, preventing subsequent actions from preceding actions and causing evidence misalignment. Emergency stop logic is linked with gate logic; if a service connection is refused, the target returns an exception code sequence, the policy issuance status is incomplete, or the target health check fails during execution, the system immediately stops the exposed object. The new license will be issued and the established sessions will be terminated in a natural closing manner, while the reason for the stop, the triggering conditions and the sequence of completed actions will be written into the audit chain.

[0057] The whitelist is defined by both asset and service identifiers; the allowed time window is defined by both change window records and off-peak business windows; and the concurrency limit is defined by both the target service connection pool configuration and the historical connection limit. Rate limiting methods include token bucket, leaky bucket rate limiting, and fixed window count rate limiting, all three methods using the maximum number of requests per unit time as a common limiting criterion. Emergency stop employs a two-level process: first, stopping subsequent actions and retaining collected evidence; second, closing the session and noting the reason for closure in the audit chain. The system retains the input source and decision result for each gate determination, enabling subsequent steps to indicate when execution was allowed and why it was stopped.

[0058] When in use, the execution of microprobes is restricted to the range of whitelist, time window, and concurrency limit through a security gate, reducing the interference of verification actions on the production chain; then, the speed of requests is maintained through queue scheduling and rate limiting, so that the evidence collection behavior has a traceable execution path and an interpretable stopping boundary.

[0059] Simply recording micro-probe requests and responses is insufficient to support subsequent alarm alignment, as monitoring alarms typically originate from different observation points on the network, endpoint, identity, and policy sides; conversely, collecting all raw logs would increase correlation costs. By collecting the minimum telemetry set bound to the action chain while executing micro-probes, and then aligning it over time to form a computable minimum telemetry fingerprint, the evidence can be both verified and directly used in step three.

[0060] To ensure that the evidence generated in step two corresponds to existing monitoring alarms at the same granularity, telemetry acquisition must be based on the action chain rather than the log source.

[0061] The system assigns an action identifier to each action in the action chain and records the local timestamp and the target response timestamp before and after initiating the action request. The system synchronously collects session metadata from the network side, service process chain summaries from the endpoint side, authentication event summaries from the identity side, and rule hit records from the policy side, and aggregates these telemetry data into action-level evidence fragments according to the action identifier and time window. Subsequently, the system performs time alignment on timestamps from different sources, giving priority to using timestamps calibrated from the same network time source. If there is a deviation, the telemetry data is mapped to the same time window based on the action request initiation timestamp, so that multi-source telemetry data caused by the same action converges into the same evidence fragment.

[0062] For network-side session metadata, the fixed extraction includes the five-tuple, session direction, handshake status, and termination reason. For end-side process chain digests, the fixed extraction includes the parent-child process relationship and executable file path, and a digest is calculated on the path string. For identity-side authentication event digests, the fixed extraction includes the subject identifier, authentication method, result code, and failure reason. For policy-side rule hit records, the fixed extraction includes the rule identifier, hit direction, and action result. The minimum telemetry fingerprint is generated by concatenating the above fields in a predetermined order and then calculating the digest. The digest algorithm can be SHA-256, SM3, or BLAKE2, while retaining the original fields for manual review and auditing. The engineering implementation path for time alignment can be NTP time synchronization or linear correction based on a clock deviation table, and deviation records are retained in the alignment results.

[0063] Output and each exposed object The binding of action-level evidence fragments and minimal telemetry fingerprint sets preserves both action identifiers and time window boundaries. When used, action-level multi-source telemetry acquisition ensures that the evidence simultaneously includes four types of observations: network, edge, identity, and policy, enhancing the verifiability of subsequent alignment. Time alignment aggregates scattered evidence into action-level evidence fragments, forming minimal telemetry fingerprints to support step three.

[0064] The verification microprobes are mapped to observable connectivity, authentication, and policy hits, thus creating a one-to-one mapping between the output fields of step two and subsequent DEB fields.

[0065] In this case, after a certain access control list change, the system selects from the candidate exposure set. Select trigger strength Higher exposure objects And read its precondition vector System basis The system generates a micro-probe action chain. First, it initiates a protocol handshake with the target port and records the handshake status. Then, it sends a controlled authentication request to the target interface and records the failure code. Next, it reads the rule hit record of the policy device and records the rule identifier. Finally, it sends a condition probe request and records the response form. Within the time window allowed by the security gate, the system obtains execution permission according to the queue, executes the action chain step by step, and collects network-side session metadata, identity-side authentication event summary, and policy-side rule hit record before and after each action. At the same time, it collects the target service process chain summary.

[0066] The visible actions on-site are as follows: the maintenance terminal establishes a connection with the target service and disconnects after the handshake phase; the target service receives an authentication request and returns a clear reason for failure; the policy device generates a rule hit record; the identity audit system generates a failed authentication event record; and the endpoint records show that the service process did not exit abnormally. The system aggregates the above records into action-level evidence fragments according to action identifiers and time windows, and generates a minimum telemetry fingerprint set accordingly. The system then encapsulates the microprobe action chain, gate judgment record, execution permission record, action-level evidence fragment, minimum telemetry fingerprint set, and completion status marker into the output object of step two, and writes this output object into the audit chain for subsequent steps to read. The output object of step two serves as the direct input of step three, avoiding semantic offsets introduced by re-collection or re-association.

[0067] In use, the implementation method describes the visible connection, authentication, and rule-hitting behavior in the field, making the microprobe execution process understandable and verifiable; then, by encapsulating the output object, it ensures that the evidence from step two can be directly consumed in step three, ultimately maintaining the exposed object. Trigger strength With the precondition vector No semantic shift occurs during cross-step transitions.

[0068] Step 3: Assemble the action-level evidence fragments from Step 2 into a differential evidence package (DEB), and calculate the alignment score. Number-constrained root cause candidate set The generation of these evidences and the final handling of them are all based on the same evidentiary baseline.

[0069] Same exposed object There are instances where reachability conditions change before and after the window change, but the log caliber differs. Without baseline observations, it is difficult to explain the source of these differences. (Using candidate exposure sets...) Using stable snapshots as boundaries, historical observations are paired with current observations to assemble differential evidence packets (DEBs).

[0070] Elevate evidence from scattered logs to a referential precondition vector. Since the objects in the action chain are bound together, the observation results, fingerprint set, and source chain need to be bound to the same container.

[0071] The system reads the candidate exposure set. In and exposed objects Precondition vector of binding With trigger strength And obtain the exposed object from the output of step two. The action chain, action-level evidence fragments, and minimal telemetry fingerprint set; the system then retrieves the same [action chain / database] from the audit chain. The most recent historical observation record, requiring the precondition vectors of the historical observation record and the current observation record. The assertion dimensions are consistent and all are from the same stable snapshot version. This generates baseline observations and current observations.

[0072] The Differential Evidence Packet (DEB) consistently includes: baseline observation results, current observation results, baseline minimum telemetry fingerprint set, current minimum telemetry fingerprint set, action identifier sequence, action time window sequence, and source marker sequence. Based on this, the system generates a retest signature, used to rerun the micro-probe in subsequent steps with the same action sequence, same entry parameters, and same gate constraints. The specific form of the retest signature is to concatenate the action identifier sequence, target asset identifier, entry network domain identifier, authentication method identifier, and control point identifier, calculate a digest, and write it into the Differential Evidence Packet (DEB). The system writes the DEB as a single record into the audit chain and uses it as... The traceability identifier is returned as an index to the alignment process.

[0073] In use, the differential source can be pointed back to the baseline observation by pairing it with the current observation. The assertion dimension; solidifying the rerunnable boundary of the action chain through retest signatures, so that subsequent verifications revolve around the same input; preserving the evidence generation path through source tag sequences, so that the audit chain is verifiable.

[0074] Monitoring alarms originate from different observation points and are directly associated by alarm title. This can easily lead to duplicate causes with the same name. Using the smallest telemetry fingerprint in the differential evidence packet (DEB) as a bridge, alarm evidence is normalized to the action granularity, forming an alignment score. As a necessary constraint for root cause inference, it makes whether an alarm points to a certain action chain a computable quantity, thus writing the distinction between true hits, noisy alarms, and coverage gaps into the DEB instead of relying on manual judgment.

[0075] Within each action time window, the system retrieves alarm fragments from the security information and event management platform, network detection system, and terminal detection system, and constructs alarm fingerprints according to the same field order as the minimum telemetry fingerprint. Subsequently, while maintaining the monotonicity of the action sequence, the system calculates the maximum consistency score between the action fingerprint sequence and the alarm fingerprint sequence, and incorporates the time offset as a penalty into the same score, thus forming an alignment score. .

[0076] First, use the similarity function Calculate the similarity of a single fingerprint pair, then obtain the global score using a monotonic alignment path, and finally obtain the alignment score through saturation mapping. : Where: Alignment fraction : Used to characterize the degree of consistency between the action fingerprint sequence and the alarm fingerprint sequence, with values ​​ranging from 0 to 1. Its function is to serve as the alignment constraint strength for the generation of root cause candidates; saturation mapping function Used to map alignment scores to a finite interval, with values ​​ranging from 1 to 2. Its function is to suppress extreme value dominance; its specific form is Alignment path set : Used to limit the alignment path to a matching set that maintains a monotonically increasing index, with a finite set of values; alignment path : Used to represent a specific matching trajectory, with a value range of Inner element; Action index : A set of positive integers used to identify positions in an action sequence; alarm index : Used to identify the position in the alarm sequence, and is a set of positive integers; Action fingerprint : Used to indicate the first The minimum telemetry fingerprint feature vector for each action is a non-negative vector; alarm fingerprint : Used to indicate the first The fingerprint feature vector of the alarm segment, a non-negative vector; action timestamp. : Used to indicate the first The alignment reference time for each action, represented as a real number on the timeline, serves as the input for time penalty calculation; alarm timestamp. : Used to indicate the first The alignment reference time for each alarm segment is represented as a real number on the timeline; the time penalty coefficient... Used to adjust the effect of time offset on the score, with a value of [value missing]. To achieve a balance between content consistency and temporal consistency; similarity function Used for calculation and Content similarity, with a value range of Its function is to evaluate consistency without relying on the full text of the original log; its specific form is as follows: ,in For inner product, and ; Feature mapping operator Definition: Maps a structured set of fields to a non-negative vector. Let the set of fields be... Its elements are discrete key-value pairs or discrete enumeration values; defined The construction method is as follows: assign a dimension index (using a dictionary or consistent hashing) to each discrete field value; if a field value appears, the corresponding dimension is set to 1; otherwise, it is set to 0; for fields with multiple values ​​(such as a set of rule identifiers), each value is set to 1; for numeric fields (such as port numbers), they can be discretized into interval buckets before being set. This yields a vector. , ,in For the first A set of fields for a single action evidence fragment. For the first A collection of fields for each alarm segment. Alignment threshold. The range of values ​​is Its function is to discretize the alignment result into labels; when The time marker is a true hit, when If an alarm segment exists but a monotonic alignment path cannot be formed, then a noise alarm is marked. If an action chain exists but no alarm segment can be aligned, then an overlay gap is marked.

[0077] In the above, the solution for monotonic alignment paths can be obtained using dynamic programming, shortest path solvers, or constraint satisfaction solvers, with the constraint that the same alarm segment can match at most one action to avoid multiple attributions; when the alignment score If the preset alignment requirements are not met, the system will label the alarm as a noise alarm or the action chain as a coverage gap, and write the label into the differential evidence package (DEB).

[0078] When using it, align the fractions. Constrain alarm evidence to the action granularity, so that alarms and actions are linked. The relationship can be recalculated; reverse mismatches are avoided through monotonic alignment, making true hit labels traceable; and the blind patching entry is fixed by covering the gap labels, providing a basis for subsequent temporary deep defense.

[0079] Obtain the differential evidence packet (DEB) and the alignment score. Afterwards, the phenomenon still needs to be narrowed down to executable objects; otherwise, step four cannot price the repair action. (Based on asset mapping) Using the path relationships as the skeleton, the difference fields and true hit labels are projected onto the difference path subgraph to form a root cause candidate set. .

[0080] Make the root cause candidate point to a specific patch version, specific configuration key, specific policy rule identifier, or specific permission grant record, so as to be consistent with the action granularity of the subsequent budgeted minimum fix set.

[0081] As a supplement: Let the set of optional actions be... (from the root cause candidate set) (obtained through action), for each action Definition, cost (Non-negative real number), risk reduction amount (Non-negative real numbers), decision variables The budget limit is ,but If there are dependency order constraints (e.g., tightening the policy before revoking permissions), then the dependency pairs... Increase: Risk reduction The source is fixed as step three: for the action The bound evidence chain segment, if it is located in the differential path subgraph And the corresponding alignment score If the true hit label is satisfied, then Take as trigger strength The monotonic function value; the simplest implementation can be taken as This ensures that verified paths take precedence.

[0082] The engineering implementation tool can be either a mixed-integer programming solver or a constraint programming solver, and the solution output is... The set of actions, i.e., the budgeted minimum repair set.

[0083] Specifically, the system extracts the action index and differential field that caused the differential from the differential evidence package (DEB), along with... Tracing back the entry edges, authentication edges, and policy edges involved in these actions yields a differential path subgraph; the system then reads the change impact recorded in step one. The source fragment is used to retrieve changed objects within the coverage area of ​​the differential path subgraph and compare them with the exposed objects. The effective carriers together form candidates; when the true hit label in the differential evidence package (DEB) is valid, the system requires that the candidate must simultaneously meet two conditions: being located in the differential path subgraph and sharing the control point identifier with the true hit action, thereby eliminating change objects that only appear on the periphery but are irrelevant to the alarm. The differential field comparator prioritizes comparing the authentication failure reason, policy hit result, service fingerprint, and permission subject identifier to avoid using network jitter fields as the root cause; graph backtracking can use graph database queries or depth-first traversal, and candidate filtering can use a rule engine or the satisfiability modular theory solver (SMT solver); for permission candidates, the system aligns the timestamp of the authorization approval record with the alarm time window; for policy candidates, the system aligns the policy issuance record with the policy hit record.

[0084] The system arranges evidence chain segments for each candidate in the differential evidence package (DEB). Each segment is fixed and includes: graph edge identifier, action index, differential field name, alarm segment identifier, and time window, which facilitates subsequent review and rerun.

[0085] When using it, through the asset map The difference path subgraph makes the candidate It points to a specific executable object; it suppresses irrelevant changes from entering the candidate list through true hit constraints, making the candidate set interpretable; and it fixes the reference relationship through evidence chain segments, so that subsequent processing does not require cross-system splicing.

[0086] Furthermore, the reasons for the formation of a certain candidate can be verified along the evidence chain, thus allowing for direct reference during the repair scheduling. Specifically, in one instance, a micro-probe completed an entry handshake and controlled authentication request to the management interface, and the system retrieved this information in the audit chain. Historical observations and DEB assembly; the system retrieves failed authentication alarms and policy hit alarms within the action time window and constructs alarm fingerprints, calculating alignment scores. The tag is then written to the DEB; when a true match is found, the system updates the asset graph. The process traces back to an access control list rule identifier and a temporary authorization record identifier, and adds both to the root cause candidate set. Simultaneously, an evidence chain segment containing rule identifiers, authorization identifiers, action indexes, and alarm identifiers is generated within the DEB. The visible result is a DEB record appearing in the audit chain, listing candidate identifiers. If the coverage gap label is valid, the system will... The system converges to the collection point identifier or the policy miss identifier and outputs it so that step four can prioritize temporary deep defense; if the noise alarm label is established, the system outputs the alarm segment identifier and its misalignment reason field for subsequent rule revision.

[0087] When used, it enables the visible process of DEB assembly, alignment, and candidate generation, and the evidence chain can be verified; the classification output solidifies true hits, noise alarms, and coverage gaps into subsequent action selections; the unified encapsulation fields ensure that step four can be directly priced and scheduled, triggering a rerun.

[0088] Step 4: Based on the root cause candidate set Generate a sequence of repair actions for resources and change window constraints. If immediate repair is not possible, generate a temporary deep defense action sequence. Use dual-channel regression to transform the handling results into reproducible evidence, and then infuse the verification conclusions into the trigger strength. The microprobe action chain pruning rules ensure that similar events converge along the same evidence path.

[0089] Step three has already set the root cause candidate set. The study limited the data to the differential path subgraph and eliminated peripheral noise using true hit alignment constraints, but the root cause candidate set... In the engineering field, these objects are still manifested as four types of carriers: patch objects, configuration objects, policy objects, and permission objects. If disposal instructions are issued directly to these carriers, inconsistencies in action granularity can easily occur, making it impossible to sort and execute changes within the same change window. This also makes it difficult to correspond to the observed differential fields during subsequent retesting.

[0090] Each candidate is transcribed into a unified action description, and the input location, scope, and rollback conditions of the action are solidified as boundaries to ensure that subsequent programming and acceptance have the same reference.

[0091] For the output of step four to be directly usable by the execution system, the action must point to a specific writable location and be able to point back to the evidence chain segment that forms the action.

[0092] The system reads each candidate evidence chain segment from the differential evidence package (DEB), categorizes them by carrier type, and then generates a unique action description for each candidate. This action description includes at least the target asset identifier, target service identifier, target location identifier, pre-change snapshot identifier, and post-change target identifier. The target location identifier points to the patch package name and version, configuration file path and key name, policy rule identifier and matching condition, and permission grant record identifier and subject identifier, respectively. The system then establishes a reference between the action description and the action index of the micro-probe action chain from step two, forming a single-chain reference between the action and the differential field that triggered it, thereby fixing the necessity of the action on the same evidence baseline.

[0093] Patch actions are defined as replacing the target version and restarting the corresponding service process; configuration actions are defined as modifying key values ​​and loading the effective definition; policy actions are defined as publishing rules and completing the distribution confirmation definition; and permission actions are defined as revoking grants and completing the directory synchronization confirmation definition. Rollback conditions are limited to reverting the patch version, restoring the configuration snapshot, withdrawing policy rules, and restoring permission grants, and rollback actions must also be written into the audit chain. Action descriptions can be written into change order fields or audit log fields, retaining the original text of the target location identifier and snapshot identifier. Optional engineering implementation paths include: verifying the feasibility of the action sequence using a mixed-integer programming solver, restricting the processing dependencies of the programming solver, and using a graph search solver in the asset graph. The scope of the validation action and the dependency closure are verified on the differential path subgraph.

[0094] When using it, by setting the root cause candidate set The mapping is used to describe unified actions, making patches, configurations, policies, and permission carriers sortable and executable at the same granularity. By binding actions to evidence chain segments of the differential evidence package (DEB), the necessity of actions and verifiable fields are made clear, facilitating retesting of signature references.

[0095] Furthermore, the change window for the production network is limited, and some actions have preconditions for execution. If critical fixes cannot be completed within the window, the exposed object... It may still be accessible and available; at the same time, if temporary defenses only implement broad blocking, they may easily affect unrelated businesses and cause long-term legacy issues.

[0096] Trigger strength Expressing urgency in order to align scores Expressing consistency of evidence, and using asset mapping The differential path subgraph defines the impact area and generates a repair action sequence; when repair is not feasible, a temporary deep defense action sequence is generated and an expiration cancellation condition is defined, so that the temporary actions are retrievable and verifiable.

[0097] By replacing experience-based ranking with evidence weights and path boundaries, action selection and sequence must be simultaneously influenced by trigger strength. Alignment score With the constraint of differential path subgraph.

[0098] The system first checks the preconditions for each action description, and these preconditions are derived from the precondition vector. Differential fields with the differential evidence package DEB: Policy-type actions require the distribution channel to be available and the policy device to be reachable; permission-type actions require the subject identifier and grant record identifier to be complete; patch-type actions require the target version package to be obtainable and the restart to be within the window's allowed range; configuration-type actions require configuration write permissions and the existence of the loading entry point.

[0099] The system then generates a sequence of repair actions within the change window, with the order rules fixed as follows: evidence weight first, dependency relationship first, and rollback cost controllable. The evidence weight is determined by the trigger strength. Alignment score The results were obtained by fusing after piecewise linear interpolation mapping, and numerical differentiation was performed to check the impact of changes in evidence weights on action selection. Dependencies were determined from the asset graph. The service dependency edge and control point edge are given, and the rollback cost is determined by the number of rollback steps and the scope size. If critical actions cannot be included in the sequence due to insufficient window or missing preconditions, the system switches to generating a temporary defense-in-depth action sequence, prioritizing actions that can impose restrictions at the entry point and control point of the differential path subgraph. Temporary actions include application layer firewall rule publishing, network segmentation policy adjustment, access control list rule tightening, and identity subject permission convergence. Application layer firewall rules can be deployed at the reverse proxy entry point or service gateway entry point, access control list rules can be deployed at the switching device policy plane or cloud-side security group policy plane, and identity subject permission convergence can be deployed at the directory service policy plane or cloud permission policy plane.

[0100] The system defines an expiration cancellation condition for each temporary action. The expiration cancellation condition is fixed as the corresponding repair action being completed and verified by dual-channel regression. At the same time, a reverse cancellation order is defined for the cancellation action, canceling the entry restriction first and then the inner restriction, to avoid short-term detours during the cancellation process.

[0101] When used, the intensity is triggered. Alignment score Evidence weighting drives the sequence of remediation actions to focus on urgent and evidence-consistent paths. This is achieved through asset mapping. The differential path subgraph constraint ensures that temporary deep defenses fall between the entry point and the control point while maintaining a controllable impact area.

[0102] Furthermore, once the handling process enters the execution phase, common on-site risks include actions being issued but not yet effective, or actions being effective but their impact exceeding the scope of the differential path subgraph. Without a unified execution trajectory and rollback trigger conditions, it is difficult to trace the cause when differential anomalies occur during subsequent retesting. The execution process is limited to a traceable action pipeline, with the differential evidence package (DEB) serving as the sole reference for comparison before and after execution. Implementation methods are interspersed to present visible actions and visible results. This ensures that the handling process and the evidence chain maintain the same field definition, allowing for rollback according to the same criteria and preservation of rollback evidence in the event of anomalies.

[0103] Specifically, the system reads the exposed object from the output object in step three. Differential Evidence Package (DEB) Index, Alignment Score Before executing each action sequence, a pre-execution check is performed, including the target service health status, policy distribution channel status, directory synchronization channel status, and change window status. After passing the check, the system executes each action sequentially, recording the execution request identifier, execution completion identifier, and scope identifier at the end of each action. Simultaneously, a snapshot of key fields before and after execution is written to the audit chain. These key field snapshots are derived from the differential evidence package (DEB)'s differential field set and precondition vector. The assertion dimension.

[0104] In use, pre-execution checks, confirmation issuance, and snapshot recording ensure that issued but ineffective states can be identified and traced. Rollback trigger conditions and a fixed rollback order allow exception handling to revert to a pre-execution snapshot while maintaining dependencies. This enables subsequent retesting of differential anomalies to point back to specific actions, snapshots, and rollback points.

[0105] After the initial handling is complete, simply verifying the version installation or rule existence is insufficient to confirm that the attack path has been cut off. Furthermore, if the micro-probe rerun does not produce the expected differential, it is necessary to differentiate between handling failure and data collection gaps. Dual-channel regression verification should be performed under the same retest signature constraint, and the verification results should be fed back into the trigger strength. The microprobe action chain pruning rules enable the system to converge to the executable root cause with fewer actions in the next similar event. To elevate acceptance from action completion to evidence differential validity, the execution pipeline and microprobe reruns need to be included in the same decision chain.

[0106] Channel 1 verification uses the execution completion identifier as a basis to check the patch version, configuration key value, policy rule activation status, and authorization record revocation status item by item, and writes the verification results into the current observation field of the differential evidence package (DEB). Channel 2 verification uses the retest signature fixed in the differential evidence package (DEB) as a constraint to rerun the second step of the microprobe action chain. During the rerun, the same entry network domain, the same authentication method, and the same security gate boundary are used. The system performs a differential comparison between the minimum telemetry fingerprint set generated by the rerun and the minimum telemetry fingerprint set before processing, aligning the action index, and requires that the difference falls within the root cause candidate set. The corresponding differential fields include changes in policy hit results, changes in authentication failure reasons, and changes in path assertions from satisfied to unsatisfied. If channel two does not meet the differential requirements, the system first checks whether step three marks the coverage gap. If the coverage gap is established, the gap is pointed to the collection point identifier or rule caliber identifier and a completion task is generated. If the coverage gap is not established, the action index that does not meet the differential is pointed back to the handling action description, triggering re-handling or triggering rollback.

[0107] Differential comparison employs field-by-field matching and alignment with action time windows; the rerun scheduling reuses the rate limiting and queue rules from step two; during power-back, the system writes the verified severed evidence chain segments into the trigger strength. The source marker is used to write the index of actions that were not cut off but completed to the trigger strength. Historical factors are used to adjust subsequent weights, and the action index is associated with the negative sample entry of the microprobe action chain pruning rule, so that the next exposure of the same type of object... When triggered, the probability of entering an invalid handling action is automatically reduced.

[0108] In use, dual-channel verification distinguishes between execution completion and path interruption, making the handling conclusions verifiable and reproducible. By covering gap branches, missing data collection and handling failures are separated, giving the completion task and re-handling a clear direction and maintaining the same evidentiary standard, enabling subsequent similar events to converge faster and reducing redundant verification.

[0109] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0110] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0111] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0112] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0113] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A vulnerability monitoring, localization, and defense-in-depth system based on attack and defense simulation, characterized in that: This includes establishing an asset map, abstracting vulnerabilities, configuration items, and permission items into exposed objects, generating a candidate exposure set based on vulnerability updates, changes in the exposure surface, or alarm anomalies, and performing initial screening based on reachability and preconditions. Verification microprobes are generated for the candidate exposure set. These microprobes are used to verify the minimum steps required for accessibility, preconditions, and utilization conditions, and to prohibit destructive loads. They are executed within the range and rate constraints of the safety gate and telemetry data is collected to obtain the minimum telemetry fingerprint. The results before and after execution are compared with the minimum telemetry fingerprint to generate a differential evidence package, and alarm-step alignment is performed to obtain an alignment score. This score is then combined with the asset map to determine the candidate root cause object set and retest signature. Under budget and change window constraints, the minimum repair set is determined from the candidate root cause object set. Temporary deep defense action sets are generated for the remaining objects. The repair effectiveness is verified, and the microprobes corresponding to the retest signature are rerun and verified. The results are then fed back into the candidate exposure set generation and microprobe template library.

2. The vulnerability monitoring, location, and defense-in-depth system according to claim 1, characterized in that: The asset graph consists of asset nodes, service nodes, port nodes, dependency edges, identity and permission edges, and security policy edges. It also establishes a binding identifier between the exposed object and the service node. The binding identifier includes the asset identifier, service identifier, port number, and version identifier, so that the candidate exposure set can be grouped according to the binding identifier.

3. The monitoring vulnerability location and defense-in-depth system according to claim 2, characterized in that: Acquire probability scores, directory hit information, port open records, service launch records, security policy change records, and alarm and anomaly records. Form a candidate exposure set according to preset fusion rules. The fusion rules include time association constraints, same-origin association constraints, and dependency association constraints, and record the trigger source corresponding to each exposure object.

4. The vulnerability monitoring, location, and defense-in-depth system according to claim 3, characterized in that: The accessibility and preliminary screening of preconditions includes performing network connectivity detection, port accessibility detection, and authentication entry availability verification on exposed objects, and structuring the detection results into a precondition vector and writing it into the candidate exposure set, while also writing the collection timestamp and evidence source identifier into the precondition vector.

5. The vulnerability monitoring, location, and defense-in-depth system according to claim 4, characterized in that: The verification micro-probe generates an action chain based on the precondition vector. The action chain includes connectivity verification, authentication interaction, policy hit verification and result collection steps in sequence. During the generation stage, the action chain is limited to only read-only requests and authentication requests, and the execution entry and request parameter template are recorded for the action chain.

6. The vulnerability monitoring, location, and defense-in-depth system according to claim 5, characterized in that: Before executing the verification micro probe, the security gate writes the target range whitelist, concurrency limit, rate limit, execution window, resource budget limit, emergency stop condition and rollback condition, and deducts the resource budget during execution. When the resource budget limit is reached, the emergency stop condition is triggered.

7. The vulnerability monitoring, location, and defense-in-depth system according to claim 6, characterized in that: The collection of telemetry data includes network-side session metadata, terminal-side process chains, authentication events, and policy hit records. Fields are extracted according to the action sequence of the action chain to generate a minimum telemetry fingerprint. The minimum telemetry fingerprint includes session identifier, process identifier, account identifier, policy identifier, and action sequence number, and is stored in association with the action timestamp.

8. The vulnerability monitoring, location, and defense-in-depth system according to claim 7, characterized in that: The differential evidence package includes a precondition vector, execution result, minimum telemetry fingerprint, alignment score, candidate root cause object set and retest signature. It completes alarm-step alignment with time window constraints, subject-object consistency constraints and fingerprint similarity constraints, forms a mapping relationship between alarm identifier and step identifier and outputs alignment label.

9. The monitoring vulnerability location and defense-in-depth system according to claim 8, characterized in that: The candidate root cause object set is jointly determined by the differential fields of the differential evidence package and the dependency relationship of the asset graph. The candidate root cause object set is limited to configuration key, component version, policy ID and permission boundary, and a set of disposal actions corresponding to the retest signature is generated for the candidate root cause object set.

10. The vulnerability monitoring and defense-in-depth system according to claim 9, characterized in that: The minimum repair set is generated by the solver from the set of disposal actions under budget and change window constraints, and a temporary deep defense action set is generated for candidate root cause objects that do not enter the minimum repair set; the dual-channel regression verification includes repair effectiveness verification and retest signature corresponding verification microprobe rerun verification, and the verification results are fed back into the microprobe template library.

Images