Cloud Application Security – Best Practices and Security Tools

A cloud application is any program deployed in the cloud rather than hosted on a local machine or server. An on-premises application could become a cloud application by lifting and shifting to a cloud-based server, changing the application’s security profile. Beyond this sort of transitioning, cloud-native application development has grown in popularity. A common approach is rearchitecting an on-premise monolithic application that might be running in a virtual machine to a  microservices architecture running in a Kubernetes, container-based environment. The benefits include improved operational efficiency due to on-demand scaling and increased flexibility in bringing new ideas to market. 

However, these advancements cause a change in security responsibility. Developers can easily create new cloud resources through cloud consoles, infrastructure as code (IaC), or CI/CD pipelines. However, are security best practices being followed when configuring these resources? 

In 2023, 39% of businesses experienced data breaches in their cloud environments. In addition, respondents reported human error as the leading cause of cloud data breaches: It was mentioned by 55% of those surveyed. To ensure that best security practices are followed, cloud application security uses policies, processes, and controls to protect cloud-based applications and data.

This article explores cloud application security by reviewing common security risks related to a modern cloud application architecture. We also consider the various security tools required to gain security oversight of cloud applications, and we end with security best practices for cloud applications.

Summary of key cloud application security concepts

Introduction to cloud application security

A cloud application security risk is the potential for loss of data or a weak spot that could lead to a security incident. A cloud application security threat is a type of attack or adversary. Your cloud application security challenge is to mitigate risks to avoid them becoming threats.

For example, a misconfigured AWS bucket that allows public access is a risk. An attacker trying to discover sensitive data within the AWS bucket is a threat. Your challenge is effectively protecting your cloud resources and sensitive data. Adequate cloud application security involves identifying and remediating/mitigating risks, defending against threats, and overcoming challenges. 

Pegasus Airlines example

In May 2022, a security firm discovered an unprotected AWS S3 bucket containing 6.5 TB of “electronic flight bag” information, including navigation information, proprietary software, and personal information on crew members. The risk in this case, was a misconfigured AWS S3 bucket, and the threat was a malicious actor discovering and exploiting the data. After the incident, the challenge for the organization was securing its other cloud resources.

OWASP Top 10

Although still under development, the OWASP Cloud-Native Application Security Top 10 provides a good overview of common security risks affecting cloud applications:

From a security perspective, cloud application development changes an organization’s attack surface and broadens network perimeters. A common security challenge with cloud-native application architectures is that the security risks above relate to separate services; for example, a monolithic application may have one server to secure. In contrast, a cloud-native application will likely use multiple connected services to provide the application functionality. A microservice architecture breaks a monolithic application into smaller independent components. Each component offers a specific function, and combining multiple functions creates the complete application. Containers are a popular way to implement a microservices architecture.   

In the next section, we will further consider the security risks by using an AWS architecture as a reference.

Cloud application architectures

A cloud application refers to any software application deployed in a cloud environment: private, public, or hybrid. The table below highlights recommended architecture shifts from traditional on-premises to modern cloud applications.

Traditional on-premises		Modern cloud architecture
Monolithic		Decomposed
Designed for predictable scalability		Designed for elastic scale
Relational database		A mix of storage technologies
Synchronized processing		Asynchronous processing
Design to avoid failures (MTBF)		Design for failure (MTTR)
Occasional large updates		Frequent small updates
Manual management		Automated self-management
Snowflake servers		Immutable infrastructure
Source

Modern cloud architecture approaches can lead to reduced costs and improved operational efficiency. However, these changes also bring new security challenges and a shared security responsibility.

Shared security responsibility

The shared responsibility model must be understood when deploying and operating cloud applications. The image below shows who is responsible for security for four main deployment strategies: on-premises, IaaS, PaaS, and SaaS.

The image shows who is responsible for security for four main deployment strategies: on-premises, IaaS, PaaS, and SaaS. (Source)

When moving from an on-premises architecture to IaaS, PaaS, or SaaS, your security responsibility becomes more focused, but that does not mean that it is more straightforward. A particular cloud service or SaaS product may not meet your security needs: For example, the SaaS product may not allow you to restrict access to specific IP addresses or satisfy your data confidentiality requirements. 

Whatever your deployment strategy, you will always have certain responsibilities:

The UK National Cyber Security Centre makes the following recommendation regarding SaaS:

“We recommend SaaS if you can find a service that meets your needs. This model allows you to delegate the most responsibility to your cloud provider and gain [the] most advantage from the security benefits of the provider working at scale.”

– UK NCSC (Source)

