From Network Visibility to Cybersecurity: The Main Myth About Network Telemetry That Hinders Unlocking NetFlow's Potential

Today, I want to talk about the benefits of NetFlow and network telemetry for protecting networks from hacker attacks. This topic is not new, but there are still many controversies surrounding it.

Network telemetry is often perceived as an artifact from the world of network engineers, rather than a serious information security tool. Typically, this is due to the misconception that NGIPS systems are equivalent to NTA. In this case, the primary functionality is considered to be signature-based attack detection, which requires only raw traffic to work. Meanwhile, methods of behavioral analysis, machine learning, and other non-signature techniques in such systems are complementary and do not form the core of the detection logic.

For example, the Cisco SourceFire NGIPS solution (2013 datasheet) also uses only raw traffic, and its functionality strongly overlaps with a typical domestic network traffic analyzer, which positions itself as NTA or NDR. The Cisco product relies on signature-based methods, payload analysis, reputation databases, and complementarily uses machine learning for detecting malware like worms.

Due to this widespread misconception in the Russian market, a common false belief has formed: to detect network threats, only raw traffic analysis is needed, and telemetry is not suitable for this.

Below the cut, I will explain how to detect threats based on network traffic metadata without analyzing the payload, specifically using network telemetry.

What is network telemetry, and why is it needed

Strangely enough, confusion often arises here. Some people mistakenly classify data collected by endpoint protection agents as network telemetry. In reality, that is not the case.

Network telemetry is statistics of network flows collected from network equipment of L2 level and higher: switches, routers, firewalls and other devices. The most common protocol for collecting such telemetry is NetFlow.

A bit of history

NetFlow is a network telemetry standard developed by Cisco in 1996. In fact, it has become synonymous with the term "network telemetry" and the most widely used tool for analyzing what is happening on a network. There are several versions of the protocol; the tenth version is known as IPFIX (Internet Protocol Flow Information Export).

NPM (Network Performance Monitoring) class solutions are built on top of NetFlow. For example, the solution from the well-known vendor SolarWinds (which has already withdrawn from the Russian market). Some manufacturers use their own telemetry protocols: NetStream (Huawei), JFlow (Juniper), AppFlow (Citrix).

Why network telemetry is needed

NetFlow allows detecting threats in networks where it is difficult or impossible to obtain a copy of network traffic. Here are a couple of examples of such cases for illustration.

The first example is a data center. It processes huge data streams of hundreds of Gbit/s, and the complexity and high cost of analyzing such a volume of raw traffic make NetFlow the only source of network data in the data center.

Another option is geographically distributed decentralized networks with a large number of separate internet access points: stores, small offices, educational or medical institutions, and so on. Capturing a traffic copy (SPAN) in such networks can be difficult due to outdated equipment, communication channel limitations, or network topology.

Telemetry Sources

There is a fairly wide range of equipment from different manufacturers available for collecting network telemetry: from Enterprise-class devices such as Cisco, Huawei, Eltex, Juniper, Extreme, Fortinet, to SoHo-level solutions including Mikrotik, D-Link, TP-Link, Zyxel, Asus and others.

Sampling: When telemetry becomes useless for information security

An important nuance: information security tasks significantly limit the use of sampled (reduced) telemetry, such as sFlow. During sampling, we lose metadata for each session: communication frequency, individual session volumes, and precise quantitative parameters.

All this breaks the features required to build models of normal host behavior and detect anomalies.

For information security purposes, full non-sampled telemetry is required.

What does IPFIX provide? Key parameters

Data obtained from network telemetry has been covered many times before, but I will still repeat a few interesting IPFIX parameters:

• Sender and receiver IP and MAC addresses;

• Sender and receiver ports;

• Transport protocol;

• TCP flags, including the reason for flow termination;

• Flow duration (start and end);

• Number of packets and volume of flow data;

• Autonomous Systems (AS);

• Type of Service (TOS);

• Application (DPI equivalent) — if supported on the exporter side;

• HTTP metadata: user-agent, content type and other parameters.

It is interesting that Cisco network equipment supports its own DPI — NBAR, which contains an extensive database of L3–L7 level protocols and applications. Otherwise, DPI data can be transmitted to IPFIX by the exporter, for example, NGFW.

Information Security (InfoSec) scenarios for which network telemetry-based analysis can be applied

Reputation Analysis (Threat Intelligence Feeds)

The simplest option is checking IP addresses against reputation databases (TI feeds). For example, in our product «Garda NDR» we use Threat Intelligence data. These feeds include:

• C&C (Command and Control centers);

• Botnet activity;

• DDoS;

• Cryptocurrency mining;

• TOR, proxies;

• Phishing, malware;

• Brute force, spam, suspicious hosts.

In the advanced version of TI feeds, additional enrichment fields are available: Autonomous Systems, date of last activity.

But IP addresses are just the start. What about hostnames that are not present in standard telemetry? We use a module for analyzing DNS queries to corporate DNS servers, along with our own proprietary system for enriching session metadata at the stage of assembling sessions from packets. This allows us to check hosts against TI feed lists. Reputation lists can come in a wide variety of forms — the key requirement is that they include supported parameters such as IP addresses, hostnames, and others.

Corporate infrastructure and Shadow IT

Basic IP/MAC data is sufficient to build subnet profiles by IP address or port, detect new protocols, IP addresses, or violations of network segmentation rules on firewalls.

