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

Hello everyone and welcome to the Art of Defending: How to Build a Comprehensive Threat Response Strategy webinar on what's your Webex producer. In a moment I will turn the session over to Gio Tan, but first I have a few housekeeping notes to cover. Please note, your microphone is being automatically muted, so feel free to ask your questions in the Q&A panel throughout the session. To view the Q&A panel, click the 3 dots on the lower right corner of your Webex window. And 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 are ready, so let's get started. Gio, in a few seconds, it's all yours.

Thanks, Mark. So hi everyone and welcome to this webinar today. So today you will be hearing from Carlos Diaz, who is a Principal Engineer at Cisco, as well as Rob Gresham, who is the Principal Technical Marketing Engineer at Cisco. So the webinar has been recorded ahead of time to ensure a good webinar playback experience for all. But if you have any questions while the playback is happening, please put it in the Q&A. We will be able to get through them through the webinar, or if not, post the webinar itself. With that, Mark, back to you to playback the recording. Thank you.

Today's session will involve a scenario in which 2 SOC leaders are given a task by their CIO. Let's get started. Hi, Carlos and Rob. I'm thrilled to have enlisted your expertise in our Happy Puppies Company. As you know, we need to deliver a comprehensive threat response strategy to the Board of Directors where I can get their approval for the next part of our security budget you'll be leading with your teams. I'll leave you to it.

Thank you, Emma. Well, greetings, Robert, nice to meet you. I joined here before a month ago. I'm a detection engineer and lead, leading part of the SOC. And I'm looking forward to you joining the company so that we can get this important task done.

Thanks, Carlos, for bringing me on. It seems like she brought me on to basically lead and build the response plans and help with the automation of some of our tasks and kind of get as much efficiency out of our products that we have available. So I look forward to working tightly with you to help the SOC actually manage the processes that they need to manage.

Likewise, brother. Welcome aboard at Happy Puppies. So what I wanted to do is I wanted to bring you up to speed in your ramp up and tell you what I've learned in my first month here. And I also wanted to share with you what I believe the task is at it and for, right? Basically, we are going to defend Happy Puppies, and I personally think it's an art of defending against complex attacks. So I want to tell you a little bit about my philosophy, which will be a little bit of theory. I want to get into some practical scenarios of the most immediate trends I've learned in the last month. And then when I can pretty much discuss execution strategy moving forward. What are your thoughts?

I think that really dovetails well with what we're trying to accomplish, right? We have detection and engineering, and then we have response engineering or response and helping the SOC. So being able to understand your theory and then tying that to -- I'll go do a likewise demo on the same capability on what we're trying to do with the security collection we have available.

Great. Let's get right into it. So Rob, look, my philosophy about defending is that I think driving security programs has a unique persona at the center, and that is a cyber defender. What I find unique about cyber defender from other knowledge working professions is that you're essentially like the 911 operators, and they require key decision-making points in order to do the right things to defend. What I've learned in my career as a defender is that it's comprised of 3 strategies: prevention strategies that I put in place to try to be anticipative or enjoy a proactive stance, detecting circumstances or concerns that are relevant to my business, so basically, I need to identify credible concerns, and most importantly, in the event that my mechanism have been bypassing prevention, having enough time to respond and confront the harmful risk that we may be faced with. I firmly believe that it's very hard to scale a SOC in humans, so we have to be very particular and selective about the controls we apply for the worst vulnerabilities so we can defeat the most significant threats that harm the business. That's at the hard what I believe. What are your thoughts about this?

Well, looking at what you're presenting here, it kind of takes me to how we play with our tools, right? How do we make these tools work for us? When we're looking at prevention and anticipating, that means we have to have a good threat assessment and understanding of what our attack surface looks like, also what threats are targeting us. That allows you to create and identify good detections that help us do a better job of defending. Then you're just not taking stock in every miter TTP or tactic. You're basically pulling the ones that are important for us. And then I'm building response capabilities to confront that, whether they're with you proactively in a prevention scenario or reactively in a response scenario of being able to go, okay, I got to investigate this, I got to find it. But we also do threat hunting across the way. I think all of these things are defending in the grand scheme of things. So I agree with you 100%.

