Corelight Blog

By Richard Bejtlich, Principal Security Strategist, Corelight

I am really fired up to join Corelight. I’ve had to keep my involvement with the team a secret since officially starting on July 20th. Why was I so excited about this company? Let me step backwards to help explain my present situation, and forecast the future.

Twenty years ago this month I joined the Air Force Computer Emergency Response Team (AFCERT) at then-Kelly Air Force Base, located in hot but lovely San Antonio, Texas. I was a brand new captain who thought he knew about computers and hacking based on experiences from my teenage years and more recent information operations and traditional intelligence work within the Air Intelligence Agency. I was desperate to join any part of the then-five-year-old Information Warfare Center (AFIWC) because I sensed it was the most exciting unit on “Security Hill.”

I had misjudged my presumed level of “hacking” knowledge, but I was not mistaken about the exciting life of an AFCERT intrusion detector! I quickly learned the tenets of network security monitoring, enabled by the custom software watching and logging network traffic at every Air Force base. I soon heard there were three organizations that intruders knew to be wary of in the late 1990s: the Fort, i.e. the National Security Agency; the Air Force, thanks to our Automated Security Incident Measurement (ASIM) operation; and the University of California, Berkeley, because of a professor named Vern Paxson and his Bro network security monitoring software.

When I wrote my first book in 2003-2004, The Tao of Network Security Monitoring, I enlisted the help of Christopher Jay Manders to write about Bro 0.8. Bro had the reputation of being very powerful but difficult to stand up. In 2007 I decided to try installing Bro myself, thanks to the introduction of the “brolite” scripts shipped with Bro 1.2.1. That made Bro easier to use, but I didn’t do much analysis with it until I attended the 2009 Bro hands-on workshop. There I met Vern, Robin Sommer, Seth Hall, Christian Kreibich, and other Bro users and developers. I was lost most of the class, saved only by my knowledge of standard Unix command line tools like sed, awk, and grep! I was able to integrate Bro traffic analysis and logs into my TCP/IP Weapons School 2.0 class, and subsequent versions, which I taught mainly to Black Hat students. By the time I wrote my last book, The Practice of Network Security Monitoring, in 2013, I was heavily relying on Bro logs to demonstrate many sorts of network activity, thanks to the high-fidelity nature of Bro data.

In July of this year, Seth Hall emailed to ask if I might be interested in keynoting the upcoming Bro users conference in Washington, D.C., on October 10-12. I was in a bad mood due to being unhappy with the job I had at that time, and I told him I was useless as a keynote speaker. I followed up with another message shortly after, explained my depressed mindset, and asked how he liked working at Corelight. That led to interviews with the Corelight team and a job offer. The opportunity to work with people who really understood the need for network security monitoring, and were writing the world’s most powerful software to generate NSM data, was so appealing! Now that I’m on the team, I can share how I view Corelight’s contribution to the security challenges we face.

For me, Corelight solves the problems I encountered all those years ago when I first looked at Bro. The Corelight embodiment of Bro is ready to go when you deploy it. It’s developed and maintained by the people who write the code. Furthermore, Bro is front and center, not buried behind someone else’s logo. Why buy this amazing capability from another company when you can work with those who actually conceptualize, develop, and publish the code?

It’s also not just Bro, but it’s Bro at ridiculous speeds, ingesting and making sense of complex network traffic. We regularly encounter open source Bro users who spend weeks or months struggling to get their open source deployments to run at the speeds they need, typically in the tens or hundreds of Gbps. Corelight’s offering is optimized at the hardware level to deliver the highest performance, and our team works with customers who want to push Bro to the even greater levels.  

Finally, working at Corelight gives me the chance to take NSM in many exciting new directions. For years we NSM practitioners have worried about challenges to network-centric approaches, such as encryption, cloud environments, and alert fatigue. At Corelight we are working on answers for all of these, beyond the usual approaches — SSL termination, cloud gateways, and SIEM/SOAR solutions. We will have more to say about this in the future, I’m happy to say!

What challenges do you hope Corelight can solve? Leave a comment or let me know via Twitter to @corelight_inc or @taosecurity.

By Vincent Stoffer, Senior Director of Product Management, Corelight

