Netflow versus Full Packet Capture

[KEVINDIENST]

After a recent conversation with RSA personnel, I'm curious how many users see value in Netflow data if you already have FPC deployed?

Are you only using Netflow if FPC is cost prohibitive or for other deployment related difficulties?

Do you see any use case(s) where netflow data is valuable even if FPC is present?

Thanks,

[GarethPritchard]

This article provides a really comprehensive comparison between FPC and Netflow:
https://www.netfort.com/wp-content/uploads/PDF/WhitePapers/NetFlow-Vs-Packet-Analysis-What-Should-You-Choose.pdf 

Personally, I would say one of the big benefits of FPC aside from the comparison chart above, is the ability to calve out and analyse suspicious payloads. this can save hours / days when investigating an incident.

[MichaelPochan]

From a place that uses both, the only value I've found from having netflow in addition to FPC is the historical retention. In Netwitness, we only have packets going back 2 days and meta (which covers all standard netflow fields) going back 30 days. In our dedicated netflow solution however, we have data (and some DPI meta) going back almost a year. Aside from that, FPC provides almost everything we need. 

[Anonymous]

I use Netflow (SILK) all the time, even though I love Netwitness full packet capture.

A common use case - you find some suspicious traffic in your IDS or Netwitness, and want to

see who else has connected to the "bad" site in the last month or so.  If your sessions have expired from Netwitness, 

netflow is your only hope!

Another common use case:  Netwitness is totally great for carving out suspicious traffic in a drill down.

But if you don't drill down and eliminate protocols/ports/hosts, etc, you sometimes end up with 40 or 50

"pages" of session details.  That can be a real pain to wade through.  In Netflow you can easily ouput a

CSV file of all connections for a single source and easily walk through each aspect of that connection.

SILK is so easy to setup, and totally invaluable at times.  I'd suggest both!

[Anonymous]

To those using both NetFlow and RSA NetWitness Full Packet Capture, 

A couple of quick questions:

•  How is NetFlow traffic data fundamentally any different than Meta gleaned from Full Packet Capture in RSA NetWitness?  
• Doesn't RSA NetWitness Full Packet Capture provide 100% of the NetFlow data, just living as Meta?  
• If so, why not simply use RSA NetWitness Full Packet Capture for the network segments currently targeted for NetFlow on an architecture of extended meta retention to accommodate much longer time periods?Now you consume both the value of NetFlow data _and_ the security analysis of RSA NetWitness App Rules on the full packet data, achieving a multiplier on visibility value without incurring session retention storage costs, no?

Architecturally, I like NetFlow into a RSA NetWitness Log Decoder to gain visibility into ‘far flung’ / ‘hard to tap’ reaches of an environment, which differs from 'Full Packet Capture consumes more disk than NetFlow' articulated in the previous posts.   

Best Regards, 

Alan

[MichaelPochan]

Data retention for a dedicated Netflow system is greater than the Netwitness retention for meta (at least in our environment). Also, certain flow exports like NSEL from things like ASAs provide additional information like user IDs and NAT stitching. But other than those things, Netwitness Packet meta pretty much covers everything.