So listen, before we move on to the next point, I just wanted to ask you, the role of CTI in this entire philosophy of defending, right? I believe that defending and the usage of CTI has to allow us to take effective actions in the sequence of events or the sequence of an attack as it progresses. So if I design an effective defense status, it relies on visibility, correlated detection so that you can have the best confirmed decision-making power to apply those actions to degrade the impact. Do you have experience with that particular site of response?

Yes. A lot of times we use like, I don't know, call out a friend, right, David Bianco, who uses Pyramid of Pain. We want to move up the top end of that stack. We want to be able to take like cyber threat intelligence and actually hone in on those TTPs and tactics and techniques and not necessarily the IP addresses and hashes and domains that maybe advisers are using because they're pivoting fairly quickly on that. I totally agree.

Got you. Okay. So I think in that sense, effective defenders are those that understand how to put their actions to defend in the right sequences before it gets to too late. Let me illustrate this concept for you in the next slide. See, I think that before we invest in implementing those controls and spending time writing detections, I think we need to understand is how to design an effective security architecture or system. So I read this book by Winn Schwartau called Time Based Security. And what I found in that book is that an effective formula he describes is P greater than D plus R. And that's basically his way of demonstrating a rigorous aspect of saying an effective security system is the one that allows you to have enough time to respond, very similar to like fire rating doors and buildings that can resist heat temperatures or fires, et cetera. I found that to be riveting because I want to show you what I found here in the first month of Happy Puppies, right, with Systems C and B. My initial assessment in the last 30 days has been that Happy Puppies has similar investments to detect and prevent, but the way that they have been operationalized is very little prevention, sort of small balance detection in some areas, but there's constant reactivity. So then the immediate improvement I made was moving them from System C to System B, which is I want to get more confidence detection, but we're still finding ourselves where we are responding significantly. So I'm concerned that the amount of humans that it takes to keep up with the threat paradigm has to really account for what Winn Schwartau describes as buying yourself enough time by first applying prevention.

I totally agree with your use of using Winn's work. I learned it in SANS at a course that I did on Defense Architecture. So I'm totally enthused that we're using technologies or thought processes and methodologies that are just not pulled out of thin air and experience but actually things that have been used and stand the test of time, right? Because we're principle-based in the grand scheme of things. So totally aligned with you on this. I've seen this before, so I totally agree where response actually creates the environment that you're not moving enough stuff to prevention, right? You're responding so much that you're not creating enough detection or enough prevention. You're not doing yourself a service, right? And then when you have too much detection, you're filtering what you can respond to, but you're still not making that piece. We've got to have that way where if we solved for what does prevention equal, it's detection and response outcomes equals prevention. So if you understand that your detection and response gives you a certain capability to react to that object, how do you move that into a prevention? But the question is, Carlos, I've always had a hard time. Maybe you can explain it to me. How do we move that? How do we move that bar?

Okay. So given that you just joined Happy Puppies, I think that there's a contract between you and I, right? You're the R guy. I'm the visibility and detection and prevention guy. So I think the first thing is to understand what is the R composed of. And I basically think response is all about the actions you take on the technologies we have at hand. But to give you enough time to effectively design that, I think we don't need to understand the amount of actions like you can block, you can restrict, you can apply privileged password reset, and like those are the actions. I think that that's an infinite deep rabbit hole. Then what's most important me to understand is when do we use a particular type of actions. Like for example, if I block an IP address during the attack, I think we're back in System C. We're reacting, right? Versus if I know that I can block an IP consuming CTI or some other types of TTPs, but I block before the attack occurs, then I think we're getting to Winn Schwartau towards prevention giving you enough time because proactively we're stopping the threat from progressing. So I think that's the key first, the attack life cycle progression, before, during and after. If we can understand when those actions would put them in that life cycle, then we're able to predict the third column there of the degrading effect we have against the threat. Let me illustrate that for you with a more concrete example on the next slide, right? So because I have an endpoint background, Rob, I'm very strong on endpoint. I'm depicting you here how I leave my endpoint team here at Happy Puppies. In the center, we have the 13 rounds of capability that a computer offers to an adversary. Basically, you've seen from the bottom up the numbers increment. And so if the adversary can basically walk that entire ladder all the way up to #13, they're clearly in a position to cause harm on that particular system, right? But on the left-hand side is these actions that I was just talking about. And I think you need to complement me here, but it's like when do I block? When do I restrict? When do I observe? I offer you a mini cuts example that steals memory credentials. So when I can map out the way that particular mimic has threat, behaves in the operating system with those 13 dimensions, I can then carefully select the actions that will dismantle that particular malware's capability. Does that make sense?

