Network Incident Response with NetFlow and Metadata

I spent this week in Las Vegas at CiscoLive, where I had the good fortune to speak with and learn from hundreds of network and security professionals. In addition, I had the opportunity to present as part of the Cisco Think Tank Theatre. This blog will document the important topics I learned about as well as share an overview of what I presented at the show.

The most glaring topic that became abundantly clear was the giant gap that currently exists in the market between the avalanche of security-related data and an organization’s ability to take a data-driven approach to network incident response. This gap is caused by a lack of contextual data. NetFlow and metadata summarized by the existing network infrastructure is, in my opinion, the most underutilized source of valuable data out there today!

The Network Knows

I kicked off my Think Tank presentation with the notion that every “one” and “zero” that makes up your business-critical applications traverses the network. The network sees everything, making it the most reliable source of truth and the best place to gather and provide data. Existing switches, routers, firewalls, probes, and other devices are able to summarize this network data and export it via NetFlow and IPFIX to collectors like Scrutinizer. NetFlow was invented by Cisco, and is therefore proprietary to their products. It comes in many different versions, but the most popular are NetFlow version 5 and version 9. IPFIX is an industry standard, and enables vendors other than Cisco to export valuable data to collectors, where it can be analyzed. As an extension to NetFlow, IPFIX provides more flexibility in the types of data that can be exported, and for the purposes of this blog, I’ll refer to this extended data as metadata.

NetFlow v5

NetFlow v5 is the most commonly deployed version and exports data including IP source and destination, TCP port, and the number of bytes and packets associated with each flow. This data is primarily limited to L2-4 data and is useful to identify top talkers and bandwidth consumption. This is valuable information when you manage a network and want to understand what is happening at a macro level, but it lacks the details and context to be useful when engaged in network incident response and forensic investigation.

NetFlow v9

NetFlow v9 adds the ability to export a wider range of data. It introduces the concept of templates and creates a fixed-length data string into which more information can be placed. The template acts like a decoder ring, defining what is in the export, which enables collectors to consume the content and place it into a structured database. NetFlow v9 is the basis for Cisco Application Visibility and Control (AVC), enabling Cisco switches and routers to export data such as application name, application latency metrics, jitter, URL, and QoS.

IPFIX

IPFX, as stated above, is an industry standard and is currently defined as RFC 7011. Like NetFlow v9, it is template-based, but instead of fixed-length data strings, it supports variable-length strings. This is an important distinction because it allows vendors to export nearly any data they want. In today’s market, every vendor is striving to differentiate themselves from their competitors by exporting richer, more contextual data in an effort to making their product more valuable to potential customers.

Context is King

The word “context” is being thrown around so much by vendors that it’s a potential candidate to being the latest entry to the industry’s buzzword bingo game. Unlike most examples of buzzword bingo, however, there is a primary difference: when it comes to delivering context, there is genuine, concrete, and measureable value. Context is gained by gathering the vast number of unique data elements available from the NetFlow and metadata exports.

Incident Response: The House That NetFlow Built

For decades, network and security professionals have invested in products intended to help them prevent downtime and breaches, but in today’s complex environments, network and security incidents are inevitable. While in the process of responding to these incidents, network and security professionals need to quickly investigate events, determine root cause, and return to normal. NetFlow provides the foundational information, identifying every conversation on the network and defining the source and destination IP address of every flow. Again, this is useful, but alone it lacks context. What is needed is the ability to see beyond layer 4. What is needed is the ability to stitch together information that extends all the way to layer 7, and to do it in a way that helps you answer questions like: who, what, where, when, why, and how. Context is achieved when you can associate source and destination with the username of who was logged into the device at the time of the incident. It is knowing what TCP port and application is associated with the flow, as well as seeing latency, jitter, and QoS parameters. It also comes from resolving DNS lookup per flow, or SSL common name to know what domain and URL are associated, even when it is encrypted cloud-based traffic. It also comes from having the ability to pivot into and quickly filter on any of these data elements to see what happened.

 A Data-Driven Approach to Incident Response

When responding to network and security incidents, time to resolution is everything.  Every second that goes by affects the business and places people’s jobs at risk. Part of the problem as to why quick resolution is difficult is because there is an avalanche of network and security data recorded as log events. Hundreds of thousands of log events are generated every day from network and security systems, but these logs lack context. They are an acknowledgement that something happened, but the importance of these logs are difficult to understand by themselves. IT professionals are buried in an avalanche of this data and making use of it is like finding a needle in a haystack. Log data alone is simply not actionable.

What is needed is a system like Scrutinizer that gathers data from all corners of the network, visualizing and reporting on every flow traversing the network, including data elements that extend all the way to layer 7. To relate the importance and depth of this statement, consider the number of data elements exported by NetFlow v5 (the most common version). NetFlow v5 exports around 12 data elements (source/destination IP, TCP port, packet count, bit count, and a few other things). Scrutinizer collects nearly 5,000 data elements from NetFlow v5, v9, sFlow, IPFIX, and all other types of flow exports. It provides context and delivers actionable data. Scrutinizer delivers rapid root cause analysis (including username and timestamp), and integrates with security information and event systems (SIEMs) like Splunk, ArcSight, and Elasticsearch, as well as with deep packet inspection (DPI) products like Endace. These integrations enable Scrutinizer to dynamically launch these SIEM and DPI systems and display only the data that is relevant to that specific incident. This is how Plixer enables a data-driven approach to fast incident response!

Check out all of the technology alliances and integration that enable the collection of more contextual data than anyone in the industry. Also, see firsthand how Scrutinizer delivers a data-driven approach to network incident response: download our free version and put it to work on your own network!