Security verification method and system of cloud platform, electronic device and storage medium

Abstract

This application relates to a security verification method, system, electronic device, and storage medium for a cloud platform. The method includes: applying a security verification system, the security verification system including an attack agent and a defense agent; determining potential attack paths in response to a first security verification task targeting the attack agent; performing simulated attack actions on the cloud platform based on the potential attack paths, generating simulated attack results; and acquiring operation audit logs of the cloud platform in response to a second security verification task targeting the defense agent; after determining that the simulated attack actions meet preset alarm conditions based on the operation audit logs, performing simulated defense actions, generating simulated defense results; and generating a security verification report based on the simulated attack results and the simulated defense results. The solution provided by this application can automatically verify the security of a cloud platform and continuously and accurately reflect the security status of the cloud platform.

Description

Technical Field

[0001] This application relates to the field of cybersecurity technology, and in particular to security verification methods, systems, electronic devices and storage media for cloud platforms. Background Technology

[0002] Cloud computing platforms, also known as cloud platforms, primarily provide computing, networking, and storage capabilities based on hardware and software resources. With the rapid development of cloud computing technology, more and more business systems are migrating to cloud platforms, which have become crucial carriers for enterprise business deployment and data processing. Therefore, higher demands are placed on the security of cloud platforms.

[0003] To ensure cloud platform security, enterprises typically employ a combination of periodic manual penetration testing and static security tools for security verification. Periodic manual penetration testing involves security personnel manually collecting information such as the target cloud environment's asset inventory, network topology, and exposure surfaces. Based on their personal experience and publicly available vulnerability databases, they manually analyze the collected information, outlining potential attack paths and simulating attack processes using relevant testing tools to verify system security. Static security tools, on the other hand, statically scan cloud resource configurations, checking them against predefined compliance standards and matching them with policies in a rule engine to generate a checklist. Simultaneously, a corresponding security information and event management system is deployed to collect cloud platform operation audit logs, network flow logs, and host logs. Based on static rule matching, alerts are generated to notify operations and maintenance personnel, who then manually analyze the data and execute response actions.

[0004] However, the above methods usually rely on manual operation or fixed detection rules, which cannot adapt to the constantly changing characteristics of the cloud environment. This results in a certain lag in the security verification of the cloud platform, making it difficult to continuously and accurately reflect the security status of the cloud platform. Summary of the Invention

[0005] To address or partially address the problems existing in related technologies, this application provides a security verification method, system, electronic device, and storage medium for a cloud platform, which can automatically verify the security of the cloud platform and continuously and accurately reflect the security status of the cloud platform.

[0006] The first aspect of this application provides a security verification method for a cloud platform, applied to a security verification system, the security verification system including an attack agent and a defense agent, the method comprising: In response to a first security verification task targeting the attacking agent, potential attack paths are determined; based on the potential attack paths, simulated attack actions are performed on the cloud platform, generating simulated attack results; and, In response to the second security verification task for the defense agent, the operation audit log of the cloud platform is obtained; after determining that the simulated attack action meets the preset alarm conditions based on the operation audit log, the simulated defense action is executed and the simulated defense result is generated; A security verification report is generated based on the simulated attack results and the simulated defense results.

[0007] In one instance, the first security verification task includes a security verification object, and the step of determining potential attack paths in response to the first security verification task against the attacking agent includes: In response to the first security verification task against the attacking agent, cloud asset information of the cloud platform is obtained; Based on the cloud asset information, a cloud asset relationship graph is constructed; Based on the cloud asset relationship graph, potential attack paths associated with the security verification object are determined.

[0008] In one instance, determining the potential attack path associated with the security verification object based on the cloud asset relationship graph includes: Traverse the cloud asset relationship graph to identify multiple potential vulnerability nodes associated with the security verification object; Based on the attribute information of the potential vulnerable nodes, the attack entry node and the attack target node are determined; The potential attack path is generated based on the attack entry node and the attack target node.

[0009] In one instance, the first security verification task includes a first access permission, and the step of performing a simulated attack on the cloud platform based on the potential attack path and generating a simulated attack result includes: Convert the potential attack paths into corresponding simulated attack action sequences; Under the first access permission, the simulated attack action sequence is executed sequentially to generate a simulated attack log, which is then used as the simulated attack result.

[0010] In one instance, the second security verification task includes a second access permission, the preset alarm conditions include alarm characteristics, and the step of determining whether the simulated attack action meets the preset alarm conditions based on the operation audit log includes: Under the second access permission, the operation audit log is analyzed in real time to obtain the current event characteristics; If the current event characteristic belongs to the alarm characteristic, then the simulated attack action is determined to meet the preset alarm condition.

[0011] In one instance, the second security verification task includes a pre-configured cloud platform defense strategy, wherein executing simulated defense actions and generating simulated defense results includes: Match the simulated defense action sequence corresponding to the alarm feature from the cloud platform defense strategy; The simulated defense action sequence is executed sequentially to generate the simulated defense result.

[0012] In one instance, generating a security verification report based on the simulated attack results and the simulated defense results includes: After aligning the timestamps of the simulated attack results and the simulated defense results, security operation and maintenance metrics are automatically calculated. The security operation and maintenance indicators are filled into the preset template to generate the security verification report; The security verification report is used to update the cloud platform's security knowledge base.

[0013] A second aspect of this application provides a security verification system for a cloud platform, the system comprising: An attack agent is configured to, in response to a first security verification task targeting the attack agent, determine potential attack paths; based on the potential attack paths, perform simulated attack actions against the cloud platform, and generate simulated attack results; and... A defense agent is used to respond to a second security verification task for the defense agent, obtain the operation audit log of the cloud platform; after determining that the simulated attack action meets the preset alarm conditions based on the operation audit log, execute the simulated defense action and generate the simulated defense result; The director agent is used to generate a security verification report based on the simulated attack results and the simulated defense results.

[0014] A third aspect of this application provides an electronic device, comprising: Processor; and A memory that stores executable code, which, when executed by the processor, causes the processor to perform the method described above.

[0015] A fourth aspect of this application provides a computer-readable storage medium having executable code stored thereon, which, when executed by a processor of an electronic device, causes the processor to perform the method described above.

[0016] The fifth aspect of this application provides a computer program product comprising computer instructions that, when executed by a processor, implement the method described above.