Corelight recently released our 1.15 software update which includes some fantastic new features, including our first group of curated Bro Packages which we’re calling the “Core Collection.”  In this blog post, I’ll tell you a bit more about how Corelight is making it easier to detect threats on your network, and providing even better data to respond to them.

Bro is much more than just a source of network data, it’s also a Turing-complete, domain-specific programming language.  Expert users know that Bro scripts (now often shared as packages) are the way to tune your sensors to generate alerts, customize the data output, and to take action.  At Corelight we support running custom Bro Packages on our platform, and some of the technical details of how and why we did that are described in this blog post.

Despite the fact that customers can run their own Bro scripts and packages on our platform, we find that many people still want easier access to content created by Corelight and the broader Bro community.  So in our 1.15 software release we chose 10 of the most popular and interesting Bro Packages (most contributed by members of the Bro community) and pre-loaded them directly onto the Corelight Sensor platform.  We believe making the results of Bro’s powerful scripting language available by default and easy to use means you’ll not only have the best data for forensics, incident response, and threat hunting, but you’ll also have detections and enrichments that make your workflow easier.

Like any Bro packages running on a Corelight sensor, these 10 run in a sandboxed environment to protect the underlying operating system, and we’ve also ensured they don’t significantly impact the performance of the sensor, and we made them as easy to enable as flipping a switch.

We divided these packages into 3 separate functional groups: detection, data enrichment, and operations.  Our intent is to demonstrate how powerful Bro’s scripting capabilities can be across a variety of use cases.  I’ll briefly describe what packages we included in each group and how to use them:

Detection:

bitcoin – Detects Bitcoin, Litecoin, etc. mining traffic over TCP or HTTP and generates an alert.  Useful to track down users exploiting internal system or network resources for profit.

ja3 – A popular package written by the security team at Salesforce, this hashes properties of the SSL/TLS client negotiation to help identify and catalog client software being used over SSL/TLS.  Once you’ve associated a ja3 hash to a piece of software (whether it’s a particular version of a web browser of a piece of malware), it’s easy to match and alert on those hashes using Bro’s intelligence framework.  And because those client negotiation properties don’t change, you can use the ja3 hashes to pinpoint client software regardless of the IP it’s coming from or the external server it’s reaching out to.

http stalling – Detects a web client sending data very slowly (a resource exhaustion attack) against a webserver and generates an alert.

long connections – Because Bro usually only logs connections when they have completed, this package detects long connections that are still running and logs them periodically.  Because malware can use persistent connections, this log is great for identifying ongoing C&C channels and generally keeping your eye on other long-running connections to establish them as valid or malicious.

scan detection – A great example of the ability of Bro to provide behavioral insight, this detects machines that are port scanning (both vertically and horizontally) and generates an alert.  It’s very useful for finding recon and feeding into an orchestration platform for blacklisting.

Data Enrichment:

Hostname enrichment – One of the most common first steps when investigating network traffic is to map an IP address to its corresponding hostname.  This Corelight only feature tracks hostnames observed over DNS by the sensor, and add them as a new column to the conn.log. This speeds the incident response workflow, by providing those hostnames where available, and does so without tipping your hand to potential adversaries with an active DNS lookup.

SMTP URL extraction – For SMTP, this extracts any URLs which are seen in the message body.  Useful for searching for phishing links and doing URL intelligence matching on live email.

http post bodies – Writes an additional field into the http.log that adds the POST body data (size limited).  Watch for credentials, C&C, and more in HTTP traffic.

Operations:

shunting – Corelight’s flagship platform, the AP 3000, can now handle shunting large or long running connections using its integrated NIC – which allows performance to be maintained in extreme conditions, while still preserving connection state information.  For our other platforms, this script also shows what connections would have been shunted, helping to profile traffic meeting certain conditions. A number of options are configurable in the new Web GUI to tune the threshold for shunting.

SSL expiring certs – Highlights any internal x509 certificates which are expired or will be expiring within 30 days.  A great way to double check on the integrity of your secure applications.

As you can see, there is a lot to explore!  We’ve made it easy to enable any of these packages and this is only the first step –– we plan to offer lots more content for the Core Collection and even other collections in the future.

By Robin Sommer, CTO at Corelight and Bro development lead