Absolutely. Tell me more.

Okay. So like I was saying, you have defensive actions N plus 1 based on the products you buy. You don't have a problem with the absence of capabilities of products. The problem is the prioritization and when to use those particular actions purposely aligned to before, during or after. So if you can just animate that slide, here's where it boils down to. I'm depicting there for you with the arrows map to the scenario of Mimikatz, you've got to 2 actions. You're either going to apply a restriction or you're either going to provide a detection, right? And just with those 2 actions out of the 6, notice the difference in the column of when back to the attack's life cycle. By applying the restriction against the privilege of users, meaning admin accounts where Mimikatz can successfully read the memory, I apply it before, I'm now backing Winn Schwartau's Time Based Security. We're in the green. We're buying selves enough time. But if I fail to realize that, and I'm just setting privileges doing the incident, this is where the problem of scaling with humans lies, right? And the same will be true for detection. Now what's most important here is that I don't think we want to have Happy Puppies learning through failures. And that's what the introspective side of the degrading effect is. Naturally, we will learn some, but the goal will be is not to make it the main way that we learned, right? So introspective prevention isn't necessarily advancing Happy Puppies towards a more proactive, a more resilient posture. So in essence, this is where a lot of my skill set is going to stop because I'm not a response expert like you, but that's what I'm thinking I need to understand when I give you correlated detections, I want to give you high context visibility, so you can actually tell us what are the response mechanisms we need to use.

Absolutely. So this is where you start talking about countermeasures -- active and passive countermeasures, where we do things ahead of time because we know them -- we, as a team, have to understand what countermeasures are in play actively as the attack is going. So what objects are being blocked, for example, like your previous example of, hey, I'm going to block this IP address. And you're blocking, say, a known C2 IP address. Well, that just tells me that there's malware on that box, that I still have a problem that I have to resolve. I still have an investigation that's required in order to clear the adversary out of the area, I've got to push them all the way out. So there's some more processes like what am I going to do moving into that. Am I just going to start restricting user access? Are they moving sideways? There's different techniques or tactics on the defender side to actually degrade the analysts or degrade the adversary's movement inside our environment. Sometimes when it's a rapidly moving adversary, you want to take out the credentials first before doing quarantining the system. It's an assessment at that point. And I think you've got good idea of where we need to go between restriction and detection. But tell me more how this works with our tools that we have currently?

