Rich Mogull: [00:00:00] And I think the biggest point we wanted to get across when we decided to collaborate on this is you can't win by chasing vulnerabilities. We have seen things.

Chris Farris: We have seen things you people would not believe that we can't even talk about it. Are you still logging in as root to manage those AMIs?

Rich Mogull: I like to live dangerously.

No, absolutely not. I am not that stupid.

Ashish Rajan: Have you been in a situation where you have been airdropped into an organization and you have to solve the cloud security problem? Or you're looking at a CSPM and it has a mountain of red alerts on it, even with the context. If those are two scenarios that you have been familiar with or about to become familiar with, this is the episode for you.

For this episode, we had Chris Farris, as well as Rich Mogull, who have developed a

Universal Threat Actor Model for helping people like you, me, and others who are probably airdropped in a lot of organizations. on what are some of the common threats, what are some of the common vectors that should be a priority to help you go through that wall of red sometimes you get at a [00:01:00] CSPM.

We also spoke about how an organization could be structured, whether it's a medium sized organization or a large size organization or a startup, where you could be looking at putting all the effort for, especially when you're being, tied either from a resourcing perspective, or you are the only cloud person, no SOC team there, but whatever the situation may be, our hope is that after at least watching and reading the Universal Threat Model for Cloud, you would be well equipped enough to at least start having conversations at a broader scale.

On how to do cloud security in your organization, whether it's AWS, Azure, Google cloud, doesn't matter which one, it should be all universal. So with that said, if you know someone else who's probably going to be working in a similar situation, Definitely share the episode with them. Chris and Rich are also speaking at RSA about this very event.

And I will leave the link for the RSA talk here if it's available already. But if not, I'll definitely encourage you to check out the talk, which they did on the same topic at RSA 2024. They're also in the fwd:cloudsec community, which I'm part of as well. I'll definitely encourage you to [00:02:00] join and connect with other Cloud Security people.

But otherwise, as always, if this is the second or third time you're watching or listening to this episode. I would really appreciate if you give us a subscribe on YouTube, if you're watching this there. But if you're listening to us on iTunes or Spotify, definitely give us a follow, subscribe there as well.

It really helps us get the word out. And plus you get to be notified when a new episode comes out as well. So you can jump onto it straight away. Thank you so much for your attention and I will see you in the next episode. Bye. Peace.

Welcome to another episode of Cloud Security Podcast. Today, I've got Rich and Chris.

They're not a band. They're just friends. Maybe to start off with Chris, if you want to give a bit of intro by yourself and maybe followed by Rich, introduce you guys to my audience. Some people already know most of you, but. I would love to at least introduce you to the broader audience as well.

Chris Farris: So I'm Chris Farris.

I've been doing cloud security stuff, mostly in the media and entertainment space since about 2016, I'm a AWS Security Hero, which, really makes me wonder about things. And, my focus has really been on trying to help [00:03:00] companies figure out what to do about cloud security.

So I really feel like, educating and informing and empowering builders and security teams is, what gets me going in the morning

Rich Mogull: My name is Rich. I've been involved in cloud security over 13, 14 years now. I got involved early with the Cloud Security Alliance. I wrote the CCSK training program wrote multiple versions of the CSA guidance and day to day I have two jobs. One at my company Securosis and this other one Firemon that bought a startup that I did. And similar to Chris, I spent a lot of time trying to help improve cloud security, educate people publish research do a whole training thing called Cloud Slaw. That's probably worth talking about on another day.

Ashish Rajan: I was also going to say, considering there's a lot of cloud experience floating on this call. I'm also curious, what was the first cloud service that you guys ended up working on?

Chris Farris: I have this AWS account and it'll be a blog post someday. From 2010, I had found it when I was searching in my email and I was like, what's this email from Amazon Web Services from 2010?

So I did a password reset, I logged in, I realized this predated [00:04:00] IAM. I had these X. 509 certificates that I used to authenticate to the APIs as the root user. It was like opening Tutankhamun Tomb. The weird stuff that suddenly came rushing back into my memory when I was like, oh yeah. I set up a VoIP system on this thing to robo call for a candidate and make it Georgia.

I would say EC2 is probably the first service because yeah, there were only like four back.

Rich Mogull: Actually right about the same time, 2010 AWS did my first account to start building and learning on. IAM wasn't there. I think VPC had been announced, but it wasn't really in production yet. So everything was like dark connected.

The only way to log in was with the root user, with root user access keys. Unlike Chris I did not have to go find that account. I still have that account because if anybody has ever taken the Cloud Security Alliance, the CCSK plus training, the AMIs used for that training still run out of that account. Cause we built the first training class in 2011.

Now. They've been updated since 2011. Amazon gets about [00:05:00] 15 year old AMIs, but yeah, those still run out there. I've actually complained to the CSA guys, we got to get this out of my personal account, okay, please. A CSA account to run this stuff out of, we're making that change.

Chris Farris: Are you still logging in as root to manage those AMIs?

Rich Mogull: I like to live dangerously no, absolutely not. I am not that stupid.

Ashish Rajan: I think I still remember the time when VPCs could not be made private as well is when I logged in and just the default was always on the internet. Now, I feel like

Rich Mogull: these were originally only private. And that's around that 2011 timeframe, I think.

Ashish Rajan: Yeah.

Rich Mogull: And VPCs were separate than EC2 Classic. Which is what all your instances would run on.

Ashish Rajan: Yeah. And then

Rich Mogull: what year they blended them together, but it could be the only way to use a VPC was over an enterprise level VPN connection, so you could even use home now,

Chris Farris: Yeah and a EC2 classic was here's a public IP address that Nats to a private IP address, but it's a shared private IP address space.

So Rich's machine and my [00:06:00] machine could actually talk to each other if we didn't do our security groups correctly. Imagine if people can't do them correctly in 2020. For they were really not doing them correctly in 2010

Rich Mogull: back then like now, if you create a new a launch wizard security group, it opens up port 22 and in those days there was no access at all and Amazon had opening up port 22 because I think 98. 73 percent of their support calls were. I ran an instance and I can't log into it because nobody can figure out the security groups.

Ashish Rajan: Oh my god, one of the reasons why I brought this up is because I think it's worthwhile knowing that because so much has changed in cloud over the years, some people probably started off like both of you as well, when things were very different in AWS.

And even until today, we still have a lot of things that are not the same from five years ago. And maybe change completely differently. And both of you have been in situations as well, similar to me, where you have been airdropped into situations where now you're looking after the security of an entire organization for cloud.

I'm curious. And obviously I want to give a shout out to the talk that you have at RSA [00:07:00] and I would definitely get into the Threat Model that you have, and we'll talk aboutthat later during the talk as well. I guess my first question is, where do you start when you're normally airdropped? Say in 2024, someone airdrops you into an AWS environment.

