Cloud platform security analysis method and device based on dynamic permission graph modeling

Abstract

Embodiments of the present disclosure provide a cloud platform security analysis method and device based on dynamic permission graph modeling, which comprises: collecting and analyzing role and permission information in Azure AD, and constructing a graph structure of mapping permissions to executable operations; based on the graph structure of mapping permissions to executable operations, generating executable attack chains through a graph search algorithm; simulating the execution process of the attack chains, detecting whether the platform triggers corresponding defense strategies, and recording related responses to generate a strategy response matrix; and identifying strategy configuration vulnerability points in the attack chains according to the strategy response matrix, and outputting optimization suggestions.

Description

Technical Field

[0001] The embodiments disclosed herein relate to the field of software design, and more specifically, to a cloud platform security analysis method and apparatus based on dynamic permission graph modeling. Background Technology

[0002] With the widespread adoption of cloud computing, enterprises and organizations are increasingly reliant on mainstream cloud service platforms such as Microsoft Azure, AWS, and Google Cloud. Secure management of identity and permissions has become a critical hub for cloud security governance. Microsoft's Azure Active Directory (Azure AD), as the core identity access control infrastructure in the Microsoft cloud ecosystem, is responsible not only for managing the identity relationships between users, devices, applications, and services, but also serves as the primary platform for implementing role-based access control, managing access policies, and enforcing authentication and authorization mechanisms. This means that once an attacker penetrates Azure AD and successfully controls the associated critical roles or interface permissions, the attacks they can launch will not be limited to privilege escalation or data access, but will encompass a complete attack chain involving core resource scheduling, lateral movement, persistent survival, and bypassing cloud alerts.

[0003] Existing systems lack effective tools to systematically map roles, permissions, and operations, making it impossible to assess the potential risks of different roles, verify and provide feedback on the effectiveness of strategies in real time, and establish an automated evaluation and optimization loop for strategies. Attack simulation systems cannot identify the penetration of different strategies and the patterns between attack chains, and cannot effectively evaluate and optimize the protective effects of strategies. Summary of the Invention

[0004] The embodiments described herein provide a cloud platform security analysis method, apparatus, computing device, and computer-readable storage medium storing program instructions based on dynamic permission graph modeling. The aim is to ensure a closed-loop effect from attack chain construction to policy optimization through real-time simulation, monitoring, and feedback, thereby making security protection more efficient and comprehensive.

[0005] According to a first aspect of this disclosure, a cloud platform security analysis method based on dynamic permission graph modeling is provided, comprising: collecting and parsing role and permission information in Azure AD, and constructing a graph structure mapping permissions to executable operations; generating an executable attack chain based on the graph structure mapping permissions to executable operations using a graph search algorithm; simulating the execution process of the attack chain, detecting whether the platform triggers the corresponding defense strategy, recording the relevant responses, and generating a strategy response matrix; and identifying policy configuration vulnerability points in the attack chain based on the strategy response matrix and outputting an optimization suggestion report.

[0006] In some embodiments of this disclosure, collecting and parsing role and permission information in Azure AD to construct a permission-to-executable-operations graph structure includes: obtaining a tenant ID and authentication token through Azure AD for identity authentication; after successful authentication, extracting all accounts, roles, policies, resources, and their permission configuration mappings through Azure API, UIPortal, or CLI tools to construct an original permission graph; based on the original permission graph, performing semantic modeling on the permission behavior of each role, aggregating permission items to specified operation categories to form a permission-to-executable-operations graph structure; displaying the constructed permission-to-executable-operations graph structure through visualization tools; identifying potential attack paths based on the operation category and resource call path of each permission item, listing potential attack points corresponding to each role and permission item; and labeling the risk level of each operation based on the nature of the permission operation and its potential impact on the system, and analyzing whether there is a possibility of bypassing security policies.

[0007] In some embodiments of this disclosure, the operation categories include information reconnaissance operations, lateral movement operations, permission manipulation operations, resource exploitation operations, persistent deployment behaviors, and log bypass / weakening behaviors. Information reconnaissance operations are used to collect information about target resources; lateral movement operations allow attackers or users to move laterally within the system, jumping from one account or resource to another; permission manipulation operations allow users or attackers to manipulate permissions; resource exploitation operations are used to extract sensitive information from resources; persistent deployment behaviors are used to create long-term effective modification or automation tasks in the system; and log bypass / weakening behaviors are used to bypass or disable logging and monitoring mechanisms, helping attackers conceal their actions.

[0008] In some embodiments of this disclosure, generating an executable attack chain based on a graph structure mapping permissions to executable operations using a graph search algorithm includes: using the attacker's identity in the graph structure as the starting point of the attack path, exploring all possible paths from the starting point to other system resources or operational targets using a graph search algorithm; during the graph search process, for each branch path, pruning the path based on the branch execution probability, operational harm, and policy penetration; after path pruning, using the path that satisfies the requirements of legitimate permission chain executability, strong destructiveness, and high alarm penetration probability as the attack chain, where each step in the attack chain is described as a certain attack operation.

