Open XDR versus Native XDR

As the extended detection and response (XDR) market emerges, we’re seeing two different types of XDR being created: open XDRs and native XDRs. In this blog post, we’ll define key attributes for each type of XDR solution, their respective advantages and disadvantages, and what type of XDR is best suited for what type of organization.

The key components of XDR: front end, back end, and content

XDR is typically made up of three major feature sets: front end, back end and content. The front end consists of the “sensors”  that generate security telemetry data, like CASBs, EDRs, IAM, DLP solutions, and others. The back end ingests all the collected telemetry data, logs and context information, then conducts all the data correlation, advanced analytics, threat detection, investigation, tool orchestration, and response automation. 

The third critical component of any successful XDR is content. Without prescriptive, prepackaged content that ties these pieces together around specific use cases, it’s impossible to achieve the value props of simplicity, automation, and successful outcomes that XDR promises. Because content is critical for any type of XDR — both native XDR and open XDR — and we already discussed it in a previous post, we’ll leave it out of scope for this blog post.

What is a native XDR?

A native XDR is a closed ecosystem that offers both the front-end solutions that generate data as well as the back-end capabilities of analysis and workflow. To be a native XDR solution, a vendor should ideally offer all required sensors needed for common XDR use cases, typically endpoint, network, cloud, identity, email, etc. as well as a back end capable of performing threat detection, investigation, and response with that data. Native XDR vendors can be EDR vendors who are expanding their portfolio to include more sensors and back-end capabilities such as efficient advanced analytics, or they can be platform vendors which have a wide portfolio of security tools that they are trying to more tightly integrate to provide XDR-like functionalities. 

What is an open XDR?

Alternatively, open XDR vendors offer a solution that is predominantly focused on the back-end analytics and workflow engine. Leading open XDR vendors also add prescriptive content required across all the phases and the full lifecycle of threat detection, investigation and response (TDIR) to easily solve common SOC use cases out of the box. Open XDRs need to integrate with all of an organization’s existing security and IT infrastructure, then correlate and analyze all relevant data, and finally automate and optimize TDIR workflows, making it easier for SOC teams to respond to incidents quicker. As security stacks have grown more complex and disjointed in organizations, open XDRs act as a single control plane across multiple products and vendors. This provides visibility and allows orchestration and automation of actions (similar to SIEM and SOAR functionality) so that SOC teams don’t have to run manual workflows across a myriad of tools.

Pros and cons of each approach, i.e. what type of XDR solution suits my organization?

For organizations that may rely on a single (or only a few) vendor for IT infrastructure and security, a native XDR product might be good enough. The assumption (to be verified via a POC) is that a single vendor might better integrate across both the front- and back-end capabilities within that vendor’s ecosystem. Organizations that have security products provided by a single vendor would find that vendor’s XDR to be a natural candidate. However, there may be gaps both in coverage and depth as a single native XDR vendor wouldn’t be able to offer comprehensive security coverage across all attack vectors and wouldn’t have the depth of capabilities in all areas it does cover.  Additionally, this approach subjects customers to vendor lock-in, whereby they may have to forego using preferred tools made by other vendors to use those made by their XDR vendor. Sometimes that means that organizations have to rip and replace for example their EDR to adopt a native XDR.

Open XDRs are suitable for organizations having several vendors deployed across their security and IT environment. More sophisticated security programs, and often those at larger organizations that may have more resources, will have deployed best-of-breed security tools across multiple vendors. An open XDR means they don’t have to rip out and replace existing front-end sensors to accommodate the walled-garden approach of native XDRs. Open XDRs are, by nature, geared to efficiently integrate across a wide variety of other technologies. Organizations can just augment and rationalize their current toolset, and improve its output and value by layering an open XDR to solve their common threat detection, investigation and response needs. And security teams can add new tools, and mix and match their vendors while continuing to benefit from their open XDR.

Exabeam’s take on the XDR market

We believe the open XDR approach best positions most security teams for success and reduces their cybersecurity risks. While the native approach may, in theory, offer the major pieces of a security program and the simplicity of a single vendor, we believe this will inevitably lead to vendor lock-in and a lack of depth and breadth of coverage for organizations. Security teams will find it difficult to get best-in-class capabilities across email, DLP, identity, cloud all from a single vendor.

In addition, organizations selecting a native XDR may find it very difficult to add a security tool from another vendor that covers a new attack vector or more advanced threats. Because native XDRs are usually focused on their own portfolio, little to no capabilities and support exist to efficiently integrate with sensors from other infosec tools.

The flexibility offered by an open XDR allows security teams to keep existing investments in best-of-breed security tools while allowing desired changes to their tech stack. Open XDRs are made to integrate with other products — so they can comprehensively take all information and combine weak signals from multiple products to find complex threats missed by other tools.

While we acknowledge that native XDRs might be suitable for some organizations, we have been working with customers and prospects on an open approach. As security programs evolve, we see open XDRs as a key solution in future-proofing an organization’s security program and allowing it to grow with best-in-class solutions from across vendors.
To learn more about the XDR market, read our post about how XDR evolved to fill a gap in legacy security tools. As always, let us know if there’s a topic around XDR that you’d like discussed.