Name: Stop Cloud Attacks in Their Tracks with Wiz Defend
Uploaded: 2025-08-13T16:51:31.947Z
Duration: 34 min 16 s
Description: Stop Cloud Attacks in Their Tracks with Wiz Defend

Transcript for "Stop Cloud Attacks in Their Tracks with Wiz Defend": So there you go. And we're live. Welcome to the WizDefend live demo demo webinar. We're gonna go through WizDefend, what it is, and give you, a little demonstration of the product in just fifteen minutes today. Now I can see people are still joining, so let's give a minute for that to start. In the meantime, we'd love to make this session as interactive as possible. So if you're just joining us, feel free to add into the chat what exactly your role is within your organization, whether that's reporting into the cloud security org, SecOps, more of a engineering platform engineering or DevOps type of function. It'll help me and Daniel, of course, tailor this demo to make it, more interactive and better suited for your purposes. Alright. Seems like we're two minutes in, so I'll just go ahead and get started. I'm gonna cover a brief overview of what Wiz is in two, three slides, then we'll hand it over to Daniel, for the live demo. Now, first of all, to cover what Wiz is, we are one platform for the modern cloud security operating model. So Wiz started out with a with a product we call Wiz Cloud today, which is fundamentally about cloud security postures, secure configuration, and proactively getting visibility across your cloud environment and burning down any critical risk, risks in the cloud to prevent any sort of exposure. So this is when you think of our agentless scanning, attack path prioritization, that's with cloud. Built for cloud security, rule management, and GRC teams. Next, we heard another voice. There are a lot of customers starting to use Wiz, not just for security teams, but for their developer teams as well. DevOps, an application and platform developed developers themselves. So then we developed with code, with the acquisition of a company called RAF, to be able to not just scan things in the CICD, but shift even earlier and help developers build securely by design by finding and fixing, code vulnerabilities, insecure configurations and base images and other related security issues in their developer environments while they're programming, while they're pushing things into build. Lastly, we have WizDefend, which we'll go over today. This is our offering for security operations teams, including incident responders, threat hunters, threat intelligence analysts, and, forensic analysts as well. It's about detecting and responding to cloud threats in real time. Because ideally with with with cloud, you get zero critical risk in the cloud, but you also may need to be, privy in case there is an active security event or something changes and there's a breach in some way or another. So that's WizDefend and what we'll go through today. They're offering to help you detect and respond to cloud attacks in real time. Now why do you need a solution like WizDefend? Well, fundamentally, the cloud changes everything in the the attack surface entirely for security operations. First of all, there's a new threat landscape, and so you have to think about getting visibility and being able to detect new types of attacks like container escape and highly automated identity attacks. And so SecOps are left with the question, am I collecting all the right logs and telemetry? And do I have visibility over all the right workloads and runtime signals to be able to detect something as it happens? Next is a problem with inadequate tooling. So we find that many of our customers, even from smaller to larger security organizations, are doing some sort of DIY approach for detection response to the cloud. They're either manually creating and maintaining and applying all their own custom, threat detection rules across multiple cloud environments, or maybe they're using a tool, developed for endpoints and trying to extend that to cloud. The finding that they're getting a number of noisy alerts and very limited coverage, and very limited states of incident readiness. And lastly, when you come to when you finish the detection and visibility problem and you go to investigation and response, investigation in the cloud can be quite complex. There's a lot of cross service investigation and manual correlation needed to understand all these related alerts and group them together to say, what exactly is the story of this incident? What exactly is happening as a as a connected threat? So those are the problems that we see that sec security operations face in the cloud. So what we need here, in order to effectively detect and respond to events in real time is a unified approach. One that's purpose built for the cloud and has all the right context so you can just investigate within a singular, high fidelity issue that's raised to your teams. And so, ideally, this approach would have both visibility over run time activity on workloads, but also, cloud telemetry, SaaS telemetry, and IDP telemetry and signals as well. It would combine, not just threat detection rules, but also a element of behavioral analytics or baselining with normal behavior in your cloud environment, and then be able to detect and alert you if there is a deviation, from normal behavior or suspicious activity in your cloud. Lastly, you should have complete visibility across the control plane. So any risk that, exist in your cloud environment, that could lead to a, actual breach or a blast radius of attack that could lead to sensitive data, credentials exposures, identity access, that sort of thing. And finally, taking an account cloud threat intelligence, understanding deeply what attack vectors and what threat actors are actively targeting, these sort of access points, and then raising to you just precise threat alerts, taking in all this deep context, to understand, holistically, what is your exposure in the cloud, what is happening and where, and what could actually lead to a breach. And so this was defend in one slide. What we're doing here is we're taking in runtime signals, combining that with cloud and Slack's telemetry, in the Wiz signals lake and also layering it with our code to cloud risk context and our latest up to date cloud threat intelligence from the Wiz Security Research team. So what you get out of this is very high fidelity precise detections, that are covering all layers of your cloud environment and different threat factors as they are announced, as well as, making investigation in response very, very simple for SecOps teams. Wiz is doing all the work by analyzing all the telemetry and signals and then automatically correlating related detections and events together to form a complete attack, incident timeline and give you all the context you need for immediate triage, threat hunting, or response in case you want to block something in run time or have a playbook in place, to be able to remediate the issue at multiple levels. So that was the brief overview. Now I would love to turn turn it over to my colleague, Daniel Lemons. They'll be running us through the demo. And feel free, please, to drop questions in the chat, as well throughout the demo or from these slides. Thanks, Lauren. Give me one second. Hopefully, you can see my screen and hopefully you can hear me. One second. Alright. So good afternoon, team. My name is Daniel. I'm with the principal's engineer here at Wiz. And today, I'm gonna quickly show you, WizDefend. So let's jump right in. So WizDefend, as Lauren said, it's an extension of, WizCode and WizCloud. So you got the full context, of Wiz, including, like, vulnerabilities, remediation, compliance, and now really focus on threat detection in the cloud. So if you're familiar with Wiz, this is the landing page. But now we really wanna focus, on threat detection and the SOC team. So we have this lens that helps us prioritize risk factors within Wiz, and then I'm gonna flip into threat detection and response. And this is gonna be everything that the SOC analysts, the SOC operations team, the tax engineers will like to see it. So we have our secure operations dashboard, and here we introduce, a new detection method. It's called threats, which I'll go in in in a second. But as Lawrence said, Wiz and Wiz Defend ingesting, a whole bunch of telemetry from cloud activity logs, DNS logs, and also the runtime sensor. And then we're correlating that into Wiz. So as you can see here, for example, if I just go into event type under our cloud events, you can see here that we're correlating, logs from, CloudTrail logs, from networking logs, including VPC flow logs, runtime events that's coming from our Wiz sensor as well, Kubernetes audit logs, DNS logs. And then we're correlating all that information with, which is can be really easy here to do some analysis and some try hunting as well with the cloud events page. But now we wanna focus into the actions. So you can see here, like, in my demo environment, I had 453,000,000 events. But from those, I have twin, 12,000 detections. Our detections are coming from our detection rules. Those are written by our, tread research team. And then you can see here that, we're pulling, based on those logs. Right? So the event origin is here. And then we're creating detection rules based on those specific logs. Right? So if I flip just in CloudTrail logs, you see here I have a very comprehensive set of, threat detection rules, that are written specific for that cloud ingestion logs. And, overall, we have over 3,000 rules, again, written by our threat research team. So we're always analyzing in the wild. We're always checking the latest, attract factors, you know, performed by bad actors, and then we correlate in then those into rules. So you can see pretty comprehensive, set of rules that goes extend from, the control plane, the data plane, and also from the workload, aspect as well. And then we're also matching those with the MITRE TAD framework as well. So if I wanna see, for example, any all the rules that are based on initial access, I'll have a collection here of all the rules that are matched for that specific MITRE ATT and CK for, cloud attacks. And then from detections let me put that back. So from detection, we have tracks. So tracks is a new, type of alert in doing Wiz, and then I go and click on one. Well, we call it correlating within 24, an attack scenario or attacking ping from a malicious actor. So let's say in the case of a of a malicious actor where they were able to perform, like, enumeration and then they performed some recon, And then they were able to access the host and then performing things on the host and then extending that from the host, to the to the control plane. We're able to analyze that within twenty four hours if that specific alert's coming from the same principle and then is attacking the same resources or a set of resources that we'd be able to correlate. And then from there, we create a threat. Right? So a threat in this case here, we have different principles. So this is like an, there's a service account. There's a virtual machine as well that was attacked and then also a service account. This specific thread here is also based on, on a real attack, a real blog post that we have. It's about the Selenium, attack, vector that malicious actors spinning up crypto linings on those specific containers. You can read more about it in our blog. And then you can see here, like, the vent origins as well that's coming from this specific, trap is coming from the, different, source logs. Right? So coming from the sensor where we're detecting based on the eBPF, malicious activity that's happened on the on the host, either that is a process level, networking level, also file as well. And then we're matching those with, the logs from the cloud as well. In this case, you have CloudTrail logs, data events, and then log to the logs as well to be able to correlate. And then the resource set up out of this attack, right, you can see there's a bucket, there's a container, part of this subscription, and there's also virtual machine. And then the MITRE framework here, we have you know, host of native attacks here including credential access, discovery, initial access. So we'll be able to match that with the specific track. Right? And then from here, usual, with, action as well, we're able to, create tickets. This is here. There's a ticket associated with Slack, but you'll also be able to send this to Jira, to ServiceNow, to SIM, and so forth. If we're going to the story line, this is really cool, where we make, life really easy for SOC analysts. Even if they're not, cloud experts or they're not container experts, we can come here and read more about what happened within this attack, right, and be able to, prevent this breach or take an action on it. Right? So in this case here, there's a container, part of this ECQ, And then, malicious act was able to initiate a Python process and then also was able to do a reverse shell that's coming from this IP here, which is malicious speak coming from Mexico. And then we're able to do unauthorized API calls, including, trying to access sensitive data here from this this bucket. So here we have the punctuation impact and then some of the top insights here that we also be able to call out, during the star line. So this is built using AI, and then it makes really easy to understand the attack and then start taking action as well. And then the detections here, as you can see. Right? So part of those threat detection rules that I mentioned before, we correlated here eight detections into one single threat. So this makes life really easy for the SOC analyst again. Right? Because they don't have to go to multiple tools, multiple screens. Right? They'd be able to have a a pretty good correlation in the sending of the attack. Just focus on the single track. Right? So I'm just gonna click on one here just so you can see, a little bit of more details on it. So in the case here, this is a detection from the sensor. Just gonna pick a phone one here. So this was a reverse shell that was got executed. You can see the program here. You can see what got executed as well. See that came from the sensor. And then as the sensors monitor, all the telemetry that's happening, inside of the pod, so we can see here about as part of the process tree. We can see here, the service account, the container that, was actually taking an action here. And then we can see here the malicious act was able to run a script. Also another script as well here. And then as part of that script, you created a reverse shell here. You can see, like, the socket. Right? So you can see full details here. We can also view here. This is really cool. You can view the program details here. So let's say someone, doesn't know what Python is. You can have more description here. This is also built on AI as well, and then you can also view the file reputation in case that file is malicious. And then we're going back into, the reverse shell here. I can also view with this, specific event under, runtime events. So this is useful as well for stock analysts, that are doing thread hunting. Right? Be able to see if this malicious actor, outside of this pipe in command that got executed, was able to escalate privileges, was that actually able to, run more commands and so forth. So we have this runtime events here that gives a really good comprehensive, data here for collecting telemetry inside of the pod. As you can see here, I can view and filter out the cross analyst. I can add, like, more filters here as well if I wanna do more breakdown on the, type of event, more expression. Right? So this is really helpful here to make sure that we can understand the whole picture of the the attack. So going back here, into the reverse shell, I just wanna make sure that I and then here, we have the command line that got executed. Right? So pretty much here, I'm getting a mirror from what the attackers actually performed on that part and then be able to have that visibility inside of this. Right? So full details here inside the pod of that detection. And then the investigation graph here will give you you know, this is a very familiar with, way of showing the attack, right, via the attack path. So we can see here, as described it on the line. There's a malicious, actor coming from this IP. He affected this e c two instance. I'm actually gonna zoom here. We can actually see how many API calls are actually, attempting here. So we can see the seven x. This is new as part of this investigation graph as well. And we can see here the list commands that are coming from this I'm role into this account and also the get object as well for that condition, storage. As everything in Wiz, well, we're calling in, the cloud findings as well. So in this case here, this bucket has data findings. Right? So they're able to have a complete picture normally from, like, a threat detection, run time execution. We also have the complete context of the cloud as well. So here in this case, we can see this compromised, sensitive data here as well. Right? And we can also see here as part of the other attack. Right? So there's a there's a container that got spun up. This is a salinity room, container. Alright. It had more detail. This looks quick. And they are, like, more detections in the seven days. So this is good as well for analysts to know if this specific container is is constantly getting attacked or what was the timeline that this attack has started as well. And then here, the correlation, now we can see, like, the image that's coming in that container. Right? And then also the repo associated. This is part of as well as Wiz, as Laura mentioned. Right? Everything in Wiz, it's a one single detection and one single trap, but we're correlating, detections that are coming from code, from cloud, and then from run time as well. And then you can see here the reverse shell that I showed before, right, coming from that malicious IP that spun up like the four four four. And then we have the timeline. So here we can really also have, like, the history of the attack, when it started, why would they assume role, some, some CLI query commands, to that specific, ECQ. And then, the process that got spun up inside of that specific node, and then the reverse shell to that node. And then the malicious actor is trying to access the IMDS, right, trying to perform more actions, including, like, reverse shells and then try to read sensitive data, from from from the security itself. And then he connected to a malicious IP via, the reverse shell. Right? So full details of the attack, I'm not gonna go into because it's quite a lot. And you can see the list rows here. You can see when it described the instance, database instance as well. And then this is where our notification was sent out. So this is will also be a part of, the the trap. Right? So when an alert gets sent to the SOC analyst, how they're responding, right, the timeline as well for responding. And then here, like, more information about the attack as well. So pretty comprehensive. You can see the timeline here. We can also focus only on only on the attack itself. Right? But if I wanna have a complete picture, I would just extend this as well. And we can also view the triggering events. The cool thing here, that I can also put a comment, right, on, like, what happened, and I can also initiate a response directly from Wiz. Right? So this is use Wiz normally has only read permissions to the environment, but we also have a separate infrastructure that will provide more permissions including the ability, for example, to isolate any situations. Right? Isolate that from the network or creating a snapshot or in the case here as well also block that bucket that got compromised. Right? So taking an action directly from Wiz, right, can save a lot of time, especially analysts or especially if you're on the attack. And then the analyst has to understand, better about the attack or even stop a breach, right, in this case. So you can also isolate here from from directly from this. So this is what's on a nutshell, the threats. If I go back into the dashboard here, we have other information as well, including new time to resolution of threat, sensitive coverage, and also the incident awareness. Just wanna mention just really quick. As part of Wiz, we also have another, really cool dashboard that's called, the incident awareness. So this helps, SOC teams or help, 12 defenders here in this case, to know if you prepare for a breach. Right? So in this case here, we've even I need to know readiness score for Mohammed collecting logs, to the cloud. Right? And then how those are displaying into Wiz as well. But this really help us understand, for example, am I collecting the correct logs? Am I logging the right logs? What am I missing in my environment that'll help us in the case I suffer a breach? Right? So we'll be able to see those here. Right? And then also be able to see, like, the compliance results for that, like, which log resource is missing the cloud trail. Right? So full details here for, teams to help as well to remediate this problem, make sure that we're collecting all the logs that are necessary. And then we're also matching the the log, configuration breakdown with the my attack framework as well. So it might prepare, for example, here on user execution. So you see you can see I have some grace here, which help us understand here. Okay. I'm not collecting follow-up logs. I'm not collecting net logs. Right? And that can impact in the case I need to do for an investigation as part of the minor attack, cloud breakdown. And then we have other resources here as well that help us identify, like, the log findings, the runtime protection, my subscriptions here, and then here, like, the sensor coverage as well. So and this is pretty much what we have for a ten minute demo. So thank you very much. Any other questions? I'm here to answer questions as well. I believe we had two questions come in. What is one was about the log type supported and do we support, any logs outside of audit logs or management logs? Yeah. The answer is yes. As we went through in the beginning slides, we have support across management or audit logs, network logs such as VPC flow, route 53 resolver query logs, data logs such as, like, s three data events are fairly common, identity logs such as enter ID or Okta, logs themselves, and then SAS logs, such as GitHub or Snowflake. So you can see, like, anomalous activity or access happening in those applications as well. Second question from Kapil, which is, is what query language or is there query language available, that I can use for threat hunting? Can we actually, like, demo this real quick, Daniel? I can show it as well, the cloud cloud events and run time events, whichever. And you can share it if you want. Yeah. One sec. I don't have my demo. But if you want, I can share this really quick. I have my screen. It's up to you. Yeah. Sorry. I'm it's offensive kicking me in. So can you just share the cloud events or one time events? Yeah. So we actually make it very simple to query. You don't need to use any sort of proprietary language. You just it's all natural language, and you can build simple and or functions or just type in exactly what you want and it'll help start building out a query. So I want to see events for a certain resource that's already available as a filter or a certain origin, that's already available as a filter. Or you wanna monitor, like, a certain container that's very important in your environments. All of those can be easily just add add built presets, within directly within the cloud events or the run time events tab. Yeah. You can also filter directly from from the event, and we also have this stream view table here. Folks are familiar, for example, with Splunk, we'll definitely with this type of view here. Let me just hide this. And then here, we can add, like, more, sources as long as that way. So results, error codes. Right? And then we just provide more information within this frame. So really easy as Lauren said. Really easy. You don't need a language. Right? You can group by as well. And we have different event sources and and features here as well. Yes. And then the run time events? Yeah. And then the run time events, I don't know if you wanna say something, Lori, but same same type of approach. Right? So you have each statements. You have type of different type of events. You have different operators as well. And then here, you can help us, for example, feel to, like, I wanna see everything that's coming from that specific virtual machine. Here, we're looking at all the telemetry that's coming from, from the sensor. Right? So we can group by as well, like, is it coming from a specific hash? Is it coming from a specific command? Is it does it has a DNS query as well? Let's try to filter that so there's no DNS query. But also really easy to filter, and we can also add, let's say, I wanna see everything that's coming from that specific resource and then the event type outgoing connections as well. And you can see here, just filter out. Right? And then here, you know, I only have for one hour, but let's say I wanna see if it's from, like, two weeks. I hope we have it. So we can also go back as as far as ninety days as well, and then you have more information here, like, to actually we can filter this out. We can group by destination, IPs, and so forth as well. Yes. More questions. Wow. Got busy right at the end. Perfect. I love it. So, IK or you said that, I saw GuardDuty flash by. What is your relationship or what is the relationship between WizDefend and GuardDuty? So AWS GuardDuty is like a built in native sort of service for threat detections on GuardDuty. And what we're doing is we also have threat detection rules and behavioral baseline in a number of ways that can, detect, suspicious events within your environment. We also have a connector. So if you want to use if you want to bring the detections you have already, that you're taking from GuardDuty into defend, we can help ingest the detections that GuardDuty has and then, you know, help out further with the investigation by correlating what is picked up in in GuardDuty with the other detections that we have within Wiz, and speeding up the investigation because you have those not as separate alerts, but together in a threat as a singular incident story. It's it's a bit of, you could use both, or you could use, with defend, in place of GuardDuty because we do have those detections, and we're also multi cloud. So any rules that you have, threat detection rules you have or custom rules you have within WizDefend will be applied across all your different cloud environments, and telemetry types versus just singular within AWS. Okay. Akshay had a question. I was going through the WizDefend source. Of course. Okay. So your customer is going through the documentation on WizDefend. I need a question on, is all responses happening on sensors installed in the endpoints? Okay. So we just launched actually so the the run time sensors specific for cloud workloads. We support today, Linux, containers and Kubernetes, as well as, Windows environments. And we just launched a sensor for on prem as well. We can add the launch blog for it here. But it's yes. It's all happening, within the sensor that is installed on those cloud cloud native workloads, and now in preview, on prem environments as well. Yeah. I'll add the blog link as well. Can the tool okay. And from Anurids, can the tool process native behavior based alerts and conclude if alert or multiple alerts is actionable or not. What what do you mean by actionable here? Like, if there is a remediation available or, I think I can just show just really quick what the person is answering, but one of the things that we can make action of as well for, for WizDEMAND and Wiz sensor as well. So we have our detection rules, and then I can just filter here by the one from, the Wiz sensor. Right? So a huge collection of rules, they are set to, detection only. Right? So we generate an alert, like, in this case here, generate a threat, generate a a detection, but it didn't block. But we can also create runtime response policies. And then instead of detection, we can actually block. So we can set a new response policy, to all projects or, like, specific project, and then I can select here, like, a specific track category. So let's say I wanna block everything that's malware and then crypto miners, and we can also view the rules here that apply. Right? And then the response mode here instead of simulate, which is default, we can also block it. Right? So every time, the sensor picks up a malware activity or a crypto mining activity as I showed here on the demo, we'll actually block that call. Right? And then we'll fill the process inside of the a specific prod. This applies for the Wiz sensor on Kubernetes, but also Linux and Windows as well. So Mhmm. For that answer. Yes. And then, Marie, for, talking about can we conclude, if something is actual or not, if it is a false positive or a true positive? Yes. Within the what we're correlating and analyzing on the detections, we also have a new ability that we're calling our agentic AI doc. So what that's doing is it's actually assessing, doing multiple queries and running some logic in the background that we expose to you and determining if this is a valid issue or not. So we've added that new, to a number of the threats. So you'll so you'll be able to see, if this was assessed by, like, our first level of SOC analyst, the agentic AI SOC, if you will, whether or not this is a true positive alert. Yeah. And just really to go ahead, Lauren. I was just gonna say just really quick, on that same topic. I know we I have one minute left. But we also as part of as you mentioned, Lauren, from detection, we also have this behavior baselines where we monitor the, the environment for thirty days. And then you can see here, like, as a detection logic, right, for I just picked this one here. We're detecting within 30 days a specific behavior, and if it deviates from this behavior, we're actually gonna do, like, a detection. That's why it's anomalous. So this is what you mentioned. It's a a behavior at baseline as well. So anything that runs outside of the norm within 30 days, right, that we consider as malicious, we're gonna look at that as well. And last question for today. Akshay wants to know the differences between, an issue, a threat, and detections in the context of WizDefend. So issues are fund those are from WizCloud. Those are fundamentally about cloud configuration, issues, and they're triggered by the cloud configuration rules. Threats are coming from data sources in the run time. Your telemetry, run time signals from the sensor wherever it is deployed, or like threat intelligence picking up of indicators of compromise in your environment. So that's a threat. And, the issue the the relationship between detections and threats is that threats is like a parent thing. Right? It's the whole story of an attacker and incident. So a threat may have correlated detections, AKA the individual alerts, the individual issues that have the individual detections that have triggered, by a rule, by anomalous behavior, suspicious activity, by deviation from the the behavioral baseline. All those are detections. And what WizDefend will do is automatically group those together and set out an an incident timeline and give you all that context in the investigation graph like Daniel showed, so that you won't have to do all this manual work trying to piece together what alerts are related to, one threat actor, one occurring incident in your environment. Okay. I think we've gone over a bit. Thank you guys so much for staying. If you click into the docs panel next to the q and a, we have a lot of take home activities. One pager, a free guide for threat cloud threat detection and digital, forensics and incident response. So feel free to, take a look at just the summary blog or the one pager. We can also answer additional questions, if you email those in. So thank you everyone so much for attending. This was a great, lovely interactive session. And thank you, Daniel, again for the great demo. Thank you.