[0017] The technical solution provided in this application may include the following beneficial results: In this application, a security verification system is applied, comprising an attack agent and a defense agent. In response to a first security verification task targeting the attack agent, a potential attack path is determined; based on the potential attack path, a simulated attack action is executed on the cloud platform, generating a simulated attack result; and in response to a second security verification task targeting the defense agent, the operation audit log of the cloud platform is obtained; after determining that the simulated attack action meets preset alarm conditions based on the operation audit log, a simulated defense action is executed, generating a simulated defense result; based on the simulated attack result and the simulated defense result, a security verification report is generated. Thus, through collaborative processing between the attack agent and the defense agent, automatic security verification of the cloud platform is achieved. Simultaneously, based on continuously generated simulated attack results and simulated defense results, the security status of the cloud platform is comprehensively evaluated, significantly improving the accuracy of cloud platform security verification.

[0018] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0019] The above and other objects, features and advantages of this application will become more apparent from the more detailed description of exemplary embodiments thereof in conjunction with the accompanying drawings, wherein the same reference numerals generally represent the same components in the exemplary embodiments thereof.

[0020] Figure 1 This is a flowchart illustrating a security verification method for a cloud platform according to an embodiment of this application; Figure 2 This is another flowchart illustrating a security verification method for a cloud platform as shown in an embodiment of this application; Figure 3 This is a schematic diagram of the cloud asset relationship map shown in the embodiments of this application; Figure 4 This is a schematic diagram illustrating a potential attack path as shown in an embodiment of this application; Figure 5 This is a schematic diagram illustrating the principle of rule engine association analysis in an embodiment of this application; Figure 6 This is a schematic diagram illustrating the process of updating a cloud platform using a security verification report, as shown in an embodiment of this application. Figure 7 This is a schematic diagram of the security verification system architecture shown in the embodiments of this application; Figure 8 This is a schematic diagram illustrating the working principle of the security verification system shown in the embodiments of this application; Figure 9 This is a schematic diagram illustrating the structure of a security verification system for a cloud platform according to an embodiment of this application; Figure 10 This is a schematic diagram of the structure of an electronic device shown in an embodiment of this application. Detailed Implementation

[0021] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While embodiments of this application are shown in the drawings, it should be understood that this application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to make this application more thorough and complete, and to fully convey the scope of this application to those skilled in the art.

[0022] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0023] It should be understood that although the terms "first," "second," "third," etc., may be used in this application to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0024] Cloud computing platforms, also known as cloud platforms, primarily provide computing, networking, and storage capabilities based on hardware and software resources. With the rapid development of cloud computing technology, more and more business systems are migrating to cloud platforms, which have become crucial carriers for enterprise business deployment and data processing. Therefore, higher demands are placed on the security of cloud platforms.

[0025] To ensure cloud platform security, enterprises typically employ a combination of periodic manual penetration testing and static security tools for security verification. Periodic manual penetration testing involves security personnel manually collecting information such as the target cloud environment's asset inventory, network topology, and exposure surfaces. Based on their personal experience and publicly available vulnerability databases, they manually analyze the collected information, outlining potential attack paths and simulating attack processes using relevant testing tools to verify system security. Static security tools, on the other hand, statically scan cloud resource configurations, checking them against predefined compliance standards and matching them with policies in a rule engine to generate a checklist. Simultaneously, a corresponding security information and event management system is deployed to collect cloud platform operation audit logs, network flow logs, and host logs. Based on static rule matching, alerts are generated to notify operations and maintenance personnel, who then manually analyze the data and execute response actions.

[0026] However, the above methods usually rely on manual operation or fixed detection rules, which cannot adapt to the constantly changing characteristics of the cloud environment. This results in a certain lag in the security verification of the cloud platform, making it difficult to continuously and accurately reflect the security status of the cloud platform.

[0027] To address the aforementioned issues, this application provides a cloud platform security verification method that can automatically verify the security of a cloud platform and continuously and accurately reflect its security status.

[0028] The technical solutions of the embodiments of this application are described in detail below with reference to the accompanying drawings.

[0029] Figure 1 This is a flowchart illustrating a security verification method for a cloud platform as shown in an embodiment of this application.

[0030] See Figure 1 This method is applied to a security verification system, which includes an attacking agent and a defending agent. The method includes at least the following steps.

[0031] Step 101: In response to the first security verification task for the attacking agent, determine the potential attack path; based on the potential attack path, perform simulated attack actions on the cloud platform and generate simulated attack results.

[0032] During the operation of an enterprise cloud platform, the cloud environment information of the cloud platform often changes continuously. Traditional periodic manual penetration testing and static security scanning tools are difficult to capture the security risks brought about by changes in the cloud environment in real time.

[0033] To mitigate security risks on cloud platforms, this application proposes a security verification system that is a multi-agent verification system deployed in a cloud environment. This system includes at least a director agent, an attack agent, and a defense agent. Each agent perceives the environment, collaborates to complete complex tasks, and makes automatic decisions, achieving functions such as task scheduling, data processing, and result analysis. When a security verification task is received, the director agent in the security verification system can precisely allocate the task based on the types of other agents, scheduling the attack and defense agents to process data in parallel. This optimizes the cloud platform's security verification process from a manually driven, statically configured approach to a system-automated, dynamically verified approach.

[0034] In this embodiment, the director agent assigns the first security verification task to the attack agent. The attack agent receives and responds to the first security verification task, determines at least one potential attack path, performs simulated attack actions on the cloud platform based on the potential attack path, and generates simulated attack results.

[0035] Optionally, the attack agent refers to an agent that simulates an attack on the cloud platform, used to analyze the cloud asset information of the cloud platform based on the first security verification task, determine potential attack paths, and execute simulated attack actions based on the potential attack paths.

[0036] Security verification tasks refer to the tasks of controlling an attacking agent to simulate an attack, and controlling a defending agent to simulate a defense. In this application, security verification tasks are divided into a first security verification task and a second security verification task according to the type of agent.

[0037] The first security verification task instructs the attacking agent to initiate a simulated attack process. This task may include configuration information such as the security verification object, attack target, attack scope, and access permissions for the cloud environment. For example, when performing security verification on an ECS (Elastic Compute Service) instance within a test VPC (Virtual Private Cloud), the security verification object in the first security verification task is the test VPC, the attack target is the ECS instance, and the access permissions are limited to reading cloud asset information and performing security verification operations within the authorized scope.

[0038] A potential attack path refers to an access path determined in a cloud environment based on the relationships between cloud assets and the existing security risks. This path describes the cloud asset nodes that may be traversed during a simulated attack, the security risks that may be exploited, and the simulated attack steps that may be executed. In other words, a potential attack path includes the attack chain that may exist from the attack entry node to the attack target node, such as the access process from the exposed service node to the core database node and the vulnerabilities or configuration defects that may be exploited.

[0039] As an example, when it is detected that the security group rules of the ECS instance allow public network access to the SSH (Secure Shell) service, and the ECS instance has permission to access the database instance, the potential attack path could be a path from the public network access node through the ECS instance to the database instance.