In addition, NCSC recommends platform as a service (PaaS) over infrastructure as a service (IaaS). Changing the deployment strategy of your cloud application from IaaS to PaaS can help focus your security efforts. For example, using Google Anthos, you can orchestrate containers with Kubernetes in an environment with consistent security best practices and focus your security efforts on application code and data security. 

Cloud application architecture example

The architecture diagram is an example from AWS showing Elastic Kubernetes Service (Amazon EKS) integration with VMware Cloud. AWS DevOps tools deploy the application images to EKS. You can read more about the different points in this architecture here.

Example AWS cloud application architecture (Source)

Let’s think about the security aspect of this architecture. 

Security responsibility

There are three parties involved in this architecture, with the following responsibilities:

• Customer: Security in the cloud. For example, patching the container images with the latest security updates and providing dev team members with the required permissions to deploy container images.
• VMware: Security of the cloud. For example, ensuring that the software and systems that comprise the VMware cloud on AWS service are secured.
• AWS: Security of the infrastructure. For example, the hardware underlying the Amazon EKS cluster.

The shared security responsibility of the architecture (Source)

Security risks, threats, and challenges

The following table shows a selection of architecture components and example security questions. Although it is not an exhaustive list of security questions, it demonstrates using an architecture diagram to start thinking about security questions and responsibilities.

Cloud application security tools

This section describes and explores the benefits of common tool categories for cloud application security. Consider it a glossary of terms you will encounter when considering your cloud application security requirements. 

Here’s a summary of the tools described below.

Static application security testing (SAST)

SAST tools provide real-time feedback to developers as they code by highlighting vulnerabilities and risky code during the coding process. This is also known as white-box testing.

Interactive application security testing (IAST)

IAST uses sensor modules and software libraries in the application code to perform security testing on the running application. The sensor modules keep track of application behavior, and an alert is issued if a vulnerability is detected.

Dynamic application security testing (DAST)

DAST performs application security testing by applying different attack types to the running application. It is a black-box testing method because it cannot access the application’s source code.

Software composition analysis (SCA)

SCA analyzes all of a codebase to identify third-party libraries and open-sourced components. SCA can help identify security vulnerabilities introduced by external libraries and provide a complete inventory of external code dependencies.

Cloud security posture management (CSPM)

CSPM tools help identify and remediate security risks for your cloud resources. They compare your cloud environment against a defined set of best practices and known security risks. 

Cloud access security broker (CASB)

A CASB is a security tool placed between cloud network users and cloud-based applications to enforce security policies. By generating a model of the expected cloud application usage, a CASB can help identify abnormal behavior.

Cloud workload protection platform (CWPP)

CWPP solutions provide ongoing security by monitoring and managing cloud workloads. CWPPs detect any workloads deployed in your cloud environments and automatically perform assessments, monitor networks, detect issues, and apply security standards based on your organization’s policies.

Cloud infrastructure entitlement management (CIEM)

CIEM aims to help you understand which access entitlements exist across your cloud application. A CIEM can help improve understanding of what a user or system identity can access.

Cloud service network security (CSNS)

CSNS provides cloud network security functions like load balancers, denial of service (DoS) protection, web application and API protection, and SSL/TLS inspection. 

Cloud-native application protection platform (CNAPP)

CNAPP is a term first used by Gartner in 2021 and describes an all-in-one platform that unifies security and compliance capabilities. CNAPPs combine a large number of previously siloed capabilities into a single user interface. These platforms can help security teams collaborate with developers by providing a common platform, following the “shift left” philosophy. 

CNAPP platforms combine the capabilities of multiple security tools into a single platform (Source)

Unified Vulnerability Management (UVM)

A UVM platform enables you to manage assets and vulnerabilities from various security tools within a single platform. A UVM platform can streamline your cybersecurity by providing security data in one place and prioritizing the top security risks. The latest UVM platforms use generative AI models to risk score, correlate findings, and add business context to improve the efficacy of security teams.

Paladin Cloud’s Unified Vulnerability Management prioritization engine unifies findings into a single platform, enabling security teams to focus on the top security risks.

Cloud application security best practices

This section describes five security best practices to follow when developing and operating your cloud application.

Understand your attack surface

Understanding your cloud application attack surface can be challenging. You can only secure what you know about, and developers can mistakenly create new attack vectors. New resources easily expand the network of your cloud environment, microservice architectures can result in multiple publicly accessible endpoints, and serverless technologies mean that assets are constantly appearing and disappearing. 

Establish a security baseline based on the architecture of your cloud application and environment. This baseline should define how each asset should be configured and how each asset is connected, and it should establish the cloud application’s network perimeter. It will also help establish your cloud application’s expected behavior, including the data flow. 

Where is ingress vs. egress activity expected? What are the expected API request rates? Establishing what normal cloud application activity looks like will help you identify anomalous activity due to malicious actors.

