Video: Wiz Defend: The future of cloud detection and response for the modern SOC [EMEA] | Duration: 3476s | Summary: Wiz Defend: The future of cloud detection and response for the modern SOC [EMEA]

Transcript for "Wiz Defend: The future of cloud detection and response for the modern SOC [EMEA]": Early for you, but we'll get started in just a minute or 2. We got a Louisville. I I will leave out the Louisville Slugger. I don't feel like anyone needs that reference. Okay. So East Coast people, you can grab it's almost a beer. It's almost beer o'clock. You can grab your lunch. Got Atlanta, Richmond. Fabulous DC. I'm impressed that you can be in Manhattan and Southwestern Connecticut. That seems like a really good accomplishment. Shout out to Seattle. That's where I'm based, so no no bias. We've got a really wide variety of folks in here today. That's awesome. We'll give folks about one more minute to get started. Oh, okay. In Mexico, if you're I hope you're sitting out there with a sitting on the beach taking this webinar. Alright. Well, I expect a couple more folks to filter in, but I will get started in the meantime. Hello, everyone. Welcome to today's webinar, Wizdefend, the future of cloud detection and response for the modern SOC. My name is Laura. I am part of the Wiz campaigns marketing team, and I will be emceeing today. So we're so excited to have you join us today and we appreciate you taking the time from your busy schedules, especially in early mid December. Just so you know, there are a couple of ways you can engage with us during today's webinar. Type any and all questions in the chat box at the right. You can also use the q and a section. We can move them around. So don't worry if a question gets in the chat, we'll move it to the q and a. There's also in the right hand module, a section for docs. This includes related resources, a demo link if you're curious to learn more, as well as our launch announcements. We will do our best to keep track of questions and answer some of these in real times. Otherwise, I will be keeping track of them for the q and a portion. This will be recorded and you should get a recording in your inbox in the next day or so depending on when that email goes out, but definitely this week. With that, that's housekeeping. If you have any trouble, with the sound or noise or anything like that, feel free to log back in log out, log back in the standard, turn it off, turn it on. But feel free to let me know if you're having any more difficulties, and I will do my best to help. And with that, I will pass off the proverbial mic to Greg from the Wiz team. Awesome. Thank you, Laura. And welcome, everybody. We're really excited for you to be here. We appreciate you being here today. Really to take a look at WizDefend, which we consider the future of cloud detection and response. And I'm sure a lot of you saw our announcement, but, on December 2nd, we actually announced WizDefend into preview public preview. So really excited about that, and really the impact that Wizdefend will have on SecOps teams around the world. So before we get started and dive in, let me just take a moment to introduce the panel today. So quickly, my name is Greg Zemlyn. I'm on the product marketing team here at Wizz. Next, we're really excited to have Nate Stevens here. So he is a cloud security engineer from Matillion. It's, one of our valued Wizz customers, and they are active users of defend. So later in the webinar, Nate's gonna share his insights and experiences from, you know, his personal journey and his team's journey on the impact that that Wizz Defend has brought to their organization. And last but definitely not least, we have Ophir Bruckner on here. He's the director of product for cloud detection and response here at Wiz. And he actually joined us by way of the acquisition of JEM Security, where he was one of the cofounders there. So Ophir brings just a tremendous wealth of knowledge and experience, all things related to SecOps, incident response, cloud detection and response. So really excited to have Ophir on today, and, look forward to hearing from him as well. So I guess a bit more housekeeping, just kinda what you can expect from today. So we're gonna spend a little bit of time kind of giving a defend overview, particularly what problems we solve and what the solution actually looks like, at least in slide form. And then I'll pass it off to Ophir, and we'll spend a lot of time actually in the product going through a demo. I think that's, you know, at the end of the day, what everybody is here to see. And then finally, the part that I'm excited for is our discussion with, Matillion. And so I wanna make sure everybody gets their questions answered throughout the session. We're gonna leave some time for live q and a at the end, hopefully. But, as Laura mentioned, please feel free to put in any questions that come up along the way in chat. And, you know, anybody that's not speaking at the time, we'll try to answer them as they come in. So with that, I think, you know, before we dive into defense specifically, I think it's important, to take a step back and and really understand the broader Wizz platform and kinda understand, you know, where we started, which kind of informs our decision on where we're going. So I'm sure many most of you are very familiar with WizCloud. You know, this is really what started Wiz. It's fundamentally about security posture. It gives you that full agentless visibility to identify and prioritize risk in your production environment. And we really, you know, built WizCloud with cloud security in mind, GRC in mind, vulnerability management teams in mind, but also built the platform in a way where DevOps can come in and developers come in. And, you know, the great thing about Wiz is, you know, roughly half of the users of the platform are nonsecurity personnel. So very easily digestible information. You know, we talk a lot about cloud security requiring a new operating model. And, really, you know, a big part of that operating model is breaking down silos. It's getting teams into the same tool. It's allowing for security to be self serving. And so from WizCloud, it was a very natural extension to Wizcode. Right? This is shifting left. Wizcode is really about securing everything during the software development life cycle. So, securing your BCS itself, but then also identifying risk and hopefully mitigating that risk during your pipe or development pipeline with the hopes that it never makes it back into your production environment. And so, really, these two pieces are something that we consider, proactive security here. Right? Like, you're identifying risk. You're mitigating that risk. Hopefully, before anything negative happens to your environment, You're effectively reducing your attack surface. So doing everything that you can to really, protect yourself. But then, you know, you need to also be in a position where you can detect and respond to emerging threats. And that's really what WizDefend is about. So it's the first product that Wiz has built specifically for SecOps. You know, SOC analysts, incident responders, everybody under that SecOps umbrella, we specifically tailor the tool for them. And I point out here, you know, Wizz has been working on cloud detection and response for a number of years now, and we acquired JEM, I think, 7, 8 months ago. And JEM has accelerated and really redefined how we approach cloud detection and response. So when Outfir takes us through the tool, I think one of the things that everybody will immediately notice is just this full unified experience. So it's, you know, really a single platform experience, for for SecOps as well. And so since the acquisition, basically, the teams have been building busy tearing down Gem's tool and and really rebuilding everything on Wood's infrastructure. So the last thing I'll point out here is just really the importance of having everything in a single platform. Right? So when you look at a threat that you detect, you have all the context all the way from code through your production environment really to to decorate that detection and, you know, give the teams all the context they need to actually go through and triage and investigate. And on the other side of things, you know, post investigation, when you're going through incident response, you can trace everything back from your detection all the way back to code and really, be able to remediate things at the root cause, which oftentimes in, cloud applications is at that code level. So looking at how the cloud changed things for SecOps, and it changed a lot of things, but a good place to start is really with the threats. So they're inherently different in the cloud. They're very sophisticated. And, unfortunately, the state we're at today is teams oftentimes are trying to detect and identify these threats using a set of tools that, you know, probably was not designed specifically for a cloud application. Additionally, they're using threat intelligence that, you know, may or may not be tailored to the cloud. Most oftentimes, it's not. There's also this requirement for, you know, manual creation and curation of detection rules. So, you know, not only do you have to collect the telemetry, but your team also has to ensure that you have adequate detection coverage. That kinda leads us into the impact. So, you know, if you do detect something, can you effectively investigate and can claim contain a cloud threat? You know, hopefully before there are serious business impact and repercussions. So oftentimes, this starts with, am I collecting the right telemetry? Or, unfortunately, you know, from conversations that I have, you know, do you even know if you're collecting the right telemetry until you have an issue and go to actually, do the incident response and and dig into the root cause of that incident? Do I have the necessary cloud context to make detections actionable? Right? Are you sending things to your SOC analyst where their immediate course of action is a whole bunch of manual queries to pull in context, really just taking additional time that oftentimes we don't have? Do you have the expertise and bandwidth? Right? With the tools that we have today, it's tremendously difficult to do investigation. It's you know, somebody, needs to have subject matter expertise in cloud investigations. It's hard to staff, oftentimes with enough enough resources to do that. And finally, can I effectively respond? So, you know, this is kind of a 2 part question in my mind. It's a technology question. But more importantly, I think it's actually a people question. So, you know, there's multiple owners now for, the cloud environment. You have to think the SOC to cloud security to DevOps to developers. So it's this whole chain. Right? And, unfortunately, teams are very, very siloed. And so, you put all these pieces together, and it at least begs the question. Right? So doing things how we're doing them today, just how much time exactly is lost? And that really brings us into, you know, the current state of cloud detection and response. And so what is the problem that WID solves? In general, what we see for SecOps teams today, you're taking in tons and tons of data. Right? There's no shortage in the cloud, certainly, of possible data sources you can bring in. And so we're throwing all this data, piping it all into a SIEM. And this is just a ton a ton of work for teams. Right? You have all this data. You have to build everything yourself. You're writing your own detection rules. You're spending a huge amount of time and resources. And, you know, unfortunately, oftentimes, you still don't get the coverage that you want or need, or maybe you don't even know that you don't have the coverage that you need. On top of that, when you go to investigate threats, I mentioned this before, just a ton of manual querying. You know, these queries take time. They take somebody who knows what they're doing, really just to answer simple questions like, is this a normal activity or not? Threat intel feeds that are not designed for the cloud specifically. Right? Oftentimes, we're bringing in endpoint threat intel feeds, and it's just not giving an accurate portrayal of, cloud threats as a whole. Next, teams are trying to respond. Right? For those that have adequate resources, there are a ton of homegrown playbooks and and scripts. It's not only the manual effort to actually create those, but then you have to make sure that they're always up to date. You have to make sure that they're always working. And finally, you know, in the cloud, investigating threats usually requires that application owner, developers, really that whole chain that I mentioned before. Right? So the SOC knowing who to contact that owns what part of an application and what part of the infrastructure that potentially needs to make a chain. All in all, we're just taking far too long to investigate and far too long to respond. So what does Wizz Defend actually look like as a solution? So defend, like everything that we do at Wizz, is really built on the security graph. So we ingest telemetry from multiple sources. Right? We have audit logs, data events, network logs, IDP, in infrastructure SaaS, just a ton of information coming into defend. Then we bring in runtime information with the Wizz sensor. So covering Kubernetes, super net or serverless, virtual machines, and we heavy we we automate all that heavy lifting correlation. Right? So I've talked a couple times now about the manual process to actually, run an investigation. But, you know, simple things or seemingly simple things like correlating runtime with cloud events, Tremendously time consuming. So definitely something that, Defend automates for that. So on top of this, we enrich it with our own cloud threat intelligence. So we have a very large, well known threat research team that is constantly curating threats, uncovering kind of emerging threats, emerging trends, updating detection rules for your team. We use additional, threat intel feeds as well. And finally, we bring in all that cloud to code context. Right? CSPM information, KIM, AISPM, DSPM. Everything that we have in the WIS graph can be used to contextualize these detections. So, finally, you know, we look at this in terms of 4 pillars. Right? You'll see on the right hand side here, this is kinda how we think of defend. And we'll go through this pretty quickly. And I think, you know, a good reason to do this, it'll kinda help steer Ophir's demo and help everybody keep track. But the first step is prepare. And, you know, we call this incident readiness sometimes. And the goal here really is to give teams a real time view of the visibility that you have, what telemetry are you collecting, and how that maps to how prepared you are to actually respond to an incident. So we take a look at your telemetry. We map everything to the MITRE ATT and CK framework. We show you any gaps that we have. But more important, we give you, actionable insights to actually improve your detection coverage and your ability to respond. The second up is detection, and I'm not gonna spend a ton of time here. O'Farrell will dive in a little bit more, but we really combine 2 approaches. So we have thousands of prebuilt detection rules that come from our WIDS through our research team. These are continuously updated, curated by the team. On top of that, we layer in behavioral analytics, and this is really done to reduce noise. And our end goal is to deliver very high fidelity detections out of the box. Right? We do some very unique things like grouping alerts that you'll see here in a minute. But really, you know, very high priority for us is to make sure that your SecOps team receives detections that they feel very confident they should always look into, and they're actionable out of the box. And that kinda leads into the 3rd piece, which is investigation. So for every alert, we automatically generate a full incident timeline. We show the blast radius on our investigation graph. We actually show the attack unfolding on the investigation graph. This really automates a ton of the manual investigation work that teams are doing now. And really the end result there is just a reduction in your mean time to respond. And the last piece is response. So we provide actionable recommendations, for how to contain an emerging threat. You know, this is supported with Gen AI Gen AI. It really can range from automated blocking at runtime to killing processes on the workload level to network isolation, role revocation. So tons and tons and tons of control at your fingertips. Additionally, you know, we we have, hundreds and hundreds of integrations with, the major security tools in ASOC. We don't require a change in workflow. We can integrate with the SOAR, run a playbook as a response. And then the last piece I'll bring up is really through the broader integration with the platform. It really unifies security teams. Right? It unifies your cloud security team, your sec ops team, your developers, dev ops. It brings everybody together. It really tears down those silos. And, really, you know, from customer conversations that I have time and time again, that that change in people and that change in security culture just hasn't a dramatic, dramatic impact on driving down the MTTR. So with that, we're gonna shift gears for a second, and, I will stop sharing and let Ophir dive in for a demo. Perfect. Thank you very much, Greg. And where do I I think you need to stop sharing so I can start. Sorry. I'm trying to find the oh, there you go. Perfect. Here we are. Alright. So as Greg mentioned with Wizdifend, our goal is to extend Wizdifend to, to, and expand on the real time and security operation aspect. And to that end, the first kind of gateway to is defend is the new board, the the security operations board. And this is where, we'll show you kind of a high level overview of, everything that is real time oriented. So the threats, the readiness, the sensor coverage, I'm gonna go into each one of these in-depth, but the one I I wanted to focus not to focus on now before we dive in is the detection pipeline, which is where you can see how we take millions or even billions of events depending on the on the size of the environment, and we narrow them down to a handful of threats that you need to to go over and, and investigate. And again, we're gonna go in-depth into how we do that, but again, just a nice, opening. And so the first, pillar I wanted to focus on is the readiness. And this is where we make sure that you have the proper visibility into the workloads, into the logs, and that you will get the signal that will enable detection and, also proper context when you're investigating. So we start with an accumulated, incident readiness score, and that actually breaks down into a couple of different factors. And the first, we can see it here. It's the log collection the log configuration breakdown. So what we'll show you here is the aggregated, coverage percentage for each category, but also for each log type that we mark as critical. So under control, we will look at things like CloudTrail, audit logs for GCP, activity logs for Azure, and so on. Under data, it would be s three data events, database audit logs, under network things like VPC flow logs, VPC VNS logs, and this list goes on. But again, the idea is to give you this sense of what's currently covered and where do you have the biggest gaps. And then on the right side here, we took the same data, but we applied a different perspective, the attackers perspective, and we're actually using the MITRE ATT and CK cloud, matrix to do that. So we aligned each of the MITRE techniques to the relevant log sources. So if I'm looking at something like ex filtration of data from information repositories, for example, you can see how these are all of the relevant logs in my environment. Now this is based on the inventory that Wiz already collect for your environment. So it's not just a static list. It applies to to the to the resources that you have in your in your tenant. And what we'll also do is we'll aggregate the covered percentage for all of these so you can understand you can see that, you know, for this technique, this is my aggregated coverage. And that's just a great way to prioritize and to to decide which logs you wanna cover first and, you know, which can waste bay which can wait based on the on the technique that you care about. And another breakdown that we've recently added is the sensor coverage breakdown. So sensor, while not mandatory, is a big part of the fend. And and, you know, those signals really enhance our visibility into the workloads, into the containers. So for it's highly recommended to have this deployed as well. And here we'll show you exactly where as the sensor been deployed, where do you have deployment gaps, and, you know, where you should fix these kind of things. And of course, with each of these, we can see the the covered resources, the uncovered resources, and so on. And the same goes for the logs. So if I'm looking at something like VPC flow logs, for example, I can get the full list of unmonitored VPCs and also a very quick remediation step for each of them. So I can just copy the CLI, run it with the right permissions, and I'm good to go. These logs will start, being collected and ingested, into WIS so we can perform both the detection and again, also use them to provide more context throughout the investigation. Now once we have the log set up, the next step is detection. And as Greg mentioned before, we, made some significant enhancements to the detection engine in Wiz. So the first, stage of the detection engine is actually the rules. And we have Wizz comes out of the box with tons of rules. We have over 2,000 of them. You can see them all here under, in the threat detection rules page. And as you can see, again, out of the box, we already cover all of the different MITRE tactics, all of the the big platforms, all the different, data sources within those platforms. But just a nice way to see kind of, again, a high level overview of what we're covering. But this is only the first stage. And when a rule triggers, we'll move on to the second stage, which is behavior behavioral analytics. So what we do is we build a baseline for every resource that we see in the logs. And it could be, you know, traditional UBA like users, machines, and such, but we've also extended it to the cloud. So things like s 3 buckets, managed databases, VPCs, anything that we can see as a standalone resource in the logs will be the baseline form. And then what we do is we try to find this combination of suspicious and unusual for this specific entity just to rule out any routine actions that keep repeating themselves and to reduce the numbers, the number of false positives that you have to deal with. And then after all of these stages, when we create a detection, what we'll also do is we'll group detections together based on the involved, resources. And this is where we introduce a new concept called threats. So threats in WizDefend are actually groups of detections, that you can investigate together just to get a a better understanding of what happened to get the broader story instead of having to manually connect those dots yourself when, you know, you're bombarded with a lot of of of disparate signals and and a lot of different, detections and alerts. And what you'll see here in the in the threats page is actually all those different threats, and I can, always expand any of them and see exactly what happened aside from the, the title. Right? So here, for example, we have a connection to a a very malicious domain. But actually, inside, we can see that there were a lot of bad activities, done by this specific role and, or service account, and and we can see them all here. And this leads us to the actual investigation part. So in with defend, we've created a new investigation workflow for those threats. You can take this one as an example. So here, what we're seeing is an easy 2 is easy 2 instance credentials that were being used outside of AWS. So we start by showing you some of the metadata, you know, the involved entities, the resources, the project rate happened, the subscription, and so on. But, the most important thing here is to see that this threat is actually a group of 6 different detections, and then we can see that we have signals from the sensor, from GuardDuty, from CloudTrail. We could have also had signals from VPC flow logs, from data events. We group all of these together, again, in order for you to investigate only one threat instead of those 6 different detections. And in order to help you with this investigation, the first thing we'll show you is the investigation graph. So what you can see in the graph are all of the involved entities and the way they communicated with each other. So we start with the originating IP. In this case, we also know it's malicious. Then we can see the machine that initiated all of those actions, the role that was used, the bucket that, some data was executed from, the process tree inside the container in case we have the sensor like here, and so on. And this entire graph is based on the Wizz infrastructure, meaning that we can always dive deeper and also get information from other modules in Wizz like the scanning, these configurations, the the DSPM. For example, here, if I look at this bucket and, a few details and I go into data, I can actually see that this bucket has a lot of, data, a lot of sensitive data findings. Things like, email addresses, credit card information, and so on. Or if I can go to this machine, I can actually get a lot more information on its activity. And that is also something that we're adding now with with defend. That is the activity heat maps based on the logs that we're ingesting. So I'm looking at this easy two instance, and I can see all of the source IPs that use that were used with its credentials, all of the source countries, events that were initiated by this machine, services that were used, and so on. And I mentioned behavioral analytics before. This is just a great way to actually see why we are marking something as unusual. Right? If we're seeing a specific IP address that wasn't used before, a specific country, a specific service like s 3 in this case, and so on. So again, just a great way for us to show you what's kinda happening behind the scenes and why something was marked and unusual. And then once we're done going over the entities and the communication and kind of a overview of what happened, we can always dive deeper into the details and see a full timeline of the incident. So here you can see 2 types of of events in this timeline. We have the ones with the red background. These are what we call triggering events. These are the actual events that triggered the detections, but we also have the ones with the white background, the extended timeline events, which are events that we're adding as we're, building this timeline by asking a bunch of queries, around those entities. So for example, here we focused on the machine and we wanted to know what happened before, what happened after. And the goal is to save you those back and forth trips to your SIM and just give you all of the data right here. This is what happened before the alerts were triggered. This is what happened after in between and so on. And what this timeline also reflects is anything that happened by your team, what we call the blue team timeline. So you can see things like severity changes, status changes, comments, and so on. And the goal is to use this timeline, you know, for the entire team to collaborate on instead of anyone everyone having their own kind of notepad or Excel that they have to keep sync. So that's the goal here. And then once we went over the investigation graph, the timeline, and we understand, you know, this is really bad. We need to do something about it. This is where we can move on, to the to the response tab as well. And in under response, we actually have 2 types of actions. So first of all, you can see the menu here to the left with all of the different entities and resources that are involved in this threat. And for each of them, we offer a bunch of actions that you can take directly from the platform. So we can, for example, if I'm looking at the machine, I can isolate traffic to the Internet. I can stop it. I can create a snapshot. And the way we're doing all that is by deploying a Lambda. When you when you enable this, response remediation feature, we'll deploy a Lambda in your environment, which you fully control, and it will pull a base image, which will contain all of these action all of these actions. Of course, it's an image that we intend and we keep updating. But the idea is that you fully control it and you can also extend it with your own actions. So we actually have in the product a full response actions catalog where you can see all of the built in actions and add your own very, very, easily. And then apart from these actions that are building that you can just basically run from from the platform, what we'll also do is we'll we'll feed all of the information of the threat to our AI engine, and we'll generate this playbook that you can use, that you can follow in order to respond to this threat. So here, for example, from looking at the AI generated, playbook, you can see how the first recommendation is to isolate the instance, and then to revoke the profile, to secure the bucket, and so on. And here, whenever we have an action that might fit the suggestion, we'll also show it here with the run button. Right? So it's kind of a shortcut to to actually going and performing each of those actions in the playbook. Now it's important to mention, these actions are not that the run actions are not it's not AI generated code. The only thing that is generated by AI here is the playbook and the steps themselves. So these actions are safe. They were tested by a human and and, you know, we we feel very safe to to, to recommend, to recommend you to to use them and to, to include them here. But the playbook it's the playbook itself is, AI generated. Perfect. Now before we wrap up there, I saw some questions about the sensor. So I do wanna touch, on that one more time. So the sensor, again, it's not a must for risk defend, but as you can see, it really enhances, our visibility and the things that we can, that we can show you here in the threats. For example, here we have I'm looking at the detection. We have actually, I think, yeah, 3 detections that were regenerated from the sensor that were grouped to detections that are based on the CloudTrail logs and the GuardRT signals. We can also see the full process here in the graph. And for each of those detections, if I click on it, I can also see a full process tree. Everything that happened, all of the execution data, the command lines, the user data. So it's a lot of information for you to have when you're investigating, an alert that that, is related to the workload. So definitely not a requirement, but definitely recommended to to deploy the sensor as well. Perfect. So thank you very much, for joining the webinar and for going through the this demo with me. And I'm still gonna answer questions in the time of the chat so so if you have them. Greg, to you. Thank you, Ophir. That was fantastic demo. Lots of questions came up. Again, we'll answer those as quickly as we can. Now we're gonna dive back in and, you know, talk to Nate from Matillion. And I'm really excited from, for this portion of the webinar. I think it's a great, great view to be able to talk to a customer and really get firsthand experience, from the benefits that they're seeing. So first of all, Nate, thank you for joining us. I sincerely appreciate it. Glad you're here today. So to kick things off, can you just let everybody know kind of what Matillion does? Yeah. Thanks for inviting me, Brooke. So I'm a cloud security engineer at Matillion. Work from all the way to management, I am, and looking after our cloud estate predominantly in AWS. Within, we have 2 main products that do some of the things that ETL products. So they extract data from a source and load it into a data warehouse like Snowflake, transform into a format that's useful for a business, and then that can be shipped off to a visibility or analytics tool. Regarding Wizz Defend, we've got the main platform we're concerned about for threat protection and responses, our SaaS platform, Data Productivity Cloud, where we handle the majority of the computes and that all runs in Kubernetes. So we're already a heavy user of the Wiss sensor. Very nice. No. I I appreciate the background there. I think it helps set the stage a little bit. So I guess taking a step back, Nate, what did what did your security stack look like before defend? Or even if you wanna step back further, what did it look like before Wiz in general? Yes. Sure. So before Wiz, we had a lot of tools spread across doing specific things. So we had a tool for content security. We had a tool that was gathering all our logs that we used for like a scene. We had some native AWS tools for inventory, and sort of security of our network and data events. Using Wiz, we look to consolidate a lot of that, and that's what, again, what we're doing with defend, mainly to reduce costs. So, initially, we were able to drop costs quite significantly. And with Wiz defend, our cloud service provider tooling that's doing the sort of data and network security is about the 3rd highest, item on our bill. So we also don't have we didn't have a lot of access to the raw logs, so network and data logs. We just got access to what the detections told us, which could be a bit limiting. And there was no more access to the threat section rules logic either. So we had to rely on the rules description to work out what the detection was telling us, which could be a bit of a guessing game path design. So a lot of look for consolidation and saving money, but also where we could gain features of, like, data retention, getting a lot more data retention from what we did previously. Their visibility with the UI, I think the UI is a lot better than we've seen with other tools too. That's great. Yeah. That's fantastic to hear. Certainly, kinda illustrates your journey and, not only what Wizdefend has added, but what Wizit in general has added. So I guess kind of dovetailing off of that, you know, what are the primary benefits that you have seen with WizDefend, or what has your team seen? Did you look at any other solutions? Like, what was your criteria for for defend in general? Mainly, it was to cover the issues I raised earlier regarding sort of, like, getting act getting more visibility of our logs and autonomy over our logs. We're consolidating all our logs into one platform, which means they behave really nicely with our existing inventory. So we can pivot off a detect pivot off a detection to what configurations, resource, or vulnerabilities it has. We're getting quicker detections as well. So we were noticing our CSP. It would see a thing, then it would poll for about an hour, and then it would tell us about it because it was trying to gather more information. Whereas with, there's still that polling of adding detections together, but you get told about the initial detection, which was quite important. Last set of, again, not only our logs. So we can act we can access and query them, and then build threat sections on top of those, and then they can be used to help with investigation. So even if it's not a a threat section that's originated from data or network logs, say, like management, API logs in CloudTrail, we can see, okay, what is this principal resource done to data or network stuff? We can do that in the past. And that's a bit of UI as well. So we've got the timeline, shows chronological view of what's happened. Main part I really like is showing the previous detections for this threat detection rule because it gives you a nice context of why it was closed up beforehand, why there wasn't a big no put in place, that sort of thing. And then the security graph, which sort of gives you a map rather than a chronological list. And you can use the nodes on a list to pivot to other resources. So you'd say, okay. Why is this resource done? Like I said earlier, the configuration vulnerabilities of those resources. And then lastly, the threats. So previously, Wiz would be very sort of like, one to one relationship between a detection and a rule. Whereas now they've been grouped up, so it reduces the noise you're getting. So you get one detection, you get one sort of notification for a threat, and the only time it will give you another detection is if that severity changes, if a new threat section was tagged onto it, which has a high severity. So you get the same visibility, but you're getting less noise, which is very helpful for people small teams that are on call, you know, getting wake woken up a lot at night. Kinda leads into my next question. So, you know, I'm curious, like, from your team's perspective. Is it a relatively flat team? Is there an escalation process? Like, can you can you walk through maybe a sample threat at Matillion and just kind of walk everybody through the workflow? Yeah. Sure. So we run a bug cloud program in our preproduction environment, and we've been using Wiz to try and attribute that activity to 1, is it a bug crowd research? But, 2, what are they doing? Because there's there can be a bit of time lag between research of finding a vulnerability and then telling us about it because they're trying to refine that report so you can get paid as much as possible. So what we do is we take the threat sections that trigger from that from that bugcrow researcher, bundle them into a runtime response policy, and then put that in a production environment. It gives us a really quick mitigating control to block the exploit until we get that report a couple days later from the bug card researcher so then we can go and fix the problem in our app. The investigation graph and timeline helps us do that more quickly. So we're doing that in full risk defend, but it could take a bit of time to work out is this bulk of our research and what actually have they done. And getting the visibility of if they've been able to access data or pivot to other resources of the network was a little difficult. Team wise, we're quite a flat team. So escalation wise, it goes me, manager, director. Once the director that we had, bit of a big, large issue. So luckily, what we're seeing with the WISD detections is they're very far left on the MITRE ATT and CK framework. So in the early in that detection process, which gives us a good idea that we're detecting things early, and we've got a good sort of controls to prevent anything from getting worse. That's great to hear. I I like that that, what you just threw out about detecting early and being pretty far left. I think that's a a very important thing that a lot of organizations ultimately wanna get to. I guess, for you in particular, Nate, like, is there anything that we haven't covered from, like, your day to day that you've seen drastic improvement from defend? Not right now. Yeah. Mainly because the preview was focused heavily on getting the threats working well and also those new data event sources. What we had a few weeks ago was a call with the product team regarding the road map, and there was a few things that looks really interesting. Sort of what we were trying to do in house already. Was it looking at, so first of all, Slack integration? So what we do right now is when we get a detection that occurs from, like, an AWS SSO role, we go to that person and say, okay. What are you doing? You got a guarantee for this? Just trying to get your context around it. There's literally integration to send the Slack message to that person directly and sort of sync Wizz and Slack together with that information, which is really nice. Also, we've been looking at, can we reduce false positives and help with investigations using AI? So we're getting prompts, on the next steps, see so reviewing historical data to see if this is a false positive and also generating false positive, generating ignoreals to get rid of false positives. And I like that Wiz is looking at that side of thing with AI rather than detections. We've seen other products that, where they're trying to use AI to be threat sections. It's very difficult to work out what is this AI model actually looking at because it doesn't really tell you. It's just sort of it thinks it's suspicious because of the baseline. It was against baseline. So last question, and I know from our previous conversations, like, you're you're an advocate for defend. You like defend. Your team likes defend. But as a security engineer, how did you go about making recommendations, like business case recommendations for, you know, possibly purchasing a tool like WizDefend? It may mostly came down to the cost. We have the majority of the functionality we needed was that we had threat detections of our network and data logs. So mostly it down to cost. So what we did was took what we're spending right now to do the security, and then we took write our same data volume. How how much is it gonna cost to collect it. And we looked at about 60% reduction in price, which is nice. You've also got pay with for Wizzdafen. So once you do that, you're looking at about similar cost, maybe a little bit of savings from our point of view. From that from there, I think it's quite easy to justify Wizz defend. We're already using Wizz advanced, so we would have a lot of data in there. We're already proficient with using it. So we're gaining more functionality with Wizz defend, but we're paying the same or less. If you do this process and you work out it's more, I think it's diff more difficult to justify with defend. You will sort of look at the features that it offers and if that's worth it to you, especially like reducing noise. If it isn't, I would recommend waiting about 3 months and then coming back to ask for another demo because, look, working on other previews, we've, seen features get released really quickly, like I said, with the road map. And those extra features might be worth it to sort of that extra money that you're looking at spending what you've got right now. No. That's great great insight, mate. Anything we missed here? Anything that you wanna add? I can't think of anything. I think we've covered anything. Yeah. Well, awesome. I mean, thanks again, Nate. We really appreciate you being here. Matillion's obviously a great partner. You're a great partner. So, yeah, thank you, Nate. And, I think with that, we're gonna go ahead and open things up for a live q and a. So I think, Ophir, if you can hop out here, see if we have any quest Hello. Hello. So thank you thank you for attending this this webinar. Do you hear me, Greg? I hear you. Yep. Cool. So we can kick off the q and a based on the all the good stuff that we shared. Yes. Yes. So it looks like there's still a question from Nessie on the difference between, threat detection rules. So, Nessie, maybe you can clarify. Are we talking about the threat detection issues tab or threat detection rules themselves? Yes. So threat detection issues. So there anybody that's a Wizz customer, I'm sure you're aware that there are some cloud detection and response capabilities actually in Wizz Cloud. So these are based largely just off of a subset of CloudTrail events. And so that tab was always there, for WizCloud specifically. Mhmm. And moving to WizDefend, everything becomes a threat. So you saw when Ophir was doing the demo, we have, like, the group threats. That's our new detection engine. Everything will live there. Eventually, the threat detection issues that you saw in the screen today will consolidate to that threats tab. Does that make sense, Nesli? Do you need any clarification? Okay. Let's see. We have a question from Adrian. Do you provide a way to review raw logs? Yes. We do. So you can search through the raw logs. You can search through runtime events, really to do, like, cloud threat hunting stuff. What retention I'm reading the question for you, Greg. That makes things easier. Question from Kurt. What retention levels for the CloudLock does we offer? So we offer a base retention. I believe it's 30 days, and then you have the off option to actually extend that, based on different license levels. Yep. Another one from, if I pronounce it correctly. Can we have custom data connectors for additional correlation? By creating data connectors yourself, no. Those will be controlled by Wiz, primarily for the fact that we wanna make sure that the detections that are written are a value to customers. So we'll control the data sources from that perspective. We will allow integration of kind of customer's threat feed. So bring your own threat feed. Cool. Do I see any other question? We have one from Darko. Currently, taking 4 and 6 snapshot is a feature included in Wizz advance. Will this feature now be now be exclusive for Wizz defense license or any other similar features will be moved? No. I don't I don't think so. I don't know of anything off the top of my head, Nico. Do you? Nope. Not on that part. For me, it's like stay where it is Yeah. Today. We always try to do that. Yep. I don't see any other question, but feel free to ask. Oh, I see question maybe in the chat. Where's the option to extend the retention? I think it's on the back end for now. I mean, it's not there yet. Right? Yeah. That's correct. Is it possible to ignore, approve a threats like with the vulnerability findings? I don't remember that. Full kind of full tuning capabilities. You can ignore threats. You can ignore detection rules. So very, very granular in terms of of what you can do there. Interesting question from Roberto regarding, ingestion of third party EDR solution, specifically CrowdStrike, what do we do there? The integration in this end. Yeah. Yeah. So for CrowdStrike and EDRs in general, we do have some limitations in terms of the kind of data that we can ingest. So, full raw telemetry from CrowdStrike is limited via their API, but we do ingest detections, and we enrich detections. We really try to treat them as like a a primary source, essentially. So when we get a runtime detection from CrowdStrike, we treat that very similar in terms of what we would get from our sensor. So we showed on the investigation graph. We correlate those runtime signals across cloud events. So as close as we can based on the telemetry that we can get from, 3rd party vendors. Do you also have integration with Microsoft TDR? So Microsoft Defender for endpoints. That's another question. That we will if we don't. Not that close to our integrations team, but, yeah, we will have support for it if we do not today. Yes. On top of my head, and I think of your mention, it's like Sentinel 1 and Crossright today. Right? As an EGR? Correct. A lot of question. Can we integrate with tools like New Relic to correlate APM logs? So, again, we we do have a road map of, what we're gonna correlate with, but New Relic, specifically, I haven't seen anything there. So that would be, in my opinion, more like a a SIM correlation. So what we're doing on the cloud side, essentially, is really Nico answered this question, but pulling off as many of your your cloud logs, cloud telemetry sources, really to, 1, offload your SIEM, and 2, kind of put together that full detection story. So, wherever you'd wanna lay in kind of New Relic risk, when I look at that question, I think it would make the most sense. Like, you take your detections, you take your context from Wiz. We offer full integrations with, you know, all the major SIMS or, platforms. You would pull that into your SIM and actually do the correlation with New Relic there. One more. That one, I don't know, to be honest. Do you take data from all the Azure Defender XDR data, specifically the risk user or risky SPN? I I don't have more insight on that, but maybe you know more, Greg. I do not. Maybe we can take that offline. Yeah. And, again Yeah. We have, a lot of information on the telemetry sources we do take in docs. So check that out, and we can also follow-up with that one. Yes. One more before, we we have to close the the webinar. Custom detection creation rules. What is the best practice? I mean, I would say it depends. I I agree. It depends. Yeah. It's it's very specific to your environment. Again, we create we allow, like, very granular creation of detection rules. But, yeah, that's a that's a tough question to answer. Yep. And one last, because we are on top of the hour. You have mentioned Lambda as a tool that will perform the action and response on AWS detection. What about Azure and, specifically, AKS? In fact, we will use the same several as function in Asia. Right? Like like we do in GCP and any other cloud that we are supporting. Yep. Yeah. The main goal here is to, I would say, provide you, like an images that you can reuse in your own environment, deploy it, connect it to Wiz, and Wiz will just send, like, the messages to the queue that will be, like, used by the function to execute the action. We are on top of the hour, so I don't know if we have the time to take one last question, but up to you, Greg. Yeah. We can why don't I take the the one about automated investigation? Yes. Well, that one, you know, it's it's, like, hugely powerful in my mind. And so when I think automated investigation, I think of the workflows that SecOps goes through today and kind of all the manual correlation activity that's required there. And so, essentially, when you look at doing an investigation in defend, what you're presented with is, 1, a fully correlated attack where, it's applicable. So, again, that that grouping that would be manually done today. 2, all the context that lives in Wiz. And so you're getting all that context around, the threat itself. Not something that you have to piece together again with, kind of manual queries and manual investigation. And then the 3rd part really is that extended timeline. And so, you know, we show you again what the attack looks like in terms of the detection events, but then a lot of our kind of brains behind that is looking at the associated events. Right? So you look at a principal that's involved with an attack, and you start interrogating and answering questions. Like, what was this principal doing before? What was this principal doing after? And so we have, you know, probably a 100 questions like that that we interrogate, and we don't just dump all of the, the the answers to that question on the timeline. Again, we go through and kind of our our bread and butter there is determining what is important to show. And so you still receive a timeline that is easily digestible. It's not muddled with, you know, hundreds of associated events. But it's hugely hugely powerful in terms of cutting down on that, kind of manual process and difficulty that, SecOps faces today. Thank you, Greg. I think that's the perfect timing to conclude that this webinar. So thank you again for your time, and, see you soon on the next one. Thanks, everyone.