With the onslaught of malware and cloud applications increasing, the business of Network Traffic Intelligence has become increasingly important. When an infection is unearthed and the incident response team moves in, to sleuth out what exactly has happened, one of the first things they will do is request the logs and this includes the flow (NetFlow and IPFIX) data. Network and application issues are trouble shot in a similar way.

Investigation requires access to some type of history else, you have to wait for the issue to pop up again. Who wants to wait for the malware to exfiltrate even more confidential information? The problem with collecting flow data alone is that it can often lack the contextual details that can shorten the investigation.

Security Intelligence

On the security side, context can mean the username associated with the IP address or it can include the fully qualified domain names reach out to or the URLs being visited. These logs can sometimes be found in IPFIX exports but, usually have to be collected from Microsoft Active Directory, Cisco ISE, Forescout CounterACT, Radius or the DNS. Once ingested, these details need to be cross-referenced with the IP addresses found in flow data in order to be useful. Once available, this additional context in a single Network Traffic Intelligence systems allows security professionals to shorten the MTTK (Mean Time To Know).

Application Intelligence

On the application side, context can certainly include the same details sought out by the security team but, may also include details on round trip time, retransmitted packets, layer 7 application information, URL visited, TCP window size, VoIP caller ID, jitter, packet loss, codec, session duration, HTTP error codes and much more. In fact, often times network administrators have to choose which details they want to export from their routers, firewalls, switches, servers and probes else, the size of the flows becomes too large which leads to excessive amounts of flow data on the network causing further congestion. As a result, richer contextual details are sometimes temporarily exported until the problem becomes apparent and then the extra information can be turned off. The culture surrounding application issues can sometimes tend to blame the network until they can prove otherwise. Certainly MTTK applies however in networking, sometimes we call it MTTI (Mean Time To Innocence).

Network traffic intelligence

History is Imperative

Although the amount of flow history available doesn’t always mater on the application side, on the security side it is imperative. Often times, 30-90 days is not enough when trying to ascertain when the infection first penetrated the network six months prior.

… malware can reside undetected in health information systems for weeks, months, and even yearsJarrett Kolthoff – Former Special Agent with U.S. Army Counterintelligence

Not having all of the data prevents security teams from being able to tell the complete story from initial infiltration to clean up. Network Traffic Intelligence systems should be able to archive the data for as long as the business deems necessary.

Billions of Data Points in Seconds

Large enterprises and service providers generate big data which means they require a data collection platform that can turn flows into actionable real-time intelligence at scale. The best solutions allow customers to choose from cloud hosted SaaS offerings which promise massive ingestion rates and allow the vendor to provide the on-going maintenance. Other times, the cost of maintaining data in the cloud is too pricey resulting in an on-premise solution where data can sometimes be archived more inexpensively. Once the best fit is decided on, customers want fast reporting with rich context and ongoing monitoring of both DDoS attacks and other types of unwanted behavior patterns. Throughout day to day operations, ad-hoc analytics are required by both security teams and application managers in order to improve operations, optimize capacity and resolve anomalies – FAST. Evaluate our forensic incident response solution today.



Michael is the Co-Founder and the product manager for Scrutinizer Incident Response System. He can be reached most hours of the day between work and home. He enjoys many outdoor winter sports and often takes videos when he is snowmobiling, ice fishing or sledding with his kids. Cold weather and lots of snow make the best winters as far as he is concerned. Prior to starting Somix and Plixer, Mike worked in technical support at Cabletron Systems, acquired his Novell CNE and then moved to the training department for a few years. While in training he finished his Masters in Computer Information Systems from Southern New Hampshire University and then left technical training to pursue a new skill set in Professional Services. In 1998 he left the 'Tron' to start Somix which later became Plixer. Feel free to email him.