[0040] Simulated attack actions refer to attack operations performed on a cloud platform within the scope of access permissions to verify security risks. Examples include accessing cloud asset information, performing identity authentication operations, or modifying data on the cloud platform.

[0041] It is worth noting that the simulated attack actions in the security verification process of this application will not affect the normal operation of the cloud platform or the original business configuration. The purpose of the simulated attack actions in this application is to verify whether the potential attack path is reachable. If it is reachable, the corresponding security risk is determined. That is, the execution of the simulated attack actions is reversible and traceable. After the security verification is completed, the system can automatically perform change cleanup and state rollback operations to restore the target cloud environment to its original state.

[0042] Simulated attack results refer to the data generated after the attacking agent performs simulated attack actions. This generally includes both successful and failed simulated attack results. If the simulated attack result is successful, it indicates that the potential attack path is reachable, and the cloud platform is at risk of being attacked. If the simulated attack result is failed, it indicates that the potential attack path is unreachable, and the cloud platform is at low risk of being attacked.

[0043] Step 102: In response to the second security verification task for the defense agent, obtain the operation audit log of the cloud platform; after determining that the simulated attack action meets the preset alarm conditions based on the operation audit log, execute the simulated defense action and generate the simulated defense result.

[0044] In this embodiment, while the attack agent in step 101 executes the simulated attack action, the cloud platform can automatically record the corresponding operation behavior of the simulated attack action and generate an operation audit log in real time. The director agent can assign the second security verification task to the defense agent. The defense agent receives and responds to the second security verification task. After determining that the simulated attack action meets the preset alarm conditions based on the obtained operation audit log, the defense agent automatically executes the simulated defense action and generates the corresponding simulated defense result.

[0045] Optionally, the defensive intelligent agent refers to the intelligent agent that performs simulated defense when the cloud platform is subjected to simulated attacks, and is used to monitor, analyze and respond to operational behaviors in the cloud platform according to the second security verification task.

[0046] The second security verification task is used to instruct the defense agent to start a simulated defense process. The second security verification task may include pre-configured cloud platform defense policies, cloud environment access permissions, and other task configuration information.

[0047] In this application, the operation audit log is a service provided by the cloud platform that records all operations performed by users and APIs (Application Programming Interfaces) on cloud resources. The operation audit log serves as the primary data source for defending against intelligent agent monitoring attacks. In this application, the operation audit log includes operation time, operator information, operating device information, operation type, and operation result, thereby recording information such as cloud resource creation, configuration changes, and login authentication.

[0048] The system uses preset alarm conditions to determine if a simulated attack action falls under a preset attack behavior or mode. When the operation audit log triggers an alarm condition, the simulated attack action is deemed to meet the preset alarm conditions, and the corresponding simulated defense action is executed. For example, for an SSH brute-force attack scenario, the preset alarm condition could be: within a preset time range, the same source address generates more than a preset number of SSH login failure events, or a login success event occurs after consecutive login failure events. When the defense agent detects the above events based on the operation audit log, it determines that the simulated attack action meets the preset alarm conditions.

[0049] Simulated defense actions refer to defensive operations performed according to pre-configured cloud platform defense policies to block, restrict, or reduce the impact of simulated attacks. Examples include adding access control rules, adjusting security group rules, isolating cloud resources, and prohibiting attackers from accessing the cloud platform.

[0050] Simulated defense results refer to the response data after the defense agent performs simulated defense actions, which may include the results of successfully blocking simulated attack actions and the results of failing to block simulated attack actions.

[0051] In this application, steps 101 and 102 can be executed in parallel by an attack agent and a defense agent. The attack agent determines potential attack paths based on the first security verification task and executes simulated attack actions. The defense agent, based on the second security verification task, obtains operation audit logs generated by the cloud platform in real time, analyzes the operation audit logs, and executes simulated defense actions based on the analysis results. Since the execution of simulated attack actions triggers the generation of corresponding operation audit logs by the cloud platform, steps 101 and 102 are linked through these operation audit logs, which helps reduce the uncertainty of false positives or false negatives.

[0052] Step 103: Generate a security verification report based on the simulated attack results and simulated defense results.

[0053] In this embodiment of the application, after obtaining the simulated attack results and simulated defense results, the security verification system can further perform correlation analysis on the simulated attack results and simulated defense results to determine the correspondence and difference information between the simulated attack process and the simulated defense process, and generate a security verification report based on the analysis results.

[0054] Optionally, a security verification report refers to a complete test report that includes an execution summary, detailed findings, quantitative indicators, and specific recommendations, which can characterize the cloud platform's overall security protection capabilities against simulated attack actions.

[0055] In this embodiment, a security verification system is applied, comprising an attack agent and a defense agent. In response to a first security verification task targeting the attack agent, a potential attack path is determined. Based on the potential attack path, a simulated attack is performed on the cloud platform, generating a simulated attack result. In response to a second security verification task targeting the defense agent, the operation audit logs of the cloud platform are obtained. After determining that the simulated attack meets preset alarm conditions based on the operation audit logs, a simulated defense action is performed, generating a simulated defense result. Based on the simulated attack and defense results, a security verification report is generated. Thus, through collaborative processing between the attack agent and the defense agent, automatic security verification of the cloud platform is achieved. Simultaneously, based on continuously generated simulated attack and defense results, the security status of the cloud platform is comprehensively evaluated, significantly improving the accuracy of cloud platform security verification.

[0056] Figure 2 This is another flowchart illustrating a security verification method for a cloud platform as shown in an embodiment of this application. Figure 2 relatively Figure 1 The technical solutions of the embodiments of this application are described in more detail.

[0057] Step 201: In response to the first security verification task against the attacking agent, obtain cloud asset information of the cloud platform.

[0058] In this embodiment, the director agent can initiate drills periodically or irregularly to assign a first security verification task to the attack agent. The first security verification task includes a security verification object and a first access permission, thereby calling the interface of the cloud platform adaptation layer according to the first access permission to obtain cloud asset information.

[0059] For example, conduct attack and defense drills regularly (such as daily, weekly, or monthly) on the same VPC, and conduct attack and defense drills regularly on different VPCs.

[0060] Cloud asset information includes cloud assets and the relationships between them.

[0061] Cloud assets refer to cloud resources deployed in a cloud environment, such as VPCs, ECS instances, databases, security group information, access control policies, user information, etc.

[0062] The relationships between cloud assets can include network connectivity, ownership, data access, and other configuration relationships.

