CSA CCM Application and Interface Security Capability Group

This control implements measures to secure APIs. Using application control and monitoring for and blocking malicious API calls can help prevent user execution of malware via APIs in cloud consoles.

This control implements measures to secure APIs. Using application control and monitoring for and blocking malicious API calls can help prevent adversaries from abusing APIs to execute malicious commands.

This control implements measures to secure APIs. Using application control and monitoring for and blocking malicious API calls can help prevent adversaries from abusing cloud APIs to execute malicious commands.

The control outlines several testing approaches, including the use of automated tools, to identify and remediate vulnerabilities or weaknesses that can be exploited. Web shells provide attackers with unauthorized and persistent remote control over a compromised web server, allowing them to execute commands, manipulate files, and steal data. A web application is compromised when an attacker exploits a vulnerability to upload a malicious script, which then acts as a backdoor for ongoing malicious activity. Remediating the vulnerabilities that allow an attacker to upload a web shell can help mitigate this technique.

Adversaries may exploit software vulnerabilities that can cause an application or system to crash and deny availability to users. Some systems may automatically restart critical applications and services when crashes occur, but they can likely be re-exploited to cause a persistent denial of service (DoS) condition. The control outlines several testing approaches, which could help mitigate this technique, including the use of automated tools, to identify vulnerabilities throughout the software development lifecycle from development to production.

Adversaries may target resource intensive features of applications to cause a denial of service (DoS), denying availability to those applications. For example, specific features in web applications may be highly resource intensive. Repeated requests to those features may be able to exhaust system resources and deny access to the application or the server itself. The control outlines several testing approaches, including the use of automated tools, to identify and remediate vulnerabilities or weaknesses that can be exploited such as the use of the application exhaustion flood technique to exhaust system resources and deny access to the web application for others.

This control applies to the secure deployments of applications and emphasizes the prevention of misconfigurations and malicious deployment activities. By modifying conditional access policies, such as adding additional trusted IP ranges, removing Multi-Factor Authentication requirements, or allowing additional Unused/Unsupported Cloud Regions, adversaries may be able to ensure persistent access to accounts and circumvent defensive measures. Secure deployment templates can limit a user's ability to modify conditional access policies to only those required, which may limit this technique.

This control applies to the secure deployments of applications and emphasizes the prevention of misconfigurations and malicious deployment activities. Adversaries may gain access to and use configuration management and software deployment applications to execute commands and move laterally through the network. Security requirements for secure application deployment such as only granting access to application deployment systems only to authorized users and administrators, or ensuring the application deployment system can be configured to deploy only signed binaries can mitigate the adversary's abuse of this technique to execute commands and move laterally through the network.

This control applies to the secure deployments of applications and emphasizes the prevention of misconfigurations and malicious deployment activities. Adversaries may abuse serverless computing, integration, and automation services to execute arbitrary code in cloud environments. For example, in Microsoft 365 environments, an adversary may create a Power Automate workflow that forwards all emails a user receives or creates anonymous sharing links whenever a user is granted access to a document in SharePoint. Secure deployment templates and IaC scripts can restrict unusual serverless function modifications, such as adding roles to a function that allow unauthorized access or execution.

This control applies to the secure deployments of applications and emphasizes the prevention of misconfigurations and malicious deployment activities. Adversaries may add, delete, or otherwise modify resource groups within an IaaS hierarchy. For example, in Azure environments, an adversary who has gained access to a Global Administrator account may create new subscriptions in which to deploy resources. Secure deployment templates should restrict the ability to openly changes to resource groups, such as creating new resource groups which may mitigate the abuse of this technique.

This control applies to the secure deployments of applications and emphasizes the prevention of misconfigurations and malicious deployment activities. Adversaries may deploy a container into a cloud environment to facilitate execution or evade defenses. The control outlines the use of scanning images before deployment, and block those that are not in compliance with security policies, which can mitigate this technique.

