The Tenable Cloud Risk Report 2024 reveals that nearly four in 10 organizations have workloads that are publicly exposed, contain a critical vulnerability and have excessive permissions. Here’s what to watch for in your organization.

In a “GPS mapping” of today’s most pressing cloud security issues, the Tenable Cloud Risk Report 2024 from Tenable Cloud Research revealed serious flaws across workloads, identities, containers, storage and Kubernetes.;

Particularly concerning was the discovery that nearly four in 10 organizations (38%) have an elevated level of exposure from workloads bearing an especially risky blend of security gaps. We called this blend a “toxic cloud trilogy,” defined as any cloud workload having these three risk factors:

• A critical vulnerability
• Excessive permissions
• Public exposure

Like the big bad wolf in the Little Red Riding Hood fable, a toxic cloud trilogy masks its existence and severity in the cloud environment. The masking makes these high risks hard to spot, prioritize and remediate. In this blog we discuss the implications of the toxic cloud trilogy and offer guidance for actions to avoid them.

Why we conducted this research

To help our customers — and ourselves — better understand the most prevalent risks in cloud environments, the Tenable Cloud Research team analyzed telemetry from millions of cloud resources in active production across multiple public cloud repositories. Conducted in the first half of 2024, the research included cloud workload and configuration information. To determine the most exploitable vulnerabilities the team applied Tenable’s Vulnerability Priority Rating (VPR) to common cloud CVEs.

Why a toxic cloud trilogy increases risk

A toxic cloud trilogy increases risk by making the workload’s weaknesses easier for attackers to exploit — and making the scope of exploitation potentially greater.

Cloud security involves layers of defense to prevent breaches if a given layer fails; a toxic trilogy effectively erodes these layers. Bad actors seek out critical vulnerabilities or publicly accessible assets. Finding one, they can commandeer highly privileged permissions or roles to burrow their way in, accessing — and even exfiltrating — sensitive data. For example, an attacker can modify access policies or elevate privileges, moving laterally and deploying resources to gain access to even more sensitive areas.

Prevalence of toxic cloud trilogies in organizations worldwide

The work of mitigating toxic cloud trilogies needs to be high on a security team’s “to do” list. That’s easier said than done. Let’s explore the challenges organizations face in addressing such exposures.

Organizational causes of toxic cloud trilogies

How are such risky combinations getting through? Fault lines can be organizational, due to siloed tooling that limits visibility. Another contributing factor is the distributed ownership of systems, spanning development, IT and cybersecurity teams, among others. Each of these teams may have a different level of risk appetite.

Here are three examples of how these factors contribute to the creation of toxic cloud trilogies:

• Didn’t see it. Siloed tooling looks for specific kinds of flaws. They can create false positives that don’t show the full context of an identified exposure, such as a vulnerability not being in runtime so not exploitable.
• Will the cloud risk owner please stand up? Depending on the organization — its size and organizational structure — many roles may play a part in managing cloud risk. You’d need to have a holistic view to catch a toxic trilogy.
• Risk hungry? The National Institute of Standards and Technology (NIST) defines cyber risk appetite as “The types and amount of risk, on a broad level, an organization is willing to accept in its pursuit of value.” While an organization may have its strategic risk appetite clearly spelled out, different teams with conflicting business goals may make compromises in implementation that clear the way for toxic cloud trilogies.

Why toxic cloud trilogy factors persist in organizations

Let’s take a closer look at each factor implicated in a toxic cloud trilogy and why these issues can be so difficult for organizations to address.

Critical vulnerabilities

Attackers abuse cloud vulnerabilities — flaws in cloud-based software — to gain unauthorized access, steal sensitive data and/or disrupt services. You would expect published CVEs to be easy, low-hanging fruit for cybersecurity teams to act on quickly. Doing so prevents or dismantles a toxic cloud trilogy. Yet, to our surprise, many high risk vulnerabilities in the data we examined remained unremediated even a month after a CVE was published.

High risk vulnerabilities remained largely unremediated after 30 days.

Why does remediating a vulnerability take so much time? One reason may be that, regardless of who technically “owns” vulnerability management in the organization, it requires the involvement of several teams. Depending on the organization’s structure, those involved in the process of remediating vulnerabilities could include security teams alerting vulnerability management teams, applications teams issuing software update requests of operating systems teams and DevSecOps teams needing to make related changes in CI/CD pipelines.

Another “drag” factor in resolving vulnerabilities may be tactical: teams see vulnerability remediation as time-consuming, requiring an arbitrary cycle of tasks. Adopting conventional wisdom, they may try to save cycles by taking a “batch the patch” approach: delaying the fix until every relevant patch is available. While this approach is understandable from a time management perspective, it places operational efficiency above security.