What's usually your thinking there? Because I imagine a lot of people also go through this as well, where they're trying to figure out, Hey, where do I even start? What's your thinking there?

Rich Mogull: It's really straightforward. And this is where some of the stuff I've done in like where a world disaster response come into play. It was stuff that Chris was doing intuitively. Like it wasn't like he was operating out of a framework for this. When you come into a chaotic situation, first thing you have to do is orient yourself. You've got to figure out what am I dealing with here?

Now for me, it's usually a few different things. It's not only from a technical standpoint, but what's the political environment? That we're working with here, who owns what, who's in charge of what are the governance structures, I'm known for saying all cloud security failures are IAM failures and all IAM failures are governance failures.

So I frequently start there, like when I was coming to do at least on the [00:08:00] consulting engagements, I'm like, Chris, I have not dropped in into an operational role to do this. I'm the outsider. Who owns what? Who's responsible for what? How big are the teams? What is the skills and staffing training? Then we can start moving into some of the technology pieces, but it's like, what's in front of me?

Is this a nuclear explosion? Is it a car wreck? Or is it my cat knocking crap off the counter?

Chris Farris: I would like to say I'm that guy in that meme. It's wait, you had governance? Because in a lot of times we drop in and the extent of the governance is, oh my gosh, the bill is too expensive. And then, of course, the answer to the bill is too expensive is.

We must obsess about tagging. And yeah, my slide from last year's RSA is basically just Sisyphus pushing a rock up the hill with tagging, how it was, how it's going, how, tagging is, one of those things. For me, it's first okay, what are the things that are going to get us breached right away?

I call these the big gaping security holes. I really should trademark that. And, they're the highly. Very easy to discover, [00:09:00] very easy to exploit things that, you know, just as part of the discovery of the internet. Hey, I've got a bucket, and it's like PII backups, okay, somebody is probably trying to access that bucket, and if that bucket's public, that two words, very similar, easy to discover.

It's a global namespace. Lock that thing down. And so this is where I come up with the idea of CSPM is threat hunting. I want to get a CSPM. Yeah. I want to run it. I'm not worried about fixing everything. I'm just going to gather all of that data and then sift through looking for the most critical criticals and then reach out to those teams and ask them to fix it.

And then I can sleep that first night. I want to look at the trends in the CSPM. It's okay, we have 600 RDS databases on the public internet. Why is this again? And why is 3386 open or 3306 open on all of them? And that then tells me, ah, okay. So we never actually figured out how to connect our end users and our on prem offices with our cloud VPCs.

So rather than saying, Hey, go fix all of [00:10:00] these databases. I say, Hey, let's go spin up a project to figure out how we connect all of our VPCs and our users together. And then we have the capability to start figuring out, what do we do with these databases? Similar okay, great. Lots and lots of EBS volumes unencrypted.

Can we change the Terraform module that we're using to set that to encrypted? Okay, cool. Thank you. That kind of piece. So it's first, what are the, and usually the big gaping security holes are small in number. There's not going to be tens of thousands of those. There's going to be dozens.

And it's a good reason for me to then go out and meet the team, right? Hey, okay. So I found this publicly writable S3 bucket that belongs to such and such product team. Let's go and introduce ourselves, set up a meeting, talk about, LA Times and how they became a crypto mining firm for somebody because they had a publicly writable bucket.

Ashish Rajan: I love the thinking of finding the big gaping security hole. I think we were talking about this offline earlier about there are patterns that are after all these years of doing cloud security, [00:11:00] they're almost like patterns to threats now where it's very rare.

I would call heartbleed, a cloud security vulnerability, but there hasn't been a zero day discovered in cloud security, unless I'm missing something here. Do you guys believe there's a zero day or are we Looking at simple challenges to what you said, if you're looking at big gaping holes, broadly, there'd be a few dozen problems to deal with, not thousands of alerts that most people are scared of when they buy a CSPM sometimes.

Rich Mogull: Let's take a bit of a step back. Cause there absolutely have been zero days. Some of the Microsoft stuff now we know DOD and government agencies were compromised because Microsoft was compromised. That's different than maybe some of the holes and things. Chris and I know through our other contacts, people, as well, there have absolutely been zero days.

We just don't know how often that stuff's exploited because those things are not, shall not be mentioned. The approach that in what we were getting at here is that there's the stuff you can control and the stuff you can't control. And you can control your own destiny to some point or the situation that you're in.

And Chris brought out, his [00:12:00] prioritization, very similar to my prioritization. Okay. What's the political environment I'm operating in the governance. Then what are the big gaping security holes? Then I start going into more like root cause analysis. Can I cut some of these problems off at the knees as opposed to chasing the vulnerabilities?

And I think the biggest point we wanted to get across when we decided to collaborate on this is you can't win by chasing vulnerabilities. Go get your CSPM, but if you chase everything in there. You're going to lose, you'll never catch up and it's really about doing the structural changes. So this is where some of the disaster response stuff came into play where I got inspired by some of these ideas where we learn about, triage and planning cycles and assessment cycles.

So the first step is we're coming in. We talk about the definition of a mass casualty incident. Casualty incident is anytime you're facing a situation that requires more resources than you have. It doesn't mean there's a bomb.

Chris Farris: Anytime you start a CSPM, you will have more findings than resources to address.

Rich Mogull: Yeah. Every time you turn on the CSPM, you're in a mass [00:13:00] casualty incident because you're going to see more. There was a red thing on EMS the other day. Somebody's had two patients. And so I was like, you understand that's a mass casualty incident because you were the only person there and you couldn't treat critical patients.

And so you go into a triage and the triage mode is if they're dead, or dying, you leave them, you focus on what you can save, but your goal is to get out of that as quickly as possible. And getting this in incident command system, we learned about the planning key. We call it. So it's the cycle for an operational period.

And that's all about what can I accomplish during this given piece of time? And how can I move myself forward to keep the problems from getting worse? And so initially, it's all about just dealing with the hundreds or thousands of patients and whatever you're facing, but then it's all right. We got to worry about food and water and we got to worry about busting people.

We've got to worry about getting power back online. And that's that second phase of what Chris is talking about, where, you know, working on improving the connections with the databases and everything else. Now, [00:14:00] how does this relate to your question about, 0 days? You can't do anything about those harder problems until you dealt with the stuff in front of you, especially because an OD in cloud means you're probably not going to know about it.

And it's the provider. Many of those are things that you can be prepared yourself for. This is actually talked about this with some of their stuff. It's the making sure that you can update your policies like Amazon finds a problem or Azure finds a problem and it's in an IAM policy. You have to be able to update that policy on your end.

If it's not something they can fix, there are things you can do to prepare for those problems. Then there's other ones where you just have to not let your friends use Microsoft.

Chris Farris: And that's it. So it is what is on your side of shared responsibility is what's in destiny. What's on the cloud providers side of shared responsibility?

