Network Flow Logs are records of metadata about network conversations, such as source, destination, ports, protocol, and timing. They help defenders identify scanning, lateral movement, exfiltration, and policy violations without capturing full payloads. Keep retention long enough for investigations, and baseline normal patterns so deviations stand out quickly.
What Network Flow Logs Capture
Network flow logs record conversation metadata rather than packet contents. That means they tell you who talked to whom, over which ports and protocols, and for how long, which is enough to reconstruct many security-relevant patterns without full payload inspection.
Because the data is summarised, flow logs are best understood as a visibility layer, not a forensic substitute for packet capture. They are strongest when paired with DNS, firewall, proxy, endpoint, or NDR telemetry that can explain what the connection was trying to do.
Why Flow Logs Matter for Detection
Flow data is especially useful for finding scanning, east-west movement, unexpected service-to-service chatter, and suspicious data transfer patterns. In cloud environments, the same metadata can reveal misrouted traffic, unintended public exposure, and workloads that are talking outside their normal peers.
Flow logs also help defenders build a baseline of normal network behaviour. Once that baseline exists, deviations such as rare destinations, unusual port use, or long-lived connections become easier to spot and investigate.
For a deeper treatment of how defenders use metadata, sensor placement, and baseline analysis, the NDR Guide is a useful companion reference.
How Organisations Use Them in Practice
Network flow logs are usually collected from routers, switches, firewalls, cloud network services, or virtual networking layers, then forwarded into a SIEM, NDR platform, or data lake for correlation. Their value depends heavily on retention, indexing, and whether the organisation can tie flows back to asset owners and known network boundaries.
In cloud-heavy estates, flow logs are often one of the fastest ways to validate whether a security group, route, or peering change had the intended effect. They are also useful for proving whether a system ever communicated with an unexpected external host during an incident window.
For AWS-specific context on network visibility, cloud logging, and the surrounding control plane, the AWS Security Guide provides a practical reference point.
What Flow Logs Cannot Tell You
Flow logs do not show decrypted content, user intent, or application-layer detail. A connection to a legitimate service can still be malicious, and a suspicious destination may turn out to be routine. That is why they work best as a triage and correlation source, not as a stand-alone verdict.
They can also miss short-lived bursts, suffer from sampling or export gaps, and become noisy in very large environments. If retention is too short or baselines are not maintained, defenders lose the historical context needed to distinguish normal variation from genuine abuse.
Risk and Threat Considerations
Flow logs are valuable because they expose attacker movement and exfiltration patterns, but incomplete collection, weak retention, or blind spots at key network boundaries can leave defenders unable to reconstruct what happened. The main risk is not the logs themselves, it is assuming they provide full coverage when they only observe the traffic that passes through the logging point.
Failure mechanism: An adversary can use low-and-slow scanning, segmented lateral movement, or short bursts of outbound transfer to stay close to normal traffic patterns while evading coarse monitoring or expired records.
Impact: Investigators may miss early compromise signals, underestimate blast radius, or fail to prove whether sensitive data left the environment, which weakens containment and post-incident recovery.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored | Flow logs are a core way to monitor network services and traffic patterns. |
| ID.AM-01 — Physical devices and systems are inventoried | Flow logs become actionable when traffic can be tied back to known assets and services. | |
| PR.DS-01 — Data-at-rest is protected | Flow logs are security records whose retention and protection affect investigation quality. | |
| Recommendation — Use flow logs to monitor network services and flag anomalous connection patterns. Correlate flow records with an up-to-date asset inventory before hunting anomalies. Protect retained flow logs from tampering and unauthorised access. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | Flow logs are audit records generated to support security monitoring and investigations. |
| AU-11 — Audit Record Retention | The term’s value depends on keeping logs long enough for investigation and review. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Flow logs require analysis to surface scanning, lateral movement, and exfiltration. | |
| Recommendation — Generate network flow audit records at the telemetry points that matter most. Set retention long enough to cover detection, response, and forensic investigations. Review flow logs regularly and investigate deviations from normal network behaviour. | ||
| MITRE ATT&CK | T1046 — Network Service Scanning | Flow logs help detect scanning patterns that map directly to network reconnaissance. |
| T1021 — Remote Services | Flow logs often expose lateral movement through remote administration paths. | |
| Recommendation — Map repeated connection attempts and port probing to scanning detections. Use flow telemetry to hunt for unexpected remote-service paths between hosts. | ||
Practitioner Guidance
Why practitioners should care: Treat flow logs as evidence quality data, not just observability data. Their value depends on source coverage, retention, and whether analysts can map the metadata back to real assets and trust zones.
What to watch for: Pay close attention to rare destinations, unexpected east-west paths, unusual port usage, and long-duration connections that do not match the environment’s baseline. Those patterns often matter more than any single connection record.
Practitioner takeaway: The best flow-log programmes combine broad coverage with disciplined baselining, because metadata only becomes useful when normal behaviour is known well enough to make deviation obvious.
Related resources from NHI Mgmt Group
- What happens when audit logs and network flow data are kept in separate tools?
- How should security teams use network flow logs to spot anomalous traffic in a tailnet?
- Why do network flow logs improve detection and investigation in a private network overlay?
- Why do logs, endpoints, and network tools fail to fully detect application-layer attacks?