[0009] In some embodiments of this disclosure, during the graph search process, for each branch path, pruning the path based on the branch execution probability, operational harm, and policy penetration includes: assessing the actual execution probability of each branch path; if a path depends on permissions or operation points that an attacker cannot obtain, then the path is pruned; assessing whether the path can lead to data leakage or service interruption, whether it can cause irreparable damage to the system, or whether it can damage the availability of a critical service; if not, then the path is pruned; assessing whether the path can bypass security policies, monitoring mechanisms, or other protection layers; if it cannot be bypassed, then the path is pruned.

[0010] In some embodiments of this disclosure, simulating the execution process of an attack chain, detecting whether the platform triggers the corresponding defense strategy, recording relevant responses, and generating a policy response matrix includes: extracting the current Azure security policy, Defender enabling rules, and SIEM interface settings; identifying the response conditions, triggering mechanisms, and interception capabilities of different strategies from the extracted security policies and rules; initializing a listening cache, which is used to collect and record the response of each step in the simulated attack chain process to the defense strategy in real time; when simulating the execution of each attack chain step, determining whether the expected resources exist and whether the attacker has the necessary permissions to perform the operation; when an attack chain step cannot continue due to resource shortage or insufficient permissions, marking the step as a potential blocking point; sending a listener query request to analyze whether the platform's logs, alerts, and restrictions are triggered; if relevant log recordings, alerts, or restrictions are triggered, recording the event and analyzing whether the defense system has made an appropriate response; if the attack chain steps receive sufficient responses and meet the expected defense effect, recording successful defense measures and generating a policy response matrix.

[0011] In some embodiments of this disclosure, policy configuration vulnerabilities in the attack chain are identified based on the policy response matrix, and optimization suggestions are output, including: if frequent penetration or failure to hit defense measures occurs in the path, it is recommended to add new interception policies to the path; if certain interfaces in the attack chain have permission issues or are abused by attackers, it is recommended to perform fine-grained role classification for these interfaces; if certain execution behaviors bypass conventional defense measures, it is recommended to add operation whitelist auditing and security information event management system diversion channels for these behaviors.

[0012] According to a second aspect of this disclosure, a cloud platform security analysis device based on dynamic permission graph modeling is provided. The device comprises a graph construction module, an attack chain generation module, a simulation execution module, and a feedback optimization module. The graph construction module collects and parses role and permission information from Azure Active Directory to construct a graph structure mapping permissions to executable operations. The attack chain generation module generates executable attack chains based on the permission-to-executable-operations graph structure using a graph search algorithm. The simulation execution module simulates the execution process of the attack chains, detects whether the platform triggers corresponding defense strategies, records relevant responses, and generates a strategy response matrix. The feedback optimization module identifies policy configuration vulnerabilities in the attack chains based on the strategy response matrix and outputs an optimization suggestion report.

[0013] According to a third aspect of this disclosure, a computing device is provided, including at least one processor; and a memory storing program instructions, wherein the program instructions are configured to be executed by the at least one processor, the program instructions including instructions for performing the methods described above.

[0014] According to a fourth aspect of this disclosure, a computer-readable storage medium storing program instructions is provided, which, when read and executed by a computing device, cause the computing device to perform the method described in the first aspect.

[0015] The cloud platform security analysis method and apparatus based on dynamic permission graph modeling, according to embodiments of this disclosure, achieves automated attack path combination by combining permission operation graphs, context state judgment, and graph search algorithms. Compared with traditional static templates or manual splicing, it can more comprehensively and accurately identify all known and unknown attack paths, possessing greater flexibility and adaptability, thereby improving the comprehensiveness and accuracy of attack path analysis. By transforming simulated attack behavior into structured interface calls and monitoring whether strategic events such as logs, alarms, and protection measures are triggered, an actual response matrix is ​​generated. This clearly identifies whether the strategy is effective, achieving closed-loop verification of strategy functions in cloud attack and defense, significantly improving the depth and accuracy of cloud security protection. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings of the embodiments will be briefly described below. It should be understood that the drawings described below only relate to some embodiments of this disclosure and are not intended to limit this disclosure, wherein:

[0017] Figure 1 This is an exemplary flowchart of a cloud platform security analysis method based on dynamic permission graph modeling according to embodiments of the present disclosure;

[0018] Figure 2This is a schematic block diagram of a cloud platform security analysis device based on dynamic permission graph modeling according to an embodiment of the present disclosure;

[0019] Figure 3 This is a schematic block diagram of a computing device according to embodiments of the present disclosure.

[0020] It should be noted that the elements in the attached diagram are schematic and not drawn to scale. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the described embodiments of this disclosure without creative effort are also within the scope of protection of this disclosure.

[0022] Unless otherwise defined, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this subject matter pertains. It will be further understood that terms such as those defined in commonly used dictionaries shall be interpreted as having meanings consistent with their meanings in the context of the specification and in the relevant art, and shall not be interpreted in an idealized or overly formal form unless otherwise explicitly defined herein. Furthermore, terms such as “first” and “second” are used only to distinguish one component (or part of a component) from another component (or another part of a component).

[0023] This disclosure proposes a comprehensive control and defense analysis method applicable to the Microsoft Azure cloud platform. It focuses on penetration chain analysis, behavioral simulation control, policy response detection, and closed-loop optimization suggestion evaluation around Azure Active Directory (Azure AD) permission objects under the Microsoft Azure cloud platform. By constructing a permission semantic graph and a policy penetration matrix, it achieves automated attack chain generation, low-interference continuous control verification, and sensitive operation simulation testing. Ultimately, it achieves full lifecycle Azure security posture control under an "attack-defense" integration approach. It can dynamically support changes in permission information and policies, provide practical simulation capabilities, optimize policy configuration, and ensure the security protection effect of the cloud platform. It can be widely applied in multiple scenarios, including red team / blue team exercises, cloud security policy review and verification, data compliance assessment, least privilege verification, and key escrow protection research.

