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

Hello, and welcome to the XSIAM 2.0 launch event. If we haven't had the chance to meet before, my name is Matt De Vincentis, and I'm the Vice President of Marketing for Cortex at Palo Alto Networks, and I'll be your host for today's special event. XSIAM is the AI-driven security operations platform from Palo Alto Networks. And since launching XSIAM about a year ago, we've seen customers deploying XSIAM globally at scale. XSIAM represents the next major step forward in terms of product maturity and capability, and we're really excited to show you what's new here today. But first, you'll hear from Palo Alto Network's Founder and Chief Technology Officer, Nir Zuk. Nir is going to talk about why the current approach to security operations is failing and what you need to do to fix it. From there, Palo Alto Network's Chief Product Officer, Lee Klarich, will walk you through our vision for XSIAM and how it's helping customers dramatically improve their security operations. And I'll be back after Lee to dive deep into the new features and capabilities with demos, including a special sneak peek of what's coming next. Just to make sure you stick around for that, you won't want to miss it. Without further ado, it's my pleasure to introduce Nir Zuk, Palo Alto Networks' Founder and Chief Technology Officer.

Forever, the cybersecurity industry has been focused on mostly 1 thing, keeping the bad actors out, network security, endpoint security, cloud security, identity and access management, vulnerability assessment, vulnerability management and so on have been all focused on trying to keep the bad actors out with a few exceptions. We look for command and control connections. We use identity and access management for internal segmentation to make lateral movement a little bit more difficult. But for the most part, it's been about keeping the bad actors out, which is great, which is important. We have to do that. We're going to fail. And why are we going to fail? Because they're going to try again and again and again and again. And if we miss them once, they're in. So they'll try 1,000 times, we'll detect them and stop them 999 times, and that's it, they're inside. So there is certainly a growing need to change a little bit the way we spend money on cybersecurity and the way we view our cybersecurity architecture moving away from, let's focus on keeping the bad actors out to, let's make sure they're out. And with that, assume that they're in, that they are able to breach our perimeter, they're inside our infrastructure and now we need to detect and stop them. Traditionally, it's been the role of the security operation center to do that, right? Go through a lot of logs and look for a lot of different things and what's called hunting, and try to detect the bad actors inside and then once detected, deal with that. A bad actor getting inside can be as simple as a phishing e-mail, making it through our perimeter controls into the organization into an end user, and an end user clicking on something and can be as sophisticated as a nation state actor lurking in our network for 3 months and looking for ways to get into our crown jewels and getting there and stealing them or changing them or deleting them or doing whatever they have to do. It's a huge spectrum of things. And it's all the role of the SoC to detect and stop those. When we go beyond keeping the bad actors out and we start looking at, let's detect them already inside and deal with that, there are 2 parameters we need to look at. The first one is the mean time to detect. And the second one is the mean time to remediate, the mean time to respond, there are different ways to interpret that, or at the end, mean time to detect is when we detect something bad, however, we detect it, we investigate the incident. And then we go back to see when was the first indication that the actor came into our infrastructure. When was the first indication that they were able to breach the perimeter. That's the mean time to detect or that's the time to detect them, of course, we do it over time, and we get the mean time to detect. How much time passed from when the first indication they are in to when we detected it. In the mean time to respond, to remediate is from the time we detected it, we started the process of dealing with it how much time has passed until we were able to say, okay, the incident is over. We're closing the ticket, the infrastructure is clean. Most organizations don't measure these numbers. Why? Because they look really, really bad. A typical CISO, if you are measuring these numbers, you would probably have to fire yourself because the average we see across our customer base of the mean time to detect is measured in weeks. On average, it takes weeks from the time a breach happens until it is detected. And the mean time to respond is measured in days, at best hours. And we think it's bad. We think it should not be like that. We think that it should be much lower than that. And we believe -- actually, we don't believe, we know because we're seeing it in many of our customers that we can bring it down to 1 minute. We can bring down the mean time to detect and the mean time to respond to 1 minute. This is what XSIAM is about. This is what this event is about. To understand how the mean time to detect can be brought down to under a minute, I want you to look at the following observation. Almost every time there is an incident and the incident is investigated and dealt with, the organization, the security operations center or the information security organization, in general, ends up understanding what happened. How they got in? What did they do? How did -- what -- how did they proceed? What did they jump? What did they access? What did they steal? What did they send out? Eventually by looking at different logs of different systems and routers and switches and applications and of course, security logs and so on, we're able to paste the picture of what happened. It takes a while. About our mean time to respond, right? It can take days, it can take weeks. We understand what happened, which means -- and here's the important observation that the organization almost always has the information to understand how a breach happened or how an incident happened. And that raises the question of if you have all the information to understand what happened, why didn't you use that information in real time or near real time in under a minute, to understand that it is happening. If you have the information to understand why didn't you just use the information to understand, why did you have to wait for a breach to happen and only then go and investigate. And of course, the answer is very simple, an investigation takes weeks. If you had to understand from all the data that's available in the organization that the breach is happening in real time, you would have to do what you do in a typical investigation for each and every event that's occurring in the infrastructure. And we're talking about millions and tens of millions of events per second. You cannot run 10 million incident response investigations every second. So you just see it and you wait for the breach, how do you know there is a breach. You find your source code somewhere else, the FBI calls, whatever, and then you go and investigate it. What I suggest is that using machines specifically machine learning or AI rather than using people, we can actually take millions of events, tens of millions of events per second and investigate each and every of these events as if it's part of a breach. And if it is a breach reported and start the response, start the remediation process, within, again, about a minute on average. XSIAM is doing it. XSIAM 2.0 is doing it even better. And you're going to hear in this event, how it happens. I want to challenge each and everyone of you to not be afraid and to start measuring your mean time to detect, start measuring your mean time to respond, report them to the organization. I know they look bad. Don't worry. We'll fix it. And then start focusing on bringing those numbers down towards the 1-minute mark. This is going to create a very secure infrastructure. This is, by far, the most important thing you can do in order to make your cybersecurity posture better. Challenge accepted? Thank you.

