Good afternoon everybody. It is September 16th, 2024. We're on episode one of season two.
First episode of season two of the Security in 45 show. Now in season one we delivered 11 different episodes on security,
industry topics, and some Cisco specific topics obviously. Now season two is going to be a little extra special
because we've added a live demo after each conversation. So for example, today we've got Matt and Brianna will be joining in a little bit here
and that's going to be on a conversation on XDR. Tomorrow though for the follow up we'll see what XDR looks like in a live dashboard.
So each month we'll learn about the topic and we'll get to see a live demo the following day. I think personally it's a great way to get some foundation up front
and then kind of see what we've learned in action.
Yeah, yeah that's going to be exciting. And actually I'm more excited because you know we're going more mainstream and we're calling it season two now.
You know it's going to be super interesting. All our episodes are already in our community page so it's going to be interesting.
And of course today we brought back Brianna and Matt as we did last year. Was it last year? That's crazy.
Yeah. It doesn't seem like that long ago. I know it was all the way back in last October. Can you believe that?
Almost a full year. Seems like yesterday. Yeah I was going to say happy birthday.
But no it was an awesome episode. If you guys want to go and check it out it's on the community page.
We're going to make sure that once we post this one you will see like a link to the previous one of course.
But again I know we're waiting for Brianna and she's going to be back here in a few.
But Matt let's get started with you if you don't mind introducing yourself to the audience one more time.
For those of you that missed me last year, Matt Robertson, distinguished engineer here at Cisco. I focus on our threat detection and response strategies.
Specifically threat detection. We see a lot of our analytics stacks.
That's great. Yeah well definitely two of our favorite all time guests so we're super excited to have you back on Matt.
And like we mentioned Brianna may be joining a little bit late but we've got Matt here and we'll go ahead and get started here.
So Matt it was in October last year when you and Brianna were on the show and at that time you know XDR was one of the hottest topics in the industry.
We heard we're talking about a lot within Cisco and then outside of Cisco. You just googled XDR. What is XDR? And it was an industry changer.
Has our industry changed its perspective on kind of XDR? I'm curious. You think it's in higher demand? Is it cooled down? What are you seeing in terms of XDR and Cisco XDR over the past year since we met?
Yeah so yeah going way back in time to what seemed like yesterday. Basically it's when we were talking XDR. And so like a year ago we had just launched Cisco XDR.
Been in the market for a few months at that point in time. In that year it's been I mean demand has been fantastic. Cisco XDR is a very fast growing product.
We get requiring new customers and you know Chuck in the last earnings gave out some number of the wowing for a lot of customers. Keep growing. Keep growing. It's great.
Now you know what's changed in the industry? If we look back a couple let's go back in time two years yourself. XDR was one of the most nebulous terms. Nobody knew what it was.
You ask. I joked back then about two years ago. It's like you ask five people what XDR is. You're going to get 10 answers.
There is no consistency anywhere on what XDR is. We at Cisco kind of put our flag down and said XDR foundationally means collection of telemetry for multiple sources.
The application of analytics to telemetry to arrive at a detection of maliciousness. And then response or guided response to that maliciousness.
And that you know that definition it works for us. It's definitely working in terms of adoption of product that's resonating with our customers.
We also made at Cisco the two really foundationally different strategic decisions that derivative from that foundation definition.
The first strategic decision that we made was that Cisco XDR would be an open ecosystem. Meaning we would integrate with third party vendors that would otherwise be considered direct competitors against point products inside of our ecosystem.
Really, really good examples and ones that we are heavily integrated with are CrowdStrike, Vulcan and Microsoft Defender.
Arguably, those are direct competitors to Cisco Secure Endpoint. Both are EDR. All three of those are EDRs.
The question of do we need an EDR? Do I need Y Secure Endpoint if I have CrowdStrike Vulcan or so on would be tricky questions.
However, Cisco XDR made the foundational definition that we're going to take telemetry from all of them, regardless.
And the second biggest thing that we did strategically was in some ways this is just building on our strengths.
We decided that network data was as foundational as any endpoint data to an XDR. Many XDR vendors really are just endpoint vendors that they've added a new telemetry source to.
Extended their endpoint detection response product so to speak.
Cisco XDR network data is as foundational as any other data set. As foundational as endpoint data.
So we actually consumed index here. One of our NDR products, which was Secure Cloud Analytics at the time, was consumed into the XDR technology stack.
So that natively we take in flow data from networks, we take in flow logs from AWS, GCP, and Azure, and we do analytics and correlation on top of that. So even if there is no endpoint data coming into Cisco XDR, it's still providing threat detection capabilities.
And then when you combine these two fundamental decisions that we made, this is where Cisco XDR is seeing substantial traction is in the correlation of endpoint network data together.
When we look at network flow data, network logs, metadata extract off the network, etc.
There can be a lot of it, and it's really comprehensive, and it's really complex and comprehensive, and a lot of work for a lot of security operations teams to collect and analyze that data.
Cisco XDR has made it much easier for the lean IT shops to consume a network protection response product that they previously weren't able to do so.
And adding the correlation of endpoint data on top of that to be able to say this host that had an endpoint agent on it and connected to this other host that then began to scan the network and then large amounts of data was actually traded off of this other unmanaged
IT asset is substantial to a lot of our customers. Being able to track threats across both managed, unmanaged assets, IT, OT domains, etc. Just bringing that data together has been incredibly valuable to our customers.
I love that. I have so many follow up questions on that. First is, I like that we have defined the definition of being about more than the endpoint. I really do think that's important.
Because the threats, they get more complex, and they're not just specific on the endpoint. So I think that extending our visibility beyond just the endpoint, as you mentioned that, like into the network, the cloud, is really should just be a requirement.
In my opinion, if we're going to call something XDR and we're really going to be looking at threats, why aren't we looking at where the threats actually live and stem from?
So I think that's great, our definition of that, of the endpoint and enterprise-wide. How is the third party, the vendor agnostic approach, playing out? Do we actually find a lot of Cisco XDR users that really almost have majority third party non-Cisco products?
Absolutely. We do see that. There's a lot of people out there that have Microsoft E3, E5. It's pretty common. The question that we often get is, people started trusting Defender and Microsoft in ways that they previously didn't.
And it's just like, I have Microsoft Defender. What does XDR add to my deployment?
I was just actually talking to a customer a couple hours ago, they're like, we have Defender, we're looking at what we can do to add and enhance our security. I'm like, well, here's XDR. And it comes back to the correlates of endpoint network.
So we looked at any end, for XDR, we're extending any endpoint. We treat Defender, Falcon, Cisco Secure Endpoint, they're all the same to our analytics stack. They have data, they have sightings. We map the data that comes from them to the MITRE tactics and techniques that come in that log data.
We map that sighting to a endpoint binding by MITRE tactic level. Then we correlate that to network sightings that we have for the same endpoints involved.
That's where it really comes in and adds a lot of value to our customers. And we see a lot of our customers, probably the majority, that are not actually using or not full stack Cisco shops. They're always adding some third party integration into their XDR.
I love that. Yeah, because we've got the one common enemy is, you know, the bad guys, the attacker. And I like that we're taking the approach of, we'll fight that battle together with you, with you Microsoft, with you CrowdStrike as we work with what the customer has.
Excellent.
Yeah.
And the approach we have for getting a look at the network telemetry, that's really very powerful, I think. Now on the same line, talking about network telemetry. My next question is, do we have any newer type of telemetry sources that we can integrate with XDR?
If you can share some of that, Matt, that'll be awesome.
Yeah, I mean, we're continually adding new integrations every quarter. You know, we do a commit, we do our evaluation, we're always looking at new telemetry sources you can add.
We've added a lot in email over the course of last year, started with email throughout the fence, we had a proof point, we added it with 365. One that I'm very, very excited about to build on though, is one that it's in beta right now and I've been talking about it
during webinars, conferences, etc. for the last couple months is the integration between Cisco XDR and Meraki.
That integration has been in years in the idea state, execution state. A friend of mine at a bar once Cisco Live many years ago, or like, you know, it would be amazing if we were to integrate secure cloud analytics at the time, and Meraki.
There's been a lot of evolution in that timeframe.
So what is in beta right now and I'm really very excited about. First, there's the XDR Meraki integration and partly I'm excited because I mentioned, firstly the network component of XDR, but also just XDR is doing, and it's really excels in a lean IT
environment. The exact same customer profile that many Meraki customers are cloud native or cloud, cloud managed network we're basically bringing cloud managed security operations centers in the form of security operating in the form of Cisco XDR.
So I coined this term snark, the snark security and network operations center together.
Absolutely I want everybody to do it, you know snark, that's, and that, and that really is Cisco XDR and Meraki and what the integration that we've done, XDR Meraki comes in multiple, multiple levels.
So the first level.
And this is actually available to anybody that has both products right now.
And you can enable enable a beta feature in the, in the dashboard UI. And that's the UI integration between XDR and Meraki and you know using an OAuth token single sign on, you can integrate dashboard, Meraki dashboard with XDR, and you can in Meraki
dashboard view and work an incident
from XDR. So you can go to the organizational wide security center you can see XDR incidents and you can look at, and it will show you the, and all of the detections that are in XDR, and you can actually like assign the sign the user, change the state you can
actually click on it and you get begin to interact with the incident, the exact same way with XDR UI.
And it's the same data set so you can actually be, you know, arguably, you can actually work an incident cradle to grade, so to speak. And that's more like a sign close open, look at, right, take immediate action from the dashboard UI and never actually go into the XDR UI.
But if you really wanted to do the security operations workflow, all those details in the XDR UI. So basically, you start in the network operations UI dashboard, click on it.
And then the incident takes you over into XDR UI, and you can then work fully do the investigation and response to, to add incidents that's the first layer of integration on Brianna has joined us.
How are you. Good. Thank you so much for coming on. We were just bragging about how Andre's and I were bragging, how we were able to get two amazing guests to return so this is just outstanding.
Yeah, I'm always excited and honored when I get to talk with Matt at the same time and we're so thankful that you invited us back we love this this series.
Glad to have you.
Awesome.
Yeah, I was actually just talking to the rocking gration so just covered the UI integration and the really exciting feature in beta right now. The beta feedback that we got from customers this morning so far it's incredibly positive. And this is a direct to cloud upload of blogs off of the Meraki MX.
So, you know like Marakees orchestration capabilities, the ability to go in and, you know, configure formally NetFlow on all of the network devices was already one of the easiest deployment mechanisms for a network centric or network monitoring technology
available to go into dashboard say configure your NetFlow collecting destinations, click deploy and dashboard would then configure a NetFlow export to any to a collection system to from every available switch for in network that could do NetFlow generation.
Now what we've done with the MX is one step further without requiring an on premise collector. You can go into dashboard say export data to XDR, and it will send direct to cloud all of the flow data from the MX is direct to
the XDR. So, firstly it goes into Marakee cloud where we read it off of their off of Marakee cloud permissions need to be maintained obviously and data, data residency, so we read it off in Marakee cloud or the dashboard or into XDR, where we begin the analytics,
the as a deployment mechanism it is phenomenal.
It's a wonderful way to deploy a network detection and response product on the planet. And this is really really relevant for all of our customers that are in say a retail scenario, where you have a lot of branches.
Many of them are MX maybe MX, MX, or you have an MX and MS or an MR kind of running your branch, you can easily get a an entry point network detection response product, single click from your armchair, not going on site.
It's a super awesome deployment, the direct to cloud, I mean I'm blown away just because it is art you know I've been at Cisco for close to 17 years now, and this is probably one of the best product to product integrations I've ever seen the user
experience is seamless between the two, the ease of deployment is phenomenal.
And there's one more thing. So I've covered, I've covered like two really super cool things so far.
Yeah, I've spent in my 17 years most of that has been in what is now labeled as the network detection and response market.
In the network detection response market.
In those retail scenarios that you know I pointed out and this is common with a lot of people have like branch offices.
So you have an overlapping IP space issue, where somebody has designed, let's say you have 10 branches they all have the exact same IP space.
Right.
And if you let's if we pick on, you know, rocky as the center called here, 192.168.128.0.24. That's the default space for every MX internal network so you'll say you have a lot of that right you know 192.168.128.10 is in 10 different networks.
And if we were sending that flow data to an analytic system, we would have a lot of trouble differentiating the 10 different instances of 192.168.128.10, we would have a problem and we'd be behavioral profile, all 10 as one device.
This is a problem that any network detection response product has in the world today. However, we have solved it in the XDR rocky integration this is like a P equals NP scenario.
Like, like, this is like an otherwise unsolved problem. And the reason the way we solve it is when rocky is that MX is are exporting the telemetry direct to the cloud it includes in it, the namespace of the device that sends that data serial number of the MX basically, and the
network that that data comes from.
We use that in combination with the IP address to uniquely identify the device.
So that we are now going to profile all 10 instances of 192.168.128.10 for the in 10 different ways like for all unique instances.
This is a otherwise unsolved problem that is now solved. And so for those, those, those branch scenarios that we were just talking about where you have 10 different instances
that IP space where you previously couldn't even think about deploying an NDR not only can you deploy an NDR.
It will work the way you want it to work.
And you don't have to leave your armchair.
And we'll be able to. First of all, I love the lead up that I felt like I was like in a preview of my favorite movie that was awesome. But, yeah, so you'll be able to then have separation and kind of observe the different segments of your network, which you previously
did based on serial number, which is unique. So that's I love that way to solve that problem.
So exciting. So exciting.
Yeah, maybe like two little things to this for our viewers, it's really important for you all to know that Matt is one of our distinguished engineers is a champion of this effort if he didn't already call that out.
Because it means that somebody who has the technical breadth and expertise of our solutions throughout enterprise networking, security, collaboration and beyond and an overall understanding of the gold strategy of the company is able to take all of that background history and understand where we've had really positive experiences for our customers.
And then there's ones that are not so much bluntly. Matt and I have heard multiple times and been guided by a lot of our field team members that both customers and partners feel that Cisco isn't always doing the best job bringing their solutions together.
Like, like, it's not the same company sometimes. So this is one of the key things that Matt called out and wanted to make sure that we were considering in this effort is how simple is it? If it was already simple, can it be easier than it was prior?
And do we look like one jointed company when we bring this together in addition to solving amazing problems? Like, we can't easily identify what network this traffic is coming from and we have duplications of 10.10.10.2, which isn't very helpful at the end of the day.
So it's really a meaningful showcasing of how Cisco is thinking about the user experience, about how Cisco security and the Cisco platform brings experiences together for our customers and thinks about that. Not just in each of the caveated spaces, like networking, security and collab, but across the board.
Well, that's awesome. I found a way to do it simple too. Like, you can count going back to the lean IT team. That's an easy way to solve a complex problem.
Love it. All right. So, Rihanna, what about, can you give us, okay, since you were here last October, we're trying to ask crazy, it's almost been a year. In terms of the responses, I know one of my favorite things about XDR is the responses that we can take.
The visualization is crucial, but what about the responses we can take? Any new responses maybe since the past year, like additions to XDR that you'd want to point out?
Yes, absolutely. I'm going to call out a couple things. So, first off, very short part of the answer, we have added many integrations from individual solutions for response and actions.
A lot of that is really dependent on the API of the solution, but that goes back to why it's important to have agreements with these different vendors that you're looking to integrate with so that if something is found to be potentially lacking slightly, not in a negative way, just a factual way that you want to use, you can go back to that vendor and say, hey, listen, we really want our solutions to work best together for the outcomes that our customers are looking for from both of us. But things like extra hops, speaking of NDR solutions, we don't just support that.
We don't just support our own things like extra hop things like dark trace things like Microsoft 365 for email things like I'm forgetting now. I know there's so many more that it's actually going out of my mind.
I'm like, but we've added a lot of just API integrations for responsive actions in general in our guided responses. And then it's important how that feeds into the guided responses because you don't want to just provide something that's flat for a customer. It needs to be meaningful. Can they use it?
What are you providing for that usage in an incident response? So, every time we think about these response integrations and integrations in general, they're really forming categories. We think through it's the detection and correlation and an incident analysis piece.
It is the responsive action. It's things like hunting and searching and asset context. And then how does those work together? So, what sort of guidance would I provide for an NDR solution or an email security solution?
Would that be a quarantine and email? And how can our analysts use XDR to kick off that workflow without having to pivot out of the solution or know any code or know any actions to take to do that just based on what's in the incident.
So, that content comes built in that workflow capability comes built in and then to progress that even further, we have customers and we have partners who are powering things like managed extended detection and response services with Cisco XDR.
Who might want a customized version of that? Maybe there's a tool that's not a security tool like an HR business tool that they want to take action in when they see a wider event going on.
Will Cisco may not build that integration because it may not be something that's relevant for all security outcomes, but our customers may want to do so. So, we have the option to not only build the custom integration for our customer, build custom content to go along with that.
But 2 super cool things they can take that content and make a customized guided response playbook now for their incidents. They can make more than 1. If they want the default to be different than the 1 that Cisco provides, they can set that up.
If they want to use the default 1 plus some customized ones, they can set triggers for when certain playbooks would apply and show up for the analyst in the incident. Something like this looks like ransomware.
Please show our Brianna's or ransomware response playbook in there to guide them through the actions, including those that may not be built into Cisco's default. So it provides a lot of that flexibility.
And especially for partners who may have lots of things they add into their service that go beyond incident response and management response. It provides that flexibility.
And then the very last piece of that is we also opened up the automate exchange, which allows us to have people developing content that they would like to share with the world. So, if they've come up with a really cool workflow.
And they want to share that for somebody to use or duplicate for their own custom version. We have community and vendor items and partner items that are shared on there in addition to Cisco built in ones.
So a lot has gone on around response because as you know, we like to say response without detection is impossible and detection without response is completely insufficient.
That's right. A quick question about the automate exchange that you mentioned. So it would use case of that be like one customer that creates some cool playbook and then that's able to be shared with another customer in the end or?
Yeah, it's actually broken down a layer below Mike. That's a great idea though. Right now it's the individual workflow. So it's not necessarily a packaged version of multiple workflows put together as an entire playbook.
But that's a really good point that maybe we open up moving forward so that it's not just individual workflows. I think he just gave us a product enhancement idea and somebody can say not only is this a workflow, but it's an entire ransomware playbook.
And you can go ahead and package it and put it out there. But I just want to call it like what I'm most excited about this on is a lot of times we get asked around the difference from XCR compared to a sims, especially in recent months.
You might know why we get that question and then also how it's different from an orchestration tool like a sore or even an EDR solution because a lot of experience are built off of that.
And one of the things that's very differentiating for us is we typically are not requiring customers to build any of the detection and analytics content. Any of the responsive content.
But sometimes we think that gets misconstrued. Does that mean that you can't do anything flexible with an XCR? No, it means we limit that and we restrict it because our goal is to do that for you.
But if you do have some special needs or customized needs, you can do that. And then if you create those, you can now share them with the world to save other people time and money by sharing it on the stage.
I'm glad you pointed that out. I think that's one of the biggest questions. I know we talked about that on October before, but XCR versus a sim and what's the difference there?
I like, Brianna, that you were pointing out the work that Cisco does with the other vendors in the background to make sure that this integration is seamless and saw some hack sim and found a way to make the end product work magically, but hopefully they don't change anything on their end or it'll all break.
So good call out there.
Yeah, that's always good. And the other thing that I'm really liking about this, what you mentioned about the automated exchange is that there's a huge sense of community within Cisco and people that work in Cisco equipment and software and things like that.
So you guys know more than anybody that the community behind Cisco is huge. And there's always somebody helping each other or helping somebody else. It's really good. I like that.
Yeah, and speaking of small sims that might have been acquired like Splunk, plus they do so much more, of course, but they have a great community. And to your point, Andres, Cisco has a great community of customers and partners in that network.
So we're so excited to continue down that model to learn from each other as to what could improve on any of the portfolio sides. And we did have the exchange idea prior to the acquisition, but it's just a great way to continue to foster that.
And hint, hint for everyone, two quick things. Like Andres mentioned, a lot of that content comes from Cisco people. I have my own product manager who owns the entire automate piece for you in XDR.
I think he's the top publisher on that exchange right now. So you're getting real quality content from people who know the product, even when people are publishing it in a community model.
And then also we're thinking of a same or similar model with integrations. So right now this is content only for workflows, but we are looking to be able to have people submit custom integrations that could potentially work.
We just want to be really mindful of that. So for the audience viewing, if you have any thoughts or ideas, feel free to share them with the teams that you work with in Cisco. We don't want content and information to get stale.
That's not helpful for you. A bunch of debt integrations doesn't help anyone on an exchange. So that's really more of where we're being mindful about the process, but that is on our target plan as well.
Pretty cool. Pretty cool. Nice. So a lot of info for everybody here, but I do have the next question and that's for you, Matt.
What about the way that we're communicating with other products? And I know you mentioned some of them, the endpoint detection, cloud, email. How are we pulling those alerts and responses? Is it everything based on API or how does that work?
Yeah, everything is where possible API based. The majority of the integrations that Cisco XDR has is API, cloud to cloud API is the most common thing.
In the absence of the ability to do cloud to cloud API, we do, for example, for network data, NetFlow, for example, which doesn't really go cloud to cloud other than case BMX.
We do have to put an on-premise data collection BM on from to collect data from the internal network where it is then sent up to the cloud via that link from that BM.
Most, yeah, like our public cloud integrations are a really good example. Again, all API, just native. In the case of AWS, just create an IM account or role for XDR.
It will then have the permissions to read off of the S3 buckets designated to bring in that floating.
That's good, I think, for everybody hearing because everyone is most of the products customers are using are API enabled in some way. So that's just such a nice good answer to hear.
And I think that speaks to the simplicity of integrating things with Cisco XDR just because API based.
It also it's it's native to those solutions when they start out in a more SAS based model, or they are the SAS or the I. S. So that's really important. And as, as I think that just mentioned, it's reduces other architecture that might be required normally, like sensors and other things.
So we know that, especially for organizations that don't have the resources to manage, maintain and deploy all of these things, they may not even be able to pay a services provider to do so anything that we can do to help reduce that effort to get data into XDR to configure how that data gets into XDR.
So that's really, really important. And I think that's really meaningful for us and not to go on about this, but maybe to tie it back to the previous question. You heard me mentioned that with responses were using APIs as well.
So, one of the really cool things about XDR very similar to what Matt was saying about Morocco is you come in and you configure it and then any and all integration capabilities that we have either today or come moving forward should work with that configuration.
And that would certainly make customers aware of that. But right now we're gathering pretty much all of the information that we need. And then when feature functionality changes or comes online or an API changes, we can inherit that and we can make those changes on the back end with our development agreements for customers by default.
That's awesome. How about in terms of, you know, we've got all these alerts like thousands of alerts coming from all these different products or endpoint products and that maybe they're coming from like a Moroccan mechs, but you know hundreds thousands of individual alerts.
Cisco XDR of course is doing simplifying all that into a single incident of everything that's related into one incident. But how did the you know when I look at the dashboard I see a real nice list of prioritized incidents and it's very clear the ones that are the most severe and the ones that are most of value to me to go ahead and tackle first.
I think they haven't already been tackled in an automated way. But how does Cisco XDR know which incident is more serious than than another?
The advanced analytics that are applied on it is really the key there. So when we think through this, we first think about what is it that defines an incident in the first place and maybe like a really simple example.
So, let's say that a mass system had a detection on it and the solution in use by his organization was able to detect that. Let's say it's a process injection. Does that handle that event? Did it stop and block or cut off the process injection?
If so, do we see any other events that would subsequently have happened or happened before that related to mass device as a first piece? My next question, if I were following like a logic path or a playbook of we would call this a detection playbook manually in a security operations team would be to say, well, did Andre's or Mike's or Brianna's system have same or similar detections? And if so, is it in the same time frame?
Then I would try to look across all those other sources that you just mentioned, Mike, right? The end point alone is not sufficient to understand if there's something happening across my environment. What if Matt's system is restricted, but Andre's is open and so his is allowed to make the communication out.
The EDR is only going to tell me so much about that, but things like my proxy or my SASE or the network communications or my public cloud integration, if it's calling out to some sort of public cloud environment, might be able to tell me that.
So we would call out to all those other sources and basically we are running the same logic as one would run in a detection playbook except for I like to say that kind of like Professor X in Marvel's X-Men, we have the power of Cerebro behind us.
We have something that can process this consistently, update it consistently, learn from it consistently. So it's not a manual process of somebody going through it.
It can be a set of steps to ask some questions, get answers and make decisions. But there's also a lot of data science behind that with things like AI and machine learning of various different types of models and all different sorts of capabilities, including
generative AI, not in the chat style model that we all know it so well, but in what it would do to process data in the back end. And that helps us do that analytics, that correlation together, which allows us to first determine is there even an incident?
Then we get to a lot of what you were just saying. Well, if there is an incident, how do I figure out the priority of this compared for one to the other? And within the incident, how do I guide the person action based on that priority?
Well, if on math system, the ADR cut it off, that might drop my priority a little bit because it handled it. But did it handle it on Brianna's and Andres and Mike's system? If the answer is yes, do I even push the incident to someone to see?
Or do I let them know, hey, your ADR did a great job. We're going to let that happen on its day and there's nothing for you to do. If Andres's system, as we talked about, was able to continue the attack, well, what sort of access does Andres have in the environment?
Same way that something like a SASI would be looking at what access it would give Andres based on his authorization, his role, all of those sorts of things. So what access does he have? What data does he have access to? What loop is he in?
What data of what classification level is stored on his device? And I'm not saying we have all this in play just yet, Matt. I know we're working on some of these, but the idea is that this is how we would figure out where the asset comes into play, what actions might have been taken on the systems and where they might not have.
Even looking forward to a threatened, warmed defense model, which is based on what I see, what's going to continue on with this threat? What would the next steps be? And if so, are there any vulnerabilities on the systems that could be exploited by the life tactics and techniques?
Aligned to the MITRE ATT&CK enterprise that would be in play. So it's a lot of analysis and questions and answering, but imagine if you had to do all that manually across multiple sources, even if they're coming into one place, not only do we feel that that is inappropriate in 2024, you shouldn't have to do that, but we want to be the ones learning and growing from that so that we can put that information together.
And then if that information that allows us to staff rank and priority specifically today based on the tactics and use and assets, we want to grow those variables more so to better understand how we can prioritize granularly for our customers.
Gosh, I can't believe we used to try and do that stuff manually like this human. That's so insane. And I knew that it would tie back to X-Men in some ways to do something that powerful. You do need the X-Men.
But I think that answer we just described is kind of XDR and the reason we really need something like that, because to try and do all that manually, there's no way we're going to catch these threats that are hidden as well as they are, especially the math point earlier that are in the network somewhere.
They're not even on the endpoint, but piecing all of that together manually. Oh my gosh.
And then the last call out I had for that one would be, you mentioned the MITRE ATT&CK framework. So I think that's important that we are basing the holistic approach on that. It's important to your point for modern day analysis.
Excellent.
To me, the Marvels reference just made it best.
Something we can all relate to.
That X for XDR, right? Like we bring it all together. I mean, personally, if I had like a Wolverine to just slash all my attackers and maybe give them some choice words, it would be pretty good for my stock. But we have to first analyze what Wolverine's supposed to slash, even though he's willing to go attack anything.
Now, is Wolverine Canadian? Matt, are you Wolverine like behind the scenes?
He is. I mean, he is Canadian.
It's Matt behind the scenes.
Oh boy.
We owe you a return. Next time we come back, Matt, we have to have some sort of picture, whether it's like AI generated or something of you as Wolverine.
You have to put, so now the question becomes, you'll have to tell us offline. Do you want to see Matt as like cartoon and comic Wolverine or like Hugh Jackman Wolverine? You'll have to decide. I think he can pull off either, personally, with the most, with no offense, or either way.
Totally. He could pull off both of those. Yes.
Nice, nice, nice. Matt, I have the next question for you. This one is interesting, but do you have any like any good use case of example, you know, without, you know, revealing too much, but just talking about maybe a customer that has seen the power of XDR, maybe somebody that has seen
the value right away, if you don't mind sharing.
Yeah.
So, I've talked a lot about network.
So far, and it is really common, I've seen a few of these in the past where it's like a customer has a repetitive outbreak, where they, you know, have the same piece of malware happens over and over and over again, they keep finding, you know,
an infected host, the EDR keep lighting up saying here is a, now the same piece of malware is here, they take it, you know, remediate that off of that host and they keep seeing it over and over again.
The, done this several different times with customers.
The last one, not too long ago, where they had seen the same, same piece of malware over and over again.
And we added in the network component, and it very quickly correlated this outbreak of malware based on network activity to a basically, in this particular example was an unmanaged network attached storage server that had been infected and this was basically patient zero.
They didn't have an endpoint agent on it and no matter how many times they cleaned up the infection off of all of the different Windows devices that the endpoint agents were on this particular piece of malware kept repetitively spreading across their environment.
And we've seen this, I mean this goes back years I've seen similar scenarios but the
way that we do the correlation today, which is pretty net new in XDR is makes this particular scenario resolvable very quickly.
Just be able to correlate a fact that you know a infected host that has an endpoint agent on it that said this particular piece of malware based on the hash value is on this host and has this network connection to this server.
So this server has a network connection to many different hosts that also have the same piece of malware on it really quickly puts that story together in ways that was really actually quite difficult.
In the past you had to do some pretty comprehensive investigation through flow data but the correlations able to quickly bridge the gap between endpoint network, which I think pretty, pretty powerful.
Another one that I saw just the other last week actually this was super weird. It was it was technically in a lab environment, so I wouldn't call it a real world scenario, but it was a real world attack.
And when I say in a lab environment we're doing our own internal testing, I handcrafted a phishing email that went through our system.
User click the link, open it up.
And, you know, that happened we've had evidence of it, no real, you know, and it was labeled as suspicious email because it looked suspicious, you know, it was an abnormal sender abnormal attachment, but there's no reputation there so there wasn't, there was no conviction in the
email itself. Just suspicious label.
In my scenario actually the user account was then compromised, and that user account was then logged used to log in to the network on a nut on another device, which triggered a abnormal user detection that we use based on ice data, which was, you know,
there's in this particular example is, you know, the, there was an established behavior of this particular user on particular device, and it was seen logging on a non normal device, which triggered the detection and correlated it to this phishing emails,
and this is where it was super interesting and this is the first time I actually had seen legitimate cross user correlation across in this case user domain in an email, and the user domain from a network domain.
So we are correlating data from the center center slash recipient and a user are from an email, email header to the network, you based username that occurred there and was basically, and the AI, which summarizes the whole event so we had correlated data
from suspicious email through suspicious network log on.
And we actually identified this as a compromised user account. I was like wow this is amazing.
You know we could theorize all day long about how these are the types of correlations that we're doing. But to see them actually work.
You know it's kind of exciting. In this, in this case it was a custom crafted attack.
There was no intelligence involved in it, you know, there was no threat Intel involved there's no it was all just the AI doing what it's supposed to be doing.
I was actually quite excited so we can actually watch through suspicious emails through to suspicious network log on and correlate a end correctly conclude a compromised network.
That is so cool like that's big because I've talked with a lot of customers I'm like what are you doing something's not definitely malicious but it's just suspicious like that's going to be your advanced threat there like maybe I'll let this pass but yeah that that's really cool seeing that come to work.
I also like the first example you brought up Matt or for that particular use case.
It was more the visibility that XDR that was the important part like just we keep resolving this but it's taking so much time how does this keep happening, but finding that that one that one.
Finding patient zero the one that didn't even know was there some lot and you know that that lost network attached storage.
Yeah, they'd totally forgotten about didn't know and touched it in years, probably the original person that set it up and left and was long gone.
Yeah, like I was kind of that same that alone was was.
I was worth the price of admission just to not have to resolve this piece of malware anymore.
So, the last we've got two more questions but I think they can kind of be tied into one because we wanted to ask and this can be open to anybody we wanted to ask you about what's.
We talked about a lot of advancement since Cisco XDR what's new but really Brianna you touched on a little bit more.
What's kind of happening with Splunk a little bit but then anything else that either of you would want to share about maybe what's coming down the pipeline for Cisco XDR would be, I think everyone loved to hear that.
Yeah, definitely. I'll jump in and I know Matt will probably have some either adjustments or additions.
Say Marocky again.
Yeah, yeah, more.
We're gonna do more with Marocky. It's gonna be really exciting.
We're already doing lots. Yeah, actually, I think though we're gonna expand beyond that in the enterprise networking space to look at the cat nine thousands and other areas where we could look at the opportunity to do the same or similar.
Obviously, Marocky is a little bit of a different setup. So it's a thoughtful process there, but we'll definitely be looking at that. Mike, a great question around Splunk and things of that nature.
We definitely have seen the market responding to the response to XDR. I know that's a weird word, weird sentence, but people are the point of presenting an incident and doing the work for someone in deciding if there is an incident is resonating and then providing the right responses crafted in order to follow up on that presented incident is definitely resonating in the market.
And I won't say, you know, Cisco XDR is the only one forcing that, but we certainly have a hand in it. So with that, we've seen for a while now that certain vendors who were trying to move from, let's say, EDR to XDR, SIM to XDR.
We're looking at things like more advanced security analytics, especially those vendors who were trying to go from EDR network to XDR. Those that might have been considering themselves at one point primarily a SIM.
They were looking at how do they provide analytics across that data? But in the last year alone, we've seen three main vendors, Cisco being one of them, really either establish a SIM or acquire a SIM for these types of purposes.
So ourselves, we know that Microsoft is in the mix with Sentinel and Palo Alto has done something similar in addition to the types of acquisitions that some of the other vendors have made for analytics and big data collection in the past.
So when we look at that, the question becomes, well, what are we all looking at doing? And as Cisco has messaged out multiple times, we're really looking to bring this concept of threat detection in incident and intelligent response management through together for people.
So threat detection incident response. And how do we not only serve our customers and organizations out there best by determining when incidents are there and guiding them how to promptly and precisely respond to that,
but almost take that to the next level of like maturity and surgical level to say, well, if you had this all in hand, or at least a solution was doing most of the work for you, what else would you want to do next?
How would you want to mature? There is that security maturity model. If you started either zero low or very low, how do you move into the mediums and the highs?
And how does the technology support you in doing that, but still give you the flexibility to go beyond maybe what something like XDR is doing today? So that's part of what's coming next for us.
First, we're starting out very better together. Similar to what I was saying earlier, we're not disjointed companies. We're one company. So how does a customer of both interact with their solutions in a meaningful way?
How can they use their incident response process today? Whether that starts an XDR or starts in something like Splunk Enterprise or Splunk Enterprise Security and use the information from both in order to work through an incident or a potential incident.
But across the Cisco portfolio, we've been updating all of the integrations that are available, putting it together in this Splunk TA beautiful app that people can go in and see data on a dashboard, take actions from that dashboard, or at least pivot day one into the right tool set.
And then moving forward, we'll be thinking more along those lines of if somebody has XDR and it's able to accomplish the incident response pieces for them, how are we supporting them growing into more advanced threat hunting and more advanced security operations maturity overall?
So that's really for those aspects with coming. And I think it's a reflection of vendors like us having some forethought in that, but also seeing the responses of customers and organizations and the tools that they're using.
What's working for them and not and the industry responding to that.
Some other just really quick things that I'll add and then I'll pass it over to Matt for any items he has. We are also doing things like around MITRE. You mentioned we use a lot of that in our detection, our analytics and our incident determination and presentation.
But we also want to help support people in understanding how the tools are supporting them in the environment and not just the Cisco tools. So things like our MITRE ATT&CK coverage heat map.
We're not trying to take over posture management and XDR, but we are trying to say we have a lot of your tools coming in, a lot of your data coming in and we know what incidents are happening and what's triggering a detection, what's not, what has responsive actions, what doesn't.
So can we provide a detection coverage heat map for you and start to bring in intelligence from Talos to help you understand where this is attacker oriented as well and where you have coverage and where you don't.
So supporting things like vulnerability management tools, posture assessment tools that customers are using today with real data about what's happening in their environment without having to pay for an adversarial emulation potentially just to find that data every time.
And yeah, there's some more exciting stuff coming there. Also, one of the cool things that we're looking at towards the second half of this year, and we'd love to come back and share more, is a concept of SOC observability.
So there's a concept of observability overall and how I understand what's happening in my environment from that aspect. We want to think through meaningfully now that you have data coming in, you know what incidents are producing.
What is that telling you about your environment and how does that help you orient yourself and action proactively, not just potentially reactively?
That's excellent. Yeah, I particularly love the heat map with MITRE. I think there's a lot of value customers will see with that.
Yeah, a lot of stuff on that last question and I'm still thinking about everything that's going to happen. So very excited about what's coming. That's nice.
Well, got a couple more minutes left. Before we hand it to Matt and Brianna for maybe some closing thoughts, how about a just a super quick lightning round?
Yeah.
All right. All right. I have to ask this question. I'm going to give this one to Matt first because this is blowing my mind.
Okay, so Matt was explaining to me, am I saying it right again? Poutine?
Poutine, that's the thing.
Yeah. Okay, so Andres came up with these questions and you got some for you, Matt, Canadian based and Brianna, you're in New York, is that right?
I am. I'm in New York.
You came up with some New York one specifically as well. So now the first thing would be poutine or Tim Hortons? Like, what you're going to pick between?
I mean, Tim Hortons is a place, poutine is delicious. So I'm going to have to pick poutine.
Okay, all right. All right. All right. Then real quick. Favorite Canadian slang word?
Hoser.
Hoser? Okay.
We may need to dig these ones out.
Canadians know what I'm talking about.
Which of these is more Canadian, hockey or curling?
This is controversial, very controversial.
This is being recorded too.
I'm going to say curling. I'm going to call it, I'm probably obligated to, but I'll probably be voted down.
Yeah, we don't want to get like hate mail coming your way. Just say curling, you know.
How about the most beautiful place in Canada you've ever visited?
Oh, yeah, there's no way. There's so many beautiful places in Canada. I personally am very personal to the Canadian Shield country, but that's just me.
Very cool. And last one I've got would be, you have a favorite Canadian musical artist, favorite Canadian band.
I'm going to build on the Hoser reference and to say Bob and Doug McKenzie. For those of you that didn't get Hoser, Google Bob and Doug McKenzie.
And there you have it.
Oh, excellent.
You're going to get hate mail for Matt not saying Rush, as he and I discussed last week actually.
Andres over to you.
You know those questions, when I was looking for those questions, there was like a rabbit hole on Reddit about poutine and team horns, just so you know.
If you haven't had poutine, have poutine.
It's delicious.
It is on my list now. Fries, cheese curds, gravy.
That's it. That's actually poutine. That's all you need. On a cold day, like well below freezing, you're eating that, you're happy.
Nice.
I'll try that.
Rihanna, for you.
Best slice of pizza in New York.
New Park pizza. So it's New Park pizza in Queens. Now, I'm going to just caveat this very, very slightly.
There's different types of pizza. There's like the, you know, round new palatine pizza.
There's Sicilian style pizza. There's what we call grandma style pizza.
So my statement would be very controversial, similar to Matt's, because there are people a hundred times that are going to tell you that that's not the best place.
That there's a place in Brooklyn that does grandma style pizza that's better. And there's probably three in Brooklyn.
There's like LNB, which is everybody's going to say the best and they're going to say the best gelato as well.
To far as there's a few. But for me, like New York style pizza, Neapolitan, New Park pizza, never burns the crust, nice and salty. Perfect.
And close to JFK airport. So if you're coming in and out of town, you can easily hop out, grab a pie and hop back.
No excuse not to.
No excuse.
That's nice. The next one easy subway or taxi.
Subway. But another good caveat for you. I'm actually a big driver in New York. I know that sounds insane.
But when you grow up in the boroughs a little bit, you sometimes become a driver.
So that's partly because if I'm going to drive in my city, I'd rather drive myself. Like I know how to get around.
That's good. Another controversial one. Junkies or Mets.
Oh, I'm a Mets fan because I'm born and raised in Queens and I'm pretty sure they kick you out if you're not a Mets fan.
Yeah, but I don't unlike most Mets fans. I will root for both.
I will, you know, if the Mets are out of it, I'll root for the Yankees. But a lot of Mets fans just hate Yankee fans. But I'm also a Giants fan. So I know what it's like to win. Unlike most Mets fans who are also Jets fans.
Yeah, I heard that it was a requirement for your driver's license to be fun if you're in Queens.
Exactly. Just like if you're in the Bronx, you better be a Yankees fan. Otherwise, again, I swear, like they should probably kick you out.
Nice, nice. And then the next one is going to be your favorite hidden gem in the city.
It's a great question. So mine is a neighborhood. I actually think that if you haven't been to Alphabet City, which is in lower Manhattan, that you should go. It's part of like the Lower East Side and that area has transformed a lot.
So there's the Lower East Side that's above Houston Street and then slightly below Houston Street as well where like Cassis-Ellicott-Haston is. But it's a great place to weave in and out between seeing what's very much changed from New York and what very much hasn't.
Like a lot of old school delis and a lot of old school restaurants, but then a lot of like, big new apartment buildings, which you might love or hate depending on how long you've been here.
But it's a really good way to see a little bit of both. And yeah, the Lower East Side is, you know, where I used to get my tattoos and piercings. So it's a good place to be.
Nice, nice, nice. Last one. I heard my New York accent come out for like a solid five minutes also.
Yeah, for a quick second I was like, yes, that was so cool.
And the last one, summer or winter?
I like winter.
Yeah, that's good.
Well, I've got some stuff. I know where to go for pizza. I'm definitely going to try this poutine thing that I've been hearing about. That's awesome.
Guys, we learned so much on Cisco XDR. Thank you so much for returning for season two.
Final thing would be any closing thoughts, Matt, Brianna, that you may have before we...
Other than there's this Meraki XDR integration. Super awesome. It's not better than poutine, but it's pretty good.
I'm going back. Cisco Meraki XDR. I'll go back.
No, but thank you so much. We hope we get the opportunity to come back. And, you know, we're really here to help solve problems for organizations. It's a legit statement.
So we're working really hard on everything from feature functionality to efficacy. If you're watching this and you're a customer or potential customer, please reach out.
We'd love to hear your ideas of how we can best help you.
Yes.
Cisco Meraki and XDR.
Absolutely. And anybody listening in, just send them to... you can send them those directly to Andres and I and we will forward them to you guys as well.
Guys, thank you Brianna, Matt, for your time and expertise today. A lot of cool stuff with XDR.
Please everyone, don't forget to tune in tomorrow, noon Eastern, for the live XDR demo dashboard.
You'll see everything that we talked about today in action. The incidences, the responses. And stay secure and we will see you on the next episode, everyone.
Thank you so much. Have an amazing day. Bye everyone.
You as well. Bye.