Cloud Threat Report Vol 6

This episode of the Cloud Security Today podcast welcomes back favorite special guests Jay Chen and Nathaniel “Q” Quist to unpack the latest Cloud Threat Report. Join host Matt Chiodi as he shares insights from the report and analyzes the current state of cloud security.

Beginning with an in-depth look at Identity and Access Management (IAM) in cloud security, the guests talk about the latest changes in cloud security. They discuss the report’s findings on permissions and what cloud systems providers are currently doing (or not doing) to help keep cloud data secure. At the end of the episode, Jay and Q give tips on how to stay up-to-date on developments in the cloud security landscape and reveal the next projects that they’re working on. 

If you enjoyed this episode, you can show your support for the podcast by rating and reviewing it and by subscribing to Cloud Security Today wherever you listen to podcasts. 

Show Notes/Timestamps

[2:11] Matt welcomes repeat guests Jay and Q onto the show

[3:36] So, what’s changed for Identity and Access Management over the last year? 

[8:05] Jay lays out what makes good cloud governance so difficult

[11:50] Complicating factors in cloud security

[14:22] What does the research show about permissions and over permissions on cloud systems? 

[17:28] “When you can’t figure out what to do, you add more permissions:” How permissions multiply

[20:19] Are cloud service providers helping or hindering cloud security?

[24:03] Debating the Infrastructure as Code framework

[28:13] Q breaks down the Cloud Threat Actor Index 

[31:32] Q’s top five bad actors on the cloud security landscape

[35:11] Jay gives his recommendations for IAM

[39:55] How you can stay up-to-date on the latest developments in cloud security

[42:10] The next projects that Jay and Q are working on

Links

Check out this episode’s sponsor, Prisma Cloud

Unit 42 reports

IAM-Deescalate Tool

Cloud Sec List

Secure applications from code to cloud.
Prisma Cloud, the most complete cloud-native application protection platform (CNAPP).

Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.

Transcript

Intro (00:01):

This is The Cloud Security Today Podcast, where leaders learn how to get cloud security done. And now, your host, Matt Chiodi

Matt Chiodi (00:13):

On this month's podcast, we once again have Jay and Q from Unit 40 twos threat research team, that's Palo Alto Network's Elite threat research group; to talk about volume six of their cloud threat report. And it's funny because I went back and looked, and you'll hear me talk about this a little bit during the show. Jay and Q have been on the show now three times, and this is simply because people find the research so interesting and so useful, and they're just fun to talk to. In this report, they go very deep into identity and access management in the cloud; IAM, so if you are not overly technical, I don't think it matters you're still going to get something out of this. I encourage you to listen because identity and access management is often one of the biggest holes in cloud applications. So here, what we'll be talking about is mostly infrastructure as a service and platform as a service, but it also applies to SAS.

Matt Chiodi (01:12):

Now, a lot of times people think, Well, I've got my SAS app, and the vendor is taking care of the underlying platform; the underlying infrastructure, but when it comes to the permissions, the identity and access management, this is where you as the consumer of that platform, need to be mindful. You should be mindful because you can have defense in depth, but if you've got some simple identity misconfigurations, I can weave my way all the way around those defenses. So pay attention, take notes, and enjoy the podcast. And one other thing, you know, I only do these on a monthly basis, so this podcast was originally recorded in September of 2022. So if you hear any date references that sound off, you'll know why. Enjoy the episode, and again, if you've got feedback, we would love to hear from you. Send us an email at cloudsectoday@gmail.com.

Matt Chiodi (02:11):

Jay and Q, welcome to the show.

Nathaniel “Q” Quist (02:14):

Thank you so much

Jay Chen (02:14):

Hi, Matt.

Matt Chiodi (02:16):

I think you guys may be the only repeated guest on this show; and this will probably be your third appearance.

Nathaniel “Q” Quist (02:26):

It is number three, and it is pretty awesome,

Matt Chiodi (02:28):

Isn't it Alec Baldwin, who's been on like Saturday Night Live more than any other guest? You guys are like my Alec Baldwin on the show, I appreciate it.