The only control you have is which cloud provider you want to use. Typically, that's done by Hey, your CXO has gone golfing with this other person. And so therefore you're using Azure now. There's very little [00:15:00] that a practitioner like us can really do to influence that decision.

So it's really, okay. If the Russians are going to get our stuff, the Russians are going to get our stuff. I'm going to try and make sure that the ransomware syndicates can't go and find an open RDP port somewhere and using the ransomware deployment protocol, drop something on our network that's gonna shut us down.

It is really about what you can control and what you can control is on your side of shared responsibility curve

Ashish Rajan: I think the Attack Mitre Framework that came through which still is about five, I think five ways attackers on the internet are using ways to gain access to a cloud environment and across the board, we had this LinkedIn post that all of us contributed into, which is the three big buckets that we feel most of the vulnerabilities normally fall in when they're not zero day.

I would love for one of you to share that, but also add in terms of how do you see this being addressed in an organization to Chris, what you said, where you turn on a CSPM. You probably would see that three things being listed 50, 000 times, which one's a priority and which [00:16:00] one's not a priority.

Chris Farris: The CSPM findings are all going to look different, but they're all going to come back to and so Rich and I had delusions of grandeur to go and create something called the Universal Cloud Threat Model and basically that kind of distills down. Most of the attacks look like this, and most of the problems that you're going to find in the CSPM that you want to address are going to map to, some of these different attack vectors and stuff.

The actual Unified Cloud Threat Model really comes down to a very simple statement. Threat actors have objectives against targets using attack vectors that are observed by defenders as attack sequences. And so then we break down the threat actors as nation states or cyber syndicates, rich as cat, researchers, whomever, those are your threat actors.

Their objectives are typically money or some kind of nation state advantage targets. They're typically your data or your compute resources or something along those lines, or you're the target that's a pivot point [00:17:00] to broader, more targeted objective. And then the vectors are really the things that we already know, access keys and credentials that are mishandled things that you put on the internet that aren't secure and suddenly get zero dayed.

Those are the zero days you need to worry about. They're not the ones in the cloud providers. They're the ones in Move It, or Avante, or Palo Alto, or, Insert, whatever Zero Day is XV for that matter.

Rich Mogull: It was the idea is that we built that model because we realized there's all this, it's great research.

I am not disparaging a lot of the vulnerability research that's going on out there by the different vendor communities. And some of our friends are doing this work and it's wonderful, important work, but it can also be distracting. So the idea is let's build a threat model that is 90 percent of the stuff that 90 percent of organizations need to worry about.

Okay. Those aren't quantified metrics, but that's the rough idea that we came up with. So this is what you use before you start worrying about the other stuff. And I think some of that's because we spend a lot of time at conferences or answering questions and talking at works, people really like honing in on like the [00:18:00] crazy stuff that meets the news headlines.

And it's okay, it's fine. That you're worried about getting struck in the head by a battery falling off the international space station that crashes into your house. But you're probably going to get hit by a car.

Ashish Rajan: And maybe just to flesh out the example a bit more, we started the conversation by talking about that.

If you guys are airdropped into an organization, which has happened to a lot of people who are probably watching and listening to this as well, bringing that to the Universal Cloud Threat Model that you guys have developed. Once the talks comes out and I'm pretty sure it will come out pretty much very close to after we release this episode.

So people will be able to see that at RSA. How would someone who's listening or watching this be able to use the Universal Cloud Threat Model? I guess what can they use it for if they were also airdropped into an organization?

Rich Mogull: I think it's got two ways that you can utilize it. One is that, when you're faced with the overwhelming stuff, when you drop in, you can look at that and go, which of these things correlate with the parts of the threat model?

Cause it's not that as much as it is universal and that we're [00:19:00] all facing same risk and a big focus of it that we didn't mention earlier is that the core concept behind it is that if you think about it for years, we've known if you put a server on the internet, it's going to be attacked. And we call it the internet background radiation that exists.

And we didn't think that was being characterized. What we call the undifferentiated attacks. It is the, if you post a key to GitHub or apparently you're privately hosted GitLab, and then that gets compromised, this is what's going to happen, that's just going to be automated, the attacker doesn't know or care who you are.

Chris Farris: And it doesn't matter if it's like a college student. Or, Netflix, or, a major Fortune 10 bank, the things are going to all be the same. Now, if I figure out I have an access key for a major Fortune 10 bank, that's probably worth a little bit more than, a college student's access key.

But you don't know that at the outset. The person who finds the key is just happy. They got an app working access key and more than likely, they're just going to spin up crypto miners on maybe they'll do an [00:20:00] AWS S3 LS and try and exfiltrate some data. And if they're lucky, they can, which again, goes back to maintain your credentials and don't use read only access.

Rich Mogull: So when you look at. What you get, because what Chris said, use a CSPM, you can use an open source, you can use a commercial, whatever you have to have some way of orienting yourself, you can use what's given to you by your cloud providers to start, but you're going to get a sea of findings and it's going to be at the criticality levels they define.

So the threat model can help you sort through that mentally. And there are spots in there to adjust because if you are a bank, I'm going to be worrying more about the nation state hackers from the college student nation state hackers are never going to progress in their attacks. If North Korea gets me, they're going to crypto mine because it's a fully automated back end service.

So it's exploitation as a service that they're running back end and that's what I'm going to experience. And then you can learn the defenses. So like in my training classes, one of the first thing that this Cloud Slaw thing I'm doing, that's a free online thing. One of the early ones is billing alerts.

The thing that's most likely a student screw up is accidentally a compromise and they're [00:21:00] going to crypto mine it. So let's throw that billing alert in like literally. So those are examples of how that can help you. Now, the other way is if you're more like Chris, who gets dropped into medium and large organizations, and you're facing all the political turmoil, and it's not like anybody's doing anything wrong.

It turns out human beings are political animals. We hope it can be something you can use in meetings. To help you prioritize efforts, you can hand it over to the dev team and go, that's why this matters. Chris did a great job, which I didn't even think about when we started. He put references into a bunch of attacks.

We've got like 20 plus references in there in all those categories, giving real world examples.

Chris Farris: Yeah. And tip of the hat to Rami, who had a lot of those in his AWS security incidents, GitHub repo. And again, that was a lot of the stuff that I did with breaches.Cloud was if I'm talking to a developer, it's a heck of a lot better for me to be able to say this company that you've heard of, you probably use, had a [00:22:00] security incident because of this thing that I'm asking you to fix.

And that becomes a much more interesting conversation with the builder community in your organization, because now you're tying it back to something that is concrete. Something that actually happened, it's not just section 24601 of 853 says, you need to go do this. It's, no, Drizzly got popped because of this.

This is what happened to the CEO and the company. As a result of this, and it makes it a lot more of a personal story for, Hey, now I need you to go work this Jira ticket and go rebuild the database. And it may take you all weekend