[0024] Figure 1 An exemplary flowchart is shown for a cloud platform security analysis method based on dynamic permission graph modeling according to embodiments of the present disclosure. Figure 1 At box S102, role and permission information in Azure AD is collected and parsed to build a graph structure that maps permissions to executable operations.

[0025] Azure provides API, UIPortal, and CLI command-line tools for querying accounts, roles, policies, resources, and their permission configurations. It can interact with the Azure Resource Manager API to obtain structured, real-time data on various accounts, roles, and policies. UIPortal and CLI tools can serve as supplementary tools, extracting permission and resource information from user actions to complement the data obtained from the API. Before interacting with Azure Resource Manager, the tenant ID and authentication token are first obtained through Azure Active Directory (Azure AD) for authentication. After successful authentication, all accounts, roles, policies, resources, and their permission configuration mappings are extracted using the Azure API, UIPortal, or CLI tools to construct the original permission graph. The permission graph displays the mapping relationship between accounts, roles, and resources, including which users or roles have which access permissions, and which operations can be performed under what conditions, thus providing a reference for further attack chain analysis.

[0026] Specifically, by accessing Azure RBAC (Role-Based Access Control), you can obtain the binding information of all accounts and roles related to the tenant, the list of API operations and permission scopes under each role, custom policies and conditional restrictions, and resource access control mechanisms. Each account can be associated with one or more roles, mapping the account-role relationship to a table to form a list of role-account bindings.

[0027] In Azure, access permissions for roles and resources are defined through API operations. Each role has a set of predefined operations, such as Read, Write, and Delete, which can be executed on Azure resources. The API permissions for each role are associated with different operations on the resource, such as accessing keys in the Key Vault, creating virtual machines, managing storage accounts, and executing remote commands. Through these API permissions, the system can understand the scope of a role's operations on specific resources. Azure supports custom permission policies, allowing users to create rules to restrict access to specific resources or limit certain operations. For example, specific conditions can be set to require operations to be executed only within a specific time window, or to allow only requests from a specific range of IP addresses. In addition to regular permissions, Azure also supports conditional access control, which can capture all custom policies and conditional restrictions under each role or account and parse their specific rules. For example, an account may have permission to manage storage accounts, but access may only be possible in a specific network environment or through a specific authentication method. The resource access control mechanism obtains the resource access control list by capturing the Azure Identity and Access Management (IAM) structure, which helps analyze the access control relationships between resources and users / roles.

[0028] After collecting the above information, the permissions and API permission mapping dictionary for each role under different resources are parsed. This dictionary includes the access level of each role for specific resources, such as read, write, and execute, forming the original permission graph. This graph displays all accounts, roles, resources, and their permission relationships in a structured manner, providing a reference for further attack chain analysis. An example of the original permission graph structure is as follows:

[0029] Account (e.g., User A, User B, Service Entity) → Role (e.g., Contributor, Reader, Owner) → Permission (e.g., Microsoft.Compute / virtualMachines / start)

[0030] Role → Operation (e.g., write, read) → Resource Type (e.g., Virtual Machine, Storage Account)

[0031] Policy → Resource Access Control (e.g., allowing virtual machines to be created only in specific regions)

[0032] Each node in the permission graph represents an entity (account, role, operation, resource, policy, etc.), and the edges represent the relationships between them (such as the relationship between roles and permissions, and the constraints between policies and operations). The collected data is stored in a database, and the permission graph is graphically displayed.

[0033] After collecting and parsing permission and role information, semantic modeling is performed on the permission behavior of each role based on the original permission graph. Permission items are aggregated into specified operation categories, forming a graph structure that maps permissions to executable operations. In one embodiment of this disclosure, based on publicly available documents, attack experience databases, and security cases, the actual meaning and potential attack behaviors of each permission item are analyzed. The permission items for each role are categorized according to their nature and purpose, with the main categories including:

[0034] Information reconnaissance operations are primarily used to gather information about target resources. Permissions include reading resource status, retrieving configuration information, and querying metadata. Typical operations include reading virtual machine status, retrieving storage account configuration files, and retrieving application configuration items.

[0035] Lateral movement operations allow attackers or users to move laterally within a system, jumping from one account or resource to another. These operations can allow attackers to escalate privileges or gain control of other accounts. Typical operations include granting other accounts access to resources or connecting to networks or services between different resources.

[0036] Access control operations allow users or attackers to manipulate permissions, typically including granting permissions and modifying role assignments, enabling attackers to expand their privileges. Typical operations include assigning or deleting roles and changing the permissions of a user or group.

[0037] Resource-acquisition operations are used to extract sensitive information from resources, such as keys, tokens, and confidential data. Through these operations, attackers can obtain and exploit critical information within the system. Typical operations include exporting keys, extracting access keys for stored accounts, and obtaining service tokens.

