Setting Up Proper Network Traffic Visibility
Most places I consult for have network monitoring that looks good on paper and fails immediately in practice. They run packet captures on every interface, feed everything into a SIEM, and then wonder why their analysts are burning out reading log noise. The actual work starts after you decide what you actually need to see and what you can afford to ignore.I started this conversation by talking about The Practice Of Network Security Monitoring because that is the framing most teams use when they realize their current setup is generating alerts but not catching anything real. You monitor to detect deviations, not to collect data. Those are opposite goals and they require different architectures.
Defining What The Practice Of Network Security Monitoring Actually Means
Network security monitoring is the systematic capture, analysis, and correlation of network session data to identify behavior that deviates from established baselines or matches known attack patterns. It is not the same as intrusion detection. An IDS checks packets against signatures. Monitoring looks at sessions over time, correlates them across multiple vantage points, and builds context around what a host or user is actually doing.The output you want is actionable alerting backed by enough retained metadata to investigate without pulling fresh captures. You achieve that by focusing on NetFlow-style telemetry, DNS query logs, TLS handshake metadata, and selective full packet capture for high-fidelity events. That combination gives you visibility into connection patterns while keeping storage costs under control.
Building the Telemetry Pipeline
You need three layers of collection before you write a single detection rule. NetFlow or IPFIX exporters on your core routers and distribution switches give you flow-level visibility into every conversation. That covers east-west traffic you would otherwise miss. Next, you pull DNS query logs from your resolvers. DNS is one of the highest-leverage data sources for spotting C2 activity, tunneling, and lateral movement. Finally, you capture TLS handshake metadata from strategic points. SNI, certificate subject, and JA3 fingerprints tell you what tools and platforms are being used even when the payload is encrypted.I have seen teams skip the DNS layer and then spend weeks confused about how a compromised workstation was phoning home through domain generation algorithms. That is avoidable. DNS logs are cheap to collect and disproportionately valuable for investigation. My current engagement involves a mid-size healthcare provider that migrated from a scattered agent model to a centralized flow-based approach. We cut their telemetry storage by roughly forty percent while actually increasing detection coverage. The difference came from filtering noisy protocols at the collection layer and focusing on session boundaries rather than raw packet counts. Automation helps here. Tools like elastic flow analysis or proprietary monitoring platforms can generate statistical baselines from your collected data. The goal is to reduce false positives before you ever write a correlation rule. A baseline that is too tight will generate hundreds of alerts per day. A baseline that is too loose will miss actual incidents.
I recommend a phased approach. Phase one covers known-bad indicators: IP blacklists, known C2 domains, and widely scanned ports. Phase two adds behavioral rules for data exfiltration patterns, unusual lateral movement, and anomalous authentication sequences. Phase three focuses on advanced persistent threat indicators like periodic beaconing, DNS tunneling signatures, and anomalous certificate usage. The workaround I use involves tracking the inter-arrival time distribution for each host's outbound connections. Legitimate services have tight variance. Malware beacons often drift. When a host that normally calls back every thirty seconds starts varying between twelve and ninety seconds, that shift is worth investigating even if the destination IP is not on any blocklist. This tiered approach means you can investigate a recent alert with full fidelity while still having enough historical context to spot slow-moving compromises. I have seen teams try to keep two years of PCAP and either go broke on storage or give up on retention within six months because the cost became unsustainable.
The fix involved reconfiguring the monitoring pipeline to handle both address families and adding a specific check for IPv6-only destinations in the detection rules. It took about three hours to implement and prevented another six months of blind spots. Another frequent error is treating monitoring as a deployment project rather than an ongoing program. The network changes. New services appear. Legacy systems get replaced. Detection rules that worked six months ago may be irrelevant today. Regular reviews of rule effectiveness and false positive rates are mandatory, not optional. Open-source options exist for each component. Bro or Zeek provides strong network metadata extraction. Elastic or Loki handles log storage and search. Suricata or Snort covers signature-based detection. The integration work between these pieces is where the real engineering effort goes, but the modularity pays off when requirements change.
Get the Full Details
I typically suggest starting with a simple triage framework: confirm the alert is genuine, assess the scope of compromise, contain the affected assets, and document the timeline. Anything more complex than that during initial triage wastes time and increases the chance of missing a detail. A healthy program sits somewhere in the middle with a steady improvement trajectory. The goal is not zero false positives. That is impossible. The goal is a signal-to-noise ratio that allows your team to focus on genuine threats instead of chasing phantom alerts. JA3 fingerprinting has become a standard technique for identifying the TLS client software behind an encrypted connection. Different SSL libraries produce distinct JA3 hashes. When a host that normally communicates with a known cloud service starts using a JA3 fingerprint associated with a custom-built tool, that is a meaningful indicator worth investigating regardless of what the payload contains.
