During September, I’ve been very fortunate to attend two actual physical conferences focused on 5G. The first was in Denver Colorado, conveniently just across the Rocky Mountains from my current home in Grand Junction. The second was in London England, 200 miles or so south of my original home in Yorkshire (typically celebrated as the home of the most successful cricket team ever, though puddings also get a well-deserved mention).
The idea of packet capture has been around for many years, but the idea of continuous packet capture, however, is relatively new. Continuous packet capture can be considered as a window into network history over a period, that can be retrieved, examined, archived, and analyzed. A network’s continuous packet capture requirements are determined by the speed of the networks being monitoring (capture throughput), and from how far back in time you want to retrieve packet data (retention time). Once the retention time is exceeded, the oldest packet data is overwritten. Think of it as a large circular buffer continuously overwriting itself.
In the past, packet capture was done after an incident to further debug network issues. In order to fully understand the problem, the issue would need to be reproduced so that a packet trace could be captured and analyzed. As a network engineer trying to find the root cause of a network issue, this above method may or may not work because the issue may not be easily reproducible. Furthermore, in many cases, the issue would most likely occur again, and the process would have to be repeated.
The greatest value in continuous packet capture is that the user is not at all involved with the debug of a network issue. The network engineer can go back in time to when the event happened and pull the actual packet data that caused the event from the packet capture appliance. Continuous packet capture delivers a copy of the exact network activity that caused the event, so the root cause investigation can be completed more quickly and efficiently.
In the case of network security events, continuous packet capture maybe even more important. If you are running an IDS or a next-generation firewall (NGF), the alerts these devices generate can be used to pull packet data from a continuous packet capture appliance, also sometimes referred to as a network recorder. Network security alerts are typically captured in a SIEM, like Splunk or IBM Security QRadar, so that they can be logged, searched for, and analyzed. But what if the information in the alert doesn’t give the entire picture or a holistic view of the event to find the root cause? In this case, having the ability to analyze the actual network data that caused the event may give the comprehensive insight needed.
To ease the workflow of a network security engineer simple integrations can be implemented between the SIEM, IDS, NGF, etc., and the packet capture appliance, to automate the process of retrieving the packet data for network security events. Single-click workflow, or fully automated retrieval and archive of event packet data are possible with today’s modern packet capture appliances.
Deploying continuous packet capture capability to your network is not necessarily an expensive investment. For networks under 1Gbps and a retention of less than a few days, this can be achieved using inexpensive commodity hardware. Open source applications can provide most of the functionality and can usually handle networks under 1Gbps. It is important to acknowledge that just capturing traffic is only half of the puzzle. The ability to find the packet data of interest is just as important in finding the root cause of the problem. Also, lossless packet capture is extremely important as it gives the whole picture. Commercially available packet capture software and NICs can be deployed for this, as they can provide the assurance of 100% packet capture at a very reasonable cost. When looking at packet capture appliances, it is important to make sure that the product supports 100% packet capture for all packet sizes at the required capture rate. It is also worth checking the search, retrieval, and streaming performance of the appliance as this can determine if the packet data is available quickly, so that the network related issue is resolved in minutes, rather than hours or days.