So I think Nir made it clear that the current approach to security operations just isn't working anymore. And he laid out the challenge for you to reduce your MTTR. Now Lee Klarich, Palo Alto Network's Chief Product Officer, is going to show you exactly how we're doing that with XSIAM.

Everyone. Lee Klarich, Chief Product Officer for Palo Alto Networks. And welcome to the XSIAM 2.0 launch event. Really, really happy for all of you to join us. Nir shared a lot of his insights, which I'm always particularly interested to hear, as hopefully, all of you are. I just wanted to expand upon one of the things that I think was most important in what he described. And it's really around how do we turn the SOC into a real-time security function. In the past, we've always had so much time to be able to detect an attack, while it is in motion, lots of opportunities to potentially stop that attack before the attacker is ultimately successful. A few years ago, this was 44 days. That's a lot of time when you think about it. Back then, we're using automation really to help address the capacity need more so than anything else. But this year, we have seen not only the average come down to around 5 days, but we've seen a number of attacks, large attacks on major enterprise corporations that have taken just hours from start to finish. This is why fundamentally, the SOC needs to become a real-time function. Even aside from that, if you just look at what it takes from SEC requirements in terms of driving 4 days to disclose material breaches. We've all seen how that's played out over the last few months. This is becoming challenging if we don't completely rethink the capabilities, the technologies underpinning the SOC. Now why does this need to happen? Why is this not just an incremental change? Fundamentally, the SOC has been built on this assumption that the SIEM is that core tool that is used and everything else is designed to kind of surround and help it. And if you think about it for a second, the first SIEM was built back in 1999. And you just think about the threat landscape and what was needed then versus what is needed now, it's completely different. And so this human-centered SOC architecture that assumes that everything is just about how do I -- as a tool take data and show it to a SOC analyst and assume the SOC analyst is going to do all of the work. Well, that's what we've all been doing and that clearly doesn't work, right? You've got tips, you've got NTA, you've got EDR, you've got UEBA, the SIEM, et cetera, all of these tools basically are sitting there trying to show the SOC analyst information so that they can go off and do a whole bunch of manual work. But there's too many alerts every day. Attacks happen too quickly, this architecture fails. And even worse, this architecture has siloed key data. And let's think about this in the form of an example, right? Unusual log-in activity. This happens all the time. This is an example of an alert that the SOC is going to ignore in order to focus on alerts that seem to be higher priority. Here's another example of an alert that the SOC is going to ignore, new application connections happens all the time, gets ignored. Here's another example. After directory access from a new computer, yes, that's just a new employee, right? No big deal. Now privilege escalation, to be fair, your SOC, hopefully, will take action every single one of these. Although by that point, it may be too late. If, on the other hand, you knew that each of these 4 alerts was actually part of a causality event that one specifically led to the next, which led to the next, which led to the next. This 100% of the time is an attack. You know this. This is the power of bringing all of the data sources together and actually applying analytics to this integrated data set. Now that requires a completely different technical architecture than what has been taken in the past. It is for that reason that we built Cortex XSIAM, the SOC platform of the future. Now underpinning this is an architecture that focuses on 3 main aspects: number one, how do we bring in real useful data and stitch it, normalize it, in order to prepare it for analytics. So this means bringing in data across everything in the network, across all endpoints, identity, cloud attack surface and other types of data sources. Now to be clear, this means hundreds of data sources are going to be ingested, stitched and normalized all in an effort to make sure that when we apply our analytics, we're applying it to a comprehensive view of everything that is happening across the enterprise. The second thing is once we do that, we're going to apply analytics to this. Now not just simple correlation rules, but real AI-driven analytics, using AI to be able to detect attacks in real time across multiple data sources in unison. And third, we're then going to use automation to perform as many of the tasks as possible. Now this doesn't mean that people go away. It just means that we're going to elevate the role of the SOC analyst to the most interesting, judgment-oriented, complicated type tasks and analytics and automation is going to take care of hopefully 90%, 95% plus of everything else. This is what XSIAM is able to do. Now behind this then and one of the most important pieces is how do we actually use AI to detect attacks in real time. Underpinning XSIAM, our 1,300 AI models that are constantly running against the data that we're ingesting. In addition to that, we're applying over 1,700 BIOC detectors. These are behavior, indicator compromise-based detectors. So in combination, we're running about 3,000 detection modules on all of the data that we are ingesting across all of these data sources. We then bring in automation and based on the data that we have, the telemetry we have, XSIAM is able to resolve 90%-plus incidents fully with automation. Think about how much time savings that gives you, but also think about how much noise that takes out of the system, so the SOC analyst can really focus on the things that really matter. So this is the underpinning of XSIAM. This is how we are transforming the SOC. Now we've shared in the past how this has transformed to the SOC at Palo Alto Networks. We ingest about 75 terabytes of data every day. But using the analytics and using automation, we were able to narrow that down to a little bit over 100 potential security incidents that need to be investigated by our SOC analyst. And even those 100-plus really are still heavily automation-driven, but with the SOC analyst paying attention to the results and making sure that we've really covered our basis. And so at the end of that, about 94% of all potential incidents are fully resolved through automation. These are incredible stats and how we achieve the MTTR of about 1 minute for high severity alerts, okay? Now that's our SOC. And I've shared these numbers before. And often the question then is, like, hey, that's you. But what our customers be able to achieve from this? Well, this is the area that I'm most proud of with XSIAM that not only are we able to use XSIAM for the benefit of our own internal security operations. But the early XSIAM customers who have adopted this and operationalized it are seeing amazing results in just the first few months of having deployed and operationalized it. In general, they're all ingesting a lot more data. This is a good thing. The SIEMs in the past tried to incent you to not ingest data. They tried to limit the amount of data. It's exactly the wrong thing to do. We need more data. And we've created an architecture that enables that and empowers you to do it. Second, we've reduced the number of noisy alerts, false positive, et cetera. We then couple that with automation for a high majority of the potential incidents such that all of our XSIAM customers are seeing 100% of the alerts are being taken care of with an MTTR that's gone from multiple days down to minutes to low hours and all of them, I believe, are on their way to low minutes MTTR in the future. This is the power that XSIAM is delivering to our early adopter customers. And we just made it even better. With the launch of XSIAM 2.0, we've launched a whole bunch of new capabilities. Some that I'm most excited about, the new command center, which brings new visualization to how XSIAM is providing value to you, the MITRE coverage dashboard, which makes it really easy for you to map everything that XSIAM is doing into a MITRE framework, which many of you use. Third, using your own AI against the data that XSIAM has ingested with our Bring Your Own ML model. This allows your data scientists to apply their logic through Jupyter Notebook to the data we've ingested without having to export it and replicate that data into a second data lake. Of course, you can do that too, if you want to, but this makes it way easier for your teams. Free tech search made it easier to search all the data we collect and we are starting alpha with our Cortex copilot, where we're starting to bring generative AI to the platform to help facilitate the SOC analyst on your teams making it easier for them to navigate the data that we are presenting to them and incorporate AI to helping achieve the outcomes that we're trying to achieve. So tremendous innovation that we're delivering with XSIAM 2.0 and we are committed to continue to deliver these types of innovation in the future with XSIAM. Thank you all very, very much for joining us today for this amazing event. And I hope you enjoy the following sessions, we'll go into more detail on XSIAM 2.0.

