A simulation attack verification method based on a security intelligent agent

Abstract

This application relates to the technical field of information security, and discloses a simulated attack verification method based on a security intelligent agent, including steps such as judgment result access and context enrichment, security intelligent agent PoC harmless verification, dynamic policy orchestration and human-machine collaborative judgment, automated execution and policy distribution, closed-loop feedback and model self-evolution. This application achieves intelligent screening of PoC scripts through vector matching, completing non-destructive risk verification in an isolated sandbox; it constructs a policy weight model based on asset attributes and business context to achieve dynamic policy orchestration and conflict resolution, clarifying the boundaries of human-machine collaborative handling; and it establishes end-to-end data feedback to achieve self-optimization of the risk assessment model. This method accurately distinguishes between real and theoretical risks, reduces the probability of mishandling, ensures the continuity of core government cloud services, achieves continuous self-evolution of the security protection system, and adapts to the stringent requirements of government cloud security protection.

Description

Technical Field

[0001] This application relates to the technical field of information security, and in particular to a method for simulating attack verification based on a security intelligent agent. Background Technology

[0002] With the continuous advancement of digital government construction, government cloud platforms have become core infrastructure supporting various government services and public welfare services. The business systems they support involve a large amount of sensitive personal information and government data, corresponding to stringent cybersecurity protection and compliance requirements. Within the government cloud security protection system, existing technologies can output corresponding risk assessment results through attack surface identification and risk assessment, providing a basis for security actions. Security Orchestration Automation and Response (SOAR) technology, as a core tool for security operation automation, has been widely applied in the security handling process of government clouds to automate risk handling and improve security operation efficiency.

[0003] However, in actual government cloud security operation scenarios, existing technologies still have many unresolved technical shortcomings in translating risk assessment results into actual response actions. First, existing SOAR tools typically trigger automated response actions directly based on preset rules, lacking a pre-response risk authenticity verification step. They cannot distinguish between theoretically existing risks and actually exploitable risks. In the complex business scenarios of government clouds, normal high-frequency business access and compliant operation and maintenance are easily misjudged as attack behaviors and blocked, leading to the interruption of core public services such as government services and medical insurance settlement. There is a lack of technical means to perform harmless logical verification of risks before response.

[0004] Secondly, existing automated handling strategies are mostly generated based on general templates, failing to be deeply coupled with the asset attributes and business context in the government cloud scenario. They cannot generate differentiated handling strategies based on the asset's sensitivity level, the attributes of the commission or bureau to which it belongs, the business time period, and the requirements for critical protection. For core business systems with high sensitivity levels and test systems with low sensitivity levels, homogeneous handling methods are often adopted, which cannot adapt to the differentiated handling needs of multiple assets, multiple entities, and multiple scenarios in the government cloud scenario.

[0005] Furthermore, existing security handling procedures are usually considered to be completed once the handling strategy is issued, without quantifying and feeding back data such as handling effects and verification results. This makes it impossible to synchronize data from the actual handling process to the upstream asset knowledge base and risk assessment model, resulting in the risk assessment model being unable to self-optimize based on actual results. Over the long term, this can easily lead to repeated false alarms and missed alarms, making it impossible to achieve continuous iteration of security protection capabilities.

[0006] Finally, existing automated processing technologies do not clearly classify and define the risk levels of processing actions. For high-risk operations that may cause significant business impact, such as business code modification or network-wide access blocking, they still adopt fully automated execution, which can easily lead to irreversible business interruption accidents. At the same time, they do not meet the compliance audit and responsibility determination requirements in the government cloud scenario and lack a controllable human-machine collaborative processing mechanism. Summary of the Invention

[0007] To address the aforementioned technical problems, this application provides a simulated attack verification method based on a secure intelligent agent, employing the following technical solution:

[0008] A simulated attack verification method based on a secure intelligent agent includes the following steps:

