 All right, everyone, as I said, I'm Ryan Smith, head of product defense. Thank you for joining us today for our webinar about mastering AI driven cloud security and what it means for kind of a new era for how we think about and do remediation as security practitioners with me today. I'm incredibly lucky and humbled because I have your guest by the security officer at Druva joining me, you guys. Welcome. And thank you for taking the time to join us today. Thank you for having me. Excellent. And then I'm also humbled because I have Sandy, our founder and CEO, and not only is he our founder and CEO, but it's his birthday today. So we're lucky enough that he chose to spend his birthday talking about AI driven remediation with us. So it shows his passion for the subject that he's here doing that rather than out celebrating today. So send it. Welcome. Happy birthday. And thank you for joining us today. Thank you so much, Ryan. Thank you for the birthday wishes. Excited to be here. You're looking forward to sort of dig deeper on this topic with you and Ryan. Excellent. Well, before we dive in, let's get to just a few housekeeping items. Attendees will be muted throughout the course of the webinar today. The webinar is being recorded and that recording will be emailed to participants with the slides at the end of the call. We will also take questions. You can leave them using the Q and A of the zoom feature, but you can ask them at any time. We'll either address them at the end. Most likely, or if it makes sense, we'll do it kind of throughout the course of the conversation today. Today's conversation is going to be a panel discussion around a couple of key topics. The first is alert prioritization and remediation and why these are such big problems for organizations today. How does AI's explosion immediately implicate kind of cloud security and what will be kind of the first cloud security solutions that adopt AI will then kind of dive into the meat of the topic around remediation. How does AI help us introduce a new area of remediation that's more efficient, leads to better results and ultimately helps scale our security capabilities as organizations. And then dive into a deep fence release, which is called ThreadRx, which is an implementation of LLMs and AI models to act as security assistance for us to streamline remediation efforts, whether that be with the patching of vulnerabilities, how those are prioritized within our security posture or their remediation today. But let's start immediately with this first insight, right? We'd recently organized a survey of our customers and fellow colleagues in the field and 90% of those organizations felt that alert prioritization and the ability to simplify remediation in kind of light of all the complexity we see within infrastructure was the number one issue facing their organizations today. So, Yogesh, I'm going to maybe start with you here. In your experience as a CISA, how important has this or how big maybe has this problem of alert fatigue become within organizations and, you know, how important is getting prioritization correct? It's a great question, right? I think, you know, it's probably one of the top five core problems that exist in the security space, right? And there are a couple of reasons for that. If you take a step back, the security industry as a whole has a problem what I would call 100% problem, right? So security teams are responsible for 100% of good outcomes. You won't find a security team that says that we are responsible for 70% good outcomes, right? So then the question is how do we achieve 100% good outcomes or 100% prevention? Essentially, it means we want 100% detection, we want 100% investigations and we want 100% remediation, right? That's tough. It just means that we want to find everything, fix everything, investigate everything and remediate everything, right? Now that's one part of the problem. The other part of the problem is we have a volume problem, right? To get to 100% detection, you know, when you think about vulnerabilities, we are already good at trying to find the known nodes, right? If there is a package that we know as a vulnerability, it's not that difficult to find, but there is just too many of them, right? So there are too many things that need patching, too many vulnerabilities that need fixing. And on the cyber defense detection and response side, companies are struggling with the tradeoff between noise and false positives on one end and false negatives on the other end, which kind of, again, going back to the 100% problem, you need to tip the scale and alert on everything and detect everything to kind of get there, right? So now these two combined together is a lethal kind of state, right? Because what they do is you have too many tools, you have too much insight, you have too many things to do and too few people to do it. And, you know, I think that has kind of led to, in many cases, burnout in teams because, you know, whether it is the SOC and incident response teams or whether it's vulnerability management teams, you know, there is a lot of burnout that is happening. But even more importantly, right, things are getting missed also, right? Things get missed because when there is too much to do, there is a repeated nature of things where it's possible to either not act on things or not miss things. And there are a lot of stats out there is one stat that you have up there. You know, sometime last year I came across an IDC stat that said that regardless of the segment of that you operate in, right, whether you're a small SMB company or you're a large enterprise, you know, IDC found on average close to around 30% alerts were being, you know, not acted upon or not missed. And that's, again, going back to the 100% versus volume kind of trade off. So it's a very critical problem for the industry to solve. No, I definitely appreciate that insight and it's something we see organization struggling with every single day. So maybe Sandy, if I throw this question over to you, you know, after seeing so many customers kind of struggle with this key problem statement. You know, what has deep fenced on to help them kind of identify the critical issues facing them in the cloud today and really prioritize this deluge of information that's coming out them from these cloud security tools. Yeah, absolutely. I mean, I couldn't agree with your wish more. Absolutely everything that he said, I think it applies even more. The problem is even more serious severe in cloud security in CNAP specifically right. Either you have agentless ways of scanning or network based scanning or host based scanning. You are always detecting more that you can you can fix it never converges the more you scan, the more you find it's a recipient asking you know, we're done a blog post around that earlier I remember that. So that's that's really the problem. So you're not seeing broadly enough is not a problem anymore. You're saying broadly enough you're scanning often enough. But ultimately, what do you do with those hundreds of thousands of findings that are being thrown at you every time you scan. And in fact, you know, we deal we're working with some customers and I think your fish can second what I'm really saying here is one of the customers probably in the top 20 companies after companies in the world. Every time they scan 40,000 vulnerabilities are reported. One of the financial majors that we've been speaking to 100,000 vulnerabilities plus every time they scan and we're speaking only about vulnerability so so far we're not speaking about, you know, CSPM that's cloud with configurations we're not speaking about malware. You put all of this together. This is a huge problem. And you know what, ultimately results in burnout you miss things that you shouldn't miss, you know, end up wasting time, you know, fixing things which probably are not critical stuff like that really. So what we realized after speaking to so many customers so many users of our open source platform as well is in order to prioritize better, you need to fetch the additional telemetry from somewhere. Now that somewhere has to come in either, either, you know, from the endpoint itself the host itself, it has to come from applications, dependency services that are running on those on that infrastructure. There should be one source of telemetry. The third one of course is the actual network traffic, you know, what, what exactly, how exactly is our security groups configured exactly which ports are open who's talking to whom live traffic, you know, who's calling who in API calls and stuff like that, or you have to get that additional telemetry from, you know, identities essential users whose which account you know which users who's doing what, or go deeper in data. There are five ways you can sort of bring in additional context that you can help to prioritize in a better way. And that's what defense is really doing. What we're really saying, look, we already have context from the hosts or the containers in which these vulnerabilities are, you know, found. Yes. Can I also figure out additional context based on the live traffic patterns, live network flows within the cloud, that will really help and you know we'll talk about exactly how. And the third one, of course, to the, you know, exactly the application context, one, you know, classic example is, and this was such a big problem when lock for J happened really and even recently when the SSG attack happened. People knew they were affected, but they did not know exactly how to go and fix. It's like everybody knew they're affected by this vulnerability but exactly where should I go and what should I do to fix it really that was the code problem more of an operations problem. What we really figured out is being able to tell, like Yogesh was mentioning earlier, this particular package has no other ability. That is the easy path. And you know, at a large enough infrastructure, you will have, you know, hundreds of thousands of such issues. Being able to tell this particular package is actually loaded in memory of a process, which is running in a container. And hey, you know what that container or part essentially is is configured in such a way in my cloud environment that it can talk to the world, you know, directly or indirectly, and that just makes it more exploitable. If the network attack vector, if the attack vector is network really, and you know, that's what we're really trying to figure out. If you just focus on exactly what is exploitable, not worry about just vulnerabilities, but actual exploitable activities, I think you can go from these hundreds of thousands of findings to just a handful that really matter and that you should be in a focusing right now, not tomorrow right now because that exploit table immediately. And I think a major theme you hit on there that, you know, causes complexity that causes people to deal with prioritization is scale. Right. And we obviously see that at the scale of some of the enterprise organizations that we help. I mean, you talk to, you know, hundreds of thousands of vulnerabilities that every time they scan, you know, hundreds of thousands of nodes that they need to protect millions of cloud resources that are changing. And that's just infrastructure complexity and scale you throw on the fact that AWS builds 100 new services every month, you know, developers start leveraging you throw in the fact that people have Kubernetes cloud native infrastructure. They have legacy hosts, they have serverless functions, and they have this in multi cloud environments. It's a lot to, you know, secure and to you guys just point a lot of times we could have the best processes the best detection tools and things but we just don't have the people or resources to handle kind of security at that scale. Right. And so let's kind of transition to some of the effects of these kind of problems of prioritization and why they're such a big deal for organizations today so we see things like 67 to 70% of cloud breaches are due to simple misconfiguration. People leaving the back door unlocked right they left an S3 bucket open to the world with customer data and a threat actor walk right in and you know just downloaded the file. You also have the fact that because of some of those operational issues that are outside of our control, whether those be, you know, internal ones, people issues scaling our people and the number of people we have to dedicate to problems. Political problems and infighting within an organization's it takes organizations 4950 days to patch critical vulnerabilities and you know threat actors already done significant damage with it within that amount of time. Even if we take the dwell time, which is the amount it takes for an organization to detect and then remediate a threat actor. That is 21 days across all threats. Now, the rub here though, is that in five minutes in the cloud, in particular, a threat actors often kind of done the dirty deed and gotten up with what they need to. So, with that big of a gap, you know, I want to say, you know, gosh, you know, maybe as a C. So, what are some of the operational challenges that you've experienced in your day to day life that lead to 49 days because like we've all said, detection is easy we know about these things sometimes instantly. You know, why does it take so long to patch sometimes makes sense. So, you know, I think talking about two, two different themes here right one one or two different topics that one is about patching. And the other is more around, you know, alert or attack detection, so to speak, right. Now, when you talk about patching and finding vulnerabilities, I don't want to say that you know, it's easy to find vulnerabilities right it's easy it's probably easy to find the known known vulnerabilities. But you know, operationally you already talked about some internal challenges that exist in most companies right there is a manual process involved. There is a manual coordination prioritization process involved there are multiple teams involved in the end to end process from where a vulnerability goes from identification to to being patched. And then obviously there is a volume problem is not not too kind of double hammer on that point. But again, it's a big part of the problem right, but I think one thing that is crucial that we are missing is context for prioritization right. So we think about it right now, or historically prioritization for vulnerabilities was CVS is based right so you know, CVS is being a standard, people looked at 100,000 issues and said well what is CVS is eight and above, you know, and that's the way they prioritized it. CVS is basically external context right so you're adding external context to a vulnerability. Now, recently, there has been some innovation there now EPSS has come in, where that context is getting a little bit more fine tune more refined. So you have CVS is your VPSS and those are all external kind of stimuli to prioritize, you know, 100,000 issues right. But what is really missing is you don't have internal context, right, for the lack of a word, you know, just come up with something I will call it IVSS like internal vulnerability scoring system right nobody has that there is no industry industry standard for internal scoring system and to generate that context and you know that kind of leads to a lemon kind of problem where there's a lot of asymmetry right. The triage teams are not really familiar with all the context they need to kind of prioritize the vulnerability, a single tool does not have the visibility to kind of generate all of that context. We're talking about, you know, the current environments cloud where, you know, it's like if you look at the entire technology stack, you really need a context from each of the layers of the technology stack to build a prioritization context right whether there is you know traffic whether there is something happening in memory where there is something happening at the application layer, and you need to stitch all of that together to get very accurate understanding of what is material. Because at the end of the day that's what we are trying to do right you know we have 100,000 issues is hard to fix 100,000 issues so we are trying to figure out what is material for us so that we can boil down narrow down and fix only the things that are material to us. So I think you know the same goes you know what is true for patching is also true for alert triage where volume is a problem but again context for remediation is a problem right. If you imagine, many companies have hundreds of AWS and GCP accounts today in the cloud, right. They're owned by 50 different teams for 40 different use cases, and you know they have they have infrastructure that is dynamic constantly changing auto scaling with all of this when there is one indication of a incident for for for you to go in and really accurately figure out what is happening accurately scope the incident, and then more importantly figure out how to, you know, immediately remediated is not a easy task right there's a lot of manual manual thing happening there where people are going asking questions, trying to log into multiple tools trying to get that context, and I think you know that kind of shows up again and again in terms of the dwell time because even after you find an alert and that alert is even a true alert right there is a significant amount of time it takes to really scope and that's incredible insight. Thanks for sharing kind of that perspective into some of those operational issues and how many of them stem from a lack of context right and send deep that's maybe a perfect segue into my question for you here which is, how can technology better help solve or address some of these operational issues, especially at the scale of the problem that you know guest was just talking about, you know, multi GPS, GCPN AWS accounts, different infrastructure that's auto scaling up and down all the time. You know, talk about how technology but specifically AI and thread rx can help alleviate some of those operational issues. Absolutely I mean everything you've said really two things come to my mind. It really boils down boils down to two things, a meaningful signal to noise ratio that that is really useful which is everything you wish it would said which is about cutting down the volume, really focusing on stuff that matters, having some sort of logic which is like IV SS I love that by the way, we always make a cool new stuff in you know these discussions you wish always always enjoy this. So internal vulnerability scoring systems for example really which is really about the context of your infrastructure your applications you know your identities and stuff that you're putting in to fill their out cut down the volume and coming to that point where you have, you know, just a set of attack parts you know that you're really dealing with you know some of those attack parts are caused by a vulnerability some of them are caused because of in a cloud misconfiguration could be a malware you know stuff like that. So first part is really that you know arrive at a meaningful signal to noise ratio so that your team teams are not burning you know cycles. So that's the kind of casing unnecessary things that can wait really number one is that number two once you're done with that. How do I reduce the operational burden, which is where I think LLMS come in picture, you know, Jenny I comes in picture for example, first start you know, like think about this way right a new vulnerability the very first ask or very first task that LLMS could do for you is basically just explaining the context in which this particular vulnerability of this particular meaningful misconfiguration affects you as a user really just explaining with the additional context that we have gathered for example, like the runtime context on also all the context which is out there, you know, that is, you know about that particular issue number one is that could just be a simple start. For newcomers in the team, for example, really right number one is that number two. You can go ahead and make suggestions around patch versions and how to exactly fix this particular issue if it's a misconfiguration maybe you know, in it. A Terraform snippet really or a pull any code snippet that you can use to go ahead and run that come, you know, a patch that particular issue if it's a misconfiguration. Similarly for vulnerability patch version exactly what steps to follow. And oftentimes what really happens is a lot of these limitations are multi step workflows. It's never like you just went ahead and install one package and everything is done. There is something else that has to be done a lot of that is really, you know, can be automated has to be, you know, sort of templatized in that way. And that's where I think it comes in picture really, you know, templatizing this multi step remediation workflows. Once you were right at a deeper or a better signal to noise ratio by using additional context. I think these are the two key things I think all security teams could do. Currently, the way we are doing this your dish, you know, in defense is essentially using elements to reduce that operational burden, right telemetry collection that is happening elsewhere using our ebf sensors and in a cloud content all of that. But right now the way LLMs are fitting in is basically reduce this operational burden by giving you code snippets and you know, think of it as a copilot, you know, remediation copilot that helps you do all of that. Right. Yeah, let's dive a little bit more into that use case of how AI can be that remediation copilot, particularly in use cases of cloud security. You know, we have this graphic which illustrates that AI and generative AI will be used both by threat actors and cybersecurity professionals alike right so it will create new challenges. But it will also definitely help make us more efficient as cybersecurity practitioners read it helps scale the capabilities of our teams so we can do more with less resources. It solves the cold sort of problem like Sandy was talking about in terms of how we enhance our cyber security posture. But ultimately, you know, the two use cases that we're going to really focus on throughout this webinar today are prioritization of remediations and accelerating and making more efficient kind of that resolution loop and time. But, you know, you'll guess as as you've kind of encountered a whole new grave new world out there of AI kind of exploding like it has a particularly over the last two years at the scale it has. You know, what are some of the ways in which you feel that AI will be useful to you as a security practitioner and, you know, are you starting to evaluate that with vendors right as a feature said or as an enhancement. of their capabilities at all. Yeah, so I'll take up the second question first right. The vendor, you know, AI is like a storm and it's, you know, just flooding everything right so when you look at the vendor landscape. There's hardly anybody who is saying that they are not doing yeah. So you know it's there's a lot of noise there in terms of, you know, really figuring out and trying to find products that are truly and accurately leveraging AI to to reduce some kind of pain point right so pretty much every every vendor out there is is kind of leveraging AI. But really I mean you know, I think I can be used, you know, the bullet points that you have on the right side of your screen for for all of those things very accurately right we talked about IVSS the internal system to get the right kind of context. But you know, if you if you think about attack detection response and remediation which is the last point right. Imagine, you know, historically until now, the way that word operates is there is a static run book right so somebody writes down a list of steps in a wiki page or a document, and then junior analyst is opening that up when there's an alert and then he's going through that steps. Now, you know that probably work 20 years back when networks were static and the architecture was static. As we just you know talked about before, it's all auto scaling dynamically changing interconnected interdependent multi cloud complex environment right. So there is no way to have that run book kind of be that static the book has to be dynamic. And how do you have a dynamic run book right so the the only way to do that it's a it's a knowledge problem right the knowledge is changing you need a system that can pass through, you know, a complex set of knowledge base, and on the maybe on the fly come up with a with a run book for a particular issue and say look like based on what we currently see in the network and in the system and how you know all the pieces fit together. We think this is the run book and this is what a security analyst should do. Now I think that's that's really the holy grail. You know, it's easy to talk about and difficult to solve and optimize for, but really I think the first place where I could immediately solve a need is to really you know move tier one to AI, right, where where you know the tier one tasks, at least the investigative pieces of getting everything together is being being done by AI. That's definitely true and I think we'll see a lot of those functions just like we've seen lower level functions and other operational areas across the business get kind of eaten up by AI that would be certainly one of the first areas to go but you know, like you said, there's a lot of noise, but there's still a long way to go for a lot of vendors in the space of their adoption of AI. So, Cindy. Why did you all as a vendor start with those last two areas which are prioritization and acceleration or resolution time. You know it seems like those are kind of basic building blocks, but maybe that's the point. So, I mean, you know, you know remedy prioritization of scan results be it vulnerability be the cloud misconfigurations be it secrets or be it malware I think that is that is a day zero need of every every every security cloud security right so it's really it really starts there. You do that you scan your infrastructure you prioritize you fix what what has to be fixed in a immediately and everything really comes after that right like you know runtime detection and protection and you know everything else really comes. That's really the fundamental building block prioritization is the biggest problem within that which is what we're really trying to address right with that graph. And of course acceleration accelerating the you know resolution time really right or remediation time essentially, that's where we're trying to optimize that bit by, you know, having LLMS right come to our rescue there by reducing the operational burden, removing that cold start problem. You've just said it very very accurately which is static run books, nothing about your job now with static the infrastructure is moving the traffic is continuously changing and you know vulnerabilities are getting reported every hour, you know. So how can you rely on a static run book and that's where you need something which parses rocks this really complex knowledge base and you know helps you on the fly. And that's where you know we have basically adding that and why essentially for prioritization and you know reducing the solution time because these are the two most senior problems cloud security teams are facing you know. So we starting there. I mean, I think we see it every day in the business right. A lot of companies or vendors are focusing on the scale of their detections but yet the OAS top 10 stayed the same for 20 years we still get popped by zero day vulnerabilities. People still take 49 days to patch. We haven't solved the fundamentals yet of cloud security so even the more advanced capabilities are going to stumble and falter a little bit if we can't you know prioritize effectively and actually go address the things that we find or detect right in a meaningful or efficient way. You know part of the way reason why it's hard to do that is not just the scale of the infrastructure that we're protecting or the complexity of it. But because of kind of what's the represented here is it's a lot of operational process to get from detection of something to prioritizing that to sending it to all of the appropriate teams to fixing scripts and getting those new scripts improved and deploying the fixes and then getting the remediations and policies optimized for next time. And by the time you kind of gone through that whole cycle. There's a whole new slew of attacks that you have to worry about that like our almost make the stuff that you were working on kind of old news so, you know, gosh, you know, we've already covered kind of the operational challenges of 49 days to patch up. How much is like a AI, you know, or, you know, what's the opportunity for AI to maybe scale the tap or solve this talent problem like because I don't foresee us getting more subject matter experts anytime soon or, you know, people's budgets getting infinitely larger So, you know, how much of this is that kind of talent issue and, you know, being able to kind of do a lot with the insights that we gather. Absolutely I think you know talent issue, but I would raise something else right. Security teams face with are faced with organizational silos also organizational silos lead to knowledge silos, right. It just means no single party has the full context of anything really. So what happens is, you know, if you think the number of personas that play a role in a, you know, investigation you have the security teams. You have, you know, incident response teams you have one of the management teams, you have system owners, you have data custodians, you have network architects, and you have engineers developing software right and all of these things kind of together play a role when we think about scoping an incident or containing an incident. So usually what security teams do is get everybody on a call and then you know try to understand Hey, you know, did you build the software should it go here what is the purpose, or what kind of data is it, you know, should it be here. What is the architecture. So all of that is a is a is a excruciatingly manual process, right. And so if you want to remove those knowledge silos, then that's where I think again you know as we talked about AI can can tremendously at least get a head start in terms of the understanding that is required to scope and remediate an incident. Yeah, I appreciate that and Cindy, can you just explain a little bit about, you know, these pieces down here about building guy roles fixing your terraform templates and, you know, getting easy to use CLI scripts right part of our problems. I don't have a Kubernetes that were always on hand to, you know, update the Kubernetes network in there and stuff so you know what ways are you kind of exploring how I can help with maybe that issue. Absolutely I mean it's it's always like you know you wish sort of mentioned in the last, I think as an answer to the last question is, can I do I have a co pilot or somebody on my staff or somebody who can help me. That boilerplate that I can use and see if this is going to fix my problem. It could be a terraform template could be a patch version or you know what any of those things really a lot of this is really, you know, repetitive grant work right like and you have to do it. There is no other way about it. There is no no choice if it's a critical issue. And that's what I think you know L and M's come in picture. Which is like I said, you know, there's already, you know, have, you know, rock that knowledge base. And it's not, you know, operational and knowledge base silos you wish mentioned and that is so so accurately put really is that need something which is basically, you know, putting all of this together and you know, in a meeting that in a code snippet that really gets you started right. It could be here on this one command and that's if you're good, or you know, fix this thing in the Helen chart and you're good, or you know run this a wcli command and it's done or here is a pulling me script which is basically going to take it off all of this issues. All this can be automated. All this can be emitted by LLM's really right. You don't have to really sit and write codes. You know, the static run books that you've mentioned again, you're really LLM's are really going to help you keep those make those run books dynamic and ever evolving based on what you're seeing on day to day basis really right that's where I think that comes in picture. Right, just to add to that right I think one point probably forgot to kind of talk about is just understanding blast radius. That's a knowledge silo problem, but it's not something that can be solved by a human, you know, right to get like you know just ask somebody and explain what is the blast radius, because imagine a scenario you have you have an incident on a particular machine. So what do you track and figure out what's on that machine. If there is a token, you know what does that token have access to, and then what is the the kill chain from that token where all the permissions go and what all things can can be can be acted upon right. So that's like going forward problem of understanding blast radius but that's also a remediation problem right. You know, even if you break organizational silos and get people together in a room, you know, it's very hard for that room to come up with what is the most optimal optimal technical solution to mitigate the risk, right, whether it is, let's patch vulnerability or whether it is let's take the machine out of circulation, or whether it is change the security group, or move it to a different VPC you know all of these things are options right and that's a very hard guidance to come up with. You know, people have to spend a lot of mental brain power to kind of analyze issues and try to figure out what what what those two things are right and AI is the perfect suited for that because you kind of get that ability to you know churn through all of these things and pull out that crisp accurate guidance. Yeah, it's a usable right, Yogesh and this this guidance is reusable as well in the sense, once a certain issue is striaged in this way, and you know you build up, you know, basically you add it to your paybook. Next time you see something, you know, similar, you basically ready with the steps remediation workflow that worked for you earlier, it might not work 100% for this one but hey look you, you're not starting cool now you already have a reference template that you can use, which will basically solve maybe 75% of your problems right you go you review it and then it's ready to go really right so that that really also sort of you know it's not only about new problems it's also about similar problems you know so this is all reusable templates that you've been created. Yeah, I love that you both went there because that's where you know I wanted to focus here is, you know, sometimes these steps, you ideally you would do all of them right and then ideal perfect world and you would patch it and all the teams would cover it then you would fix your tariff arm and then you would have a golden new golden image but the reality of the situation is, it's going to take 49 days to patch but sometimes you can solve the immediate risk to your organization by flipping a security group, and that is easier to do than working with all of these different functions or all of these different steps and you can do something here that short circuits all of the immediate risk caused by some of this operational workflow and how long it may it may take to do it so incredibly insightful but you know I think if I was to sum up some of the insights here but ultimately it's about reducing operational burden because it simplifies kind of tools, integrations between those things, automations, playbooks, it makes those things dynamic. It helps scale our talent pool and reduce the problem of having subject matter experts in every part of the organization or some of those night knowledge silos that were talked about earlier. It can accelerate the time to remediation, decreasing meantime to detection and meantime to response by giving us those scripts templates playbooks and helping us change without having to involve necessary people all the time, where there would be manual effort. And then it allows us to ultimately have and apply this to us right and our environment our context because not only AI is the accumulation of human knowledge to an extent but it's also the accumulation of the knowledge that we feed it and so if we couple that with runtime context application network traffic and things like that then we can get to some of these questions that would often take you know even a long time to decipher, but I want to spend a little bit of the last part of this webinar really walking through how deep friends with threat RX, which is a feature in our threat striker platform elite helps us with the remediation of critical security alerts. And Cindy, you know, I really want to start with you on this one of, you know, how deep friends really thinks about prioritizing security findings along with AI, not only to help organizations build an internal threat graph of their attack surface. You know, we're going to be taking those thousands of issues down to the three that you should be looking at, but then how threat RX helps remediate those attack paths and vectors and and really shortens the whole cycle here so maybe you know just take a few minutes like explain the defense platform and what you all are thinking about with threat RX here. In fact, you know that the picture that you see in front of you right now essentially has both of those critical pieces. The first piece essentially is how do I go from hundreds of thousands of scanners or to a handful that matter, and also in a manner that is you know uniquely actionable in the sense, can I go from a flat list of you know, a few thousand vulnerabilities to attack paths, which are live and taking in the sense they're really derived from additional telemetry that you're you know gathering from the infrastructure, like network traffic, you know, you're looking at what is loaded in memory of course. Hey, here is a particular vulnerability. It's actually in a package which is loaded in memory. The security groups are configured in such a way that you know traffic can actually reach here from outside so you really figured out that north south attack path. You know, an attacker can exploit this from outside of my infrastructure now because hey, the vulnerability is in a locked and loaded. The traffic HTTP request can actually reach this particular node where this particular vulnerability is loaded and stuff like that, you know, all this, all this additional context gets you what we call is thread graph. Thread graph is basically a exploitable subset immediately exploitable subset of all of your attack surface, which is derived by scanning for vulnerabilities for cloud misconfiguration sensitive secrets that might be lying around in your container images or, you know, on your post and of course malware. Right. So that's the first part that is called thread graph. Now, just imagine if you had an ability to right click or just say that hey, I see few, you know, attack paths which are live here as a threat graph. Can you actually help me remediate all of those. Right. Now, or some of those like that that you find more more meaningful or more more urgent really. You can say that hey, you know what this particular attack path which is coming in from outside and actually going to this particular part where I'm running my critical service, can you remediate this. And, you know, threat Rx comes in picture there. What it is going to really do is it's going to take all of the context that it has about the vulnerability or, you know, malware, whatever is the reason for that particular threat. Attack graph to exist. It's going to look at how your security groups can configure it, how traffic is really flowing traffic is live of course. You're going to look at all of that. And then you're generating a remediation plan based on that live attack path, which is there. This is so different from this is so you know, think about the other case right what is which is what we've been doing traditionally. You go to vulnerability and then you go to the security advisory and figure out a patch and you run it really right that's that's the old school we're doing things it doesn't scale we know that by now. What we're really doing is, you know, going from that, like I said, in hundreds of thousands of vulnerabilities to thread graph and thread graph, every live attack path you should be able to remediate generate that multi step remediation workflow for each and every attack path. So we're doing north south attack parts, but the same technology can be applied like you should mentioning earlier lateral attack parts or the blast radius right. Yeah I know this particular pod is talking to that particular S3 bucket, and not only it has a vulnerability, but it also has some sensitive data stuff like that you can also figure out the blast radius, and you know apply the remediation essentially using threat rx not only for the north south attack parts but also figuring out the whole blast radius and remediating it. So that's really what we're doing with defense thread graph is something that we launched even in open source almost, it's been more than a year, and it's really getting tremendous reviews because people are able to sort of in a go from, you know, those thousands of scan results to just meaningful stuff and the rx is something that we launched about a month ago right, which is basically, you know, adding remediation on top of on top of this attack graph that is already built using the additional runtime context. Yeah, no, appreciate that explanation and overview here. So, you know, when we think about runtime context, particularly, you know, how it helps us filter insights within our environment. You know, I think what you've said a few times on this webinar so far is, you know, sometimes the easy part of security is the no notes right the things that we know are bad and things like that but, you know, sometimes this is what a zero day is we didn't know that something existed it's within the infrastructure we know it's everywhere because it's in a library that is, you know, you know, throughout the entire open source stack and things like that. You know, how is that context important and identifying what to do in those areas where a patch might not be identified yet and so you need to know hey this new outbound connection opened up and that's certainly weird right because that hasn't happened in the past 60 days but now we have these new communication patterns within the architecture or stuff like that. So just talk a little bit about that runtime context and why this visual representation of it is so important in your role as a CISO. Absolutely right I think when you say runtime, there are two different facets to that is there is a system runtime, right and then there is a network runtime, and I think you know to accurately understand what is going on you need both of those things together, right. So, again, I mean I think we have talked about this before but for bad things to happen something has to be first loaded in memory. There has to be a port, there has to be incoming traffic to that port and that traffic has to be malicious in nature, right. And if all of those things are true then you know, maybe there is, there is a partly a problem right. There is an outbound connection from the same place right and it's going to a, you know if you add external context and say well that that IP or that domain is against suspicious, then you're adding a lot of, a lot of different types of insight to kind of pretty much confirm that there is there is a problem going on right. Without the network context, you just don't know right that might imagine a scenario where there's something loading loaded in memory but then it has never received any traffic and it is not currently receiving traffic. It's a prioritization issue right it can help you prioritize but it's not really an active problem that needs to be solved. Or maybe you know as you guys talked about that there is a there's a package with a vulnerability and you know there is no lack of those right there are hundreds and thousands of issues that come up again and again, but it's not even loaded in memory then why should we should care about it. Developers and technical operations cloud operations teams, they are kind of supporting the business right, and you don't want to kind of waste, waste time by kind of whack a mole approach where you are just because you don't know how to prioritize or how to accurately, you are just saying that let's prioritize everything and let's remediate everything, which is probably the, you know, more costly solution for the business because if you really want to be more efficient in terms of the time required then you need to accurately point out what needs to definitely I mean there is a ton of time that could be spent towards core business functions, maintaining applications that are important to revenue functions and things like that that is spent on compliance management and patching and reporting within DevOps organizations today so that's a very real issue so let's walk through that life cycle you you just talked about a year there has to be a vulnerability. It has to be critical and severe and you know active, it has to be loaded in memory. There has to be an intact path to it so it has to be accessible. So you have to identify both of those things. And then, you know, there has to be, you know, the ability to see the traffic for when it actually is exploited so when as a threat actor actually utilizing a certain TTP so the next few slides are going to walk through a very famous example that we're all familiar with probably almost beat to a dead horse at this point but it's very clear and easy to understand in the context of what we've been talking about which is long for show right. This is your day vulnerability, even before it was kind of known what the patch and remediation is, we knew that the outcome of this type of vulnerability would be remote code execution behavior so you know we wanted to see this vulnerability loaded in memory and then detect it so you'll gosh to you, you know, CVSS severity been long the benchmark for security, but you talked about it. You know, how does context that having that I DSS help us determine actual risk versus potential risk and, you know, it particularly in the case of like a zero day what was that so important to do because you had 1000 instances of lock 4j everywhere, you know, now what do you go tackle all 1000 of those or how do you determine you know what's important out of those 1000 hosts that might have that. Absolutely right I mean I think again, think about it this way I think you know it was December when lock 4j happened, maybe two years back now right. So in December you have teams running 24 by seven trying to figure out where they have an issue and how to patch it quickly and patching you know it's easy to say, but it's extremely hard and complex. It's not that straightforward right systems don't run in a silo in a vacuum in isolation, they're all interconnected so patching is a hard problem right. So, you know, if you think about lock 4j that that insight of all you have 100,000 instances of lock 4j in your environment, what only 100 of them are actually currently loaded in memory helps you prioritize well let's focus on these 100. If you know if if there is no, you know, network path to those instances, or if there is no north south network part I mean I think there is a there is a distinction to be made in terms of severity between what is externally reachable versus what is east west reachable right. So there is another context that you can use to prioritize those hundred issues even further down to say that look out of those hundred. There is east west network path for all hundred but only 10 of them have a north south network path from outside your network coming into insight so you're further narrowing it down to the 10 that you need immediately need to fix. And then you know potentially you could use the blast radius and additional context for for for kind of, you know, prioritize those 10 as well right to some of those assets might have, you know, access to sensitive data, or they might have, they might have, you know, I am roles assigned which roles can have, you know, downstream access to more critical systems right and you can use all of that context to really narrow down, I mean I think I'm coming up with numbers out of a magic head but well down to five right so you quickly drastically reduce the immediate risk that you need to solve. Now I wouldn't say that that that means your job is done right we can't just fix four issues that are that are that are kind of the most critical and call it a day, but you can definitely help use that and leverage that to say that look like you need to immediately fix over the next few days, while we come up with a more business friendly less impactful plan to kind of remediate the potential risk also right so for something like lock 4j you probably need to to remediate all risk because as we said you know things are not static. So something that is potential risk right now can become an active risk risk because something changes and and you know so you don't want that to kind of pester around as a potential risk risk for a very long time but again that this context can help bubble that up also right. Imagine you fixed all of the lock 4j issues that were an active risk and then the rest were not loaded in memory or there was no attack path and then you you know kind of even if you waited for fixing those. If there is a change that in the system that kind of creates that attack path at a point in time you can bubble that up and increase the IVSS score so to speak and say look like this is now IVSS 10 right so you need to kind of take a look at that. So all of those things will be super useful. Now I think you covered you know what I was going to cover with Sunday was you know all of that lack of context really leaves. You blind right if you are just using kind of maybe a traditional host space vulnerability scanner without kind of looking at those configuration changes the network traffic what's loaded in process and memory and things like that so really almost modern kind of or vulnerability that's been undergoing kind of an evolution right now to where if you just use those kind of legacy tools then you're going to be left blind to a lot of important steps for prioritization and then on the remediation side. Obviously this is exactly what Sandy was talking about earlier what we have up on screen in the screen challenges. Here is a CLI script which gives you a quick way to check and update libraries related to log 4j configuration so this would be an issue of addressing, you know kind of that risk at the patching level, but we may not even need to actually do that for all of the risk right which was what Yogesh was getting at was that sometimes there's a configuration that's allowing access so I think you said there is like maybe in your fictional math 10 of these EC2 instances that have public IP addresses that have traffic that's kind of live with them right so maybe actually addressing this configuration change with a Terraform script would be the quickest path to remediation so having that additional context really helps us kind of do that but Cindy maybe talk to us a little bit about what having you know CSPM data in a threat graph does for companies and why you kind of incorporated CSPM our secret vulnerability data all into kind of a contextual picture for organizations. Yeah absolutely I think these four the ones that you mentioned which is vulnerabilities cloud misconfigurations malware and sensitive secrets lying around. These are the four fundamental types of scans of course there are more and in a lot of seen apps also go deeper in data and you know elsewhere, but I think these are the basic building blocks that's where you need to start. More specifically about the what is the meaning of an attack path when it comes to a cloud misconfiguration issue really right. I think it could be two simple cases really right a lot of this has been covered already but here is an S3 bucket which is speak which is being used by one of my services where it is writing you know sensitive data it's something sensitive data and hey you know what it's open to the world very very simple very basic you know CSPM 101 kind of an issue really right this is a clear cut north south attack path you know that this is a S3 bucket which is misconfigured you go a little deeper and then you start seeing these indirect or lateral attack paths you know also called blast radius which is where you start seeing things like hey you know you know you know what here is a vulnerability in in a package. Which is running you know in a certain part and that part is running the critical service which is dealing with PII and hey you know what it is also accessing this as three bucket, which is not directly exposed to the world, but now it has become part of that whole class radius because because of this one vulnerability which was really you know which was basically exploitable. So ultimately it all comes down to that IVSS scoring mechanism that we have come up with IVSS 7 is immediately exploitable compared to CVSS 9. If CVSS 9 is not really you know accessible to attackers you know because it is not in a running node or container stuff like that. So ultimately yeah when it comes to CSPM I think these are the two examples that come to my mind Ryan. Yeah I love that. Appreciate that insight and ultimately that leads us into actually neutralizing the threat. So what we're going to actually see is the JNDI to LDAP connection, which is the runtime incident. And there's going to be a couple of ways of neutralizing that threat right and and holistically throughout that lifecycle in the moment you might want to filter network traffic or quarantine a workload. Ideally you patch the thing, you know, then you could make a configuration change ideally to prevent the network traffic there's a number of steps. So AI not only helps list those various steps and options for us or strategies. It helps us prioritize those different strategies as well, leveraging that kind of context that we had before and and give us kind of the best solution to what we were seeing, even if it's not, you know, the options that another organization would take. To make the most sense for us and I think that's really the way in which we'll see AI being used as kind of a hyperanalyst or kind of a security analyst that can kind of be queried with ultimate knowledge of the organization security posture regardless of those knowledge gaps, like the cyber gap security gaps that you guys was talking about a little earlier. So, you know, I think this has been a very interesting and thoughtful discussion. So, you guys and Cindy, I deeply appreciate you joining us today. Before we get to just a few questions we have in the audience, I'm going to maybe turn it over to you guys for any closing thoughts you might want to leave the audience with or, you know, things that have come up in today's presentation that you think were particularly insightful that people should take away as a few key takeaways. Yeah, I think, you know, zooming out broadly, a lot of the things that are a problem in the security world are knowledge problems, and knowledge summarization problems, and how to effectively use use summarization of knowledge to kind of some kind of action or a workflow right. So that kind of, it takes care of a lot of different issues, right. So I think as we move forward, we'll see a lot more applications of these, you know, there's a question around zero trust, you know, maybe just quickly answer that in that context as well right. Zero trust is probably a much broader kind of framework, so you probably need another hour to just talk about zero trust NEI and what things can play a role there. But imagine the same scenario right like you have authentication and you need to have continuous authentication to systems based on the context that you have for the endpoints or for the servers that are authenticating right, and that real time context generating that in terms of hey you know if you take the example of an endpoint, are there any, what is the posture of the end point, are there any security issues on the end point is there any active attack going on the end point what about the user, you know is even targeted, and just pulling all of that together in the authentication context is a similar kind of application of generative AI to solve a different set of problems. You know, appreciate those closing thoughts and and once again thank you so much for lending your valuable time and insights as a security practitioner to this discussion because I think it's something that we don't hear enough from as the practitioners themselves and how this is impacting their daily lives I think we make a lot of assumptions about it within the vendor landscape but you know it's great to hear from security thought leaders themselves which is this what this whole webinar series has been about for deep vents. Sandy as always thank you for leveraging your insights as a founder in the space who's actively building products to solve those operational challenges for organizations. I know we had a few more questions that we will follow up answers to as we send out this recording and the slides to this so we will make sure to get all your questions answered but I do want to be respectful of everybody's time today as we run up against the hour. So, thank you everybody for joining the conversation today. The last things I'll leave with us is if you want to try deep vents, please go visit defense. You can visit the get deep ends page and you can get started with our enterprise edition either cloud or on and as well as our open source edition, which is used across multiple organizations around the globe. It has, you know, 1.3 million people are kind of leveraging its bulls and has been a great kind of start in the fundamentals of cloud security for enterprises today so thank you for the time today. Thank you for the deep dive into this discussion around how AI can help us master remediation, given the complexity and scale of the cloud, and we'll catch you next month for our weapon our next webinar in this series.