Yes. Let me actually tell you, I think that what's important is we needed to assess that technology to put this into motion. It has to give us flexible and granular access so that we can take those actions in different mix/match combinations to create defensive playbooks. But at the heart of it, it's got to be the context of the visibility. So let me walk you through the scenario now in how to put the current investments we have. I think here the key is back to CTIs and threat intelligence, is that can't be the main way that we pursue detecting things because I think what you said about Mr. Bianco, I just looked him up, brilliant paper on that Pyramid of Pain. IOCs are just telling us isolated symptoms. But if we're going to get into giving you these response actions pretty much in an expedited way, we have to know how to make sense of those IOCs, how they're interrelated and how they will play out. And that's why in context, we got to understand the scenario. Now one way that I'm going to do that for you is I'm going to take those logs and I contextualize them for you. I'm going to put these things called minor tactics that basically help us get a human rational level of where the key stage would attack R, but I'm also going to be using very specific ways to correlate the objects, the IOCs that you see in there into how they're relating, et cetera. My attempt is to give you a way to understand key sequences that unearth strike paths of what the detectors are telling us because if I can do that for you, then you should start deriving a level of understanding of the threat intelligence that we're consuming. So naturally, if you have understanding, you should be in a position to start evaluating the defensive mechanisms that you can take an action against that threat, right? And so here's the same attack. However, these are the 5 products that we have currently invested with Emma or CIO. We have EPP for prevention, application change control on the endpoint, that's me now, your colleague. We have James over there on the proxy. We have Leandro, who is also working on the EDR. But essentially, we want to know is how to put these products to work against this threat with the right sequence of actions to respond. Like the example there where we're going to need your help is, well, how do I use the application change control to apply meaningful restrictions, hopefully to dismantle the attack early enough. Or are there situations, Rob -- this one is critical for you. Are there situations where we just can't prevent things because we risk outages, but it's meaningful enough to observe and detect with confidence and then hopefully, we can prioritize the review of those alerts and take a response because we have reasonable suspicion. So in essence, these are the tools that were bought in Happy Puppies, and we have deployed them officially today. They're working but where you're going to be very valuable for our team is helping us figure out in that sequence we outlined is the correct one for a credible concern at hand.

In theory, these all works in a perfect world, right? We all know that the data is missing sometimes, and we're missing certain visibilities. When we don't have the right architecture and right capability, what's your recommendation for kind of bridging the gap in those pieces?

When we don't have the right architecture -- sorry, I have [ to restrict the walk ].

Yes.

Well, I think that bridging the gap there is going to be highly reactive when you don't have the architecture until you get it to where you want it to be. But I think in essence, it comes down to applying controls in key areas until you start segmenting other bigger parts of your architecture. Like for example, segmenting appropriately with network, switches, routers, that's a much higher effort until you get to the desired end state. So I tend to take a very data-oriented approach to start preventing heavily on the endpoint, minimizing the opportunity to react, right? Because if I don't protect the endpoint with the high-risk aspect, like viruses, Trojans, worms, then I may not have the desired network segmentation. But if I don't protect the endpoint, these types of threats will run rapid in my flat architecture.

Absolutely. So what you're telling me is that really effective detection can unearth these harmful attack sequences, right? But I need to know more about this whole contextual correlated thing. I have an idea. I could share it with you. Are you willing to listen and kind of give me a thing? Because I'm not trying to tell you how to do your job. But I've learned something in this process of being on the receiving end of content. And the better content -- context you give me is an awesome way for us to progress forward, right? Because if I get the right content, I can react lot faster and stop a harmful attack that's coming because I'll understand exactly what's coming on. And I don't have to hunt through amounts of raw data to go put the pieces back together.

Yes, Rob, let me be extra care with you, brother, as we welcome you here to Happy Puppies. I know how to do the correlation activities in the systems attributes. Where I struggle is knowing what are those things that I need to correlate? So as long as you can guide me there, we're an open book for your wisdom.

Awesome. Well, let me talk to you about like what we think about correlation, aggregation and enrichment, right? Enrichment is one of those powerful things that we can use upfront, but when we're talking about correlation, we're talking about matching those observables together, right? When we do this matching process, it gives us the context that if it's a duck and it quacks like a duck, has legs, has wings, sits in the water, it's generally a duck or some foul thing in my environment for lack of a better fun that I can come up with. But the reality is it will demonstrate something is happening wrong. And then at that point, I need to be able to correlate that with things that are already occurring in my environment. What is the life cycle of those threats? Is it early in their life cycle? Is it later in their life cycle? Are there already alerts already set forward? I need that kind of aggregation through time and status because you may have sent me a high priority alert that's getting low fidelity alerts coming in. And I need to be able to see those additional alerts coming in because that will tell me if I'm effectively doing containment or I'm really horrible at it, which can happen sometimes depending on how well your processes and tools like. You see a polymorphic malware and you don't do good malware analysis on the actual executable. You could end up blocking something that just isn't really helping you contain that incident. And then lastly, we -- I love you, and I really want to appreciate your work and efforts, but I also need to trust and verify. So while you're using whatever enrichment tools that Emma has bought, I want to be able to third-party expert take in other additional context and be able to analyze on top of it to validate those key enrichment capabilities. It's not because our threat intelligence isn't the best in the world, it's more of I need confidence that I'm -- that intelligence is not only awesome, but I can add more value. And then especially when you don't know something, maybe these other tools might give me a little bit of a kick in the right direction, so I can react to the investigation as needed when we don't have all the information that we're looking at.

