Network Flow Logs record metadata about network conversations, such as source and destination addresses, ports, protocols, timing, and byte counts. They do not usually capture payloads, so they are used to reconstruct communication patterns, spot unusual connections, and support incident investigations. Keep retention, sampling, and coverage aligned with detection and forensics needs.
What network flow logs actually capture
network flow logs are a metadata stream, not a packet capture. They summarise who talked to whom, over what protocol, when the conversation started and ended, and how much data moved. That makes them useful for seeing communication patterns at scale, but not for reading the content of the exchange itself.
Because they are summarised records, flow logs are most valuable when you want broad visibility rather than forensic depth. They can show patterns such as new destinations, unusual ports, unexpected east-west traffic, or a host suddenly talking to many peers. For deeper packet-level inspection, practitioners usually pair them with tools covered in the NDR Guide.
How to use flow logs for detection and investigation
The practical value of flow logs comes from baselining and correlation. On their own, a single record is often mundane; over time, the same records reveal outliers, rare destinations, beacon-like timing, and traffic volumes that do not fit normal application behaviour. That is why they are commonly fed into SIEM, NDR, or cloud security pipelines rather than reviewed manually.
In cloud environments, flow logs are especially useful for understanding security groups, subnet boundaries, peering paths, and whether services are reaching places they should not. In AWS, that operational context is often easiest to interpret alongside account and network controls documented in the AWS Security Guide.
For investigations, the log value is in reconstruction: you can determine which systems communicated, whether a destination was internal or external, whether the timing matches an incident window, and whether the volume suggests scanning, exfiltration, or automated retry behaviour. The logs rarely prove intent by themselves, but they often narrow the search space quickly.
Coverage, retention, and the limits you need to plan for
Flow logs are only as good as the points where they are collected. If capture is incomplete, sampled too aggressively, or disabled on the wrong segments, the resulting picture can miss the exact traffic you most need during an incident. Retention matters too, because short-lived logs may be enough for live monitoring but too short for retrospective hunts.
Failure mechanism: The main failure mode is assuming metadata equals visibility. If logs omit important subnets, load balancer paths, or cloud fabric segments, investigators may misread an attack path or miss lateral movement entirely. Sampling can also hide low-and-slow beacons or sparse exfiltration patterns.
Impact: Gaps in coverage can delay detection, weaken forensic reconstruction, and leave security teams unable to prove whether an unusual connection was benign or malicious. In regulated or high-consequence environments, that can also undermine auditability and incident response confidence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | Flow logs support continuous network anomaly monitoring and hunt triage. |
| DE.AE-01 — Anomalies and Events Analyzed | Flow logs are analyzed to reconstruct unusual communications and incident timelines. | |
| Recommendation — Use DE.CM-01 to monitor flow-log anomalies for unusual network activity. Use DE.AE-01 to analyze flow-log anomalies for incident reconstruction. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | Flow logs are generated audit evidence for network communications and investigations. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Flow logs become useful when reviewed for outliers, unusual paths, and incident clues. | |
| Recommendation — Configure AU-12 to generate network flow records at the needed coverage points. Use AU-6 to review flow logs for anomalies and investigation leads. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Flow logs are a core audit-log source that needs retention, coverage, and review. |
| Recommendation — Implement CIS-8 to retain and review flow logs for detection and forensics. | ||
Practitioner Guidance
What to verify: Confirm that flow-log scope covers the network segments that matter most, including east-west traffic, egress paths, and shared services. If a control decision depends on the logs, verify retention window, sampling rate, and field completeness before trusting them for investigation.
What to measure: Track how often flow logs help answer concrete questions such as “what spoke to this host?”, “did this service reach an unusual destination?”, and “did traffic volume change materially before the alert?” If they rarely resolve investigations, the likely problem is coverage or enrichment, not the logging concept itself.
Practitioner takeaway: Treat flow logs as a reconstruction layer, not a substitute for packet visibility or endpoint telemetry; they are strongest when their collection points, retention, and downstream correlation are designed around the specific detection and forensics questions you expect to ask.