- Report warns long-lived credentials remain a significant security risk
- Outdated access keys increase vulnerability across cloud platforms
- Automated credential management is crucial for cloud security
As cloud computing adoption continues to rise, organizations increasingly rely on platforms such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud for their infrastructure and services, however, this means their security risks also grow more complex.
The recent Datadog State of Cloud Security 2024 report reveals one particularly concerning issue – the use of long-lived credentials, which pose significant security threats across all major cloud providers.
Despite advancements in cloud security tools and practices, many organizations still use long-lived credentials, which do not expire automatically.
The prevalence of long-lived credentials
Long-lived credentials, particularly those that are no longer actively managed, can serve as an easy target for attackers. If leaked or compromised, they could provide unauthorized access to sensitive data or systems. The longer these credentials remain in place without rotation or monitoring, the greater the risk of a security breach.
Datadog’s report reveals nearly half (46%) of organizations still have unmanaged users with long-lived credentials. These credentials are particularly problematic because they are often embedded in various assets such as source code, container images, and build logs. If these credentials are not properly managed, they can easily be leaked or exposed, providing an entry point for attackers to access critical systems and data.
Almost two-thirds 62% of Google Cloud service accounts, 60% of AWS Identity and Access Management (IAM) users, and 46% of Microsoft Entra ID applications have access keys that are more than a year old.
In response to these risks, cloud providers have been making strides toward improving security. Datadog’s report notes that the adoption of cloud guardrails is on the rise. These guardrails are automated rules or configurations designed to enforce security best practices and prevent human error.
For instance, 79% of Amazon S3 buckets now have either account-wide or bucket-specific public access blocks enabled, up from 73% the previous year. However, while these proactive measures are a step in the right direction, long-lived credentials remain a major blind spot in cloud security efforts.
Furthermore, the report added there is a conspicuously high number of cloud resources with overly permissive configurations.
About 18% of AWS EC2 instances and 33% of Google Cloud VMs were found to have sensitive permissions that could potentially allow an attacker to compromise the environment. In cases where a cloud workload is breached, these sensitive permissions can be exploited to steal associated credentials, enabling attackers to access the broader cloud environment.
In addition, there is the risk of third-party integrations, which are common in modern cloud environments. More than 10% of third-party integrations examined in the report were found to have risky cloud permissions, potentially allowing the vendor to access sensitive data or take control of the entire AWS account.
What’s more, 2% of these third-party roles do not enforce the use of External IDs, leaving them susceptible to a “confused deputy” attack, a scenario where an attacker tricks a service into using its privileges to perform unintended actions.
“The findings from the State of Cloud Security 2024 suggest it is unrealistic to expect that long-lived credentials can be securely managed,” said Andrew Krug, Head of Security Advocacy at Datadog.
“In addition to long-lived credentials being a major risk, the report found that most cloud security incidents are caused by compromised credentials. To protect themselves, companies need to secure identities with modern authentication mechanisms, leverage short-lived credentials and actively monitor changes to APIs that attackers commonly use,” Krug added.
You might also like
https://cdn.mos.cms.futurecdn.net/UpZ4RY9bVuxJmQZZW8iraj-1200-80.jpg
Source link
udinmwenefosa@gmail.com (Efosa Udinmwen)
