Today we kick off our weekly interview series with the Open Source Zeek Leadership Team and community contributors with Robin Sommer.
Before we get started, I’d like to thank Robin for taking the time to answer my interview questions and kick off this series.
Amber Graner (AG): As one of the core developers of Zeek (formerly Bro) I am sure you are no stranger to the community. However, can you introduce yourself to readers who may not know you?
Robin Sommer (RS): I became involved with Zeek in the early 2000s when I was still a graduate student in Germany looking for a research subject in network security. After starting to contribute small patches, Zeek quickly became my primary research platform; that work led to a number of new capabilities that then made back into the open source distribution. During that time I spent a couple of summers in Berkeley working with Vern at the International Computer Science Institute, and I later joined his group as staff researcher. When the National Science Foundation decided to invest into building out Zeek as an operational tool for the US research and education community, I began leading the team behind that effort. Today, I am the CTO at Corelight, a startup that Vern, Seth, and myself co-founded to bring Zeek’s capabilities to enterprise environments.
AG: When you got interested in then Bro, now Zeek, what was the driving factor that made you want to join forces with Vern to get involved and drive this project?
RS: Zeek has always offered both a powerful platform for experimentation and a strong deployment base in real-world networks—a combination that’s gold for academic research. On the platform side, Zeek’s clean architecture separates low-level packet processing from high-level analysis and detection. As result, Zeek can not only accommodate very different environments, but also support new technical approaches that would be challenging to incorporate into other systems. On the deployment side, some of the most demanding sites started using Zeek pretty much from the beginning—which provided invaluable operational feedback for evaluation & refinement.
AG: At the recent Open Source Zeek European Workshop 2019 held at CERN in Geneva, Switzerland, you gave a talk, Looking Forward: On Supervisors, Packages, and Sandboxes. In this talk you discussed 2 topics, 1) Replacing BroControl and 2) Rethinking Zeek Packages. For those who weren’t able to be at this event and hear your talk can you give a summary here?
RS: This talk was a bit of an outlook into new things that we have on our roadmap. The more concrete of the two efforts is developing a replacement for BroControl, Zeek’s current management framework. BroControl was originally developed for a setting that’s quite different to what most Zeek users are using today: a physically distributed cluster of individual PCs all running Zeek. BroControl came out of our own desire to avoid some of the maintenance tasks coming with such a setup: installing Zeek across many identical systems, pushing out new configurations, health monitoring, etc. Today, however, even large environments are often running Zeek just on a single system, leveraging all the cores available these days instead of scaling across systems. On a single system, BroControl can feel pretty quirky unfortunately. To address that, we are planing to turn Zeek itself into a persistently running service that—while still using the traditional cluster architecture internally—will have a dedicated supervisor process that spawns and manages the necessary processes as its children behind the scenes. Doing so will fit much better into standard Unix service models.
The second part of the talk was really only some early brainstorming exploring better support for running externally provided, untrusted scripts in your Zeek installation. Zeek’s package manager has been a huge success, with more than 80 packages now out there contributed by the community. However, when installing one of these packages, there’s currently no isolation between what your local scripts and that external code. That can quickly turn out problematic: It’s pretty common for Zeek scripts to exhibit widely different performance characteristics depending on the network they are running in. If an external package ends up using up all your CPU or memory, that will shut down all your monitoring. To address that, I’d like to explore isolating scripts by running them inside separate processes. This idea is quite speculative at the moment; it’s unclear if it’s even technical feasible. But it’s an example of how we have often approached new Zeek functionality in the past: Starting with a proposal for discussion and feedback, we’d then try implementing a first prototype to gauge if it makes sense to go in further.
AG: In addition to Replacing BroControl and Rethinking the Zeek Packages, what else would you like the Zeek community to get involved with. Scripts? Plugins?
RS: There are really many ways to contribute to Zeek these days, you don’t need to write C++ code to bring value to the community (although you can!). The most direct way is publishing Zeek packages: If you have written a custom Zeek script, I encourage you to make that available; it’s not hard. Beyond scripts, documentation is probably (still) our main bottleneck. While we want to improve, there’s only so much that we can do on the project’s side. The real value of Zeek comes from the many different use cases that it supports, and only the community as a whole can collect & disseminate that expertise. So I would like to encourage people to share what they have learned: Write blog postings, give presentations, participate on the mailing lists, join meet-ups.
AG: Besides Zeek, are there any other projects that you’re involved with and would like to share?
RS: Most of my open source work focuses on the broader Zeek ecosystem—there’s always plenty to do there. One of the related projects that I’m most excited about is Spicy: A new protocol parser generator to replace Zeek’s existing BinPAC system. As many in the community may have heard, there’s already a Spicy prototype available that demonstrates the new capabilities, but it isn’t ready for production usage yet. At Corelight, we are working on a new version of Spicy that will make Spicy real. There’s no release date yet, but the code will become open source under BSD license.
AG: Is there anything that you’d like to share with readers about Zeek that I haven’t asked you about?
RS: I would just like to thank the Zeek community for all the amazing things everybody is doing. There’s a reason that many of us on the core team have been involved with the project for such a long time: It’s extremely rewarding to work with such an excited community that always finds new ways to push the system’s boundaries into directions nobody had ever anticipated.
Thanks again, Robin!
Helpful Links and information:
Events: Stay tuned we’ll be announcing ZeekWeek dates and location this week.
Getting Involved: If you would like to be part of the Open Source Zeek Community and contribute to the success of the project please sign up for our mailing lists, join our IRC Channel, come to our events, follow the blog and or Twitter feed. If you’re writing scripts or plugins for Zeek we would love to hear from you! Can’t figure out what your next step should be just reach out. Together we can find a place for you to actively contribute and be a part of this growing community.
About Zeek (formerly Bro): Zeek is a powerful network analysis framework that is much different from the typical IDS you may know. https://www.zeek.org/
About Corelight: Corelight makes powerful network security monitoring solutions that transform network traffic into rich logs, extracted files, and security insights for incident responders and threat hunters. Corelight Sensors run on open-source Zeek (formerly called “Bro”) and simplify Zeek deployment and management while expanding its performance and capabilities. https://www.corelight.com
RSS - Posts