Every month we pitch a topic to the Zeek community and see what comes back. June’s focus was related to detection techniques: how is everyone actually finding bad things with Zeek, and what tradeoffs come with it? Throughout the month we learned quite a bit about the processes, constraints, and tradeoffs around detection, and we even got insight into how the Zeek team thinks through open architecture questions.
How do you actually flag something as a detection? Here is what members of the Zeek community shared about their process.
How Do You Use Zeek to Flag Detections?
Eighteen people answered a poll in response to this question about flagging detections. Custom scripts led at 44 percent. SIEM rules built on top of Zeek logs followed at 33 percent. Built-in Zeek notices came in at 22 percent. The Intel Framework, a feature that’s existed in Zeek for years, got zero votes.
Zero votes for Zeek’s very own Intel Framework? We found that curious, so we dug deeper.
As it turns out, it wasn’t that the framework was hard to configure or poorly documented. In reality, the problem with the Intel Framework, we heard, sits one layer above the tool. One contributor described maintaining threat intel as a full time job in its own right, and pointed out that no single feed fits every environment. Another put a number on the decay: good intel is useful for a few days at most. By the time an indicator shows up on a public feed next to hundreds or thousands of others, whatever made it worth flagging has usually already happened somewhere else. What both landed on instead was the same move: build detection from your own historical and live data rather than someone else’s list.
What Happens After Something Looks Suspicious
A second poll asked what people actually do once something suspicious shows up. Most go to a SIEM or dashboard first, then dig into the underlying logs to confirm whether it’s real or noise. One contributor flagged a specific risk in stopping at step one: a dashboard that isn’t well tuned can look clean while it’s actually missing things, and a quiet dashboard isn’t the same as a clean network. The second step, actually digging into the logs, is what catches the gap.
From the responses to both questions it was clear that practitioners in the Zeek community trust their own data over anything that arrives from outside, whether that’s a public threat feed or a dashboard that hasn’t been checked against the raw logs underneath it.
Where Should Detection Logic Actually Live?
There was also a harder question underneath all of this: not just how you detect something, but where that detection logic should actually live. One community member described a setup where in-house code applies Sigma rules to Zeek telemetry downstream, after the logs leave Zeek entirely. He asked whether pushing that matching further upstream, into Zeek itself, would actually buy anything.
Christian, Zeek’s technical project lead, offered a way to think about it rather than a flat answer. The real question, he said, is whether you care more about Zeek’s logs themselves or about the detections built on top of them. If it’s the logs, keeping matching downstream is probably right. If it’s the detections, there’s a case for writing directly into the matching pipeline and treating the logs as transient evidence rather than a durable record. He was upfront that he didn’t know how well this would hold up for more complex cases, like detections that need to match across multiple logs, or how deep the integration could realistically go inside Zeek’s scripting layer.
It’s an open question. But it’s a well-framed one, and exactly the kind of tradeoff worth thinking through before committing to an architecture. If you’re running Sigma, or something like it, on top of Zeek: where does your matching happen, and would you build it differently today?
What This Adds Up To
While the Intel Framework works as designed, Zeek’s logs are flexible enough to support detection wherever you decide to put it. What the conversation actually uncovers is a community that’s doing the hard work of figuring out what actually holds up in their own environment.
If any of this matches what you’re working through, the conversation is still open in the Zeek Slack.
Thank you to the community members who contributed to June’s Detection Techniques conversation: Yacin, Phuong, Dop, Chris C., Timothy, Carlos, Smoot, Chris H., Kevin, Mark, Aaron, Aashish, Trong, Sree, Tom, Pedro, Eric, Seth, and Christian.
July’s topic will be announced soon. Join the conversation today in our Slack workspace.
RSS - Posts