All right. At the moment, I know you've all been waiting for. We're going to dive deep into what's new in XSIAM 2.0, some of the new features and capabilities, and we'll give you a couple of demos. And joining me here for this section is Parker Crook, our Director of Technical Marketing. Parker, thanks for joining us.

Thanks for having me, Matt. Glad to be here.

All right. So there's dozens of new features that we've introduced in XSIAM. We're going to preview some of the biggest ones here in this section. I'm going to start with the XSIAM Command Center. This really transforms the way security teams like yours, visualize your security operations. You get a comprehensive view of your SOC operations end to end. You'll see the data sources, the volume of data coming in, the health of those data sources, all in a simple glance and you'll be able to see your case security outcomes and metrics from this dashboard and Parker, I think this demonstrates much better than I could talk about it. So why don't you show us what this looks like in XSIAM.

Happy to. Matt, I'm a big data visualization guy back from my network security days. So I'm really excited to be able to showcase this. We wanted to build a view that could end-to-end visualize engineering through operations at a high level. As you can see, there's a lot of data to unpack here on the screen. As you dive in, you'll see that it's more helpful than a pew pew map as we used to call it. As you can see, we've got an unhealthy data source on the screen here for engineering to look at. And I just want to say real quick, we do have ingestion health, which I'm not going to go into just now, but you can dive into whether alerts are out of normal profiles or there's a major issue with the source. Say, for example, an API key or an API version changed, and we just can't talk to that data source. Moving to the right, you can actually visualize just how much work we're doing in XSIAM with our incident engine, and/or stitching, bringing alerts from various sources together to build a single contextualized incident out of all the related alerts so you don't have to hunt or go looking for the scope of an incident, the platform does all of that for you. Once we have those incidents, you can see the severity as we move over, you see critical high, medium and low, but more importantly, you can quickly see overall the difference between what's automated versus what's manual work in your SOC. And as you introduce more automation into your SOC, you'll see this flow change over time. And of note here is that you can also see how automation can close out incidents or can take the ball and run with it and hand it off to an analyst. So as you can see, this is a great view across the flow of your SOC giving a view across your data that's useful for diving in and understanding where you can start optimizing automation, but also making sure your surface coverage doesn't have gaps in it, and it's healthy. Hopefully, that was exciting to dive into.