[0009] Step S1: Receive the standardized risk assessment report output from the pre-output through the preset message queue, extract the risk characteristics and asset identification information from the report, query the preset asset knowledge graph using the asset identification as an index, supplement the business context attributes for the risk event, and generate enriched risk event data;

[0010] Step S2: Based on the risk feature vector in the enriched risk event data, the corresponding PoC script is matched from the pre-set proof-of-concept PoC script library through a preset vector matching algorithm. The security agent executes the matched PoC script in a harmless sandbox environment isolated from the production network. The risk authenticity is verified by using a non-destructive detection and verification mode, and the risk verification result is output.

[0011] Step S3: Based on the enrichment risk event data and risk verification results, generate an appropriate initial handling strategy through a preset strategy weight calculation model. After conflict resolution processing of the initial handling strategy, classify the handling strategy according to the preset risk level judgment rules. Based on the classification results, the handling strategy is divided into automatic execution strategy or manual review strategy.

[0012] Step S4: The automated execution gateway converts and issues instructions for automated execution policies, verifies the execution results in real time, and triggers backup execution paths when execution fails; for manually reviewed policies, it automatically generates standardized handling work orders and pushes them to the corresponding responsible persons, and receives feedback on the handling execution results from the responsible persons.

[0013] Step S5: Based on the preset verification cycle, retest the target assets after disposal, generate disposal effect evaluation results, package the full-link data of this risk event and feed it back to the preset asset knowledge graph and upstream risk assessment model to complete the closed loop of the entire risk disposal process and optimize the model parameters.

[0014] Optionally, in step S1, the standardized risk assessment report is in JSON format and includes at least the following fields: risk assessment boolean value, risk identifier Flag, asset ID, weighted risk feature vector, and risk evidence chain;

[0015] The business context attributes include at least the asset's business continuity level, asset owner information, related business flow information, and current time period business strategy.

[0016] Optionally, in step S2, the vector matching algorithm uses a cosine similarity calculation algorithm, specifically:

[0017] Pre-generate a corresponding attack feature vector for each PoC script in the PoC script library. Calculate the weighted risk feature vector in the enrichment risk event data. With each The cosine similarity Sim between them is calculated using the following formula:

[0018] ;

[0019] in, This represents the dot product operation of vectors. Represents the L2 norm of a vector; preset similarity threshold. ,when When the threshold is met, the PoC script is matched; when no matching result meets the threshold, the preset large language model LLM is called to generate logic verification pseudocode that has been verified for security, as a temporary verification script.

[0020] Optionally, in step S2, the harmless sandbox environment and the production network are deployed in a logically isolated manner, allowing only the sandbox to send one-way probe traffic to the target verification asset, and prohibiting reverse data backhaul and access to other assets in the production network;

[0021] The non-destructive detection and verification mode adopts a probe-rollback mechanism. The security agent only sends a preset feature probe payload and completes risk verification by detecting the feature code of the target asset's return packet. It does not perform destructive operations such as obtaining permissions, reading sensitive data, or modifying system configuration.

[0022] The risk verification results include true risk results that confirm real risks and false risk results that confirm false alarms. The false risk results simultaneously generate negative sample labels for upstream model optimization.

[0023] Optionally, in step S3, the calculation formula for the strategy weight calculation model is:

[0024] ;

[0025] in, To handle the strategy weight values, This is a risk indicator, with a value ranging from 0 to 1. The higher the value, the higher the risk level. This is the asset sensitivity level coefficient, which is assigned a value according to the asset's preset sensitivity level. This is a business period factor, assigned a value based on the current business period of the asset; based on the calculated... The initial handling strategy is matched to the corresponding level. The higher the strategy weight value, the stronger the control of the handling strategy.

[0026] Optionally, in step S3, the specific method for resolving conflicts in the initial handling strategy is as follows: a core business whitelist is preset, which includes core business IP ranges, key business ports, and core business domain names; the object to be handled by the initial handling strategy is verified to be in the core business whitelist, and if it is, the control intensity of the handling strategy is automatically reduced to avoid affecting the core business.