This control applies to the secure deployments of applications and emphasizes the prevention of misconfigurations and malicious deployment activities. Adversaries may establish persistence and/or elevate privileges using system mechanisms that trigger execution based on specific events. Cloud environments may also support various functions and services that monitor and can be invoked in response to specific cloud events. Secure deployment templates and tools that limit the modification of cloud resources that may be abused for persistence, such as functions and workflows monitoring cloud events, could mitigate this technique.

This control applies to the secure deployments of applications and emphasizes the prevention of misconfigurations and malicious deployment activities. Adversaries may achieve persistence by leveraging OAuth application integrations in a software-as-a-service environment. Adversaries may create a custom application, add a legitimate application into the environment, or even co-opt an existing integration to achieve malicious ends. Secure deployment templates may mitigate the ability of an adversary to deploy malicious additions and changes to applications in the SaaS environment.

This control applies to the secure deployments of applications and emphasizes the prevention of misconfigurations and malicious deployment activities. Adversaries may implant cloud or container images with malicious code to establish persistence after gaining access to an environment. Secure deployment templates and checking the integrity of images and containers used in cloud deployments to ensure they have not been modified to include malicious software may aid in mitigating this technique.

This control applies to the secure deployments of applications and emphasizes the prevention of misconfigurations and malicious deployment activities. Adversaries may create cloud instances in unused geographic service regions in order to evade detection. Deployment templates and IaC scripts enforce which regions a deployment can occur and mitigate the ability of a compromised deployment to occur in an unused/unsupported region.

This control applies to the secure deployments of applications and emphasizes the prevention of misconfigurations and malicious deployment activities. Adversaries may abuse compute resource within a victim's cloud environment by modifying any tenant-wide policies that limit the sizes of deployed virtual machines. Deployment templates and automated rollback can enforce resource quotas, network segmentation, and least‑privilege IAM roles, reducing the ability of a compromised deployment to be repurposed for crypto‑mining or other illicit compute use.

This control applies to the secure deployments of applications and emphasizes the prevention of misconfigurations and malicious deployment activities. Adversaries may also modify settings that affect where cloud resources can be deployed, such as enabling T1535 : Unused/Unsupported Cloud Regions. Enforcing approved deployment regions, and vetting deployed applications and resources under this control may reduce the chance that malicious cloud applications can be deployed.

This control applies to the secure deployments of applications and emphasizes the prevention of misconfigurations and malicious deployment activities. Adversaries may also modify settings that affect where cloud resources can be deployed, such as enabling T1535 : Unused/Unsupported Cloud Regions. Enforcing approved deployment regions, and vetting deployed applications and resources under this control may reduce the chance that malicious cloud applications can be deployed.

This control applies to the secure deployments of applications and emphasizes the prevention of misconfigurations and malicious deployment activities. The automated patch‑management system could ensure OS, runtime, and application vulnerabilities are remediated quickly, removing the exploitable footholds attackers use to elevate privileges after a compromised deployment.

This control applies to the secure deployments of applications and emphasizes the prevention of misconfigurations and malicious deployment activities. Standardized deployment templates, a curated list of approved automation/deployment tools, and vetting of IaC libraries reduce the chance that malicious third‑party code or compromised build tools enter the pipeline.

This control applies to the secure deployments of applications and emphasizes the prevention of misconfigurations and malicious deployment activities. Adversaries may attempt to exploit a weakness in an cloud-hosted applications through software bugs or even deployment misconfigurations. Protecting cloud-hosted applications through standardized security configurations and deployment templates can mitigate the impact of this technique.

The control outlines several testing approaches, including the use of automated tools, to identify and remediate vulnerabilities or weaknesses that can be exploited. Attackers may use an existing, legitimate external Web service to exfiltrate data rather than their primary command and control channel. Regular testing should identify data exfiltration paths through applications and testing cloud APIs and web applications for unauthorized data access exfiltration.