When we founded Corelight in 2013, one of our goals was to build an organization that could sustain open-source Bro development long term. At that time, the core team behind Bro was still funded primarily through grants from the National Science Foundation. One of the underlying assumptions coming with that funding was that, with our work, Bro would become self-supporting: production-quality open-source software could generate a revenue stream to support its own development. Today, five years later, with many of the people who created and maintained Bro over the last two decades working at Corelight, that vision is becoming reality. Corelight is bridging the gap between the open-source software and enterprise environments looking for professional, supported products—they get the expertise of Bro’s creators packaged into a high-quality solution. In return, the success of Corelight enables us to invest heavily into advancing open-source Bro. You can rest assured that our team remains as committed to Bro as ever—no change there. In that spirit, I want to take the opportunity here to talk about a few of our more recent contributions to open-source Bro.

Getting Broker Ready for Production

One of Corelight’s main focus areas over recent months has been the Broker transition for Bro 2.6. While a series of Broker prototypes have existed for a while, the current Bro 2.5 still relies on a decade-old communication framework not designed for today’s network loads. Corelight’s Jon Siwek worked hard to tie together all the loose ends of this work, getting Broker ready for 2.6. He moved all of Bro’s standard scripts over to using Broker, and, during that process, improved many aspects of Broker’s API, implementation, documentation, and regression testing. Internally, Corelight is performing a series of tests to ensure that Bro & Broker, and hence the community’s Bro clusters, operate as expected.

Improving CAF

Jon also spent significant time on the innards of CAF, an actor framework library providing the low-level foundation for Broker. He tracked down and fixed a number of issues that were critically affecting stability & performance of Bro clusters. As Bro is gearing up for 2.6, CAF will be soon releasing a new stable version that incorporates all these changes, so that the trio of Bro, Broker, and CAF will smoothly work together. For easier installation, we also integrated CAF into Bro’s source code distribution, so that users don’t need to worry about getting a non-standard dependency in place before building Bro.

Supporting Dynamic Reconfiguration

Corelight recently contributed Johanna Amann’s Configuration Framework to Bro, which fills a long-time gap by providing an easy-use-to, unobtrusive infrastructure for changing Bro’s script-level tuning options dynamically at run-time.

Expanding Logging

We’ve made a number of logging improvements: restructuring DHCP logs (based on a community contribution); expanding connection histories that now capture TCP window closures, and also indicate repeats for a number of situations; and adding rate-limitations of “weirds” to address performance issues when your network exhibits a high level of non-conforming protocol usage. For geo-location, Bro now supports MaxMind’s new GeoIP2 databases, replacing their discontinued legacy format. For Bro’s TLS analysis, we reimplemented OCSP support, which was still missing from the recently contributed port of the analyzer to OpenSSL 1.1. We also added support for Cisco’s FabricPath and PPPoE over QinQ.

Improving Bro’s Scripting Language

We have been working on the scripting language as well: regular expressions can now be case-insensitive, and they can be created dynamically at runtime (which meant tracking down several memory leaks that had previously prevented Bro from allowing this). Sets and vectors have gained new operators, there’s support for bitwise operations, and we wrapped up & merged new functionality for type checking and type-safe casting.

Building & Installing Bro

Bro’s build system now knows to install Bro’s header files so that developers can build plugins without needing a copy of a Bro source tree laying around. We also added better support for cross-compiling Bro.

Bro Packages

As part of the broader Bro ecosystem, Corelight continues to maintain the increasingly popular Bro Package Manager.  We have open-sourced a number of new Bro packages as well:

• QUIC analyzer/detector parses and detects Google’s implementation of QUIC.
• Community ID provides a standardized way of labeling traffic flows in network monitors—an approach championed by the Bro and Suricata communities to enable correlation of flows across tools.
• HTTP Stalling Detector finds stalling DoS attacks taking advantage of web servers’ inability to differentiate legitimate client connecting over slow links from attackers deliberately sending data slowly to cause extra work.
• JSON Streaming Logs lets Bro write out JSON logs with additional attributes making life easier for external log shippers such as filebeats, logstash, and splunk_forwarder.

BroCon 2018 & Project Leadership

