In our continuing People of Zeek interview series, today we have Phil Rzewski, Technical Director at Brim Security and active Zeek community member. Phil, thank you so much for taking time out of your schedule to answer a few questions and let the community get to know more about you and your organization.
Phil Rzewski (PR): – Thanks for the opportunity, Amber!
Amber Graner (AG): Phil, can you tell people a little bit more about you and how you became involved in the Zeek Community?
PR: My first exposure to Zeek was when I joined Brim in late 2018. Our founder Steve McCanne (who wrote libpcap and co-authored tcpdump) and the first couple developers at Brim had come up with some clever ideas to really unlock the potential of Zeek data. I’ve worked with Steve off and on for most of the past 20 years, so when Steve invited me to see a demo of an early Brim prototype, I was immediately hooked. Of course that meant I had to quickly learn about Zeek: What users love about it, and where they need help. I really enjoy getting hands-on with new technologies, so I spent a ton of time reading older posts on the Zeek mailing list, getting acquainted with some adjacent community work (the Logstash configs from Security Onion are great for understanding Zeek with ELK!), and just hacking by running it on my laptop to sniff my own traffic.
AG: How does Zeek play a role in your day to day activities?
PR: At the moment, Zeek is the main data source we’re concerned with in the software we write at Brim, so it affects almost everything I do.
Much of what appeals to me about Zeek data is the richness of its data typing system. It’s great to look back at Vern Paxson’s original Bro paper and see it was all laid out this way from the beginning. As I learned how Zeek came to be used over the past 20+ years, it surprised me to see how many large-scale deployments turn all the events into JSON and either lose the data typing completely or restore it downstream through some awkward, out-of-band hack. Given that we’re all on the Internet, it’s baffling to me that the dominant portable data formats don’t include native data types for IP addresses, sets, or time. But Zeek does!
In terms of day-to-day activities, I’m often thinking of ways to use that rich data typing approach to solve problems in an elegant way. This led the team at Brim all the way to creating a new open data format called ZNG that takes what’s great about Zeek’s format & data typing and extends it even further. It’s a big topic all its own, so if the community wants to hear more, Steve McCanne would be a great person to go into more detail.
AG: We’ll talk more about Brim Security in just a few questions, but what excites you about Zeek and the community?
PR: I think it’s fantastic that Zeek has become such an essential tool for security use cases. But since my background is in general network architecture, I recognize that Zeek’s foundations could be applicable to so much more. It’s kind of hidden now since it’s at the old.zeek.org site, but I recently came across a great quote from there: “While focusing on network security monitoring, Zeek provides a comprehensive platform for more general network traffic analysis as well.” It’s so true! For instance, a Zeek conn record holds the 5-tuple and start-time/duration information for every observed flow, which can be the basis for quickly extracting flows from an indexed packet capture. That’s very powerful. And that’s before we’ve even started to talk about all the app-level detail Zeek provides via the protocol parsers! By comparison, a Wireshark user is accustomed to waiting several minutes to parse through a multi-gigabyte packet capture in order to see parsed protocol messages or isolate a single flow. Once you show a Wireshark user how much of that protocol detail is right there in the Zeek logs, they’re hooked. And that’s even if they don’t claim any security expertise whatsoever!
I see similar untapped potential in the Zeek data format. Imagine how much simpler operations could be if every system that generates logs could have the well-defined structure, in-band schema, and rich data typing we see in Zeek logs (or ZNG), rather than flat text or JSON. The Zeek community could play a huge part in making this happen, just by starting to write output plugins for their favorite tools.
AG: How and where would you like to see more people and organizations get involved in the Zeek community?
PR: The big opportunity that comes to mind is protocol parsing. I was excited when I heard about the launch of Spicy. When Brim was initially launched, it saw a lot of adoption by the large community of Wireshark users. Several of them expressed disappointment that they weren’t seeing detailed Zeek logs for some of the protocols that Wireshark parses out-of-the-box. To cite a specific example, I was asked about Brim support for a protocol called SSDP, which I was unfamiliar with. So once I grepped the Zeek code base and confirmed my suspicions that it just wasn’t there yet, I felt a little unsure how to guide the user further. Sure, they could start reading up on how to write a traditional Zeek protocol analyzer, but C++ is a challenging learning curve. If Spicy successfully lowers that barrier to entry, the community could bring about a future where the same breadth of parsing we see in Wireshark is also available in Zeek. How cool would that be?
AG: For others who would like to get involved in Zeek or other open source projects what would your advice be to them?
PR: For me, communication is always key. I was super geeked when the Zeek community started its own public Slack system. Mailing lists are great, but as an Internet older-timer, I still remember that warning that used to pop up every time I sent a message on Usenet: “Your posting will cost hundreds, perhaps thousands of dollars. Are you sure you want to do this?” There’s something much less daunting about sending a message on Slack. I like having channels for specific sub-areas of interest. If the right people are there to respond, it’ll start a thread and we can go as far as we want with it.
For open source projects in general, I find browsing the open GitHub Issues is a great way to feel out the state of a project. For instance, one project I researched recently had been written to work with v2 of a protocol spec, and the v3 of that protocol had already been out for years. There was a GitHub Issue where a user had asked about when v3 functionality would arrive, and it had been open for 2+ years and had almost 200 “thumbs up” from other users who also felt it was important. But neither the original maintainer nor anyone else from the community seemed to feel like they could swallow the pill of updating the code to make it current. So if I cared about that v3 functionality, this gave me a lot to think about before going further with the project.
AG: Can you tell readers a little more about Brim Security? How is Zeek used in your open source desktop application and other products?
Brim Security is a seed stage startup headquartered in Oakland, California, and our main open source software project is also called Brim. We’ve got a few backend developers that write Go, a couple frontend developers that write JavaScript, and Steve McCanne is our “coding CEO” who quickly prototypes a lot of the cool new ideas for what comes next. Several of us have worked together at previous startups that both succeeded and failed, giving us lots of lessons about what to do and not to do. There’s even remnants from previous open source projects that we’ve brought back from the ashes, and it’s always satisfying not having to rewrite those things from scratch.
In its current form, Brim is all about providing a desktop experience for querying Zeek data. In addition to being our primary data source, Zeek is actually embedded in the Brim desktop application to turn packet captures into logs. For users that import their pcaps, Brim uses the 5-tuple & time info from the Zeek conn record (as I described previously) to quickly pivot from any Zeek event to its underlying packet-level detail. And that’s just one trick that Brim has up its sleeve. We put out a YouTube video that walks through all the app functionality.
AG: Is open source important to you personally and to your organization? If so, why? What can others learn from integrating open and transparent principles and philosophies to their workflow?
Open source is very important to us. If we think back to past lives when many of us were selling licensed hardware and software, just getting an enterprise to engage with you as a “vendor” often meant huge hurdles: NDAs, license agreements, etc. And that’s just to convince them to touch the technology… after which they might tell you that it stinks! By comparison, if what you want is exposure to real-world use cases, being open source brings down so many barriers. Organizations that take pride in their $0 software spend suddenly are keen to check out the tools and provide their unfiltered feedback. Even if an organization is so conservative that they won’t touch open source projects in an official way, it seems most engineers run “home networks” where they tinker with new tools in their spare time. Since we’re at an early phase where our #1 priority is to interact with smart users, this arrangement works out perfectly. We can put our stuff on GitHub, say “File an Issue or come find us on Slack!”, and sure enough, they find us.
AG: What would you say is the most valuable/important lesson you have learned from being involved in and adopting open and transparent practices?
PR: Writing code “for public consumption” can feel scary at first, but once it becomes force-of-habit, it makes us better as creators. We can never know precisely who will find our work and what they might do with it, but we want their experience to be favorable. So for every line we commit into our repos, it makes us confront whether something is truly “finished” or if it’s still in the prototype phase, then represent it as such to the users.
AG: If you have one take away message you’d like readers to know about Brim Security what would it be?
PR: That there’s much more to come, and it’s coming pretty fast. It’s only been a month since our “v0” launch that was all about the pcap-centric use case, and we’re following up with the next big revision that allows direct import of Zeek logs in TSV and JSON format. We expect that’s going to be very appealing to traditional Zeek users.
In parallel, Steve McCanne has been busy prototyping the next big idea, which is all about taking what we’ve done with Zeek/ZNG data in Brim and applying it to finding the needle-in-a-haystack in a long tail of archived security logs. For instance, imagine you’ve got some IP or file hash that’s involved in a current incident, and you want to go back months or even years to dig up more info about when it all started. We’ve talked to users who solve this problem today either through custom tooling or heavyweight inverted full-text search software, both of which come with great expense. We think we’ve come up with a better way. It’s all being created through what we call our “tools-based approach”, where the same open source components that make up the Brim desktop experience can be assembled in different ways along with new code to solve adjacent problems. Many of those components are in zq, our other big open source project. Think of it kind of like how Unix pipelines bring together several tools that are each fairly simple on their own, but combine to do something powerful. Taking this approach in an open source community feels like a great way to quickly establish if we’re on the right track, and if we are, follow that up with the smooth UX treatment like we’ve done with the Brim desktop app.
AG: Is there anything I haven’t asked you about that you would like readers to know?
PR: While we consider ourselves very much part of the Zeek community, we’re forming our own little community as well. It’s a way for Brim users to give us feedback, report problems, and seek guidance as they start digging into the code. We’ve got our own public Slack system set up, and the links to invite yourself are on our website and in the READMEs on GitHub. So whether you want to report a bug or ask more about our new ideas to help with archived logs, come say “hello!”
RSS - Posts