[0027] Optionally, in step S3, the preset risk level determination rule is as follows: lightweight handling operations that do not affect the core business logic and have no risk of business interruption are determined as low-risk operations, corresponding to automatic execution strategies. The lightweight handling operations include at least virtual patch distribution, specific IP access rate limiting, and alarm notification sending; handling operations that involve changes to the core business logic and have a significant risk of business interruption are determined as high-risk operations, corresponding to manual review strategies. The high-risk operations include at least business code modification, core service port closure, and network-wide IP access blocking; when the risk verification result is a false risk or the initial handling strategy cannot be parsed, the handling process is automatically downgraded to a manual review strategy.

[0028] Optionally, in step S4, the automated execution gateway is equipped with a device adaptation layer, an API aggregation gateway, and an atomic capability encapsulation module. The atomic capability encapsulation module encapsulates various handling operations into standardized atomic instructions. The device adaptation layer shields the interface differences of different security devices at the lower layer. The API aggregation gateway converts the standardized handling strategy into API instructions that can be recognized by the corresponding security device and issues them. The execution result verification is completed through API return codes. When the execution times out or fails, it automatically switches to a preset backup execution path to complete the handling operation.

[0029] Optionally, in step S5, the disposal effect evaluation result includes a successful disposal result where the risk has been eliminated and a failed disposal result where the risk has not been eliminated. The successful disposal result synchronously updates the asset security status in the asset knowledge graph, and the failed disposal result triggers a secondary disposal process or a manual review work order.

[0030] The end-to-end data includes risk characteristic data, risk verification results, disposal strategy content, disposal execution results, and disposal effect evaluation data. The end-to-end data is written back to the asset knowledge graph and upstream risk assessment model through a preset API interface to update the asset risk ledger and optimize the model judgment parameters.

[0031] In summary, this application includes at least one of the following beneficial technical effects:

[0032] 1. This application constructs a PoC intelligent screening and harmless verification mechanism based on vectorized matching to verify the authenticity of risks in an environment isolated from the production network. This enables accurate judgment from theoretical risk to empirical risk, effectively eliminating false triggering conditions for handling caused by false risk alarms, providing a reliable decision-making basis for automated handling, and reducing the probability of mishandling from the root. At the same time, through a non-destructive detection and verification mode, the verification process avoids the impact on production operations and adapts to the stringent requirements of the government cloud production environment.

[0033] 2. This application, through a dynamic strategy orchestration and conflict resolution mechanism that integrates government cloud asset data standards, can generate differentiated handling strategies based on multi-dimensional attributes such as asset sensitivity level and business time period. At the same time, it defines the rigid boundary between automated handling and manual intervention through clear risk classification rules. High-risk operations are forcibly transferred to manual review processes, which not only ensures the handling efficiency of low-risk operations, but also avoids secondary business accidents caused by automated handling, effectively ensuring the continuous and stable operation of the core business of government cloud, while meeting the compliance audit and responsibility determination requirements in government scenarios.

[0034] 3. This application establishes a closed-loop feedback mechanism throughout the entire process, connecting the complete data link from risk discovery, verification, handling to effect evaluation. It transforms all data from the actual handling process into optimized samples for the upstream risk assessment model, enabling the entire security protection system to continuously correct the judgment logic and strategy parameters based on feedback from actual scenarios. This achieves continuous iteration and self-evolution of security protection capabilities, and can adapt to ever-changing attack and defense scenarios and the security protection needs of government cloud. Attached Figure Description

[0035] Figure 1 This is a flowchart illustrating the simulated attack verification method based on a secure intelligent agent in this application. Detailed Implementation

[0036] The embodiments of this application are described in detail below, and examples of the embodiments are shown in the accompanying drawings.

[0037] In the description of this specification, the references to "certain embodiments," "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples" refer to specific features, structures, materials, or characteristics described in connection with the described embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0038] This application discloses a simulated attack verification method based on a secure intelligent agent, referring to... Figure 1 It includes the following steps:

