One of my research projects this quarter will be focused on a really, really exciting subject: network forensics. While we will likely formally define it in the course of our research, I wanted to briefly explore it in this blog post. As I understand it now, “network forensics” today exists at the confluence of several essential capabilities:
- full packet capture at massive scale and in compliance with digital evidence rules
- retention of data for days or longer
- fast access to captured data via search and other tools
- packet header analysis, including summarizing and trending the network activity
- packet contents analysis across protocols, including file extraction, session viewing and application protocol analysis.
Since I just landed in the realm of network forensics from the realm of DLP, the last of the needs – content analysis – needs to be kept in focus here as well. It is not only about the packet headers, however fun those may be. Binary extraction, image preview, document searches all play a major role in network forensics tool use cases.
It is also helpful to point out what network forensics tools are not:
- not Netflow capture and analysis (NBAD) tools
- not NIDS/NIPS packet capture based on alerts
- not DLP, even though DLP tools may capture and analyze files
- not SIEM, even though some SIEM vendors are exploring full-packet capture functionality.
(as you can guess, network forensics tools have pockets of overlapping functions with all of the above, but they are not the same in either their mission or their overall capabilities)
Furthermore, as I am starting to look into this, one startling realization looms: while few organizations do it, much fewer do it well. In any case, we will be working on a detailed guidance (GTP style) on network forensics operational practices and using network forensics tools effectively.
So, here is my next call to action:
- Vendors with network forensics tools, got anything to say about it? Here is a briefing link … you know what to do.
- Enterprises, got a network forensics story – either about tool deployment or operations – to share? Hit the comments or email me privately (Gartner client NDA will cover it, if you are a client).
- Network forensics-focused consultants [yes, that probably just means you Rocky 🙂], got a story (“inspired by” your recent project) to share? I’d love to hear it as well!
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
2 Comments
Network forensics clearly offers big rewards but is also a big budget item. On its own the costs of just acquiring the capability (operational costs notwithstanding) are directly related to how much is to be captured, where capture takes place and how long data is retained for. As such the market may well evolve towards delivering more cost effective solutions and I’ve seen the emergence of a cloud-based analysis/forensics vendor (which presents its own challenges around data security and transfer).
It’s important not to undermine the capability of netflow/NBAD on the basis that it’s incumbent in many organisations but is often NOT used for security monitoring (e.g. alerting on endpoint communications with a suspicious IP or DNS requests going from workstations to outside of the organisation). I expect those organisations who can see the value of netflow/NBAD for security monitoring and incident investigation to be more likely to go up a gear and adopt network forensics.
Matt, thanks for the comment. We are going to explore the relationship between NBAD and network forensics tools in our research, for sure. I am really curious whether an NBAD user (an actual user, not just an owner of the shelfware tool) is more or less likely to adopt NF tools.