Name: See and stop what matters at runtime with Wiz
Uploaded: 2025-09-04T16:22:37.253Z
Duration: 24 min 24 s
Description: See and stop what matters at runtime with Wiz

Transcript for "See and stop what matters at runtime with Wiz": Hello, everyone. Good evening, good morning, or good afternoon wherever you are tuning in from. Welcome to today's fifteen minute live runtime and defend demo with two of Wiz's VPs of product, Raaz and Arie. We are so excited to have you join us today, and we we appreciate you taking the time with your busy schedule to join us. So quickly, in ways that you can engage during tonight's event. If you have any questions, please feel free to type them into the q and a tab or throw them directly into the chat. We also have related resources on runtime and defend in the doc section for your for you to download at your own leisure. And with that, let's get started. So I'm excited to introduce you to one of our presenters today, Raaz, our VP of product strategy. So, Raaz, I will pass it on over to you. Okay. Let me go ahead and share. Okay. So first of all, thank you so much everybody for, taking the time today to learn more about Wiz. I'll start by saying hi. I'm Raaz. I'm VP of product strategy and CMO with Wiz. And we also have Arie. Arie, do you wanna say hi? Hey. Hey, everyone. Great to meet everyone. I'm Arie Zilberstein, VP of Cloud Text Response leads that we defend and our incident response initiatives. Perfect. And today is short, but our, our goal is to make sure that each of you kind of leaves this fifteen minute session with a clear understanding of, like, what is the approach to run same security, how it works, why, and also having, like, seen a demo. And with that, I'll start from, like, a quick overview, and then we'll jump into the live demo. So it I wanna start, first of all, from the beginning. Right? Like, it was our focus from day one has been that we really wanna help organizations prevent and and fix the most critical security risks to their environments. And that always starts from understanding, okay, first of all, to prioritize. I really need to understand the structure of the environment, the architecture. What is exposed? Okay. I have this, exposed service. Well, who owns it in terms of, like, the team? Should it be even exposed? Then I wanna understand, okay. Wait. It looks like it's exposed. It should be exposed, but it's vulnerable. And, also, if it's compromised, then this specifically can have an incredibly, terrible effect because this, exposed resource and vulnerable resource also has very high privileges. In fact, privileges to a database that has sensitive information in it. So the goal was always to help understand where to focus, meaning what's most likely, like, what's exposed, and also what would have, like, the worst impact if it was, breached. Right? Now the context of how the environment is set up is super, super important. But run them signals, we actually see them as a crucial part of that picture. It's almost in my mind, like, thinking which of those, like, attack vectors are hot. Right? Like, what's actively actually running? And so random information like which processes are being spawned, which libraries are actually loaded into memory, any new API endpoint that's exposed, network analysis. Those are all very important elements to how we think about risk. And the real power in Wiz and then Wiz approach to run time is the combination of both of those things together. So when we look at risks, but we layer in that additional information, like saying, okay. I can look at this back end service. I can look at this front end service, but they're actually in communication. So there is a path here from the outside. Right? And then I can understand, okay. And this back end service is truly running, loaded, like, running and loaded, a vulnerable library, and also that front end is vulnerable. And that combination helps you understand, hey. This is where I need to prioritize. This vulnerable expose front end talk to this effectively vulnerable back end that has access to sensitive information. So combining the two brings great impact. And that's how we really think of risk. Like, in some ways, we think of, okay, we wanna understand everything. We want to look at all the potential attack vectors. And to do that, we don't have to rely on something like an agent or a runtime understanding. Right? We want to understand all of our risks based on the architecture. Then we wanna zoom in. Like, we wanna say, okay, which of those are actively running? And on top of that, where do we actually see a threat? And then we can use our run time capabilities and our response capabilities to really take action. So it's all about, like, kind of zooming into those layers of visibility. And with that, I'll jump to the demo itself to show exactly how it looks like. So this is the issue I want to to show as an example. What this issue talks about is a publicly exposed container that's running a a a a vulnerable image, and those those vulnerabilities are actually validated in run time by the Wiz runtime sensor. And this specific container has an escalation path that's critical. Now we can look at the Wiz graph here to see all of those exact layers. So first of all, like I said, everything starts from understanding my external exposure. So Wiz maps the environment, and then we use our dynamic scanner and external scanner to actively try to access from the outside and see exactly what's exposed from the outside. So in this case, this container is exposed. We can see here that this cluster runs the Wiz runtime setup. Just a quick interruption. We don't see the we don't see the the demo. Oh, that's right. Thank you. I forgot. Classic. Sorry. I moved to another tab and did not, share. So this is the image I talked about. This is the issue I talked about of the publicly exposed container, and I'll jump again to the graph and walk through. So we can see here that the Wiz external scanner has validated that this container is exposed. It actively access from the outside to show you what's exposed. Now we can see that this cluster is running the Wiz runtime sensor, and we can see that this container is indeed vulnerable. We can see the connection to the image, and we can see here that Wiz is saying that this vulnerability has been validated in runtime. If you look at the vulnerability, I can see the exact details. So I can see, okay, which layer was this vulnerability introduced in, but I also see exactly that it's running, what's running it. Right? Like, what are the what are the, what are the active run time signals that this library is indeed vulnerable and executed? And what they see here also that's very important is the code to cloud pipeline. And this is part of the beauty of being able to use our understanding of, okay, where did this container come from? Where did this image come from? Mapping it all the way back to the original source code, So that now that we understand that this container is actively vulnerable, we understand it's exposed. If we wanted to suggest a remediation, I could just open up the r to the right developer. So closing that loop between, hey, what's actually executed in run time all the way back to the developer that introduced the image, is very, very powerful. But going back to our issue here, we see that this container is exposed. We see that it's vulnerable. We see that the vulnerability is validated in run time, and we also see here that this this is especially risky because it has an access key that gives access to those buckets that have sensitive information in them. It looks just exposed on the image hard coded. And we also see here the network layers. We see that we're saying that this communicates, like this deployment communicates with this bucket. This is based on the run time network analysis. And if we look at the bucket, we can see exactly, where did it come from. We can see the network graph and analysis showing the active connections from this cluster to the bucket, and we can also see in general activity. Like, it's a combination of understanding the run time, the network layer, but also the run time layer of the cloud itself, like any activities on this bucket. So the run time context here serves us in many ways, understanding that this actually talks to the bucket, understanding that this is actively vulnerable, and showing exactly what talks to what in our environment. Now the run time sensor also adds a lot of value on top of just another layer of analysis to our risks. It could actively block this block an attack, of course, but also it comes into play in different, in different places. So one thing you can do is also just use Wiz to query your red events, your runtime events, and do hunting and discovery based on it. And, also, you can, use we use our analysis of run time to really analyze every single API endpoint we see in network traffic, and then also analyze how is it protected, is it protected, any risks we see in it. So giving us a full understanding of what's exposed, how, and mapping any new API endpoints that comes up. Now we'll remember to go back to the correct tab. So I'm going back to my deck now. This all come into play really when we think of how Wiz approaches run time. So we look at the two kind of entry points. Right? We have the Wiz runtime sensor, an e b p an eBPF sensor truly born for cloud, meant to protect cloud workloads, and we also have all the signal coming from the cloud events and from data events as well. And that allows us to focus on those four use cases. First of all, the Wiz runtime sensor helps us make sure that we can support any infrastructure, including private cloud and on premises. And and the it also helps us to actively block and protect against threats, as well as using it for observability and for runtime posture. So all of those use cases are just combination of ways understanding the infrastructure and the core architecture and layering on top of that runtime data. With that, we'll move it over to Arie. Thank you, Raaz. And and I actually, that is a perfect segue into how all of these contacts that we talked about, you know, from runtime actually serves security operation detection response teams. Because what is really the gold standard that, security operation teams and this response team need to be able to detect response to cloud attacks? First of all, it's everything we talked about. It's about the run time, the cloud, and the SaaS signals that are coming in run time and real time. This is being used to actually run behavior analytics to identify anomalous activity happening within the environment. On top of that, we also layer the cloud to code context, which is actually the big advantage of why doing detection response within Wiz is because we do see it on wealth of context that is generated by the connectors and by everything that the Wiz graph has. And then lastly, which is really important because this is what actually allows us to identify real threats and a a malicious threat. That is a cloud threat intelligence that is based on Wiz research team, the threat hunting, and also incident response team that we're doing, like active investigation for threats that and all that feeds, the analysis, of the graph of the signals to identify a a one precise threat, which is the detection response side of the house of Wiz. Now let's see how we pivot from the issue that Charles just showed you of risk that was identified within the environment So if we don't fix that if we don't fix that risk in time, how we can actually also identify that the threat actually occurred. So while this risk is being presented with all the attack, path visualization, we see all the affected resources of a potential attack. We also see that for this specific bucket, not only an issue is identified, but also threats are identified, which means that there are active threats right now happening within the environment. That is the perfect segue into, the threat detection response list and the threats that allows the security operation team, the IR team, identify malicious and active, like, active threats within the environment. So if we are pivoting, like, on the specific bucket that was exposed, we actually can go into a thread that was just identified by Wiz, and that combines and correlating multiple signals with different layers on the cloud. I think that is actually the the one advantage and the and unique part of Twist Defense that we can layer all of the runtime and real time signals coming, directly into the Wiz security graph. The first thing is runtime sensor, which is the eBPF that we talked about. On top of that, we also have the control point layer that comes with CloudTrail. And lastly, we also have data events that allows us to get visibility into every object and activity happening within the cloud. Wiz Defend actually takes all of these signals, correlate, aggregates, and create one threat story that tells us the story of the attack. So what would the SOC team do to be able to identify the threat or actually investigate that? First of all, we have the investigation graph, which is the map to how we investigate that threat in real time. It doesn't show what could hypothetically happen to this threat and what is the risk. It actually shows what actually happened in the attack from compromising the e c two to eventually compromising the machine key and the role of that e c two to eventually using that role to exfiltrate to enumerate and then exfiltrate exfiltrate data from that bucket that we saw that could lead to an an exposure before in the risk, and that is the actual attack. We also see the full process tree execution based on the run time execution data that the runtime sensor is giving us, which is exactly what we see here in the yellow. A traditional EDR would actually show you all only the yellow part here, but what Wiz Defend, which is the cloud EDR, can show you is the combination or the correlation between the runtime layer and the runtime layer of the cloud in altogether in a really easy way to absorb and understand what the cloud threat actually means. Now what we're doing, how did we get to this threat? That is actually a combination of 10 atomic detection that we were able to correlate together, again, coming from the runtime signals to the, to the s three signals, to the control point signal as well as also correlating guard duty activity. And next, if we really want to get to the bottom line of what actually happened here or what is the root cause, what the SecOps teams or the In response team will do is actually present or construct a, like, a timeline of that activity from the beginning to the end. And what Wiz Defend and Ransom sensor allows us to do is is construct the timeline automatically with all of the malicious activity and then taking even a step further with generating more enriched activity based on all the process execution and all of the other activities that we can correlate automatically within the environment. Now the last part, which is quite cool, is also applying the AI capabilities into that, which is whenever a soft wants to investigate it and want to into that, which is whenever a SOC wants to investigate it and want to do that under ten seconds or even under thirty seconds, you'll be able to open the storyline that presents, like, a good summary and a very really, really fast way to absorb and to understand, what exactly happening here, and eventually resolve the issue resolve the threat in a very, very quick way. Now taking a step back into the Wiz Defender, really, if I had to, kind of show you one picture what it actually means with defend, it actually goes into the detection pipeline what we have. So everything is really based on the our ability to ingest and to generate accurate and really enriched run time signals, like sometimes millions of events. In most cases, we have billions of events coming into the detection pipeline Wiz. That actually translated into atomic detections that we identified based on thousands of TDRs, threat detection response rules that are out of the box within Wiz. And, eventually, that is with the behavioral analytics, with the ability to aggregate and correlate, turns into the threats and solve these high critical threats that are prioritized and and really calls to action for every security operation and threat detection response team. So, so back to Raaz, to summarize what it actually means. So what we see here is really, the power we see in connecting all of this together. Right? So going all the way from code to run time to understanding the active threats, it kind of helps inform both ends of of of the funnel. Meaning, my threats now have context. So when you say, okay. What's important? What's production? Who owns the service? Should it have been exposed in the first place? Like, what happened here? And so the cloud compass enabled teams to understand cloud threats, detect them in time, and block and stop them. But also the run time signal helps the other end of things. So it helps understand, okay. Looking at all my risks, which ones should I prioritize? And when I understand what they need to prioritize, mapping back to code is what enables security teams and soft teams to talk in the talk in the same language, almost like the dev team. So opening a PR to fix things, knowing who to contact when they need to understand if something should have happened or not. So going all the way from code to cloud to cloud to run time to threats and tying all of that together is powerful across both ends of the spectrum. Being efficient in my risk reduction, but also detecting and blocking the right attacks. And with that, again, I'll thank everybody for taking the time today to learn, and I know we have some time for, q and a. Yes. We do. Alright. Thank you so much, Raz and Arie, for a super quick walk through. We are now moving to the q and a portion. So if you do have questions, please click the q and a header in the top right module and enter your questions there, and let's get into it. So first question, Arie, this is for you. So does Wiz defend protect against malware threats to potentially replace EDR solutions in the cloud? Yeah. So absolutely, yes. And we do it in two ways. One way is on run time, meaning that we have a sensor and we can identify runtime execution like, in runtime, we can identify malicious execution of processes like malware on every instance where the runtime sensor is deployed. But, actually, and that goes to the foundations of ways of being agentless. We also have agentless malware and agentless EDR capabilities. So we actually scan every asset, whether it has a runtime sensor or if it doesn't have the runtime sensor. And we can identify whether the instance has a malware even without having the runtime capabilities on that. So we actually have malware detection capabilities that can replace an EDR and actually goes beyond an EDR, that runs on on on endpoints. Great. Alright. Raz, we have a runtime question. So how does runtime sensors support Windows? So the Wiz running sensor supports Windows. It's now, in in public preview, I'm pretty sure, and it will be, GA'd, later this year. But it supports Windows machines as well. Alright. Another another sensor question. What are the sensor live response capabilities? So the sensor, really identifies, like, malicious activities, IOCs, and it can take action. Like, it can terminate malicious processes. You can define also custom response policies. And with defend, it actually complements it and extends it with a lot of, like, kind of one click actions to contain cloud threats quickly, like isolating VMs, like revoking permissions. So the combination of both is extremely powerful and both have active protection and defense capabilities. Alright. Here's another sensor question. So we're on a lot of sensor questions. Do sensors and I APIs work together in the Wiz environment and is It's a good question. I sensors is in some ways, like, I I don't want it to be, confusing to anybody. It's a name for, like, an active component, like, if you will for an agent. But the eBPF sensor we've built, while it's a run time component, it's very easy to deploy it across clouds, across Kubernetes clusters. It was really born for cloud environment, so it's very lightweight. It has, minimal impact on on the running environment, and this can be easily adopted by, like, your DevOps teams and easily added to, to your environment. Awesome. There's another one. So this one was during the demo. Are those graphs relations auto auto generated by Wiz, or is it a manual effort to bring those relations? This is a perfect question. I I see Chris answered. But, really, a lot of the effort we we do internally is and a lot of, the value I think we bring is by actually doing this mapping deeply and automatically, meaning you connect the cloud environment, and we literally build a graph database that models the entire environment and helps understand its connections. Now this is so powerful, of course, for complicated use cases, but even to just understand basic risks in the cloud, you truly need the graph. Like, if we want to know if something is highly privileged even. Well, maybe there's, like, a an SCP or something blocking those permissions somewhere along the line of of of groups. So everything we do is based on deeply understanding the environment and the mapping we do into a graph database, and we, surface risks based on that understanding, and it happens automatically. And I will just add to that that it's it's true for both the Wiz security graph and everything that is, like, the attack path analysis as well as for the Wiz investigation graph for everything defend. Meaning that instead of the SOC team going manually to try to piece together what's happening within GuardDuty, within CloudTrail, within s three data events, all of the attack, path that actually happened is being correlated automatically layered onto the timeline and onto the graph. And on top of that, we also have the wheel graph that provides risk in the analysis and all the scanning that we have in. So all of that is being actually correlated automatically, which is really the beauty, that allows SOC teams to operate, like, a lot faster. Alright. I think we have time for one more question. Another runtime question. Can the runtime analysis be used to inform firewall policy rule set? So in general, the the sensor analyzes network and activity, and runtime analysis is, like, a key part of informing and refining your firewall policy rule sets. We also have some integrations to firewalls to make that more seamless. But, yes, like, basically, looking at what's going on in terms of the network traffic and understand what's vulnerable and what's valuable can help inform how you define your firewall policies. Alright. Okay. Sorry. One more just came through. Last one. How does Wiz help developer in the demo scenario see the exposure of the image he introduced before getting into production? Great question. A lot of the power of connecting all the way from code to run time means that we have gateways in every step, but catching something in production is actually what helps a lot of organizations over time shift to the left. So while the issue we looked at helps the issue we looked at specifically already shows you what happened in production. Right? But this is effectively connected every in every place in the process to the ID, to upon mergers in GitHub, as a CICD step, like blocking or failing deployment. We even have an admission controller that can actually, like, block risky deployment. And that gives you the power to say, okay. I see something that happened already. As a security team, let me investigate. I see the developer that owns it. We agree it's an issue. Okay. Now, next time, let's, like it's it's a shared interest. Right? We don't want to run after things and fix them. It's a shared interest between us and our dev team and our dev ops team to maybe introduce that policy in an earlier place and would support that as well, wherever you're comfortable. If it's surfacing it up in the ID, if it's blocking the deployment, if it's failing the merge, anything. Well, that is a great one to end on. Well, thank you both, Raaz and Arie, for your time today, and thank you to the audience. We truly appreciate your time in joining us today. And with that, we will wrap up today's live demo session. Thank you all for joining, and we will see you next month. Thanks, everyone. Bye.