[0038] Persistent deployment is used to create long-lasting modifications or automated tasks within a system to maintain an attacker's control. By creating triggers, scheduled tasks, and other methods, attackers can ensure their control over the system remains intact. Typical operations include deploying event triggers, creating automated tasks, and setting up scheduled script execution.

[0039] Log bypass / weakening behaviors allow attackers or users to modify logging settings to hide their activity or weaken monitoring mechanisms. This is crucial for attackers because it allows them to evade detection and tracing. Typical actions include disabling monitoring, modifying diagnostic settings, and disabling audit logs.

[0040] Finally, each permission item is combined with the above classifications, and attack paths are graphically constructed according to the characteristics, risk levels, and bypass probabilities of different operations. Each permission item is mapped to a corresponding executable operation, forming a multi-dimensional graph structure. The constructed permission-to-executable-operation graph structure is displayed using visualization tools. This graph structure clearly shows the relationship between permissions and operations, as well as potential attack risks. Each operation may involve different resources and components; by tracing the paths of these operations, every path that an attacker might exploit can be identified. For example, exporting data from a database may involve multiple resources, including the database itself, storage accounts, and permission settings.

[0041] Potential attack paths can be identified based on the operation categories and resource access paths corresponding to permissions, and potential attack points can be listed for each role and permission item. Based on the nature of the permission operation and its potential impact on the system, each operation is labeled with a risk level, and the possibility of bypassing security policies is analyzed. Risk levels depend on the sensitivity of the permission, the complexity of the attack path, and the system's protection mechanisms. Operations that allow access to critical information or privilege escalation are considered high-risk. If an attacker can execute multiple attack behaviors through a single operation, the risk of that attack point is even greater. Some operations may bypass existing security policies or monitoring mechanisms, so the system also needs to assess the likelihood of these operations bypassing policies. For each attack point, the effectiveness of existing policies in intercepting the attack is analyzed. Operations that may bypass existing security policies are marked as having a high probability of policy bypass, prompting the security team to take appropriate protective measures. For example, attackers may conceal their activities by changing diagnostic settings or disabling log auditing; this behavior will be marked as policy bypass behavior. To ensure the attack point list remains effective, it is updated and optimized regularly. As permissions, role definitions, resource structures, and policies change, permissions and roles are rescanned, and the attack point list and risk levels are adjusted accordingly.

[0042] Subsequently Figure 1 In box S104, an executable attack chain is generated based on the graph structure that maps permissions to executable operations, using a graph search algorithm.

[0043] The construction of an attack chain requires a starting point, which is the attacker's identity. The attacker's identity can be a malicious user, a hijacked account, a service account with excessive privileges, or a vulnerable component in the system. The choice of the starting point is crucial to the generation of the attack chain; it determines where the attack chain begins and affects the generation of subsequent paths. The attacker's identity in the graph structure can be used as the starting point of the attack path, and graph search algorithms can be used to explore all possible paths from the starting point to other system resources or operational targets.

[0044] For example, using Depth-First Search (DFS) and Breadth-First Search (BFS), executable attack chains can be generated based on the permission graph, policy hook relationships, and the results of attack point extraction. The graph searcher traverses the permission chain graph, finding all possible attack paths. Each path represents an attacker gradually gaining more permissions and performing more operations starting from the starting point, until the attack objective is achieved, such as stealing data or damaging the system. DFS explores paths by deeply visiting nodes in each branch, making it suitable for discovering deep attack paths, but it may face the problem of excessively long paths. BFS searches by expanding nodes layer by layer, making it suitable for finding shorter attack paths. The A* search algorithm combines heuristic search and cost minimization, comprehensively considering multiple factors such as path cost and feasibility during the search process, thus making it suitable for finding the optimal attack path.

[0045] During graph search, for each branch path, paths are pruned based on branch execution probability, operational harm, and policy penetration to eliminate unreasonable or low-risk paths. For example, considering whether an attacker can successfully execute a certain path, branch probability assesses the feasibility of each operation. For instance, if a certain permission requires an attacker to first obtain authorization from certain roles or perform a specific operation, then the branch probability of this path is low. Each operation has a different degree of harm to the system; operational harm assesses the destructiveness of the operation. For example, operations such as obtaining sensitive keys or injecting malicious code have high harm, while simply reading resource status or listing resource groups has low harm. Some operations may bypass existing security policies or defenses. For example, disabling audit logs, turning off monitoring, or accessing resources through specific APIs may help attackers bypass security monitoring and increase the penetration of the attack path.

[0046] After path pruning, the paths that satisfy the criteria of legitimate permission chain executability, high destructiveness, and high potential for alarm penetration are selected as attack chains. Each step in the attack chain is described as a specific attack operation. Each operation in the final retained path must be legitimate and executable; in other words, the attacker must have sufficient privileges to complete all operations within the path. For example, the attacker needs permission to access a resource, read logs, or obtain keys. The actual execution probability of each branch path is evaluated, and if a path depends on permissions or operation points that the attacker cannot obtain, that path is pruned.

[0047] The operations within the attack path must be sufficiently destructive to pose a significant security threat to the target system. Assess whether the path will lead to data breaches or service interruptions, cause irreparable damage to the system, or disrupt the availability of a critical service; if not, the path should be removed. The path should include operations that effectively bypass security monitoring. Attackers often avoid detection by hiding their activities or altering logging methods. Assess whether the path can bypass security policies, monitoring mechanisms, or other protective layers; if not, remove the path. For example, disabling monitoring, disabling audit logs, or changing diagnostic settings will enhance the alert penetration capability of the attack chain. Path pruning will retain those paths with a high probability of bypassing detection and alerting mechanisms.