I think what I just learned through you is that it's more important for me to know how to correctly describe the things that I'm going to correlate and then also how to characterize the things that I have collected so that I can put it in your hands with the right level of confidence, the right level of criterion and the right level of basically understanding. Did I get you correctly?

You get me so perfect. And naturally, you picked me up on my next slide, is basically I needed to kind of talk about this whole behavior characteristics thing. We started with this idea of ABCs of objects, right? A, objects have attributes. They do things. They have a behavior. And then they have characteristics, what kind of object is it. And a lot of times raw data doesn't provide -- it provides a lot of attributes. And maybe it provides some behaviors, but characteristics are lacking, or we need to drive characteristics or context between attaching known behaviors or known characteristics or even attributes together. Like for example, the duration of an attack is the start time and the end time of something, that's a derived behavior. And we -- that gives us context about what's happening. Does any of this make sense to you? Or is this way odd?

Well, let me see if I understand now. Now I got the e-mail you sent me a couple of weeks ago when you were talking about this ABCs concept. So I think I want to understand is that characteristics is the way that we humans in the SOC tend to speak. Like for example, this program is malware or this program is elevated, meaning that RAM would increase privileges. That's important to describe the alert to a human that's an expert in cybersecurity. But what I love the most based on designing systems for prevention and detection is this part you're talking about behaviors because now you're telling me that there's a way to create like a taxonomy or dictionary, you use the process here. But you tell me that a process can create a registry key and that allows me to pretty much see the things I need to prevent for. So it's kind of like I'm having a guided way to understand the requirements as an engineer. Did I understand what you're doing here right?

You hit the nail on the head again. I mean, dude, we're going to have a great time defending Happy Puppies because I think that we're going to just be kicking people out, or kicking adversaries out as much as we possibly can when we see them. So -- but I have a question for you. If this is a really solid methodology and a capability, what is it that you see here when I show you this? And this is a friend's tool that they brought up, and they kind of showed me. And I was like, this is awesome. This gives me the kind of thing that I need to work with. But how do you see it? What do you see?

Well, to be honest with you, I see it's obviously based on the color, I see a very clear emphasis on perhaps what's important in the picture. But the thing that strikes me the most, and not for anything, I start to relate that to your ABCs, like for example, the executed. It's the fact that behaviors are being described there or actions are being described, right? And I think I can just clearly see that this is some form of cyber activity because I recognize Outlook, Winword, and essentially the rest of the chain. What am I looking at here?

Well, if you're an adversary looking for a place to go steel credentials, you would pick up really quickly that Rubius is a kerberoasting tool, right? And that we're losing credentials right here. This changes the game on how I respond with a credential theft against a domain controller or some object. Now I have to start looking at identity. I can't really look at the host anymore. I can't trust the identities that are in the environment that are in this attack path. So it's all the identities that are related to that piece, but it's also did -- was the Kerberoast execution successful? Did they get a golden ticket? If they did, then I got to respond fast and different and very different than what I would in a normal malware-infected environment, if that makes sense.