This control requires both Cloud Service Providers and customers to implement a Secure Software Development Lifecycle (SSDLC) with security practices throughout the entire application development process to protect cloud-based applications from cyber threats.

This control requires both Cloud Service Providers and customers to implement a Secure Software Development Lifecycle (SSDLC) with security practices throughout the entire application development process to protect cloud-based applications from cyber threats. Adversaries can steal application access tokens as a means of acquiring credentials. Application access tokens are used to make authorized API requests on behalf of a user or service and are commonly used as a way to access resources in cloud and container-based applications. The SSDLC process should ensure that applications APIs, and applications access tokens are securely created and protected in their cloud environments.

This control requires both Cloud Service Providers and customers to implement a Secure Software Development Lifecycle (SSDLC) with security practices throughout the entire application development process to protect cloud-based applications from cyber threats. Adversaries can steal and use application access tokens as a means of acquiring credentials. Application access tokens are used to make authorized API requests on behalf of a user or service and are commonly used as a way to access resources in cloud and container-based applications. The SSDLC process should ensure that applications APIs, and applications access tokens are securely designed, developed, and protected in their cloud environments.

This control requires both Cloud Service Providers and customers to implement a Secure Software Development Lifecycle (SSDLC) with security practices throughout the entire application development process to protect cloud-based applications from cyber threats. By stealing alternate authentication material, adversaries are able to bypass system access controls and authenticate to systems without knowing the plaintext password or any additional authentication factors. The use of secure coding techniques to implement token binding allows applications and services to cryptographically bind their security tokens to the TLS layer to mitigate token theft.

This control requires both Cloud Service Providers and customers to implement a Secure Software Development Lifecycle (SSDLC) with security practices throughout the entire application development process to protect cloud-based applications from cyber threats. Adversaries may exploit software vulnerabilities in an attempt to collect credentials. Secure coding and secure configurations can prevent the exploit of known web application vulnerabilities used by attackers to access stored credentials.

This control requires both Cloud Service Providers and customers to implement a Secure Software Development Lifecycle (SSDLC) with security practices throughout the entire application development process to protect cloud-based applications from cyber threats. Adversaries may manipulate source code in open-source dependencies for the purpose of compromise to add malicious code to users of the dependency. SSDLC should validate open-source components to prevent the use of malicious or vulnerable dependencies.

This control requires both Cloud Service Providers and customers to implement a Secure Software Development Lifecycle (SSDLC) with security practices throughout the entire application development process to protect cloud-based applications from cyber threats. Adversaries may attempt to access the Cloud Instance Metadata API to collect credentials and other sensitive data. The SSDLC process should ensure that applications and APIs are securely designed, developed, and operated in their cloud environments.

This control requires both Cloud Service Providers and customers to implement a Secure Software Development Lifecycle (SSDLC) with security practices throughout the entire application development process to protect cloud-based applications from cyber threats. Adversaries may query and search through compromised applications to find and obtain insecurely stored credentials. Secure coding practices and secure credential handling may prevent hardcoded/insecurely stored credentials and ensure the that those cloud accounts are not compromised.

This control requires both Cloud Service Providers and customers to implement a Secure Software Development Lifecycle (SSDLC) with security practices throughout the entire application development process to protect cloud-based applications from cyber threats. Adversaries may query and search through compromised applications to find and obtain insecurely stored credentials. Secure coding practices and secure credential handling may prevent hardcoded/insecurely stored credentials and ensure the use of proper encryption for credentials and application data.

This control requires both Cloud Service Providers and customers to implement a Secure Software Development Lifecycle (SSDLC) with security practices throughout the entire application development process to protect cloud-based applications from cyber threats. Adversaries will use T1059 for various command injection attacks through web application interfaces. Securing serverless functions, cloud APIs, and web applications from command injection can help in mitigating this technique.