Rich Mogull: had to fight dragons in the early days when there were, we couldn't refer anything.

This talk is built on the back of giants because we have our community and our friends who we have now a decade of research. We know people in cloud providers on response teams. We can't name them. We talk to them and we'll say, Hey, what's the trends? What are you seeing? They're like this, and this, that's where this information comes from.

It's not just from our [00:23:00] own experiences. We relied on very smart people, smarter than us who also do this work.

Ashish Rajan: Yeah.

Rich Mogull: And there really is consensus. We've gotten no pushback on this model by people who do this work.

Chris Farris: The only thing that's really come out is, your cat tried to sabotage the work.

Rich Mogull: He's really a turd.

Ashish Rajan: It's funny because I was reading through at least the threat model white paper that you guys shared as well. I love the description of each of the threat actors as well and how they're like, oh, there was one which was threat actor engages in a ransomware attack. And a lot of people don't even know how does the ransomware work in the AWS context, but I loved how you guys had the objectives for obviously sensitive information disclosure, selling sensitive data on the black market, but also as you go into a bit more, the vector could be unpatched vulnerability, but it could also be upload of ransomware images and nodes.

That kind of gives you a sense of, Oh, okay. So it's not just like my I'm locked out of my server. Cause I think that's what the general internet thinks for it happens to ransomware.

Chris Farris: Cloud ransomware isn't like what we saw with NotPetya and Maersk and all [00:24:00] of that. It's, you're not going to go find an active domain AD controller.

Somewhere in Ghana that was offline and you're gonna go rescue it and get your network back on. No, what's gonna happen in a cloud ransomware attack is more than likely, they've deleted your data or they've downloaded and deleted your data and they're gonna ask for some crypto to get it back. And In some cases, they'll say they have your data and they don't.

And AWS has actually talked a little bit about this in some of their cloud ransomware discussions that if you don't have data trails enabled, you don't really know if they have the data.

Rich Mogull: Yes, we sat next to each other re:Inforce 3 years ago. I think we were at that. We were both in the same talk where a lot of us in the community that, outside of the people that work at AWS, we've been talking about ransomware.

We were like, oh, you do something with KMS word encryption. And we sat down and AWS told us right then and there, they're, yep, they're copying the data out and they're deleting it and they're uploading a ransom note. We're like okay.

Ashish Rajan: Wasn't there another kind where people were [00:25:00] deleting the key used for encryption or something as well?

Chris Farris: You can't delete it. There's a seven day hold on deleting a key. So if I pop your account. And say, hey, give me 15 Bitcoin or I'm gonna delete your key. You can just say, oh hey, AWS, can you undelete my key for me? And that's it. Ransomware attack is over. Least dramatic thing ever.

Rich Mogull: Turns out bad guys are Easily as lazy as we are, and we'll always follow the path of least resistance.

Chris Farris: So financially motivated ones are right. I think nation state motivated ones probably are going to create a persona for two years and get them to randomly support obscure compression libraries in the open source community.

Very few people are otherwise are going to do that.

Ashish Rajan: This is also an interesting segway into, what are some of the either attacks or compromise or stories that were surprising to you guys,

Rich Mogull: Ashish, we have seen things.

Chris Farris: We have seen things you people would not believe. That we can't even

Ashish Rajan: talk about.

Rich Mogull: I am not surprised by a lot [00:26:00] anymore. To be completely honest, because you see enough, it's like going to a paramedic stuff. I have now seen most of the ways human beings can shorten their existence on this planet. And it takes a lot of creativity. I will say the XZ malware, or the supply chain.

That was about as close call that one really was. Yeah, that was years of prep work that was stopped. And the reality is we are already infected by that mechanism. We don't know where. So that's up there really high. The 1 that really shocked me and it was Microsoft as part of, I think it was part of midnight blizzard.

They found an older test tenant and the attackers. And we're able to use that and bridge into Microsoft's production environment and get executive and government level emails. And we still do not know how bad that attack was. That one stunned me a bit because it was such a fundamental failure, even of Microsoft's own best practices.

I have. Honestly I'm picking on them a lot. It's not that I'm biased towards AWS. I, [00:27:00] AWS has never paid me a penny. No, I'm a community builder. So I got a credit on an AWS account. I have paid Amazon a lot of money and not just for toilet paper.

Chris Farris: I'm going to disagree on the Midnight Blizzard attack because based on what I've read, it sounds okay, there was a self enrollment user in a test tenant that had some level of access to a production tenant.

And I have to imagine that it was some developer somewhere who was testing Terraform and basically said, Oh, let me go and let me spin up a user and let me give it this permission and I need to test cross tenant permission. So let me go and what other tenant do I have? Oh all right, I'll tie it to my enterprise app that I built in my corporate tenant.

But, they probably never actually used the user. The user that the Russians compromised, got created as part of testing something else and then forgotten about. The two pieces of, maybe negligence. I don't want to use that term in a legal sense, but two places where Microsoft really [00:28:00] failed was, okay, they didn't clean up stuff afterwards and they didn't give the builder who was doing this testing a third tenant that they could also test cross, cross tenant testing with and I've seen that a lot. It's I need to get a job done. So I'm going to do it with what's available to me. And if production is available to me, I'm going to do that. The one example that I found was last pass. And what was interesting about last pass is they compromised somebody like Rich or I.

Our homeplex server and use the homeplex server to pick it to their work laptop and then from there got the keys to go get the Commvault backups and I don't remember if it was Commvault or not but it was some external backup system because LastPass was all on prem.

Ashish Rajan: Yep.

Chris Farris: The backups were in the cloud so it was some proprietary backup format that was encrypted properly and everything else but it was the user's unpatched Plex server, and that was very much, one of those was like, okay, you knew who to go after.

You knew that they had a Plex server. [00:29:00] Okay, maybe their social media presence indicated that. And then you figured out how to compromise that, pivot across their home network, compromise a work machine. That was impressive.

Ashish Rajan: In terms of how people look at this, and there have been a lot, many more as well.

There's Microsoft last pass. There's a lot more in terms of how you guys see this being used. And it's funny as both of you were talking a lot of that, I'm still a bit tied to the white paper that you guys have written. Universal Threat Model, like all of these. They link back to the last pass links back whether it's a threat actor or whether it's a vector being used or their target being used.

I think it definitely resonates quite a bit. So it's really interesting to use that example. And in my mind, I'm going, Oh yeah, you can match that. You can match that. So I feel like people are watching, listening to this. They would be able to also do the same.

A lot of people also believe that you have to draw a line at that application layer, but after that, it's just basically unknown territory for everyone. then become applicationn centric in terms of where the investigation can go. And I'm thinking more in terms of the SOC teams or the SOC level one, level two, who are probably at this [00:30:00] point in time becoming the receiving end of all the CSPM alerts in a lot of organizations where cloud security is focusing on, Hey, they're not,

