Cisco Systems, Inc. (CSCO) Earnings Call Transcript & Summary

Hello, everyone, and welcome to prioritize alerts to minimize impact webinar. I'm Mark Watts, and I'm your Webex producer today. In a moment, I'll turn the session over to Gio, but first, I have a few housekeeping notes to cover. Please note your microphone has been automatically muted, but feel free to ask your questions in the Q&A panel throughout the session. [Operator Instructions] At the end of the session, a survey will automatically pop up in your browser. Please click continue to complete the survey. We really appreciate your feedback. With that, we're ready, so let's get started. Gio, in a few seconds, it's all yours.

All right, thank you so much, Mark. So welcome, everyone, to today's webinar. So today's webinar has actually been prerecorded [indiscernible]. So you'll be hearing from our experts shortly, so let me quickly introduce your speakers for today. The first speaker is Manasa Agaram, who is a product marketing manager for XDR at Cisco. The next one is Rob Gresham, who's a principal technical marketing engineer at Cisco. So if you do have any questions while you're watching the content, please feel free to put it in the Q&A. As Mark has mentioned, we'll be here to help you address any questions that come along the way. Also, as this session is recorded, we will be sharing the webinar recording with you post this session, within 1 to 2 weeks, so you can also keep a look out for that. So -- if any time you have any questions, please put it in. Otherwise, we hope that you find this session informative and educational. And yes, Mark, over back to you to play the recording.

Hello. And welcome to today's Cisco webinar: "That escalated quickly! The story of an alert." My name is Manasa Agaram, part of the Cisco XDR product marketing team. And I have with me my colleague Rob Gresham, principal engineer for product management. Rob and I will spend the next little while talking about the importance of having effective threat correlation and threat prioritization when it comes to an extended detection and response solution. So with that, I will kick it off. So imagine this. You have a smart connected home, everything from your alarm clock to your oven and your door sensors, your vacuum all connected to your network. I have a smart home with a couple different smart items. I'm sure people on this webinar have many, many more in their house. Now when things work, they work. It's great. Your alarm clock will go off every morning at 6 a.m., a little bit later if you're like me and you're not a morning person. Your coffee maker may start making coffee 30 minutes after that. Your toaster could start your breakfast that you've set up the night before. So when things work, life is good. Everything works like it's supposed to. Unfortunately, that's not always the case. Sometimes, your devices, not only are they very smart, but they're also very loud. And they will let you know when something is going off. Now imagine you have 10 devices, and now all of a sudden, they're all sending alerts telling you that something is wrong. Is it my toaster that's broken? How broken is it? Do I just have to unplug it and plug it back in like my IT department tells me to do all the time with my laptop? Or is it something more serious? Is that alert that I'm seeing on one device? Is it connected to another device or another alert that's going on? There's a lot of unknowns, so alerts without any additional insights could be a story of frustration for you. Now that's just you in your home in the morning. Imagine how your SOC team feels when they have something like an average of 10,000 alerts that comes in daily. That is a lot of alerts for your SOC team to deal with. Now let's just say for an example each alert takes about 10 minutes to address. That's still over 16,000 hours needed to address just the alerts that they see in that 1 day. That's not a tenable solution. Even if you had a "24-hour, 7-day a week running" SOC, you would need at least 52 analysts per shift to analyze those 10,000 alerts per day. That is not something any SOC team is equipped to handle, nor is it any -- is it something that we want any of our SOC analysts to have to go through with. That's just too many alerts. Now adding to that, the tactics and techniques that were once reserved for very high-value kind of nation-state attacks, unfortunately, are now being used on smaller businesses, on businesses and organizations that you and I frequent daily, so it's not just about large corporations and countries now that have to watch out for these complex threats, but it's all of us. And it's all of the time, so now our SOC teams not only have to deal with the overwhelming amount of alerts that they see in a day, but these alerts can now be part of much larger, much more complex and sophisticated connected threats, so understanding what those alerts mean becomes much more difficult but much more critical. So in an ideal world, every alert that comes in would be correlated. All common alerts across multiple different control points would be aggregated. Every alert would also be prioritized, so we would add that much needed context for every alert to really understand what that alert is saying, where it's coming from, what it means; and properly prioritize it so your SOC team understands what they need to address first. And every alert then would have a recommended action, so you would know what you need to do, what you need to do immediately, maybe what you can ignore for a little bit longer and deal with some more critical threats, but in an ideal world that's what they would look like. Every alert would be correlated. Every alert would be prioritized and every alert would have a recommended action with it. Now alert correlation and prioritization, unfortunately, is one part of your XDR story that you cannot afford to overlook. Extended detection and response, by definition, by the name itself, means you're bringing in telemetry from multiple sources or multiple vectors across your environment. Now you need to bring in telemetry from all of these different vectors from endpoint and e-mail and cloud and network identity, many more that you have available to you, but you want to bring all of that data in so you can better protect your organization so you can see more of what's happening so you can kind of get a clearer picture of your entire environment. Now unfortunately, all of that telemetry also means that you're bringing in much more, many more alerts, so with great telemetry comes a lot of responsibility. So this can sometimes be very frustrating, when you have a solution that can show you everything you need to know but it's not prioritized or does not provide that additional context that you need to really help understand and then remediate those alerts, so you need a solution that can help you really determine what those alerts are saying and what those alerts mean. Now let's talk about -- for a second, let's talk through an alert. And let's talk about how sometimes alerts don't necessarily mean causation. Alert notification does not necessarily mean causation. So let's take an example. My video doorbell will alert me that my door was opened in my home. I'm not at home. I'm at work. Or I'm at a coffee shop somewhere else, so that's interesting, but just because I have an alert that tells me the door was opened doesn't tell me the whole story. Could it be a stranger? It could be, but it also could be my partner coming home. Maybe he decided to come home early from work that day. It could be maybe a package that was delivered; and my neighbor knows about this, and she knows my security code. She has a key. She maybe just went in to put in that package. It could mean a lot of different things. Second, though, is I get another notification that there's movement inside of my home. So the security sensors inside my home are telling me that there is movement. Again this could mean a couple of different things. It could maybe be my dog. She could be walking around. She could be looking for more food or snacks. It could be my partner again who would come home early. Or unfortunately, it could be an intruder. It could be something malicious happening. I get another notification, this time on my watch, from my ring doorbell saying that the door was opened again. And this is about 15 minutes later, so things are getting a bit more suspicious. I really don't know what is going on. So now at this point, there's been a lot of alerts that are causing me to have some sort of uneasy feelings, so I rush home. I open the door; and I notice that my TV, my artworks, jewelry, everything is missing in my house. Thankfully, my dog is okay, but now I know that I've been robbed. So at every one of those steps leading up to it, we have an alert, but that alert doesn't tell you the whole story. And it doesn't tell you exactly what is happening, so this is an example of how alert notification, just alerts coming into your system, doesn't necessarily tell you what's happening. It doesn't actually tell you cause of what's going on, and that's why you need additional context. You need actual correlation. And you need that correlation to provide those insights, put that whole picture together to tell you what actually happens. So I'm going to hand it off now to my colleague Rob, who's going to take you through a much more technical example of what we said and talk more about how we can add that prioritization to really help address these situations.

