Date of Meeting: 2024/04/04
Zeek Leadership Team Members
(bold indicates attendance)
- Aashish Sharma, Lawrence Berkeley Lab
- Christian Kreibich, Corelight (Technical Lead Seat,)
- Fatema Bannat Wala, ESnet
- Johanna Amann, Corelight (Chair,)
- Keith Lehigh, Indiana University
- Kelley Misata, Corelight (Community Seat, non-voting)
- Robin Sommer, Corelight
- Seth Grover, Idaho National Lab
- Vern Paxson, Corelight & University of California at Berkeley (Founder Seat)
Minutes
Zeek Week Updates:
The LT started this meeting discussing the current state of Zeek Week. Everything is on track. The Call for Presentations has been posted a couple of weeks ago, and we do have a couple of first submissions.
Intermission: Please consider submitting a talk to Zeek Week – we are interested in a wide area of topics around Zeek.
The LT continued discussing the financing of the conference. Corelight has volunteered to provide a generous sponsorship to this year’s Zeek week, which lets us ensure that the conference can take place. However, getting additional sponsorships would enable us to provide some additional important services for the conference. We identified potential sponsors to contact. Furthermore, the LT discussed pricing for Zeek Week tickets; the discussion was not finished this time.
XZ supply chain attack:
The second half of the meeting was used by the Zeek LT to discuss the recent XZ supply chain attack, with an eye towards how this could impact us as a project.
We think that an attack like this directly on Zeek is unlikely to succeed. We are in a position, where all the main contributors to the project know each other in person. Furthermore every change to the codebase is reviewed by at least one other person – this policy has been in place for years.
However, we – like most open-source projects – have several downstream dependencies, that could theoretically be used to put backdoors into Zeek. For most projects, we pin specific versions that we only update manually. This limits this potential attack vector to a certain degree. However, we do not perform as thorough review of the changes in downstream projects, as we do in our own codebase. We will continue to discuss if there is a need to change our approach to these dependencies.
We want to take this as an opportunity to discuss the security considerations and best practices when deploying Zeek. A Zeek installation is, since it can see network traffic, a high-value target for attacks. Even though the Zeek project has a very good security track record, there are additional mitigation techniques that one should consider when deploying Zeek – like, e.g., having your Zeek installation in a separate network that is unable to directly communicate with the Internet.
We will publish a blog post & documentation update in the next weeks, that will detail the security considerations that users should take when deploying Zeek in their environments.