Absolutely. Yes. It's amazing how much information we've been able to pack into 1 dashboard, but still made it look very elegant, very easy to consume. Absolutely love it. Thanks, Parker. Let's now move to what we call your bring-your-own ML capability. This is a new feature within XSIAM that leverages Jupyter Notebooks, which is a tool that you might be using to right and share code at the moment. Now let me be clear with this. Out-of-the-box XSIAM comes with more than 1,000 AI and ML models. So it's shipped to you, let's say, SaaS service that's available to you with a lot of great AI out of the box, but now with the bring-your-own ML, we've opened that up. We've opened up access to the XSIAM data lake. So if you have data scientists or a SOC, where you want to do some specific or unique use cases just for your environment, you can do that now in XSIAM through this Jupyter Notebooks integration. So Parker, do you want to show us what this looks like and take us through a demo?

Love to, Matt. Let's dive in. Jupyter apps is an interface for code notes and data in a flexible interface that we've integrated into XSIAM. And here, we can access data easily using our SDK or with a native BigQuery plugin inside of Python. You can also store data in BigQuery to keep your data persistent and you can also interact with incidents and alerts using the SDK. More importantly, you can bring any module code or piece of logic into our platform and can run your own machine learning without having to ship data to your own platform. To help showcase this, I want to walk you through an example threat hunt looking at suspicious power shell activity. So let's take a look. Here, as you can see, I'm installing some dependencies. I'm not going to bore everybody with a lot of the code here. But as you can see, I've got some helper functions, how am I actually going to query the data using SQL. There are some things that we're going to do extracting command lines for my power shell hunt. Over here, we're actually going to extract and do vector analysis and then how we're going to plot. Here, we actually get to -- this is the SQL we're doing for our hunt. So as a threat hunter this is very near and dear to me, looking for suspicious power shell, one thing I can do with machine learning models that I couldn't do before, is be able to look at a broad hypothesis and then look for and group data together and look for anomalies. So one of the things I'm going to do is deduplicate the data. And then as you can see, I'm doing a cluster analysis, and looking here. Now this was my first cluster analysis after text to vector. And then we're going to go ahead and cluster and color code that, and this is allowing me as an analyst being able to dive in here, and I can see a couple of clusters looking at one of them. Here, I see a lot of events that are very similar. So this is very interesting because they're similar in their activity. Moving down as we move forward with our hypothesis, and we iterate on this. Moving forward, as you can see, we've got a lot of results here. The first thing we're going to do is toss out anything that already has an alert. I don't want to waste my threat hunters time on anything where we already have a workflow and an analyst looking at something. So we're going to toss out all of that data and eventually get to a set of data that's left over for information that we didn't know about that came back on our hypothesis. So this is traditional threat hunt to detection engineering, and this is, kind of -- my favorite part of this is at the end of this, even when I'm doing bespoke machine learning inside of XSIAM, I can create an alert for the information we're able to threat hunt with this functionality. So here, we're going to call back on the SDK. And with that data that we just pulled back, we're going to start creating alerts so that the same workflow that our analysts are looking at for the alerts and insights for everything else, we can just feed back into that natural workflow. So end-to-end, very elegant integration for shops that are looking to bring their own or do their own machine learning. What you think, Matt?

