Cisco XDR

Our main use case for Cisco XDR  is to centralize security telemetry and correlated events across endpoints, the network, and email security tools. This solution helps us detect threats faster, reduce alert noise, and improve investigation efficiency.

Recently, a phishing email triggered an alert in Cisco XDR  through email security, while the endpoint detected suspicious execution. The firewall logged unusual traffic, and Cisco XDR  correlated all signals into a single incident, showing the full attack chain.

The best features Cisco XDR  offers are cross-domain visibility, encompassing endpoint, network, and email in one place, and incident prioritization, which highlights high-risk events.

The threat correlation that links related alerts automatically is the feature I rely on the most because it converts multiple alerts into one actionable incident, which has significantly reduced investigation time.

Cisco XDR has positively impacted our organization by providing faster detection of complex threats, reducing alert fatigue, and giving us better visibility.

Cisco XDR is working well, but the solution could be more cost-effective for mid-sized and small organizations. Apart from this consideration, everything is excellent.

I have been using Cisco XDR for more than three years.

I highly recommend Cisco XDR, and my advice would be to deploy this solution by integrating the maximum number of security tools for full visibility and to start with key use cases. It is important to train your SOC team so that they can effectively handle this solution. I am providing this review with a rating of eight out of ten.

We integrated Cisco XDR  into customer environments and I completed multiple deployments with the product.

The investigative ability of Cisco XDR  is amazing to me. Once all the data is in Cisco XDR  and it flags an incident when it sees something that is notable, important, and of concern, it will raise an incident. The ability to look at one screen about this incident and get data from multiple different sources is a very great capability for incident responders to obtain the information they need. Cisco has AI built into the product where it actually translates some of this log data. Professionals typically have to spend a huge amount of time looking through logs trying to figure out what the log data means, and this is done for you automatically.

The number one thing was getting visibility from customer environments into one console. Customers would have network telemetry from NetFlow, Secure Network Analytics, or the Cisco Telemetry Broker. They would have an endpoint product, a firewall product, and cloud resources, but they needed to correlate all of that data into one location and be able to respond to it instead of having to go into all of these separate security products. By integrating all of these products with Cisco XDR , this allowed them to have a single pane of glass and respond more effectively and quickly to security threats and know what they needed to respond to with that intelligence.

Workflows could definitely be easier to work with. Workflows are automated tasks that can be kicked off inside of a playbook. When someone is responding to something, they can click a button and it will perform automated tasks for them inside of these other products. The product can actually control the behavior of a firewall and you can write a rule in a firewall from Cisco XDR without having to go into the firewall software. However, if it is not a native workflow automation, it is very difficult to create your own. It is not intuitive and you almost have to be a developer and get really good with the API. This could definitely be improved on, particularly the custom workflow automation.

Another thing that could be improved is Cisco documenting how it makes decisions, because there are certain factors or criteria that it uses from the source products. Cisco XDR gets all of its data from the integrations, so if you do not integrate anything, it is not going to do anything. Sometimes in these integration products, such as Secure Network Analytics or Cisco Security Exposure, they could be generating some type of alert and you do not necessarily see that in Cisco XDR. This is because it knows, maybe because of these other products, it is not really a big deal and is not big enough to raise an incident. However, I do not think Cisco does a great job in explaining what those rules are, such as why this happens and how this happens. This can cause some questions and some concern. I think it is doing the right thing, but I think it would be better if they had a rule set to say, based on this data, this is how the product actually works.

I have been using the solution since twenty twenty four, for about two years and a half.

I have never run into any type of scalability issue. I have deployed Cisco XDR in really small environments and with really large environments, and there was never a point where we could not process the data. Most of the time, Cisco already has a lot of the data, especially if it is Cisco native products. I am not aware of any scalability issues where we were deploying it and said that if it is an environment over a certain size, then we cannot do it or we have to do something different.

If I had to give it a rating out of five, I would probably say about four out of five. Every now and then something weird happens in the console, the web console. This typically is because the developers seem to be making lots of changes and you have to clear your cache and clear your browser cache, and then it will eventually work. Sometimes that is a little bit annoying. There are some back-end things that may take a little bit of time to process. When you first set up the integrations, it is not immediate. There are some things on some timers and some scheduled activities such as batch processing. This goes back to people needing to understand that, and Cisco does not do a great job of explaining that. You may think that something is broken, but it just has not run yet. So on the initial integration sometimes, it does take a little bit for data to start showing up and it can cause some confusion.

I occasionally contact customer service, though not too often. I would say probably in the earlier days there were more support cases because Cisco XDR came into existence later in 2024 and the product was evolving a lot in the early days. Later on, it has gotten a lot better, and I have not had to open up much support cases.

I never saw a false positive. I think it is very accurate. There were some times where it actually flagged some behavior that would have been malicious if I had not known very specific things about it. For example, it was custom code that was written by developers that did not use very good coding methodologies, so it was doing crazy things, but in this exact instance, it was not malicious. However, if I had not had that special knowledge already, I would need to respond to that. It identified that they do not need to be doing this in the first place, so that required a code change. I would say it is highly accurate. It runs everything through the MITRE Framework and it uses Cisco's intelligence where they are getting threat intelligence from Talos and all of the products that people have deployed, even if they do not have Cisco XDR. If you have Cisco security products deployed out in the world, all that data is feeding the back end. Therefore, you are taking advantage of the millions of customers out there and the environments that are running Cisco. Even if they do not have Cisco XDR, they are feeding data into your Cisco XDR solution and it is making it more intelligent.

