XDR as a technology was developed as an improvement over EDR. EDR itself was conceptualized based on a real need of the market – a product that would help detect advanced attacks by analyzing historical endpoint activity data and then responding to it remotely. The ability of EDR products to model the endpoint through machine-level telemetry was the core enabling technology behind the idea.
With XDR, the idea was to extend the same concept to multiple data sources, such as the network, email, cloud infrastructure, etc., to add more context around alerts for identifying attacks.
The Different Approaches
At this point, there emerged a divergence in XDR approaches pursued by two different product camps – the Endpoint Protection Platform vendors, and the SIEM vendors, mostly guided by business needs.
The SIEM was traditionally used as a log storage and forensics analysis technology. However, when the XDR opportunity came along, the SIEM vendors wanted one of their own. They introduced Open XDR, where an Analytics and Response layer was incorporated on top of the SIEM data lake. This concept helped the SIEM vendors to reuse their connector architecture, storage, and search efficiencies to cross-sell XDR.
Meanwhile, the Endpoint Platform vendors continued to advance along the EDR+ concept, where the MITRE Tactics and Technics-based analytics and response capabilities developed for EDR were extended to incorporate more data sources.
Both camps touted their products as the better XDR. However, the customer was not happy.
While the XDR vendors were fighting it out, the end customers started to realize that XDR, as a product, was only marginally beneficial to them. That was because working with XDR required high levels of threat-hunting expertise, and the shortage of skilled staff made it impossible to investigate the deluge of alerts it generated. Also, since XDR was not designed to generate real-time responses, it was almost ineffective in time-critical response situations, such as ransomware attacks. The large SOC’s could leverage XDR storage and historical lookup capabilities, but for most CISOs, XDR was turning out to be another expensive headache.
Realizing this problem a few years back, a few XDR vendors started moving away from the predominant business focus to the underlying pain points, and a new XDR has now started to emerge.
The new XDR
While the “old” XDR focused on collecting and storing historical entity telemetry and alert data, pushing most of the onus on analysts to triage, confirm, and respond to a cyber compromise, the new XDR presented automated, real-time response as its core value promise.
XDR is supposed to generate thousands of alerts for any MITRE/algo-based IOC detected in the endpoint/network data at the slightest hint of a compromise. Pouring through these alerts is an onerous manual task. However, ML and AI are there to help. ML can be used to find anomalies and has been used before in post-event spaces. However, it leads to greater noise. The key was to find ways to reduce the alert area and to use highly efficient safelists to reduce noise further.
Consequentially, a model for XDR emerges where entity-specific anomalies are detected and graded based on their characteristics. The fidelity of reported anomalies is further improved through various AI-aided safelisting techniques resulting in a highly accurate alerting system. This system automatically responds to a threat indicator in real-time at the entity level and can continuously adjust its response based on environmental cues. Only those alerts that require temporal correlation would be forwarded to a centralized store on a secondary path for deeper analysis and response. This is far removed from today’s over-dependence on complex heuristics and rules-based detection and heavily dependent on highly tuned ML models. Ultimately, such entity and attribute-specific ML models would be standardized and published directly by the application and device vendors, reducing the load on the XDR vendors.
So, who won this battle?
The Endpoint Platform-based XDR technology appears to be more aligned to this new direction over the generic SIEM Open XDR initiatives due to the need for data and algorithm specificity for low FPs and quick response. However, the SIEM, too, has a critical role. While detection and initial response are effectively tackled by the new XDR design, the Incident remediation flow requires much more contextual information at each step. As generative AI models and LLM prompt engineering are harnessed to orchestrate security workflows, the SIEM will form the reservoir for this contextual cyber data. But let’s park that discussion for a future post!