Nathaniel “Q” Quist (02:36):

That's such a compliment, oh, man!

Matt Chiodi (02:40):

Awesome, so we're here to chat about the latest cloud threat, report volume six. I really love this one, and I'm a big fan of these reports. Anytime you guys delve into identity and access management, I always find it super interesting. I think what's interesting is if people have not read the cloud threat reports, they can go out to unit 42.paloaltonetworks.com and you can find all the threat research there. I know you guys do regular threat research, even outside of these kinds of big bang threat reports, but this isn't the first time that you've looked at identity and access management in the cloud. So my question is what's changed over the last year?

Nathaniel “Q” Quist (03:28):

Sure, go ahead Jay.

Jay Chen (03:30):

Okay, it's a fun and challenging research topic to look into; in the past, we mainly looked into how to abuse and exploit IAM to achieve certain goals. For example, we look at how misconfiguration can allow an attacker to identify misconfigured cloud resources exposed to the public internet, or how misconfiguration can allow adversaries to anonymously access into a cloud environment. Or how misconfiguration helps abusing (Inaudible 4:20) permission can achieve privilege escalation. So that's what we've looked at before, but in this report, the biggest difference is that we've got access to millions of records. This is the first time that we had visibility into so much real data in a real production, cloud environment. We were able to analyze these identities to understand how people provision, manage, and use identities in cloud environments; and this is a very unique perspective.

Matt Chiodi (04:57):

This isn't a survey, right? This is real data from real cloud environments.

Jay Chen (05:02):

Absolutely not.

Matt Chiodi (05:04):

That's pretty awesome, and it's pretty unique. I don't know if I've read anything else like this that has hands-on real environments, and not survey based, so this is pretty interesting. Q, from your perspective what's changed over the last year?

Nathaniel “Q” Quist (05:19):

Yes, I couldn't say it any better than Jay did, but with the real data, and just the sheer number of identities that we were able to look at, 680,000 individual unique identities; it's amazing to have that kind of visibility into how things are working. Within a CTR, I like looking specifically at the Intel, like who are the actors that are performing and working on these particular operations. And so we spent a lot of time and research looking at what the actors are, what are they doing? And how are they targeting? It's really like, who are they? How are they doing it? And what were they targeting? And so, taking that real world misconfiguration capability and then mixing that with what actors are actually targeting and looking made this report to be pretty awesome.

Matt Chiodi (06:08):

Okay, so we are not just talking about like, here's the issues that we've found, right? Whether it be misconfigurations or overly permissive identities, and I know we'll get into that in a little bit here in a minute. However, you guys looked at who's actually taking advantage of these, is that right?

Nathaniel “Q” Quist (06:23):

Yes, exactly, and then how are they doing it? Or how successful were they in doing that? So it's pretty interesting, we are kind of leveraging that unit 42 thread intel metrics and that telemetry we get from that unit 42 from a wider networking industry and kind of push that into cloud and see that these are actual actors targeting cloud. They're actually targeting identities specifically, and this is how they're doing it.

Matt Chiodi (06:49):

So when we think about identity and access management in the cloud, right, every CSP has their own native solution, right? And they offer this as a part of their platform. This is what I think you guys are talking specifically about; this is what you looked at. For example, AWS has their own service, Azure has Azure AD right in the backend, and for Google, we actually don't know what they have, but these are the two big ones right there, those are the two primary ones that I assume that you guys looked at in this research. Let's also say that both of those, both what AWS has as well as what Azure has are not new, right? These offerings have been out there, and obviously they've continued to make changes and offer new services, but the basic offerings have been in place for years. Therefore, we're not talking about things that are in beta or have just been put out there. The question I want to ask you guys is; why is good governance around identity and access management so difficult in the cloud versus on premises? Or maybe it's not, maybe it's the same level of difficulty, I'm curious for your feedback. Jay, why don't I start with you and then Q if you want to chime in?

Jay Chen (08:05):