[0048] Based on the pruned path, different attack operations are chained together sequentially, ultimately outputting a complete attack chain. Each step corresponds to an operation, and the attacker achieves their goal step by step through these steps. The attack chain may contain multiple operations, each of which the attacker can only execute after successfully completing the previous step. An example of a specific attack chain is as follows:

[0049] 1. Read diagnostic settings: Attackers may first read the diagnostic settings to understand the target system's log configuration in order to determine whether they can hide their operations later.

[0050] 2. Enumerate resource groups: The attacker lists the resource groups in the system and determines the resources that can be accessed.

[0051] 3. Retrieve KeyVault keys: Attackers obtain keys from the system, which allows them to access encrypted data or perform other malicious operations.

[0052] 4. Create a service principal: Through a service principal, attackers can register new identities or accounts in the target system to expand their control.

[0053] 5. Key Injection: Attackers inject obtained keys into certain applications or services to gain higher-level access privileges.

[0054] 6. Function binding: Through function binding, attackers may remotely execute malicious code or trigger specific operations.

[0055] 7. Create a Webhook: Attackers create a Webhook to execute malicious tasks on the target system at regular intervals.

[0056] 8. Enable automatic scheduled calls: Attackers can continuously perform malicious operations through Webhook to maintain control of the system, and even maintain a certain degree of persistence after the attacker exits.

[0057] By traversing the permission-control point-operated object graph using graph search algorithms (such as DFS, BFS, A*), the most threatening attack paths are identified. Through the incorporation of attacker identity, path trimming, and optimization, a complete attack chain that is legitimate, highly destructive, and potentially bypasses alert mechanisms is ultimately generated.

[0058] Then in Figure 1 In box S106, the execution process of the attack chain is simulated, the platform is detected to trigger the corresponding defense strategy, and the relevant responses are recorded to generate a strategy response matrix.

[0059] Before simulating the attack chain, the current Azure security policies, Defender enabling rules, and SIEM interface settings are extracted. From these extracted security policies and rules, the response conditions, triggering mechanisms, and blocking capabilities of different policies are identified. Specifically, the security policies currently implemented in the Azure environment are extracted first. These policies include, but are not limited to, firewall rules, Identity and Access Management (IAM) configurations, and Network Security Group (NSG) settings. These security policies define which resources can be accessed and which operations are allowed or restricted; each step of the attack chain must be simulated according to these policies. Security rules related to Defender are extracted, including network attack protection, malware detection, identity protection, and log auditing. These rules determine which behaviors will trigger protection mechanisms. Interface settings related to SIEM (Security Information and Event Management) are extracted. These settings include configurations related to log management, alert handling, and behavioral analysis. The SIEM system can monitor abnormal behavior in real time and generate alerts, which is crucial for the subsequent defense analysis in the simulated attack chain.

[0060] Next, a listening cache is initialized. This cache is used to collect and record the responses of each step in the simulated attack chain to the defense strategy in real time. When simulating each step of the attack chain, it is determined whether the expected resources exist and whether the attacker has the necessary permissions to execute the operation. If a step in the attack chain cannot continue due to resource shortage or insufficient permissions, that step is marked as a potential blocking point. The purpose of this marking is to indicate potential vulnerabilities in the system's defenses and trigger further investigation. If multiple steps are marked as potential blocking points, it may indicate that the system's defense mechanisms are failing under certain circumstances, requiring further investigation and optimization. Even if a step is marked as a potential blocking point, subsequent steps in the attack chain will still continue to be executed in order to identify other potential defense issues.

[0061] For example, if an attack chain requires access to a database or service, it first verifies whether the resource has been initialized or is accessible. If the resource does not exist, this step in the attack chain will be marked as failed to prevent unrealistic results from being simulated. Each step requires the attacker to have sufficient privileges to perform the corresponding operation. If the attacker lacks privileges—for example, due to access control policies not allowing the operation or insufficient role permissions—it is marked as a "potential blocking point," and the execution of that step is terminated. This indicates that the attacker may encounter blockage from the protection system at this step and cannot continue their attack chain.

[0062] Send listener query requests to analyze whether platform logs, alerts, and restrictions have been triggered. If relevant logging, alerts, or restrictions are triggered, the event is recorded and the appropriate response from the defense system is analyzed. Listener queries can detect whether each attack step triggers the platform's security logging or alerting mechanisms. For example, if an attacker attempts to modify resource permissions, will an alert be triggered and logs recorded? It can also determine whether each operation is blocked by the platform's security restriction mechanisms. For example, a firewall might block certain malicious traffic or prevent privilege escalation. During the attack chain execution, logs of critical operations can be forwarded to a designated log management system or SIEM (such as Splunk or Azure Sentinel). These logs contain detailed information about the attack behavior and are used for further analysis of security events. If the attack chain involves API calls, the interoperability of these API calls can be verified, including checking whether the API can be successfully called, whether access control policies can be bypassed, and whether the API response meets expectations. During attack chain simulation, the compliance of the actual execution with security policies, triggering mechanisms, and security protection measures is evaluated. This simulation ensures that the execution of the attack chain matches the security protection system of the real environment to the greatest extent possible, and detects potential vulnerabilities or unidentified security risks.