Thank you, Manasa, for bringing me in. Now what you're talking about is more like an attack chain. So that's kind of what we've built in our system. And what we want to talk about is how we stitch these things together, right? Attacks can come in different -- at different points in times and processes. These alerts, observations or events that we actually see in the system, [ we record them. And they ] have multiple severities, some of them good, some of them bad. We kind of want to identify how they piece together. Well, when we take it, say, simply from one device; and then we piece another thing, like, say, maybe this is a watch list for a bad domain; and then it comes in and pulls in another connection with an execution, they could come out of order, depending on the tools that are taking the measurements and how long it takes to process those things. For example, it may take a bit for the execution in the process. Meanwhile, the command and control came back fairly quickly. Being able to tie these different attacks together by their commonality and maybe on one device is relatively simple from that single device. However, being -- doing this accurately is difficult because sometimes the network devices don't know what the asset is and doesn't know -- it may only be tracking an IP address. And for example, an IP address from an RFC 1918 address being like [ 192.168.0.1 ] would actually be replicated in a hybrid work environment pretty prevalently because that's the IP address that you have at your home. And it could be any number of addresses on the end, but if you're in a large populous area, there could be some overlap on assignments. And that would make confusion and less accuracy, so we've put in some controls in place on our side when we use our tools to kind of mitigate some of those, but these are the challenges that every SOC analyst has to go through to kind of validate what's actually happening. So when we start talking about scoring, that's where this gets a little bit more fun. We need to be able to add some kind of prioritization process when we build this chain, so we give this alert prioritization, say for this one a 90. And then we turn around and we tie that to a bad domain. Maybe we get 2 hits on this watch list, and that has an increased score of 120. Well, now we've raised that low-level alert to a medium-level alert at 120. And then we had that device execution. And you can see that we've created a high-level alert by correlating these attacks together. Now they could have had -- it's not an attack that happens like instantaneously. It's an attack that happens over time. So attack chains actually build, so you're not going to be chasing the command and control only. And you're not going to be chasing the discovery only, but you're going to actually chase the entire attack. And as you can see here, this was actually spread out between 2 devices. Now if we -- the more telemetry, the more data, the more attacks, but this is just a simple way of trying to show you how we put these attacks together. Now when we take this, we want to be able to apply the MITRE ATT&CK tactic relevant to this particular problem. And this is one example that Cisco uses, not the most accurate one but one example that we use to actually tie these together. On the left-hand side, you see the tactics and the scoring value in a graph algorithm showing the low priority to high priority based on the progression of the attack from reconnaissance to impact, impact being the worst thing happening. Now we know that execution is the predominant thing that we're going to see. And endpoint is the foundation of XDR in the sense, but there's a lot of data that can be gathered around the network and tied together. They actually create -- maybe they're lower signals, but they actually give us more information that this is truly an attack coming into our environment. And then we take that tactic and we'll assign it to an alert sensitivity. And then on that alert sensitivity, we built like a grid, and you can see this here from 10 to 600. And this alert sensitivity is actually scored between maybe some of the network activity but also the host activity and then also the volumetrics of the alerts so that we can actually say, if we get a lot of alerts, then we're going to raise the score up. And that's what I'm going to explain next. So as we take these high, medium [ and low alerts ] that you can see from that first analysis, we can see that it got a score of 90. And how do we get that score? So first, we take the number of alerts that we saw, 3. We tie that to the discovery value as we categorize that alert. And then we take that 3 score, come down to discovery and [ see 10 ] and then times the 10 discovery. And then we actually create a graphical number of 90 because we have 10 plus 10, plus 10, times 3; and that it would equal 90. So what this gives us is a way to actually calculate not only the volumetric side of it but also the tactic side of it and to be able to see all the sensitivity of the alert but also to compress the attack model so that we can keep [ raisings ]. If we kept getting a lot of scans and discovery, then naturally the alert would bubble up as attention. If you had somebody scanning crazily in your environment or, for example, a misconfiguration of a vulnerability scanner, you would see that vulnerability scanner creating lots of scans. It may not be malicious, but it would actually bubble up to a medium or high, depending on the components that it processed. When you see how an alert correlation can be elevated, you can start to see some of these chain IDs and attacks and counts and attack patterns. And what we're doing is we're bolting these patterns together, just like you see in -- the top one was the example, where we take a total number of alerts. We calculate that. Now we use a MaxDiff capability to actually maximize the difference between -- at the top level of what level, so we can take -- it's not just 1, 2 alerts, as I showed in this simple example, but we can take 29 alerts, 100 alerts, 1,000 alerts; and compress them down into a reasonable score that rates across the system but then still raises it up and creates that detection capability. So when we look at effective prioritization, there's a couple of components that we need to add. It's not just the prioritization of that particular alert based on the attack chain that we just gave you. That's one approach and one measure. The way Cisco does it is we not only take that threat correlation and analytics, as what you see here, but we also have a risk-based prioritization that we'll talk to you later in a future webinar. And then we also enrich it with threat intel and context on the way, so there's always -- every time we approach this particular problem, we're approaching it with gradually adding more context and more capability to the alerts so that we only bubble up the alerts that are truly critical to you so that you can use them in -- effectively in your environment and work on the things that you need to work on. What does this really look like? When you take endpoint, network, e-mail, cloud, identity, firewall alerts; and you apply threat intelligence, asset context, user context and MITRE TTPs and then real-world breach data from the kind of security team; and we act on these insights, we're able to create a better prioritization of alerts. This keeps us concise on what alerts are really pointing to value. For example, we know what MITRE techniques actually are part of a $20 million investigation, and those are the ones that we're going to rate the most for you. We also know that all of the assets in your environment aren't important, so we want to be able to manage which assets are actually the ones that you care about and which ones aren't. If you have a development environment, as long as you understand the context that, that development environment doesn't impact your production environment, you shouldn't have any issues, but if you knew that your development environment had connectivity to your production environment, well, then you may not leave that as just a low-priority asset that's disposable that you could rebuild. You would actually want to raise the asset score for that object. So when we look at Cisco's approach to alert prioritization, our main focus is to focus on making SOC teams more efficient. What we really want to try to keep going -- keep doing is making that valuable time. A lot of analysts spend more time validating the correlation of the alert that they've received and then gathering the objects and artifacts that are related to that and then presenting them in raw data because they need to validate what the alert is from and whether it's one alert or it's a risk-based alert that gives them an attack pattern that may be there, but then they have to go back and look at all the raw data and then draw concurrence and correlation to the actual objects. We're trying to bring that summarization and correlation together in one product so that you can focus on what matters most by [ removing ] the things that are most risky to your environment, that cause a breach; and stop wasting time on low-level alerts. Now that doesn't mean we mean that low-level alerts are bad. Low-level alerts are great for hunting in -- capabilities, but what we want to be able to do is -- you need to be able to respond faster, quicker in order to mitigate ransomware environments because every -- phishing is a prime example. If we could mitigate phishing, we would have done it 20 years ago. Unfortunately, we haven't done much better job. We -- I think we've minimized some of them, but have we done an excellent job of just getting rid of that risk to your environment? We haven't. It's still 85% to 90% of all investigations and either start or end with a root cause analysis of a breach, so we want to know that these capabilities that we're bringing forward help you respond faster by giving you as much information and a better prioritize list. Because those 10,000 alerts that the analyst wants to go through, we want to be able to shrink those down to the 10s and the ones that really matter to your environment and keep you from that $20 million breach problem that we talked about earlier. The key here is that it takes a little bit of time. So that's the big difference between that capability going forward. And then being able to create automation that leverages those alerts to actually go in, in your environment and prioritize countermeasures for blocking of [indiscernible] activities or quarantining systems is also valuable to you. And that's also included in our XDR platform, but I want you to keep in mind that relying on individual alerts is not -- that it's not a tenable solution. It's like I said before. It's a good thing to focus on known habits of hunting to be able to go expand. And maybe we're not seeing the whole picture. Maybe we're not picking up a piece. Maybe there's a nice pivot between 2 products and having that capability to 100, but relying on those individual alerts is just not going to be attainable. There's just too many of them. Your SOC teams can't just keep up with the capabilities that you have, so what you want to be able to do is ensure that we're prioritizing the investigation and the response actions that they need so that we have that capability to respond effectively and quickly. It shouldn't be about your integrations. It shouldn't be about what integrations you have and trying to make those work together. It should be tied to the SOC outcomes, what actions that you need automated and not the products that actually drive those automations. And then lastly, there's a lot of capabilities within the network to actually tell the truth and tell you what's actually happening. For example, when you have a command and control environment, we want to make sure that you understand that in the command and control environment there's a process on the endpoint. And if the endpoint isn't telling you that, that process actually fired, there's a good possibility that there's malware on your system or that it didn't catch it; and that's okay. The endpoint -- the whole idea of malware is to hide away from the endpoint. And a rootkit can't inspect another rootkit. The idea is that you're trying to bypass the common observation levels. That's what attackers are trying to do. They're trying to hide in the normal or hide in the basics, but the network, when we look at when you hit a bad IP address or a bad domain, we want -- that's visibility to and information to the asset -- or to the analysts to tell them how this process is going and where they're going. So Manasa, I'm going to pass it back to you so we can talk about our capabilities, if you could please go ahead and bring up that slide.

Great. Thank you so much, Rob. So that was a really great overview, I think, in terms of why alert prioritization is so important; why correlating all of the different telemetry sources is very, very important for any XDR solution. And Rob, you did such a great job kind of taking us through the Cisco way of doing things. So for more information. Rob did mention that we're going to have some more webinars coming up, and we will, but in the meantime, we encourage you to go over to our Cisco XDR website. You can check out a video overview of Cisco XDR. You can actually see Cisco XDR in action. We have a guided demo that's available. So those are some great resources. And we will be back soon with [ another ] installment in our webinar series where we will talk in more detail about Cisco XDR capabilities. So thank you so much for your time today. We really hope you got some great information and some insights out of this. And we will talk to you soon. Thank you.

We'd like to thank you all for attending this event. We hope you found it informative. And as a reminder: Please take a moment to complete the confidential survey that has been posted in the chat panel. It will also pop up in your browser as you exit. So thank you for joining, and have a great day.