What Is XDR Telemetry

XDR telemetry refers to the data collected by specific security solutions – including but not limited to email, endpoint, server, cloud workload, and network. As each security layer or solution contains varying types of activity data, an XDR platform collects telemetry to detect and hunt for unknown threats and assist in root cause analysis.

Telemetry type by security layer

Security solutions collect data on a variety of events that occur within a day. These events vary from user-accessed file information to registry modification on a device. Examples of the types of data collected include, but are not limited to, the following:

Network events

  • Traffic flow patterns
  • Perimeter and lateral connections made
  • Suspicious traffic behaviors
  • TLS (formerly SSL) fingerprints (JA3)

Cloud workloads

  • Configuration changes
  • New/changed instances
  • User account activity
  • Processes
  • Executed commands
  • Network connections
  • Files created/accessed
  • Registry modifications

Email

  • Message metadata (external and internal email)
  • Attachment metadata
  • External links
  • User activity (such as logins)

Endpoints

  • Processes
  • Executed commands
  • Network connections
  • Files created/accessed
  • Registry modifications

How collected telemetry makes a difference

What differentiates XDR platforms is the type of data collected and how it is used.

An XDR platform built primarily on its own native security stack has the advantage of a deeper understanding of the data. This enables the platform to collect precisely what is needed to optimise analytical models for correlated detection, in-depth investigation, and threat hunting.

Vendors who primarily pull data from third-party products unfortunately begin with a lesser understanding of the associated data. These vendors are likely missing the type and depth of telemetry needed to understand the full context of a threat.

Although it is common practice to look at telemetry, metadata, and NetFlow, this alert data actually does not provide related activity information required to run analytics and drive actionable insight.

Understanding the way telemetry is structured and stored is as important as understanding the telemetry collected. Depending on the activity data, different databases and schemas are better at optimising how the data is captured, queried, and used.

Using network data as an example, a graph database would be the most efficient, but for endpoint data, the open search and analytics engine Elasticsearch would be preferable.

Having various data lake structures set up for different telemetry can make a significant difference in the data’s efficiency and effectiveness for detection, correlation, and search.

XDR telemetry vs. SIEM alerts

While SIEM is effective at aggregating logs and alerts, it is not as efficient at connecting multiple alerts identified with the same incident. This would require an evaluation at the root telemetry level across security layers.

Leveraging telemetry, XDR alerts consider alert information as well as other critical activities designed to identify suspicious or malicious activity. For example, PowerShell activity on its own may not result in a SIEM alert, but XDR is able to assess and correlate activities across several security layers, including the endpoint. 

By running detection models on the collected telemetry, an XDR platform can identify and send fewer, and higher-confidence alerts to the SIEM, reducing the amount of triage required by security analysts.

Related Articles