Speaking of community work, the Bro Leadership Team asked Corelight to host BroCon 2018, a task which our Events team has been happy to take on. As Bro’s NSF funding winds down, it is becoming quite challenging for the open-source project to organize large events on its own. Corelight employees are also active members of the Bro Leadership Team. In that role, Corelight staff have focused particularly on finding a new name for the project (still ongoing); moving the project back from Software Freedom Conservancy to ICSI; and being a liaison between the open-source project and the BroCon event team, providing history and context.

And all the little things that make Bro great

While not especially visible, Corelight has probably spent the greatest portion of its time on all the routine maintenance work that—while often hard to notice—is critical for any popular open-source project: fixing bugs & security issues; shepherding and merging community contributions; improving documentation & regression testing; and, crucially, providing users & developers with answers to questions. You can track much of this work on Bro’s public channels, such as mailing lists, the issue tracker, and Git repositories. Some work has to remain behind the scenes, however, such as discussion of security issues as well as interactions involving specifics of peoples’ environments.

We have never been more excited about the project, and are continually gratified and amazed at the way it has grown. Bro has always been popular among its fans, and we strongly believe that as it gets more usable and capable, deployment of Bro will continue to accelerate and really become a fundamental part of the modern security stack.

By Alan Saldich, CMO, Corelight and Brian Dirking, Sr. Director Partner Marketing, Databricks

Incident response, threat hunting and cybersecurity in general relies on great data. Just like the rest of the world where virtually everything these days is data-driven, from self-driving cars to personalized medicine, effective security strategies also need to be data-driven.

Whatever security solution, service or business process you implement, it probably relies on data from just four sources: logs, networks, hosts and third party intelligence feeds. Some or all of that data is fed into an analytics stack like Apache Spark™ where advanced analytics, artificial intelligence, machine learning and other techniques can be applied.

When it comes to the data about network traffic though, most organizations are stuck between “not enough data” and “way too much.” The former is normally NetFlow data that provides basic information about network traffic, source / destination IPs, time and date, bytes sent / received and few other important (but sparse) pieces of information. The latter is typically PCAP (packet capture) where every bit on the wire is stored. Since big networks carry a tremendous amount of data, storing it all is non-trivial and can become expensive and cumbersome.

The Alternative

So what’s the alternative? Well for over 20 years, an open source project called Bro has been used in production at some of the world’s largest organizations and biggest networks, namely government agencies, research universities and very large / web-scale companies.

Bro is a network monitoring framework that ingests a copy of all traffic on a network, parses and analyzes it in real time using its event processing engines and scripts, and then outputs data (“Bro logs”) to some external analytics system like Spark. There are dozens of Bro logs for most common protocols like SMTP, SSL, SMB, DHCP, DNS and many others. Each Bro log contains 10 to 40 fields describing that part of the network traffic.

Furthermore, Bro logs include key pivot points in the data that allow incident responders to follow their instincts or observations by taking advantage of unique identifiers for critical aspects of network traffic: all connections (Connection UID) and files (FUID) are uniquely identified. Along with consistent and precise timestamps across all logs, Bro gives incident responders access to everything they’ll need to resolve most security incidents quickly without having to resort to PCAP except in rare instances.

Corelight was founded by the creators of Bro to deliver network security solutions built on this powerful and widely used framework. Since Corelight does not provide an analytics application, we are excited to work with leading companies like Databricks to combine the power of Bro data with the intelligence of Apache Spark and all of its analytic capability.

The challenge of managing threats in a big data world

Staying abreast of the latest threat isn’t the only challenge. The increasing volume and complexity of threats require security teams to capture and mine mountains of data in order to avoid a breach. Yet, the Security Information and Event Management (SIEM) and threat detection tools they’ve come to rely on were not built with big data in mind resulting in a number of challenges:

• Inability to scale cost efficiently
  Companies deploy logging and monitoring devices across their networks, end-user devices and production machines to help detect suspicious behavior. These tools produce petabytes of log data that need to be contextualized and analyzed in real-time. Processing petabytes of data takes significant computing power. Unfortunately, most SIEM tools were built for on-premises environments requiring significant build-outs to meet processing demands. Additionally, most SIEM tools charge customers per GB of data ingested. This makes scaling threat detection tools for large volumes of data incredibly cost-prohibitive.