[0039] Step S1: Receive the standardized risk assessment report output from the pre-output through the preset message queue, extract the risk characteristics and asset identification information from the report, query the preset asset knowledge graph using the asset identification as an index, supplement the business context attributes for the risk event, and generate enriched risk event data;

[0040] Step S2: Based on the risk feature vector in the enriched risk event data, the corresponding PoC script is matched from the pre-set proof-of-concept PoC script library through a preset vector matching algorithm. The security agent executes the matched PoC script in a harmless sandbox environment isolated from the production network. The risk authenticity is verified by using a non-destructive detection and verification mode, and the risk verification result is output.

[0041] Step S3: Based on the enrichment risk event data and risk verification results, generate an appropriate initial handling strategy through a preset strategy weight calculation model. After conflict resolution processing of the initial handling strategy, classify the handling strategy according to the preset risk level judgment rules. Based on the classification results, the handling strategy is divided into automatic execution strategy or manual review strategy.

[0042] Step S4: The automated execution gateway converts and issues instructions for automated execution policies, verifies the execution results in real time, and triggers backup execution paths when execution fails; for manually reviewed policies, it automatically generates standardized handling work orders and pushes them to the corresponding responsible persons, and receives feedback on the handling execution results from the responsible persons.

[0043] Step S5: Based on the preset verification cycle, retest the target assets after disposal, generate disposal effect evaluation results, package the full-link data of this risk event and feed it back to the preset asset knowledge graph and upstream risk assessment model to complete the closed loop of the entire risk disposal process and optimize the model parameters.

[0044] This embodiment discloses a simulated attack verification method based on a secure intelligent agent, applied to the core medical insurance business system hosted on a provincial government cloud platform. This system is a Level 3 compliant system, carrying a large amount of sensitive personal information of insured individuals, and has extremely high requirements for business continuity and data security protection. The system's preset asset sensitivity level is L3, with peak business hours from 8:00 to 18:00 daily and off-peak hours during other times. The triggering scenario for this embodiment is as follows: a front-end multi-dimensional attack surface identification and judgment system detects a configuration change of "cancellation of two-factor authentication" in the identity authentication module of the core medical insurance business system, determines it as a high-risk event, generates a standardized risk assessment report, and outputs it.

[0045] The specific implementation steps of this embodiment are as follows:

[0046] The first step involves incorporating the assessment results and enriching the context. The system receives standardized JSON-formatted risk assessment reports from the front-end system via a pre-configured Kafka high-performance message queue. A risk feature extractor then extracts the corresponding core fields from the report, including the risk assessment boolean values. Risk label Asset ID, 256-dimensional weighted risk feature vector The risk evidence chain includes operation records of the configuration change, a comparison of the configuration before and after the change, and related API interface information. Using the extracted asset ID as an index, a context enrichment engine queries a pre-defined asset knowledge graph to supplement the risk event with corresponding business context attributes. These attributes include the asset's business continuity level (core level), information on the asset's responsible person and approver, related medical insurance settlement business flow information, and business strategy information indicating that the current period is a peak business time. Integrating this information generates enriched risk event data, completing the risk event access and context enrichment.

[0047] The second step involves performing a PoC (Proof of Concept) harmlessness verification operation based on vector matching for the safety intelligent agent. This is based on a 256-dimensional weighted risk feature vector from the enriched risk event data. The system performs vector matching operations through the PoC vector retrieval engine. Each PoC script in the system's pre-built PoC script library has a pre-generated 256-dimensional attack feature vector. Using the cosine similarity calculation algorithm, calculate With each in the warehouse The cosine similarity Sim between them is calculated using the following formula:

[0048] ;

[0049] in This represents the dot product operation of vectors. The L2 norm of a vector, and the system's preset similarity threshold. In this embodiment, the calculated similarity result is 0.96, which meets the threshold requirement and matches the corresponding "Unauthorized Access Verification PoC Script".

