Bottom Line Up Front
Network forensics is the practice of capturing, recording, and analyzing network traffic to detect, investigate, and reconstruct security incidents. When your EDR agent flags a suspicious process, or your SIEM correlates an unusual login pattern, network forensics is what tells you where the attacker went next, what data left your environment, and how long they were inside before you noticed.
This isn’t optional infrastructure for organizations under SOC 2, ISO 27001, HIPAA, PCI DSS, or CMMC. Auditors expect you to demonstrate that you can reconstruct a security event from network-layer evidence — not just say you’d “look into it” if something happened. If your incident response plan mentions forensic investigation but you have no packet capture capability and 24 hours of flow logs, you have a plan with no teeth.
This guide covers what to actually build: the architecture, the compliance mapping, the deployment steps across cloud and on-prem environments, and the operational discipline that turns a forensics capability from a checkbox into something that actually catches attackers.
Technical Overview
How It Works — Architecture and Data Flow
Network forensics relies on three data types, each with different fidelity and retention cost:
Full packet capture (PCAP) records every byte on the wire — payloads included. It’s the gold standard for reconstructing exactly what happened, but it’s expensive to store and index at scale.
Flow data (NetFlow, sFlow, IPFIX, or VPC Flow Logs in cloud environments) records metadata about connections — source/destination IP, ports, protocol, byte counts, duration — without payload. It’s cheap, scalable, and sufficient for most investigative questions.
Protocol and application logs (DNS query logs, proxy logs, load balancer logs, firewall logs) sit in between — structured, searchable, and often the fastest path to an answer.
A mature architecture layers these: flow data everywhere as a baseline, targeted full packet capture at chokepoints (internet egress, segment boundaries, high-value asset subnets), and log aggregation feeding a SIEM for correlation and alerting.
Where It Fits in Defense in Depth
Network forensics is a detective control, not a preventive one. It doesn’t stop the intrusion — it tells you it happened, how, and what to do about it. In a defense-in-depth model, it sits alongside EDR/XDR and log management as your primary source of ground truth during incident response, and it’s often the only evidence source that an attacker can’t tamper with (they can delete host logs; they generally can’t reach into your network tap infrastructure).
Cloud vs. On-Prem vs. Hybrid
| Environment | Primary Capture Method | Key Tooling |
|---|---|---|
| AWS | VPC Traffic Mirroring, VPC Flow Logs | GuardDuty, Traffic Mirroring to Zeek/Suricata sensors |
| Azure | NSG Flow Logs, Virtual Network TAP | Network Watcher, Sentinel |
| GCP | VPC Flow Logs, Packet Mirroring | Packet Mirroring to third-party sensors |
| On-prem | SPAN/mirror ports, network TAPs | Zeek, Suricata, dedicated NDR appliances |
Cloud-native flow logs are enabled with a checkbox but capture metadata only. Full packet visibility in cloud environments requires traffic mirroring configured deliberately — most teams skip this until an incident forces the question, which is the wrong time to learn your mirroring session was never configured.
Hybrid environments are the hardest case: you need consistent retention and alerting logic across cloud-native flow logs and on-prem TAP-fed sensors, typically normalized in a SIEM so an analyst isn’t context-switching between five consoles during an active incident.
Key Components and Dependencies
- Sensors: Zeek (protocol-aware logging), Suricata (signature and anomaly-based IDS/IPS), or commercial NDR platforms
- Storage: Object storage (S3, Azure Blob, GCS) for long-term PCAP retention with lifecycle policies
- SIEM integration: Splunk, Elastic, Microsoft Sentinel, or similar for correlation and search
- Time synchronization: NTP across all sensors — without it, event correlation across log sources is unreliable and your timeline reconstruction falls apart under audit or legal scrutiny
Compliance Requirements Addressed
Network forensics maps to nearly every major framework, though the language varies.
| Framework | Relevant Control Area |
|---|---|
| SOC 2 | CC7.2 (detection of security events), CC7.3 (incident evaluation and response) |
| ISO 27001 | A.8.16 (monitoring activities), A.5.24-5.28 (incident management) |
| HIPAA Security Rule | §164.312(b) audit controls; supports breach investigation under the Breach Notification Rule |
| PCI DSS | Requirement 10 (log and monitor all access), Requirement 11 (test security systems regularly) |
| NIST 800-53 / CMMC | AU (Audit and Accountability) and IR (Incident Response) control families |
Compliant vs. Mature
Compliant looks like: flow logs enabled, retained for the required period, and a documented process describing how you’d investigate an incident.
Mature looks like: pre-built detection rules mapped to MITRE ATT&CK techniques, automated PCAP capture triggered by SIEM alerts, quarterly tabletop exercises that actually exercise your forensic tooling, and an analyst who can answer “show me every host that talked to this IP in the last 90 days” in under five minutes.
The gap matters. A lot of organizations pass their SOC 2 Type II with flow logs sitting untouched in an S3 bucket that nobody has ever queried. That satisfies the control language. It does nothing for you during an actual breach.
Evidence Requirements
Auditors will typically ask for:
- Retention policy documentation — how long you keep flow/packet data and why it aligns with your incident response and legal hold requirements
- Sample investigation output — evidence that you’ve actually used the tooling, not just deployed it
- Alerting configuration — proof that network anomalies generate tickets or SIEM alerts, not silent logs
- Access controls on forensic data — who can query and export packet captures, since this data often contains sensitive payloads
Implementation Guide
AWS Deployment
- Enable VPC Flow Logs at the VPC level, sent to CloudWatch Logs or S3 for cost efficiency at scale.
- Configure VPC Traffic Mirroring on high-value ENIs (bastion hosts, database subnets, internet-facing load balancers) with a target of a Zeek or Suricata sensor running on an EC2 instance or in a container.
- Forward Zeek/Suricata output to your SIEM via a log shipper (Filebeat, Fluent Bit, or the SIEM vendor’s native agent).
- Set S3 lifecycle policies to transition raw PCAP to cheaper storage tiers after 30 days, with a defined deletion or archive point matching your retention policy.
Example Terraform snippet for flow log enablement:
“`hcl
resource “aws_flow_log” “vpc_flow” {
vpc_id = aws_vpc.main.id
traffic_type = “ALL”
log_destination_type = “s3”
log_destination = aws_s3_bucket.flow_logs.arn
max_aggregation_interval = 60
}
“`
Azure and GCP
Azure: enable NSG Flow Logs at the network security group level, feed into Sentinel via the Log Analytics workspace. Use Virtual Network TAP for full packet visibility on critical subnets.
GCP: enable VPC Flow Logs per subnet, use Packet Mirroring policies to route traffic to a collector instance running Zeek.
On-Prem
Deploy TAPs or configure SPAN ports on core switches feeding a dedicated Zeek/Suricata sensor. Size sensor hardware for sustained throughput, not average throughput — forensic capture that drops packets during a DDoS is forensic capture that fails you exactly when you need it.
Hardening Beyond the Baseline
- Encrypt PCAP storage at rest and restrict access via RBAC — packet payloads often contain credentials and PII
- Implement write-once storage (S3 Object Lock, immutable blob storage) for forensic data subject to legal hold, preventing tampering post-incident
- Integrate sensor alerts into SOAR playbooks so a detected C2 beacon automatically triggers PCAP retention extension and ticket creation
Operational Management
Daily: Review SIEM dashboards for flagged anomalies — unusual outbound volume, connections to known-bad IPs (threat intel feed correlation), DNS tunneling indicators.
Weekly: Spot-check sensor health. A Zeek instance silently dropping packets due to resource exhaustion is worse than no sensor at all, because it creates false confidence.
Change management: Any change to network topology (new subnet, new peering connection, load balancer reconfiguration) needs a corresponding review of mirroring and flow log coverage. This is the step most teams forget — and it’s the gap an auditor will find when they ask you to prove flow logs cover 100% of in-scope network segments.
Incident response integration: Your IR plan should specify exactly which team member pulls PCAP, from where, and how it’s preserved for chain of custody. Practice this in your next tabletop exercise — don’t discover during a real incident that nobody remembers the S3 bucket name.
Annual review: Reassess retention periods against current legal and compliance requirements, validate that mirroring configuration still matches your actual high-value asset inventory, and confirm sensor detection rules are updated against current MITRE ATT&CK techniques.
Common Pitfalls
Enabling flow logs but never querying them. This is the single most common gap between passing an audit and having real capability. If nobody has run a query against your flow log data in six months, you don’t have a forensics program — you have a storage bill.
Full packet capture everywhere. Capturing every packet across your entire environment creates storage costs and index times that make investigation impractical. Target capture at chokepoints instead.
No time synchronization. Correlating events across sensors with clocks that drift by even a few minutes makes timeline reconstruction unreliable — a serious problem if that timeline ends up in a breach notification or legal proceeding.
Treating retention as a compliance number instead of an operational one. Meeting the minimum retention period specified by a framework doesn’t mean it’s long enough to catch a slow, low-and-slow intrusion that dwells for months before detection.
The checkbox trap: passing your SOC 2 audit with documented flow log retention while your actual detection rules haven’t been touched since deployment is compliant and dangerous simultaneously.
FAQ
How long should I retain network flow logs and PCAP data?
Most frameworks require a minimum retention period, often 90 days to one year for logs, but align your policy with your incident response and legal hold needs rather than the compliance minimum. Full PCAP is expensive to keep long-term, so many mature programs retain flow data for a year and full packet capture for 30-90 days.
Do I need full packet capture, or is flow data enough?
Flow data answers “who talked to whom, when, and how much data moved,” which covers most investigative questions. Full packet capture is necessary when you need payload-level evidence — reconstructing an exfiltrated file or confirming malware command-and-control content — so reserve it for chokepoints and high-value segments.
Can network forensics tools replace EDR?
No — they’re complementary. EDR gives you host-level visibility (process execution, file changes), while network forensics gives you the lateral movement and exfiltration picture that EDR alone can miss, especially on unmanaged or IoT devices.
How do auditors verify network forensics capability during a SOC 2 or ISO 27001 audit?
They’ll typically request retention policy documentation, sample query or investigation output, and evidence that alerts generate tickets through your incident response process. A configuration screenshot alone usually isn’t sufficient — they want proof the capability is actually used.
What’s the biggest mistake teams make when first implementing network forensics?
Deploying the tooling without building the operational muscle to use it — no baseline of normal traffic, no tested query workflows, and no tabletop exercises that actually exercise the forensic data path during a simulated incident.
Conclusion
Network forensics is one of those controls that looks simple on an audit checklist and is genuinely hard to operationalize well. The technical deployment — flow logs, traffic mirroring, a Zeek sensor — is a few days of work. Building the muscle memory to actually use that data during a 2 a.m. incident, with clean evidence and a defensible timeline, takes ongoing discipline that most lean security teams struggle to maintain alongside everything else on their plate.
If you’re heading into a SOC 2 audit, building out your ISMS for ISO 27001, or trying to close the gap between “we have logs” and “we can actually investigate,” SecureSystems.com can help. We work with startups, SMBs, and scaling teams across SaaS, fintech, healthcare, and e-commerce to build compliance and security programs that hold up under real audits and real incidents — with transparent pricing and hands-on implementation, not just a policy template dump. Book a free compliance assessment and find out exactly where your network forensics capability — and the rest of your security program — actually stands.
