As is expected with any new market segment or capability, questions about extended detection and response (XDR) abound. This article answers a few of the more common questions from those that are trying to figure this space out.
What is XDR?
An incredibly simplified way of thinking about XDR is that it is EDR++.
A more complex (but accurate) way of thinking about XDR is:
There are tools on the market today that take traditional approaches to security operations: ingesting data from across the environment and performing security analytics on top of it. In contrast, there’s a set of tools on the market today that are innovating to provide a different approach: performing detections based on where the data is.
This has been the point of view of endpoint detection and response (EDR) vendors since inception — that the location of the data (on the endpoint) can provide the highest efficacy telemetry source for detection and response. It started with the endpoint — thus, EDR was born. It must, however, now encompass other aspects as data shifts from being located on-premises to the cloud. This is the first motion leading EDR vendors to evolve to XDR — to identify and protect where the data moves next.
There’s also a second motion leading EDR vendors to evolve to XDR:
EDR is a market-validated tool for effective endpoint detection and response, but incident responders need more telemetry than the endpoint alone: network, email, and applications. In an effort to address this, security teams have used security analytics platforms to match endpoint telemetry with telemetry from other parts of the environment to varying degrees of success. Some solutions, however, have suffered from high resource consumption, high rates of false positives, and large data volumes, creating their own big data challenges.
XDR looks to address this by taking a different approach to detection and response, which continues to be anchored to the endpoint and other high-efficacy telemetry sources but correlates endpoint detections with telemetry from other sources to simplify investigation and response.
What’s the difference between Native and Hybrid XDR?
Native XDR integrates aspects of the vendor’s own suite of tools first and foremost, while hybrid XDR puts a premium on integrations with third parties. Both hybrid and native XDR include native EDR capabilities, as this remains the most pivotal and defining piece of XDR.
Native XDR takes a vendor’s XDR solution, which of course includes the EDR product as its basis, and integrates other aspects of its portfolio first and foremost, such as its email security tools or network analysis and visibility (NAV) tools.
This is in contrast to hybrid XDR, which integrates other third-party tooling first and foremost. Hybrid XDR takes a vendor’s XDR solution, which of course includes the EDR product as its basis, and prominently integrates third-party security tooling.
Does Native XDR mean it has no integrations with other tools?
Most native XDR tools have some way to integrate with other security tools.
According to Forrester research, security teams prioritize tooling with integration capabilities. Thus, both native XDR and hybrid XDR must support integration with third-party security tools by some means — there is simply no other option. Native XDR vendors will continue to lead with their suite of offerings first but may offer integration with third-party tooling through their security information and event management (SIEM) or security analytics platform.
Ultimately, vendors have a limited amount of resources they can dedicate to aspects such as integrations with third parties versus integrations with their own technology. For some end users, it may be more valuable to use a native XDR offering because it is able to so closely integrate with the vendor’s own native technology. With hybrid XDR, vendors will need to dedicate time and effort to building meaningful integrations with a set number of prioritized vendors that they are dedicated to maintaining.
What does XDR replace in the SOC?
XDR replaces EDR in the security operations center (SOC). That is the simplest way to put it. It may eventually replace the SIEM, but that is a five-year vision at this point more than anything else.
When discussing XDR with vendors, one of the easiest ways to determine what they are selling is to ask them this question. Those purporting to be XDR vendors that replace security analytics platforms or the SIEM are most likely a security analytics provider taking a security analytics approach. There are core differences between XDR and security analytics platforms in both product architectures and deliverable outcomes that prevent XDR from replacing SIEM on its own today, like compliance or detection from NAV and other tools.
Does XDR need SOAR?
XDR does not need SOAR; if anything, buying SOAR on top of XDR to fulfill the response capabilities in XDR is redundant. One of the things that’s important about XDR is that it is not meant to mash together existing security analytics technology in order to form some magically better technology. It is meant to focus on optimization through automation based in EDR technology to improve the incident response process without relying on the crutches normally associated with rules and playbooks.
Are security teams clamoring to buy XDR?
Honestly, no, they aren’t. I get lots of questions from chief information security officers about XDR, but it’s all questions like “What is XDR?” and “Why is vendor Y pushing XDR on me? Is it worth it?” Now is the time for education and experimentation on XDR. Security practitioners can get the most impactful, clear and effective use out of XDR by building a journey from endpoint protection platform (EPP) to EDR to XDR.
Why is XDR getting so much hype? What are security teams actually interested in when it comes to XDR?
It’s easy to say XDR is getting hype because vendors think they can sell more of their portfolio by calling everything they sell XDR. And that’s true! There’s another reason, however, that’s focused on actual security team needs: There is a yearning in the security community for a solution that can provide better outcomes than what they are using today.
There are three challenges XDR looks to address for security practitioners:
Generally speaking, security tools take a very nebulous approach to security analytics. If we collect a bunch of data and then perform analytics on top of it, we will be able to see more and understand more about incoming attacks. At first blush, this makes a lot of sense. With the massive amount of enterprise data, however, this quickly becomes untenable. XDR prioritizes the data used for detection to avoid overwhelming analysts with alerts.
Investigation takes the longest of the entirety of the incident response process. It’s particularly challenging for new analysts who don’t necessarily have the skill set to perform quick investigation. One aspect that has been so compelling about EDR technology is emerging capabilities around automated root cause analysis. XDR takes this a step further by incorporating other telemetry into root cause analysis and the investigative process for more comprehensive incident information.
Response needs to be done quickly and completely. Doing response quickly is straightforward, and separately, doing response completely is also straightforward. Doing response quickly and completely, however, is very challenging. A compelling aspect of EDR technology is emerging capabilities around recommended response actions. XDR takes this a step further by incorporating other tools into recommended response to give analysts the context to know how they need to respond and the ability to execute that response in one place.
Do XDR and SIEM work together?
Yes! At least for now. XDR and SIEM are on a collision course, but for the time being, they are complimentary, as XDR cannot address all the use cases SIEM does around governance, risk management, and compliance and detections from other telemetry sources. Some vendors are introducing SIEM solutions as part of their offering, sold in tandem with their XDR offering, while others recommend working with a third party.
What are the architectural differences and similarities between SIEM and XDR?
What outcomes does XDR provide compared to SIEM?
Does XDR being the evolution of EDR mean that EDR no longer matters?
In a recent report on XDR, I stated “EDR is dead. Long live XDR” to drive the point home that XDR is the next evolution of EDR and will ultimately replace EDR. That is still true, even if the line item in the budget still reads EDR and security teams are still looking to EDR. To replace EDR with XDR in the SOC will take time and will be a journey for practitioners, much like the journey from EPP to EDR. It is still important that we understand and call out the differentiable capabilities that EDR vendors are able to showcase in their endpoint offering and be able to separate that from the next step in the practitioner journey: XDR.
For some organizations, it may make sense to limit the integrations they have within their XDR technology and simply use XDR as an EDR. One of the benefits of XDR evolving from EDR is that it may better enable practitioners to integrate more telemetry sources as their security program advances.
This post was written by Analyst Allie Mellen, and it originally appeared here.