[0063] As an example, Company A's cloud platform includes a test VPC and ECS instances deployed in the test VPC. The attacking agent calls the interface of the cloud platform adaptation layer according to the first access permission, and obtains the cloud asset information corresponding to the test VPC through the interface of the cloud platform adaptation layer. The cloud asset information includes VPC identification information, ECS instance information, security group configuration and access control policies. At the same time, it obtains the ownership relationship between the ECS instance and the VPC, and the access control relationship between the ECS instance and the security group.

[0064] Step 202: Construct a cloud asset relationship graph based on cloud asset information.

[0065] In this embodiment of the application, after obtaining cloud asset information, the cloud asset nodes and the relationships between cloud assets are extracted by parsing the cloud asset information, and a cloud asset relationship graph is constructed based on the cloud asset nodes and relationships.

[0066] Furthermore, the attacking agent can identify the attribute information of cloud assets, map each cloud asset to a cloud asset node, and establish connection edges between cloud asset nodes based on the relationships between cloud assets, thereby generating a cloud asset relationship graph and storing it in a graph database.

[0067] As an example, in constructing a cloud asset relationship graph, firstly, a blank graph data structure is created, and then the parsed cloud asset information is traversed. For each cloud asset, the attack agent creates a corresponding cloud asset node, assigns a unique node identifier to the node, and stores the extracted attribute information in the node's attribute dictionary. Next, the attack agent analyzes the relationships between cloud assets. For each pair of related cloud assets, a connecting edge is created between the two corresponding cloud asset nodes, assigns an edge identifier to the connecting edge, and stores the type and parameters of the relationship in the edge's attribute dictionary. Finally, the cloud asset relationship graph is stored in the Neo4j graph database, which supports efficient graph traversal queries and path search algorithms.

[0068] Step 203: Based on the cloud asset relationship graph, determine the potential attack paths associated with the security verification object.

[0069] In this embodiment, after constructing a cloud asset relationship graph, the attack agent determines potential attack paths associated with the security verification object based on the graph. This process includes traversing the cloud asset relationship graph to identify multiple potential vulnerability nodes associated with the security verification object, determining attack entry nodes and attack target nodes based on the attribute information of these nodes, and generating potential attack paths based on the attack entry nodes and attack target nodes.

[0070] In fact, the attack agent of this application has a built-in security verification strategy, which includes a security rule base of hundreds of rules and a graph search algorithm. The security rule base is mainly used to identify configuration defects or security risks in cloud asset nodes. For example, the rule in the security rule base is to check whether the security group has opened port 22 for 0.0.0.0 / 0. The graph search algorithm can be a breadth-first search algorithm. In this way, the cloud asset relationship graph is traversed according to the security verification strategy and the graph search algorithm to determine the potential vulnerable nodes associated with the security verification object.

[0071] After obtaining multiple potentially vulnerable nodes, the attack entry point and target nodes are determined based on their attribute information. Other potentially vulnerable nodes are used as intermediate attack nodes, and at least one potential attack path is generated based on the relationships between the nodes. For example, if the security verification object is the "core database," all paths from the "public network" node to the "core database" node are automatically identified, and each path is a potential attack path. Furthermore, this application can also sort the potential attack paths according to risk score or path length.

[0072] Among them, the attack entry point node can be a cloud asset node that the attacker first accesses or initially visits in the cloud environment, such as a public network node, an instance node exposed to the outside world, or a service node with open access permissions.

[0073] The target node for the attack is the cloud asset node corresponding to the security verification object, which is the target of this security verification.

