How XDR Differs from SDR, SIEM and Platforms

In Jon Clay’s post, he does a great job of explaining the evolution from EDR to XDR. In short, he explained that Endpoint Detection and Response (EDR) is great, but that having sources of information beyond endpoint is better. The “X” in XDR is essentially “many” or whatever we can add to provide a broader, better source of detection and response.

So that is how XDR is different from EDR.

A common and healthy initial reaction to XDR should be, “This sounds a lot like SIEM and platforms: many things feeding into a single collector.” Allow me to explain the differences, and why these differences make for a very big, very real, and very pragmatic deal of difference.

Let’s look at SIEM. A lot of rocks get thrown at SIEM, but SIEM is awesome considering what it is being asked to do—pull log data from dozens or hundreds of vendors’ products and then try to make sense of them to produce meaningful alerts.

SIEM, however, is wide yet shallow. It collects from a lot of things, but the information it collects is very limited. SIEMs can’t force a specific product class, such as an endpoint protection platform (EPP), to cough up more information than the generic, agreed-to-upon format allows. And when that EPP adds some new proprietary inspection features, the SIEM is highly limited as to when and how it could add those new data feeds.

And the big factor of SIEM is that SIEM has no R in it—that is, there is no inherent response built into SIEM. It’s a detection tool, a fire-alarm that isn’t connected to the sprinklers. But across so many products from so many vendors, SIEM is still and will continue to be valuable, and is not replaced by XDR. In fact, with XDR it can be even more valuable.

What about vendors that provide a lot of products across multiple categories–those that are supposed to have exchange and correlation richer than SIEM’s, and include response. Isn’t that what platforms are? How is XDR different from that?

Platforms have fallen short for a few reasons. The foremost reason platforms haven’t done the job is that they don’t have an independent collector or data lake.

I’ve been preaching about “glue between the silos,” for years but it’s still silos.There is signaling between the elements, and the consoles for the elements have had the analysis built in. This is weak for two reasons: Consoles are for a specific organization role (for example, EPP is for endpoint security ops), and the integration for that role is not enterprise-wide.

Here’s what I mean. If that EPP pulls in useful info from an IPS, that is usually helpful specifically to the EPP analysts. But what if that resultant information would be even more useful to a data center security analyst who could combine it with cloud workload protection data to find and block a lateral attack?

Platforms are missing that central super-data lake, and the benefits of security info collection are still within silos. Platforms self-limit on the narrowness of their collections, and the response capability is limited to that product: The EPP console pulling in IPS info only interacts with EPP. Anything outside that deeper-than-SIEM silo still needs a lot of time-consuming and custom interaction between people outside the platform. It’s deeper than SIEM, but it’s still in silos.

XDR is the greater glue between the platform silos, but breaks down those silos with a new element: the central data lake. And the data collected isn’t limited to the scope of a specific role. It isn’t role-centric; it is attack-centric.

Roles naturally have blinders on, and attackers know that. XDR is flexibility and being able to instantly address rich and deep security data in new ways that may not have been foreseen. With a central repository designed for unstructured and unforeseen queries, new kinds of attacks can be dealt with more easily. With already-advanced machine learning and advancing AI, increasing alert quality can be done at the source rather than only as a result of looking at a lot of low-quality alerts.

There’s a lot of communication shown, but the key elements are that having highly rich APIs designed centrally means that adding any new product is instantly additive: It is already designed to feed and draw from the XDR data lake immediately. Sure, there are already rich APIs, but not across a wide range of products, including email security, and not with an XDR-specific data lake.

The bottom line is that XDR is EDR for more than endpoints alone, as it covers the entire IT stack of an organization.

This guest blog is part of a Channel Futures sponsorship.