Excessive permissions

Attackers target credentials, putting identity and access management (IAM) on the radar of everyone responsible for securing the cloud. Overprivileged human identities are a known, high-impact risk factor in identity-based attacks. Overprivileged non-human identities are the key impact factor in breaches based on application vulnerabilities. All are part of the same IAM system.

87% of human identities in AWS have critical or high excessive permissions

Our research revealed extensive instances of excessive permissions in both human and non-human identities. We also found that human identities are granted significantly more risky excessive permissions than non human identities. For example, in the Amazon Web Services (AWS) permissions we studied, the vast majority had excessive critical and high risk permissions.

Human and non-human identity permissions in AWS

Avoiding risky permissions is a cloud security best practice, and also, in many cases, a compliance requirement, achieved by acting on least privilege implementation.

At the helm of permissions and access management are the IAM teams. Aided by no shortage of cloud providers and third-party tools — including AWS IAM, Microsoft Azure Active Directory, Google Cloud Platform (GCP) IAM; AWS IAM Access Analyzer, Azure Privileged Identity Management (PIM), Okta and Auth0 — they work to create and maintain access permissions structures and policies, and apply least privilege to the extent possible.

Security teams, on the other hand, are at another helm, and using other tools, to spot exposures. They are looking not only at permissions but also workloads, data, applications and infrastructure as a whole. This broader approach informs security teams about permissions-related risks as well as granular policy refinements that enforce least privilege, including when elevated permissions should be granted but limited by time.

By design, IAM tools lack full stack and even multi-cloud entitlements context; they may recommend least privilege yet from a narrow permissions and policy lens. They are unable to bring into focus access risk that feeds into a vulnerability or resource to create a toxic cloud trilogy.

IT and security leaders need to enable their IAM and security teams to work closely with each other. Do they?

And why are human identities more likely to be assigned excessive privileges? In some cases, project managers prevail upon their IT colleagues to elevate privileges for an urgent business need. Note, too, that developers may be using programmatic, IAM role-based templates to define access for non-human identities.

Public exposure

The phrase “public exposure” conjures up an actor performing before an audience. In cloud infrastructure, public assets — databases, websites, email servers and other online services — are just that: exposed to external networks so legitimate parties outside the organization can access them.

Risk increases when assets are unintentionally public with either excessive permissions and/or a vulnerability. Worse is when the asset contains sensitive data. Organizations need to be able examine whether an asset is configured as public. In the case of publicly exposed cloud storage, they need to be able to discover and classify sensitive data contained within, including who can access it and how it is used, so any remediation measures can be prioritized accordingly.

29% of organizations have public-facing storage buckets

Our research found that 96% of organizations have public-facing cloud assets; 29% of organizations have public-facing storage buckets. It is essential to know if this exposure is due to a misconfiguration, such as an unpatched resource or overprivileged access. If oversight is at play, it may be due to business drivers such as time to market or lack of cloud security personnel, or the need to implement guardrails, policies or visibility. Context and tools are needed to be able to monitor and close such exposure, and downgrade permissions to the minimal needed.

Key actions to prevent toxic cloud trilogies

Taking a few key actions can prevent toxic cloud trilogies in your cloud environment. Here’s what we recommend:

• Treat your cloud infrastructure security as a whole. Attackers have figured out that multi-cloud integrations offer fertile ground. Put your multiple cloud environments under one security roof, unifying workload monitoring, entitlements management and security posture, for comprehensive visibility. Include contextual analysis to reveal which cloud assets hold sensitive data and who can access them.
• Don’t wait, remediate CVEs. Make it your organization’s security culture to quickly address severe vulnerabilities. Context matters when prioritizing vulnerabilities for remediation. The ability to quickly analyze which systems contain a vulnerability, which users interact with that system, what data is stored there and whether or not it’s publicly accessible will enable you to prioritize those vulnerabilities which represent the greatest risk to your organization. You’ll be able to give prescriptive guidance to the other teams involved in your vulnerability remediation process.
• Don’t underestimate permissions risk. Analyze all identities dynamically, enabling teams to identify access risk and confidently resolve the excessive permissions that lead to toxic cloud trilogies. Apply least privilege principles, including through time-saving just-in-time access controls that make developers willing security partners.
• Be aware of public-facing assets and configurations. External exposure is a double-edged sword — necessary for doing business and a potential source of exposure. Rein in and monitor assets configured as public.

Summary

Our research showed that unwittingly or not, many organizations have unnecessary exposures in their cloud environments. Since we can’t know what a malicious actor will do next, control what you can. Add context to unmask and prioritize security gaps like the cloud toxic trilogy, and close such exposures swiftly.

Learn more