Rich Mogull: they are not.

And that is one of the problems. And I'll turn that.

Ashish Rajan: In my mind, they're going towards it. So they're not fully there yet. I definitely feel like a lot of the companies that I'm talking to where they're realizing the cloud security people are becoming a lot more about, for some reason, we installing virtual appliances in cloud for security, but there are those examples as well.

Do you guys find where are the CSPM alerts going at the moment that in the conversations you guys have?

Chris Farris: So either into a black hole or into the vulnerability management program and they're getting prioritized public S3 buckets or unencrypted EBS snapshots are getting prioritized next to okay you still got Apache struts on this machine or you know there's a CVE or CVSS 4. 0 or TLS encryption 1. 1 or whatever. I see them mostly feeding the vulnerability management program. [00:31:00] I think in mature organizations, very mature organizations, it makes sense that a CSPM finding of a certain level of criticality should go to the Security Operations Center.

Ashish Rajan: Yeah.

Chris Farris: And it should trigger a SOAR workflow that basically says, bad thing happened.

I have an event in, CloudTrail or whatever your audit management log is. I either know the identity of the carbon based life form who did it. And so I can point the finger at goose and say, you made this bucket public. Or it was okay somebody pushed something in the pipeline, did this thing, and you can trace it back through pipeline to source code to some human, again, there's always a carbon based life form at the end of this that approve the PR, push the commit, whatever. And those are the people then the security operations can reach out to and say, Hey, you did a no. And then it depends on your political, again, you can either auto remediate it if it's safe.

It's not safe to auto remediate certain things about [00:32:00] databases or you tell them, Hey, you need to go fix this right away. And that's, that would be the way to do a SOC workflow around it. But you can only do that once you've burned down the massive legacy of CSPM findings and only for highly critical things.

Because again, a hundred thousand CSPM findings can't be a hundred thousand tickets for a sock to work. You don't have a SOC that big.

Ashish Rajan: No one does, but to you guys point, what is a good starting point? All of us are aware of even with context in large organizations, there's still thousands of alerts in CSPM.

I think it's funny when you see a demo and it's five alerts out of 50, 000. I'm like, I don't know at scale of that's like

Chris Farris: publicly writeable buckets, publicly readable buckets,

AWS root access keys, EC2 instances with admin permissions or hell read only permissions or S3 full access permissions that are on an instance on a public subnet that's exposed to the world with IMDS v1.

Those are the things, those are the big gaping [00:33:00] security holes I'm talking about. Those are the things that aren't necessarily a SOC ticket. They're definitely a JIRA ticket to the builders who have to go remediate it.

Ashish Rajan: Yeah.

Chris Farris: But I wouldn't pollute your SOC who's also looking at, incoming telemetries and active attacks with that information.

Yeah. The other piece is, it's the year 2024, and if you're already getting airdropped into an environment that got tens or hundreds of thousands of CSPM findings, the chances of you having a SOC, pretty much zero. So there isn't a SOC to assign these to. There's you, and if you're lucky, maybe a few other security folks, so therefore, you really only can hit those most immediate, in that triage framework. There's only so many things you can hit, so hit the ones that are going to give you the most risk reduction for the least amount of effort.

Rich Mogull: I've got biases here because I built something to do stuff. And we're not here to talk about that today.

I'll give you an example. Years ago, I went in and it was a consulting thingy and they were using a different CSPM [00:34:00] and it was when I was doing some of my Securosis work as I was, it was a training. So it was just, I was coming in and doing one day training. Basically on the big gaping security calls, as I was sitting there, they pulled up the security team and the devs were in the room.

This was one of the cool things is they were using me in this one day workshop. Yeah. To get security and development on the same page and so they pull the devs into place as well. And then the security guy pulls up their CSPM and goes, we have a thousand Lambda functions with admin access because that's the path of least resistance around it.

So what Chris said, and it's an area I spend a lot of work in, it's. Bridging that gap. Here's the thing you can not win. You never win in security. You just, you don't die. All patients die. Eventually all bleeding stops eventually. And the wind for me, you can't get ahead of things if you're not engaging with teams, that's not going to happen and building those bridges from a political standpoint and then a technical standpoint. Ryan Huber, when he was at [00:35:00] slack, he did a great blog post. It's probably still out there. I'm sure it still is where when he saw certain unusual things, he would just, it would automatically slack to an employee and the employee click. I meant to do this. It was like a 1 button and that dropped like 90 percent of what he needed to respond to what Chris was getting that is the more you can get to the automation and getting not everything. Okay. All right, because we've made that mistake. Let's throw every vulnerability into devs backlog.

Ashish Rajan: Yeah,

Rich Mogull: the critical eyes that we have consensus on send those a slack alert, send them as teams. Sorry, if your on teams , or whatever you're doing, make them aware of it, give them the time. Engage them to fix it. And this gets into security champions programs. This gets into trainings and all the other stuff you can do to make that the world better, other than just sending crap to the SOC, who's never going to be able to keep up.

Chris Farris: But the key is the ones that we agree to send. Not every high finding is a high finding. Most CSPMs I look at, unencrypted EBS snapshots are a high finding. So that already throws the curve of [00:36:00] things way out there, because those are the things that are going to come in very much the mass casualty way, the number of public S3 buckets is high, the number of publicly writable or readable buckets is generally low.

And so that's why those end up in that immediate categorization of triage because we can get rid of those quickly. Even if the bucket is public, it means that random people can't go figure out everything that's in the bucket, so those are the ones that make sense to target first.

Ashish Rajan: Maybe the question then becomes, how would you lay this out? Cause I think the conversations that I'm having are definitely a mix where the vulnerability management team was responsible until there was a, in charge of cloud security and in some of the other conversations I've been having where the SOC team is being up skilled to learn about cloud and cloud security because they have level one, level two, they are at scale, but obviously they don't have the skill set to understand the difference between an S3 bucket versus a EC2 instance. For them, it's just text on the [00:37:00] screen.

I don't know what that means. So there's definitely some upskill for that, that I've seen in some organizations and they're trying to go down that path. If I were to like, and I was going to use a Star Wars analogy because both of you are Star Wars fans. I don't know what would be the magic wand equivalent, but whatever the magic wand equivalent in the Star Wars universe would be.

How would you want this to be? Because I feel like vulnerability management. Used to be where my OS is not patched. And that's where usually they've drawn the line go. If the OS kind of goes into the cloud world, then maybe extends onto those components of computes that are OS running. They look at AMI or images, but I'm curious to hear from both of you as to where do you see vulnerability management, cloud security, and SOC kind of sit in this 2024 world if people had a choice to change that and use some Star War power.

Rich Mogull: Remember there is in Star Wars, you've got the empire and various flavors of the Republic or anyway, by the way, for your listeners last year, fwd:cloudsec, Chris, Ashish and [00:38:00] I, and a bunch of other people, we all hung out at Disneyland together, went to the Star Wars line.