[0063] If the attack chain steps are adequately responded to and achieve the expected defense effect, successful defense measures are recorded, and a policy response matrix is ​​generated. The policy response matrix is ​​a detailed table recording the execution result of each step, including information such as the target interface, log entries, alarm triggering, whether execution was prohibited, policy name, and response latency. Specifically, the policy response matrix contains the following fields:

[0064] Step number: Record the number of each step in the attack chain for easy tracking and analysis.

[0065] Target Interface: The target interface for each step of the attack operation, such as "vm.run" or "vault.getKey". The interface refers to the resource or service targeted by the attack chain operations.

[0066] Trigger logging: Indicates whether this step generates a record in the system log. If a record is generated, it indicates that the system monitored the behavior during this step.

[0067] Whether a security alarm was triggered: This indicates whether a security alarm was triggered, and whether the system detected an anomaly and issued an alert.

[0068] Is execution prohibited? If this step is blocked due to permissions, policies, or firewalls, record "Yes"; otherwise, record "No".

[0069] Policy Name: If a relevant security policy is triggered, record the policy name. For example, "AlertKey01".

[0070] Response latency: Indicates the delay time during which the security system reacts to this step. For example, a latency of 120ms represents the time from executing the operation to triggering a response.

[0071] An example of the generated policy response matrix is ​​shown below:

[0072]

[0073]

[0074] Finally, in box S108, policy configuration vulnerabilities in the attack chain are identified based on the policy response matrix, and optimization suggestions are output.

[0075] Based on the policy response matrix, the system can identify penetration points, policy-uncovered segments, and violation risk segments in the attack chain where measures are not applied. Specifically, by examining which steps fail to trigger security alerts or are not blocked, the system can locate unprotected links in the attack chain. These links may become penetration points, meaning attackers can bypass the protection system and continue operating. If an attack step does not trigger any policy response, or if the system does not have sufficient protection, it indicates that this part of the operation is not protected by the policy. Such segments may be potential security vulnerabilities requiring further policy strengthening. By analyzing which steps fail to trigger the expected response, the system can identify violation risk segments where protection measures are not fully applied or effectively covered. These segments may be protection gaps requiring the addition of new security controls.

[0076] After collecting and generating the policy response matrix, the current protection strategy is optimized based on the data in the matrix, and a policy recommendation report is automatically generated. This report combines the most frequently intersecting failed policy points across all attack chain paths with the actually hit policy segments, outputting specific policy recommendations and optimization measures to improve the overall protection level. First, the attack chain paths are analyzed to determine which policies failed and these failed policy points are recorded. Failed policy points refer to steps in the attack chain that the system deems ineffective in blocking, allowing the attack to successfully penetrate. This could be due to incomplete policies, overly lenient policies, or attackers bypassing protection measures. Actually hit policy segments are steps where the protection system successfully responded to and blocked the attack, indicating that the existing strategy is effective on certain attack paths. These policy segments need to be retained and strengthened as effective protection measures.

[0077] Based on the policy response matrix and failed policy points, policy recommendations are automatically generated to propose optimization measures for weak points in protection. Specific recommendations may include: If frequent penetration or missed defenses occur along a path, it is recommended to add new blocking policies to that path. For example, for path X, it is recommended to add a new firewall rule or intrusion detection system rule (such as Rule_A) to prevent similar attacks from recurring. If certain interfaces in the attack chain have permission issues or are abused by attackers, it is recommended to implement fine-grained role classification for these interfaces. For example, for interface combination Y, enable multi-factor authentication to prevent privilege escalation attacks. If certain actions bypass regular defenses, it is recommended to add an operation whitelist audit and security information event management system (SIEM) diversion channel for these actions. For example, for action Z, this action can be added to the audit list, and related logs and alerts can be diverted through the SIEM system for real-time monitoring. Recommended policies can be output in various formats for rapid deployment and execution in real-world environments. For example, the Microsoft Defender policy format can be directly integrated with Microsoft Defender security tools, simplifying security policy deployment and synchronization. For automated configuration in cloud environments, policy recommendations can be output in Terraform or ARM Templates format for direct application in the Azure environment, enabling automatic synchronization. This allows policy changes to be applied directly in the Azure environment, ensuring that optimization recommendations are quickly translated into actionable security measures.

[0078] Figure 2 This is a schematic block diagram of a cloud platform security analysis apparatus based on dynamic permission graph modeling according to embodiments of the present disclosure. (Refer to...) Figure 2 As shown, the device includes a graph construction module, an attack chain generation module, a simulation execution module, and a feedback optimization module.

[0079] The system comprises the following modules: a graph construction module for collecting and parsing role and permission information in Azure AD, and constructing a graph structure that maps permissions to executable operations; an attack chain generation module for generating executable attack chains based on the graph structure; a simulation execution module for simulating the execution process of the attack chain, detecting whether the platform triggers the corresponding defense strategy, recording the relevant responses, and generating a strategy response matrix; and a feedback optimization module for identifying policy configuration vulnerabilities in the attack chain based on the strategy response matrix and outputting an optimization suggestion report.