That's pretty cool. Clearly, very, very powerful. Again, I just want to reiterate that the vast majority of our customers will use the out-of-the-box AI and ML, right? Like it's more than 1,000 AI and ML models that come built into XSIAM and you can do threat hunting in XSIAM today, but for some of the more advanced use cases and capabilities, very specific niche use cases that an individual customer might want. I'm pretty pleased that we've now opened up the data lake for customers to bring their own ML. That's awesome. Let's shift gears now and talk about the MITRE coverage dashboard. And so this essentially provides you visibility across the MITRE ATT&CK framework so that you can stop guessing about where you have coverage, where you might be protected or not against the latest threat vectors. And you can also visualize when different tactics and techniques are triggered with a particular incident. So Parker again, let's take us through a demo.

Yes. If you know me, and you've heard me talk, you know I'm a big MITRE fan.

Absolutely.

So very excited to be able to showcase this. So we've had MITRE TTP coverage in Cortex for some time now, most notably exposed in our incidence view. But we wanted to take that powerful framework, that same language that everybody is using to talk about incidence and expose, 2 dimensions of looking at that data across your environment. So one is showcasing coverage across your protected surfaces. And the second is building an environment wide view of all TTPs that have been observed. And what I love about this is that this isn't just limited to what our research team is building for you. We're exposing that too, which I'll show you in just a second, but every correlation rule or behavioral indicator in the system can be mapped to MITRE TTPs, so if your team is building custom detectors, you'll see that, that data is represented in this Board as well, which is critical for the modern SOC moving forward. Just going to dive in here, I want to walk you through a couple of pieces. Up in the upper right-hand screen, we talked about surface coverage, as you can see, cloud endpoint, identity, we're making sure that we actually have that surface covered. There are certain techniques that are only viable to be looking at if you have that surface covered. And then on -- moving over to the left, this is kind of what traditionally everybody is looking at is what are the incidents that I've got. And that's one way to represent or utilize TTPs, down below, this is where I get really excited talking about what we've done is that for the tactics, you've got the tactic level visibility for incidents. As you can see, I've got defense evasion, I've got a critical, and I've got a couple of mediums here. And then down here, I've actually also got the coverage. So I've got 1 protection module over here for OS credential, I've got 2 protection modules in 22 detection rules. And I can actually click on that cell and really explore what is my coverage for these, and where we've got intellectual property around our modules, we're just going to tell you the count. But where we've got content that's available, like behavioral indicators of compromise or correlation rules, we're actually allowing you to pivot over to that data and see what coverage you've actually got for that individual technique. Now I've also got a related incident here, and I can pivot over to that incident directly from the MITRE map. So if I want to come in and take a look at what's going on behaviorally in my environment, I've got credential dumping. Well, that's really interesting to me. Let's pivot over to that critical incident or I've got credential dumping coverage, what does that look like? So 2 different sides of the same coin. Very interesting for me as a MITRE tech guy.

