Blog post

On Futility of Dead Packet Storage

By Anton Chuvakin | March 08, 2013 | 5 Comments

securitynetwork forensics

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:

The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.

Comments are closed


  • Tracy Reed says:

    The title of this article instantly reminded me of a scene from the most excellent movie Pulp Fiction:

    Jimmie: When you came pulling in here, did you notice a sign out in front of my house that said “Dead Packet Storage”?

    Jules: Jimmie, you know I ain’t seen no…

    Jimmie: Did you notice a sign out in front of my house that said “Dead Packet Storage”?!?!

    Jules: No. I didn’t.

    Jimmie: You know WHY you didn’t see that sign?

    Jules: Why?

    Jimmie: ‘Cause it ain’t there, ’cause storing dead packets ain’t my f*cking business, that’s why!

  • Erik Larsson says:

    Good description of a well-known conundrum 😉

    – For forensic analysis, what are your thoughts about storing traffic metadata instead of (or as a complement to) full packet capture?

    The approach is to use DPI probes to produce forensically relevant traffic information (metadata) to reduce the size of forensic data compared to full packet. The reduction is size can be a factor 150x, which means that you can easily store up to 1 year’s worth of info. It may not be applicable for compliance, but it works well for networks forensics, to sharpen & shorten investigation times. With the addition of traffic records from a DPI probe, security tools like SIEMs could considerably reduce time to discovery and containment.


  • @tracy Loved the comment!! Maybe a vendor will create a sign for “NO DEAD PACKET STORAGE HERE”

  • @erik

    >For forensic analysis, what are your thoughts about storing traffic
    >metadata instead of (or as a complement to) full packet capture?

    It is very useful but it does NOT replace full pcaps. Metadata/session data/etc is hugely useful, but (in some key cases) does NOT serve the same purpose as full capture. For example, going back and grabbing a file out of traffic cannot be done with metadata alone (you can see the size, MD5, etc,etc, but not the actual file)

  • Logging a comment from here for posterity:

    “Piecing what the intruder has done in the last 7 – 30 days is still valuable info, even if the asset was comp’d 60 days ago.”