Endpoint Detection and Response (EDR) products have become essential to organizations’ cybersecurity strategies. As a result, understanding the telemetry provided by these products is crucial for building additional detections and conducting threat hunting.

Having the appropriate logs is important for creating detection rules as well as for responding to detection alerts. Trained analysts spend less time investigating those alerts or threat-hunting for other malicious activity when they have the logs they need. An EDR can be an invaluable source of telemetry that encapsulates numerous data points. Unfortunately, not all EDRs provide the same wealth of telemetry that would aid analysts in drawing conclusions more quickly during an investigation.

In this article, we will discuss the goal of the EDR Telemetry project, what it is, and what it is not, and how we think it can help EDR vendors and consumers alike.

EDR telemetry refers to the data collected and transmitted by Endpoint Detection and Response (EDR) products and tools. EDR products are designed to monitor, detect, and respond to potential threats and suspicious activities on endpoints, such as computers, servers, and other devices within a network. The telemetry data generated by EDR systems can be used to provide valuable insights into the security events and activities occurring on the endpoints.

In the context of this project, telemetry is defined as a source of data that is automatically collected and transmitted by a sensor in real time.

The main goal of the EDR Telemetry project is to encourage EDR vendors to be more transparent about the telemetry they provide to their customers. Almost all EDR vendors have their detection rules hidden for many reasons, such as intellectual property protection and competitive advantage. However, we believe telemetry is slightly different, and vendors should be open about the raw telemetry their products can generate. When EDR vendors are open with their telemetry, users can better understand the data collected and use it to build custom detection rules tailored to their specific environments and security requirements.

By comparing the telemetry generated by different EDR products, the project aims to help users make informed decisions when selecting EDR products. However, telemetry is only one of the many attributes that make an EDR great; therefore, this project should not be used as a definitive method of comparing EDR products.

The methodology for populating the comparison table for the EDR-Telemetry project involves a systematic approach to ensure the accuracy and reliability of the information presented. First, we analyze the table schema of each EDR vendor based on their documentation. We then populate the table with the appropriate values.

In cases where the table schema analysis from the available documentation does not provide sufficient evidence for a conclusive decision on a specific category or a sub-category, we proceed with independent testing using methods such as the Atomic Red Team project. This approach involves executing the appropriate technique from the Atomic Red Team repository that would yield the expected telemetry results. For instance, to evaluate the scheduled task creation sub-category, we would run Atomic Test #2 — Scheduled Task Local. This comprehensive and efficient testing process ensures that the comparison table is populated with accurate and reliable data.

In addition to the analysis and testing processes, all contributors involved in the EDR-Telemetry project are required to provide evidence supporting the information they provide before it is added to the comparison table. This evidence can take various forms, such as raw logs, public or private documentation, or screenshots. By ensuring that all contributions are backed up with verifiable evidence, we maintain the integrity and accuracy of the data presented in the comparison table.

The Telemetry Comparison Table is a central component of the project, comparing the available telemetry for different EDR products. It is important to note that the data in the table do not represent the capability of each EDR product to detect or prevent a threat. Instead, this comparison focuses solely on the available telemetry for each product.

Link to Table: https://docs.google.com/spreadsheets/d/1ZMFrD6F6tvPtf_8McC-kWrNBBec_6Si3NW6AoWf3Kbg/edit?usp=sharing

Criteria for Including Telemetry Events in the Telemetry Comparison Table

The Telemetry Comparison Table focuses on out-of-the-box events, not signals (detections/correlating events) or additional modules/integrations. This is because tracking different configurations and including other modules offered by EDR vendors would be challenging. Therefore, only out-of-the-box default telemetry events available to customers after installing the sensor are considered for comparison.

In this initial release, we decided to focus on event categories that we believe provide the most useful information that aids in threat hunting and threat detection. Some of these are explained below:

1. Process execution: Information about processes running on endpoints, such as process names, command-line arguments, and parent-child relationships.
2. File system activity: Details about file creation, modification, deletion, and other file system events.
3. Scheduled tasks and services: Information about scheduled tasks and services running on endpoints, including task names, execution times, triggers, actions, and service status. This data can help security teams monitor and identify potentially malicious tasks or services that may be used by attackers for persistence, lateral movement, or privilege escalation.
4. Network connections: Information about network connections made by processes, including IP addresses, port numbers, protocols, connection states, etc.
5. Registry activity: Data related to changes in the Windows registry, such as the creation, modification, or deletion of registry keys and values.
6. User activity: Details about user logins, logouts, and other user-related events on the endpoints.
7. System configuration changes: Information about changes in system settings, security policies, and other configuration details.

While the project aims to provide valuable insights into the telemetry provided by different EDR products, it is essential to understand its limitations:

1. The list may not always be up to date, as the telemetry capabilities of EDR products may improve over time.
2. The project currently focuses on Windows operating systems but plans to include Linux and MacOS at later stages.
3. When possible, we often opt to get a trial of the EDR product and validate the telemetry it produces based on various tests, such as via atomic-red-team tests to generate the necessary telemetry. When a trial is out of reach, we can only include the information that we are provided by contributors based on the vendor’s documentation.

We would like to invite EDR vendors to directly contribute to this project, either by correcting the existing information or by providing us with their documentation and temporary access to their products through trials in order to validate the telemetry sources.

The EDR Telemetry project plans to map the Table Event Categories and Sub-Categories to MITRE ATT&CK® and the Mitre DEF3ND project. Additionally, as more vendors make their telemetry available, the table will be updated to include any missing information or additional events.

If you have information about an EDR product’s telemetry not listed in the repository, you can contribute by submitting a pull request or opening an issue with the relevant information. Please contact me (@kostastsale) or @ateixei on Twitter if you want to share the proof of the proposed additions privately. The project relies on the community’s support in improving and taking it to the next level.

In conclusion, the EDR Telemetry project promotes transparency and encourages EDR vendors to share their telemetry data. With a focus on comparing telemetry provided by different products, the project helps users make informed decisions when selecting EDR products for their specific needs.

• Official project page: https://github.com/tsale/EDR-Telemetry
• Comparison table: https://docs.google.com/spreadsheets/d/1ZMFrD6F6tvPtf_8McC-kWrNBBec_6Si3NW6AoWf3Kbg/edit?usp=sharing
• Contribution Guidelines: https://github.com/tsale/EDR-Telemetry/wiki/FAQ
• FAQ: https://github.com/tsale/EDR-Telemetry/wiki#contribution-guidelines

Special thank you to the following individuals that reached out and contributed to this initial version of the project:

@CrimEvader @Sam0x90 @WikiJM @jamesspi @br0k3ns0und @nas_bench @cbh_security