[0074] As an example, Company A deployed a dedicated test VPC containing one ECS instance and one RDS (Relational Database Service) instance. The attacking agent, through steps 201 and 202, has constructed a cloud asset relationship graph for this VPC and stored it in the Neo4j graph database. The first security verification task issued by the director agent to the attacking agent targets the RDS instance. The attacking agent loads a built-in security verification policy, whose rule base includes hundreds of rules such as rule R1 (checking if the security group has port 22 open for 0.0.0.0 / 0), rule R2 (checking if the ECS instance's operating system uses a weak password), and rule R3 (checking if the RDS instance allows public network access).

[0075] The attack agent traversed the cloud asset relationship graph and detected a configuration risk in the security group bound to the ECS instance in the test VPC, which allowed 0.0.0.0 / 0 to access port 22. Furthermore, the ECS instance had access to the RDS instance. Therefore, the ECS instance node associated with the security group was identified as a potentially vulnerable node. Simultaneously, since the initial accessed cloud asset node was a public network node, this public network node was identified as the attack entry point node, the RDS instance node as the attack target node, and the ECS instance node as the attack intermediate node.

[0076] The attacking agent uses a breadth-first search algorithm to search for reachable paths in the cloud asset relationship graph, generating potential attack paths.

[0077] As another example, by modeling cloud assets and their relationships as a graph structure, the complex cloud environment can be visually represented. More importantly, the graph search algorithm can automatically discover the complete attack path from the attack entry point (public network) to the critical target (core database), which is the technical basis for automated attack path planning.

[0078] refer to Figure 3 , Figure 3 This is a schematic diagram of the cloud asset relationship graph shown in an embodiment of this application. Assume that enterprise A has deployed a dedicated test VPC. Based on step 201, the attacking agent obtains multiple cloud asset nodes, including a public network node, security group A, ECS instance A, RAM user X, Access Key AK-X, metadata service, RAM role R, OSS bucket Y, and the core database. Based on step 202, the attacking agent constructs the cloud asset relationship graph of the VPC from each cloud asset node and their associated relationships, and stores it in the Neo4j graph database.

[0079] refer to Figure 4 , Figure 4This is a schematic diagram of potential attack paths illustrated in an embodiment of this application. Based on the aforementioned step 203, the attacking agent obtains two potential attack paths. Path 1 (External Penetration >> Privilege Escalation >> Data Theft): Public network node → Security group A → ECS instance A → RAM user X → OSS storage bucket Y → Core database. That is, the attacker first compromises ECS instance A, finds the plaintext configuration of RAM user X's AccessKey on the instance, uses this AccessKey to access OSS storage bucket Y, and finally steals the database backup. Path 2 (Lateral Movement >> Role Hijacking >> Data Theft): Public network node → Security group A → ECS instance A → RAM role R → OSS storage bucket Y → Core database. That is, after the attacker compromises ECS instance A, they access the metadata service to steal the temporary credentials of RAM role R associated with the instance, use these role credentials to directly access OSS storage bucket Y, and finally steal the database backup.

[0080] Step 204: Based on potential attack paths, perform simulated attack actions on the cloud platform and generate simulated attack results.

[0081] In this embodiment of the application, the attack agent converts the potential attack path into a corresponding simulated attack action sequence according to the potential attack path determined in step 203, and executes the simulated attack action sequence sequentially within the scope of the first access permission to verify whether the potential attack path can be implemented in the actual cloud environment, and generates a simulated attack log, which is used as the simulated attack result.

[0082] The process of converting potential attack paths into corresponding simulated attack action sequences involves determining attack steps based on the node order and relationships between nodes in the potential attack path, and configuring corresponding attack parameters and tools for each attack step to obtain a simulated attack sequence. For example, for the attack step of "SSH weak password brute-force," the attack agent can be configured with a dictionary containing common weak passwords as attack parameters and a custom script as an attack tool.

[0083] The attacking agent arranges the attack steps according to the node order of the potential attack path to form a simulated attack action sequence. Under the first access permission, it completes the entire simulated attack action sequence, generates a simulated attack log, and uses it as the simulated attack result.

[0084] Among them, the first access permission can be the RAM (Random Access Memory) credentials allocated by the director agent to the attack agent through the cloud platform adaptation layer during the initialization phase.

[0085] The simulated attack log includes the execution time, attack parameters, response data, and success / failure determination results for each attack step. In this application, the system records key log information generated during the simulated attack process, such as attack time, attack source IP, executed operations, attack parameters, and corresponding response results, to achieve precise tracking and correlation analysis of the entire attack process. This allows for accurate determination of whether the attack behavior has been identified by the defense agent and triggered an alarm. Furthermore, the system can determine the actual occurrence time of the simulated attack action based on the simulated attack log and correlate this time with the time when the defense agent subsequently generates an alarm to obtain the time difference between the attack occurrence and alarm triggering. This allows for the calculation of security operation and maintenance indicators such as average detection time and response efficiency. Simultaneously, the attack agent converts the simulated attack results into simulated operation event objects conforming to the cloud platform log format and sends them to the cloud platform via a message queue, thereby simulating the log data generated by a real attack for real-time monitoring and analysis by the defense agent.

[0086] Step 205: In response to the second security verification task for the defensive agent, obtain the operation audit logs of the cloud platform.

[0087] In this embodiment, when the director agent starts the exercise, it simultaneously sends a second security verification task to the defense agent. The defense agent responds to the second security verification task and obtains the operation audit log of the cloud platform. This process runs in parallel with the simulated attack phase of the attack agent, forming a real-time closed loop of attack and defense confrontation.

[0088] After receiving the second security verification task, the defense agent pulls the operation audit logs of the cloud platform in real time through the cloud platform adaptation layer and converts them into a standardized event stream. The conversion process includes field extraction, format unification and semantic annotation of the operation audit logs.

[0089] Step 206: After determining that the simulated attack action meets the preset alarm conditions based on the operation audit log, execute the simulated defense action and generate the simulated defense result.

[0090] The second security verification task should include at least the cloud platform defense strategy and the cloud platform's second access permissions.

[0091] Among them, the cloud platform defense strategy is a set of pre-configured response scripts, which defines corresponding simulated defense action sequences for different alarm types.

[0092] The second access permission is the RAM credential allocated by the director agent to the defense agent through the cloud platform adaptation layer. This credential has the permission to read the operation audit logs of the cloud platform. The defense agent can only obtain log data through this permission and cannot modify the configuration information of cloud resources.

[0093] The defensive intelligent agent of this application can perform real-time analysis of operation audit logs under second access permissions to obtain current event characteristics. If the current event characteristics belong to alarm characteristics, it is determined that the simulated attack action meets the preset alarm conditions, and the simulated defense action sequence corresponding to the alarm characteristics is matched from the cloud platform defense strategy, and the simulated defense action sequence is executed in sequence to generate simulated defense results.

[0094] The current event characteristics are a set of features that can be extracted from a standardized event stream. For example, for an SSH login verification action performed by an attacking agent, the defending agent extracts features from the operation audit log, such as cloud resource information, operation type, number of failures, and login verification result, which are dependent on the SSH login verification action.

[0095] Furthermore, different types of attack behaviors can correspond to different alarm characteristics. For example, alarm characteristics corresponding to SSH brute-force attack detection behavior may include characteristic ① the operation type is SSH login, characteristic ② the same source IP address, characteristic ③ the operation time is within a preset time window, and characteristic ④ the number of login failures exceeds a preset threshold. As another example, alarm characteristics corresponding to unauthorized access to the public network may include characteristic ① the access source is a public network address, characteristic ② the cloud resource information is internal cloud resources, and characteristic ③ the access permission exceeds the configured permissions.

[0096] Finally, the current event characteristics are compared with the alarm characteristics one by one. When the current event characteristics and alarm characteristics are all consistent, it is determined that the simulated attack action meets the preset alarm conditions. An alarm object is generated through the rule engine, and the simulated defense action sequence corresponding to the alarm object is matched from the cloud platform defense strategy. The simulated defense action sequence is executed in sequence to generate the simulated defense result.

[0097] As an example, see reference Figure 5 , Figure 5 This is a schematic diagram illustrating the rule engine correlation analysis principle in an embodiment of this application. It mainly includes three parts: the original event stream (time sequence), rule library examples, and generated alerts. Two detection rules are defined using the rule engine language: one detects SSH brute-force attacks, and the other detects privilege escalation attack paths. The rule engine can match the original event stream with the rules in real time. When the event sequence meets the rule conditions (such as the same IP successfully logging in after multiple failed SSH attempts within 5 minutes), the rule engine will trigger the generation of an alert. For example, the rule engine in the defense agent internally maintains an alert feature library corresponding to preset alert conditions and can continuously receive log events by calling the corresponding interface of the cloud platform adaptation layer. When a login event flows in, the rule engine caches the events of that IP for the past 5 minutes. Once a pattern of "failure count >= 3 and one successful login" is matched, the rule immediately triggers the generation of an alert object.

[0098] The defense agent is triggered by a pre-defined response script, which defines a simulated defense action sequence against "SSH brute-force attacks." The primary action of this simulated defense action sequence is to "block the attacking IP." The defense agent then calls the corresponding interface in the cloud platform's adaptation layer, using credentials with write permissions for the security group, to add a blocking rule, thus achieving automated interception.

[0099] Step 207: Generate a security verification report based on the simulated attack results and simulated defense results.

[0100] In this embodiment, the director agent can automatically calculate security operation and maintenance indicators after aligning the timestamps of the simulated attack results and simulated defense results, fill the security operation and maintenance indicators into a preset template, and generate a security verification report.

[0101] For example, the timestamp of successful SSH login recorded by the attacking agent is aligned with the timestamp of alarm generation recorded by the defending agent, and the defense response delay is calculated to be 5 seconds.

[0102] Among them, security operation and maintenance metrics are used to evaluate the security detection and defense response capabilities of the cloud platform, including but not limited to quantitative indicators such as attack success rate, defense detection rate, and average response time. For example, if a simulated attack sequence contains 10 attack steps, and 7 steps are successfully executed while 3 steps fail because the target configuration has been patched, the calculated attack success rate is 70%. The attack success rate reflects the density of security vulnerabilities in the current cloud platform; a higher success rate indicates a greater security risk. Alternatively, if the attack agent executes simulated attack actions corresponding to 5 potential attack paths, and the defense agent identifies 4 of them through alerts, the defense detection rate is 80%. The defense detection rate reflects the cloud platform's ability to cover known and unknown attack patterns; a higher detection rate indicates a more robust defense system.

[0103] Meanwhile, the director agent can also generate suggestions for adding new detection rules based on the differences between successful but undetected attacks, or generate suggestions for removing outdated attack modes based on the results of failed attacks (such as outdated attack modes failing because the target configuration has been fixed).

[0104] The preset template refers to the report format for organizing simulated attack and defense results, including four parts: execution summary, detailed findings, quantitative indicators, and specific recommendations. In this application, the preset template supports customization and expansion, allowing enterprises to add, delete, or modify it according to their actual needs.

[0105] Security verification reports are used to update the security knowledge base of the cloud platform. Successful attack patterns can be abstracted and stored in the attack pattern library. The weights or confidence levels in the rule base are updated based on the hit situation. Optimization suggestions are submitted to security personnel for review and then formally added to the rule base, thereby driving the continuous evolution of the next round of drills.

[0106] For example, if an attacking agent fails to access a storage bucket path due to a misconfiguration because the relevant configuration has been fixed, it can be recommended to remove this outdated attack pattern from the knowledge base. As another example, if a defending agent successfully intrudes using method X but goes undetected, with the log pattern being [Event A >> Event B], it can be recommended to add or adjust a related rule. This new rule should be submitted to security experts for analysis first, and then formally added to the cloud platform's defense strategy after confirmation.

[0107] As an example, see reference Figure 6 , Figure 6 This is a schematic diagram illustrating the process of updating a cloud platform using a security verification report, as shown in an embodiment of this application. The complete closed-loop process from automated attack and defense drills to continuous improvement of security capabilities includes: execution of automated attack and defense drills, generation of drill reports and evolution suggestions, review and confirmation by security experts, updating of the knowledge base, and use of the evolved knowledge base in the next drill.

[0108] This process ensures the efficient operation of the automated system while incorporating the experience and judgment of security experts, enabling the continuous and reliable evolution of security capabilities. In other words, it transforms known methods into evolvable automated detection capabilities by relying on a large amount of data, rule engines, statistical analysis, and human-machine collaboration.

[0109] To facilitate understanding of the security verification method in the embodiments of this application, the security verification system in the embodiments of this application will be described in detail below.

[0110] refer to Figure 7 , Figure 7 This is a schematic diagram of the security verification system architecture shown in the embodiments of this application.

[0111] In this application, the security verification system adopts a layered modular architecture and defines the roles, goals, tasks, and collaborative processes between agents through CrewAI (Multi-Agent Collaboration Framework).

[0112] At the top layer is the director's intelligent agent, which is responsible for overall coordination, including the rehearsal choreography engine, the debriefing analysis engine, and the evolution management engine.

[0113] The middle layer consists of attack agents, defense agents, and a knowledge base module. Attack agents and defense agents are core execution units that simulate attacks and defenses, while the knowledge base module stores all data and rules.

[0114] The cloud platform adaptation layer is an external service and tool integration layer. It needs to provide a unified adapter module for different types of interfaces (REST API, RPC, CLI parser). It encapsulates and abstracts the API differences with different cloud vendors, enabling the system to be compatible with mainstream cloud environments. At the same time, it encapsulates the details of various security tool interfaces and log platform APIs, providing a unified calling interface to the upper level.

[0115] It is understandable that in practical applications, the number and type of intelligent agents can be set as needed. For example, attacking intelligent agents can be further divided into reconnaissance intelligent agents, analysis intelligent agents, planning intelligent agents, and execution intelligent agents, while defense intelligent agents can be further divided into monitoring intelligent agents, correlation analysis intelligent agents, and response intelligent agents.

[0116] refer to Figure 8 , Figure 8 This is a schematic diagram illustrating the working principle of the security verification system shown in the embodiments of this application.

[0117] 1) Initialize the director agent.

