Safeguard
Application Security•

What is network traffic analysis and what should you collect?

Network traffic can be captured as packets, summarized as flow records or read from logs. What each shows, what encryption hides, and a collection plan.

Safeguard Security Team
4 min read

Network traffic analysis is the practice of collecting data about what moves across a network and reading it for problems: attacks, misuse, faults and policy breaks. You can collect full packets, flow records that summarize conversations, or logs from devices. Flow records are the usual starting point because they are small and keep working when payloads are encrypted.

What are the three kinds of data?

Full packet capture records every packet. It gives the most detail and costs the most storage, and it raises privacy duties since it holds content. It suits focused investigations and short retention.

Flow records summarize. RFC 7011, which specifies the IP Flow Information Export protocol, defines a flow as a set of packets or frames passing an observation point in the network during a certain time interval, where all packets share common properties. The protocol exists so an exporting process can send traffic flow information to a collecting process in a common representation. A flow record says who talked to whom, on which ports, when, and how much, without the content.

Device and application logs add context the network cannot see: a firewall's allow or deny decision, a proxy's URL, a DNS server's queries, an authentication server's result. NIST SP 800-92 treats these as logs to be generated, transmitted, stored and analysed, and a SIEM is where they are usually correlated.

What can flow data tell you?

More than people expect. A baseline of normal flows shows which servers should talk to which, so these stand out: a new destination, a database server initiating outbound connections, a host scanning many addresses on one port, large transfers at odd hours, or a device talking to a country it never has. These map to MITRE ATT&CK techniques around discovery, lateral movement and exfiltration, which gives your alerts a shared vocabulary.

NIST's guide to intrusion detection and prevention systems covers the related approach of inspecting traffic against known attack signatures and anomalies. NIST CSF 2.0 states the goal as an outcome: networks and network services are monitored to find potentially adverse events.

What does encryption change?

Content inspection shrinks as encryption spreads. TLS 1.3, standardized in RFC 8446, encrypts more of the handshake than earlier versions. You can still see endpoints, timing and volume in flow data, and that is why metadata analysis keeps its value. If you need content inspection at a boundary, you must decide deliberately whether to decrypt there, and say so in policy, as NIST describes for application-proxy gateways that decrypt and re-encrypt traffic.

A constructed example

A network team exports flow data from its core switches and internet edge. In the first month, the baseline reveals that a print server initiates connections to dozens of external addresses every night. Investigation finds an old management agent phoning home to a vendor service nobody approved. The team blocks it at the edge and documents the decision. In the second month, an alert fires for a workstation connecting to 300 internal hosts on port 445 in ten minutes. It is a faulty backup tool, caught early, with a clear timeline from flow records.

How to check or apply this

  1. Decide the questions: attack detection, performance, compliance or all three. That sets the data you need.
  2. Export flow data from edge, core and key segments, including cloud virtual networks where the provider supports it.
  3. Add DNS, proxy and firewall logs. Synchronize clocks so events line up.
  4. Build baselines of normal traffic per segment over several weeks.
  5. Write a few alerts tied to known behaviors: scanning, new outbound destinations, large transfers, and unexpected internal protocols.
  6. Keep full packet capture for narrow, high value segments with short retention, and decide the privacy rules first.
  7. Test by running a controlled scan or transfer and confirm it is detected, ticketed and read by a person.
  8. Review rules monthly and retire alerts that nobody acts on.

Quick check

Do I need packet capture for everything?

No. Flow records answer most questions about who talked to whom and how much, at far lower cost. Keep packet capture for focused cases.

Can I analyze traffic that is encrypted?

Yes, at the metadata level: endpoints, timing, volume and protocol behavior stay visible. Content needs decryption at a controlled point, which is a policy decision.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.