Sure, I think IAM in government in general is equally challenging and difficult in both offering and in the cloud. However, they may have different pinpoints, and I can give a few examples of why IAM governments in cloud environments are challenging. The first is the number of commissions, so if we look at the number of commissions that are available in an AWS environment at the time of this report, they offer more than 23,000 different permissions. And these numbers continue to grow, so no one can really catch up with the number of permissions because they keep releasing new features and services. Therefore, it is very hard for anyone to be able to fully understand all the permissions of just one single service.

Jay Chen (09:14):

Another challenge is the number of identities; the number of human identities and non-human identities in a cloud environment. One interesting difference is that there are more non-human identities in the cloud than actual human identities. And this poses a challenge because as the number of workloads in the environment grow, there will be more identities. And because of the distributed manner and the service oriented manner of cloud services, almost every application and every service in your current environment needs at least one identity. However cloud is a fast changing environment, a lot of times when your work is depreciated, they are still identity lingering around in your source code, in your logs, or in documents. And these lingering identities can pose significant risks to your current environment. And finally, I think that the third challenge is a non-unified way of managing identities. The fundamental concept of IAM is the same, it has never changed, but the approach to managing and provisioning in IAM has differed significantly across the environment, across different CSP. For example in AWS, IAM is identity centric, meaning that you create a permission policy and attach it to users; you provide user specific access to specific resources. However, in GCP and Azure identities are resource centric, meaning that you have a permission policy and you attach permission to specific resources. And this resource allows who can access that resource. This means that conceptually, they are very different, and another example is; in Azure and GCP, identities are granted in a hierarchical way, but this concept does not exist in AWS, at least in a single account, there's no hierarchy relationship in AWS. Even if you are given a compliance policy, it is not straightforward to translate a single policy into most old clouds. That's another big challenge; there's no unified way of managing and understanding that.

Matt Chiodi (11:49):

That would definitely add a lot of complexity, right? Because every organization I speak with is operating in almost all of the clouds you mentioned. Maybe they have a preponderance in one, but they almost always, I remember talking with customers and they are saying, "Oh, I only have AWS," and I am like, "Are you sure you don't have any projects in Azure?" And they'd be like, "Well, yeah, we do, we've got, but they're not big. Everyone has at least two, or usually three, whether it's shadow IT or it's just some quote "small project" that's probably a lot bigger than they think it is.

Then, you've got the complexity, like you said, they're not the same, they're very different in terms of how they work. And so if you try to then manage that with any scale, I think that that probably is a lot that would lead to a lot of the things we'll be talking about here in terms of what you've found. Q, how do you see this?

Nathaniel “Q” Quist (12:39):

Yes, the complexity just grows, if you have exponential growth wherever your cloud platform is put onto it they don't speak the same language in the background as Jay was talking about. If I would put one example in there would probably be the latest headline thing with Uber, and that compromise that they had there it started out with just a phishing email. A user just got hit with a phishing email and then they had access, or that user had access to an internal shared internet, and that internet had PowerShell scripts and that PowerShell script had administrative access to both GCP and Azure; two different back ends. We still have to think about a user at the front end who's operating or who may have access to other things in a traditional networked environment that we should all have security for but they were still able to pull hard coded credentials out of those PowerShell scripts and get to two different cloud service providers. And if we go back to earlier in this year, Palo Alto had their cloud security report, which is mostly survey data, but an interesting thing about it was that 60% plus of the organizations that were surveyed were in two or three cloud organizations. Therefore it doesn't matter how small it is, you could have nothing in GCP in the case of Uber for example and your Azure is a major piece, and you still get compromised or side channeled into that environment. Actors are seeing these things, and maybe they are not intentionally targeting those things, but they are definitely taking advantage of those opportunities.

Matt Chiodi (14:12):

Okay, let's jump over to the research; what did you find when it comes to how permissions are used in cloud identities?

Nathaniel “Q” Quist (14:23):

It's pretty significant, 99% of cloud organizations are overly permissive, and it's a terrible fear and distraction because of the number 99%, it's like is that real? That's not real. It's actually a real environment, and we started looking at just a single identity and access management policy that has permission. That permission capability that has access 99% of those are overly permissive to that system or that resource that they were going to use. That number alone is completely staggering in that aspect.

Matt Chiodi (15:01):

When you guys say overly permissive, how do you define that? Because anytime I hear a statistic that's like that big, and I hear a 99% number, I always think, Okay, well how do you define overly permissive? Obviously, what one organization might consider overly permissive may not be what somebody who's regulated by NERC, The Nuclear Energy Regulatory Commission may consider something very permissive, and then somebody on the other side, maybe like a startup might be like, "Ah, that's not risky at all." Now I'm curious to know, how do you guys define that?

Jay Chen (15:42):

We define an identity as overly permissive, if this identity were granted permissions that were not used in the past 60 days. This means that there were excessive permissions that are not necessary for this identity in the past 60 days. And what we found is 99% of identities have excessive permissions. Also, looking at this problem from another angle; we also look at how the granted permissions are actually used by each identity, and what we found is that only less than 10% of the granted identities were actually used; meaning that if an identity is granted a hundred different permissions, usually this identity only uses less than 10 permissions. So 90% of the permissions can be revoked without impacting the functionality of the identity, but significantly reducing the risk of the (Inaudible 16:54).

Nathaniel “Q” Quist (16:54):

This actually goes back to what Jay was saying earlier, that the majority of identities are non-human. There are service accounts that are performing a lot of these operations. So a service account should be well defined when you start that service, and you should know exactly which permissions it needs to have before it even starts running. It seems to be that when we're configuring our building most of our cloud infrastructure or using an infrastructure as code or template or something of that nature, we're just overly giving that resource way too much access to other things that it doesn't need to even touch in its normal automated function.

Matt Chiodi (17:28):

So it sounds like, from my experience; I know we don't have the data, at least in the report for like what this is in the on premises world, but my guess from years of experience is that it's probably very similar, maybe not even as bad and maybe even tighter on premises than it is in the cloud. Thinking back to my early days as an admin, a lot of times when you couldn't figure something out, what do you do? You add more permissions, right? You're like, Oh, let me give it a power user or an admin access and then I'll go back later and I'll figure it out, I'll take the permissions away later. And you guys know human nature, right? It works, and so you move to the next step or the next project, and rarely ever do you come back and fix those permissions. Now multiply that out by however many people, how many admins, or DevOps are working on stuff, unless they're actually filing bugs and tracking these things it just ends up as tech debt.

Nathaniel “Q” Quist (18:28):

It is the same thing with developers, developers just want to build the thing and make it work to satisfy a first to market requirement, or it's a major push for the organization to get to the cloud as fast as they can. So they're just going to push as hard as they can, and developers just want to build the thing and then go to the next project. And so they usually start out with root access for most things because they don't have to worry about any issues to stop their Dev process.

Matt Chiodi (18:53):

So 99% are overly permissive, and if I heard you right, you guys defined overly permissive, meaning that for more than two months or 60 days, a permission that was granted has not been utilized. So that means two months have gone by, an application is running, it's utilizing a service account in some capacity, and it hasn't called for its permissions. And I think if I remember the next statistic, right, it was that 90% of those granted are not even used. So it's only like 10% are effectively used, I don't know, is that over the course of those 60 days?

Jay Chen (19:26):

Right.

Matt Chiodi (19:27):

So if you're a developer and you're listening, this means that you need to go back, and you need to remember that somewhere in the neighborhood of 90% of the permissions you thought you needed, you probably don't. So this is all just a violation of what we've been talking about for a long time in cyber security, which is the principle of least privilege. And it is like everybody agrees; I haven't met anybody that says now least privilege doesn't make any sense. Everybody is like, "Yes, least privilege makes sense," but it's putting it into practice and operationalizing it, and making it a standard in an organization I think is really the hard part. So this begs the question, are the cloud service providers, are they being helpful in terms of what they offer out of the box when it comes to IAM policies?

Jay Chen (20:20):