[0118] The director agent loads the exercise orchestration configuration file, sets the exercise target scope, and assigns security verification tasks and cloud environment access permissions to the attacking and defending agents.

[0119] 2) The reconnaissance phase of attacking intelligent agents.

[0120] The attacking agent calls the cloud platform API to list all cloud assets, constructs a cloud asset relationship graph, and stores it in the Neo4j graph database.

[0121] 3) Attack agent analysis phase.

[0122] The attacking agent loads the security rule base and traverses the graph to mark potential vulnerability nodes.

[0123] 4) Attack agent planning phase.

[0124] The attacking agent runs a graph search algorithm on the graph to search for a path from the attack entry point to the attack target and generate attack steps.

[0125] 5) The attacking agent performs simulated attack actions and the defending agent performs simulated defense actions.

[0126] The attacking agent executes simulated attack actions sequentially according to the attack steps, generates a simulated attack log, and records the attack results.

[0127] The defense agent collects operation audit logs in real time. The defense agent analyzes the logs, matches rules, triggers alarms, and performs simulated defense actions such as blocking through the rule engine.

[0128] 6) Director's AI agent debriefing analysis.

[0129] Compare attack and detection logs to calculate metrics such as success rate, detection rate, and response time.

[0130] 7) Generate reports and evolutionary recommendations.

[0131] Output security hardening suggestions and rule optimization solutions, update the knowledge base after expert confirmation, and drive the next round of exercise cycle.

[0132] Taking SSH weak password attacks as an example, the scenario settings include the target cloud environment, target cloud resources, preset vulnerabilities, and security verification targets.

[0133] The target cloud environment includes the type of cloud platform and its region.

[0134] The target cloud resource is set up as a dedicated test VPC, which contains one ECS instance i-test001.

[0135] The default vulnerabilities include configuration errors: the security group associated with this ECS instance has an inbound rule that allows any source IP (0.0.0.0 / 0) to access TCP port 22 (SSH service), and weak password risks: the operating system of this ECS instance uses the extremely weak password root / 123456.

[0136] The goal of the security verification is to demonstrate how the security verification system can automatically discover this configuration vulnerability, plan and execute an attack, verify the automated detection and response capabilities of the defense agent, and ultimately generate actionable remediation recommendations.