• Inability to conduct historic reviews in real-time
  Identifying a cybersecurity breach as soon as it happens is critical to minimizing data theft, damages, and creation of backlogs. As soon as an event occurs, security analysts need to conduct deep historic analyses to fully investigate the validity and breadth of an attack. Without a means to efficiently scale existing tools most security teams only have access to a few weeks of historical data. This limits the ability of security teams to identify attacks over long time horizons or conduct forensic reviews in real-time.
• Abundance of false positives
  Another common challenge is the high volume of false positives produced by SIEM tools. The massive amounts of data captured in OS logs, cloud infrastructure logs, intrusion detection systems and other monitoring devices produce events that in isolation or in connection with other events may signify a compromised network. Most events need further investigation to determine if the threat is legitimate. Relying on individuals to review hundreds of alerts including a large number of false positives results in alert fatigue. Eventually, overwhelmed security teams disregard or overlook events that are in actuality legitimate threats.

In order to effectively detect and remediate threats in today’s environment, security teams need to find a better way to process and correlate massive amounts of real-time and historical data, detect patterns that exist outside pre-defined rules and reduce the number of false positives.

Enhancing threat detection with scalable analytics and AI

Databricks offers security teams a new set of tools to combat the growing challenges of big data and sophisticated threats. Where existing tools fall short, the Databricks Unified Analytics Platform fills the void with a platform for data scientists and cybersecurity analysts to easily build, scale, and deploy real-time analytics and machine learning models in minutes, leading to better detection and remediation.

Databricks complements existing threat detection efforts with the following capabilities:

• Full enterprise visibility
  Native to the cloud and built on Apache Spark by the original creators of Apache Spark, Databricks is optimized to process large volumes of streaming and historical data for real-time threat analysis and review. Security teams can query petabytes of historical data stretching months or years into the past, making it possible to profile long-term threats and conduct deep forensic reviews to uncover backdoors left behind by hackers. Security teams can also integrate all types of enterprise data – SIEM logs, cloud logs, system security logs, threat feeds, etc – for a more complete view of the threat environment.
• Proactive threat analytics
  Databricks enables security teams to build predictive threat intelligence with a powerful, easy-to-use platform for developing AI and machine learning models. Data scientists can build machine learning models that better score alerts from SIEM tools reducing reviewer fatigue caused by too many false positives. Data scientists can also use Databricks to build machine learning models that detect anomalous behaviors that exist outside pre-defined rules and known threat patterns.
• Collaborative investigations
  Interactive notebooks and dashboards enable data scientists, analysts and security teams to collaborate in real-time. Multiple users can run queries, share visualizations and make comments within the same workspace to keep investigations moving forward without interruption.
• Cost efficient scale
  The Databricks platform is fully managed in the cloud with cost-efficient pricing designed for big data processing. Security teams don’t need to absorb the costly burden of building and maintaining a homegrown cybersecurity analytics platform or paying per GB of data ingested and retained.

How a Fortune 100 company uses Databricks and advanced cybersecurity analytics to combat threats

A leading technology company employs a large cybersecurity operations center to monitor, analyze and investigate trillions of threat signals each day. Data flows in from a diverse set of sources including intrusion detection systems, network infrastructure and server logs, application logs and more, totaling petabytes in size.

When a suspicious event is identified, threat response teams need to run queries in real-time against large historical datasets to verify the extent and validity of a potential breach. To keep pace with the threat environment the team needed a solution capable of:

• Large data volumes at low latency: Analyze billions of records within seconds
• Correct and consistent data: Partial and failed writes cannot show up in user queries
• Fast, flexible queries on current and historical data: Security analysts need to explore petabytes of data with multiple languages (e.g. Python, SQL)

As an example of how customers are using advanced cybersecurity analytics, check out this recent video from Apple.

For another more general explanation of how Corelight and Databricks can be deployed together, Databricks produced this video that includes an explanation of how they ingest Bro logs as part of their security solution.

The Challenge

It took a team of twenty engineers over six months to build their legacy architecture that consisted of various data lakes, data warehouses, and ETL tools to try to meet these requirements. Even then, the team was only able to store two weeks of data in its data warehouses due to cost, limiting its ability to look backward in time. Furthermore, the data warehouses chosen were not able to run machine learning.

The Solution

