Network security monitoring: packet captures, NetFlow and session data
In short: Network security monitoring collects evidence about traffic so analysts can spot and investigate attacks. Full packet capture shows everything but is costly; flow data such as NetFlow and IPFIX shows who talked to whom, when and how much, and is cheap enough to keep for months. Most SOCs combine both with firewall, proxy and DNS logs.
What network security monitoring is
Network security monitoring (NSM) means collecting and analysing data about network traffic to detect and investigate attacks. Endpoint tools see what happens on a device; NSM sees how devices talk to each other and to the internet. That is valuable because many devices, such as printers, cameras and IoT sensors, cannot run an endpoint agent, and because attackers almost always need the network to spread or to send data out.
The main kinds of data
| Data | What it shows | Trade-off |
|---|---|---|
| Full packet capture | Every packet, including payload | Most detail, very large, usually kept for days only |
| Session or flow data | Source, destination, ports, protocol, bytes, duration | Small and cheap, no content |
| Transaction data | Records of DNS queries, HTTP requests, TLS handshakes | Good middle ground for investigations |
| Statistical data | Traffic volumes and trends over time | Spots unusual spikes, not detail |
| Alert data | Signature matches from an IDS or IPS | Easy to act on, only finds known patterns |
NetFlow and IPFIX
NetFlow, originally developed by Cisco, makes a router or switch summarise traffic into flow records. A flow is a set of packets sharing the same source and destination address, ports and protocol. IPFIX (IP Flow Information Export) is the IETF standard based on NetFlow version 9, and many vendors support it. Because flow records are small, you can store months of them and answer questions like "did any internal host talk to this suspicious address in the last 90 days?".
Flow data is good at revealing:
- Large uploads to unfamiliar destinations, which may be data theft.
- Regular, small connections at fixed intervals, a pattern called beaconing that can indicate malware checking in.
- One internal host connecting to many others on the same port, which can indicate scanning or worm spread.
Where and how to collect
Place sensors where traffic crosses trust boundaries: the internet edge, between user and server VLANs, and in front of the data centre or cloud gateway. A SPAN port (port mirroring) copies traffic from a switch port to a sensor; a network TAP is a hardware device that copies traffic reliably even under heavy load. Make sure every device sends logs with correct time from NTP, or you will not be able to line up events.
Tip: most traffic today is encrypted with TLS, so payload inspection is limited. Metadata still helps: destination names from DNS and the TLS server name, certificate details, timing and volume often reveal more than you expect.
Real-world example: a hospital spots beaconing
An analyst at a fictional hospital reviews flow data and notices a radiology workstation contacting the same external address every 60 seconds, around the clock, with almost identical byte counts. Nothing else on the network contacts that address. Packet capture is only kept for three days, but that is enough to see the TLS server name, which is a newly registered domain. The SOC isolates the workstation through its EDR agent, blocks the domain at the firewall and searches 90 days of flow records to confirm no other device had contacted it.
Practice
Why keep flow data for longer than full packet captures?
What is beaconing and how can flow data reveal it?
What is the difference between a SPAN port and a TAP?
Key takeaways
- NSM watches how devices communicate, including devices without agents.
- Full packet capture gives detail; flow data gives long, cheap history.
- NetFlow and IPFIX summarise traffic into flow records.
- Place sensors at trust boundaries and keep clocks in sync.
- Encryption hides content, but metadata still reveals a lot.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.