[0137] S1. The director agent loads the exercise orchestration configuration file for the test VPC, and assigns settings such as RAM credentials with "read-only" permissions for the VPC to the attack agent by calling the corresponding interface of the cloud platform adaptation layer, and assigns settings such as permissions to the defense agent to read ActionTrail logs.

[0138] S2. The attack agent invokes the Python SDK of the cloud platform adaptation layer to initiate API calls sequentially. It not only discovers the target ECS instance and its associated security group ID through DescribeInstances and obtains basic security group information through DescribeSecurityGroups, but also obtains detailed information on security group rules through the DescribeSecurityGroupAttribute API, providing data for building an accurate security map.

[0139] S3, rules such as "The security group should restrict public network access to the ssh (22) port" loaded by the attacking agent in the security rule base.

[0140] S4. The attacking agent executes a Cypher-like query in Neo4j, which automatically finds the attack path.

[0141] S5. Under full authorization, the attacking agent makes genuine security verification requests (by calling the corresponding interface of the cloud platform adaptation layer to attempt SSH authentication) and determines the success or failure of the attack steps based on the target's actual response. Each attack records a "failure" or "success" result locally: for example, when attempting root / 123456, it records "success" and calls the corresponding interface of the "cloud platform adaptation layer" to generate a simulated LoginInstance event object conforming to the ActionTrail log format, which is then sent via a message queue to simulate logs generated by a real attack.

[0142] S6. The defense agent pulls logs from the specified ActionTrail project by calling the SDK of the cloud platform adaptation layer. The rule engine in the defense agent continuously receives these log events by calling the corresponding interface of the cloud platform adaptation layer. When a LoginInstance event flows in, the rule engine caches the events of that IP for the past 5 minutes. Once the pattern of "failure count >= 2 and one success" is matched, the rule is immediately triggered, and an alert object is generated.

[0143] S7. The pre-defined response script of the defense agent is triggered. It defines a simulated defense action sequence for the "SSH brute-force attack" alert: the primary action is "block the attacking IP". The agent then calls the corresponding interface of the "cloud platform adaptation layer", uses credentials with security group write permissions to call the AuthorizeSecurityGroup API, adds a blocking rule, and realizes automated blocking.

[0144] S8, the director agent acts as both referee and analyst, collecting all logs and action records from the message bus or database of both attacking and defending agents. It automatically calculates key security operation and maintenance metrics through timestamp alignment. The report generator populates this data into a pre-set template, generating a complete test report containing four parts: execution summary, detailed findings, quantitative metrics, and specific recommendations.

[0145] S9. The evolution management engine of the director agent analyzes the security verification data: attack patterns are abstracted and stored in the attack pattern library. The hit of a detection rule increases its weight or confidence in the rule library, and the system may also automatically generate a new, more granular rule suggestion (such as increasing the alert level for brute-force attacks against the root user) as an output optimization suggestion, which is finally reviewed and confirmed by security experts.

[0146] S10. After the exercise, generate a security verification report and update the knowledge base.

[0147] It should be noted that this embodiment only uses SSH weak password attacks as an example. In actual applications, the security verification system can expand the attack pattern library and detection rule library to cover various attack scenarios such as SQL (Structured Query Language) injection, Log4j (Logging for Java) vulnerability exploitation, and cloud credential theft, thereby improving the security verification system's adaptability to security risks in different cloud environments.

[0148] In this embodiment, a security verification system is applied, comprising an attack agent and a defense agent. In response to a first security verification task targeting the attack agent, the system acquires cloud asset information of the cloud platform; constructs a cloud asset relationship graph based on the cloud asset information; determines potential attack paths associated with the security verification object based on the cloud asset relationship graph; performs simulated attack actions on the cloud platform based on the potential attack paths, generating simulated attack results; and, in response to a second security verification task targeting the defense agent, acquires the operation audit logs of the cloud platform; after determining that the simulated attack actions meet preset alarm conditions based on the operation audit logs, performs simulated defense actions, generating simulated defense results; and generates a security verification report based on the simulated attack results and simulated defense results. Thus, through collaborative processing between the attack agent and the defense agent, automatic security verification of the cloud platform is achieved. Simultaneously, based on continuously generated simulated attack results and simulated defense results, the security status of the cloud platform is comprehensively evaluated, significantly improving the accuracy of cloud platform security verification.

[0149] Corresponding to the aforementioned application function implementation method embodiments, this application also provides a cloud platform security verification device, electronic device, and corresponding embodiments.

[0150] Figure 9 This is a schematic diagram of the structure of a security verification system for a cloud platform, as shown in an embodiment of this application.

[0151] See Figure 9 A security verification system for a cloud platform, the system comprising: Attacking agent 901 is used to respond to the first security verification task targeting the attacking agent, determine potential attack paths, execute simulated attack actions on the cloud platform based on the potential attack paths, and generate simulated attack results; and, Defense agent 902 is used to respond to the second security verification task for the defense agent, obtain the operation audit log of the cloud platform; after determining that the simulated attack action meets the preset alarm conditions based on the operation audit log, it executes the simulated defense action and generates the simulated defense result; Director agent 903 is used to generate a security verification report based on the results of simulated attacks and simulated defenses.

[0152] As an optional example of an embodiment of this application, the first security verification task includes a security verification object, and the attacking intelligent agent 901 includes: The cloud asset information acquisition unit is used to acquire cloud asset information of the cloud platform in response to the first security verification task against the attacking agent. The graph construction unit is used to construct a cloud asset relationship graph based on cloud asset information; The potential attack path determination unit is used to determine the potential attack paths associated with the security verification object based on the cloud asset relationship graph.

[0153] As an optional example of an embodiment of this application, the potential attack path determination unit is used for: Traverse the cloud asset relationship graph to identify multiple potential vulnerability nodes associated with the security verification object; Based on the attribute information of potentially vulnerable nodes, determine the attack entry point node and the attack target node; Based on the attack entry node and the attack target node, potential attack paths are generated.

[0154] As an optional example of an embodiment of this application, the first security verification task includes a first access permission, and the attack agent 901 is used for: Convert potential attack paths into corresponding simulated attack action sequences; Under first access privileges, execute the sequence of simulated attack actions in sequence, generate simulated attack logs, and use the simulated attack logs as the results of the simulated attack.

[0155] As an optional example of an embodiment of this application, the second security verification task includes a second access permission, the preset alarm conditions include alarm features, and the defense agent 902 is used for: Under the second access permission, the operation audit log is analyzed in real time to obtain the characteristics of the current event; If the current event characteristics are alarm characteristics, then the simulated attack action is determined to meet the preset alarm conditions.