I do think cloud service providers try their best to help to make their users more secure. Out of box policies are designed to accommodate millions of users, cloud service providers provide this out of box policy to help users quickly bootstrap their application, and start the new service instead of spending time understanding every permission needed to start a new workload. And by designing this out of box service out of box policies need to be permissive and broken. So the issues that we found; which I will mention a little bit and these are not the CSPs fault by any way. They try their best to create and manage hundreds of different services for cloud users, and this is really the responsibility of the users when using the cloud resources. You can definitely start with out of box services and you are encouraged to do so to make your adoption more smooth and less error prone. And at some point when your workloads become more mature, and more predictable, it is the user’s responsibility to create a customized policy for your workload. And cloud service providers also offer such services to help you create more least privileged types of permission policy. There are services and tools out there, but it is up to the users who are actually implementing.

Nathaniel “Q” Quist (22:29):

I mean, similarly to what we were talking about a moment ago, the big statistic out of this was that we looked at the top five of the most used cloud service provider policies. So what are those cloud service providers managed policies that are mostly used among all of the cloud organizations we found, and looking specifically within AWS, administrator access was number three. And then on Azure side, owner access, which is the same as administrator access was number two, so those are the most frequently used policies that are being used for cloud environments. And we just talked about why we want things to work and the best way to make things work is to give them all the access and then we get most of our problems, and it'll work.

Nathaniel “Q” Quist (23:16):

However, that's administrative access and so there's a level of education that you need to have to quickly lift and shift into the cloud. Sure, you want more permissions in order to make sure that you can remain productive and we all need the dollars coming in, which means we need to create in order for that to happen. And so just the easiest way to get there is to use administrator access, so for that education aspect, you don't have to have administrator access. You could probably get away with EC2 read only access or you need a lambda execution only process on this particular service. It just depends on, again, having that education of what cloud managed service policies are a better fit for that particular process.

Matt Chiodi (24:04):

It seems like this would be a good case used with infrastructure as code; meaning if an organization has any scale or they're moving towards any scale in the cloud, everything they create should not be net new, right? Meaning that this shouldn't be like, "Hey, this is the first time we've ever done this," So if someone utilizes the infrastructure's code, they've tested something out, this is where you can work through a reduction of privileges. How far down can I actually minimize things before it breaks, and then once you've figured that out for service X, you should be able to put that into a template. That way every time something's being created from that template, it's getting that minimized set of permissions. I think that's interesting, and I don't know if either of you have any feedback on that?

Jay Chen (24:53):

Yes, there's one important step that I forgot to mention, one very interesting finding from this research is that we've compared how permission policies are used and we compare the out of box policies and policies created by users. And we found that in general, like on average out of box policies granted 2.5 times more permissions, than a customer managed policy. And also on average the permission usage rate of out of box policy is 2.5 lower than the customer managed policy. Referring back to previous stack, I mentioned less than 10% of the granted permissions are used in all the permission policy, but this permission usage rate; if we look at this permission use usage rate for out of box policies, their usage rate is below 1%. That's why I want to mention that we are not blaming CSP for offering these out of box policies, because they try their best to scope for each of their services. If they did not offer such a managed policy, most of the users would just use other means to run off their workload, and the problem will be even worse. However, with this managed policy, at least they help cloud users to scope their workload to specific services such as Kubernetes or your virtual machine or your lambda functions.

Nathaniel “Q” Quist (26:42):

There's one thing that I do want to say Jay and jump in there real fast; it kind of gets a bad rap, but the DevSecOps sort of acronym or moniker or whatever you want to call it, people are like, "we don't need this, get that out of there, because it's just bottlenecking and closing things down." However, having active communication between your security team and your DevOps when you're doing that whole CICD pipeline of building and developing and then producing, and making sure security is in that loop. I mean permission set really need to have that conversation, if we're building something, and if we're making an infrastructure as a code template to scale rapidly, I mean, make sure that your security team is involved and at least knows, and it has an angle to look at identities specifically in those particular templates, it will help tremendously.

Commercial (27:28):

Prisma Cloud secures infrastructure, applications, data and entitlements across the world's largest clouds, all from a single unified solution. With a combination of cloud service provider APIs in a unified agent framework, users gain unmatched visibility and protection. Prisma Cloud also integrates with any continuous integration and continuous delivery workflow to secure cloud infrastructure and applications early in development. You can scan infrastructures, code templates, container images, server-less functions, and more while gaining powerful full stack runtime protection. This is unified security for DevOps and security teams, to find out more, go to prismacloud.io.

