We started Corelight to bring the power of Bro network monitoring to an audience that is interested in security, stability, and long-term sustainability. Even though we created and built Bro over the last 20 years, when we developed our commercial product we made some design decisions that make running the Corelight Sensor slightly different from running open-source Bro… changes to improve performance, security, and deployability. Here we’d like to explain the rationale behind a few of these decisions.
We take a diligent approach to new features on our platform because Bro’s biggest benefit of programmability can also be a liability. From the beginning, we wanted to expose the full richness of Bro analysis to our customers, but we also chose to limit some functionality at first, because they did not meet the high quality and security standards required by an enterprise-class commercial product. As we continue along our development roadmap, we’re revisiting these items to find new and better ways to implement these features in our sensors and potentially contribute back to open-source Bro.
Let’s go through a few of these differences, along with some of the extra features that you get with the Corelight sensor that distinguish it from open source Bro.
API-Driven
Users of open source Bro know how to run Bro with broctl (BroControl) because it helps with managing everything from a single process to large multi-system or even multi-location clusters. This works very well in the open-source community where users are familiar with running software at the command line, but we felt that we shouldn’t offer this same interface for our commercial customers, because with it comes a lot of complexity. Our appliance is fully API-driven, and we currently expose that API through two mechanisms: directly from our command-line client (https://github.com/corelight/corelight-client), or over SSH through our terminal-based GUI. Broctl gives our open-source users a great deal of capability, but we took the approach of wrapping most of that functionality in other mechanisms to simplify management for our customers. We are currently exploring how to take what we’ve learned from offering this experience to our customers back into the open-source world because a core mission of the company is to continue improving Bro.
Intelligence (Intel) framework
The Intel framework is used by Bro to read in indicators of compromise (IOCs) from external sources at runtime and do matching deep into network traffic. For example, if you load in an email address, Bro will watch for that email address in, for example, the “emailAddress” object identifier of X.509 certificates used in SSL/TLS session establishment (as well as a number of other places).
The problem is that the way people typically load intelligence data into Bro is with a format that I specified in 2013 when I created the Intel framework which has literal tabs in the file separating fields. It’s like CSV, but using an invisible character! This causes trouble for people who are hand-creating these files, as you can imagine. We left the intelligence integration out of our Bro appliance from the beginning because of the number of problems we’ve seen people encounter with formatting the files correctly. We also noticed that many of our enterprise customers were instead applying their IOCs to the logs in their downstream data analysis system.
Eventually, we will want to cleanly integrate with threat intelligence management platforms where data can be pulled in more quickly and there are no concerns with file format accuracy. In the interim, we are now working on integrating the Intel framework into our appliance with some guardrails. Our platform API will enable you to load in the “normal” Bro intelligence files, but our system will extensively sanity-check them so you get a response immediately from the API if you made a mistake. This should provide a nice mix of people that want to sit as close to the metal of Bro as possible, while still getting the enterprise approach to stability that we press so hard for at Corelight.
Bro scripts and Sandboxing
One of the absolute best features of Bro is the scripting language. It’s the true differentiator between it and many other network monitoring systems. Users can write their own scripts which add new chunks of functionality to Bro, even as far as creating logs that reflect their own environment and unique challenges. For an example of this, take a look at the script Salesforce published for fingerprinting SSL/TLS clients (https://github.com/salesforce/ja3). The team at Salesforce was driven by their internal needs to understand SSL/TLS usage on their network, and that need resulted in a script that any Bro users can now load.
The problem at Corelight was that the intense customizability provided by Bro could be a liability for our customers because scripts can have adverse effects on the stability and correct behavior of the software. Due to that, our stance on custom scripts was to initially not make them available, but while keeping an eye toward eventually doing so, in a safe and robust manner. Ultimately, after a lot of discussion, we designed a sandbox that the scripts run inside so that you can feel confident that the scripts you are loading on our appliance are safe. The sandbox restricts a number of functions from being used, along with some behaviors that we know to be non-performant. For example, we bar the new_packet event from use due to its potential for causing major performance issues. This trades a small reduction in capability for removing a feature fraught with side effects.
The sandbox took quite a bit longer to create than we initially expected but we felt that rushing it out would fail to live up to the level of quality we strive to always provide. One thing I’ve always found interesting is that sometimes through restrictions, the most creative results arrive. By creating an environment that doesn’t give you every possibility in the world we’ve created a bounding box where creativity and problem solving can thrive.
Specialized Hardware
Bro doesn’t natively support any specialized hardware. Typically, when Bro users have something like a specialized NIC (network card) they take advantage of it through libpcap wrappers that hide the NIC complexity behind an API that Bro does natively support. This tends to work fine, but it doesn’t provide the ability to take advantage of the full specialized capabilities that the NIC provides. At Corelight, we viewed this as our chance to work with a vendor to really push the state of the art in terms of integration. We formed a great partnership with Accolade Technology where we’ve pushed each other to develop ideas for offloading processing and creatively using their NICs in previously unexpected ways.
Our customers benefit from the tight integration with the specialized NIC hardware in two ways. First, there are performance benefits due to our use of specialized capabilities on the card such as high performance injection of packets into system memory. Secondly, our customers get to experience the benefit of this non-commodity NIC without having to spend the time understanding it and integrating it into their own deployment.
Conclusion
Bro’s flexibility has given us the ability to create a network monitoring appliance that is truly ready to use “out of the box” but continues to have a number of doors that can be opened for further exploration and modification. As we move into the future and continue developing Bro and the Corelight Sensor, we will continue our deliberative approach to providing production-ready features with the full programmability of Bro.