Absolutely hugely powerful. Hopefully, with all of the time that we're saving the SecOps teams by being able to automatically resolve incidents and have to deal with so many false positives, they can spend more time in the MITRE dashboard actually improving the security posture of their organization. I think that's fantastic. Okay. We've seen a lot or we have one more thing to share with you here today. And this is a preview, and I'm super excited to give you a glimpse into what we're calling the Cortex copilot. We expect this to be generally available in 2024, but we want to give you a sneak peek here today. So the Cortex copilot introduces generative AI technology underpinned by LOMs or large language models into XSIAM, and it enables you to ask questions using natural language at the prompt just like you would with ChatGPT. So the whole idea here is for the Cortex copilot to assist your SecOps analysts in day-to-day tasks and really accelerate SOC operations by simplifying some of those common and time-consuming tasks that you perform in your SOC. Parker this one is super exciting. We're getting a sneak peek here. Can you take us through it?

Yes. I'm really excited because sometimes as an analyst, you don't know what the next step is and being able to have a way to really bridge that gap is pretty interesting inside of the way that we work in the SOC.

Absolutely.

Let me show you something here. So our goal with copilot is to give you an efficient workflow to interact with data in XSIAM. As you can see, we start by getting an overview with the last 24 hours. And we can also slide this out if we want to work in this flow with a little bit more space, so let's do that. And as you can see, we have historical queries. We've got suggestions on how to get started with copilot. And then something I want you to keep in mind while I go through an incident is that often Copilots are pitched as benefiting beginners, and I'd like to show how expert users can benefit. Often, subject matter experts dive too deep when the answer is right before them. So show me an overview of the incidents in my organization. Well, there's a couple of incidents happen in the last 24 hours. Here's the top incidents. Well, okay, so next up, tell me about the riskiest incident. So let's pull that in. Next up, we can see there's a couple of interesting tidbits here about this incident. Maybe I want to pivot on user. So here, I would take a look at Jeff Darcy, so here, we've got Jeff. Of note, look, we've seen his user score go up 5% recently. He's got a number of incidents. He has only been active on a couple of devices, but he's got a couple of locations, so a couple of things that we could pivot on here. What I'm going to focus on next is let's take a look at the laptop. And here, we can go ahead and see that there's been an incident on his laptop, and what we're doing for the senior analyst is that senior analysts a lot times dive way too deep and do too much analysis and before they get to the conclusion. And here, what we're doing is we're actually pulling out the core part of the causality chain, what is the genealogy of attack, the process is responsible for the malicious activity. And we're calling out what are the behaviors we saw in that causality chain. So this is pretty new inside of Cortex XSIAM. We're calling out, we saw some malicious power show. We saw some possible traveler. So kind of naturally, the next thing that we would ask is, well, how do we remediate this? So show me playbooks to remediate this. And here, trust and validation are key. Historically, with security, we've worried about false positives. Now with AI, we have to worry about false recommendations. With XSIAM, we're providing recommendations based on playbooks that exist in the system, and we're going to go ahead and allow analysts to take a look at those playbooks and even make changes to those playbooks before they execute them. And then even when we go ahead and find a playbook that we want to go ahead and execute to remediate the incident. Once we say run it, we're going to go ahead and say, "Are you sure you want to do this." So we're making the analysts have a 2-step confirmation process because this is generated from copilot. So coming in here, we've got, okay, we're going to go ahead and click it, and the system is going to go ahead and start running that playbook to remediate the incident. Now here's where I'd like to go ahead and call out that everything in copilot has a built-in feedback mechanism. So you can go ahead and validate and have the trust over time that we're going to iterate and get better and better based on your feedback, what's going on in your system. With that, you can see how a copilot can help focus an investigation and give convenient answers and next steps. What do you think about that, Matt?

