That was impressive. In terms of how people look at this, and they have been a lot many more as well. There's Microsoft LastPass, 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 tired to the white people that you've ever written. You know, it's a third model. 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 the 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 listeners, 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 where after that, it's just basically unknown territory for everyone, app then become application 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 point in time becoming the receiving end of all the CSPM alerts in a lot of organizations where cloud security is focusing on, hey, are you correct? They're not. They are not. And that is one of the problems. And I'll turn that in my mind, they're going towards it. So they're not fully there yet. I definitely feel like a lot of the talk companies that I'm stuck into, where they're realizing the cloud security people are becoming a lot more about. For some reason, we're installing a 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 then in the conversations you guys have? So either into a black hole or

into the vulnerability management program, and they're getting prioritized public S three 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 CVS, S 4.0 or TLS encryption 1.1 or whatever. I see them mostly feeding the vulnerability management program. 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. And it should trigger a sore workflow that basically says bad thing happened. I have an event in cloud trail or whatever your audit management log is. I either know the identity of the carbon base 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 base life form at the end of this that approve the PR push to commit whatever. And those are the people then the security operations can reach out to and say, hey, you didn't know. 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 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 sock 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, 100,000 CSPM findings can't be 100,000 tickets for a sock tour. You don't have a sock that 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 your demo in five alerts out of 50,000. I'm like,

I don't know, at scale, that's like, 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 big gaping security holes I'm talking about. Those are the things that aren't necessarily a sock ticket. They're definitely a jurid ticket to the builders who have to go remediate it. But I wouldn't pollute your sock who's also looking at incoming telemetry and active attacks with that information. The other piece is it's the year 2024. And if you're already getting air dropped into an environment that got tens or hundreds of thousands of CSPM findings, the chances of you having a sock pretty much zero. So there isn't a sock 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 medians 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.

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. And it was when I was doing so my secure this 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 goals. As I was sitting there, they pulled up the security team and the desert room. This was one of the cool things is they were using me in this one day workshop to get security and development on the same page. And so they pulled the devs into place as well. And then the security guy pulled up their CSPM and goes, we had 1000 lambda functions with admin access because that's the path of least resistant around it. So what Chris said, and it's an area that's been a lot of work in, it's bridging that gap. Here's the thing, you cannot win. You never win in security. You just see, you don't die yet. All patients die eventually, all bleeding stops eventually. And the win 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 Hubert, when he was at 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, they would automatically Slack to an employee. And the employee click, I meant to do this. It was like a one button. And that dropped like 90% of what he needed to respond to. Well, Chris was getting that is the more he can get to the automation and getting not everything. All right, because we've made that mistake. Let's throw every vulnerability into Dev's backlog.

Yeah, the critical eyes

that we have consent song, send us a Slack alert, send them as teams. Oh, sorry, 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 and skits into trainings and all the other stuff you can do to make that the world better, other than just sending crap to the sock who's never going to be able to keep up.

But the key is the ones that we agree to send, not every high finding is a high finding. Most CSPMs I look at on encrypted EBS snapshots are a high finding. So that already throws the curve of things way out there, because those are the things that are coming in very much the mass casualty way. The number of public S three buckets is high. The number of publicly writeable or readable S three 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. Maybe the question then becomes how would you let it start? Because I think the conversations that I'm having are definitely a mix where the Wonderability 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 skill 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 S three bucket versus a EC2 instance. For them, it just takes to the screen. I don't know what that means. So there's definitely some up skill 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 the Star Wars analogy, because both of you are Star Wars fans. I don't know what would be the magic around equivalent, but whatever the magic weren't equivalent in the Star Wars universe would be. How would you want this to be? Because I feel like Wonderability Management used to be where my OS is not patched. And that's where usually they draw the line go. If the OS kind of goes into the cloud world, then maybe extends onto those components of computes that are always running. They look at AMI or images, but I'm curious to hear from both of you as to where do you see Wonderability Management Cloud Security and SOC kind of sit in this 2020 forward? If people had a choice, you change that and use some Star Wars power. 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, Forward Cloud, Zach, Chris, she and I, and a bunch of other people, we all hung out at Chisley land together, yeah, which is Star Wars land. It was a lot of fun. So that's how he knows our person at Mass here. We have to face the practical reality that the reason there's not one size fits all is, Chris said some organizations may have one security person or 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 casually incident kind of concept comes into play is it's all about scaling resources.

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 one or two 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 Secret Planner and we're a very large for $44 billion target, I think. Hicking on the bros, man, everybody's picking up bros. Crypto was so 2022. Now it's January. Who does

crypto jacking these days? I thought Bitcoin was the old news. But to what you said, in terms of being able to apply universal threat model to other companies of any scale, given a choice, say for meeting 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 communities and maybe JNI to some extent as well. How are we going to manage this? 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, present it to the teams. Certain things probably are enough that you want them to be incidents. Okay, developer just in your sandbox account, spun 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 CSPM's 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. 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 remove this database and move it over here.

