Close this search box.

The Case for Open XDR – X Means Everything

Samuel Jones
The current model for cybersecurity is broken. It consists of acquiring and deploying a lot of stand-alone tools, each with its own console, to analyze logs or traffic and detect anomalies that could be threats. In this model, it’s up to each security analyst to communicate with other analysts to determine whether each tool’s individual detection (each of which, by itself, may look benign), can correlate with other detections from other tools to reveal a complex attack.

This model forces enterprises to create complex security stacks consisting of SIEM, SOAR, EDR, NDR and more, for the purpose of instrumenting the enterprise, identifying threats, responding to threats, and managing risk. Acquiring all of these tools and managing their licenses is complex and expensive, and the manual correlation required to compare each tool’s detections leaves a lot of gaps in the overall security infrastructure. 

Analysts are often bombarded with false positives by these systems as well, causing “alert fatigue” and job dissatisfaction. Even enterprises that declare themselves satisfied with their existing SIEM and other tools will admit that the amount of time and energy they have poured into standing up a multi-tool security infrastructure isn’t delivering the requisite results.

The Case for XDR

XDR, or eXtended Detection and Response, has become a catch-all definition for any technology performing detection and response, because in the acronym, X is really a variable. While X can represent “Endpoint+” or “Network+”, that disregards the present pain of the enterprise of siloed tools, uncorrelated data, and alert fatigue. The whole goal of XDR is to address this pain, and therefore X has to mean “Everything.” Everything, then, implies a platform approach to covering the entire attack surface through detection and response.

This platform approach can fix today’s broken model by converting siloed tools into a unified toolset, converting uncorrelated data into a living correlated representation of the attack surface, and converting alert fatigue into peace of mind. How a technology realizes this goal is the key architectural question. There are two types of XDR today: Open and Native.

Open vs. Native XDR

  • Open XDR is delivered via an open architecture capable of leveraging existing security tools’ telemetry and response capabilities across the attack surface
  • Native XDR is delivered from a single vendor’s security tool suite that provides telemetry and response across the attack surface

Regardless of the architectural approach of an XDR platform, it must satisfy the following technical requirements in order to be considered XDR:

  • Deployability Cloud-native microservice architecture for scalability, availability and deployment flexibility
  • Data Fusion Normalized and enriched data across the entire attack surface including network, cloud, endpoints, applications and identity
  • Correlation High-fidelity correlated detections across multiple security tools
  • Intelligent Response – One-click or automated response from the same platform

cloud detection and response
A common misconception about Open Vs. Native XDR is that they are mutually exclusive types of XDR. They are not. An XDR platform can be fully Open, and partially Native. For example, an XDR platform can have a few built-in tools from its vendor while openly integrating with the existing tools from the other vendors. This e