Palo Alto Networks, Inc. (PANW) Earnings Call Transcript & Summary

Okay. Welcome, everyone to Fight Tech with Tech. I think we've got a a quorum here, 32 attendees. Good morning. So welcome. My name is Carlo Tarantini, I'm a Senior Product Marketing Manager here at Palo Alto Networks and today, I'm going to talk to you about XSIAM and our approach to redefining the SOC and implementing and basically [ evangelizing ] an autonomous SOC. So what we're going to talk about today is a short intro to XSIAM and actually the design principles of this solution, what led us to redesign the stock and rethink the sock. And then we're going to address a few success stories because since XSIAM's inception last November, we've been pretty successful. And we just had so much love and have hundreds of customers that kind of adopted XSIAM. We do have some success stories to share with you that can help you sort of make a decision and kind of understand again, the value of the solution and what you can get out of it, basically. And then eventually, let's see XSIAM in action. We're going to pray the demo gods and I'm going to show a short demo of the solution. across its key pillars. I think I'm going to show you something to do with solving the engineering challenges of the SOC, our dashboards as well as our incident management and incident investigation workflow. But let's get started with an intro to XSIAM. So look, security operations centers do thrive on data. And data has allowed SOCs to evolve and become very, very sophisticated. And from speaking to our customers in our cabs, we know that once a breach takes place, security analysts who are very, very skilled these days can figure out very quickly what happened, which systems got hit which data got stolen, which accounts got compromised. And they can quickly respond to incidents. And with all this data available to them and it makes them really skilled and empowers them. Well, the question is what's preventing SOC from becoming proactive in the first place? What's preventing SOC from preventing incidents and looking ahead and kind of getting ahead of attackers. And the answer is we thought that basically, there are 3 fundamental challenges that SOCs are facing today. Number one, there is just a lot of data and threats hired inside of the noise of data and that data keeps growing. I'll give you a few stats. 2019 survey reported that I think it's a [ ponie ] survey, but we've run a similar study. About 41% of CSC, anything between 10,000 and 11,000 alerts on average each day, and some claim to see more than 500,000, right? That's a huge number of alerts. So that's a huge number of data flowing into the SOC. How do you leverage it? How do you operationalize it? XSIAM deployment, only 10, 11 years ago, actually the inception of [ XSIAM ], [ playing ] with about 10, 20, maybe 40 terabytes of onboarded storage per month. And today, our customers use or generate that much data each and every day before the SOC goes to lunch. So that's about a 30x increase in the amount of data that SOC generates. But I don't know about you, I haven't seen many organizations hire 30x as many analysts in the last 10 years. And yet, the situation is pretty dire. And we all know the terrible stats. Average dwell time of a threat is still 200 days, and SOC are struggling to leverage all this data. So problem number 1 is there is a lot of data. Issue number 2 is it's hard to make sense of all this data. The average SOC utilizes dozens of solutions actually according to what's next in Cyber survey. It's about [ 32 million ] and it's a bit complicated these days to connect the dots and kind of understand that something happening on your network, something happening in the cloud, something happening on an employee's laptop and why they're working from a Starbucks might be all connected to the same reach and the same incident. And finally, most security operation centers rely on human analysts to figure all this out. a 10,000-employee organization, again, according to a [ panama ] study, I believe, will have on your -- there are 300 IT staff and 9 of these are security staff. So we're talking about 3% of IT staff head count for security. And in the majority of cases, for companies between 10,000 and 100,000 employees, the ratio falls always between that 2% and 5% so it's always that kind of ratio. So imagine that sort of inverted pyramid of loads of alerts, loads of data handled by a handful of security specialists or heroes basically. And there's not a way sort of upon the shoulders of the specialists. And people in the SOC, we believe, and hardly able to figure this all out and quickly enough and respond threats quickly enough and to shut things down. We've passed a bit of a breaking point. So if you think about it though, from a security perspective, from an industry perspective, most of the security estate has been redesigned, right? This is a bit of good news if you think about it. So network security has moved from Perimeter to Zero Trust and SASE. The infrastructure, infrastructure security has moved from the data center to the cloud in part because the companies are transitioning, they are transforming digitally. The endpoint or endpoint security has evolved from antivirus to next-gen antivirus, EDR, and then XTR, and Palo Alto played a role in this evolution. But what about the [ seem ], right? [ SEAM ] evolved incrementally in the last decade with ad hoc data engineering solutions almost like patching or sort of plucking holes. We've had content packs, integration packs, all kinds of disparate solutions, but we still are facing some fundamental challenges. Why? Because if you think about it, some leading SEAM solutions have been launched or well launched in 2007 and that's when the iPhone was created, that's when Facebook was created. It's time for a rethink of security operations and of the fact that it revolves around the SEAM. So that's why Palo Alto Networks, we thought we'd redesign the SOC completely. And what we decided to do is to build and enable a fully automated SOC via a new SOC platform, and this is an autonomous platform that we called XSIAM, Extended Security Intelligence and Automation Management, that's a mouth full. So what does XSIAM do? What is the design principle? The concept behind XSIAM?. So basically, the idea behind XSIAM is to stitch together all the data that we've got in the SOC, all the alerts, collect expansive amounts of data, collect data at scale and then once you define redesigned completely a back end and created story or stories out of that data, you use it to power use cases and kind of -- and functions within the SOC across the 3 categories of detection, investigation and response. What I'm talking about is leveraging AI from the outset and if you think about it, most industry solutions that do leverage AI, maybe collecting data from the network, they do provide value, but it's mostly in the detection space, right? Think about anomaly detection applied to data from a [ taper ] -- solutions that are able to -- the cluster machines to define peer groups. Fine, great and generate loads of alerts, but that's great for detection, what about investigation and response? Now one of our tenants in the Palo Alto mission was to extend AI and ML so investigation response and to the whole sort of range of use cases and across the whole service catalog of the SOC. And the outcome -- also one of the outcomes we're looking for is to implement automation. Now SOCs are analysts first or legacy SOCs are basically analysts first. What I mean is they thrive on or rely on data in the form of alerts. Now I learned [indiscernible] texts that are human readable, issued or sort of highlighted or displayed in a scene. And from these alerts, traditionally SOC do build their own automation, their own analytics. But everything relies on partial data in the form of alerts and relies on humans to do investigations. Now what we want to do is flip this on its head, create a complete redesigned data back end, collect loads of data, stitch it together. Now you can run automation on top of that data and you can run real AI and machine learning and the analyst sits on top of this pyramid, just supervising the unusual, the complex instances, those high severity alerts that require human intervention, that require human intelligence. So the outcome that we're looking here by reversing sort of the concept of a SOC really and kind of designing machine-led, machine first human empowered SOC isn't to replace humans completely, quite the opposite. We want to use automation and AI to empower humans. Machine learning and are still a critical part. Automation is still at fundamental to SIM, but the role is to empower professionals to do the things they were hired to do, to do the things they might enjoy and likes of threat hunts delving into data, doing research all sort of tasks that require human intuition in human intelligence. So that's what XSIAM is designed to do, empowering humans. And there are 3 concepts to how we do this. The first is around data that's spread around in multiple systems within a SOC. Now with XSIAM, that's exactly -- we started with an assumption that we would have to collect expansive amounts of data. So we put enormous amounts of data from many sources from endpoints, from the network, from identity systems, from the cloud, from applications. And now that we have this coherent large basis of machine readable data, we stitch it together, we create associations with it and write stories that can be fed to our analytics engine. So when our machine learning and AI models are processing it, they're not processing it independently sort of in a disconnected fashion, but they're processing it with an understanding of how different data elements, different data, different bits of datum related to each other. Once we have that, we can rely more on automation instead of humans. And that's why we call the system automation first. And there are 2 parts of automation that when we think about how we conceptualize XSIAM. So when we think of automation, generally, we think about human workflow, right? We think about [ SOAR ]. But there's also and especially in XSIAM, what we call native automation. And it's the most valuable sort of automation, that's the one you normally don't think about. It's how we automate the ingestion of data and how we normalize it. And you will see elements of native automation in the demo. And then the mapping into a bigger data model that I'm going to show you in the demo hopefully, to then putting analytics against that. Doing baselining, and eventually finding anomalous patterns. And that's the native automation that's built into XSIAM. Now in addition to this native automation, we have that workflow automation. We have a [ tall ] element. And this is when automation takes other tasks that we associate generally to being human-driven. Third, if we asked 10 SOC analysts, at least 9 out of 10 will describe their job as responding to stuff. Okay, that has to happen. But can we do a good enough job with the automation and the analytics inside the SOC to free the SOC up to be more proactive and do more of the threat hunting, do more of the research. Now to start looking at the attack surface proactively and patch things before an attack realizes that they have an opportunity to take advantage of things, we need to redesign the SOC. And we work to -- so that the proactive side of things outweighs the reactive side, and that's one of [ high in ] XSIAM. And in a way, we wanted to push the SOC to start having a risk prevention capability or towards prevention capabilities, not just letting it dwell on response capabilities. So given these principles, what is XSIAM? Now XSIAM is a single cloud-based platform, it's not implemented on prem. And it unifies being a single platform, all the best in class SOC solutions that you see in this slide. SEAM endpoint protection, user behavior analytics, threat intelligence platform, endpoint detection and response. All these things than most SOCs sort of iron separate products, they're unified into XSIAM. And in addition to having these solutions together, we don't just provide sort of a single pane of glass. We augment these solutions. We provide outcomes that basically go beyond sort of the sum of SOAR EDR, XDR and attack surface management. As you will see, as shown in the demo, we have recommendations. Our automation and sometimes our AI can provide you with suggestions as to actions to follow or enable suggestions as to enable automation to run playbooks that can augment your outcomes. You'll see that in the demo later. XSIAM is also a single user experience for all core workflows in the SOC, and it's not just a bunch of unrelated products from different tabs. And that's really important because in this case, you have one single interface, an analyst doesn't have to swell around and look at different workflows and different things to figure things out. Some time ago [ Forester ] put out a report on what they call analyst experience, and they said that the #1 killer of security analyst effectiveness is the loss of flow and what they call context switching. Having to switch from one console to the other being constantly distracted. XSIAM as a single data back end behind the tool, which enables advanced AI and ML and it allows our customers to basically consolidate the spending and the complexity of multiple products into one, single, simple and cost-effective platform, so everything is included in XSIAM. Now before I switch the slide in the demo and the case studies, I want to highlight how XSIAM solves some of the engineering challenges in the SOC. And I want to address that significant issue that affected the engineering side of the SOC for a long time and it involves the astronomical efforts required to build, integrate and maintain the scene. Why does it take such a long time to drive value for most SEAMS often several months? And even before we can demonstrate proof of concept, the process of replacing a [ SEAM ] can take up to 1.5 years sometimes. And what's about onboarding each data source. To truly benefit from the scene, we need to integrate, if you think about it, a number of components like endpoints, firewalls, clouds and identity and access management solutions to name a few. And think about the process involved in data onboarding, normalization, building integrations and the subsequent development of correlation rules, alerts, dashboards. And then automation, if you have some spare time or time to spare. So you can imagine the immense workload that this creates for at least one person on the SOC team. It's not just about building a SOC, know that maintaining these integrating tools within the scene presents an ongoing challenge. If you think about it, versions can change, data formats may change, integrations can break or new features may be introduced. So how do you ensure that integrated tools in the context of a SOC remain effective and useful? Well, when we examine existing architectures, we found that the integrations within the SEAM are fragile and prone to disruption. And realizing the need for change, we set out to reimagine the architecture. We do inspiration, if I'm honest, from the data flow perspective of Cortex XDR. And we took XDR, we kind of took to inspiration from its [indiscernible] infrastructure and merged XDR with our marketplace. And we found out when we came up with a new integration concept without showing the demo to basically bring to bear XSIAM's data onboarding tools. So what I'm trying to say is, and my key point is by addressing the time-consuming nature of seen deployment and then onboarding maintenance we are aiming to streamline operations, reduce overhead and maximize efficiency. And these are all sort of things that you can see into XSIAM in the context of the marketplace. And what we do is, it sounds trivial, as you see it, it's very simple to use, but ultimately, really, we're aiming to revolutionize the engineering landscape of the SOC. And you'll see how how simple is that, it is in reality, but it took us a lot of work to figure this out. Now we at Palo Alto run XSIAM in our own SOC, and we run all the Cortex solutions. And the results for us have been outstanding. Our SOC handles about 1 trillion events a month which boils down to 36 billion events per day. And our system is able to buy those events down, handle them and bring them down basically a single-digit number of incidents that have to be manually triaged and handled by our SOC team. So we go from 36 billion [ incidents ] to about a few hundred incidents, 133 currently. So we keep these numbers up to date, about 8 manual incidents that have to be handled daily and 0 major incidents so far. And the results have been outstanding, right? 10 seconds mean time to detect and 1 minute mean time to respond. Now this is the beauty of the scripted statistics. If you think about it, our analysts are not sort of twiddling their thumbs all day, you'll have a distribution that's skewed towards the sort of incidents are taken care of by automation in seconds, and you'll still have the odd sort of instance at 20 minutes, 30 minutes, 1.5 hours of threat hunt. But still, we sort of witnessed the beauty of statistics and these stats are real. So we achieved a 1-minute response time. And we couldn't have done this with the automation that comes from our systems being built on Cortex. And one year after launch, we have hundreds of happy XSIAM customers. And I'd like to share now for about 5, 10 minutes, a few success stories with you. The first one is Imagination Technologies. Now this is a publicly referenceable U.K. customer, a pretty important customer to us. It was a design -- they were a design partner to us in building XSIAM, they're based out of the U.K.. They have a really small security team, although they have always been quite forward-looking and innovative. Imagination is a market-leading player in automotive technology, and they do lead in a safe human machine interface for automotive with the GPU, their AI and their connectivity solutions. Now what was the situation? Point security platforms made visibility very difficult for Imagination and their security team had to deal with manual and reactive interventions. And those human interventions, lots of them led to long investigation times and crushed efficiency in their SOC. When they first started engaging with us about XSIAM, there was also a sizable challenge going on at Imagination with false positives and having really an old style team that really made it difficult for them to connect the dots on any kind of attack movements across their infrastructure. And what were they looking for? Well, first and foremost, there were -- in terms of the outcomes of the SOC, they were looking to protect their IP, their precious IP and also protect their people and they were open to using mature intelligent and ML-powered endpoint protection. And because the team is really small, they wanted to automate repetitive data analysis task to improve the team's productivity. And the goal really was to grow as analysts and to add more time from value-add security operations tasks like research. And for the same reason, they also wanted -- one of the wish was to decrease engineering overheads and look after the data. Basically, the goal was to unite endpoint, network, cloud and also identity data to simplify and accelerate onboarding of new data sources. They have the engineering challenge I talked to you about a few minutes ago. And you can watch the video case study on our website. Now they did adopt XSIAM. They helped us sort of evolve XSIAM. And with XSIAM now at Imagination, both the IT and security teams are using the data, are using the interface, are using the dashboard and this is making their lives easier. They're making more efficient use of their time and again, they're getting to answers far more quickly and reliably than they ever have before with the point solutions that they used to have. With the legacy SEAM, it was really hard to ingest the data. They told us it would have taken time [Audio Gap] to again prioritize your work and carry out new investigations in the incident dashboard. So you have an instant name, a severity and criticality that you can change. I'll get back to this in a second. What I wanted to show you for starters is basically addressing the engineering challenge. And I'll start from the marketplace before getting back to [ cents ]. So in the marketplaces is where we collect ROI integrations in terms of automation and data onboarding. And the -- when I first started exploring the product, basically trying to address that engineering problem, I'll try to add the data source. I purchased XSIAM. I acquired it, I'm starting to admit later sources. And we have a new data source page where you can actually start onboarding and selecting sources. This is where you have all your integrations. There's dozens here on my demo tenants. And I'm going to start by showing you the CyberArk 1 because it's a comprehensive one. It has all the different components you need and then I need to explain to you the benefits of XSIAM. Now in the CyberArk pack, and I'm sort of trying -- I'll try and add a data source. You'll find all the elements of an integration. And you'll find things that you'll get out of the box in XSIAM. So in the CyberArk pack you have several components. You have integration, you have correlations, you have dashboards, you have a playbook, you have data models and you have passing. XSIAM is in fact not just about plugging in your data source and collecting data, right? It's about delivering value. So the many tools that require analysts as such, contextualize, determine if it's something is of course false positive or not right? Out of the box, you will get a few functionalities that allow you to kind of streamline your operations and kind of cut down on these tasks straight away. So if I'm trying to onboard CyberArk identity collector, what I'm doing is as usual, I'm giving a name to this integration, and I'm kind of pointing it to my server. Now what I also have in this integrator is a bunch of things that do add value straight away. So one is data normalization. So every same product must have passing rules to understand incoming data, right? For example, you have fields like Source IP, [ SRC-IP or dot-IP ], all those different sort of pieces of data might all point to the same thing and might all carry the same information. Now with XSIAM, we're going beyond that because we're creating a single data model for all the data. And that data model is called XDM. So this means that instead of creating rules for each product's individual logs, we map those logs into one [ courier ] and unified data model, and that's our XDM model. So this unified data model is really important for analytics in XSIAM, and that's why we use it. If you've ever done any machine learning whatsoever, you'll know that, first and foremost, you'll have to basically organize your data sort of clean it up, and make sure your ML algorithms can create their own features and run their supervised learning and unsupervised learning, but that data engineering step is really crucial. And in XSIAM, it comes out out of the box so normalization is done out of the box with these integrations. So again, what -- having the data is not sufficient. So once you have it, once you onboarded it, you have to make sure that you generate alerts. And in these integration packs, we basically create correlation rules -- we give correlation rules that allow the system to generate alerts from the start. So you get value as soon as you create an integration. Now this is a bit of an abstract correlation rule, but you can always modify your correlation rules, if you like. So basically, this generates sell log-ins every -- or log-in -- alerts every -- log-in attempts. For instance, you could expand the correlation rule to include multiple data sources, not just CyberArk to generate those alerts. So again, you get your integration pack, you have normalization out of the box and you have correlations and now you're generating alerts. But as you start receiving alerts, as you start receiving data, normally, as a SOC, you'll start having a whole bunch of money processes or design a whole bunch of money processes around it or every time new data comes in. And that's why we're also bringing in automation packs and automations for each data integration park. So we're also bringing in playbooks you do add value for you rather than that. So you don't have to spend analyst time triaging alerts in this particular case for CyberArk in this particular case for brute force, an investigation. And playbooks.com with integration packs in XSIAM have, for those who are familiar with [ Exor ], a very familiar format. They're workflows, and in this particular case, I'm showing you the brute force investigation one, but generally, we'll design these playbooks around the most sort of useful and high-impact use cases and for most of our integrations. So you have the data, you have correlations, you're generating a lot and you have automation. What you might do at this point is to basically you'll need insights, you need reporting, you need dashboards, and they do come with the integration as well. So they eliminate the need to create your own custom queries, to create your own custom dashboards, all these dashboards that come into the integration pack within integration pack. So it's just simply plug and play. And that's we -- and how we envision going back to the engineering challenge I described at the beginning of my presentation that data onboarding should be a click-through process and not a month-long project passing rules and creating correlation rules to get the value out of your SEAM product. So I've created my -- onboarded my data, I've got my integrations, I'm running XSIAM, I want to get value out of it. One of the things I might do is investigating alerts. Now I'm going to show you a workflow. And basically, the question I'm trying to answer is, once you ingested the data, what do the outcomes look like. So let's begin what understanding what happens when an incident occur. We have this concept, as I mentioned, stitching and the incident engine, and in XSIAM, incidents are like puzzles and the different pieces of the puzzles are alerts. These alerts can come from different sources. But XSIAM puts them together automatically when they are related. So that way, you don't have to wonder where if an alert is connected to another. The system puts them together for you, stitching together the data in the first place. For example, if you have a malware case over 50 machines or 50 different computers, all that information will be neatly organized into one alert. And when we look at the workflow for an [indiscernible], we see the whole picture, not just bits and pieces this way. Now with each incident inside of XSIAM, which incidentally, in terms of the interface is very similar to XDR, we can have a couple of different investigation workflows. One obvious one being might mapping. Let me take a better incident than this. So in -- we're familiar with a [ micro ] framework, with a [ micro ] matrix. It shows different techniques, different incidents, they range from, in this case, from [ recognizance ] to [ ex-filtration ] or active scanning. And from this year, you can get a very quick high level on the understanding of what the incident is about. And what's going on. And I also suggest adding insights, which had extra context and microanalysis and insights are low in information on alerts that weren't enough to generate an alert in the first place. So I can see that from this particular incident involving [indiscernible] activity, which is high severity. Basically, there was some WMI involved as well as log on and auto start as well. So it helps me get a full picture in terms of what happened with execution, persistence and defense evasion. So micro analysis, when you're running a manual investigation is really important. But automation, this element of the UI is where XSIAM really shines because with got automation embedded in the incident itself. So unlike having separate systems for triaging and automation, we've got everything in one place, they work seamlessly. So that unlocks loads of capabilities. And in automation, you have several types of insights and several outcomes. For instance, you can have playbooks and playbooks are sort of workflows or a series of tasks. And some of these playbooks that have been run as part of the [indiscernible] who might require human intervention. So they might require intervention from an analyst. In this case, for instance, I've got XSIAM running a playbook in the context of this incident asking me if I want to proceed. So in the case of the machines scanning a network that has been found in this instance, it has isolated the endpoint already. It's asking me, do you want to keep the machine isolated or not? That's 1 type of playbook you can find in the context of incident. But my favorite part of the automation element inside of the incident is playbook recommendations. Now these are instances where XSIAM miss telling you, hey, there are playbooks that could make your life easier here. So you can either do this investigation manually or the investigation steps manually or I can run these steps for you. And to be honest with you, most or some of the playbook recommendations that are triggered by automation or sometimes by AI, do add value to the investigation phase. And in particular, you'll find in some instances that XSIAM is trying to sort of designate them over in a sandbox. So in this case, the system is trying to handle a wildfire alert, performing enrichment on different entities and trying to establish a verdict to make your life easier to kind of enrich the information in the incident. And then you have playbooks complete. You can see playbooks that have been run and completed in new system that I was trying to handle the incident and eventually, you might find to get -- you are getting to a point where you define your use cases in a way that automation is handling most of the incidents and most of the tasks for you and most playbooks complete kind of close the incident automatically. So this is the instant management section and the automation section within the context of handling incident in XSIAM. I just wanted to show you what a playbook looks like, especially for those who are familiar with XSOAR. So I'm going to pick one that's being completed and an instance where XSIAM basically blocked a transfer, a large amount of data over FTP. Now what I really like about the XSIAM in general and also the integration between automation, incidents and analytics is that basically, we're not making lighting and searching easier, we are not just doing that. We have profiling and analytics happening in the back end, and that's fully integrated with automation. So in this case, the system is trying to sort of block a large amount of data sent over to FTP and one of the steps of the playbook, once it's checked the threat intel and indicators of compromise associated with the destination and reach that information with IP info. Well, the system is asking the machine learning is this a prevalent address? Is this somewhere we generally send data to. And that's -- this is this particular step of the playbook: Get an XSIAM,, global IDEX profile on the IT. So what happens behind the scenes is for each security relevant elements inside the system for each domain, for each IP, for each user account, basically, we create profiles stitching together data from different sources, and then we assign roles. For instance, you have a different -- a specific domain. We create a profile of that domain with a few statistics, and then we can decide to assign a role to it and decide that, that particular domain is a domain controller. So once we created a role, basically, we can interrogate the AI and ask in this case, in this particular -- is this IP, according to their profile and their behavior is prevalent or not. Do we normally send data to this IP? And the answer is no. So you can see how automation, analytics, alerting they're all integrating in the system. And basically, it might have generally a small set of playbooks that you might be using your SOC, maybe 3, 4, 5, 10. But once you've exhausted those playbooks, you might not know what to do next, might not figure out what to do next. Well, in this case, you have playbook recommendations and integrated automation that basically are a force multiplier for you and kind of push your adoption of automation to the next level. And the other significant aspect to try to explain to you and touch on is the integration between automation and analytics and how within the context of a playbook, you actually can interrogate and use the outputs of analytics to enhance your investigation. You need to sum up within the context of an incident, you can always run a manual investigation if you want. So if you're familiar with XDR, if you decide that you're comfortable investigating manually, you can still look at the key assets and artifacts for that particular let. WildFire is our sandboxing through solution. So for all our suspicious IPs that we capture, run into our sandbox. You can get your verdict for Wildfire, it will provide you with human [ rebuild ] information, tell you what the malware is about so you can get the full picture. You will have Unit 42 tags associated to these malicious entities and to these sort of executables. So you can associate them to a particular attack or attacker, or threat actor. And if you want to investigate manually just as you would do in XDR, you can switch to alerts and insights and kind of look at the full list of alerts for this particular incident. And it's easy to show you how to build the storyline of an instant from here because you just have to, again, get to alerts and insights and kind of really read what happened chronologically. So in this case, right? a binary file was created to [ disk ] with a double extension, got suspicious generally. Then it was impacted. We saw some signs of malware infection, and then really, really high impacts of actions like [ disable windows firewall ] and some defensive [ aging ]. So if you want, you can still run your investigations manually. In the incident war room in a similar fashion to XSOAR, where you have communication tools with your team. So that's where you have basically a chart. You can use the bots to actually run all the functions that you'd have in your store, in particular, in XSOAR. And within the incident war room, you'll be able to -- again, going back to the collaboration element, communicate to your team, lead nodes and basically add a discussion in kind of land from your threat hunt basically by sort of exchanging information and kind of taking notes. And finally, just in the same fashion of as our XDR, you have your causality chain inside the incidents and inside of XSIAM. So in the execution element, basically this menu here, for each group of alerts intelligently sort of defined, right? So the system kind of collects series of alerts and builds causality , which represents an attacker action on the system, basically, you'll have a graphical representation of the attack flow. So I'm now looking at what happened and the set of actions spawned by a process, which we call Causality group Honor Honor in -- or on a machine, on a specific machine because causality chains are generally focused on the machine and some of the sequence of events that led to compromise. Each of these boxes is kind of -- is an executable so it's an act in the causality chain and in the causality chain trying to reconstruct the flow of events, I can see that basically, I went from Chrome probably downloaded an unsigned an archive of sorts. And from this process actually can observe that someone extracted a malicious file, which then carried out a series of attacker actions. And if I want to do my threat hunt, I always have my basic indicators in this blue strip, especially the [ Shaw and then the Hash ] that I can use for IOC enrichment as well as the details of the file that I can locate in a machine, if I want to respond and then the alert and the actions associated with that particular land. So this is a bit of an explanation of a manual incident investigation in XSIAM. And to close up by looking back at the dashboards, I just wanted to show you how basically you can if you -- on a high level, you don't just enable automation, leverage analytics and do your investigations. You can always -- can also track the performance of your SOC. There are tools like the security [ ash ] admin dashboards that allow you to kind of break down the performance of your investigations as it were across the alerts categorized by criticality. So you can see what your [ MTVD ] or [ MTTRE ] is across several sort of critical alerts and there are several dashboards of this kind and you can see how much time you're spending on a lot of different criticalities. And maybe you'll find out that, hey, for some reason, are spending lots of time on low priority alerts, there must be something wrong with my process or I can create some automation or some playbooks that can help me speed up my investigation in my response. Well this is a [indiscernible] overview of XSIAM, it's basically dashboard, investigation tools and data onboarding, 3 sort of pillars and fundamental aspects of the XSIAM workflow. That's it from me.I'm just looking out for questions, if we've got any. Going once, going twice. You can follow-up your questions, if you like. Okay. you can always get in touch with us at the end of this webinar. You'll receive a thank you email with our contact details. And for those who asked or sort of submitted their queries, we'll get back to you. Well, is this product integrated with third-party produce? The -- if you're trying to -- basically, if your idea is to integrate XSIAM with a third-party product, exposing its output from an API and sending it another or sort of a higher level interface. Well, if you need -- if your use cases, you have several XSIAM tenants, you can -- from the Cortex gate when using our MSSP interface on managed services sort of dashboard, you can oversee the output of different XSIAM tenants that's your use case. But if you're looking to basically use XSIAM as a detection tool, you might want to consider an XDR as a different product because if your XSIAM is part of your workflow, and not the end game, and not your sort of main UI, then you might want to reconsider how you see XSIAM. It's really designed to be a central focal point in the end basally your main sort of system within the SOC. It's really not designed to send data to other systems unless you have a multi-tenant sort of configuration, if that make sense. No Problem. Okay. Well, thanks for sticking around. Really appreciate it. Hope you have a wonderful day. Hope you found this useful and until next time. Thanks.