So having heard you speak in the previous slides, I think what you're showing me here and as a detection engineer lead, this represents the world class outcome that I need to engineer for. Now I understand what you're talking about correlated context. For example, in my world, we have the skill to do that is, I need to track process payers like Outlook to Winword. We have -- we consume today Windows event ID 4688. We noticed that you typically get a process pair. So this tells me that I need to basically correlate process payers to build this path that you're showing. And most importantly, I think just show me the relevance that user identities are crucial in the context of identity, so you know how to take that response action for credentials be installed. That's what I think I now got clearly from what you were telling me earlier.

And again, Carlos, you and I are seeking up on spot every time -- at this point where we're starting to move through this. This doesn't happen in every org, so it makes kind of awesome that I get to find a peer where I'm working together that we're actually seeing the fruits of our labor from visibility driving to detection, detection driving to understanding. So I can react accordingly. But when we look at this, sometimes we've got to look at what this correlated context needs, right? It needs multiple sources. And we need to be able to tie these attack sequences together in each component as we drive along this problem. So whether it's e-mail, DNS records, EDR, NDR tools, this new tool that Cisco gave us called Network Visibility Module or even net flow data, right? And then everybody is like, oh, PCAP [ entered ], it didn't happen. Maybe not. I mean if we can create that context from the data, maybe I don't need to keep every PCAP that goes on. Maybe I just need to see all the pieces together, that correlation that we talked about and pulling those pieces together. So if we say like spear phishing happens, you get an e-mail, maybe it's a good/bad, maybe it's tagged, maybe it's intent from that e-mail vendor. And then we turn around and we see the redirect from our -- maybe it's secure access or even Zscaler or another tool coming into place, and we see that capability. And then it doesn't matter what EDR vendor we choose. Most of them give us process injection, some kind of domain account information. And then we're watching and collecting all the network visibility capabilities that we have in that detection response tool to get system network connections from the NDR vendor, but also that NBM tool gave us that lateral tool transfer, seeing that lateral left to right movement happening on those hosts. And that was powerful because it also gave us the processes that, that lateral movement was using in that 2 pair tool you were talking about, but also it gives us user accounts of the system at the time and what was the process user that was actually using that, whether it's admin credentials or elevated credentials in that space. So if we can take all of this data content, drive into that particular solution, we'd have something powerful. Would you agree?

I would agree, but then I just want to validate here because I'm getting excited about the correlated context as there are many products. So going back to your attribute behavior and characteristics, you only showed us a process application applied to that. Are you saying that your methodology has all the objects for the e-mail domain, the DNS domain, the NDR domain, et cetera, it can scale up to that? Because if the answer is yes, then I feel confident I can take the telemetry, contextualize it with those behaviors, those characteristics, and I can build this particular slide.

I think that we have the context and the smarts and the capability to build this. But I was getting a demo the other day from Emma, which she brought me in on a technical review of a particular product. And I want to show it to you because they gave me like a little click-through thing that I can walk through and kind of show it to you. So I want to show you and see if this really kind of lines up to what we were talking here. So as you can see here, this is an investigation view of this particular incident that we're looking at. And right now, we don't see a lot of context in this piece. And I can move through the object and kind of give you an overview. But when I was playing with it and looking at it, it's an example of a wizard spider attack. And if you're familiar with them, might or ingenuity used them in Round 4 as an evaluation of EDR, so we can see how good EDRs are working and whatnot. And with this particular Cisco XDR product, they kind of showed us this piece here. And I just honed in on this particular one because when I found it, it was a familiar process that we know well, right? It's on d.exe, it was like holy cow, that's a valid process. I would miss that in most detection. So what makes this suspicious to us, and it already identified that it came from users public. So then I'm like, oh, wow, what else has this been used on this system? And the best part of this is that we got the whole attack. Even if I drift down -- I'm sorry, moving up -- if I drift down to the bottom here, I can see the whole entire attack time line from end to end over the period of what has happened. And I was like, okay, this is pretty awesome. Now the question is that can we feed our data into this product, get it into the right way so that they can actually ingest it and produce these outcomes. But I needed you to do a technical assessment on it and make sure it's actually delivering the results that we see. Does this fit in the same methodology that you have that I have?