[0050] The PoC script is executed by a security agent in a pre-defined harmless execution sandbox. This sandbox is deployed in a logically isolated manner from the government cloud production network. It is only allowed to send one-way probe traffic to the API interface of the target medical insurance business system being verified. Reverse data backhaul is prohibited, as is access to other assets within the production network, ensuring that the verification process will not have any impact on the production environment.

[0051] The verification process employs a non-destructive probe-rollback mechanism. The security agent only sends HTTP probe requests without authentication tokens to the target API interface, completing risk verification by detecting the signature codes in the server's response packets. No destructive operations such as gaining permissions, reading sensitive data in bulk, or modifying system configurations are performed. In this embodiment, the target server returns business data containing sensitive information about insured individuals, rather than a response message indicating authentication failure. The logical verification determiner outputs a verification result confirming the risk as a genuine and exploitable risk. If the server returns an authentication failure response message during the verification process, it is determined to be a false risk, and negative sample labels are generated synchronously for subsequent optimization of the upstream model.

[0052] The third step involves executing dynamic strategy orchestration and human-machine collaborative judgment based on business context. Based on the enriched risk event data generated in the first step and the true risk verification results output in the second step, the weight values ​​of the handling strategies are calculated using a context-weighted engine and a pre-set strategy weight calculation model. The calculation formula is:

[0053] ;

[0054] in This serves as the risk indicator for this risk event, with a value of 1.0. This is the asset sensitivity level coefficient, with a value of 1.0 assigned to Level L3 sensitive assets; The business time factor is currently in peak business period, so it is assigned a value of 0.5. The calculated strategy weight value is 0.5. Based on this weight value, the corresponding initial handling strategy is generated. The initial strategy is to roll back the configuration changes of the identity authentication module and restore the two-factor authentication configuration.

[0055] The generated initial handling strategy is conflict-resolved. The system has a preset core business whitelist, which includes the IP range, key business ports and domain names of the medical insurance core business system. The system verifies the target of the initial handling strategy to confirm that it will not cause false interception of core business resources in the whitelist, and there is no need to downgrade the handling strategy.

[0056] Based on preset risk level judgment rules, the initial handling strategy is risk-classified. If the handling strategy involves core configuration modifications to the business system, it is a high-risk operation with a significant risk of business interruption, corresponding to a manual review strategy. The system suspends the automatic execution process and automatically generates a standardized high-risk handling work order. The work order includes details of the risk event, the risk evidence chain, the recommended handling operation, the impact scope assessment, and the recommended rollback configuration version number. It is pushed to the preset asset responsible person and approver through the security management platform, awaiting manual review and handling feedback. If the handling strategy is a lightweight operation that does not affect the core business, such as virtual patch distribution or specific IP rate limiting, it is judged as a low-risk operation, corresponding to an automatic execution strategy, and directly transferred to the automated execution gateway. If the risk verification result is a false risk, or the initial handling strategy cannot be parsed by the system, the handling process is automatically downgraded to a manual review strategy to avoid the handling process being stuck.

[0057] The fourth step is to execute automated operations and distribute policies. For manually reviewed policies, the system receives the execution results from the asset manager. In this embodiment, after receiving the work order, the manager manually verifies that the risk actually exists, performs a configuration rollback during the non-business window, restores the two-factor authentication configuration, and submits the feedback result of the completed disposal in the work order system. For automatically executed policies, the disposal policies are distributed and executed through an automated execution gateway. The automated execution gateway is equipped with a device adaptation layer, an API aggregation gateway, and an atomic capability encapsulation module. The atomic capability encapsulation module encapsulates various disposal operations into standardized atomic instructions. The device adaptation layer shields the interface differences of different security devices such as lower-layer firewalls, WAFs, and switches. The API aggregation gateway converts the standardized disposal policies into API instructions that can be recognized by the corresponding security devices and distributes them. The execution results are verified in real time through API return codes. If the execution times out or fails, it automatically switches to a preset backup execution path to complete the disposal operation. For example, if the WAF blocking execution fails, it automatically switches to the network layer switch to distribute ACL rules to complete the blocking operation.