It is all about getting the data into the product because technically there is not really anything to install in the environment. It is about connecting what is in the environment out to Cisco XDR. I would always focus on the network traffic, getting either Secure Network Analytics data out there or deploying the Cisco Telemetry Broker to get network data. We need network telemetry and then focus on the endpoint. The endpoint is probably one of the more difficult ones because it does touch all of the hosts in that customer, so they are typically more concerned with changes because they do not want to affect that environment. So we are integrating that, network, endpoint telemetry, email integration, and then cloud. If we can get the cloud data, that is typically what we would do. I have not had any issues on the Cisco XDR side. It is typically things in the customer environment that are already not working correctly and therefore we have to fix it to get the data out. However, it is typically a straightforward process as long as the underlying products are in good shape. That is where you really run into a problem, but those are not part of a Cisco XDR problem. They are just normal life in IT.

The implementation team is very professional, very helpful, and willing to help. We always had a good experience.

Cisco XDR absolutely can provide ROI. It has some default tasks that it thinks probably everybody should use, but then you can make those work. For example, if you do not have this type of product, you can take that out and not focus your time on incident response on that. You can focus your time on incident response on your email, endpoint security, and cloud.

Cisco XDR totally supports third-party integrations and it works as long as the third party already has an API. If they have an API that allows changes to be made and data to be written, then it typically works really well. If it is a closed-off system, it is not going to work well. The cloud integrations work really well getting data from AWS  and getting data from Azure , and getting that network data. This is a great part of it and it does not really require much of an integration. It is just reading that data that is already there. However, it kind of depends on the third party, but it does work. When I have done it before, it has worked well.

It is difficult to say because it depends on how many products a customer would have. But if they had an endpoint product, a firewall product, a network product, and a cloud product, and they had an incident, they would have to get into each one of those and then do research, potentially an hour per product. Whereas now, they are in Cisco XDR and they are able to get the answer to this in less than thirty minutes. This is a huge time savings to me personally.

Getting the endpoint data is absolutely critical and Cisco XDR does a great job. Getting endpoint data from something such as CrowdStrike or from Cisco Secure Endpoint  and then taking in data from the network with NetFlow logs or data from Secure Network Analytics or something that does IPFIX, and then the cloud logs and then also being able to do email integration for email threats, all of that data is available to investigate, to make decisions, and to see if one host ever talked to another host. When investigating an incident, that is extremely beneficial. The integration of that data and merging it into one screen where I do not have to look at different solutions is a great benefit. The merging of all of that data into one display is probably the best benefit of Cisco XDR.

There is the concept of playbooks where, if an incident is raised and there is a problem, it allows companies to build out how they want their incident response staff to operate. What is the first step? What is the second step? What do we investigate first? Who do we notify about this? It allows them to customize that response process to align with the company's own written IT security policy. This helps focus incident responders on the tasks that they need to do for that specific environment and focus on the things that are important to them, not just what Cisco thinks.

I would rate this product a nine out of ten overall.

My main use case for Cisco XDR  is to collect all the logs from the use cases of how users try to explore and perform their tasks. We are threat hunting to prevent, detect, and respond to threats, collecting from different systems such as M365 and others, correlating them into one central location, and trying to correlate between different kinds of logs to provide whether the alert is a true positive or not.

A simple example of how I used Cisco XDR  to connect all these logs and coordinate between different systems is that we have M365 connected to Cisco XDR , as well as browser security connected. Many users use client applications including Outlook, but many use cases go wrong when they are using it via a browser. So what we did was correlate all the source logs from the browser and XDR  and try to correlate them with the user's reactions as well as their daily usage. This helps us understand their daily perspective of how they are behaving. Behavioral analysis was easier when we connected all these systems.

From the malware detection perspective, Cisco XDR can actually find out if there is any malware present, and we can lock down the system as well, which we call isolation. That is a great add-on for me.

From the SOC perspective, the best features Cisco XDR offers are the ease of use and the ability to understand the logs and log aggregation. It is one of a kind. What stands out for me about the log analysis and the user interface in Cisco XDR is that Cisco has an AI assistant that we can utilize to understand the correlation. The main intent of the integration architecture allows us to integrate easily without any cumbersome processes. We can simply specify what should be integrated with what. They have an open integration architecture already present with third-party tools such as CrowdStrike, Palo Alto Networks, and AWS . Additionally, the automated response workflow can actually automate the flows and tell me the response automatically, indicating whether something is an issue or not. All these features make my daily work and log analysis easier.

Cisco XDR has positively impacted my organization because instead of ten people working on one event, Cisco XDR can do many things an analyst can do, reducing the human effort required and coordinating everything. The mean time to respond has improved for the company, and we have automated many processes. A severe incident would typically take my engineer one or two days to solve, but Cisco XDR would have already completed almost half of that work. The engineer can then review the incident and understand whatever analysis has already been provided.

The features of Cisco XDR are a great add-on for the SOC team, and the security has increased by using Cisco XDR.

There are no significant improvements needed for Cisco XDR. The inclusion of new incident mechanisms and the ability to automate them automatically would make things easier.

I have been using Cisco XDR for almost one year.

In my experience, Cisco XDR is stable.

Since Cisco XDR is on a cloud-native architecture, I believe it is significantly scalable.

Customer support for Cisco XDR is a bit slow in the initial stages, but I believe it has improved nowadays.

Before Cisco XDR, I previously used SecureWorks and switched due to problems.

I have seen a return on investment with Cisco XDR. I can share that I save time and people. For money saved, I do not see much improvement, but time saved is significant.

My experience with pricing, setup cost, and licensing for Cisco XDR was good.

Before choosing Cisco XDR, I evaluated options including SecureWorks and SentinelOne.

With the functionality and support Cisco XDR provides, I advise others to go for Cisco XDR, whether for a small company or a large company. I rate this product 7 out of 10.