Protecting your flow data: how to secure network flow data export and collection

RedSocks, a Dutch start-up company in the network security industry, has recently enhanced its product portfolio with a new product: the RedSocks Probe. In this blog post, I will elaborate on the unique features of the RedSocks portfolio in general and the RedSocks Probe in particular, which make a great leap forward in the context of secure network flow data export and collection.


Network flow monitoring has become one of the most popular approaches to monitoring network traffic in all sorts of networks, ranging from small and medium enterprise to ISP access and backbone networks. By aggregating individual packets into flows, flow monitoring benefits from major scalability advantages over individual packet analysis solutions. When it comes to security and privacy considerations, packet captures are by now considered one of the most sensitive kind of user data that must be handled with ultimate care, mostly driven by political discussions and reports on data leakages. Flow data, however, is far behind in this respect: although it is generally recognized that flow data carries information that allows for identifying individuals through IP address, for example, it is often transferred in an unencrypted fashion from observation points to data collection points, and subsequently stored in plain. As a consequence, any tap or breach immediately results in leakage of sensitive user data, often even to the public.

Flow monitoring architecture

To understand the security weaknesses of most flow monitoring setups, we first have to understand their overall architecture. A network flow is as per RFC 7011 defined as “a set of IP packets passing an observation point in the network during a certain time interval, such that all packets belonging to a particular flow have a set of common properties.” Individual packets that make up flows are captured at observation points, aggregated into flows by flow exporters and sent, using protocols like NetFlow and IPFIX, to flow collectors for storage. After that, analysis applications may retrieve the flow data from flow collectors for analysis. In principal, any flow monitoring setup is composed of any combination of these three building blocks; flow exporter, flow collector, and analysis application. Note that flow exporters are often part of high-end forwarding devices (i.e., routers, switches and firewalls), but can also be dedicated devices that receive network traffic over mirror ports or taps; in the case of a dedicated flow exporter, we usually use the term ‘probe’.

Security in traditional flow monitoring setups

When analyzing the state of security in traditional flow monitoring setups, we can identify three components where data breaches may occur or traffic may be tapped:

  1. Flow exporter – Probes often come with on-board storage to ease their deployment; instead of requiring two appliances (probe plus collector), only a single appliance has to be installed. Storage of flow data is typically unencrypted (although IP address anonymization may be performed sporadically) in the form of text-based storage, binary storage, or storage in any sort of DBMS. A breach of the system, e.g., by means of its Web interface or SSH, or perhaps even physical theft, therefore results in theft of unencrypted yet sensitive user data. Note that on-board storage is never available for flow exporters that are integrated in forwarding devices.
  2. Flow collector – Flow collectors store flow data in an unencrypted fashion, as described above for flow exporters with on-board storage.
  3. Transport between flow exporter and collector – Cisco’s NetFlow v5/v9 is the predominant flow export protocol/technology, which merely dictates support for UDP as the underlying transport protocol, providing no security in terms of encryption, authentication or integrity. Only IPFIX (as per RFC 7011) defines that (D)TLS should be used as the security mechanism for transport. If no security mechanism is available, one should use dedicated networks, such as VPNs, for transporting IPFIX messages. Even though many (commercial) flow exporters claim to support IPFIX, hardly anyone implements (D)TLS for securing IPFIX traffic.

Conclusion: established vendors support neither secure transport, nor secure storage; those aware of the unencrypted nature of NetFlow and IPFIX traffic are therefore forced to rely on dedicated networks.

The RedSocks approach

RedSocks is a protagonist of security and privacy, and therefore takes security and privacy in flow monitoring setups to the next level. First, the RedSocks Probe – a device that has access to full packet streams – is designed for point-to-point connectivity to a RedSocks Malware Threat Defender (MTD), e.g., for time synchronization, requires no dedicated Internet connectivity and has no on-board data storage. Captured data can therefore neither be leaked to the Internet, nor be stolen in the event of a breach. Second, the MTD, acting both as flow collector and as analysis application, provides encrypted (forensic) data storage. In addition, the MTD supports transport over encrypted channels using (D)TLS, so transport is secure when third-party flow exporters are used with the MTD. These features make the RedSocks portfolio a unique combination of devices for security and privacy-aware network monitoring.

By Rick Hofstede

Back to overview