Matt Chiodi (28:15):

One of the big pieces of news and innovation in the report that I found super interesting was the introduction of an industry first cloud threat actor index. So my question is, what does it do and how can companies use this to help secure their cloud environments? Q I know this was your baby, why don't you tell us about it?

Nathaniel “Q” Quist (28:35):

Sure, I love cloud threat actors, and actors in general and how they work. The quick and dirty of it would be if you were going into let's say an MMA cage fight or something of that nature and you didn't know what that person was doing or what the techniques they were using to knock you out. I mean, you would be done in like five seconds, right? Knowing and studying how adversaries move and how they operate or what they're more prone to do or when they're in specific situations, that's the goal of the Cloud Thread Actor index. It's one of the actors identifying who's actually targeting us, what are the tactics and techniques they're using to perform those operations? And then, can we learn from them? There's two aspects of the Cloud Threat Actor Index that are very helpful, one piece is something called a Unit 42 Atom, which is essentially a minor attack framework structure of a given actor's operation set. So it'll give you the specific tactics that they're performing, like this is how they perform, and the initial access. This is how they perform louder movement; this is how they perform privilege escalation, et cetera. And then it takes those pieces; each one of those techniques that they use to perform those tactics, and then it gives us the very quick and easy indicators of compromise that were used to perform that. For example, these are the IP addresses they were targeting from, or their panel control infrastructure was hosted on, and these are the hash values that their malware was actually using. If you're looking at the pyramid of pain when it comes to threat intelligence the easy pieces, the hash values, the IPs, and the domains are all given as open source information via the unit 42 atom frameworks. So a security practitioner would be able to quickly take those, and put those into their security tool and you'd be able to be defended or at least monitored or alerted for those particular indicators. When it comes to the behavioral side of it, like how are the actors actually moving and operating? You can say, well, these are the sets they're primarily targeting, and the big thing that we found all of the cloud threat actors are using, is every single one of them was targeting identity specifically. They were compromising the system and they were pulling out what the access tokens that this particular cloud endpoint has. Are there other configuration files in that system that we could use to laterally move from container to container, escape the container, or go to the cloud itself and then build other services and processes. So that's the power of that cloud threat actor index, it tells us who's doing it, tells us how it's doing it, and it tells us what they're looking for.

Matt Chiodi (31:22):

I know you covered five different threat actor groups in the report, we obviously don't have time to go through all five of them, but which did you find most interesting out of those five and why?

Nathaniel “Q” Quist (31:34):

Yes, they've been talked about many times but they're called team TNT within unit 42, we call them Adept or a Libra Adept. And what they do primarily, why they're so interesting; and they're supposedly retired right now, and we'll see if that sticks or not.

Matt Chiodi (31:55):

Actors retire? Do they get social security and 401ks?

Nathaniel “Q” Quist (31:59):

They say, "I'm tired of collecting all this data, I just don't want to do it anymore," but what's really interesting about them is why we call them adept specifically because their usage of automation was impressive. They had this repository, and you could call it their swan song of their last action before they retired, it was called the Chimera Repository. And Shamiras are a multi-headed Dragon sort of thing or mythos and or is that Hydra? Anyway, what they did is within 48 hours after this repository was published online, they had over 5,000 cloud endpoints pulled back into it; they were compromised with that system. And what this repository also did is, it had a specific thing called an AWS grab data or even search, they just did a search command and it after a compromise, they would immediately look in that particular container instance or whatever they compromised and pull back 14 different cloud applications and two different cloud service providers, AWS and GCP.

Nathaniel “Q” Quist (33:06):

