Plenty of guides explain where to start learning network traffic analysis. This one assumes you have already started, and answers a different question: once you can open a packet capture and read it, what actually separates a good analyst from someone who is just staring at the same data for longer? The answer has very little to do with which tool is open and a lot to do with six habits that hold up across all of them.
Why does baselining always come before anything else?
Because "suspicious" is a comparison, not a property. A connection on an unusual port, at an unusual hour, moving an unusual amount of data, is only unusual relative to something. Without a baseline of what normal actually looks like, by time of day, by network zone, by protocol mix, every judgement call is really just a guess dressed up as analysis.
NIST's Guide to Intrusion Detection and Prevention Systems makes this the foundation of the entire discipline for a reason: detection logic built without a baseline either misses real anomalies buried in normal-looking noise, or drowns in false positives generated by normal behaviour nobody bothered to characterise first. Baselining is not the interesting part of the job. It is the part that makes the interesting part possible.
What do you actually do once most of the traffic is encrypted?
Give up on reading the payload, for a start. Deep packet inspection assumed you could see what was inside a connection, and TLS quietly broke that assumption years ago. What is left is metadata: packet sizes, timing, destination, and the handshake itself.
This is where JA3 fingerprinting, the technique Salesforce's security team open-sourced in 2017, earns its place in a modern analyst's toolkit. JA3 builds a fingerprint from the unencrypted parts of a TLS handshake, the client's offered cipher suites, extensions, and elliptic curves, hashed into a single string. Two completely different pieces of malware using the same TLS library often produce the same JA3 hash, which means you can flag a connection as suspicious without ever decrypting a single byte of it. The lesson generalises: when you lose visibility into content, you do not lose visibility into behaviour, you just have to know where to look for it.
Should you capture everything, or just enough?
Neither extreme works. Capturing full packets everywhere generates more data than most teams can store, let alone review, and it buries the signal in its own volume. Capturing nothing but summary statistics loses the forensic detail you need the moment something actually goes wrong.
The practical answer is both, at different scales. Flow data, NetFlow, sFlow, IPFIX, gives broad, lightweight visibility across an entire environment: who talked to whom, how much, for how long. Full packet capture gets reserved for the specific conversations flow data flags as worth a closer look. Think of flow data as the map and packet capture as the magnifying glass. You do not walk around with the magnifying glass pressed to your eye all day, and you cannot navigate with only the map.
How do you stop drowning in your own traffic logs?
By actively deciding what not to look at. A huge proportion of any network's traffic is high-volume and completely benign, backups, health checks, routine replication, and none of it deserves an analyst's attention on a normal day. Suppressing that noise deliberately, rather than letting it compete for attention with everything else, is what makes the actually unusual traffic visible in the first place.
The discipline here is negative: knowing what to stop looking at is just as much a skill as knowing what to look for, and it is the one nobody puts in the job description.
Why does one weird connection matter less than three weird things at once?
Because single indicators are cheap for an attacker to avoid, and analysts who chase them one at a time get exhausted fast. An odd destination port alone might be nothing. An odd port, at an odd hour, moving an odd volume, on a host that has never made that kind of connection before, is a different story entirely. When several independent baseline deviations line up on the same connection, the odds that you are looking at genuine staging or lateral movement go up sharply, and that correlation is a far stronger signal than any single data point could ever be on its own.
Do you need a logger, a detector, or a scalpel?
These are three different tools solving three different problems, and reaching for the wrong one wastes time. Zeek is a transaction logger: it describes traffic in structured detail without judging it, which makes it exceptional for building the baselines discussed above. Suricata is a signature engine: fast, alert-driven detection against known-bad patterns. Wireshark is the scalpel: full packet-level detail for the specific conversation you have already decided is worth dissecting by hand.
None of the three replaces the others. A mature analyst reaches for Zeek to understand what is normal, Suricata to get alerted when something matches a known bad pattern, and Wireshark once flow or alert data has already narrowed the search down to a handful of packets worth reading line by line.
| Tool | What it actually is | Best for |
|---|---|---|
| Zeek | Transaction logger, describes traffic without judging it | Building baselines, retrospective investigation |
| Suricata | Signature engine, alert-driven detection | Catching known-bad patterns fast |
| Wireshark | Full packet-level inspection | Dissecting a specific conversation by hand |
The skill is the mental model, not the tool
Every practice above points at the same underlying truth: good traffic analysis is really the discipline of knowing exactly what a boring Tuesday looks like on your network, in enough detail that anything else stands out immediately. Attackers do not announce themselves. They try very hard to look like a boring Tuesday too, and the analyst who has actually done the baselining work is the one who notices when they do not quite manage it.
That mental model is built through repetition against real traffic, not through reading about it. TryHackMe's Network Security and Traffic Analysis module, the third module in the SOC Level 1 path, is built around exactly that kind of repetition, working through Zeek and Wireshark against real captures rather than static examples, and it builds directly toward the Security Analyst Level 1 certification as a credential that tests this judgement directly.
Frequently asked questions
Do I need to master Wireshark before learning Zeek or Suricata? No. They solve different problems, and a beginner is better served getting basic exposure to all three early rather than mastering one in isolation. Depth in whichever one matches your actual work comes with time.
Is packet capture still useful if most traffic is encrypted? Yes, but its role has narrowed. It is far more useful for dissecting a specific flagged conversation than for broad monitoring, where flow data and metadata analysis now carry most of the weight.
How long does it take to build a useful baseline for a real network? It varies with network complexity, but most teams see a workable baseline emerge within a few weeks of consistent monitoring, and it keeps improving as more edge cases get characterised over time.
Can automation replace an analyst's baselining judgement? It can support it, not replace it. Automated anomaly detection is only as good as the baseline it is measured against, and deciding what counts as a meaningful deviation is still a human judgement call, especially early on.
Is JA3 fingerprinting still reliable today? It remains a useful signal, though modern browsers increasingly randomise TLS extension order specifically to weaken it, so JA3 works best as one signal among several rather than a single source of truth.
What is the single biggest mistake new analysts make with traffic analysis? Chasing single indicators in isolation instead of looking for correlated deviations across several signals at once. It burns out attention fast and misses the pattern-level signals that actually matter most.
Nick O'Grady