Using the Databricks Unified Analytics platform the company was able to put their new architecture into production in just two weeks with a team of five engineers.

Their new architecture is simple and performant. End-to-end latency is low (seconds to minutes) and the threat response team saw up to 100x query speed improvements over open source Apache Spark on Parquet. Moreover, using Databricks, the team is now able to run interactive queries on all its historical data — not just two weeks worth — making it possible to better detect threats over longer time horizons and conduct deep forensic reviews. They also gain the ability to leverage Apache Spark for machine learning and advanced analytics.

Final Thoughts

As cybercriminals continue to evolve their techniques, so do cybersecurity teams need to evolve how they detect and prevent threats. Comprehensive network traffic extracted by Bro is the highest quality data available to incident responders and threat hunters, and an essential ingredient to the Databricks analytics platform for cybersecurity. Big data analytics and AI offer a new hope for organizations looking to improve their security posture, but choosing the right platform is critical to success.

Download our Cybersecurity Analytics Solution Brief or watch the replay of our recent webinar “Enhancing Threat Detection with Big Data and AI” to learn how Databricks can enhance your security posture, including ingestion of Bro logs for network traffic monitoring.

If you’re not familiar at all with Bro, watch Corelight’s two-minute video here.

By Howard Samuels, Director of Sales Engineering at Corelight

Bro provides enriched network visibility for top organizations around the world, and there are many use cases for Bro logs.   The security field uses Bro data for incident response and cyber threat hunting. But Bro log use cases don’t always have to involve finding bad actors, identifying breaches or attack blueprints.  The clean, structured, and enriched data from Bro can also be used to simply provide necessary protocol information not otherwise easily obtained from servers.

In this example, we show how a company can obtain DNS visibility and extend the lifespan of a large production deployment of DNS servers via a few Corelight sensors that generate Bro DNS logs. This use case features a utility company with over 50 DNS servers worldwide.  A federal governing body told them that there were DNS lookups going to known cyber threat sites originating from their network and therefore they weren’t sufficiently self-governing their DNS activity. Given the importance and focus on safeguarding utility companies from cyber attacks, getting in front of this DNS issue was of paramount importance.  

The company had limited DNS network visibility because their DNS servers could not effectively log activity.   The DNS logging service on their servers didn’t give enough functional information – and therefore visibility – to identify these malicious communications.  Moreover, the data their DNS servers did provide was a flat file with too much noise and the logging mechanism also had a negative impact on the DNS servers’ overall performance.    

They considered upgrading all their DNS servers, but given the cost they discarded this option.  They determined that a more comprehensive, faster, and cost-effective solution was to deploy Corelight sensors in their main data centers to obtain enriched Bro DNS logs.  With Corelight and Bro they could easily capture both DNS requests and answers to queries and quickly stream them to a SIEM. The benefit was immediately clear when an analyst who had previously tried to identify non-authoritative DNS lookup records was able to easily achieve this with the logs provided by Corelight sensors.

The utility company used packet broker to distribute raw traffic to the Corelight sensors which then do the heavy lifting of extracting the DNS information into a log or data stream for export to their SIEM.  The solution architecture is simply network taps sending traffic into a packet broker. Behind the broker is a Corelight sensor. The packet broker filters are configured to send only DNS traffic to the Corelight Sensor.  The enriched logs are spooled from the Corelight sensor to a datastore and ultimately consumed in a SIEM. Problem solved, customer happy, money saved and the technology team are now heroes. Their security team is now looking at network logs and will look at expanding their use to the SOC.  

Thinking more broadly beyond DNS, consider other crucial network services and the struggle to keep accurate time stamped logs and your ability to get enriched data from these services?  What if network service logging for DHCP, Kerberos, or Radius is set to OFF, FATAL, WARN or ERROR – i.e. not nearly enough data? Or, ALL, DEBUG or TRACE – too much noise? What if INFO misses the data you need?  What if there is only one logging service level and therefore not configurable? Bro provides better network data that can spare operational cycles and extend the life of network services, thereby saving money and just as importantly reducing operational headaches.

By James Schweitzer, Federal Solution Engineer at Corelight