[0058] The fifth step involves executing closed-loop feedback and model self-evolution. The system uses an effect verification probe to retest the target medical insurance business system after the intervention, following a preset 30-second verification cycle. In this embodiment, the retest results show that the target API interface has restored two-factor authentication, access requests without a token have been blocked, the risk has been eliminated, and a successful effect evaluation result is generated. The asset's security status in the asset knowledge graph is updated to "safe" via the asset status synchronizer. If the risk is not eliminated after the retest, a secondary intervention process is triggered, or the process is upgraded to manual review of the work order. The entire chain of data for this risk event is packaged, including risk characteristic data, risk verification results, intervention strategy content, intervention execution results, and intervention effect evaluation data. This data is written back to the asset knowledge graph and the upstream risk assessment model via a preset API interface. Manual intervention records in the entire chain data are marked as high-risk samples to optimize the model's subsequent risk grading and human-machine collaborative judgment logic. Negative samples corresponding to false risks are used to optimize the model's risk judgment parameters, reducing subsequent false alarms and completing the closed-loop process of risk intervention and the self-evolution of the security protection system.

[0059] This embodiment, through the execution of a complete process, accurately verifies and securely handles high-risk events while ensuring the continuous and stable operation of core medical insurance services. It avoids the impact of automated handling on core operations, achieves rapid risk response and closed-loop management, and continuously optimizes security capabilities through end-to-end data feedback, adapting to the stringent security and business requirements of government cloud scenarios. Although embodiments of this application have been shown and described above, it is understood that these embodiments are exemplary and should not be construed as limiting the application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

Claims

1. A method for verifying simulated attacks based on security agents, characterized in that, Includes the following steps: Step S1: Receive the standardized risk assessment report output from the pre-output through the preset message queue, extract the risk characteristics and asset identification information from the report, query the preset asset knowledge graph using the asset identification as an index, supplement the business context attributes for the risk event, and generate enriched risk event data; Step S2: Based on the risk feature vector in the enriched risk event data, the corresponding PoC script is matched from the pre-set proof-of-concept PoC script library through a preset vector matching algorithm. The security agent executes the matched PoC script in a harmless sandbox environment isolated from the production network. The risk authenticity is verified by using a non-destructive detection and verification mode, and the risk verification result is output. Step S3: Based on the enrichment risk event data and risk verification results, generate an appropriate initial handling strategy through a preset strategy weight calculation model. After conflict resolution processing of the initial handling strategy, classify the handling strategy according to the preset risk level judgment rules. Based on the classification results, the handling strategy is divided into automatic execution strategy or manual review strategy. Step S4: The automated execution gateway performs instruction conversion and execution of automated execution policies, verifies the execution results in real time, and triggers backup execution paths when execution fails. For strategies requiring manual review, standardized processing work orders are automatically generated and pushed to the corresponding responsible persons, and feedback on the processing results is received from the responsible persons; Step S5: Based on the preset verification cycle, retest the target assets after disposal, generate disposal effect evaluation results, package the full-link data of this risk event and feed it back to the preset asset knowledge graph and upstream risk assessment model to complete the closed loop of the entire risk disposal process and optimize the model parameters.

2. The security agent based simulation attack verification method of claim 1, wherein, In step S1, the standardized risk assessment report is in JSON format and includes at least the following fields: risk assessment boolean value, risk identifier Flag, asset ID, weighted risk feature vector, and risk evidence chain. The business context attributes include at least the asset's business continuity level, asset owner information, related business flow information, and current time period business strategy.