[0080] Specifically, the graph construction module can automatically capture permission data for all users, roles, RBAC (Role-Based Access Control), resources, and policy allocations within a tenant. It performs semantic analysis on the collected permission data to identify the control behaviors and potential attack risks corresponding to each permission. By marking the intent of different resource operations, it provides decision support for the generation of subsequent attack chains. The attack chain generation module can construct attack paths under compliant permissions using path search algorithms based on permission data. Through multi-path generation, the feasibility of different attack paths can be evaluated and scored to determine their potential danger. The simulation execution module can simulate actual operations in the attack chain, observe whether the behaviors in the attack path can successfully access the target resource, return feedback results for each operation, and record whether it was blocked by the policy. It monitors and analyzes system logs, Azure Monitor, and Defender alerts in real time to determine if any defense policies have been triggered. Along the attack chain path, it tracks whether each step of the operation hits the defense policy, which operations were blocked, and which were not. Through structured output, it can generate a policy effect graph to help users understand the effectiveness of the policies. The feedback optimization module can automatically identify vulnerabilities in security policies based on uninterrupted attack paths and existing policies, and propose policy reinforcement suggestions to help optimize existing defense strategies.

[0081] Based on the analysis results of the above modules, detailed reports can be generated to provide decision support for the DevSecOps process and ultimately improve the system's security protection capabilities.

[0082] Figure 3 This is a schematic block diagram of a computing device according to embodiments of the present disclosure. (Refer to...) Figure 3 As shown, the computing device 300 includes a processor 310 and a memory 320 storing program instructions. The program instructions are executed by the processor 310 and include instructions for performing the method 100 described above.

[0083] In embodiments of this disclosure, processor 310 may be, for example, a central processing unit (CPU), a microprocessor, a digital signal processor (DSP), a processor based on a multi-core processor architecture, etc. Memory 320 may be any type of memory implemented using data storage technologies, including but not limited to random access memory, read-only memory, semiconductor-based memory, flash memory, disk storage, etc.

[0084] Furthermore, in embodiments of this disclosure, device 300 may also include input device 330, such as a keyboard, mouse, etc. Additionally, device 300 may also include output device 340, such as a display, for outputting a visual security report.

[0085] In other embodiments of this disclosure, a computer-readable storage medium storing program instructions is also provided, wherein the program instructions, when executed by a processor, can achieve the following: Figure 1 The steps of method 100 shown.

[0086] In summary, the cloud platform security analysis method and apparatus based on dynamic permission graph modeling according to the embodiments of this disclosure achieves automated attack path combination through the combination of permission operation graphs, context state judgment, and graph search algorithms. Compared with traditional static templates or manual splicing, it can more comprehensively and accurately identify all known and unknown attack paths, possessing greater flexibility and adaptability, thereby improving the comprehensiveness and accuracy of attack path analysis. By transforming simulated attack behavior into structured interface calls and monitoring whether strategic events such as logs, alarms, and protection measures are triggered, an actual response matrix is ​​generated. This clearly identifies whether the strategy is effective, achieving closed-loop verification of strategy functions in cloud attack and defense, and significantly improving the depth and accuracy of cloud security protection.

[0087] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatuses and methods according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0088] Unless otherwise expressly indicated by the context, the singular form of words used herein and in the appended claims includes the plural form, and vice versa. Thus, when referring to the singular, the plural form of the corresponding term is generally included. Similarly, the terms “comprising” and “including” shall be interpreted as including rather than exclusively. Likewise, the terms “including” and “or” shall be interpreted as including unless such interpretation is expressly prohibited herein. Where the term “example” is used herein, particularly when it follows a set of terms, the “example” is merely exemplary and illustrative and should not be considered exclusive or extensive.

[0089] Further aspects and scope of adaptation become apparent from the description provided herein. It should be understood that various aspects of this application may be implemented individually or in combination with one or more other aspects. It should also be understood that the descriptions and specific embodiments herein are for illustrative purposes only and are not intended to limit the scope of this application.

[0090] Several embodiments of this disclosure have been described in detail above. However, it is obvious that those skilled in the art can make various modifications and variations to the embodiments of this disclosure without departing from the spirit and scope of this disclosure. The scope of protection of this disclosure is defined by the appended claims.

Claims

1. A cloud platform security analysis method based on dynamic permission graph modeling, characterized in that, include: Collect and parse role and permission information from Azure AD to construct a permission mapping to executable operations. This includes: obtaining tenant IDs and authentication tokens through Azure AD for authentication; after successful authentication, extracting all accounts, roles, policies, resources, and their permission configuration mappings through Azure API, UI Portal, or CLI tools to construct an initial permission graph; based on the initial permission graph, semantically modeling the permission behavior of each role, aggregating permission items to specified operation categories to form a permission mapping to executable operations; identifying potential attack paths based on the operation category and resource call path of each permission item, listing potential attack points corresponding to each role and permission item; and labeling each operation with a risk level based on the nature of the permission operation and its potential impact on the system, and analyzing the possibility of bypassing security policies. Based on the graph structure of permissions mapped to executable operations, an executable attack chain is generated using a graph search algorithm; The execution process of the attack chain is simulated to detect whether the platform triggers the corresponding defense strategy, and the relevant responses are recorded to generate a strategy response matrix; and Based on the policy response matrix, identify policy configuration vulnerabilities in the attack chain and output optimization suggestions.

