Dear SOC and IT Analysts,
Let me just come right out and say it: if you’re not spending quality time with packets, you’re not really doing cybersecurity. I know, I know—you’ve got alerts screaming at you, SIEM dashboards dancing like Las Vegas slot machines, and some intern keeps accidentally nuking firewall rules. But listen: amidst all that chaos, packets tell the truth. They’re receipts. They don’t lie, they don’t spin, and they don’t need coffee.
Packet analysis isn’t some outdated skill from the stone age of NetSec—it’s the Rosetta Stone of modern incident response. You can’t rely on log summaries and assume you’ve “seen it all.” That’s like reading a movie’s subtitles without ever watching the film. Sure, you’ll get the plot, but you’ll miss the facial expressions, the tone, the context—and probably the part where the hacker slipped right past your NGFW while you were refreshing Splunk.
Let’s be real: most alerts are glorified guesses. A packet, though? That’s a fact. You want to confirm a DNS exfiltration? Packet. Need to prove a lateral move wasn’t just a false positive? Packet. Trying to make your case to leadership that the printer was indeed talking to a C2 server in Moscow? Packet.
Yes, tools help. Yes, automation is sexy. But nothing replaces raw packet visibility. It’s like trying to solve a murder mystery without the autopsy—you might have clues, but you don’t have proof.
Let me give you a little backup:
Packet Loss Isn’t Random: According to Cidon, Khamisy, and Sidi (1993), packet loss in high-speed networks is bursty and strongly correlated—not the i.i.d. fairy tale you might assume. This changes everything about how we interpret missing data and forward error correction.¹
Flow Data Isn’t Enough: Hofstede et al. (2014) show that while flow monitoring (NetFlow/IPFIX) is scalable, it relies on packet observation to work—and misconfigurations in the early stages lead to analysis artifacts later. It’s not "packets or flows"—it's packets first, flows later.²
TCP Behaves Weirdly Under Pressure: Paxson (1997) showed that TCP implementations behave very differently under stress, with bugs and quirks that aren’t visible through logs alone. Packet traces were the only way to detect these quirks. Source code access? Optional. Packet trace? Essential.³
So here's my plea: crack open Wireshark once in a while. Learn to read PCAPs like a novel. Know what a normal handshake looks like so you can spot the handshake that’s reaching for your wallet.
Because when the alerts are wrong—and they will be—you’ll want a packet to back you up. And when they’re right, you’ll need a packet to show the whole damn story.
Sniff wisely,
A Packet Evangelist
Cidon, Israel, Asad Khamisy, and Moshe Sidi. “Analysis of Packet Loss Processes in High-Speed Networks.” IEEE Transactions on Information Theory 39, no. 1 (1993): 98–108. https://doi.org/10.1109/18.179340.
Hofstede, Rick, Pavel Čeleda, Brian Trammell, Idilio Drago, Ramin Sadre, Anna Sperotto, and Aiko Pras. “Flow Monitoring Explained: From Packet Capture to Data Analysis with NetFlow and IPFIX.” IEEE Communications Surveys & Tutorials 16, no. 4 (2014): 2037–2064. https://doi.org/10.1109/COMST.2014.2321898.
Paxson, Vern. “Automated Packet Trace Analysis of TCP Implementations.” In Proceedings of the ACM SIGCOMM '97 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication, 167–179. ACM, 1997. https://doi.org/10.1145/263105.263160.