It was a lot of fun. So that's how he knows our work. We have to face the practical reality that the reason there's not one size fits all is, as Chris said, some organizations may have one security person or a handful. Other organizations may have a security team of hundreds or a thousand people.

Your ability to do all of this will depend greatly on the scope of what you're responsible for and what resources you have. And that's why that mass casualty incident kind of concept comes into play because it's all about scaling resources

Chris Farris: And the universality of the cloud threat model. So you don't have to go worry about building a cloud threat model because if you are 1 or 2 people.

This is probably what you need to worry about. Except if FTX, where they didn't actually have a security team and they just put everything in secrets manager and we're a very large for 44 billion target. I think.

Rich Mogull: Picking on the bros, man. Everybody's picking [00:39:00] on the bros.

Chris Farris: Crypto was so 2022. Now it's GenAI.

Ashish Rajan: Who does crypto jacking these days? I'm like, I thought Bitcoin was old news, but to what you said in terms of being able to apply Universal Threat Model to companies of any scale, given a choice, say for medium large companies, because at a certain scale, you have enough resources to at least start looking at, okay, either we need to have a dedicated person or need to figure this out because as much as we like to or not like to we are in this world of cloud and perhaps multi cloud and containers and kubernetes and maybe Gen AI to some extent as well. ,How are people going to manage this?

Chris Farris: So I think going back to your question, what's vulnerability, what's SOC, what's cloud security? I think if you're dealing with just getting rid of all of the CSPM findings, that's a vulnerability management function and you prioritize the CSPM.

In with the CVSS ,in with the application security findings from whatever your application security tool is in one program, risk, rank it, [00:40:00] present it to the teams. Certain things probably are enough that you want them to be incidents. Okay. Developer. Just in your sandbox account, spin up a Windows instance, put 3389 on the internet.

That's not something that you want to show up in a report a week later. That's something you want to action right away. And so some CSPM findings probably are incidents. And I'm actually starting to say that CSPMs need yet another level of severity, which is the incident severity. It's above critical.

You have an incident severity, and as soon as that incident severity finding is generated, that's an event or an incident that your security operations center works on. And then your cloud security, a really kind of cloud security architecture, but there's a lot of different titles that start with cloud security.

They need to be focusing on the things that will move the needle and close massive problems. Oh, all of our databases are on the internet. That's because we don't have a meshed network of VPCs. [00:41:00] Let's go look at how we would set up transit gateways, establish direct connects or VPNs to the on prem offices, set up client VPNs or some other form of VPN or tail scale or whatever so that builders wherever they are in the world can ride RFC 1918 to talk to the database and you can get the dang thing off the public internet.

And that's then what cloud security should be working on. How do you systemically fix large swaths of problems. And then vulnerability management is there with the lists that come out of the CSPM with, okay, 15 databases got, remediated, but we still have these three and making sure that those three are still on the radar of the team so that they can then go and make sure, ah, yes, we need to schedule the downtime to read. Move this database and move it over here.

Rich Mogull: There's a phrase I use for one part of what Chris said. And when he's talking about the incident ratings, cause that's something I've spent time researching. A few years ago, I wrote a blog post. I call it Schrodinger's misconfiguration.

So if you think about Schrodinger's cat, the thought experiment [00:42:00] is you put a cat in a box with a decaying radioactive particle. And then if that particle decays, it releases a poison and the cat's dead. And so the idea is until you open the box, that cat is in a state of being alive and being dead, it's a quantum mechanics thing, which I have a history degree, so I shouldn't be talking to you about cloud security or quantum mechanics. The idea for the CSPM alerts, cause that's the term I use is CSPM alerts is for certain categories of misconfigurations. They are indicators of attack, and you don't know if that is an attack or not, because it exists in one of three states at the time that alert was created. It was either an attack, because again, this is always using legitimate credentials.

So it's either an attacker compromise those credentials and did that, or. It was an accidental misconfiguration, or it's on purpose and needs to be an exemption and it's a known good kind of state, or it was on purpose and it shouldn't be exempt. So I don't know, maybe that's 4 states. So any of those alerts, not for everything a CSPM can find, but [00:43:00] like a public S3 bucket, it's going to be one of those 3 to 4 things everytime Structurally, How do we deal with that?

And there's a few things that I found that because I've gotten over a bunch of different orgs from more of a governance perspective that can help address some of the stuff that exactly that Chris talked about. I think one is upscaling and training has to happen and in the SOC, like once you can get them to realize that you need to focus on, I call it cloud log before syslog, don't go into your SIM and do your hunting based on IP addresses and IOCs, which is all the time you need to be looking at your actual, like your cloud trail logs, your Azure activity logs, those things. So looking at the cloud logs as opposed to the syslog piece. So that's going to be a focus training. If you're big enough to have a SOC, you have to have subject matter experts for every single cloud platform you operate on.

So that SME may help.SOC depending on your size and may help the vuln management team and then may do developer relations pieces as well. And they're going to run the CSPM and they [00:44:00] maybe do architecture like if you're more in the midsize, but they have to know AWS.

They have to know Azure. They have to know Google. I am okay on AWS. Everything we've talked about. I'm only okay because every time I write like one of my labs, I have to double check with Chris and other people to make sure I'm not screwing something up. I learned from him. I learned from others every day, but Chris learned stuff from maybe not me, but from other people as well.

Like we're all exchanging, and you know who we hang out with?

Ashish Rajan: Yeah.

Rich Mogull: And you're part of that group too. We're always all exchanging info because none of us are experts on everything in AWS. And now I go on orgs all the time. They're like, oh, yeah now I have to do Azure. I'm probably competent on Azure.

By competent means. I'm just ahead of the person that's about to get clawed by the bear. I'm barely running faster than them. And I know real Azure experts with my level of knowledge in Azure. And then Google, like Chris is spending more time in Google, how much time is it going to take you to get equivalent to your AWS knowledge?

You can probably only do that if you have to, if you forget about AWS. Or

Chris Farris: quit my day job and all my other side [00:45:00] activities and go try and, because there is no compression algorithm for experience. And so the only way I could do that is stop doing other things and go redo my experience of the last several years, but do it in a Google scenario.

And I think going back to what Rich was saying, it's absolutely important to upscale, not just on the security team, but on the builder team to your builders need to, and not all developers maybe need it, but certainly the DevOps teams that are supporting the builders definitely need it. So the, there's a range of how much training each group needs, but they all need some,

Rich Mogull: look, we're biased.

Okay. So all three of us. I'm staring at the pictures right now, offer training classes of some degree. I think that the skills gap is a huge issue. And it's not that we're trying to be promotional. We try to teach as many people CPR as possible because there's evidence that shows early CPR is way more valuable.

