Understanding Telemetry Sources

Understanding Telemetry Sources

This lesson introduces the telemetry sources that feed modern detections. Students learn the difference between logs and telemetry, what endpoint, network, cloud, and application data can reveal about attacker behavior, and how to think critically about the evidence each source provides.

Logs Versus Telemetry: What Is the Difference?

In security conversations, people often use the words log and telemetry as if they mean the same thing. They overlap, but the distinction matters for detection engineering.

What is a log?

A log is a record of an event. A web server writes a line in a log file every time it receives a request. An authentication system writes an entry when a user logs in or fails to log in. Logs are usually human-readable text and are generated by applications, operating systems, and network devices.

What is telemetry?

Telemetry is broader. It is any data collected from a system that describes its state or activity. Telemetry can include logs, but it also includes structured events, metrics, traces, and real-time streams. Endpoint detection and response tools, for example, collect rich telemetry about process creation, file changes, network connections, and registry modifications. That telemetry is often structured and designed for analysis, not for reading in a text editor.

Why the difference matters

A detection engineer must know whether the data is a simple log line or rich structured telemetry. Logs can answer what happened. Rich telemetry can answer what happened before, what else changed, and what happened next. That context is often the difference between a weak detection and a strong one.

For example, a single log line might show that a new process started. Endpoint telemetry can show the parent process, the command line, the user account, the file hash, and any network connections the process made. The log tells you one thing; the telemetry tells the story.

The Four Pillars of Detection Data

Detection data generally comes from four broad pillars. Each pillar has strengths and blind spots, and mature detection programs use them together.

Endpoint telemetry

Endpoint data comes from the devices people use: laptops, desktops, and servers. It includes process creation, file access, registry changes, scheduled tasks, loaded drivers, and network activity from the endpoint. Endpoint telemetry is often the richest source for detecting attacker techniques because many attacks require the attacker to run commands or modify files on a device.

Example: A process spawning a command shell and then making an outbound connection to an unusual IP address is visible in endpoint telemetry.

Network telemetry

Network data describes traffic moving between devices. It includes connection logs, flow records, DNS queries, TLS metadata, and intrusion detection alerts. Network telemetry is valuable because it covers devices that do not have endpoint agents, such as printers, cameras, and industrial systems. However, encrypted traffic limits what network data can reveal.

Example: A device making thousands of DNS queries to newly registered domains is visible in network telemetry.

Cloud telemetry

Cloud data covers activity in cloud platforms and SaaS applications. It includes API call logs, identity events, storage access, and configuration changes. Cloud telemetry is essential as organizations move workloads off-premises. Attackers increasingly target cloud identity and storage, and these actions may not appear in endpoint or network data at all.

Example: A user granting unusual permissions to a third-party application is visible in cloud telemetry.

Application and identity logs

Application logs capture activity inside specific software, such as a web application, database, or email system. Identity logs capture authentication and authorization events, including logins, password resets, and role changes. Identity is a critical detection surface because attackers often begin with stolen credentials.

Example: A single user account logging in from two countries within minutes is visible in identity logs.

Thinking Like an Attacker: What Evidence Would You Leave?

A detection begins long before any rule is written. It begins with a simple question: if I were attacking this system, what traces would I leave behind?

The evidence-first mindset

Instead of starting with a tool or a query language, start with the adversary. Walk through the attack step by step and ask what evidence each step would create.

For example, suppose an attacker wants to steal files from a server. They might:

• Guess or steal credentials. This creates authentication logs, especially failed logins.
• Log in remotely. This creates a successful authentication event from a new location or device.
• Run commands to search for sensitive files. This creates process execution telemetry.
• Copy files to an external location. This creates network connection data and possibly file access records.

Each step leaves a trail. The detection engineer’s job is to identify which trail is observable with available data and which observable trail best distinguishes malicious activity from normal activity.

What makes a good detection signal?

Not every piece of evidence is equally useful. A good signal has three qualities:

• It is observable. You actually have the data.
• It is specific. It does not happen constantly in normal operations.
• It is reliable. It is difficult for an attacker to avoid or spoof.

For example, a failed login is observable and sometimes specific, but it is easy to generate by accident. A new process running from a suspicious folder with an unusual command line and an outbound connection is more specific and harder to fake. The strongest detections combine multiple pieces of evidence into a single pattern.

This mindset, thinking from the attacker’s perspective first, is a core habit of effective detection engineering. It keeps you focused on threats, not on tool features.