3. The security agent based simulation attack verification method of claim 1, wherein, In step S2, the vector matching algorithm uses a cosine similarity calculation algorithm, specifically: Pre-generate a corresponding attack feature vector for each PoC script in the PoC script library. Calculate the weighted risk feature vector in the enrichment risk event data. With each The cosine similarity Sim between them is calculated using the following formula: ； in, This represents the dot product operation of vectors. Represents the L2 norm of a vector; preset similarity threshold. ,when When the threshold is met, the PoC script is matched; when no matching result meets the threshold, the preset large language model LLM is called to generate logic verification pseudocode that has been verified for security, as a temporary verification script.

4. The security agent based simulation attack verification method of claim 1, wherein, In step S2, the harmless sandbox environment and the production network are deployed in a logically isolated manner, allowing only the sandbox to send one-way probe traffic to the target verification asset, and prohibiting reverse data backhaul and access to other assets in the production network; The non-destructive detection and verification mode adopts a probe-rollback mechanism. The security agent only sends a preset feature probe payload and completes risk verification by detecting the feature code of the target asset's return packet. It does not perform destructive operations such as obtaining permissions, reading sensitive data, or modifying system configuration. The risk verification results include true risk results that confirm real risks and false risk results that confirm false alarms. The false risk results simultaneously generate negative sample labels for upstream model optimization.

5. The security agent based simulation attack verification method of claim 1, wherein, In step S3, the calculation formula for the strategy weight calculation model is as follows: ； in, To handle the strategy weight values, This is a risk indicator, with a value ranging from 0 to 1. The higher the value, the higher the risk level. This is the asset sensitivity level coefficient, which is assigned a value according to the asset's preset sensitivity level. This is a business period factor, assigned a value based on the current business period of the asset; based on the calculated... The initial handling strategy is matched to the corresponding level. The higher the strategy weight value, the stronger the control of the handling strategy.

6. The security agent based simulation attack verification method of claim 1, wherein, In step S3, the specific method for resolving conflicts in the initial handling strategy is as follows: a core business whitelist is preset, which includes core business IP ranges, key business ports, and core business domain names; the object to be handled by the initial handling strategy is verified to be in the core business whitelist. If it is, the control intensity of the handling strategy is automatically reduced to avoid affecting the core business.

7. The security agent based simulation attack verification method of claim 1, wherein, In step S3, the preset risk level determination rules are as follows: lightweight handling operations that do not affect the core business logic and have no risk of business interruption are determined as low-risk operations, corresponding to automatic execution strategies. The lightweight handling operations include at least virtual patch distribution, specific IP access rate limiting, and alarm notification sending; handling operations that involve changes to the core business logic and have a significant risk of business interruption are determined as high-risk operations, corresponding to manual review strategies. The high-risk operations include at least business code modification, core service port closure, and network-wide IP access blocking; when the risk verification result is a false risk or the initial handling strategy cannot be parsed, the handling process is automatically downgraded to a manual review strategy.

8. The security agent based simulation attack verification method of claim 1, wherein, In step S4, the automated execution gateway is equipped with a device adaptation layer, an API aggregation gateway, and an atomic capability encapsulation module. The atomic capability encapsulation module encapsulates various handling operations into standardized atomic instructions. The device adaptation layer shields the interface differences of different security devices at the lower layer. The API aggregation gateway converts the standardized handling strategy into API instructions that can be recognized by the corresponding security device and issues them. The execution result verification is completed through API return codes. When the execution times out or fails, it automatically switches to the preset backup execution path to complete the handling operation.

9. The simulated attack verification method based on a secure intelligent agent according to claim 1, characterized in that, In step S5, the disposal effect evaluation results include successful disposal results where the risk has been eliminated and unsuccessful disposal results where the risk has not been eliminated. Successful disposal results synchronously update the asset security status in the asset knowledge graph, while unsuccessful disposal results trigger a secondary disposal process or manual review of the work order. The end-to-end data includes risk characteristic data, risk verification results, disposal strategy content, disposal execution results, and disposal effect evaluation data. The end-to-end data is written back to the asset knowledge graph and upstream risk assessment model through a preset API interface to update the asset risk ledger and optimize the model judgment parameters.

Images