If I show up as the paramedic with all my fancy electricity and drugs. And you haven't done CPR [00:46:00] properly in the four to 11 minutes for me to drive there. They're gone. There's nothing I can do with it. And that's what we're in. So security awareness, the security champions programs, I think is absolutely critical, getting those people in, getting them to know, the basics.

You need to know CPR. And I need to know how to yell clear and press the press. They don't give us the paddles anymore. Look I need to go off on a rant about this. Like the Johnny and Roy paddles.

Ashish Rajan: Cause they give you the patches, right? Maybe to add one more layer to this as well. And I think you guys are right.

I'm a hundred percent agree. And so the fact that there's definitely training required, not because all of us provide some form of training, but just in general, if you talk to anyone who has experience in cloud and you talk about how many people do they know that know cloud, how many people do they know that know more than one cloud?

If someone's saying they know more than one cloud and they know both of them really well, I'll be really surprised or they're lying. Sorry. Or they don't know what really well means. Oh, it could be that as well. Where I was going to come from is that people who are listening or watching to watching this.

[00:47:00] What's a good starting point ? Some people suggest. Hey, we should do tabletop exercises. We should do the security lunches thing. What's a good place to start teaching your broader, like the SOC team as well as your developers and DevOps people. What's a good starting point?

Clearly it's not going to be training from the cloud service provider for sure. Cause I think that's going to be very biased and everyone knows the fact that every, I'm not going to name the trainer, but people, but then sometimes you find you're in a CSP training and after every class.

So who's going to use the service in their own environment today? And you always go that's that's sometimes the questions being asked by trainers, but I'm curious to hear from both of you, where do you think is a good starting point?

Chris Farris: I would start with CloudSLAW. CloudSLAW serves a purpose of really like a cloud engineer, like the person who's going to own the AWS org.

Ashish Rajan: Yeah.

Chris Farris: That, that's where we've progressed to now. So if you are an Azure organization. And suddenly, congratulations. Now you need to go. No. A. W. S. CloudSLAW is [00:48:00] the perfect place to go to. Okay, here's how to actually open the 1st account correctly. That's amazing. Not that. Oh, hey, we built this whole thing.

And oh, then told us to turn on org. So I clicked the orgs button in my workload account. And we talk about one way doors and two way doors. Turning on orgs in your workloads account is not necessarily a one way door. It is a portal to the other side of the universe, and you will spend nine seasons getting back to where you started, where you can then progress on with doing anything else.

I would say Cloud Slaw for that cloud engineering. For a basic developer, I've not seen anything really good. And part of that is because developers don't take security training. Developers want to go and learn the latest frameworks and the latest languages and all of that cool stuff.

Ashish Rajan: Yeah.

Chris Farris: There isn't a lot that says, okay, here's the best way to go and assume a role into another account so you can read this S3 bucket rather than just making the S3 bucket public so you can read from it.

Rich Mogull: So for people who don't know, it's Cloud Security Lab a week. It's a free newsletter you can sign up for. And it's a [00:49:00] 15 to 30 minute lab every week. And 19 weeks in once I finish editing today's.

Ashish Rajan: I'll definitely put a link in for that as well. I'll definitely recommend that as well.

I think I agree with what Chris summarized about CloudSLAW. If you have absolute zero idea, but you're technical, not like you don't know what networking is, you're definitely a bit technical in terms of you've done some IT in your life. Definitely a good place to start. Sorry.

Rich Mogull: No, I thank you guys for being supportive because it's a lot of work.

So it's cool to have people supportive. So I think there's a couple of things like eventually in a year, I'll be able to point a pathway through something through that where developers can pick and choose pieces to learn some of the techniques. Chris and I had talked about, do we create a security champions training, like a one day for these developers, the CCSK, which in again, bias, cause I'm behind that, you teach that as well.

Yeah. Or at least you're authorized to, I haven't looked at the numbers to see if you've taught classes yet, but that can do it, but not really. That's more, I've used that for developers, but it's more along the other lines. I do think the cloud provider trainings can be a little useful [00:50:00] there.

As long as you temper that they're showing you, there's nothing wrong with the training from Amazon or Microsoft and Google is that training should show you how to use their tools. That is the purpose of that.

And at a certain point in time, I tell people who take some of my other trainings. That it's great that you're here and I'm going to teach you the general principles.

If you're the AWS person, you need that training also because you need that level of detail that I'm not going to get into in the kinds of things that I do. I think the onus can be on the security team. However, what I have found that is useful, the security people, if you're in an organization big enough to have a program like this, you can build some of your own training.

You can take the bits and pieces of the work that all of us have done in other areas and put together lunch and learns and stuff where the developers. And then also, because then you get to integrate how you do things if I get hired to do a private training, I'm like, great. What SIEM do you use?

What this what that what your process is? It's not about I can teach you my generic stuff, but your team needs to know how to use their tools. Yeah. And that becomes a very big part of what the [00:51:00] security team can do and listen to your show and participate. Like plenty of developers are interested in this

Chris Farris: I did a presentation for the day job on what attack threats are happening, in 2024 and it was really just a combination of breaches.cloud and probably some of the early iterations of Universal Cloud Threat Model and it was very well received because it was topical, tied into things that people were seeing in the news. It was tied into. Hey, why did my, prescription drug cost me 500 this month? Ah, yes, somebody didn't do MFA on this thing that was on the internet, and now nobody can actually process prescriptions in the United States.

Those are the sorts of things where we should be able to make security fun and exciting and interesting. Because God knows the threat actors are making security exciting and interesting, but in the Chinese curse sense of it.

Rich Mogull: There is a hacker in every fricking movie and TV show on the face of the planet.

Ashish Rajan: Yeah. Like

Rich Mogull: security is not [00:52:00] boring.

Ashish Rajan: Yeah. Yeah. A hundred percent. Definitely not boring. But what is boring is coming to the end of the chat. Unfortunately, I would love for you guys to share, obviously CloudSLAW from Rich and I think the training that Chris you're doing as well. But before we got into that, I have three fun questions for you guys.

I think Chris has already heard of this before, but the first question being, what is something that you're proud of that is not on your social media?

Rich Mogull: Oh God, my whole life's on my social media.

Ashish Rajan: Are you including your cat?

Rich Mogull: Yeah, including my cat.

Chris Farris: He's not proud of his cat.

Rich Mogull: That's a tough one, because you both know how open I am, and so I'm like, I got my pilot's license, but I don't shut up about that.

I'm a paramedic, I don't shut up about that. I dress up as a stormtrooper, but I don't shut up about that.

Ashish Rajan: No, see, I did not know that you dress up as a stormtrooper until I actually met you. So I imagine a lot of people who are tuning into this stuff from a cloud security background. So they may not even know that part about yourself.

So they may not know about the, all the other things you're clearly doing that you have so much time for outside of cloud.

