Gartner Blog Network


On Futility of Dead Packet Storage

by Anton Chuvakin  |  March 8, 2013  |  5 Comments

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:

Additional Resources

Category: network-forensics  security  

Anton Chuvakin
Research VP and Distinguished Analyst
8 years with Gartner
19 years IT industry

Anton Chuvakin is a Research VP and Distinguished Analyst at Gartner's GTP Security and Risk Management group. Before Mr. Chuvakin joined Gartner, his job responsibilities included security product management, evangelist… Read Full Bio


Thoughts on On Futility of Dead Packet Storage


  1. 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!

  2. Erik Larsson says:

    Anton,
    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.

    Erik

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

  4. @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)

  5. Logging a comment from here https://twitter.com/bammv/status/311102180537028610 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.”



Comments are closed

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.