Most conversations about sensor placement focus on where to tap. Perimeter, core network, east-west segments. Pick your spot and start capturing. But one contributor to this month’s community discussion put it in a way that resonated: before you decide where to tap, you need to understand how your network actually works. A topology diagram isn’t always enough to get you there.
The underlying questions are consistent regardless of environment: where does traffic actually flow, what do you need to see, and what are you willing to accept not seeing? Our recent Topic of the Month discussion showed how differently those questions get answered in practice.
The Map Is Not Enough
A topology diagram shows you where things are. It doesn’t show you how traffic actually moves, where routing decisions get made, or where packets end up when something unexpected happens. Those details live in the heads of the engineers who built the network, and if you don’t know them before you decide where to tap, you can end up with sensors in the right-looking places that produce misleading or incomplete data.
One practitioner who has monitored networks ranging from home labs to large conference environments (including Black Hat and the Supercomputing Conference) put it plainly: it’s not enough to point at choke points on a diagram and say “tap here,” because there are other things that come into play. Split routing is one example. If a network has multiple egress points and traffic is allowed to take different paths in and out, packets for a single session can end up on separate links monitored by different Zeek workers. Instead of one cohesive log, you get two incomplete ones, neither useful on its own. The fix requires either re-engineering the network (rarely realistic) or investing in packet brokering to aggregate traffic before it reaches Zeek.
A quick lesson here is to involve the people who built the network before you decide where to tap. They know where the traffic actually goes, and a conversation with them upfront can save you from discovering the hard way that your placement assumptions were wrong.
Every Deployment Accepts Some Blind Spots
Perfect visibility isn’t available to most practitioners. Budget, hardware, network topology, and link speeds all constrain what’s actually possible. A community poll this month reflected that: most said network topology was the biggest factor shaping their placement decisions. As one contributor noted, the question probably deserved a ranked-choice format because for them, most factors were at play simultaneously, just with different weights.
The tradeoffs show up differently depending on the environment. Three examples from this month’s discussion:
One operator managing a network across multiple remote locations described maintaining dedicated hardware at each point of presence as a significant operational burden. Rather than refreshing systems at end-of-life, they’re moving toward forwarding that traffic centrally instead.
Another practitioner, working with essentially no budget for specialized equipment, set up port mirrors at the core and on SAN distribution switches. The core mirror captures north-south traffic and about 60% of east-west, with the SAN mirrors picking up additional east-west coverage. Intra-VLAN traffic remains outside what Zeek sees.
A third had previously captured 90% of intracampus traffic from mirror ports off the core, but rising link speeds forced a fallback to cross-border traffic only (internet-facing traffic crossing network boundaries, as opposed to internal east-west).
Each represents a deliberate decision about which blind spots are acceptable given real constraints, not a failure. The practitioners who contributed weren’t apologizing for their setups. They were describing the reasoning behind them, which is exactly what makes that knowledge useful to someone else facing similar tradeoffs.
Don’t Skip What’s Outside the Perimeter
Several contributors made a case for tapping outside the firewall, not just inside it. The reasons are worth being specific about because they’re different.
One argument is about verification: if you’re only tapping inside the perimeter, you can’t confirm that your defenses are doing what you think. Tapping on both sides lets you compare what’s hitting you with what’s making it through. If traffic that should be blocked is showing up inside anyway, you want to know before it shows up somewhere worse.
The other argument is about intelligence: for organizations that are frequent targets, outside-the-perimeter data captures patterns in what’s attempting to get in. One practitioner at a research institution described it as understanding what’s trying to get in versus what actually makes it past Zeek—a meaningfully different kind of visibility from what you get monitoring inside the wire alone.
Context Shapes Everything
The diversity of environments in this month’s discussion makes clear that sensor placement isn’t a problem with a standard answer.
One practitioner monitors OT networks in substations, placing sensors at Level 1 and Level 2 to watch for unusual behavior between RTUs, SCADA systems, and HMIs. The placement logic is fundamentally different from enterprise IT, driven by the Purdue Model and the specific protocols in use.
Another runs 20-plus VLANs on a home network, with a single choke point at the trunk interface that delivers 100% of north-south traffic and around 90% of east-west. The lesson they drew from it generalizes: more segmentation creates more choke points, and more choke points create more opportunities to find placements where the visibility-to-cost ratio makes sense.
A network provider monitors data centers, points of presence, and a sinkhole (a tap on address space they own that has no specific route, useful for catching configuration errors). These are three active strategies serving three distinct purposes. A fourth location (WAN peering points) was attempted but abandoned: SPAN port contention meant the routers couldn’t mirror the same traffic twice.
What this range makes clear is that the underlying questions are the same across all of them. Where does traffic actually flow? What do you need to see? What are you willing to accept not seeing? Every environment answers those differently, and that’s exactly why talking through placement decisions with other practitioners is useful.
Want to share how you approach sensor placement? Join the conversation in the Zeek Slack community.
Thank you to the community members who contributed to May’s Sensor Placement conversation: Dop, Aaron S., Chris C., Mark O., Seth, Aashish, Glenn, Jim, Timothy, Kevin, Eric, Mark M., Trong, and Carlos.
This month we’re talking about Detection Techniques. From notices to intel framework to custom scripts, how are you actually using Zeek to find bad things on your network? Join the conversation today in our Slack workspace.
RSS - Posts