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

That's because I'm on mute. So just confirming, hopefully, everyone can hear me. Good morning, good evening, good afternoon, and welcome to today's Fight Tech with Tech webinar on Cortex XSIAM. I'm your host, Nana-Ampofo. I'm going to introduce myself a little bit in a moment. We are going to give it 1 to 2 minutes for more people to join. I'm just going to put some house rules in the chat as well. It's kind of the basics rules when we're doing a webinar. I'd love for you to use a Q&A and know that we'll be able to unmute as well, if needed, to give you an opportunity to talk. But I want to put that in the chat. All right. So I think we have -- so far, we have 30 attendees. I think we're good to go ahead and start, and hopefully, we'll have more people joining us along the way. So then going to take a moment to greet everybody from wherever you are in the world. So good morning, good afternoon, and indeed, for some of you, it might be good evening. Today, we're going to be talking about Cortex XSIAM, and we're going to be looking at how we achieve success at the front line of the autonomous SOC. I'm your host, Nana-Ampofo and I'm a Cortex specialist. I'm a technical specialist that speaks to our customers day to day about transforming the security operation. So in my work, I get to speak to CISOs, security architect, security analysts, security engineers, and people who are confident about improving the security operations, and I believe we all are working in this field. So I'm looking forward to talking to you a little bit about XSIAM today. I'm going to take you through the product, the vision for the product. I'm going to leave in some anecdotes about our security operations center in our own journey, but I'm also going to tell you about some of our customer journeys as we adopted this product, including one of my customers, Imagination Technologies, as they are one of the first organization to adopt the technology. So let's go straight into it. Now half of you were in the chat, just to repeat them out, please feel free to use the Q&A if you do have questions. I will poll from time to time to check in and respond to any questions. And if needed, I will also unmute you and allow you to talk so that we can have a chat live. I'm going to go ahead and get started. Right. So this is what we're going to talk to you about today. We're going to talk about what XSIAM is? And then we're going to go to some customer stories. Then we're going to take a moment to pray for the demo gods and then we're going to go into the demonstration, which will hopefully proceed without any if you not that, that has ever happened in a live webinar. So let's see, that's going to be fun. Right, let's talk about what the issue is. Let's frame this challenge. The challenge that we've seen as an organization and this reflects our own journey as well as our many customers is the traditional approach has been -- the best way to solve security from a data standpoint is to have these specialized data and analytical tools. So we have our EDR, UEBA, NTA, cloud detection and response. And every time there's something new, we add a 3 or 4 other acronym in security to do that job for us of dealing with the silos. Now the problem is we end up with humans acting as a human correlation engine. So you, of course, want machines to be actually doing that work because they're better handling data and volumes. And these days, we are all typically facing a massive, massive deluge of events. So even using our own security operations center and our organization as a reference point, as a company, we see about 36 billion events a day, which is an insane number, and we only have -- we have 15,000 employees. We do, of course, have about 400,000 virtual machines that we look after as part of our security operations center because that encompasses all the various deployments of our technology, which encompasses customer data and also some other things. But of course, we have a lot of things that we have to look after. However, that is still -- we're still not the biggest company in the world. So thinking about that, every organization, regardless of the type, is dealing with a massive volume of data. Now if you split that data into different swimlanes, you will have a challenge from a learning perspective to actually get out accurate detections off the back of that. And the other problem you will have inevitably is that even if you send all of those detections as alert into a SIEM, you then need a human sitting behind the screens to look back to try and make sense of how all those different alerts fit together. They have to go through the detection investigation and response rate as part of that. And typically, what has happened to compensate for this data problem is that automation has become a bolt-on. So it's either the automation, which is a kind of very simplistic automation, whereby some EDR tools will allow you to do things like if I see a threat on an endpoint autoisolate that endpoint or maybe have some very, very, very simple rules for deciding whether or not to authorize that endpoint. But security does not work in terms of single action for a very simplistic rule. It works with respect to processes. Those processes correspond to workflow. And those workflows are things that we can automate. And we can do that by bringing tools like XSOAR much closer to where the data sits, much closer to where our alerts are being generated, but we can also simplify the requirements that are placed on automation by rethinking the way that we actually organize data and use data for the purposes of detection, both from a machine learning perspective, and a threat hunting and human ingenuity perspective within the process. So let's talk about that more. Before we get into that, as a company, you know that our history has been outlined. It seems that most people on this call will know that our history has really been accounted from different parts of the security space. What we're most known for has been starting off as a next-generation firewall company, reorganizing that space, making groundbreaking shifts by bringing together and simplifying what was the traditional UTM-based architecture into our single path parallel processing architecture and introducing concepts like App-ID and a true Layer 7 firewall to the world. We since advanced that technology to incorporate things like fast. So this has really been the bedrock of Palo Alto's network, but that's not what the company would build to do. The company was built to disrupt everything about security in a productive way to ensure that we are reimagining this space. So we've done that in the cloud, both in the private and public cloud. In the private cloud, we have reinvented assets of the private cloud by bringing our new form factor with our VM-Series firewalls, eventually with our CN-Series firewall in the container form factor. And we've also gone into fields like CSPM and CNAPP and CWPP. We've expanded our capabilities into things like scanning APIs, scanning code and actually shifting left. And this has been really revolutionary in the cloud space, but we thought, well, let's keep going, what we started to do that in the endpoint space. We were the first company to release the concept of XDR in 2019. That really shook up the market. And not too long after that, everyone's favorite vendor or least favorite vendor was releasing something. That said, this is XDR and all the analysts were on it. So this is really interesting because in my time in the technology industry, I think there's a few times when a vendor has said, "Hey, we have a new idea, and we call it this." And pretty much every major vendor and analysts after that said, "Oh, we also wanted to do that thing, and we also think that's a great idea." So we thought let's go to the next stage, which is let's disrupt the thought because the SOC has always been built around this idea of the SIEM being the central platform for the SOC and the SIEM has its own problem. So we thought let's redesign how SOC works and let's redesign the technology to enable customers to redesign the people and process as part of the SOC. And this is really important because what makes XSIAM so different is not just that it is a new technology. It is a technology that enables you to rethink the people and process aspect, which is the most critical aspect, I would say, of a SOC. Through technology, you can swap out, you can do all sorts of things around technology, but you can't just keep hiring people. They're not infinite security analysts available. And your processes are the key things that reflect your risk posture and your attitude towards risk, your mutual compliance. It reflects everything that is key to actively having a digital blueprint for how your business responds to risk. So these things are critical. And if you have the right technology to underpin that, it really gives you the opportunity to explore and enhance the way that you do that. So let's get into what XSIAM is. Of course, XSIAM is a capability to borrow from all the concepts that we have established ourselves for in the security operation space. We take the idea of HIP data from XDR, and we bring that into XSIAM. But let's take a moment and let's talk about what that means. HIP data is the ability to take the different data sources and augment those into a single log. So in other words, let's use a very basic example. I am currently sitting in a hotel room, I'm actually on business travel. I'm going through the Internet through our CASB platform using our GlobalProtect agent. I also have a Cortex XDR agent sitting on my machine. From a network perspective, I'm generating logs. I have the Zoom App-ID and a bunch of other app IDs that are being generated. And maybe who knows, there might unfortunately be some threat that my machine will encounter from a network perspective. All of these things will log from a network perspective, but that would be a single data silo in a traditional architecture. What the security team will not be able to do is establish, which processes are responsible for launching which App-ID. So in other words, we want to have that full breadcrumb trail back to the process that originated that network connection. But we also want to see how that process was originated. Was it through some suspicious activity with respect to power shell? Was it done legitimately because a user clicked on something on their machine and launched the client? Is that particular process that's running at the moment, running using a CLI that looks a little bit strange for that particular process? Are there some strange activities with respect to the DLL that have been loaded? So there's all these other things that you want to be able to get into the depth that are coded off in the traditional environment in an EDR tool, for example. Now the great thing is that there's no vendor out there that collects more detailed network data than our firewall in whichever form factor, physical, virtual, container. There is no vendor that collects more telemetry from an endpoint perspective. And then we're able to interplay really nicely with identity logs from technologies such as Okta and Azure AD. And we are then able to do that stitching. So what stitching means is that we're able to reflect the series of actions that were taken from a process and a niche perspective to lead to those network connections and then give you the full detail around the traffic logs that sit behind that. So we have that complete log without you needing to have to write a correlation rule to tell you that story in a time without you needing to write parsing rules to tell you that throwing the fin out of the box, we will stitch that data. We will bring that story together. We will ship it into our machine learning data management layer, which will then enable us to tell you interesting things about that data from the perspective of suspicious and malicious activity. Now in the demo, we're going to actually see what that looks like. But the key thing I really want to take -- I want you to take away from this is that normally is a lot of work for a SOC analyst to do to get that full picture with a very simple example of just network detection. We will do this out of the box. We will bring the logs together, but it also enables us to get better results from a machine learning perspective because we are then able to actually train in a more accurate way to build more reliable detection model. And the other key thing is that we then wrap automation around it. So that means that everything that we do, and we'll see this when we go through the XSIAM demo. Everything that we do in XSIAM and in this idea of an autonomous thought should be automation first. Automation first does not, and I want to be very clear on this, it does not mean that we are replacing humans. It means that we are sufficiently augmenting humans to ensure that we are reducing -- we're balancing that risk reduction against the automation needs by being able to take the workflow that your organization cares about, this is really key, and represent them as an automation workflow within the product that responds to a specific alert. So this then enables the SOC to work on being more proactive, it empowers analysts to focus their work on doing activities like threat hunting, alert improvement, working with the engineering team to improve playbooks, to improve internet layouts. This generally gets better because that's what you want them to do. But the other very important outcome when we kind of talk again about people and processes is that it encourages analysts to stay. One of the things that we found in our own SOC and our customers SOC as they've adopted our approach, I mean, even pre-XSIAM with customers that have adopted XDR, we have seen lowering churn, which means that analysts will want to stay because it allows for a SOC that is more dynamic. It allows for day-to-day work that is left about alert fatigue and is more about doing interesting type of work that analysts generally enjoy. So this is really the key and this is what makes this approach so different. So this is why we believe that we need to transform from the machine-led approach that empowers humans kind of a human-led approach with automation as an afterthought and as a bolt-on. Let's go a little bit further. Let's talk about the foundations of XSIAM. We talked about this. I won't spend too much time here. The key things are the intelligent data and analytics, the automation-first approach and are focused on enabling proactive security from a people side, people of about proactive security. The automation-first approach is automating your workflow and that is the focus on processes, the intelligent data and analytics vector technology. What does that mean in terms of what is within the product? Now as a company, we have always focused on building best of breed. We have to. We literally have no choice to survive as a company because we have about 90,000 plus customers growing all the time. Our customers span from U.S. Department of Defense, all the way to kind of some relatively small start-up somewhere in the world. The variety in terms of our customers and the criticality and all of them are critical regardless of which space they operate in. But the truth is that some organizations have world span and reach in terms of if they were to be bridged but to fail, which means that it is on us to ensure that we're able to provide products that are restrictively secure and also to secure ourselves. We also, of course, look like a very, very interesting target from anyone to a script kiddie that's trying to make a name for themselves to a very sophisticated threat actors. And that is why we have to run technology that is military grade with respect to the ability to protect, to provide prevention capabilities but to also provide detection capability. This is why when we talked about having a best-of-breed platform, we mean that each of these individual categories, we have been tested and proven to have capabilities that can match the very best in our industry. So it can go toe-to-toe against our peers in any one of these categories and prove that we're able to keep at the same level as the very best out there. This is key because by bringing all of those capabilities together into a single product in XSIAM, we're now able to present a company that is very unique. And as you'll see, this is a single product approach that is not a -- here's a bunch of web front-end tricks to make it look like it's actually a single product. But when you start clicking around, you realize that you're being diverted back into the individual products, and there's no cohesion in the back end. We designed and built completely new back end that takes ideas from each one of these technologies versus just putting our front-end ramp around it. So this is really key. But let's look at a case study. Let's look at what we've achieved in our own SOC by deploying this. It's taken us the better part of 6 years to get to a space where we have XSIAM fully deployed, we've replace any legacy SIEM technology. So we no longer have a traditional SIEM of any kind within our SOC. Our data platform revolves around XSIAM. Our automation capabilities revolve around what we're able to do with our store capability. And over time, that will all collapse into XSIAM because, of course, much like anyone else, this is a journey in a transition. What does mean? As we said earlier, we see about 36 billion events a day. Those events are filtered by our product into about 133 alerts. Now it does say 125 when automated, I do want to clarify that. What it actually means that this reflects the percentage of activity that we're able to get out of automation so that we're able to then reflect on much effort towards resolving an alert goes through automation versus growing through human activity. So roughly 90% plus of that resolution goes through automation versus human activity. This has helped us really transform the way we operate. And as you can see, it's helped us to have and maintain some very, very impressive metric. Well, let's talk about this from the perspective of our customer. So I'm going to start with actually one of my own customers, Imagination Technologies. We are fortunate enough to work with their team throughout the transition to XSIAM. Now they have a very, very small team. They have to contend with that constant firefighting exactly the type of issue that I have seen in many, many customers. What they really needed to do is to have a unified approach to endpoint, network, cloud and identity data to be able to comfortably have all of that data pitched for them so they didn't have to do all the heavy lifting to be able to leverage automation as a first part to help to deal with any potential threats in their environment so that they could take all of that weight off of their very small team and allow that team to continue to operate effectively without being overwhelmed. So this has allowed them to have an easier path to ingest data and to normalize that later using XSIAM, the sitting capability and our data model. They're able to have all threat information in one place. They have more confidence to make the right security decision, and they've been freed up to purpose some other time. So this is the quote from Paul Alexander who is the Director of IT Operations, and I'll give you all a moment to read that. I'm actually going to walk you through that. I'm going to have a quick look to see if you have anything in our Q&A. Okay, not yet. And again, feel free -- for those of you that may have joined a few minutes late, feel free to jump into the Q&A if you have any questions. I will be taking that from time to time to answer any of your questions. We are still going to have a demo, just to emphasize for those of you that may have joined a little bit later on. There is a demo coming. So this is what Paul had to say. I'll read one line of it. XSIAM is a single highly integrated tool. So this is important because, as I said earlier, it is not a game of front-end manipulation. It is a unified back end with different technologies, allowing us to actually take advantage of connecting those technologies in the back end, as you'll see in the demo. Let's look at another customer who we are referring to as Health System Inc. Of course, not every customer wants to have their name publicly out there, but this is a health-focused customer. Their need was to decrease their log-in costs, to decrease security architect tuning time, they wanted to have more confidence in their alerting, and they wanted to have the full threat picture together. There is another key thing that I find there. So besides the stitching of the underlying log, XSIAM will also correlate alerts into a single incident, as you will see. It will highlight all the key artifacts for that incident. In other words, it is doing work that you traditionally associate with a Tier 1 analyst. This is giving you an opportunity to rethink the structure of a SOC with regard to the traditional tiers and to enable you to transition to a way of upgrading that pictures more emphasis on Tier 2 and Tier 3 type work and less emphasis on Tier 1 work. In other words, you have an opportunity for your analysts to do more senior work, which is fantastic, I would say, for every organization. XSIAM leads to decreased false-positive. It also significantly help the credited speed and it's made better financial sense. So let's think about that for a moment. Many organizations will tend to take the best-of-breed vendor approach, where they'll buy point products and then they'll try and bring that all together in a coherent architecture. They'll put a SIEM on top of it, they'll put XSOAR on top of it and they'll just try and make it work. That means that you have to -- you pretty much will end up stuck in the traditional 3 tier operating model. You might get help from an MSSP to do your Tier 1 work, for example, which is something I hear from a lot of customers. And then you're going to maintain some sort of engineering functions to help with all the playbooks that you have to build XSOAR and all the correlation alerts and things like that we have to do from a SIEM perspective. It's really important to consider that this is actually a huge cost for most organizations. And once you start to actually do the math around it, transitioning to a capability like XSIAM for our customers has lowered the total cost of ownership for security platforms. Now I'm going to take a moment, actually there's 2 questions in the Q&A.