2. The cloud platform security analysis method based on dynamic permission graph modeling according to claim 1, characterized in that, The operation categories include information reconnaissance operations, lateral movement operations, permission manipulation operations, resource exploitation operations, persistent deployment behaviors, and log bypass / weakening behaviors. Information reconnaissance operations are used to collect information about target resources. Lateral movement operations allow attackers or users to move laterally within the system, jumping from one account or resource to another. Permission manipulation operations allow users or attackers to manipulate permissions. Resource exploitation operations are used to extract sensitive information from resources. Persistent deployment behaviors are used to create long-term effective modification or automation tasks within the system. Log bypass / weakening behaviors are used to bypass or disable logging and monitoring mechanisms, helping attackers conceal their actions.

3. The cloud platform security analysis method based on dynamic permission graph modeling according to claim 1, characterized in that, The graph structure based on the permissions mapped to executable operations, which generates executable attack chains through a graph search algorithm, includes: Using the attacker's identity in the graph structure as the starting point of the attack path, a graph search algorithm is used to explore all possible paths from the starting point to other system resources or operational targets. During the graph search process, for each branch path, path pruning is performed based on branch execution probability, operational risks, and policy penetration; and After path pruning, the paths that satisfy the requirements of legal permission chain executability, strong destructiveness, and high potential for alarm penetration are taken as attack chains. Each step in the attack chain is described as a certain attack operation.

4. The cloud platform security analysis method based on dynamic permission graph modeling according to claim 3, characterized in that, The process of pruning each branch path during graph search, based on branch execution probability, operational risk, and strategy penetration, includes: Assess the actual execution probability of each branch path, and cut off the path if a path depends on permissions or operation points that the attacker cannot obtain; Assess whether the path could lead to data breaches or service interruptions, whether it could cause irreparable damage to the system, or whether it could compromise the availability of a critical service. If not, cut off the path. Evaluate whether the path can bypass security policies, monitoring mechanisms, or other protection layers; if it cannot, cut off the path.

5. The cloud platform security analysis method based on dynamic permission graph modeling according to claim 1, characterized in that, The simulation of the attack chain execution process detects whether the platform triggers the corresponding defense strategy, records the relevant responses, and generates a strategy response matrix, including: Extract the current Azure security policy, Defender enabling rules, and SIEM interface settings, and identify the response conditions, triggering mechanisms, and blocking capabilities of different policies from the extracted security policies and rules; Initialize the listening cache, which is used to collect and record the response of each step in the simulated attack chain to the defense strategy in real time; When simulating each step of an attack chain, it is determined whether the expected resources exist and whether the attacker has the necessary permissions to perform the operation. If an attack chain step cannot continue due to lack of resources or insufficient permissions, the step is marked as a potential blocking point. Send listener query requests to analyze whether the platform's logs, alerts, and restrictions have been triggered. If relevant log entries, alerts, or restrictions are triggered, record the event and analyze whether the defense system has responded appropriately. If the attack chain steps are adequately responded to and achieve the expected defense effect, the successful defense measures are recorded, and a strategy response matrix is ​​generated.

6. The cloud platform security analysis method based on dynamic permission graph modeling according to claim 1, characterized in that, The step of identifying policy configuration vulnerabilities in the attack chain based on the policy response matrix and outputting optimization suggestions includes: If frequent penetration or failure to hit defense measures occurs in the path, it is recommended to add a new interception strategy to that path; If certain interfaces in the attack chain have permission issues or are abused by attackers, it is recommended to refine the role classification of these interfaces. If certain actions bypass standard defenses, it is recommended to add an operational whitelist audit and a security information incident management system diversion channel for these actions.

7. A cloud platform security analysis device based on dynamic permission graph modeling, characterized in that, It includes a graph construction module, an attack chain generation module, a simulation execution module, and a feedback optimization module; The permission graph construction module is used to collect and parse role and permission information in Azure AD, and construct a permission graph structure that maps permissions to executable operations. This includes: obtaining tenant IDs and authentication tokens through Azure AD for identity authentication; after successful authentication, extracting all accounts, roles, policies, resources, and their permission configuration mappings through Azure API, UI Portal, or CLI tools to construct an original permission graph; based on the original permission graph, performing semantic modeling on the permission behavior of each role, aggregating permission items to specified operation categories, forming a permission graph structure that maps permissions to executable operations; identifying potential attack paths based on the operation category and resource call path of each permission item, listing potential attack points corresponding to each role and permission item; and labeling each operation with a risk level based on the nature of the permission operation and its potential impact on the system, and analyzing whether there is a possibility of bypassing security policies. The attack chain generation module is used to generate an executable attack chain based on the graph structure of the permissions mapped to executable operations, and through a graph search algorithm. The simulation execution module is used to simulate the execution process of the attack chain, detect whether the platform triggers the corresponding defense strategy, record the relevant responses, and generate a strategy response matrix. The feedback optimization module is used to identify policy configuration vulnerabilities in the attack chain based on the policy response matrix and output an optimization suggestion report.

8. A computing device, comprising: At least one processor; and a memory storing program instructions, wherein the program instructions are configured to be executed by the at least one processor, the program instructions including instructions for performing the method as described in any one of claims 1-6.

9. A computer-readable storage medium storing program instructions that, when read and executed by a computing device, cause the computing device to perform the method as described in any one of claims 1-6.

Images