Here we go again with “Next-Gen”: The new center square on the XDR buzzword bingo card.
Claiming Next-Gen doesn’t give a vendor an industry leading position in any market category, particularly for those who have only begun to recognize the value, and as a result, are taking a ‘supplement-what-we-have’ approach to find its place within the market. There is no question, that as an industry, we all need to do better to communicate how we deliver to the core customer need, instead of defining a market or marketing terms. This is true for XDR (extended detection and response).
In reality, XDR is a significant evolution in the market that can have real substance behind it and potential for great customer return. As an XDR solution provider ourselves, we are glad to see others increasingly validate the space by recognizing the need to move beyond EDR (endpoint detection and response). The problem, as is often the case in the security market, is that the differentiators and the value-drivers for XDR are in the nuances – the “what, why, how” technology details behind all the claims.
XDR data collection is not the issue
The ability to collect telemetry and logs is not new or unique...to anyone. More logs may technically mean more visibility, but it doesn’t, by default, mean more insight or quicker action (mean time to detect – MTTD or mean time to respond – MTTR). What differentiates XDR platforms is what is done with the data collected.
Ingesting multiple log streams and making it searchable could evoke several assumptions, but these may not be happening. These include:
- All of that data is used for automated correlation – XDR should have built-in detection models that cross what was previously data silos, in order to correlate, at scale, the events and activities that happen not only within, but beyond the endpoint, which is the core proposition of XDR.
- The data is used to graphically create an attack-centric view of an entire chain of events across security layers, with the power to run a root cause analysis, look at the execution profile of an attack, and identify the scope of impact across assets.
- There is an ability to take direct response actions across the multiple vectors that the data is being ingested from (let’s not forget the R in XDR means response beyond what is actioned on the endpoint).
While enriching existing endpoint telemetry with third-party data sources is a component of XDR, the ability to serve the customer need is dependent on being able to offer a full depth of detection and response capabilities for other layers. While legacy EDR vendors are building upon EDR by ingesting more data, many of the deep analytical capabilities and the investigation and response components remain siloed to the endpoint. And with little direct experience outside of EDR, their fundamental understanding of threat detection and response for other vectors can be lacking.
XDR layers make an impact
As a general rule, the more security vectors brought into a single, integrated XDR platform, the greater correlation opportunities, which will result in more comprehensive detection, investigation and response. A caveat to this is to ensure you consider the security layers that can drive the most impact. While endpoint often is the default, going beyond could mean vectors such as:
Email: Email is a natural extension point for XDR. While EDR can identify that a threat came into the organization via email, it can’t offer key details on the scope of compromised accounts and therefore can’t directly remove or stop the spread of the threat. Given that the vast majority of social engineering attacks start with email, combining email with endpoint detection and response is a powerful capability.
Network with network-centric sensors: Combining network and endpoint is also extremely valuable. It is important to note that network data gathered by an endpoint agent can be incomplete. For example it may not record all inbound/outbound IP traffic, and more importantly, an endpoint agent can only gather telemetry from endpoints on which it is installed. From a network perspective, the XDR advantage is seeing activity for those unmanaged devices the organization is blind to. These can be as simple as a contractor device or BYOD system. They can also be more complex like OT devices, such as printers, solar panels or even fish tanks! Many major breaches involve endpoints that didn't/couldn’t have an EDR agent installed.
Cloud Workloads & Applications: Threats target the cloud differently, requiring a new set of techniques and defenses to secure cloud applications that are rapidly deployed using workloads, containers, serverless, cloud networking and cloud file storage. These environments require workload and cloud infrastructure discovery capabilities that integrate with major public and private cloud providers like Amazon Web Services (AWS), Microsoft® Azure™, Google Cloud Platform™ (GCP). With this integration, the security operations center (SOC) benefits from automatic visibility of new cloud infrastructure and specific applications/workloads enabling them to sweep, hunt and determine root cause across a wider set of data. Furthermore, vulnerabilities and network-based attacks don’t stop in the cloud so using intrusion detection / prevention (IDS/IPS) technology that rapidly examines cloud attacks is an important layer to consider. Many other vendor solutions simply cannot look at the network layer resulting in further blind spots and slower detection. Lastly, with a substantial portion of cloud workloads and applications based on Linux®, you need to have a platform that continues to support hundreds of builds and kernels of these platforms in use.
XDR is more than superficial integrations
A superficial description of an XDR solution that leverages the provider’s security stack is to describe it as monitoring and analyzing events from a product suite. This shows a lack of understanding of the advantages of a platform approach with native integrations.
XDR should deliver not only a unified data layer, but a unified platform for all detection and response activities.
Regarding the unified data layer, let’s consider that a vendor, with its deep understanding of the data from its own sensors, will:
- Know exactly what data to collect to optimize cloud-scale security analytics engines for correlated detection and in-depth investigation. This ensures only needed, relevant and contextual data is collected.
- Be able to build models based on the depth of its threat intelligence. Consider Trend Micro Research with 15 global threat research centers, hundreds of security experts and data scientists that are constantly gathering intelligence and products whereby 119,000 threats are blocked per second, according to the 2020 roundup report, over half a million customers.
- How best to define, structure and store the data.
- Definitions of detections and severity indicators can vary as each vendor defines their data differently. A vendor will never have the same depth of understanding of a third-party vendor’s logs as they would their own. Without this, it will always be more difficult to normalize the data (reconcile to a common interpretation) – this is the key to being able to leverage expert analytics on the data for deep analysis.
- One database type does not fit all, so knowing and being able to select the most efficient structure based on data characteristics enables the vendor to optimize data usage and avoid bloated data lakes. For instance, for network data, a graph database might be the most efficient, but for endpoint data, Elasticsearch or another database type might be preferable. Invisible to the customer in its architecture and solution performance, having various data lake structures set up for different telemetry can make a significant difference in the efficiency and effectiveness of leveraging for detection, correlation, and search.
This is not to say third-party integrations are not important or don’t add value, but an XDR approach that is defined by third-party integration simply can’t deliver the same capabilities. Certainly, customers will undoubtedly have other security tools or technologies deployed in their environment, so integrations are needed to acquire meaningful data that can enrich and validate XDR alerts. However, these integrations may not offer optimized detection or support the full user capabilities needed to visualize an attack, investigate each stage and take direct response from a single console.
XDR is a purpose-built platform
Legacy EDR vendors told us that their solutions were uniquely designed to solve the customer challenge of endpoint detection and response, and this set them apart to the endpoint protection vendors who were adding EDR capabilities. Interestingly, these same vendors are now taking their existing architectures and are adding XDR capabilities, often through third-party integrations, claiming this bolt-on approach as Next-Gen.
Given the scope of XDR, the argument for the need for purpose-built solutions finally comes to fruition. Those XDR solutions with the greatest capability and potential are those that have been built from the ground up to offer XDR.
There are fundamental differences to effectively ingesting, analyzing and acting on data across multiple security layers, as compared to what is needed for the endpoint alone. Data needs are different, investigation views/actions are different, response options differ, and the list goes on.
XDR focuses on the things that individual detection and response solutions can’t do alone.
At the end of the day, it is about giving organizations a means to see more and respond faster. It’s about breaking down the silos, minimizing the noise, and empowering the security analyst to defend the organization with confidence and speed.