Key Takeaways: Network Monitoring and Traffic Analysis
A one-page reference. Reread before an exam or before moving on. Dense by design.
The core idea
You can't defend what you can't see. The network is ground truth: an attacker who compromises a host can lie through it, but cannot avoid generating traffic across infrastructure they do not control. Visibility is decided before an incident, not during it — detection, hunting, IR, and the SIEM all depend on telemetry someone chose to collect in advance.
The three altitudes of network visibility
| Altitude | Tool | Keeps | Retention / cost | Best question |
|---|---|---|---|---|
| Full packet capture (PCAP) | Wireshark / tcpdump / tshark |
every byte (payload + headers + timing) | hours–days; HUGE storage | "Exactly what was in this conversation?" |
| Connection logs (NSM) | Zeek (formerly Bro) | one structured record per connection + protocol logs (dns/ssl/http/files) | weeks–months; moderate | "What connections happened, and were any odd?" |
| Flow data | NetFlow / IPFIX (sFlow/J-Flow) | 5-tuple + bytes/packets/time; no payload | months–years; TINY per record | "Who talked to whom, how much, everywhere, over time?" |
- Full packet capture vs flow = the central tradeoff: everything about some traffic, briefly vs almost nothing about all traffic, for a long time. Mature programs use both + Zeek in the middle.
- Encryption hides the payload, not the metadata. From an encrypted TLS flow you still see: src/dst IPs, ports, sizes, timing, SNI hostname, and the server certificate.
- Flow is often generated free by routers/switches you already own (a config change), no new sensor.
Reading the telemetry (field cheat-sheet)
| Source | Key fields | What pops out |
|---|---|---|
Zeek conn.log |
id.orig_h/p, id.resp_h/p, service, duration, orig_bytes, resp_bytes, conn_state, uid |
odd port + empty service; huge orig_bytes/tiny resp_bytes (exfil); many dsts (lateral) |
| Flow record | src/dst IP:port, proto, start, bytes, packets | regular start times + constant bytes (beacon); large outbound (exfil) |
Zeek ssl.log |
SNI, certificate, issuer (joined by uid) |
freshly registered C2 domain; odd cert |
Zeek dns.log |
query, type, answer | high query volume + high-entropy names (tunneling/DGA) |
uid joins Zeek logs → pivot conn.log → ssl.log → dns.log → files.log for one connection.
The network baseline
A network baseline = a model of normal (who talks to whom, on what ports, what volumes, when). Almost every detection is "this differs from baseline." - Baseline per host AND per destination, not globally (global hides the attacker in the aggregate). - Pitfall: baselining during a compromised window enshrines the attacker as "normal." Refresh and sanity-check against known-good expectations ("should this asset ever talk to the internet?").
The three behaviors network monitoring catches best
All three are detected by aggregation over many records, not a single-packet rule.
| Behavior | Definition | Network signature | Detection | Evasion → counter |
|---|---|---|---|---|
| Beaconing | regular C2 check-ins | same src→dst on a fixed interval, constant tiny size, around the clock | group by (src,dst,port); low variance of inter-arrival times (beacon_score) |
long interval + jitter → long flow retention |
| Data exfiltration (network) | unauthorized outbound data | outbound volume ≫ host baseline, to new/odd dst | sum outbound per (src,dst) vs baseline | low-and-slow → cumulative baselines; DNS tunneling → dns.log volume/entropy; blending → per-host baselines |
| Lateral movement | spread from foothold to other hosts | one host → many internal dsts on admin ports (445/3389/5985/22) | count distinct internal dsts per src in a window | — (key: needs east-west visibility) |
beacon_score: high when inter-arrival gaps are consistent (low coefficient of variation = std/mean) and the pattern is long-lived. Set a threshold (~0.9) and weight by check-in count.- East-west vs north-south: lateral movement is east-west (internal↔internal) — a perimeter firewall never sees it (Chapter 6 term). You must place sensors internally.
Sensor placement & feeding the SIEM
- Get traffic to sensors via span/tap:
- SPAN port (port mirror): switch config, cheap, drops packets under switch load, no new HW.
- Network tap: dedicated inline HW, 100% fidelity, no loss, costs money. Use on critical links (e.g., the CDE — a SPAN drop there is unacceptable).
- Sensor placement determines what you can detect. A detection you can't feed doesn't exist. Map "what must I see?" → "where must a sensor sit?"
- What feeds the SIEM: Zeek logs + flow records + notices/alerts (small, structured). Raw PCAP stays local, pulled on demand. The SIEM correlates network + endpoint + identity → weak signals become strong detections (Chapter 21).
- NDR (network detection and response): the operational discipline of doing all of the above continuously to detect, investigate, and respond.
Decision aid — "which altitude / sensor?"
- Need the content of one suspicious exchange → full PCAP (Wireshark), targeted, short retention.
- Need to detect a behavior across many connections → Zeek (rich) or flow (cheap, long, wide).
- Need network-wide, long look-back (slow beacons, cumulative exfil) → flow (months–years).
- Need east-west (lateral movement) → internal sensors / internal flow — not a perimeter sensor.
- Need guaranteed completeness on a critical link → tap, not SPAN.
Certification crosswalk
| Concept | CompTIA Security+ | (ISC)² CISSP domain |
|---|---|---|
| Packet capture / protocol analysis | 4.0 Security Operations (monitoring tools) | Security Operations |
| Flow data (NetFlow/IPFIX), NSM | 4.0 Security Operations | Communication & Network Security |
| Beaconing / C2 detection | 2.0 Threats; 4.0 Operations | Security Operations |
| Data exfiltration / DLP context | 4.0 Operations; 2.0 Threats | Security Operations; Asset Security |
| Lateral movement / east-west | 2.0 Threats, Vulns & Mitigations | Communication & Network Security |
| Taps vs SPAN, sensor placement | 3.0 Security Architecture | Communication & Network Security |
| Feeding/centralizing logs (→ SIEM) | 4.0 Security Operations | Security Operations |
Project additions this chapter
- Meridian program — network-monitoring design: flow export on core/edge (13-mo retention); Zeek via taps on internet uplink, CDE link, and the user↔data-center (east-west) boundary; targeted 72-hour PCAP on CDE + edge; retention tiers (flow 13 mo / Zeek 90 d / PCAP 72 h); all forwarded to the SIEM. Gap named: encrypted payloads → compensate with baselining + correlation.
bluekit—pktflow.py:summarize_flows(rows)(baseline primitive),top_talkers(flows)(exfil first-look),beacon_score(timestamps)(beacon detector via inter-arrival regularity).
Common pitfalls
- Trying to full-capture everything everywhere forever (petabytes; storage-bankrupt or silently lossy).
- "We have logs" ≠ "we have monitoring." Telemetry not consumed against detections is unread.
- Ranking by volume, not regularity, when hunting beacons (the biggest talker is usually benign).
- Baselining during a compromise (the attacker becomes "normal").
- Only north-south visibility → blind to lateral movement; a perimeter sensor can't see east-west.
- Hunting beacons by known-bad IPs (signature thinking) → misses fresh C2 with clean reputation.
- Forgetting that the network can't read encrypted payloads → must correlate with endpoint/identity.