In this module
NF0.9 Evidence Integrity and Legal Context
You understand evidence integrity from endpoint forensics — hashing images, documenting chain of custody, write-blocking media. Network evidence has the same requirements with different mechanics. This sub covers how evidence integrity applies to PCAP files and Zeek logs, and the legal framework that governs network monitoring.
Network evidence has two challenges that disk evidence doesn't: it's captured in transit (not at rest), and monitoring other people's network communications has legal implications that examining a hard drive doesn't. A PCAP file that was modified after capture, or network monitoring conducted without legal authority, can invalidate an investigation — regardless of what the evidence showed.
This sub covers the evidence integrity requirements for network forensics (hashing, chain of custody, timestamp integrity) and the legal framework for network monitoring in the UK and internationally.
Deliverable: Evidence integrity procedures for PCAP and Zeek log handling, and the legal framework that authorises network monitoring in corporate and investigative contexts.
Figure NF0.9 — The network evidence integrity chain. Each step ensures the evidence remains defensible from capture through reporting. Timestamp integrity (NTP synchronisation) is the most critical requirement — a desynchronised sensor produces evidence that can't be correlated with endpoint timelines.
PCAP Evidence Integrity
A PCAP file is a forensic artifact. Treat it with the same integrity requirements as a disk image.
When you capture traffic for an investigation — as opposed to continuous NSM monitoring — the PCAP file becomes a forensic artifact that may be used in legal proceedings, insurance claims, or regulatory reports. The integrity requirements are the same as for disk forensics: hash the original, document the chain of custody, work on copies.
Hash the PCAP file immediately after capture using SHA-256. Record the hash, the capture time window, the sensor identity, and the capture parameters (interface, BPF filter, capture tool version). Store the original PCAP as read-only. Create a working copy for analysis. The original hash and the documented capture parameters allow anyone to verify that the evidence hasn't been modified.
For continuous NSM captures (rolling PCAP files that overwrite themselves), the integrity model is different. The rolling capture is an evidence source, not a preserved artifact. When you identify traffic of interest, extract the relevant time window into a new PCAP file, hash it, and treat the extract as the preserved evidence. Document when the extraction was performed, from which rolling capture file, and what filter was applied.
Zeek log integrity follows the same pattern. Zeek logs are text files that are continuously appended. For investigation purposes, copy the relevant log files (or the relevant time range from those files), hash the copies, and preserve them as evidence. The original logs on the sensor continue to rotate and may be overwritten — the preserved copies are the evidence.
Timestamp Integrity
Network timestamps come from the sensor's clock. If the sensor's clock is wrong, every timestamp in every log file and PCAP is wrong.
This is the single most important integrity requirement for network forensics. A Zeek conn.log entry shows a connection starting at 14:22:15 UTC. An endpoint event log shows process creation at 14:22:14 UTC. The 1-second difference is consistent with network latency. But if the sensor's clock is 3 minutes ahead because NTP failed, the conn.log shows 14:25:15 and the correlation falls apart. Worse, you might correlate the network event with the wrong endpoint event.
NTP synchronisation must be verified on every NSM sensor. Configure NTP with multiple time sources. Monitor for NTP failure or clock drift. Document the sensor's time source in every investigation. If clock drift is discovered during an investigation, document the estimated offset and apply it to all network timestamps.
Legal Framework for Network Monitoring
You need legal authority to monitor network traffic. The authority depends on who owns the network, whose traffic you're capturing, and what jurisdiction you're in.
In the UK, the primary legislation governing network monitoring is the Investigatory Powers Act 2016 (IPA), the Regulation of Investigatory Powers Act 2000 (RIPA), and the Computer Misuse Act 1990. For corporate network monitoring, the Telecommunications (Lawful Business Practice) (Interception of Communications) Regulations 2000 provides the framework.
Corporate network monitoring is generally lawful when the organization owns the network, monitoring is for a legitimate business purpose (security, compliance, acceptable use enforcement), employees have been notified that monitoring occurs (typically through an acceptable use policy), and the monitoring is proportionate to the risk. The key requirement is notification — employees must know that network communications on corporate systems may be monitored.
For investigations that involve personal communications (email content, web browsing history), the Data Protection Act 2018 (UK GDPR) adds requirements for proportionality, necessity, and data minimisation. Capturing full PCAP that includes the content of personal emails raises different legal questions than capturing Zeek metadata that records connection timestamps without content.
For law enforcement and regulatory investigations, network evidence may require lawful interception authorization under IPA. If your investigation is being conducted in coordination with law enforcement, consult with legal counsel before capturing additional traffic.
The international dimension matters if your network spans multiple jurisdictions. EU GDPR, US ECPA (Electronic Communications Privacy Act), and other national regulations have different requirements for network monitoring. Multi-jurisdictional investigations require legal guidance specific to each jurisdiction where traffic is captured.
During the INC-NE-2026-0418 investigation, you need to capture additional network traffic from the egress sensor to monitor for ongoing C2 activity. The legal team asks whether this capture requires additional authorization beyond the existing acceptable use policy.
The answer depends on what you're capturing and why. Monitoring for C2 beacons from compromised hosts to external attacker infrastructure is a security operation — proportionate to the known threat, targeted at the compromised hosts, and within the scope of the existing AUP's security monitoring provisions. Capturing all traffic for all users "in case it's relevant" is broader and may require explicit legal review.
The proportionality principle applies: capture what you need for the investigation, document why you need it, and don't retain more than necessary. A BPF filter that captures only traffic to/from the known C2 IP addresses and the compromised hosts is proportionate. An unfiltered capture of all egress traffic for an indefinite period may not be.
When in doubt, ask legal. The 15 minutes it takes to get legal clearance is cheaper than the defense challenge to improperly obtained evidence.
Network ownership authorises you to manage the network — route traffic, apply firewall rules, implement quality of service. It doesn't automatically authorize you to intercept and read the content of communications that transit the network. The distinction matters legally.
In the UK, the Lawful Business Practice Regulations permit monitoring for specific purposes: preventing crime, investigating unauthorized use, ensuring compliance with regulations, and maintaining system security. Monitoring outside these purposes — even on your own network — may breach RIPA or the Data Protection Act.
The practical safeguard is an acceptable use policy that explicitly states network monitoring occurs, combined with proportionate capture practices that focus on security-relevant traffic rather than blanket surveillance. Most corporate network monitoring for security purposes is well within legal boundaries — but the legal authority comes from the AUP and the legitimate purpose, not from network ownership alone.
Try it: Review your organization's monitoring authorization
Setup. Locate your organization's acceptable use policy, information security policy, or any document that addresses network monitoring.
Task. Determine: (1) Does the policy explicitly state that network monitoring occurs? (2) Does it specify the purposes for which monitoring is conducted? (3) Is there a process for escalating from routine monitoring to targeted investigation capture? (4) Does the policy cover evidence handling and retention?
Expected result. Most organizations have an AUP that mentions monitoring but doesn't specify the process for investigation-level capture. If your AUP says "network activity may be monitored for security purposes" — that covers routine NSM. If your investigation requires capturing specific employees' traffic content, you may need additional authorization documented.
Debugging branch. If your organization has no AUP or monitoring notice: this is a gap that needs addressing before you deploy an NSM sensor. The technical capability to monitor is separate from the legal authority to monitor. Deploy the AUP before the sensor.
You've built the sensor and mapped the evidence landscape.
NF0 established why network evidence matters when every other source is compromised. NF1 built your Zeek + Suricata sensor with the 10 investigation query patterns. From here, every module teaches protocol-specific investigation against real attack scenarios.
- DNS deep dive (NF3) — tunnelling detection, DGA analysis, passive DNS infrastructure mapping, and the INC-NE-2026-0227 AiTM phishing DNS trail
- Protocol analysis (NF4–NF7) — HTTP/HTTPS, SMB lateral movement, SSH tunnelling, and email protocol investigation with Zeek metadata and PCAP
- Detection and hunting (NF8–NF11) — Suricata rule writing, C2 beacon detection with JA3, NetFlow analytics, and proactive network threat hunting
- NSM architecture (NF13) — production sensor deployment at 1–10 Gbps with Arkime, Security Onion, and enterprise storage planning
- INC-NE-2026-0830 capstone (NF14) — multi-stage investigation using only network evidence: phishing → domain-fronted C2 → lateral movement → DNS tunnel exfiltration
Cancel anytime