This control requires both Cloud Service Providers and customers to implement a Secure Software Development Lifecycle (SSDLC) with security practices throughout the entire application development process to protect cloud-based applications from cyber threats. Adversaries will use T1190 to exploit vulnerabilities in web applications internet-facing host or system to initially access a network. Proper input validation and secure coding practices can prevent exploitation of web application vulnerabilities.

The control outlines several testing approaches, including the use of automated tools, to identify vulnerabilities throughout the software development lifecycle from development to production. It emphasizes testing for risks such as injection attacks and session hijacking, and recommends alignment with industry standards like the OWASP Top 10 to enhance application security. Adversaries may manipulate software dependencies and development tools prior to receipt by a final consumer for the purpose of data or system compromise. A vulnerability scanner can be used to identify any third-party issues as outlined in the implementation guidelines.

The control outlines several testing approaches, including the use of automated tools, to identify vulnerabilities throughout the software development lifecycle from development to production. It emphasizes testing for risks such as injection attacks and session hijacking, and recommends alignment with industry standards like the OWASP Top 10 to enhance application security. Adversaries may attempt to exploit default admin or user accounts in cloud services, SaaS platforms, or cloud-deployed databases that weren't properly secured during setup.

The control outlines several testing approaches, including the use of automated tools, to identify vulnerabilities throughout the software development lifecycle from development to production. It emphasizes testing for risks such as injection attacks and session hijacking, and recommends alignment with industry standards like the OWASP Top 10 to enhance application security. Adversaries may use brute force techniques to gain access to accounts when passwords are unknown or when password hashes are obtained. Deprecated hash functions (MD5, SHA1) and weak key derivation make password cracking significantly faster, enabling successful brute force attacks .

The control outlines several testing approaches, including the use of automated tools, to identify vulnerabilities throughout the software development lifecycle from development to production. It emphasizes testing for risks such as injection attacks and session hijacking, and recommends alignment with industry standards like the OWASP Top 10 to enhance application security. Adversaries may search compromised services or applications to find and obtain insecurely stored API keys for SaaS services or cloud storage encryption keys.

The control outlines several testing approaches, including the use of automated tools, to identify vulnerabilities throughout the software development lifecycle from development to production. It emphasizes testing for risks such as injection attacks and session hijacking, and recommends alignment with industry standards like the OWASP Top 10 to enhance application security. Adversaries may passively sniff network traffic to capture traffic between microservices, API calls to SaaS platforms, or data transfers between on-premises and IaaS resources that lack proper TLS encryption.

The control outlines several testing approaches, including the use of automated tools, to identify vulnerabilities throughout the software development lifecycle from development to production. It emphasizes testing for risks such as injection attacks and session hijacking, and recommends alignment with industry standards like the OWASP Top 10 to enhance application security. Adversaries may modify access tokens to operate under a different user or system security context to perform actions and bypass access controls. For example, replaying or tampering with a JSON Web Token (JWT) access control token to elevate privileges or abusing JWT invalidation.

The control outlines several testing approaches, including the use of automated tools, to identify vulnerabilities throughout the software development lifecycle from development to production. It emphasizes testing for risks such as injection attacks and session hijacking, and recommends alignment with industry standards like the OWASP Top 10 to enhance application security. Adversaries may attempt to bypass access controls and elevate privileges to gain unauthorized access. Therefore, testing for improper privilege escalation, such as scenarios where a user can act without authentication or gain administrative rights while logged in as a standard user, can help mitigate these risks.

The control outlines several testing approaches, including the use of automated tools, to identify vulnerabilities throughout the software development lifecycle from development to production. It emphasizes testing for risks such as injection attacks and session hijacking, and recommends alignment with industry standards like the OWASP Top 10 to enhance application security. Adversaries may attempt to bypass access controls and elevate privileges to gain unauthorized access. Therefore, testing for improper privilege escalation, such as scenarios where a user bypasses access control checks by modifying the URL, can help mitigate these risks.

