Five Myths about NetFlow

Alicia Butler from Lancope wrote a interesting post about the 5th Myths about NetFlow. You can find the original post HERE

NetFlow is an important tool for incident responders, providing valuable insight into the activities that take place on organizations networks. NetFlow is capable of summarizing information about network traffic into brief records that may be maintained indefinitely, providing a running history of network connections that may be referenced during incident response.

With all the good NetFlow brings, there are still some misconceptions about NetFlow that need to be dispelled.

Myth 1: Complex Attacks Can’t Be Detected with NetFlow

On the contrary, NetFlow records are often used to identify complex attacks, allowing responders to identify indicators of compromise across a large amount of network traffic in a timely fashion. Furthermore, because NetFlow can see deep into the network, it can be used for behavioral analysis that identifies anomalous traffic patterns, network reconnaissance, policy violation, internal pivots, and more.

Myth 2: Full Packet Capture Makes NetFlow Irrelevant

Full packet capture is simply not a sustainable practice. Maintaining these records for an extended period of time requires extensive deployment of probes and massive storage capacity. Furthermore, analyzing records of full packet capture is very time consuming compared to the preprocessed data available from NetFlow.

Moreover, it’s not likely that a packet capture solution will be able to monitor pervasively throughout your network. You’re likely to be doing it at an access point that exists between your network and the outside world. Maybe you’ve got a little bit of packet capture scattered around within your internal environment, but it’s very difficult to capture every single packet that happens everywhere.

Myth 3: NetFlow Provides Insufficient Information

One of the biggest mistakes made in incident response is failing to conduct sufficient monitoring and surveillance to inform the response effort. NetFlow logs every communication taking place through a monitored device and provides information essential to incident responders. In its most basic configuration, NetFlow logs timestamps, source/destination IP addresses and ports, and the amount of information exchanged. Advanced configurations may include additional information requested by incident responders.

Myth 4: NetFlow Is Not Admissible Evidence

Incident responders can rest assured that NetFlow records can indeed be admissible in court. These records, gathered during the normal course of business, are often relied on as evidence in both criminal and civil trials. Various courts have repeatedly accepted NetFlow as a valid form of evidence of network activity.

Myth 5: NetFlow Degrades Performance

When NetFlow first came to market over 15 years ago, it had a significant impact on router and switch CPU consumption. However, NetFlow is now a core capability of network devices, which are optimized to perform NetFlow operations without significant performance impact. Generally speaking, networking devices operating under a 50 percent utilization rate should see an impact of less than 2 percent on CPU performance after NetFlow is enabled. From a bandwidth perspective, network overhead is usually between 0.1 percent and 0.3 percent of the monitored traffic.

To learn more about leveraging NetFlow for Incident Response download your free copy of the “Incident Response with NetFlow for Dummies” ebook.

One thought on “Five Myths about NetFlow”

  1. it is all correct about netflow except the Sampled Netflow.on higher end devices like Nexus switches you cant use full Netflow regarding to performance impact on the devices.from security point of view Sampled Netflow don’t add much visibility you need for security event handling.that is why we need SPAN/Tap and Packet-Capture-To-Netflow like Lancope sensor.just for your information Cisco add wonderful feature on Cisco Nexus as Nexus Data Broker.you no longer need matrix switches like GigaMon for traffic capture and multiplexing flow to a sensor

Leave a Reply to Ali-A Cancel reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.