But what if there is no DPI and only the port is known? In this case, we use our own proprietary port-to-protocol mapping database, which helps identify non-standard ports for known protocols. It is clear that this approach is only effective for static ports. For dynamic ports, extracting the applicationId will be required.

Network telemetry can also be used to detect non-corporate DNS, DHCP, or even spoofed domain controllers. The logic is simple: we look for traffic outside of designated corporate resources. For this, user asset groups are used. We use a logical asset group builder with hierarchy support to scale the detection logic across geographically distributed sites. For example, for DHCP, we detect the use of ports 67/68 for all hosts that are not part of the DHCP server group.

Thus, in any infrastructure, there are zones where NGIDPS based on payload analysis is ineffective. The same applies to Red Team tools with open-source code: a signature can be written for each one, but modifying the tool makes the signatures useless. APT groups use customized tools.

How to detect attacks in network telemetry without payload

The answer is through non-signature methods by building profiles of normal network traffic and identifying anomalous deviations. This approach is known as NTA (Network Traffic Analysis) and emerged back in 2017. Pioneers of non-signature detection using machine learning were Vectra (since 2011) and Darktrace (since 2013).

Since 2020, NTA has evolved into NDR. In 2025, Gartner released the first quadrant for the NDR (Network Detection and Response) segment. All four leaders in the quadrant use network telemetry in their work.

From the point of view of non-signature analysis, the difference between full traffic capture and telemetry is in the volume of metadata. ML models for detecting anomalous deviations from normal behavior work precisely with metadata (similar to the Zeek principle), rather than with payload, like IDPS.

Why network telemetry is becoming a new trend

A logical question arises: "Why has the transition to telemetry become a trend precisely now?". It is not only about the efficiency of algorithms, but also about the physical impossibility of using old methods in modern infrastructures. The classical approach of analyzing a full copy of traffic (SPAN) runs into the explosive growth of private and public cloud infrastructure volumes. This applies both to the ability to analyze large volumes and to cost considerations.

Global Trend: Clouds and Telemetry

Analyzing huge volumes of data in clouds (Amazon, Google, Azure) is a modern global trend. Clouds support a specific format of network telemetry — VPC Flow Logs.

Specifically to work with telemetry in the cloud, Vectra acquired the startup Netography, which specializes in cloud security and the analysis of NetFlow, sFlow, IPFIX, and VPC Flow Logs. The founder of Netography is Marty Roesch, the creator and developer of the IDPS Snort, founder of the company SourceFire, which was acquired by Cisco.

It is symbolic that the founder of the classic legendary IDPS is now advancing the analysis of network telemetry.

Situation in Russia

In the Russian Federation, on-premise infrastructure still dominates, but the need to analyze large volumes of data does not go away. Essentially, in the enterprise segment, public clouds are replaced by private ones.

The main advantage of network telemetry is its size. It constitutes approximately 5–10% of the volume of raw data. This is especially important with high channel utilization and large traffic volumes.

Threat Detection Based on Behavioral Analysis in Network Telemetry

Now, to the point. How exactly are threats detected in network telemetry?

Spoiler: exactly the same way as with traffic copies — via metadata.

This involves using specific features for each host, building its profile (baseline), and identifying anomalous deviations. Features must be available in the telemetry or can be enriched with external data.

Using ML allows comparing a host's behavior to its predicted profile. It can be built in two ways:

• Historically — by comparing the host to its own behavior in prior time periods;

• By similarity — by comparing the host to other hosts that are inherently similar to it.

Unsupervised learning models are used to build profiles. They are trained on data directly on-premises.

For certain types of attacks, it is more effective to analyze («sender – receiver») pairs with an individual prediction for each pair. For example, this is important for brute force, password spraying, or tunneling.

To improve detection accuracy, it is extremely important:

• to build individual profiles for each host or pair (rather than for groups);

• to use small time intervals (for example, a session spike over five minutes is very distinct, while the same spike over five hours is blurred).

Unsupervised learning can also be used to detect certain types of attacks. For example, communications with C&C or C2, and the use of tunnels to mask them. To detect some malware, ML models trained on datasets with examples of malicious and normal traffic can be used.

For working with network telemetry, the features of ML models must be supported in the network telemetry.

This approach was implemented in Encrypted Traffic Analysis by Cisco. In the SNA (formerly Stealthwatch) solution, based on enriched network telemetry of encrypted traffic, the vendor classified various flows containing different types of threats.

Improving accuracy with TI feeds

What is not supported using network telemetry?

It is important to understand not only the capabilities but also the limitations of network telemetry. The first limitation is IDPS. Any logic that requires analysis of payload or protocol command content cannot be implemented using only network telemetry. The second limitation is deep analysis of application layer protocol content.

Conclusion

Network telemetry is not a replacement for full network traffic analysis. However, it is a powerful information security tool in cases where traffic analysis is impossible or severely restricted:

• during high network loads (hundreds of gigabits and above);

• in geographically distributed networks with multiple exit points;

• in cloud environments with large volumes of transferred data (VPC Flow Logs).

The longstanding myth that NetFlow is "only for IT" has long been debunked in practice. Modern NDR solutions are built specifically on non-signature analysis of network traffic metadata, rather than relying solely on IDPS system signatures.

This fact is also confirmed by our analytics. According to data from the research we conducted, more than 50% of NDR-class solutions on the global market work with network telemetry and its analogs.