There's a crazy use for one part of what Chris said. And when he's talking about the incinerating is because that's something that I've spent time researching. Here's a guy who wrote a blog post, I call it Schrödinger's Miss Configuration. So if you think about Schrödinger's cat, the bot makes me bet is you put a cat in a box with a gang radioactive particle. And then if that particle decays, it releases a poison in 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 language. I have a history degree, so I shouldn't be talking to you about cloud security. Next, the idea for the CSPM alerts, because that's the term I use as CSPM alerts, is for certain categories of misconfigurations, they are indicators of attack. And they 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 compromises 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 four states. So any of those alerts, not for everything a CSPM can find, but like a public S3 bucket, it's going to be one of those three to four things every time structurally. How do we deal with that? And there's a few things that I found that because I've gone 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 upskilling 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, go into your SAM 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 to ban your size and may help the whole management team and then may do developer relations pieces as well. And they're going to run the CSPM and they maybe do architecture like you're more in the mid-sauce, but they have to know AWS, they have to know Azure at no Google. I am okay on AWS. Everything we 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 learn from him, I learn from others every day like 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. Yeah. And you're part of that group too. We're always all exchanging a focus, none of us are experts on everything in AWS. And now I go and ores all the time, they're like, Oh yeah, now I have to do Azure. I'm probably competent on Azure. My competent means I'm just ahead of the person that's about to get clogged by the bear. I'm barely running faster than that. And I know real Azure experts with my level of knowledge in Azure. And then Google, like Chris is spending more time at 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, like or quit my day job and all my other side 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 too. Your builders need to and not all developers may be needed, but certainly the DevOps teams that are supporting the builders definitely needed so that there's a range of how much training each group needs. They all need

some. What 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 tried to teach as many people CPR as possible because there's evidence to chose early CPR is way more value of I show up as the paramedic with all my fancy electricity and drugs. And you haven't done CPR properly in the forward at 11 minutes for me to drive there. They're gone. There's nothing I can do with and that's what we're in. So that 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 panels anymore. I need to go off on a rant about this like the johnny and Roy paddles. Yeah,

because I give you the batches. Maybe to add one more layer to this as well. And I think you guys are right. I'm 100% agreeance on the fact that there's definitely a friend required. Not because all of us provide some false on-flailing, 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 no cloud? How many people do they know that no 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. I'm sorry. Or they don't know what really well means. Yeah. I could be that as well. What I was going to come from is that people who are listening or watching watching this. What's a good starting point? People suggest, hey, we should do table dog 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 cloud service provider for sure. Because I think that's going to be very biased. And everyone knows the fact that every, I'm not going to name the trainer or book people, but then sometimes you find you're in a CSV training and after every class lesson. So who's going to use the service in their environment today? And you always go, 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? I would start with

cloud. Oh, yeah. Yeah. Cloud's law serves a purpose of really like a cloud engineer. Like the person who's going to own the AWS org. Yeah, that's where we've progressed to now. So if you are an Azure organization and suddenly congratulations now, you need to go know AWS. Cloud's law is the perfect place to go to. Okay, here's how to actually open the first account correctly. That's amazing. Not that, oh, hey, we built this whole thing and oh, then AWS told us to turn on org. So I clicked the orgs button in my workload accounts. 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 or you can then progress on with doing anything else. I would say cloud's law for that cloud engineer 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. 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 three bucket rather than just making the S3 bucket public so you can read from it.

So for people who don't know, it's called Security Lab a week. It's a free newsletter that you can sign up for and it's a 15 to 30 minute lab every

week and 19 weeks in once I finish editing today's definitely the link in for that as well. I definitely recommend that as well. I think I agree with what Chris summarized about cloud's law. If you have absolute zero idea, but you have technical, not like you don't know what networking is, you definitely have a technical in terms of doing some IT in your life. Definitely a good place to start. Sorry. I just want to call it down. No,

I even 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 have talked about do we create a security champions training like a one day for these developers. The CCSK, which in again buys because I'm behind that, you teach that as well, or at least you're authorized to. I don't look at the numbers to see if you talk classes yet, but that can do it, but not really. That's more, I've used that for developers, but it's more on the other lines. I do think the cloud provider trainings can be a little useful 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, would 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 and take the bits and pieces of the work that all of us have done in other areas and put together one of the options 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 sim 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 security team can do. And listen to your show and participate like plenty of developers are interested in this.

Yeah, 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 dot cloud and probably some of the early iterations of universal cloud threat model. And it was very well received because it was topical. Yeah, 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 the 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. Here's a hacker in every frickin movie and TV show on the face of the planet. Yeah, like security is not boring. Yep.