Dr Anton Chuvakin Blog (Original)

Security writing since the mid-2000s. New posts are mirrored from Anton on Security on Medium.

On Futility of Dead Packet Storage

By Anton Chuvakin
Historical Archive Note: This post was originally published on the Gartner Blog Network on March 8, 2013 by Anton Chuvakin.
Original URL: http://blogs.gartner.com/anton-chuvakin/2013/03/08/on-futility-of-dead-packet-storage/ | Archive.org Snapshot

Think about it: if you typically detect compromised  assets in 60 days after the attacker gets in (a great result, BTW, compared to published industry averages!) and you store packet captures in your network forensics tool for 30 days, why the hell you are doing it? Just toss the tool out of the window and use the money to buy beer for your team.  Smile 

More practically, if a detection lag period is longer than an evidence retention period, which one do you improve? Do you store data for longer or do you improve your detection capabilities? Sorry, I know that the enlightened  readers of this blog have started cringing right about now, but please remember that “90% of people are not even in the top 10 Percentile”…. That is in fact a legitimate question for many.

So, in case of log data (stored inside your SIEM and log management tools), many organizations chose to crank up their retention. A year of log storage is fairly common (and PCI DSS mandated), and longer retention periods (2-3 years) are not rare either. On the other hand, storing a year of full captures from ONE saturated 10gbit link (assuming 10x compression) comes roughly to  3,942,000,000,000,000 bytes aka almost 4 petabytes. That’d be per ONE link of not really EPIC bandwidth (which means no internal network capture and thus no lateral movement visibility).

If you are thinking of a more comprehensive capture or longer retention, you might have to learn another new word: exabyte (1,000 petabytes = 1 exabyte). Which is another way of saying that you won’t do it Smile Still, many organizations are more comfortable buying boxes rather hiring and retaining good security people and building organizational capabilities (example). Thus, upon reading this post, some may consider investing into additional packet storage. However, this is the battle you won’t win – at least not with that attitude – and your detection lag will stay long. Ultimately, if you keep the packets only “in case of an incident”, but you detect an incident only when the packets are gone, why are you really doing that?! For compliance, maybe? Smile

Our research into network forensics shows retention times for raw packets in the 7-30 day range (with much longer session metadata retention, of course). If you bought that shiny new network forensics tool and set your capture retention to 30 days, how confident are you about your ability to detect an incident in 30 days or less? Even if you whitelist plenty of traffic and avoid capturing that (with the most hilarious example being enterprise off-site backups), the volume of data will still strangle you.

Thus, while storing logs “just in case” works OK, storing raw packets may not. The point is this data must be explored if it is collected! Your network forensics tool should focus on analysis and not on high speed collection/indexing. Ultimately, this is about building a capability and not about buying a collector box!

Posted related to my network forensics research: