14/11/2024 | News release | Archived content
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:
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
Taking a few key actions can prevent toxic cloud trilogies in your cloud environment. Here's what we recommend:
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.