Why XDR As We Know It Will Fail

Palo Alto Networks CTO Nir Zuk first coined the term extended detection and response (XDR) in 2018. The concept of XDR, which Palo Alto describes as "breaking down traditional security silos to deliver detection and response across all data sources," is a sound one. And as cloud adoption and use of software-as-a-service apps skyrocketed in the wake of the global pandemic, so has the need to get data from all of these disparate platforms and tools in one place for security investigations — hence the hype around XDR over the past few years.

But there's a big difference between a technology's concept and its execution, and I believe XDR — both the single-vendor approach and the open or hybrid model — has inherent limitations that will prevent it from succeeding in the market.

The Problem With Single-Vendor XDR
Single-vendor XDR promises a single provider will offer all the out-of-the-box capabilities required to successfully execute threat detection and response across data silos, including all the collecting, aggregating, correlating, and analyzing required for security investigations. With today's dispersed data and disparate security tools, however, it's unrealistic to think that any one vendor can have all the best technologies and capabilities required to perform efficient security investigations. But even if they do, this monolithic approach usually entails one mega industry player acquiring a bunch of smaller companies to piecemeal together a complete security portfolio. There's little business incentive to ensure all these disparate technologies are tightly integrated, which is a requirement for building a fully functional XDR platform.

Additionally, the need for XDR largely stems from challenges with security information and event management (SIEM) and security analytics to support security operations. SIEM was the original correlation point for disparate data sources. However, SIEM rules and analytics capabilities quickly led to an overwhelming number of alerts, and subsequently, a significant number of false positives. If SIEM — and later security orchestration, automation, and response (SOAR) systems — couldn't help us get all data in one place, with the context and information required for accurate security investigations and to make informed response decisions, why do we think XDR can? Especially today when data variety and volume make data centralization impossible?

Last, but certainly not least, the single-vendor approach to XDR assumes that organizations will rip and replace their existing technology stacks that they've invested in over the years in favor of a single XDR vendor's platform. And one can only imagine what a CEO or board member's reaction will be if a CISO or security leader asks to scrap all the time, money, and effort put into their security ecosystem to put all their eggs in a new, single basket — an XDR vendor that promises, but hasn't yet proven, that it can centralize data and technologies for more-accurate threat detection and response.

The Problem With Open or Hybrid XDR
In this XDR model, organizations can use point solutions from various open or hybrid XDR vendors. This strategy accounts for the "rip and replace" issue, as many enterprises have already invested in many of these security technologies, but — just like the single-vendor approach to XDR — here too, there still needs to be a connectivity layer that integrates all these siloed tools. And this introduces a few questions: Who is responsible for doing this? Is it realistic for us to think that individual vendors will seamlessly integrate with each other and remove the burden from customers? Or will customers be forced to sign on with managed detection and response (MDR) players to off-load the heavy lifting?

These are important questions to evaluate because, without this connectivity layer, it's impossible to bring together disparate technologies and platforms, which means it's impossible to facilitate data access across all silos to help security analysts understand the relationships among data to initiate informed response actions. And this means XDR will fail to deliver on its intended outcomes.

One additional point to consider: We're starting to see XDR alliances emerge, which are designed to overcome this integration issue by connecting member technologies in one ecosystem to help analysts improve threat-detection and response capabilities. But these groups are still closed ecosystems, limiting customers to only the technologies offered by the vendors that are members of the specified alliance. So, companies still must rip and replace existing infrastructure and allocate time, budget, and resources to implementing these new technologies.

Seeing Beyond the Hype
Is there hope that XDR will improvise and adapt to deliver on its original promise? Possibly, if XDR vendors start to realize the importance of a connectivity layer that sits on top of the security ecosystem to provide access to all the data these tools provide.

But XDR is a lot of hype without the supporting longevity — and it will become a technology of the past within just a few years. At the end of the day, it's a new attempt at solving the decades-old problem of more efficient security investigations. I think companies will see a similar result to what they experienced with SIEM and SOAR technologies — millions of dollars and years of time invested to get alert fatigue and subpar results.

The takeaway here is that companies shouldn't take the hype at face value and blindly throw money at the latest and greatest security acronym. They should do the due diligence required before implementing any new security technology. Additionally, whether using XDR, SIEM, SOAR, or another technology to aid in security investigations, security teams should consider adding that integration layer. Only then will they be able to make the transition from using a subset of their data in security investigations to accessing all of it for more accurate investigations and informed response decisions.