What Is Cloud Application Security?
Cloud application security is the process of securing cloud-based software applications throughout the development lifecycle. It includes application-level policies, tools, technologies and rules to maintain visibility into all cloud-based assets, protect cloud-based applications from cyberattacks and limit access only to authorized users.
Cloud application security is crucially important for organizations that are operating in a multi-cloud environment hosted by a third-party cloud provider such as Amazon, Microsoft or Google, as well as those that use collaborative web applications such as Slack, Microsoft Teams or Box. These services or applications, while transformational in nature to the business and its workforce, dramatically increase the attack surface, providing many new points of access for adversaries to enter the network and unleash attacks.
Why Do Organizations Need Cloud Application Security?
In recent years, many organizations embraced an agile software development process known as DevOps. This approach combines traditional software development and IT operations to accelerate the development life cycle and rapidly release new software applications.
However, traditional network, application and infrastructure security measures typically do not protect cloud-based applications, thus making them vulnerable to a host of cyberattacks during development.
Organizations that are leveraging the cloud, particularly as part of the software development process, must now design and implement a comprehensive cloud security solution to protect against an expanding array of threats and increasingly sophisticated attacks within the cloud environment — including those that target the application level.
Cloud Application Security Framework
The cloud application security framework consists of three main components:
- Cloud security posture management (CSPM) focuses on misconfigurations, compliance and governance, and securing the control plane.
- Cloud Workload Protection Platform (CWPP) oversees runtime protection and continuous vulnerability management of cloud containers.
- Cloud Access Security Broker (CASB) works to improve visibility across endpoints that includes who is accessing data and how it is being used.
CSPM, CWPP and CASB are the trifecta of securing data in and access to the cloud. Organizations are encouraged to deploy all three security methods to optimize their cloud security infrastructure.
An In-depth Look at CSPM, CWPP and CASB
Cloud Security Posture Management (CSPM)
The CSPM automates the identification and remediation of risks across cloud infrastructures, including Infrastructure as a Service (IaaS), Software as a Service (Saas) and Platform as a Service (PaaS).
CSPM is used for risk visualization and assessment, incident response, compliance monitoring and DevOps integration, and can uniformly apply best practices for cloud security to hybrid, multi-cloud and container environments.
CSPMs deliver continuous compliance monitoring, configuration drift prevention and security operations center (SOC) investigations. In addition to monitoring the current state of the infrastructure, the CSPM also creates a policy that defines the desired state of the infrastructure and then ensures that all network activity supports that policy.
CSPMs are purpose-built for cloud environments and assess the entire environment, not just the workloads. CSPMs also incorporate sophisticated automation and artificial intelligence, as well as guided remediation — so users not only know there is a problem, they have an idea of how to fix it.
Some organizations may also have a cloud infrastructure security posture assessment (CISPA), which is a first-generation CSPM. CISPAs focused mainly on reporting, while CSPMs include automation at levels varying from straightforward task execution to the sophisticated use of artificial intelligence.
Cloud Workload Protection Platform (CWPP)
Cloud workload protection platforms (CWPPs) protect workloads of all types in any location, offering unified cloud workload protection across multiple providers. They are based on technologies such as vulnerability management, antimalware and application security that have been adapted to meet modern infrastructure needs.
Cloud Access Security Broker (CASB)
Cloud access security brokers (CASBs) are security enforcement points placed between cloud service providers and cloud service customers. They ensure traffic complies with policies before allowing it access to the network. CASBs typically offer firewalls, authentication, malware detection, and data loss prevention.
Cloud Application Security Threats
Cloud applications are vulnerable to a wide range of threats that may exploit system misconfigurations, weak identity management measures, insecure APIs or unpatched software. Here we review some of the most common threats organizations should consider when developing their cloud application security strategy and solution.
Misconfigurations are the single largest threat to both cloud and app security. These errors can include misconfigured S3 buckets, which leave ports open to the public, or the use of insecure accounts or an application programming interface (API). These errors transform cloud workloads into obvious targets that can be easily discovered with a simple web crawler. In the cloud, the absence of perimeter security can make those mistakes very costly. Multiple publicly reported breaches started with misconfigured S3 buckets that were used as the entry point.
Because many application security tools require manual configuration, this process can be rife with errors and take considerable time to set up and update. To that end, organizations should adopt security tooling and technologies and automate the configuration process.
APIs are often the only organizational asset with a public IP address. This can make them an easy target for attackers, especially if they are insecure due to lackluster access controls or encryption methods.
Insufficient Visibility and Threat Detection
The shift to the cloud is a relatively recent phenomenon for many organizations. This means that many companies may not have the security maturity needed to operate safely in a multi-cloud environment.
For example, some vulnerability scanners may not scan all assets, such as containers within a dynamic cluster. Others cannot distinguish real risk from normal operations, which produces a number of false alarms for the IT team to investigate.
As such, organizations must develop the tools, technologies and systems to inventory and monitor all cloud applications, workloads and other assets. They should also remove any assets not needed by the business in order to limit the attack surface.
Misunderstanding the “Shared Responsibility Model”(i.e., Runtime Threats)
Cloud networks adhere to what is known as the “shared responsibility model.” This means that much of the underlying infrastructure is secured by the cloud service provider. However, the organization is responsible for everything else, including the operating system, applications and data. Unfortunately, this point can be misunderstood, leading to the assumption that cloud workloads are fully protected by the cloud provider. This results in users unknowingly running workloads in a public cloud that are not fully protected, meaning adversaries can target the operating system and the applications to obtain access. Even securely configured workloads can become a target at runtime, as they are vulnerable to zero-day exploits.
Shadow IT, which describes applications and infrastructure that are managed and utilized without the knowledge of the enterprise’s IT department, is another major issue in cloud environments. In many instances, DevOps often contributes to this challenge as the barrier to entering and using an asset in the cloud — whether it is a workload or a container — is extremely low. Developers can easily spawn workloads using their personal accounts. These unauthorized assets are a threat to the environment, as they often are not properly secured and are accessible via default passwords and configurations, which can be easily compromised.
Lack of a Comprehensive Cloud Security Strategy
As workloads move to the cloud, administrators continue to try and secure these assets the same way they secure servers in a private or an on-premises data center. Unfortunately, traditional data center security models are not suitable for the cloud. With today’s sophisticated, automated attacks, only advanced, integrated security can prevent successful breaches. It must secure the entire IT environment, including multi-cloud environments as well as the organization’s data centers and mobile users. A consistent, integrated approach that provides complete visibility and granular control across the entire organization will reduce friction, minimize business disruption and enable organizations to safely, confidently embrace the cloud.
Cloud Application Security Best Practices From CrowdStrike
Organizations must design and implement a comprehensive security solution to protect against an expanding array of threats and increasingly sophisticated attacks within the cloud environment, including those related to cloud applications. To do this, a cloud security strategy should adhere to the following principles:
1. Focus on the Adversary
In all areas of security, including the cloud, it is critical to understand your adversaries and their modus operandi: who they are, what they want, what they must accomplish to get it and how that maps to an attack surface. CrowdStrike has observed that many of the same adversaries are active in the cloud and in other parts of the IT landscape.
The difference is that the cloud offers adversaries the opportunity to use a new set of tactics, techniques and procedures (TTPs).
2. Reduce the Risk of Exposure
Every cloud-based application or workload expands the organization’s attack surface, creating more avenues of entry for would-be attackers.
There are two main ways to reduce the risk of exposure:
- Improve visibility across the entire cloud environment by maintaining an inventory of all cloud applications, workloads and other assets.
- Limit the attack surface by continually searching for and removing applications or workloads that are not needed to run the business.
3. Develop and Implement a Cloud Security Policy, Framework and Architecture
Develop and apply consistent policies to ensure the ongoing security of all cloud-based assets. These policies should define which users will have access to applications and how access will be authenticated and granted through advanced security measures such as multifactor authentication (MFA) and identity and access management (IAM) methods.
Organizations must also develop a comprehensive security strategy that integrates all elements of cybersecurity, including network security, infrastructure security, endpoint security and cloud security. The cloud security architecture should address several critical aspects of the infrastructure: data protection, monitoring and visibility, threat detection, cloud governance, compliance with relevant regulations, and security measures set in place for physical components of the infrastructure.
4. Monitor the Attack Surface
It is important to continue to look for ways to improve visibility into the necessary attack surface. This makes it more challenging for adversaries to hide and also drives up their attack costs.
This approach consists of deploying the CrowdStrike Falcon® agent on all cloud workloads and containers and employing the CrowdStrike Falcon OverWatch™ team to proactively hunt for threats 24/7. In addition, CrowdStrike uses specific cloud-native indicators of attack (IOA), analyzes machine learning (ML) patterns and performs free-form threat hunting, looking for hands-on keyboard activity by adversaries within CrowdStrike’s cloud workloads and control plane.
This level of visibility coupled with proactive threat hunting has allowed CrowdStrike to detect subtle, nearly imperceptible behaviors with uncanny accuracy, such as an incident in which an adversary was probing for the existence of certain S3 buckets. Those buckets were not publicly accessible, and they were named in a way that made using brute force impossible, which prompted CrowdStrike analysts to investigate how the adversary could have obtained a list of the S3 buckets.
After considerable research, CrowdStrike intelligence sources surmised that the adversary was probably pulling S3 bucket names from sampled DNS request data they had gathered from multiple public feeds. That type of data is easily obtained by accessing resources from public Wi-Fi. The lesson here is that the adversary sometimes has more knowledge of and visibility into an organization’s cloud footprint than you might think.