[0156] As an optional example of an embodiment of this application, the second security verification task includes a pre-configured cloud platform defense strategy, and the defense agent 902 is used for: Match simulated defense action sequences corresponding to alarm features from cloud platform defense strategies; The simulated defense action sequence is executed sequentially to generate the simulated defense result.

[0157] As an optional example of an embodiment of this application, the director intelligent agent 903 is used for: After aligning the timestamps of the simulated attack results and simulated defense results, security operation and maintenance metrics are automatically calculated. Fill the security operation and maintenance indicators into the preset template to generate a security verification report; Among them, the security verification report is used to update the cloud platform's security knowledge base.

[0158] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated further here.

[0159] Figure 10 This is a schematic diagram of the structure of an electronic device shown in an embodiment of this application.

[0160] See Figure 10 The electronic device 1000 includes a memory 1010 and a processor 1020.

[0161] The processor 1020 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor. Memory 1010 may include various types of storage units, such as system memory, read-only memory (ROM), and permanent storage devices. ROM may store static data or instructions required by processor 1020 or other modules of the computer. Permanent storage devices may be read-write storage devices. Permanent storage devices may be non-volatile storage devices that retain stored instructions and data even when the computer is powered off. In some embodiments, permanent storage devices use mass storage devices (e.g., magnetic or optical disks, flash memory) as permanent storage devices. In other embodiments, permanent storage devices may be removable storage devices (e.g., floppy disks, optical drives). System memory may be a read-write storage device or a volatile read-write storage device, such as dynamic random access memory. System memory may store some or all of the instructions and data required by the processor during operation. Furthermore, memory 1010 may include any combination of computer-readable storage media, including various types of semiconductor memory chips (e.g., DRAM, SRAM, SDRAM, flash memory, programmable read-only memory), and disks and / or optical disks may also be used. In some embodiments, memory 1010 may include a removable storage device that is readable and / or writable, such as a laser disc (CD), a read-only digital multifunction optical disc (e.g., DVD-ROM, dual-layer DVD-ROM), a read-only Blu-ray disc, an ultra-high density optical disc, a flash memory card (e.g., SD card, mini SD card, Micro-SD card, etc.), a magnetic floppy disk, etc. Computer-readable storage media do not contain carrier waves or transient electronic signals transmitted wirelessly or via wired connections.

[0162] The memory 1010 stores executable code, which, when processed by the processor 1020, can cause the processor 1020 to execute part or all of the methods described above.

[0163] Furthermore, the method according to this application can also be implemented as a computer program or computer program product, which includes computer program code instructions for performing some or all of the steps in the method described above.

[0164] Alternatively, this application may be implemented as a computer-readable storage medium (or a non-transitory machine-readable storage medium or a machine-readable storage medium) storing executable code (or computer program or computer instruction code) that, when executed by a processor of an electronic device (or server, etc.), causes the processor to perform part or all of the steps of the methods described above according to this application.

[0165] This application also provides a computer program product, which includes computer instructions that, when executed by a processor, implement the method described above.

[0166] The various embodiments of this application have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A security verification method for a cloud platform, characterized in that, Applied to a security verification system, the security verification system including an attack agent and a defense agent, the method includes: In response to a first security verification task targeting the attacking agent, potential attack paths are determined; based on the potential attack paths, simulated attack actions are performed on the cloud platform, generating simulated attack results; and, In response to the second security verification task for the defense agent, the operation audit log of the cloud platform is obtained; after determining that the simulated attack action meets the preset alarm conditions based on the operation audit log, the simulated defense action is executed and the simulated defense result is generated; A security verification report is generated based on the simulated attack results and the simulated defense results.

2. The method according to claim 1, characterized in that, The first security verification task includes a security verification object, and the step of determining potential attack paths in response to the first security verification task against the attacking agent includes: In response to the first security verification task against the attacking agent, cloud asset information of the cloud platform is obtained; Based on the cloud asset information, a cloud asset relationship graph is constructed; Based on the cloud asset relationship graph, potential attack paths associated with the security verification object are determined.

3. The method according to claim 2, characterized in that, The step of determining the potential attack path associated with the security verification object based on the cloud asset relationship graph includes: Traverse the cloud asset relationship graph to identify multiple potential vulnerability nodes associated with the security verification object; Based on the attribute information of the potential vulnerable nodes, the attack entry node and the attack target node are determined; The potential attack path is generated based on the attack entry node and the attack target node.

4. The method according to claim 1, characterized in that, The first security verification task includes first access permissions. The step of performing simulated attack actions on the cloud platform based on the potential attack path and generating simulated attack results includes: Convert the potential attack paths into corresponding simulated attack action sequences; Under the first access permission, the simulated attack action sequence is executed sequentially to generate a simulated attack log, which is then used as the simulated attack result.

5. The method according to claim 1, characterized in that, The second security verification task includes a second access permission, the preset alarm conditions include alarm characteristics, and the step of determining whether the simulated attack action meets the preset alarm conditions based on the operation audit log includes: Under the second access permission, the operation audit log is analyzed in real time to obtain the current event characteristics; If the current event characteristic belongs to the alarm characteristic, then the simulated attack action is determined to meet the preset alarm condition.

6. The method according to claim 5, characterized in that, The second security verification task includes a pre-configured cloud platform defense strategy. The execution of simulated defense actions and generation of simulated defense results include: Match the simulated defense action sequence corresponding to the alarm feature from the cloud platform defense strategy; The simulated defense action sequence is executed sequentially to generate the simulated defense result.

7. The method according to claim 1, characterized in that, The security verification report generated based on the simulated attack results and the simulated defense results includes: After aligning the timestamps of the simulated attack results and the simulated defense results, security operation and maintenance metrics are automatically calculated. The security operation and maintenance indicators are filled into the preset template to generate the security verification report; The security verification report is used to update the cloud platform's security knowledge base.

8. A security verification system for a cloud platform, the system comprising: An attacking agent is used to determine potential attack paths in response to a first security verification task targeting the attacking agent. Based on the potential attack paths, simulated attack actions are performed on the cloud platform to generate simulated attack results; and, A defense agent is used to respond to a second security verification task for the defense agent, obtain the operation audit log of the cloud platform; after determining that the simulated attack action meets the preset alarm conditions based on the operation audit log, execute the simulated defense action and generate the simulated defense result; The director agent is used to generate a security verification report based on the simulated attack results and the simulated defense results.

9. An electronic device, characterized in that, include: processor; as well as A memory having executable code stored thereon, which, when executed by the processor, causes the processor to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, It stores executable code that, when executed by a processor of an electronic device, causes the processor to perform the method as described in any one of claims 1-7.

Images