Attack surface management (ASM) can help provide visibility into your cloud application’s attack surface: 

• Follow established security best practices and policies, and benchmark your cloud application security against them. Guides like the CIS Benchmarks can help you define a security baseline.
• Use tools that help you map out your cloud resources. Paladin Cloud continuously monitors your cloud environment to identify assets and detect any vulnerabilities, misconfigurations, and security risks.

Implement software supply chain security

Cloud application security involves securing your code from vulnerabilities that attackers could exploit. Outside code and third-party components help speed up the development cycle, but you must understand what open-source code and third-party components your cloud application depends on to avoid introducing unknown security risks. For example, how did your organization respond to the vulnerability found in the Log4j open-source logging library? Where was Log4j included in your cloud application? 

It is unlikely to be practical or cost-effective to remove your cloud applications’ dependence on third-party code, but you can mitigate risks by:

• Knowing which third-party code your cloud application depends on
• Validating the checksums of container images and third-party libraries
• Conducting regular vulnerability scanning and patching
• Providing least privilege access to CI/CD pipelines
• Scanning your application code with automated SCA, SAST, and DAST security testing tools, among others. A leading provider of these tools is Contrast Security.

Gain an understanding of IAM

Understanding identity and access management for your cloud provider is fundamental to developing a secure cloud application. According to Gartner, 75% of security failures result from inadequate management of identities, access, and privileges.

The table below links to the IAM services for the three major public cloud providers.

With many organizations adopting a multi-cloud strategy, it is crucial to understand the differences between IAM services. Each provider implements some variant of role-based access control (RBAC). To use IAM securely for your cloud application, follow these best practices:

• Enforce least privilege by granting the most limited predefined or custom roles that meet your needs.
• Use non-human identities to control access between services rather than embedding access keys in code.
• Use time-limited credentials wherever possible.

Avoid misconfigurations

The scope of cloud application security extends beyond your application code. Security misconfigurations can occur for cloud resources, services, and infrastructure as code (IaC) implementations. IaC tools like Ansible, Terraform, and Severless help you deploy consistent cloud resource configurations. In the same way that compiling your application code always produces the same binary, IaC generates the same environment every time it deploys.

For IaC to work effectively, your development team must change the IaC source, not the target cloud resource. Of course, IaC can introduce security misconfigurations if security best practices are not followed when writing your IaC.

Use Unified Vulnerability Management across security tools and cloud environments

More than three-quarters (79%) of organizations have more than one cloud provider, so you are likely using multiple security tools to monitor your cloud applications. The leading cloud providers make available the following security tools:

• Amazon Web Services: AWS Security Hub
• Microsoft Azure: Microsoft Defender for Cloud
• Google Cloud: Security Command Center

Each tool integrates well with the provider’s services, but maintaining security oversight of a cloud application that spans two or more cloud providers can be challenging and time-consuming. Furthermore, the cloud application security tools section showed many tool categories. Using these tools in isolation can mean that business context is lacking from the generated alerts, and duplicate alerts can lead to alert fatigue. 

A Unified Vulnerability Management platform like Paladin Cloud connects with your existing security tools and consolidates findings into a single dashboard. You can connect vulnerability scanners, CSPMs, and app code scanners into Paladin Cloud, and the AI-powered Prioritization Engine will correlate findings to identify the top security risks. With this approach, security operation and development teams can maintain oversight of security incidents from a shared environment.

Last thoughts on cloud application security

Cloud application security is a broad topic and involves more than just your application’s code. It needs to encompass the underlying cloud infrastructure and the data used by your application. See our enterprise data security article for further information on securing your cloud application data.

Start by understanding which deployment strategy your cloud application is using. Your security responsibility will be most significant for IaaS. If PaaS and SaaS services fit your cloud application requirements, this can help focus your cloud application security efforts. 

Use your cloud application architecture diagram to understand your security responsibilities and risks. Consider which risks from the OWASP Cloud-Native Application Security Top 10 apply to your architecture. As your cloud application develops, ensure that you understand how its attack surface changes. New attack vectors can be introduced due to misconfigured and newly created cloud resources.

There are numerous cloud application security tools that will produce findings at multiple stages of your cloud application development cycle. The major public cloud providers offer built-in security solutions, but it can be time-consuming to review multiple dashboards, and outputs from different services need to be standardized. Viewing their findings in isolation can result in missing critical business context. 

The latest breed of security tools is not looking to replace existing security tools; instead, it is unifying findings into a single platform. Generative AI models can correlate findings to prioritize the top security risks affecting your cloud application. Paladin Cloud is a leading example of a Unified Vulnerability Management platform that is using generative AI to prioritize security alerts.