If you’re reading this blog, you probably know that Bro can uncover indicators of compromise and discover adversary lateral movement by monitoring east-west traffic within the enterprise. But you may not know about one of the best sources of data for this purpose, the Bro server message block (SMB) logs.  Bro’s SMB protocol analyzer has undergone several iterations, and it is now a built-in feature that many Bro users might have overlooked. If you are running Bro 2.5, all that is needed is to manually load the SMB policy.

SMB is used for many purposes. Most users of Windows networks rely on SMB every day when accessing files on network drives, and network administrators use the same protocol when they perform remote administration. Unfortunately the adversary, whether script kiddies or nation-state actors, also uses SMB! By the way, do you know whether SMBv1 is running on your network… and how can you be sure?

The video that accompanies this blog provides an introduction to the power of Corelight’s advanced filtering and the content contained in Bro’s SMB logs to monitor SMB usage for remote scheduled tasks and file access. If you use Bro to monitor SMB, please share tips here so others can benefit – if you don’t use Bro, would you like to learn how it transforms raw network traffic into comprehensive, organized logs? If you are interested in learning more detail about Bro’s ability to detect malicious activity hidden in SMB, this SANS paper is a great place to start.

I hope you enjoy this short introductory video. Good luck and good hunting!

By Seth Hall, Co-Founder & Chief Evangelist at Corelight

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.

We’re proud to announce the Corelight for Splunk app is available!  Using the new app (and its associated Technology Add-on (TA)), you can now monitor the health and performance of Corelight Sensors in Splunk and explore the rich data Bro provides through a series of dashboards.

The Corelight for Splunk App, associated TA, and Q&A page are all on Splunkbase now.

If you’re using open-source Bro and you want to use Corelight’s app, you need to send your Bro logs to Splunk in a streaming format using JSON. To do so, install the json-streaming-logs Bro package using the Bro Package Manager, also directly available via GitHub.

In the next few months, we’ll be publishing more information about the app, including an FAQ and a longer blog post dedicated to highlighting its functionality and benefits.  

In the meantime, let us know if you have any questions or concerns installing or using the new app: appsupport@corelight.com.

The Corelight Team

By Brian Dye, Chief Product Officer at Corelight

I’ve enjoyed meeting many companies and leaders in the Bay Area over the past few months. The best surprise I had in doing so was with Corelight (where I recently joined as their chief product officer). Despite many years in security, when they proudly proclaimed “we’re bringing an easier, faster, commercially supported version of Bro to the market” I had to respond with a less than glorious “OK … but what is Bro?”

To find out, the first people I talked to were top incident responders … the ones with battle scars, the SANS trainers, the folks you call when “it” hits the fan. This was my first surprise:  The immediate answer was “of course I know Bro. I use it all the time, even to teach SANS security incident investigations classes.” It turns out, Bro creates a uniquely useful set of insights out of network data; insights that are far richer than NetFlow but far more concise and searchable than a full PCAP. Bro is the “Goldilocks” insight level for security investigations.

Next, I talked to CISOs I especially respected. They knew about Bro too, for how valuable the data was and for what it helped their teams do. These CISOs knew that Bro was taking off as part of the industry focus on improving SOC effectiveness and better arming their investigators. What they didn’t like was that open source Bro was a complex “roll your own” solution and deploying it required expert-level UNIX people, so getting access to the valuable data Bro provides meant taking their (scarce!) talent and putting them on infrastructure management. Those same people were often the very incident responders and threat hunters who should be focusing on defending networks, not installing technology. That is where Corelight comes in: the Corelight Sensor radically simplifies the deployment and operation experience, resulting in a lower hardware and operational cost. The number and caliber of customers signing on with Corelight as we speak is proof positive of that value.

After all that, there was a lingering question in my mind… if Bro is so awesome, why isn’t everyone using it? (While Bro is well known by some, its adoption by enterprises has lagged behind government agencies, universities and web-scale companies). The answer is actually pretty simple: Bro’s capabilities, while critical for 20 years at national labs, intelligence agencies and other organizations with existential threats from determined adversaries, were not needed by typical enterprises in the 1990s and even 2000s. Bro was created before the cloud, mobile, SAAS and high bandwidth links were in common use by “normal” companies. And most companies didn’t have SOCs or the level of security + technical expertise to get Bro working. Obviously, all that has changed — the problems faced by enterprises have grown into the long-extant capabilities of Bro.