The control describes multiple testing approaches with automated tools to identify vulnerabilities from development through production. The control outlines testing for injection attacks, session hijacking, and aligning with industry standards like OWASP Top 10 to ensure applications are secure. Adversaries may attempt to access the Cloud Instance Metadata API to collect credentials and other sensitive data. Testing for the unnecessary use of metadata services or restricting and disabling insecure versions of metadata services that are in use may prevent adversary use of this technique. Additionally, adversaries may exploit a Server-Side Request Forgery (SSRF) vulnerability in a public facing web proxy that allows them to gain access to the sensitive information via a request to the Instance Metadata API.

The control describes multiple testing approaches with automated tools to identify vulnerabilities from development through production. The control outlines testing for injection attacks, session hijacking, and aligning with industry standards like OWASP Top 10 to ensure applications are secure. With proper permissions (often via use of credentials such as Application Access Token and Web Session Cookie), adversaries may abuse cloud APIs to invoke various functions that execute malicious actions.

The control describes multiple testing approaches with automated tools to identify vulnerabilities from development through production. The control outlines testing for injection attacks, session hijacking, and aligning with industry standards like OWASP Top 10 to ensure applications are secure. Adversaries may attempt to exploit a weakness in an Internet-facing host or application by using techniques such as as SQL injection, command injections, Cross-site scripting (XSS), and Cross-Site Request Forgery (CSRF).

The control describes multiple testing approaches with automated tools to identify vulnerabilities from development through production. The control outlines testing for injection attacks, session hijacking, and aligning with industry standards like OWASP Top 10 to ensure applications are secure. Adversaries may attempt to exploit a weakness in an Internet-facing host or application by using techniques such as as SQL injection, command injections, Cross-site scripting (XSS), and Cross-Site Request Forgery (CSRF).

The control describes multiple testing approaches with automated tools to identify vulnerabilities from development through production. The control outlines testing for injection attacks, session hijacking, and aligning with industry standards like OWASP Top 10 to ensure applications are secure. An adversary may steal web application or service session cookies and use them to gain access to web applications, internet services, or cloud services, as an authenticated user without needing credentials.

The control describes multiple testing approaches with automated tools to identify vulnerabilities from development through production. The control outlines testing for injection attacks, session hijacking, and aligning with industry standards like OWASP Top 10 to ensure applications are secure. Adversaries can use stolen session cookies to authenticate to web applications and services. Authentication cookies are commonly used in web applications, including cloud-based services, after a user has authenticated to the service so credentials are not passed and re-authentication does not need to occur as frequently.

The control describes multiple testing approaches with automated tools to identify vulnerabilities from development through production. The control outlines testing for injection attacks, session hijacking, and aligning with industry standards like OWASP Top 10 to ensure applications are secure. Adversaries may forge web cookies that can be used to gain access to web applications or Internet services. Web applications and services (hosted in cloud SaaS environments or on-premise servers) often use session cookies to authenticate and authorize user access.

The control requires prioritized remediation based on risk assessment and CVSS scores, automated patch management, and integration of remediation tools into CI/CD pipelines to address vulnerabilities as early as possible in the development lifecycle.

The control requires prioritized remediation based on risk assessment and CVSS scores, automated patch management, and integration of remediation tools into CI/CD pipelines to address vulnerabilities as early as possible in the development lifecycle.

The control requires prioritized remediation based on risk assessment and CVSS scores, automated patch management, and integration of remediation tools into CI/CD pipelines to address vulnerabilities as early as possible in the development lifecycle.

The control requires prioritized remediation based on risk assessment and CVSS scores, automated patch management, and integration of remediation tools into CI/CD pipelines to address vulnerabilities as early as possible in the development lifecycle.

The control requires prioritized remediation based on risk assessment and CVSS scores, automated patch management, and integration of remediation tools into CI/CD pipelines to address vulnerabilities as early as possible in the development lifecycle.

