Understanding Open XDR
What Is Open XDR?
XDR stands for eXtended (or Cross Platform) Detection and Response. Its aim is to integrate disparate tools over the security stack—EDR, SIEM, cloud, and more—to provide a single, comprehensive view of threats so that your organization can discover, investigate and react faster to protect itself.
Open XDR (also known as hybrid XDR) is distinct from native or vendor-specific XDR platforms. Open XDR is vendor-agnostic, and delivers deep integration over best-of-breed tools from multiple vendors. Open XDR combines advanced analysis and field-validated content with existing technology deployed in the field, to reduce complexity, increase visibility and improve risk management.
Open XDR vs Native XDR
XDR is primarily broken down into two types:
Mainly deals with third-party integration.
Offers an all-in-one platform.
Each type of XDR platform offers advantages for their different use cases.
Open XDRs are suited to organizations that have several vendors deployed over their IT and security environment. Security programs that are more sophisticated, and generally those at bigger organizations that might have more resources, will likely have deployed best-of-breed security tools over multiple vendors. An open XDR indicates that they don’t need to rip out and replace the front-end sensors that are in use to make room for the walled-garden method of native XDRs.
Open XDRs are, by their nature, created to efficiently integrate a broad variety of other technologies into coherent search schema. Organizations can rationalize and augment their current toolset, enhancing their value and output by layering an open XDR on top of the security stack to centralize threat detection, response, and investigation requirements. Security teams can also add new tools and mix and match elements from vendors while benefiting from their open XDR.
For organizations with a more homogeneous IT security and infrastructure, a native XDR product could be sufficient. The assumption, which should be verified through a POC, is that a single vendor can more effectively integrate across the front- and back-end capabilities within the ecosystem of that vendor.
Organizations with security products issued by a single vendor could discover that their vendor’s XDR is a natural choice. However, there may be gaps both in depth and coverage — especially where that vendor doesn’t provide key detection capabilities. A single native XDR vendor will not be capable of offering a comprehensive level of security coverage over all attack vectors, and might not have the depth of capabilities in all the areas where it does cover. The IBM and Ponemon 2021 Breach Report indicated that the resolution of a breach typically involved data from 19 tools. Finding 19 appropriate tools from a single vendor is no small feat.
What’s more, with this approach customers may experience vendor lock-in, meaning they might need to give up preferred tools made by other vendors and have to settle with those made by their XDR vendor. This might mean that, for example, the organizations have to rip and replace their EDR to take on a native XDR.
Open XDR vs SIEM: Solutions Compared
Security information and event management (SIEM) systems are the precursor to XDR platforms. Like XDR, SIEMs collect data from across the organizations and different tools, then organizes the log and event use for threat detection, investigation and response (TDIR). In some respects a SIEM has a broader scope than XDR, including functions like long term data storage, and compliance reporting.
In many Security Operation Centers (SOCs), it is unlikely that XDR will fully replace SIEM. Both systems will likely coexist, each serving a different function. Below we explain the key differences between SIEM and open XDR.
|Domain Coverage||Multi domain coverage, including threat detection, investigation and response (TDIR); reporting; compliance and; centralized storage.||Single domain coverage (TDIR).|
|Design Approach||Created for customization and “emergency” situations.||Created to be centered around efficient TDIR.|
|Data Location||Generally assumes that the data must be centralized in the SIEM.||Generally assumes that data might be retained anywhere and/or doesn’t have to be retained for the long term.|
|Delivery Model||Can be cloud-delivered, on-prem, or both.||Cloud-delivered.|
|Storage||Provides an infinitely scalable storage.||Doesn’t necessarily provide long-term storage.|
|Detection Approach||Generally centered on correlation-based analytics.||Generally provides machine learning-based advanced analytics.|
|Automation Approach||Generally provides automation; highly flexible orchestration and; playbooks for TDIR and non-TDIR use cases.||Generally provides automation; prepackaged, use case–specific TDIR with prescriptive orchestration and; playbooks.|
|Market Position||Generally replaces or displaces CLMs, legacy SIEMs, and/or data lakes.||Generally augments CLMs, legacy SIEMs, and/or data lakes.|
This comparison deals only with the differences. There are also various technical similarities, such as open integration with security tools, long-term storage, efficient search and threat-hunting and cloud-nativity.
Related content: XDR vs SIEM
Open XDR vs SIEM: 3 Technical Differences
Open XDR has four core architectural differences from SIEMs.
1. Data Normalization and Analysis
In XDR, data is forced into an enriched and normalized state, and this is carried out before the data is stored in a data lake. SIEM commonly saves data in its original form from the original logs or event sources.
For an XDR, correlation and detections of alerts are automatically driven by AI, while SIEM uses human-written correlation rules to create events of interest. This often requires specialized knowledge or experience, which are not available on every staff.
XDR’s pre-processing stage addresses the problem of data quality and standardization, which is required to build and sustain meaningful AI. In security, this indicates that the data must be centralized, enriched and normalized to minimize data complexity. If data is modeled in different ways at every deployment of a platform, it will be impossible to maintain AI models.
XDR requires data to be modeled in the same manner over each deployment before it lands into a Data Lake; data only available in its enriched or normalized state.
SIEM either offers this as optional functionality or does not offer this feature; in the optional scenario, enrichment and normalization is approached as a post processing step on raw data, which is already in storage. Therefore, SIEM architectures struggle to produce an AI engine of equal fidelity as XDR. SIEMs can leverage AI, however, it will be more challenging to scale.
2. Alert Triage
In XDR, incidents are created from correlated alerts, from which one response on the same platform is orchestrated. In comparison, the SIEM sends alerts to a distinct SOAR platform which then carries out downstream response and correlation.
Open XDR performs response and correlation as part of the platform. A higher-order construct is built from individual security events, and the Open XDR platform responds to the incident as a whole.
In contrast, a SIEM passes alerts to a SOAR, which has to correlate alerts along with a limited set of rules without deeper analysis of everything occurring in the environment. Open XDR creates a response like SOAR and SIEM do, however, the response fidelity is noticeably improved, because XDR uses AI-driven correlations and detections, where all the data is accessible.
3. Unified Tooling
In an XDR model, the tools needed for security operations are unified into one platform, including UEBA, data lake, SOAR, TIP, EDR, or NDR. SIEMs only include a data lake, meaning that SIEM users must integrate various complex tools by themselves. Many SIEM solutions provide extended lists of deep customization and plugins, but the responsibility for configuring and building the system is placed on the user or integrator.
The main impact of this difference is the time, capital and resources it requires to operate a security platform. SIEMs are expensive to operate because they are open-ended technologies. Open XDR platforms are prescriptive technologies, thus organizations can employ them more efficiently.
Open XDR vs SIEM: Which Is Right for Your Organization?
If the functional coverage solely focused on TDIR over a heterogeneous stack, then a tool addressing that function (open XDR) could be a better choice. This offers a shorter time to value than a general-use tool, like a SIEM.
However, if the functional coverage extends beyond TDIR, then a SIEM might be best. The XDR may not be capable of addressing these added requirements—for instance, if they involve centralized storage or compliance.
An organization might wish to begin with a specific requirement on TDIR and then seek to expand their scope to different parts of security operations, including log or compliance centralization. These organizations must find vendors that provide an open XDR with a simple upgrade path to a SIEM with full-features, for instance by adding compliance packages, storage, or non-TDIR dashboarding capabilities.
Irrespective of the above, an organization must prioritize tools that provide pre-packaged content for basic and advanced use cases, which could be delivered at scale with an outcome-based strategy.
Exabeam Open XDR
Exabeam Fusion XDR, a cloud-delivered solution, is an Open XDR that takes an outcome-based approach and offers prescriptive workflows and pre-packaged, threat-specific content to efficiently solve threat detection, investigation, and response (TDIR).
Pre-built integrations with hundreds of 3rd party security tools and our market-leading behavior analytics combine weak signals from multiple products with understanding of normal operating behavior to find complex threats missed by other tools. Prescribed workflows and pre-packaged content focused on specific threat types enable SOCs to achieve more successful TDIR outcomes. Automation of triage, investigation, and response activities from a single, centralized control plane turbocharges analyst productivity and reduces response times.
See Exabeam in action: Request a demo