Security products collect data regarding a variety of different events that occur within a business day. These events vary from user-accessed file information to registry modification on a device. Example of the types of data collected include but are not limited to:
The capability to collect telemetry is not new or unique. What differentiates XDR platforms is which data is collected and what is done with it.
An XDR platform built primarily on its own native security stack has the advantage of having a deep understanding of the data and can therefore collect exactly what is needed to optimise analytical models for correlated detection, in-depth investigation, and threat hunting.
Vendors who are primarily focused on pulling data from third-party products start with less understanding of the associated data. Likely they are not getting the type and depth of telemetry needed to understand the full context of the issues. Most will look at alert data that does not provide related activity data (e.g., telemetry, metadata, NetFlow) to run analytics to drive actionable insight.
How telemetry is structured and stored is as important as what telemetry is collected. Depending on the activity data, different databases and schemas are more appropriate at optimising how the data is captured, queried, and used. Selecting the most efficient structure of the data lake build based on data characteristics enables it to serve the data usage best. For instance, for network data, a graph database might be the most efficient, but for endpoint data, Elasticsearch might be preferable. Having various data lake structures set up for different telemetry can make a significant difference in leveraging the data’s efficiency and effectiveness for detection, correlation, and search. Trying to fit the data within a single, common schema means losing a depth of capability.
SIEM aggregates logs and alerts well; however, it is not as efficient at connecting multiple alerts identified with the same incident. This would require evaluating its root telemetry across security layers.
Leveraging telemetry, XDR alerts can consider not only alert information but other critical activities in order to identify suspicious or malicious activity. For example, PowerShell activity on its own may not result in a SIEM alert, but XDR can look at that alongside other endpoint activities, and when considered together, identify it as part of a core event.
By running detections models on the collected telemetry, an XDR platform can identify and send fewer, higher-confidence alerts to the SIEM, reducing the amount of triage effort required by security analysts.