A network engineer in a Zeek Week world

With almost two decades of networking experience, I recently made my first foray into a security-centric user conference at Zeek Week, an annual conference for the user community of the open source network security monitoring platform known as Zeek (formerly Bro) held last month in Seattle. I’m also seven months into a new job here at Corelight as a product manager, and I’m still as excited about Zeek as I was last month about Zeek Week. Why?

Looking through Zeek data and collateral, I’ve been exploring questions like, “why are Zeek DNS logs so incredibly awesome to me as a network person, and awesome to the threat hunter too, but for totally different reasons?”, and “what do you mean, TLS 1.3 doesn’t mean the end of security monitoring as we know it?” 

First, let me set the stage:. I’ve spent almost all of my career on the Network side of the house. I’ve spent time at most of the major core and edge router vendors in Silicon Valley, and have almost two decades of experience in network architecture, protocols and service provider networks; however, I’m relatively new to security. Security is a broad term, but no matter how you slice it, it’s new to me, and I’ve been absorbing how the Corelight team and Zeek’s founders look at the world. 

At Zeek Week, I found that many of the security folks attending have the same questions. For logs and log data, there were talks on how to use the Zeek data to threat hunt and real life examples of issues found and squashed with Zeek, like the presentation given by Aashish Sharma from the Lawrence Berkeley National Lab. Aashish walked us through a construction of incident timelines, using the log data. As a network person, I look at the DNS.log information from Zeek as a treasure trove that helps me debug when my DNS services aren’t performing correctly. The security folks were looking at the same data and understanding that someone might have hijacked the responses to redirect (or not) clients elsewhere. This was a powerful and eye-opening experience for me.

Network folks enjoy protocols and products that have multi-purposed names, and it seems security folks are no different. The MITRE Corporation (known as MITRE), recently released a Zeek package called BZAR (Bro/Zeek ATT&CK-based Analytics and Reporting) that detects ATT&CK-based adversarial activity. Many customers I’d had contact with were interested in the BZAR project, and Mark Fernandez with MITRE gave an excellent session laying out both the logic and practical proof points for the different elements within the BZAR package. What struck me was the ability to leverage a community-sourced package – MITRE is not Corelight, after all – and immediately deliver on expanded threat detections. I can’t think of many network tools that actually deliver on the “package strategy”, and the MITRE work demonstrates the power of the open source community to me. 

Encryption and the advent of TLS 1.3 – it’s on everyone’s mind, whether your focus is on the network or security. Before Zeek Week officially started, this year there was a first-ever

“Intro to Zeek” training session, followed by a “Making Sense of Encrypted Traffic”. Matt Bromiley taught the “Making Sense of Encrypted Traffic” session, and later in the week, another session on encryption and JA3 from Gigamon were eye opening. Encryption is definitely a reality, and TLS 1.3 encrypts more than ever before, but both sessions demonstrated that there was still a lot of valuable information that Zeek makes available in it’s logs. Both presenters were super excited and enthusiastic about the power of Zeek in an encrypted world. 

I hadn’t realized when I registered for the training session that there would be a “Capture the Flag” session as a part of the “Making Sense of Encrypted Traffic” session. But there was, and I admit, I wasn’t even sure what “Capture the Flag (CTF)” meant – this isn’t something we do on the network side of the house. Matt taught the session, engaging the crowd as he walked among us, looping us into the conversation, walking through examples, asking us questions, and then laying out the challenge. Who would be first to capture the flag and complete in record time? Using the skills that we’d learned in the morning from Keith Lehigh, including how to run Zeek in our VM, generate output, look at the output, search the output, and ingest PCAPs, the afternoon was spent with (some of us) furiously typing away, completing question after question. The air was thick with tension, positive tension mind you, and palpable enthusiasm. 

It was one of the neatest afternoons I’ve spent. Woefully aware that I still have a lot to learn and the journey of “Zeek newbie” is just beginning for me, I’d happily do it again. I left the session with a thorough understanding of how much Zeek can parse and discern from encrypted flows – despite the fact that they’re, you know, encrypted – and that there is still a lot of information to be had. I left the session thoroughly motivated to dig into Zeek and spend more time piecing together what I’ve read in the documentation with the hands-on approach of a lab. I left the session motivated to come back next year and beat my fellow Corelight colleagues’ times if there’s another CTF exercise (even though it’s not a competition in the strictest sense of the word).

While I enjoyed the various presentations over the 2.5 days of Zeek Week, I’d be remiss in not mentioning the other ways in which participants connected. Breaks during Zeek Week were generous in length, giving us time to congregate in the hallways, find a fresh warm tea, check out the demo stations from various vendors, and meet new people. 

I’m a product manager, so it’s in my nature to want to understand use cases, and I met so many different folks who were happy to share how and why they use Zeek. The passion and enthusiasm of the crowd was infectious, and on display during meals and at break time. I learned that one particular attendee was from a company with over 2,000 Zeek servers. His deployment is huge and on a scale that most others aren’t. I learned that another attendee was from another company grappling with Zeek and security and what that meant for privacy in their country. Corelight had sponsored a package contest – write a useful Zeek package and contribute it to the community – and I met several individuals who’d participated in that contest, and learned why they’d chosen the topics they had. I was struck at how truly easy it was for the package contest winner to come up with an idea, implement, and contribute the package back to the community – all within the space of 3 days. Her amazing talent and feat aside for a moment, it’s a testament to the power of Zeek and its ability to be extensible, one of the founding tenets of the project.

Zeek Week was an amazing experience for this first timer. Having spent seven months learning from other Corelighters and customers, it was nice to meet people face-to-face, have the hands on experiences of the labs and training, hear from presenters that are just as excited about Zeek as we are, and meet other users who might differ in locale or differ in job title or differ in how they use Zeek, but are all united in their passion for what the project allows us to do. I learned that the open source community is passionate and enthusiastic about the power of Zeek. I learned that TLS 1.3 does not mean the end for visibility in the network. I learned that Zeek data looks different to me than it does the threat hunter, but that threat hunters are able to weave and pivot across the Zeek UID to track down what happened, when, and ultimately determine if something was (or wasn’t) compromised or data was stolen. I learned that Zeek’s DNS.log is an incredibly powerful tool that shows how Zeek data provides far more value than even Daemon logs for the protocol do. 

Ultimately, I learned that threat hunters look at the data differently, which makes sense – their goals are different than those operating the network. Zeek data is security data created by security professionals, and it is approachable for network professionals as well.