That's awesome. Super, super cool. Obviously, it's going to continue to get better over time as the system learns and as we learn. I think that's hugely powerful, and I'm super, super excited to see the copilot will become generally available for all customers in 2024, but it's available in preview mode right now for existing XSIAM customers in XSIAM 2.0. All right. So Nir told us about why the current approach to security operations isn't working anymore and what we need to do about it. Lee gave the vision for XSIAM, and we just saw the new features and capabilities that we've introduced in XSIAM 2.0. But at the end of the day, all of this is about us helping you deliver better security outcomes. And now that XSIAM has been deployed at scale by many organizations globally, we're starting to see some of the real-world results, and I want to share some of that with you here in just a few minutes. And let's start with Palo Alto Networks' own security operations center. Of course, we use our own products, and we have XSIAM deployed in our own SOC. And as I'm sure you can imagine, as the largest cybersecurity company in the world, we're heavily attacked. So we're now SOC, we're ingesting on average, 75 terabytes of data per day into XSIAM. And that's being stitched together into approximately 133 incidents per day, 94% of which are automatically resolved using the AI and automation that's built into XSIAM. And what that leaves is our security analysts just have a handful of alerts they need to manually investigate and respond to which means they clear through their backlog every single day. 100% of the incidents are closed out in our own SOC. And the bottom line, this means we've reduced our MTTR down to a minute. And when I talk to customers about this, the first thing they say is, well, of course, your SOC has these great metrics. They're using your own product. It's obviously heavily tuned. And while that may be true, and we have a fantastic security operations center, we're starting to see similar results across our early XSIAM customers. Here, we've got a view of the aggregate data of some of these early XSIAM customers and what their metrics look like before XSIAM and what they look like after they've implemented XSIAM. So from a high level, you can see that our customers are ingesting much more data into XSIAM than they were with their previous SOC platforms. But even though they're ingesting more data, they're resulting in fewer incidents. So fuel false positives, which is kind of counterintuitive because normally when you ingest more data in your SOC platform, it leads to more alerts that you need to shift through in triage. That's not the case with XSIAM. And the high majority of these incidents are being automatically resolved, leading to, again, our XSIAM customers closing out 100% of their incidents on a daily basis versus less than 20% with their previous SOC architecture. And this has reduced their MTTR to -- from between 2 and 3 days pre-XSIAM, to minutes post-XSIAM. And we've got a couple of specific customer examples here. This is a customer in the hospitality industry. And this security engineers said that with XSIAM, they now have more visibility and faster investigations, the seamless data onboarding and automation, and that's a game changer for them. So with this particular customer was very complex, not to mention expensive to ingest data into their previous SOC platform. With XSIAM now instead of ingesting just data from one source, they're now ingesting a much larger amount of data from 21 different sources, but still fewer incidents have flagged and they're able to close out 100% of those incidents and it's brought their MTTR down from between 2 and 3 days to 1.7 hours on average. That's a massive improvement in their ability to detect and respond to threats. We have another customer in the oil and gas space. They deployed XSIAM actually over a Christmas break, and their security leaders said that they are able to migrate their SOC over to XSIAM with just one other person during that Christmas break. And for other SIEMs, it could have taken them months with many more resources to do the same sort of implementation, very quick, very easy to get up and running. And again, the same sort of story, ingesting much more data, flagging fewer incidents, clearing through all of their incidents on a daily basis and reducing their MTTR down from days to less than 1 hour. All of this, the capabilities plus the real-world impact that we're seeing with our customers has led to Palo Alto Networks being recognized in the GigaOm Autonomous SOC Radar as a leader and outperformer. In the report, GigaOm mentioned that XSIAM delivers a comprehensive autonomous SOC solution that scores high on a wide range of key criteria. We're really proud of this recognition. If you want to read the report, you can head to paloaltonetworks.com/XSIAM, and you can download it for yourself. And with that, today's XSIAM 2.0 launch event has come to an end. If you'd like more information about XSIAM, head to paloaltonetworks.com/XSIAM. We've got a new product tour up there on the website, it looks awesome. And there's a bunch of other content that will help get you up to sphere in XSIAM, too. Thank you so much for joining us here today.