Which Zeek Alerts Do You Trust? Practitioners Say It Depends.
One team won’t start building an alert until someone has written down what it is, why it matters to the organization, what to do when it fires and how to confirm it’s resolved. Another curates and tests its Zeek alerts first, decides whether each one goes to the SIEM or triggers an automated block, and writes the documentation afterward.
Both approaches came up in September’s Topic of the Month, which asked about the detections people rely on, and most of the discussion went the same way: two teams doing a job differently, each with a clear reason why.
The detection source to trust depends on the alert
Asked which source they trust most when an alert fires, several people said it depends on the alert. For some alerts, Zeek is the most reliable source. For others, local application logs of web traffic are “far more reliable.” For alerts that combine Zeek events with other sources, as one community member put is, “The SIEM isn’t ‘downstream’, it’s the glue that binds Zeek to Active Directory, to Linux syslog, to network device events, to firewall log events.”
Another team answers “it depends” with a question of its own: “how big is the fire?” For a zero-day, whatever tool works gets applied as soon as possible. The bigger issue it making sure the team knows what tools it can bring to bear and what each one is good at.
One answer starts from the alert, the other from the incident, and both assume a team that knows its tools well enough to choose.
Tagging Zeek data at collection to answer “who owns this IP?”
Teams also differ on where Zeek data picks up its context.
At a large institution, figuring out who owns an IP address can be a non-trivial problem that slows down an investigation. One practitioner’s answer is to scope enrichment that benefits the institution at the beginning of data collection, adding tags when data is collected at the Zeek server. Their Sigma rules and analysis sit one step above the SIEM and a few layers below Zeek.
That puts ownership context in the data before an investigation starts. The “SIEM-as-glue” view puts the weight further along, where Zeek events meet Active Directory, syslog and firewall logs.
Some teams document an alert before building it, others after testing it
The documentation-first process is one its author pushed for and got management to agree on. Before building an alert, the team answers four questions, in their words:
- What is the alert?
- Why is the alert important?
- What do you do when you receive the alert?
- How do you verify the alert is resolved?
The documentation then shows what tooling fires the alert and which data sources to check next.
The team that documents afterward curates Zeek-based alerts from core log files and custom detection scripts. Once an alert is tested, the team decides whether it only needs to trigger in the SIEM or should take an automated action, like blocking bad IPs using blackhole routing.
Automatic firewall bans, with a list of IPs that never get banned
The number of teams taking automated actions on alerts and notices surprised at least one person, who wondered what those actions look like.
One reply described the setup used at a large conference, where a corpus of Suricata signatures and Zeek notices results in an automatic firewall ban for the source IP. The same setup keeps a list of IPs that never get banned, because “stuff happens” fast and you don’t want to break too many things too quickly.
That’s just one setup at one event. If your team automates actions on Zeek alerts, or has decided not to, we’d like to hear how in this Slack thread!
Thank you to everyone who contributed to September’s conversation: Aashish, Tom, Mark M., Chris C., Carlos, Fatema, Evan, Mark O., Sujala, Trong, Jakob, Dop, Aaron, and Seth.
October’s topic is “What do you do with your Zeek data?” Join us in the #topic-of-the-month channel on our Slack workspace.