Skip navigation
cloud access protocols and IAM security threats Konrad Bąk / Alamy Stock Photo

Cyberattackers Increasingly Target Cloud IAM as a Weak Link

Cloud access protocols in place? Check again. IAM is under attack by cyberbullies according to experts at Black Hat.

Cybercriminals always look for blind spots in access management, be they misconfigurations, poor credentialing practices, unpatched security bugs, or other hidden doors to the corporate castle. Now, as organizations continue their modernizing drift to the cloud, bad actors are taking advantage of an emerging opportunity: access flaws and misconfigurations in how organizations use cloud providers' identity and access management (IAM) layers.

In a talk on Wednesday, Aug. 10 at Black Hat USA entitled "IAM The One Who Knocks," Igal Gofman, head of research for Ermetic, will offer a view into this emerging risk frontier. "Defenders need to understand that the new perimeter is not the network layer as it was before. Now it's really IAM — it's management layer that governs all," he tells Dark Reading.

Complexity, Machine Identities = Insecurity

The most common pitfall that security teams step into when implementing cloud IAM is not recognizing the sheer complexity of the environment, he notes. That includes understanding the ballooning amount of permissions and access that software-as-a-service (SaaS) apps have created.

"Adversaries continue to put their hands on tokens or credentials, either via phishing or some other approach," explains Gofman. "At one time, those didn't give much to the attacker beyond what was on a local machine. But now, those security tokens have much more access, because everyone in the last few years moved to the cloud, and have more access to cloud resources."

The complexity issue is particularly piquant when it comes to machine entities — which, unlike humans, are always working. In the cloud context, they're used to access cloud APIs using API keys; enable serverless applications; automate security roles (i.e., cloud access service brokers or CASBs); integrate SaaS apps and profiles with each other using service accounts; and more.

Given that the average company now uses hundreds of cloud-based apps and databases, this mass of machine identities presents a highly complex web of interwoven permissions and access that underpin organizations' infrastructures, which is difficult to gain visibility into and thus difficult to manage, Gofman says. That's why adversaries are seeking to exploit these identities more and more.

"We are seeing a rise in the use of non-human identities, which have access to different resources and different services internally," he notes. "These are services that speak with other services. They have permissions, and usually broader access than humans. The cloud providers are pushing their users to use those, because at the basic level they consider them to be more secure. But, there are some exploitation techniques that can be used to compromise environments using those non-human identities."

Machine entities with management permissions are particularly attractive for adversaries to use, he adds.

"This is one of the main vectors we see cybercriminals targeting, especially in Azure," he explains. "If you don't have an intimate understanding of how to manage them within the IAM, you're offering up a security hole."

How to Boost IAM Security in the Cloud

From a defensive standpoint, Gofman plans to discuss the many options that organizations have for getting their arms around the problem of implementing effective IAM in the cloud. For one, organizations should make use of cloud providers' logging capabilities to build a comprehensive view of who — and what — exists in the environment.

For more IAM Security expertise, view the entire article on Dark Reading.

TAGS: Security
Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.