My last question was “where can we go from here?” One of the clearest long-term trends in cyber is that better data enables better security. As a result, at Corelight there is a wide range of opportunities to both give organizations new insights and solve existing problems in far better ways. One example, driven by a mindset shift: many organizations wrestle to make their data analysis and investigation as seamless and effective as possible … but they treat the incoming data as immutable.  Corelight proves that it isn’t, and by improving both the quality and structure of that data the entire investigation stack gets better – and we can continue enriching the quality of that data. It reminds me of the old BASF ads … “we don’t make the things you buy, we make the things you buy better.”

This, of course, is just the beginning. I’m excited to join the Corelight team, and can’t wait to show you what we can do for you. Better security starts with better data.

By Johanna Amann, Senior Engineer at Corelight

If you are familiar with Bro scripts you have probably encountered redefs, which allow you to change a number of Bro settings. One commonly used redef is Site::local_nets, which lists the networks that Bro considers local.

As the name redef implies, redefs allow the re-definition of already defined constants in Bro. This is often done in local.bro (but can be done in any loaded script-file). To modify Site::local_net, you can use code similar to this:

redef Site::local_nets = +={10.1.0.0/16};

A disadvantage of redefs is that these redefinitions can only be performed when Bro first starts. Afterwards, Site::local_nets is just a normal constant and can no longer be modified.

However, it is clearly desirable to be able to change many of the configuration options that Bro offers at runtime. Having to restart Bro causes Bro to lose all connection state and knowledge that it accumulated. To solve this problem, Corelight has created the Bro configuration framework, which allows changing configuration options at runtime. We designed the configuration framework in a way that is easy to use and unobtrusive, while also giving great power and flexibility when needed. Using the configuration framework in your script only requires minimal changes. To declare a configuration option, you just prefix it with the newly introduced option keyword:

module OurModule;

export {
    option known_networks: set[subnet] = {};
    option enable_feature: bool = F;
    option system_name: string = "testsystem";
}

Options lie in between variables and constants. Like constants, options cannot be assigned to at runtime; trying to manipulate an option will result in an error. However, there are special calls that can be used to modify options at runtime; these are also used internally by the scripts that power the configuration framework; we discuss this further below.

Given those three options defined above, we just need to tell Bro where to find the configuration file. Simply add something akin to this to local.bro:

redef Config::config_files += { "/path/to/config.dat" };

config.dat contains a mapping between the option names and their values:

OurModule::known_networks 10.0.12.0/24,192.168.17.0/24
OurModule::enable_feature  T
OurModule::system_name  prod-1

Now the options are updated automatically each time that config.dat is changed. Additionally, a new log file, config.log contains information about the configuration changes that occurred during runtime.

Behind the scenes, the config framework uses the Bro input framework with a new custom reader. Users familiar with the Bro input framework might be aware that the input framework is usually very strict about the syntax that it requires. This is not true for configuration files: the files need no header lines and either tabs or spaces are accepted as separators.

For more advanced use-cases, it is possible to be notified each time an option changes:

function system_change_handler(ID: string, new_value: string): string
    {
    print fmt("Value changed from system_name to %s", new_value);
    return new_value;
    }
    
event bro_init()
    {
    Option::set_change_handler("OurModule::system_name", system_change_handler);
    }

This code registers a change handler for the OurModule::system_name option. Each time that the option value is changed, the system_change_handler function will be called before the change is performed. As you might already have deduced from the function signature, the change handler also can change the value before it is finally assigned to the option. This allows, for example, checking of parameters values to reject invalid input. It is also possible to chain together multiple change handlers: Option::set_change_handler takes an optional third argument that can specify a priority for the handlers.

Note that change handlers are also extensively used internally by the configuration framework. If you look at the script level source code of the config framework, you can see that change handlers are used for logging the option changes to config.log.

If you inspect the scripts further, you will also notice that the script-level config framework simply catches events from the Input framework and then calls Option::set to set an option to the new value. If you want to change an option yourself during runtime, you can call Option::set directly from a script.

The following figure shows the data flow and the different components that make up the entirety of the config framework:

You can try the configuration framework today! It has been merged into Bro and will be part of Bro 2.6. To try it, either install Bro from source or install one of the nightly builds.