The top 4 pitfalls with cloud identities (and how to avoid them)
Organizations face many challenges when it comes to securing cloud identities. They must ensure cloud services are properly configured, have clear visibility into their cloud identities, understand who can take what actions, and determine whether the actions of human and non-human users are malicious or inappropriate.
Unfortunately, teams often find themselves waving the white flag and granting admin privileges to their entire cloud identities for the sake of speed. Overwhelmed by the need to address individual requests for access, cloud developers may choose expedience over security by opening up permissions more broadly than is required. There are more than 35,000 possible permissions from AWS, Azure, and Google Cloud alone.
Cloud identity management is a tough nut to crack. And the data shows that most organizations continue to struggle. Fortunately, it’s possible for teams to prevent their identities from being exposed and detect identity threats before it’s too late. Here’s how.
A cloud identity crisis
Misconfiguration remains a leading cause of cloud data breaches. Why? Cloud developers can quickly spin up or down compute, storage, and database services all on their own. This can make it difficult to know what’s actually running in your cloud at any specific point in time. Further, cloud service providers offer a number of configuration settings and parameters for each service, which can make it hard to determine what resources are at risk.
The situation is even more dire when considering the state of cloud entitlement management. Given the complex nature of the cloud and the speed of innovation, cloud users and entities are typically over-permissioned, with the intention of right-sizing access at a future date. This important step, however, rarely happens. And the fact that machine identities typically outnumber humans by an order of magnitude only further exacerbates the issue.
In a recent study on cloud security posture management (CSPM) trends, Enterprise Strategy Group (ESG) found that three of the of five top misconfiguration issues experienced by respondents, were overly permissive user accounts, overly permissive service accounts, and unprotected cloud secrets.
These excess entitlements, dormant cloud identities, and toxic combinations leave organizations highly exposed to cloud breach, account takeover, and data exfiltration. For example, in the now infamous Capital One breach, while the Amazon S3 bucket containing sensitive customer information was not directly exposed to the public internet, an EC2 instance with an excessive identity and access management (IAM) role was likely to blame for the event.
Most security breaches and incidents involve external actors using compromised credentials or insiders maliciously or accidently abusing their access. According to Verizon, “82% of breaches involve the human element,” such as the use of compromised credentials, phishing, misuse, or mistakes.
In light of those facts, understanding what cloud identities are doing is essential. However, monitoring behavior can be very complex, labor intensive, and expensive. It usually requires stitching together disparate data from multiple solutions and writing and maintaining endless sets of rules — tall tasks for thin security teams.
Given the active black market for stolen credentials and an increasing number of known attacks against multi-factor authentication (MFA), there is good reason to believe that cloud identity threats will continue unabated.
Something’s got to give.
Top 4 cloud identity pitfalls to avoid
How can organizations both prevent identity risk exposure and detect identity threats in progress? Let’s take a look at how to avoid the most common pitfalls, steer clear of costly mistakes, and successfully accomplish cloud identity management.
1. Beware of misconfigurations
This one is pretty basic, but it bears repeating: improper cloud configurations — specifically misconfigurations tied to cloud identities — leave organizations vulnerable to security events and more susceptible to breaches. Organizations should implement automated measures to continuously discover cloud resources and services and then assess their configurations for identity-related risks. These cloud identity risks include weak and default passwords, hardcoded secrets/keys, no MFA, wildcard permissions, and more. Organizations can also gain quick visibility by using industry frameworks and best practices from the Center for Internet Security (CIS), PCI Security Standards Council, and International Organization for Standardization (ISO) and by writing custom policies to meet the specific business needs.
Finally, organizations can effectively cut through the alert noise with new technologies like attack path analysis. These types of security functions can pinpoint the riskiest misconfigured assets and allow organizations to see exactly how an attacker could exploit a misconfiguration to compromise a critical host or high-value resource.
2. Don’t ignore security during development
Another way for organizations to reduce exposure from cloud service misconfigurations is to build security into development. Finding and fixing misconfigurations and vulnerabilities early limits your cloud attack surface and creates fewer runtime issues. It’s also an order of magnitude less expensive to fix security flaws early, versus fixing them in production.
But, remember, it’s shift left — not shove left. By prioritizing the developer experience, security teams can foster a stronger sense of trust and collaboration across different departments. Organizations should empower developers to self-service the security of their code without the need to context-switch out of existing toolchains and workflows. Give developers frictionless guardrails that only interrupt them when something bad is found, instead of gates that stop them for no apparent reason. And be sure security teams are providing developers with the context and guidance they need so that they can quickly understand what risks need their immediate attention.
3. Don’t let privileges go unchecked
Traditional wisdom calls for a least-privileged approach to granting access. However, with more than 35,000 possible permissions from AWS, Azure, and Google Cloud alone, determining what permissions are needed is no easy task. The temptation to grant admin access to most users and services lingers heavily in the background because it is easy, fast, and ensures frictionless development and operations. However, it also creates a very dangerous and unnecessary level of risk.
Microsoft recently found that more than 50% of cloud identities are super admins, and only about 1% of granted permissions are actually used.
Strong cloud identity security starts with clear visibility. Organizations should use an automated approach that dynamically discovers cloud identities and their associated entitlements. This way, you will have a full and always up-to-date inventory of your cloud users, resources, groups, and roles. Next, they should determine the net-effective permissions for each cloud identity by automatically correlating identity and resource-based permissions. This provides visibility into which identities have access to high-value databases or which can perform certain actions, like making the database public.
Finally, to right-size permissions and limit identity risk exposure, you will want to be able to understand which entities and permissions are used (and how frequently) and, conversely, those that are never used or have remained dormant for an extended period of time. These usage patterns, along with other risk factors like toxic access combinations and role chaining, will allow you to quickly pinpoint which cloud identities to focus on first.
4. Maintain a watchful eye
Even the most effective least privilege program cannot prevent credentials and accounts from being compromised or from malicious insiders wreaking havoc. Secure cloud identity management requires a defense-in-depth approach that includes cloud identity risk prevention and cloud identity threat detection. As such, organizations must actively monitor human and non-human activities to detect unusual behavior that may be a sign of an attack in progress.
Automated tools can help organizations continuously collect, monitor, and analyze massive amounts of data to detect unusual behavior, account compromise, and malicious or accidental insider threats. To avoid the toil of patching disparate data points together from across the cloud-native lifecycle, organizations should find a solution with a unified data model of all cloud user and service behaviors and activities from code to cloud.
Gain control over cloud identity security
Avoid these top cloud identity security pitfalls with a clear understanding of your cloud identity architecture and its risks and with the ability to detect potential threats in progress. Identify cloud misconfigurations early in development and continuously at runtime. Gain visibility of all cloud identities and permissions and prioritize which ones pose the greatest risk. And, lastly, detect both bad actors that are using compromised credentials and keys and malicious or accidental insider threats associated with access abuse.