It would look specifically for the identity and access management credentials of those applications or of those cloud platforms. Using that data, they would just pull that back into their command and control repository, and they had all those credentials, and so they said within 48 hours, they had 5,000 plus different cloud endpoints. And if we're thinking that you know, 99% of cloud organizations are overly permissive and they most likely are using administrator access in those particular instances, if we do 99% of 5,000, that's 4,950 of those endpoints that had administrator rights or overly permissive access in those particular identity pools. So it's pretty staggering that that could be the worst case scenario that we could project. However, that's what makes this particular cloud thread actor or the techniques that they were doing so critical for us to understand and build defenses against.

Matt Chiodi (34:05):

That sounds like the enterprise security teams should be taking a page out of their book in terms of leveraging automation. It sounds like the attacker in this case is not just one step ahead, but many steps ahead of where many enterprise security programs are.

Nathaniel “Q” Quist (34:21):

There are things that we can do, we can literally stop so much of this from happening, and automation is our friend.

Matt Chiodi (34:32):

With AI and ML, right? I'm just joking, I'm sure that's a part of it also. However, all of this leads me just to be further convinced that IAM security is extremely complex, especially in the cloud. Let's just kind of wind things down here, I'm curious, what are maybe one or two recommendations you have for security teams who are looking to up their game when it comes to IAM security in the cloud? Give me 2 or 3.

Jay Chen (35:10):

First (Inaudible 35:15) multi-factor authentication for all human identity, sometimes MFA is not possible or too difficult for non-human identity. And second, use identity providers such as Azure AD or Okta to log into your client environment, this way you have a central management and visibility to host your identities and periodically scan for all of your identities and identify the unused identity and remove those identities. And finally, use tools provided by third parties or cloud service providers. In AWS, there's a service called IAM Access Analyzer, and in GCP there's a service called IAM Recommender. These services can help you generate least privileged permission policies based on the APA usage history; so I think I gave four.

Nathaniel “Q” Quist (36:17):

I think Jay's being a little humbling and modest there, he also wrote an amazing tool called IAM Deescalate; and what it will do is it will look in your AWS environment and look at the potential paths that a specific identity has before it can get to like, say a root access or privilege escalation. And once it finds one of those, it will create policies automatically that will stop that particular attack escalation path from occurring. It is a very useful tool, and it's also on unit 42 like Palo Alto’s GitHub repo as well.

Matt Chiodi (36:57):

If I Google IAM Deescalate, I will find it, and if not, just go to unit 42 or Palos GitHub rebound, and you'll find that tool. That's pretty awesome, and that's specific to AWS that does not work in Azure, is that right?

Nathaniel “Q” Quist (37:11):

That's correct.

Matt Chiodi (37:12):

I know they're totally different, it is totally different how AWS versus Azure.

Jay Chen (37:21):

I got a lot of requests, and it's possible, I just don't have time to work on it now.

Matt Chiodi (37:27):

It’s in GitHub, so someone needs to fork it and they need to make another version that supports Azure.

Nathaniel “Q” Quist (37:34):

One more thing that I could say is CNAPP or Cloud Native Application Protection Platform, is kind of a new-ish term, vendors are picking it up and using pieces with it. It is for pre vendor agnostic, so depending on which platform you're using or which security vendor you're going through. However, what the cloud native or the CNAPP is for, is to bring all the different types of cloud security together under one security umbrella, so everything from code scanning, to identity scanning, to governance risk compliance to cloud workload protection and network security. Those five pillars all come together underneath that CNAPP umbrella, and it gives you a bigger picture of if an attack were to happen, you can follow it through its different phases.

Matt Chiodi (38:27):

And I think Palo Alto Networks has one, I think it's called Prisma Cloud, and I think they're a sponsor of this podcast, isn't that funny? Anyway, you're right there are different ways of doing it, and from speaking both on the consulting work I do with IANs and from previous experience, I know that most CISOs and security teams are absolutely overwhelmed with just a number of security tools they have. So the power of having all of those capabilities for cloud, including identity and access management in one security tool, like a Prisma cloud or a CNAPP, whichever one you may choose, is extremely powerful. I always tell people when they're looking at it, in fact, I have a consulting call coming up later today where someone's asking me this very question and they've got to go out, and you've got to do your proof of concepts. However, I always tell people at the end of the day, having one of these CNAPP tools is better than not having one or better than having 10 tools that are trying to achieve what a single tool could potentially do for you is way more powerful because it allows you to get the best value from the tool where you're not trying to train your staff on 10, 15 different tools, rather just one. So I appreciate that, that's great feedback. So you guys are threat researchers, which means you have to stay on top of what's happening and there's news breaking every day, there's another breach, there's some kind of new exploit, and there's some new vulnerability, I'm curious to know, how do each of you stay up to date and keep learning? Q I'll start with you and then Jay will let you take it home.

