The Cloud Security Alliance (CSA) recently published its annual report on cloud security top threats for 2022, entitled "Top Threats to Cloud Computing—Pandemic Eleven." The CSA Top Threats Working Group surveyed over 700 professionals on security issues in the cloud industry to create the report. Importantly, this year’s survey shows broad recognition that the cloud customer is increasingly responsible for security rather than the cloud service provider (CSP).
In the “shared responsibility” model, pioneered by AWS but now widely adopted across the industry, the cloud service provider is responsible for the security of the underlying infrastructure, and the customer is responsible for the security of everything they put in the cloud, such as their data, workloads, and applications.
The CSA Top Threats to Cloud Computing—Pandemic Eleven are:
- Insufficient Identity, Credentials, Access, and Key Management
- Insecure Interfaces and APIs
- Misconfiguration and Inadequate Change Control
- Lack of Cloud Security Architecture and Strategy
- Insecure Software Development
- Unsecured Third-Party Resources
- System Vulnerabilities
- Accidental Cloud Data Disclosure
- Misconfiguration and Exploitation of Serverless and Container Workloads
- Organized Crime/Hackers/APT
- Cloud Storage Data Exfiltration
#1 Insufficient Identity, Credentials, Access, and Key Management
Why is identity management rated the number one cloud threat today? Because access to cloud resources is primarily determined by identity, not by network segmentation (though this practice should still be employed as a defense-in-depth mechanism). In other words, identity is the new perimeter. With so many assets, sprawling cloud accounts, and users accessing these from so many different locations, identity is now the primary means of restricting access.
There are currently five times as many machine identities as users, and this is expected to increase exponentially over time.
According to Gartner’s research report, “Managing Privileged Access in Cloud Infrastructure,” by 2023, 75% of security failures will result from inadequate management of identities, access and privileges, up from 50% in 2020. Moreover, identities are not only assigned to users but to machines as well. In fact, there are currently five times as many machine identities as users, and this is expected to increase exponentially over time. Machines are not only static assets like servers, databases, and storage systems but more ephemeral assets like serverless applications and containers. In 2021, Gartner found that more than 95% of accounts in IaaS use, on average, less than 3% of the entitlements they are granted.
For IAM in the cloud, cloud infrastructure entitlements management (CIEM) is the name of the game. With a CIEM solution such as that offered by Uptycs, you can:
- Easily do permission gap analysis to compare what permissions a role has and which it actually uses, so you can remove unnecessary permissions
- Know your IAM risk and governance posture at a glance
- Implement least privilege and zero trust policies
- Spot identity misuse and abuse
- Visually examine identity relationships with mapping
Click Here For A Self-Guided Tour of Uptycs CSPM+CIEM Features
#2 Insecure Interfaces & APIs
APIs are pervasive in the cloud space because everything is code (virtual) and every application needs to communicate with other applications to function. Like traditional applications, API’s are prone to misconfiguration, poor coding practices, lack of authentication and inappropriate authorization. Developers should apply scaling and automation tools for API management and maintain API catalogs, to include details such as internal or external facing, what they are used for, what data is exposed and how they are consumed.
Use an API-security tool to run tests early in the development process. Some tests that should be run include:
- Invalid inputs
- Injection attacks
- Parameter tampering
- Unhandled HTTP methods
- Insufficient logging and monitoring
- Business logic vulnerabilities
- Excessive data exposure
- Authentication, access, and encryption controls
- Excessive loads
#3 Misconfiguration & Inadequate Change Control
Cloud service providers make it easy to launch resources in the cloud, like servers, databases, containerized applications, etc. The downside to this ease of provisioning is the ease of misconfiguration. Assets can be launched in minutes, replicated and distributed throughout your cloud infrastructure, and any misconfiguration errors in base images will be repeated.
Over time a server here or database there are reconfigured on the fly for specific purposes, and keeping track of these changes over the whole infrastructure is difficult. This is also called configuration drift, and it is a real problem in the cloud.
Gartner predicts that through 2025, 99% of cloud security failures will be the fault of the customer, largely due to misconfigurations. Security teams need to know what cloud assets they have, how they are configured, when/what configuration changes occur, and a history of those changes. Aside from careful attention to inventory and configuration of new assets, continual scanning for configuration errors must be conducted because your environment and the threat landscape are ever-changing.
A “safe” configuration today, could easily become a vulnerable one tomorrow. A cloud security posture management (CSPM) solution helps modern defenders monitor all of their cloud assets, their configurations, catch configuration drift and vulnerable configurations, and track configuration change history.
A good guide for safer configuration practices are compliance standards for the cloud and your industry. While compliance is not security, it is an important baseline. Compliance standards for cloud resources, like CIS benchmarks, aim to define the minimum secure configuration standards and are a good place to start when hardening your attack surface. Beyond compliance, you will want to define best practices based on your industry and business priorities. With a good CSPM solution you can create custom compliance rules to meet your specific needs.
#4 Lack of Cloud Security Architecture & Strategy
This is on the cloud adopter. You may find some helpful guidance in this white paper entitled: Architecting a Cloud Security Strategy - Six Strategies to Keep Your Cloud-Based Applications Secure.
In summary, every organization will need a unique security strategy to meet their needs, but some basic guiding principles should be considered in every strategy, such as:
- Understand the shared responsibility model and where your responsibilities lie.
- Incorporate the principle of least privilege from launch and ongoing.
- Manage permission escalation requests for personnel who may need to do this in emergency situations, using automated tools, logging and alerting.
- Establish isolation zones in your cloud network to limit damage during an attack. Ex. set up a DMZ, public zone and private zone, at minimum.
- Protect data at rest and in transit with encryption.
- Apply the principle of separation of duties where necessary for personnel who require some measure of privileged access.
For general cloud security best practices, consult the Cloud Security Alliance’s CSA Security Guidance for Critical Areas of Focus in Cloud Computing.
You should also reference the architecture guides available from AWS, Azure, and Google Cloud to begin to build out your architecture or evaluate what you already have established.
#5 Insecure Software Development
You need to protect developer laptops, crucial endpoints where the magic happens and supply chain vulnerabilities can creep in. Even the most sophisticated and modern cloud-native applications require developers to access the cloud from traditional laptops.
A developer may use their laptop to sign on to multiple resources through an identity provider, download code from a public Git repository, use Chrome extensions for development tasks, access cloud-based SaaS developer tools, use containers and Kubernetes to package and deliver their application, and manage all aspects of the CI/CD build, test, deploy process.
Supply-chain issues are front of mind for most security teams these days, and here we can see there are numerous potential vulnerabilities which can creep into the development process.
A complete laptop-to-cloud approach to securing the innovation supply chain is necessary.
Some companies use piecemeal security tools to monitor endpoints, IAM, cloud workloads and Kubernetes, but this allows for security gaps in coverage, visibility, and defenses. Security visibility, vulnerability and compliance monitoring, and behavior-based threat detection across all assets, endpoint and cloud, provided by one tool, is the optimal solution.
The security of developer machines is a top concern for many Uptycs customers whose business revolves around applications run in the cloud. Read how Flexport uses Uptycs to develop and deliver code securely, secure their cloud instances, and get better visibility into their Windows and macOS endpoint fleet, aggregating telemetry from developers’ laptops for audit, detection, and investigation.
#6 Unsecured Third-Party Resources
A product or service is the sum of all the other products and services it uses, such as APIs, SaaS products, and open source code repositories. Nearly all digital products contain some elements from third-party suppliers. An attacker only needs to find a weakness in the supply chain to exploit all products stemming from it. This is known as supply chain vulnerability.
A software supply chain is composed of the components, libraries, tools, and processes used to develop, build, and publish software. These days most applications are not built from scratch, rather built upon existing code from libraries and pieced together with some original code to produce the final product much faster than reinventing the wheel from the start. There could be vulnerabilities lurking in components of code gathered from multiple sources.
To reduce risk of supply chain vulnerability, begin by using trusted suppliers who practice open reporting of vulnerabilities as they are discovered, and who are quick to provide fixes for any issues. If a new vulnerability in a third-party component of an application is discovered, how then do developers find out if this is running in their applications and requires remediation? Documentation.
A complete and detailed list of all third-party resources, including the specific components used, needs to be maintained and periodically reviewed. This is often referred to as a SBOM (software bill of material), which outlines everything that is required for the software to run (dependencies, libraries, API’s, etc.). Basically, it is a list of ingredients that make up software components.
#7 System Vulnerabilities
New vulnerabilities are discovered continuously, so you should be scanning your systems continuously as well. Cloud security analytics platforms, such as Uptycs, can give you the ability to find out if that newly announced vulnerability is lurking within your cloud systems, so you can take action.
Finding a vulnerability like public access allowed on a single S3 bucket is easy, but what about thousands of buckets, across multiple accounts? The visibility gained with use of a cloud workload protection platform (CWPP) is key to knowing what assets you have running and what vulnerabilities may exist.
Instead of doing regular security audits of your cloud environment several times a year, automate continual checks all day, every day, with a good CWPP tool.
#8 Accidental Cloud Data Disclosure
Accidental data disclosure can happen in the cloud. Some examples of accidental data disclosure include employees sharing links to internal documents in email, which then end up shared with someone outside of the organization. Another is that your developers might persist in the bad habit of hard-coding user credentials into their API keys for third-party cloud services, and then upload the code to a shared repository, like GitHub.
User education could help prevent some of these accidents and you should also provide safer options to these dangerous practices. Even still, you will need data loss prevention tools in your arsenal. Make use of offerings from your cloud provider, such as Google’s CloudDLP.
#9 Misconfiguration & Exploitation of Serverless & Container Workloads
In the cloud, building applications with containers and Kubernetes is the new normal.
Containers, though they may reside on any server, are considered cloud-native devices. They are lightweight virtual machines of sorts, with no operating systems; only the necessary software for running containerized applications. Like virtual machines, they run on top of, but separate from, traditional server hardware.
They can be called, run, and shut down in moments to perform brief operations, and are usually orchestrated to run in harmony as though they were one large application. In this way, a bulky application does not need to be launched and running at all times; instead, individual containers perform the tasks that are called as they are needed, and then shut down again. Popular container runtimes include CRI-O, Docker, and LXC.
You can think of containers as bees in a hive, each with their own job to do, with Kubernetes as the queen bee, establishing the rules of the hive.
Kubernetes, aka K8s, is a container orchestration tool used for management of large container fleets. Cloud providers offer variations of Kubernetes services like AWS EKS, Google Kubernetes Engine, and Azure Kubernetes Service, as well as managed container orchestration platforms like AWS ECS and serverless technologies like AWS Fargate.
Continuous runtime security for containers is essential, as these ephemeral assets may spin up and down in seconds. A CWPP with KSPM (Kubernetes security posture management) analyzes vulnerabilities, compliance, malware, and other malicious threats in container images and running containers, as well as the Kubernetes control plane. Importantly, historical telemetry should also be preserved for historical interrogation and investigation.
Shift left with build time scans. Early in the development stage, you can use a CWPP/KSPM to check container images for known vulnerabilities to stop the launch of vulnerable images before they are released into production. You can integrate these scans into the Jenkins build process to scan Docker images for vulnerabilities at build time.
Click Here For A Self-Guided Tour Of Uptycs CWPP/KSPM Features
#10 Organized Crime, Hackers & APTs
Hackers, especially advanced persistent threat groups, are the very reason we need to strengthen our defenses. The cat-and-mouse game between hackers and cybersecurity professionals will continue so long as there is a chance the hackers can benefit from their activities. While we cannot control what the hackers are up to, we can help you detect their activity in your cloud with behavioral threat detection capabilities.
Proactively, you need to harden your cloud configurations and monitor your compliance and security posture. However, no amount of prevention is ever 100% secure, and at some point a live attack will be occurring in your cloud space. Here you need more than prevention, you need cloud detection and response (CDR). CDR provides cloud threat detection based on suspicious activities threat actors typically perform, such as discovery, lateral movement, and escalating permissions. A CDR will ideally identify and surface suspicious activity within a MITRE ATT&CK dashboard, tracking threat actor behaviors, not just IoCs.
#11 Cloud Storage Data Exfiltration
Data exfiltration attacks are one of the most feared (by the data owners) and the most profitable (by the attackers). A good CDR tool can help you detect these attacks in real time using a combination of IOC and behavior-based threat detection. However, beyond this you will want to proactively make your data as secure as possible. Some basic data hygiene measures are as follows:
Data Residency: Most cloud service providers offer service from various regions around the globe and you will want certain services in regions closest to your customers. Know where your data lives, a.k.a data residency, and know what laws affect data of such residency.
Data Classification: Choose a naming convention such as public, confidential, sensitive, and personally identifiable information (PII). Tag data with classification labels, to make it searchable and sortable by software. Apply security controls on classified data as appropriate, such as IAM policies, encryption at rest and in motion, network segmentation, MFA and so on.
Automate data classification and monitoring with specialized tools capable of content matching and machine learning.
Data Lifecycle: Do not keep data unnecessarily beyond its usefulness. Not only is storage expensive, but storing a lot of defunk data only broadens your attack surface. Have a plan for the data lifecycle, according to its classification and regulatory requirements. Have a staged backup plan (ex. short term, long term, archive), and properly destroy data when it is time.
Key Takeaways
The cloud represents everything-as-code, and the unique vulnerabilities in this environment must be accepted and addressed head on. Do not confuse ease of provisioning with ease of management. Cloud sprawl quickly becomes an overwhelming beast to tame without constant monitoring of your systems.
A strong cloud-native security analytics platform with CIEM, CWPP, CSPM, KSPM, and CDR capabilities will do much to help you secure your cloudscape. Of utmost importance is the visibility and control you gain over sprawling cloud assets. You need to be able to monitor all cloud configurations, vulnerabilities and compliance status, as well as perform real-time threat detection and have fine-grained control over cloud identities and entitlements.
Even when it comes to planning and scaling your cloud architecture, building modern applications using exciting new technologies like containers and serverless, AI, machine learning and big data analytics, visibility is crucial for cloud security. You need the ability to see the big picture, as well as dig into details and get the information you need quickly.