This control guidance requires organizations to establish security baseline requirements for different cloud applications. Security requirement examples include access control, encryption, and configuration management for applications to prevent misuse, abuse, and exploitation. When it comes to Cloud Service Hijacking, adversaries may leverage compromised software-as-a-service (SaaS) applications to complete resource-intensive tasks, which may impact hosted service availability.

This control guidance requires organizations to establish security baseline requirements for different cloud applications. Security requirement examples include access control, encryption, and configuration management for applications. Adversaries may use an existing, legitimate external Web service to exfiltrate data rather than their primary command and control channel. Security requirements should be in place to mitigate the configuration cloud applications and web services that could be abused to exfiltrate data

This control guidance requires organizations to establish security baseline requirements for different cloud applications. Security requirement examples include access control, encryption, and configuration management for applications. In cloud-based environments, adversaries may also use cloud APIs, data pipelines, command line interfaces, or extract, transform, and load (ETL) services to automatically collect data.

This control guidance requires organizations to establish security baseline requirements for different cloud applications. Security requirement examples include access control, encryption, and configuration management for applications. Adversaries may collect sensitive data from cloud storage solutions used for cloud applications.

This control guidance requires organizations to establish security baseline requirements for different cloud applications. Security requirement examples include access control, encryption, and configuration management for applications. Application access tokens are used to make authorized API requests on behalf of a user or service and are commonly used as a way to access resources in cloud and container-based applications and software-as-a-service (SaaS). The baseline security requirements outlined in the implementation guidance can be used to set usage limits and manage user permissions on cloud applications to prevent access to application access tokens.

This control guidance requires organizations to establish security baseline requirements for different cloud applications. Security requirement examples include access control, encryption, and configuration management for applications. An adversary may steal web application or service session cookies and use them to gain access to web applications or Internet services as an authenticated user without needing credentials. The baseline security requirements outlined in the implementation guidance can be used to help reduce the impact of stolen cookies.

This control guidance requires organizations to establish security baseline requirements for different cloud applications. Security requirement examples include access control, encryption, and configuration management for applications. Web applications and services (hosted in cloud SaaS environments or on-premise servers) often use session cookies to authenticate and authorize user access. Access control and permissions can be mitigations to limit and restrict acceptable users granted to access web applications and services.

This control guidance requires organizations to establish security baseline requirements for different cloud applications. Security requirement examples include access control, encryption, and configuration management for applications. Valid accounts in cloud environments may allow adversaries to perform actions to achieve Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Access control and account management related to cloud accounts for web applications may mitigate the abuse of legitimate cloud accounts.

This control guidance requires organizations to establish security baseline requirements for different cloud applications. Security requirement examples include access control, encryption, and configuration management for applications. Adversaries may achieve persistence by leveraging OAuth application integrations in a software-as-a-service environment. Adversaries may create a custom application, add a legitimate application into the environment, or even co-opt an existing integration to achieve malicious ends. Review integrations by restricting or limiting users' ability to carelessly add new application integrations into a SaaS environment before a unapproved or potentially malicious applications is introduced to the cloud environment.

This control guidance requires organizations to establish security baseline requirements for different cloud applications. Security requirement examples include access control, encryption, and configuration management for applications. Adversaries may gain access to and use centralized software suites installed within an enterprise to execute commands and move laterally through the network. Configuration management and software deployment applications may be used in an enterprise network or cloud environment for routine administration purposes. These systems may also be integrated into CI/CD pipelines. Ensuing proper system and access control isolation for cloud applications through use of group policy may aid in mitigating this technique.

This control guidance requires organizations to establish security baseline requirements for different cloud applications. Security requirement examples include access control, encryption, and configuration management for applications. Adversaries may abuse serverless computing, integration, and automation services to execute arbitrary code in cloud environments. Many cloud providers offer a variety of serverless resources, including compute engines, application integration services, and web servers. Access control that can restrict the abuse of serverless functions from users and processes can help with mitigating this technique.