Nathaniel “Q” Quist (39:57):

I'm always reading, I'm always getting alerts or notifications of different security newsletters and different things like that across multiple different topics. I think it's important to stay kind of broad so you can capture a wide enough net of information. If there's one thing that I could say that is very helpful, is the easy step into the whole cloud security platform or security process for cloud. It's something called the Cloud SEC list, and it's managed by a fellow named Marco. I've never met him personally, but I would like to. The Cloud SEC list; cloudseclist.Com every Sunday at US time early in the morning it will populate the latest trends of cloud security topics that have happened for that week prior. It's a really good recap rundown of what's happening in the cloud security industry in general, and it usually has some really good insights. It's only once a week, so if something happens on Tuesday, you might miss that, but that's what Twitter is good for and some of those scraping tools that you could use.

Matt Chiodi (41:03):

Awesome, we'll put a link to that in the show, J how about you?

Jay Chen (41:14):

I get most of my information from social media, like Twitter and newsletters, and I have another one that I really like and it's called TLDR.

Matt Chiodi (41:29):

I get that

Jay Chen (41:30):

It's by Klint from (Inaudible 41:37), and it's not just on cloud, but this newsletter is for application security in general, but it usually has a section for cloud security and it is one of my favorite.

Matt Chiodi (41:54):

I love it, so I have one last question; can you guys share what you're working on next in your research? Or is it top secret?

Jay Chen (42:06):

Nothing we work on is top secret.

Nathaniel “Q” Quist (42:08):

Yes, we've done a lot of reports, like we've said with this last CTR was the second IAM identity access management topic that we focused on. And we're looking at broadening that, and perhaps looking at code scanning, and looking at identity in a slightly different way. There's also definitely going to be some more cloud threat actors and the next volume of the index is going to be in there, so there will be some good stuff.

Matt Chiodi (42:40):

That's awesome, with the Cloud Threat Actor Index, are there any plans to do anything separate from the report to make that either more real time, I'm curious, how are you guys looking at the next kind of iteration of the Cloud Threat Actor Index?

Nathaniel “Q” Quist (42:59):

Yes, The Cloud Threat Actor Index's ultimate goal is to be timely and relevant for any major event that's happening and that's targeting the cloud environments, and the actors or the groups that are behind those particular operations. There's been a lot of work done, for example, if you look at Solar Winds that was attributed to the Nobelium group or APT 29; they also had just a very impressive attack using both Dropbox as well as Google Cloud as far as for the command and control infrastructure, so there are a lot of callbacks into that. Also, for APT 10, or China Chopper; there is a lot of good information on those. The goal is to be timely and relevant so as new actors and techniques are coming in we're updating that as fast as we find new information.

Matt Chiodi (43:56):

I love it.

Nathaniel “Q” Quist (43:57):

You can find a lot of that on Unit 42 Atoms; we're in there as well.

Matt Chiodi (44:02):

Awesome, well Jay and Q it's been great chatting with you today and it's always been good. And if people want to go out and download a full copy of the report again, you can go to unit42.paloaltonetworks.com; one of the world's longest domain names that I frequently misspelt while I was working there. And I'm glad to be at a company now where the domain name's only four letters. If you go to unit42.paloaltonetworks.com, you can find the latest cloud threat research, including the latest cloud threat report. Jay and Q, thanks again for joining us.

Nathaniel “Q” Quist (44:32):

Thank you Matt, it was a pleasure.

Jay Chen (44:33):

Thank you, Matt.

Narrator (44:35):

Thank you for joining us for today's episode, to find out more, please visit us at cloudsecuritytoday.com.