Rich Mogull: I don't have a lot of time. And one of the things I did [00:53:00] get into and enjoy is I'm in the 501st Legion. So I've got a, an approved stormtrooper costume, but I also build ones for my kids.

So I'm staring, I have a helmet from Sabine sitting over there from Star Wars Rebels. And then I have Pusheen the Cat a lorian.

Chris Farris: I'll answer what's not on my social media that I'm proud of my children, because I don't let them, especially my young one, be there. Wow. Where's that from?

Rich Mogull: So Pusheen the Cat is like this meme cat thing for an online web thing.

My daughter, a few years ago, decided she wanted a Mandalorian Pusheen costume. Oh wow. So I custom built one and she went to Comic Con. Where is she at for it now? She doesn't fit it, but yeah.

Ashish Rajan: Oh wow, there you go. And thanks for sharing that as well, Chris. Your kids are going to get definitely a shout out over here as well.

So both your kids got a shout out. The second question. What is something that you're spending time on when you're not working on solving cloud universal threat problems?

Rich Mogull: For me, it's been flying. It's been like the big thing. So I, what kind of plane are you flying at the moment? Mostly a Cessna 177 Cardinal.

Which is this 1968 airplane bigger [00:54:00] than a 172 and then I, the flying club I'm in has a 172. So I got my license in November. I spent last summer training, training to get your pilot's license in Phoenix in the summer is interesting because of the thermals and such, but I just got back Monday.

I took off work. It was my birthday last weekend and me and a friend I ran in the plane all day. We flew up and we flew around the Grand Canyon. So it's the first like big thing like that I've done and it's just fun. It's like this cool skill. It scares the crap out of me every time.

Ashish Rajan: Thanks for sharing that.

Chris, what about yourself?

Chris Farris: So I think the last time you asked me this, I was renovating in my daughter's condo. That, thank God, got finished because I hired Professionals to do it. Right now. I'm actually catching up on a whole bunch of other cloud security stuff that I haven't been doing, but I am planning summer vacations and travels and that is the other thing that I like to do is see the world and, get to other continents.

So kind got Frankfurt and Brussels ahead of me. Now, Brussels is tied into a cloud security thing. Yeah. But it's is an excuse to, of course, hang out in central Europe for a while. Yeah,

Rich Mogull: very hard at helping me find an excuse to go aswell .

Ashish Rajan: [00:55:00] I'm going to look forward to seeing both of you anyways.

Frankfurt is not far from Brussels either. So I should tie that together. Final question.

Chris Farris: Frankfurt's for Christmas markets in November. So yeah, we're planning that far out.

Ashish Rajan: All right. Okay. Fair. Christmas markets in like Germany and stuff are definitely great. So I would definitely agree in support.

Final question. What's your favorite cuisine or restaurant that you can share with us? Chris, I've heard yours, so Rich, do you want to go first? Favorite cuisine or restaurant?

Rich Mogull: My favorite cuisine is is Mexican and

Ashish Rajan: we've

Rich Mogull: got some good ones. There's and some of them aren't even like super fancy or anything.

There's one Carlos is the name of it. And yes, that is a Mexican restaurant. That's what I ordered for my birthday. So I love that. The other cuisine I love is breakfast. That's probably my favorite.

Chris Farris: Always a good steak for me, a really fancy sushi place is always worth doing so. Yeah.

Yes. Plan to find one of those my next trip when I'm out in San Francisco.

Ashish Rajan: Guys, this has been amazing. Thank you so much for doing this with us as well.

And it's been a long time coming, so I'm glad we [00:56:00] got the opportunity as well. I'll definitely put a link for your talk for RSA as well. Where can people connect with you guys on the internet to talk more about the universal threat model, but also all the other work that you guys are doing, including the training that you guys provide as well.

Chris Farris: So anybody who's not already in the cloud security forum slack should join that and the easiest way to get an invite to that is go to www.fwcloudsec.Org, fwdcloudsec. org. There should be a link on that to both the conference in North America in June, the conference in Brussels in September and the slack that you can fill out a form and request to join.

And that's probably the best way to find both of us. That's how we find each other. And you can find me on Twitter, JC, Jake, Chris Farris. Same thing at Mastodon at Jake, Chris Ferris at InfoSec Exchange. Cool. No, LinkedIn. I am on LinkedIn. And you can find me as Chris Farris Cloud security nerd, or what do you, Rich?

Rich Mogull: The same, the fwdcloudsec community, how the three of [00:57:00] us know each other. Yeah. Cloud Security Forum is one of the easiest, best places, obviously Securosis, SEC. U R O S I S dot com. And if you want to do CloudSLAW that's you can get to through Securosis, but it's also SLAW security lab a week at securosis. com. If you want to sign up for that, I'm R Mogul, R M O G U L on almost every social media. I'm technically on Twitter, but not really. I have my account, but I basically dropped it on Mastodon. I'm R mogull at Def Con dot social and LinkedIn. And those are the best places to find me.

Ashish Rajan: And I'll put all the links in there as well, but.

I was gonna ask, who is on Mastodon these days? Is there, outside of you two are there other cloud security people there?

Chris Farris: Cloud security, not so much. There's definitely other security folks on there. And I like following that group. Because they're looking at the other pieces of the global threat landscape.

So I can say, ah, look at this. This is how I know [00:58:00] that, North Korea is crypto mining as a way to fund their nuclear program. And I should correct myself. I'm apparently not J Chris Farris at Twitter. I am JC Farris at Twitter and therefore that at InfoSecExchange. I'm only J Chris Farris on GitHub.

All right.

Ashish Rajan: Okay. I'll make sure the team puts the right link as well, but thank you so much. I'm looking forward to seeing you both and looking forward to hanging out as well. But thanks so much for doing this and thank you everyone for tuning in. Definitely connect with Chris and Rich on everything that they do, all the amazing work they do as well.

So thanks everyone for joining in. I'll see you next one. Thank you for listening or watching this episode of Cloud Security Podcast. We have been running for the past five years, so I'm sure we haven't covered everything cloud security yet. If there's a particular cloud security topic that we can cover for you in an interview format on cloud security podcast or make a training video on tutorials on cloud security bootcamp, definitely reach out to us on info at cloudsecuritypodcast.

gv. By the way, if you're interested in AI and cybersecurity, as many cybersecurity leaders are, you might be interested in our sister AI Cybersecurity Podcast, which I run with former CSO of Robinhood, Caleb [00:59:00] Sima, where we talk about everything AI and cybersecurity. How can organizations deal with cybersecurity on AI systems, AI platforms, whatever AI has to bring next as an evolution of ChatGPT, and everything else continues.

If you have any other suggestions, definitely drop them on info at CloudSecurityPodcast. tv. I'll drop them in the description and the show notes as well so you can reach out to us easily. Otherwise, I will see you in the next episode. Peace.

‍