So I'm going to go over to the Q&A to answer those. Before I do that -- well, as I do that, I'm going to leave this quote up on screen for you to have a look, and let's have a look at some of those questions. So I apologize. I see a question on Eric, let's have a look at that. How hard or easy would it be to use XSIAM if you already have XSOAR, right? So Eric, to answer your question is to migrate to XSIAM, and I'll talk about this more during the demo. If you already have XSOAR, you will be able to take some of your content into XSIAM. That being said, the important thing as you'll see in the examples is that the way that things work in XSOAR with respect to XSOAR and the way that you handle alert actually tends to mean that you will have smaller, more focused playbook as opposed to a complex playbook that will handle incidence of scale. But what I mean by that is XSIAM is alert related and focusing on a specific technique, if we're looking at it from a micro perspective, whereas XSOAR tends to be incident-related. XSOAR tends to be building a playbook to look at an entire incident versus building a playbook that's going to look at a single alert. And in some cases, you'll be doing both, and it might be that you're doing a copy paste of that -- lift and shift to that playbook because, again, it's playing capability, you can import and export playbooks, but you could import that playbook into XSIAM, use it for the corresponding alert for the corresponding tool. However, keep in mind, we'll see it in the demo that it might be that you need to have a more compact playbook. And in some cases, you can take advantage of the out-of-the-box playbook in XSIAM, and we'll talk about this, too. So I hope that gives you an idea. For every customer, it's going to be case to case in terms of that conversation. So what I would recommend is because, of course, I can't speak to your specific case in this call is, if you don't have -- if you have more questions that are specific to your organization, do reach out to your core sec team, have a conversation with them about XSIAM, and they can actually help you talk through the specifics or engage someone like myself because I'm part of a team that covers our customers in EMEA and LATAM. So it might be the that you end up speaking to me again. All right. So just an unremarkable way to answer live. I see there are notes in the chat, I'll have a look at that. The license model for XSIAM. So Let's talk about the license model for XSIAM. I'm going to do the last case study. We'll talk about the license model, and then we'll go into the demo. So let me start -- let me go through this last case study. So this is Resort Co. So this is a hospitality organization, they needed to decrease their log-in costs, again to increase the learning confidence, which we saw in the previous example and they want to consolidate their security stack. For them, it's led to a reduced meantime to respond. They've been able to improve their real-time investigation closure, and they went from 3 offerings to 3 dispatch technologies to a single technology that's able to deliver all those capabilities. And again, this is really key because in the traditional approach, it's been about I need this vendor that is the best EDR vendor, I need the best NTA vendor, I need the best this, the best that and I pop them all together. That doesn't help to solve problems with respect to the overarching outcome and in terms of being able to change your approach to people and processes as this is really the key thing that XSIAM helps to you. It helps you to reduce your metrics, it helps you to retain your staff and it helps you to automate your processes and workflow at the heart of the SOC and take the automation-first approach. So that is really key. I'm going to put up this approach from the senior network lead at Resort Co. And then I'm going to respond to the question -- I'm going to respond to Frank's question about the licensing model. I'm going to talk about the licensing model, and then we're going to go into our demo. The licensing model in XSIAM works as follows. We have an employee-based licensing model that is based on the number of digital users in the organization. We also then have the ingestion model. And the ingesting licensing is similar to your traditional SIEM. So this is enabling customers to bring in third-party data and load that data into our data model, which will then be driven through analytics. Those are the 2 core licenses in XSIAM. So to be clear, you have the employee based license which allows customers to use our XSOAR capability, analytics to deploy the XDR agent throughout the organization. And then we have the ingestion license, which is to bring in all non endpoint data. So the employee license includes endpoint data. All non endpoint data goes through the ingesting license. We then have a series of modules because we appreciate that not every customer will want to consume external attack service management, for example, from day 1. So ASM is a module, you can consume that if you want from day 1 or you can consume that at a future time. You have a forensics module, if you like to use the forensic capability of the XDR agent. It's exactly the same agent. It's just a matter of turning on that forensic capability. If you have forensics teams in your organization, then they can make the use of that. We have a module for the ITDR capability in XSIAM, and then we also have a threat intel module. So that is just making it easy for you to consume the capability in a modular pattern, starting with the XDR and XSOAR element of XSIAM and then going to each corresponding module if you want to continue those capabilities. So I'm going to shift over, just making sure that there are no more questions, nothing in the chat, and I'm going to go ahead and we're going to get that demo started. I'm going to close this window. And here you can see XSIAM. Now again, please feel free to keep those questions coming. Thank you for keeping a nice and interactive so far. I will come back to dashboard. I'd actually like to start with a different part of the product. And then depending on time, we'll definitely come back to that product. So I'm going to go through a couple of different things. I'm going to start with a very simple incident In XSIAM, then we're going to build our way to a more sophisticated incident in XSIAM. And the reason why I chose to do that is I wanted to show you a basic incident where we just have our XDR agent. Now those of you that have come across our XDR agent, it's an EDR capability that we have. This is exactly the same agent that we use. And for those of you who that have seen demos of XDR and/or currently use XDR, you'll realize that this looks almost identical to XDR because, again, we've taken the capabilities of XDR, we brought them into the XSIAM back end, but we've also taken the capabilities of Cortex XSOAR and we bought those in to the XSIAM back end. So what you see in front of you is threats that are run in my own environment, where I've had 3 alerts that have been generated. And of the 3 alerts, 2 were high severity, 1 was medium severity. XSIAM was able to automatically triage those alerts, group them into a single incident. So now I don't have to go and run around looking at the individual alerts. It's able to extract the assets. It's given me the names of the user. It's given me the user's machine. And it's also told me in this case, I've tagged up my machine, so it's given me that tags as well associated with those machines. Those same tags, by the way, can be used to implement things like access control, so there are only users that are supposed to access and review certain machines are able to do that, but the common threat might get kind of onto that one ahead of time. We're also able to review all of the various alert sources and data sources for this particular incident. We'll see a more sophisticated incidents in the moment where we're looking at multiple and even third-party data sources as well. But starting with it just to give you the basics. You'll notice that 2 playbooks have run and completed, they run against 2 of my 3 alerts. A third playbook has run, but it's waiting for the analysts. So let's click on that playbook and see. So think about it this way. There were 3 alerts, there were 3 playbooks. In other words, the product has had for each alert that's been generated by the agent, digital playbook that will run and do some work on behalf of the analysts. Two of those playbooks have run to their full conclusion. One playbook is waiting for me or the analyst to click on it and provide some sort of input or feedback. And this is really important, and I should praise the demo god for a moment. I did wanted to start that they would come after me as they always do. So we're having a nice loading speed. Let's see if that comes up. As it comes up, I would like to explain though. Here we go. This is a really, really basic playbook that I built to respond to alerts. So the key thing here is that you can build alert drive and drop. For any of you that are used to XSOAR, you'll see that this looks very, very familiar because it is XSOAR capability, not XSOAR, the product, hidden using front end [indiscernible]. So you'd rather haven't been scuffled off into a different screen that opens XSOAR. It's actually a playbook that's integrated into the same UX, and I can go ahead and interact with it in a way an independent XSOAR incident between XSIAM, which is really cool because I can not only focus on threat alert, but having to focus on all 3 alerts at the same time. And that means that I can write some pretty simple playbook. So this is a very simple playbook. All it's doing is asking to isolate the agent automatically based on the alert side, giving us some parameters to do that. And then it's asking me, should I keep the machine isolated? If I say no, I mark the target completed. I will go ahead. We're going to do another quick pray to the demo gods and of course, that didn't quite work. It will isolate that endpoint, but we're going to stop that there. That's probably because my machine is offline at this moment. My demo machine is off-line. That will then isolate the endpoint, and that will complete the playbook. So this is giving you a basic view of this. But if we go into the incident configuration, I want to show you how actually builds that playbook. I'm not going to build the playbook for wake of time, but I do want to show you how I would be able to create a trigger. Do I have a basic trigger down here, which is labeled for me. I can create a playbook triggered in time. I can give the trigger a name. I can tell. I can decide which playbook needs to run. I can, of course, put a notes in the description. But what this does is that it loads all the alerts from all the different technologies within XSIAM and then allows me to create the filter. So I can filter across a range of different things, as you can see. I can filter according to your alert book, I can filter according to the category, to the alert name, description, the alert type and so on and so forth. This allows me to then identify in quite a bit of detail what conditions I would like to trigger a playbook of name X for. And that playbook will then run when an alert rather than the data in an alert meet the criteria that has been set to execute that playbook. So this is really important because it then allows you to have a flexible setup for processing alert, then processing a playbook and reactive, which means that the way you think about use cases from a tough perspective changes because in many SOC -- and again I speak to SOCs day to day, let's build an alert use case rather than detecting use case and it will probably be built out in the same. And then let's build a SOAR use case that will probably be built out in a separate SOAR tool. Now a use case becomes let's build the detection capability if we have to build it because XSIAM has many machine learning detecting capable of the box. At the moment, we have probably close to 1,000 -- potentially over 1,000 actually need to count this, but don't quote me on that number, different detection capabilities. This has ranged from a whole set of different things that you can detect based on the underlying data in XSIAM. If your team still needs to build additional capabilities, they can do this using their own correlation rules and their own hand written rules. Once you have those alerts and of course, we've got third-party technologies of wealth, you can bring alerts into third-party technologies. And then you can trigger a corresponding playbook to run using this playbook triggering mechanism that I've just gone through, and you can build your own playbook. But let's move on to a more complex incident to illustrate that. Now what you see in front of you is a more complex incident. This incident has 37 alerts in total. Within those alerts, we actually have used our XDR agent, our Palo Alto network's firewall but here are some examples of the analytics within XSIAM. So again, if you use XDR, you'll notice that this is a stain detection and analytics capability that you'd be used to in the XDR world with the caveat being that XSIAM is now able to look at a wider range of underlying data sources in XDR, a significantly wider range of underlying data process. And we'll actually, in a moment, look at what data source ingestion looked like within XSIAM because we have this really amazing marketplace, and we have a data source onboarding capability to bring that in. We see several data resources here, they are third-party data sources in our firewall and the HDR agent, but we also see third-party data sources like [indiscernible] and from Windows Event Log. We see a number of playbooks that are run to completion that are run in response to these alerts, much like I showed you in the previous example, and we also see all the corresponding assets. If I click on the key assets in artifact page, I'm able to get a full breakdown of all the artifacts that have been identified, enriched with tagging from Unit 42 to give additional context and classifications from our box -- I'll describe it, out of the box, anytime that we have an alert from XDR, we will elect our agents those alerts will be -- rather malicious files will be committed to outside. So if we know the file already, we will block it based on the existing wildfire verdict. If we don't know the file, we will use local analytics to evaluate it, which is a machine -- SAP machine learning model that will -- while machine learning models throw static analysis, that will look at certain parameters and decide whether or not to run certain features and decide whether or not the file of malicious. We will also commit a copy of that file to wildfire for our analysis, and we will always provide the wildfire analysis report and the wildfire verdict for the analyst to review. This is really important because as you can see here, you can see all the processes, both malicious and benign that have been involved in this particular incident. We also see all the various IPs and domains enriched with who has information on demand and in reprising with VirusTotal information. We have a full intel management platform, which is a module, as I mentioned earlier within XSIAM that we can use to do further enrichment within the XSIAM playbooks for each and every single alert and have those captive within the alert layout. So I'm going to pause here and just take a moment to see if there's any Q&A. Currently no Q&A. Keep those questions coming in, of course. And of course, we do have an incident. So here, you can actually interact with your peers during the course of an incident, you can exchange ideas, you can run commands. And this is really powerful because again, -- it allows me to collaborate without having to pivot into a completely different piece of technology. It's making it much easier for teams to work together. You'll notice that there is a severity for this incident, which is from critical, we can go all the way down to low. Now we offset it score. Now I haven't talked about this year, I'm actually going to pivot back to one of our other systems to illustrate this. I'd like to talk to you a little bit about SmartScoring. The Smart scoring is a very cool machine learning-based capability that we introduced into XDR and XSIAM. What SmartScoring does that it enables the product to look at certain features within your environment, but also global features. So what I mean by this is we will look at your environment in the perspective of where a particular IP is? What the tendency is for process to be blocked, et cetera, you'll look at all of these various statistical features and then it will allocate a score from 0 to 10, but we will also explain some of the details around that. So in this case, we will look at a better example. We'll actually give you detail. So for example, we'll tell you the reason why the score is set to 98, when that malware was detected, the XDR agent prevented suspicion activity, and then we collectively performed some suspicious path, correct, actively improving this capability all the time and this is greatly enhancing the ability for us to tell you what to prioritize. So severity is always a useful reference. However, severities are dictated by the underlying alerts. And depending on the technology, it might create a very high severity alerts and a very high severity incident or a critical incident that for your environment is actually a score of 10. You can, by the way, set your own scores, so you don't have to rely on our SmartScoring. But SmartScoring is just a very quick short answer to help to guide your team that we will know which incidents to focus on first. So I'm going to close that, I see that there is a notes in the chat. I'm going to take a moment to look at that, and then we're going to talk about data source. So we've got a few different questions from Eric. Have you ever tested playbook management comparing at times with XSOAR? What's going on playbook store? We will talk about that. [indiscernible]. Okay. So let's start from the bottom. So we'll talk about the question on being able to analyze vulnerability management. So XSIAM as part of the XDR capability in XSIAM has something called Host Insights, which we inherit from XDR. What that will do is that will do vulnerability assessment across your Windows and Linux update. Over time, we're going to have more coverage for our operating systems and third-party applications. But we'll also integrate with tools like Tenable and Qualys. So you can pick in those alerts from their tools, and you can then have your playbook to respond in real time to alerts from those technologies. You can have that data onboarded as a data source so that you can create your own correlation rules, create your data sets off the back of that to use that to trigger additional alerts and then have a playbook that responds to those alerts. So the idea here is that we are then able to fully view your vulnerability, whether that's the vulnerability assessment that's been done by our agent or the vulnerability capabilities that come from your third-party tool quick bundle. So you can use that capability within XSIAM. So the second question is, have we illustrated how XSIAM investigation is faster than XSOAR investigation? So I think let's think about it in a different way. It's not so much that XSIAM investigation is after the XSOAR investigation. It's that in the XSIAM world, you do not need to build playbooks that respond to the entirety of every alert in the incidents. You can build focused playbook that only look at specific alerts and within the product, we will also provide out-of-the-box playbook capabilities. And let me show you what that means, we can suggest playbook to you within the technology. So I'm just going to go ahead and open one of my other systems to illustrate that. We're conscious of time. We've got about 15 minutes. So we do have enough time to go through those questions and also look at example from a data perspective. So if I go over here to the inside configuration, I've got my playbook trigger. And what I did not show you earlier, let's give that a second to load, is recommendations. So this is something interesting that we've added in XSIAM, and this is because we have found that by doing studies with our own customers, we found that customers struggle to implement for, not because the tools like SOAR tools in their totality are impossible to use. And of course, many SOAR vendors will say, "Well, we have the easiest technology to use, so then you'll be able to implement more playbooks. But it's more complicated than that. The problem is that what SOAR tends to be doing is SOAR tends to be trying to compensate for the fact that many organizations haven't deployed a tool like Cortex XDR that is able to do data stitching, that is able to do automated alert collision and grouping. So what they tend to do, if you look at a SOAR playbook besides enrichment, which of course is one of the very important stages, a lot of playbooks that are built, and I worked with customers for years on these kinds of projects. The playbooks are doing a lot of triage work and a lot of work that is going and trying to make sense of this bad tool. As you've seen in the XSIAM interface, we're doing this thing upfront. The technology is taking care of a lot of that heavy lifting so that we -- you don't necessarily have to write that into a play. That's one. Both XDR and XSIAM will do that. Then the second aspect is instead of having to insert the SOAR part as a bolt-on, you're actually able to let SOAR react live as alerts are being generated. So as an alert comes in, you immediately can write a playbook that responds to that specific alerts in that specific technique. And this means that from an engineering perspective, the effort required to actually implement SOAR is greatly reduced. And I've seen this with my customer. So in this case, I'm referring to some of the playbooks that we will recommend, -- these playbooks we recommended will often telling you the reason why we recommend that. And this is interesting because this means that we're focusing on technique. We're focusing on specific alerts and alerts are not unique, incidents are unique. And an incident is typically a combination of different alerts, but if we can focus on having modular playbooks that respond to alert and we have a technology that allows the alerts transition immediately towards a playbook, then you can respond live to different alerts they happen to the degree that you want, of course, because you can control the playbook and control, which parts of it are automated and which parts of it are manual. And then you can also ensure that the capability will close out those alerts for you, potentially close out that -- those incident for you. So this is really the best way I would say to think about the difference from an XSOAR-centric world to an XSIAM-centric world is bringing down the overhead in implementing and maintaining for the customer, recommending playbook to you, and we're also bringing the SOAR mechanism noted to be alert. We are doing the triage work that you would typically have to do as a first part of your playbook whether it is public playbook. We are doing that work for you. So in other words, I'd like to think of it as we are doing much more work for you from an engineering perspective that you have a like to load when you're implementing SOAR, so thought less about. And much like with the analyst perspective, we don't want security engineers to be spending hours and hours and hours of cycles, building complex, building and maintaining complex playbooks, we want them to be doing more interesting work, but the same goes for the analysts. That's what it's about. It's not so much that we think that XSIAM will be dramatically faster versus XSOAR in a head on rate. It's more about how we can actually give a very valuable time back and reduce that effort that's required on top that we would say are not the critical tasks for security engineers, are not the critical tasks for security analysts. So I will stop there. I hope that answers your -- 2 out of 3 of your questions, Eric. I do not see any other questions. So you are on luck. I will answer your first question as well. All right. So talking a little bit about playbook management, okay? So playbook management -- there -- I think you've seen that actually. I hope that I've answered that question. But if not, again, feel free to reach out. We could have a more detailed computation one-to-one. We can go through some examples that are specific to your environment. So with that in mind, I'm going to go through a couple more parts of XSIAM. So I'd like to show you how data sources are onboarded. And the important thing about XSIAM is we've taken the concept of a marketplace that you would be familiar with in the XSOAR world for those of you that are familiar with XSOAR and we brought that into XSIAM and we brought the ability to be able to onboard data sources into our data model, which is the last thing that I'm going to talk about -- second last thing I'm going to talk about depending on time today. And as you can see, we have many technologies here. So here, I'm able to start to connect a variety of different technologies. We actually have hundreds of different technologies that are connecting here. I can filter this by technology type. As you see, we even support things like third-party endpoint solutions in our competitors like Check Point, we'll take in their data, we'll integrate with their technologies. We'll provide you with playbook. So a lot of the content that any of you extra users will be used to fit within XSIAM, but we're also then able to take in the raw data from various different technologies into the product tree. This is really key because being able to take in all these different data sources. So if I click on any given data source, let's say, for example, clicking on AlienVault, XSIAM will then walk me through that process of onboarding with. Again for those of you that use, XSOAR might look a lot like the XSOAR because it's supposed to look a lot like the XSOAR marketplace. But the next time, we also have recommended content. In this case, we don't have an example of recommend content for AlienVault. But if there's still relevant content that we thought, hey, if you connect this 2, you'll get additional value, we will recommend additional content that you should connect. So this is really key. Now once that data comes into XSIAM. I'm not going to go into the playbook side, on the SOAR side of it. I'm going to talk about the automation, the ingestion side of it from a SIEM perspective. So the SIEM aspect of XSIAM is we've taken data and we absorbed into our data model. And we do that by passing the data into it's unique data set and then abstracting from that data set into a data model. Now again, this is a concept for those of you that are working with SIEM. We'll be quite used to this idea of being able to normalize data into a common schema, allowing us to then be able to easily query that. So what you'll see here, I'm actually going to pick -- let's pick Apache, for example, as an example. So here, we have -- it's actually Tomcat. So we have the Apache term. We have the Apache roll logs coming in from a Tomcat survey. What you'll see is that we've created a data set, but we've also gone ahead and set the parameter for extracting various logs -- various fields from the log. And then we are mapping those fields into our XSIAM data model. by mapping them into this common data model. So for example, that means that every time we encounter force IPv4, I don't need to know the specific field and specific format within the field to find that log for Apache. And let's say, for example, I was using multiple web services, I was using a web server technologies, NGINX, Apache, IIS. I'm using all of those in my environment. If I want to run a query or I want to feed in the case of XSIAM my data model to do analytics on the source IPs and analyze that I don't want to have to track all of these different labels and different schemas. I want to have a common language. And this is what the data model allows us to do. But by extracting data into this common data model, we're then able to present this information on the fly to any time our customers want to make a praise. So any time an analyst wants to run a query, you can build correlation with detection capabilities on the back of that. You don't have to memorize or be an expert in every schema for all the hundreds and hundreds of tools out there, which is incredibly useful. So that is the one aspect that I wanted to cover. And then I do want to speak briefly about our threat intel management capability, which is embedded within XSIAM. So it means that we can manage indicators, I can click on any indicator, I can have track a verdict. I can bring in hundreds of threat intel sheets. We can also run jobs. For those of you that might have seen a similar capability we have within XSOAR. We've brought that into XSIAM. So it means within XSIAM, you can comfortably manage all of your various threat feeds, but you can also use those threat feeds to create detection that will generate alerts in XSIAM and offer those detection again, you can run playbooks within XSIAM. You can have the groups into common incidents. You can run jobs in XSIAM that will go and harvest any changes in your threaten cell feeds and use those changes to go and do threat hunting for you automatically. So there's so many interesting things you can do when you start to bring all of these technologies to live in the same place, you're cutting the overhead, that engineering overhead of having to manually connect your tools and maintain those tools between different connecting. Now you have them built into a unified technology in a single console. So again, unified front end, but more importantly, unified back end. So the last thing to show you, I think we'll probably get back boarding today unless someone asks specific questions on that, until we have 5 minutes left, is data ingestion health. This is one of the key things that we've seen as a talent within the SOC is once you conduct all your various technologies to your SIEM, to your SOAR, you want to be able to actively track or at least you want the technology to actively track. We haven't seen logs from this particular technology in the our few hours in the last few days, we want to be able to actively monitor and track that your engineering team can then be on top of any issues, underlying issues in your infrastructure that are actively calling you to have a blind spot without you necessarily being aware of that blindspot. It is another key thing that we brought into XSIAM along with more recently compliance reporting. So we now have compliance reporting for all the major compliant frameworks out there for your GDPRs, your ISO, that we're able to cover those through the compliance reporting module. And with that, because I always am conscious of the fact that XSIAM is a part that stands so many different spaces and the extremely topics to cover, I think I'm going to pause -- stop here. We'll give it a couple of minutes for any questions you might still have. I'm going to leave it on the dashboard page, so at least you'll have a look at the dashboard. And I'll open it up for a couple of final questions and/or comment. So let's give you all a couple of minutes if you have a question, if you have a comment, please feel free to put that in the chat or put that in the Q&A. Going once, going twice, and I will take that as no further questions or comments at this point in time. I want to thank you all for your time today. Thank you for attending this webinar. I hope that you found it useful and enjoyable. And I look forward to speaking to some of you individually. As I said, feel free to reach out to Palo Alto Networks account team if you have any further questions on XSIAM and perhaps will have an opportunity to discuss the product again in more detail. I wish you all a fantastic day ahead if you've starting your day or a fantastic evening if you're ending your day. So with that, I'd like to say goodbye. Thank you for attending.