Monday, December 5, 2016

The Intelligence Framework Update

Note: This is a guest blog post by Jan Grashöfer, the original post may be found here

Recently Bro's intelligence framework was refactored and extended with a couple of new features. This post will discuss the updates and tries to clear some of the backgrounds that turned out to be common pitfalls in the past.

The Intelligence Framework Data Model


Understanding the intel framework's data model is the key for exploiting its full potential, so let's have a closer look: The core of an intelligence datum is the indicator (also indicator of compromise, IoC), e.g. an IP, hash or domain name (for a list of available types see Bro's script reference). The indicator can be enriched by meta data of different kinds, e.g. a description, url or severity level. The same indicator can be obtained from different intelligence sources, providing different meta data. Thus in Bro's intelligence framework, a plain indicator can be described by multiple meta data records. A meta data record is uniquely identified by its source. Figure 1 illustrates the described relation.















Figure 1: Data Model of Bro's Intelligence Framework

Keeping this in mind now let's have a look at the intel files. Each line represents what is called an intelligence item (Intel::Item). An intelligence item consists of the indicator, the indicator's type and a meta data record (fields prefixed by meta.), including the meta data source. In terms of the data model this is equal to the internal representation with n=1. So what about the relations? The second thing to keep in mind regarding the intelligence framework's data model is the fact that intelligence files are only the supply mechanism to feed intelligence data into Bro. The "database" Bro uses for matching is kept in memory following the described model. So how do they interact? Bro uses the input framework to read intelligence files. Each line triggers a corresponding insert into the in-memory data structure. Imagine the same indicator was obtained from two different sources, each supplying different meta data. Thus the same indicator occurs multiple times (in a single file or in different files). Ingesting the files, Bro will store the indicator only once, associate both meta data records to it but will not duplicate it (see Figure 2).

#field indicator indicator_type meta.source meta.desc meta.url
bro.org Intel::DOMAIN test-source1 domain for testing http://source1.com/id-x
bro.org Intel::DOMAIN test-source2 domain for testing http://source2.com/id-y












Figure 2: Internal representation of the example items

In case a file is changed (Note: Changes have to be atomic e.g. using mv), Bro will reread the whole file and update the in-memory data structure. Changing some meta data values will cause a corresponding update but changing the meta data source, Bro will assume the indicator was obtained again from a new source, causing Bro to add another meta data record and assign it to the given indicator. Likewise Bro will add a new intelligence datum if the indicator or indicator type was changed, while keeping the original item in the in-memory data structure. Accordingly deleting a line from an intel file will not delete the corresponding intelligence item from Bro's database (see the next section on how to get rid of inserted intelligence data). This means in particular that the intelligence files on disk do not necessarily reflect the actual database Bro uses for matching.

Now that we have the intelligence indicators at hand, let's have a quick look how matching works. In theory, every piece of data, that is made available by Bro's events, can be used for matching. Once there is something that should be checked against the database of indicators, the datum is wrapped inside a Intel::Seen record and sent to the intel framework. The record contains the seen indicator, its type and additional information, e.g. where the indicator was seen. Bro comes with a set of policy scripts located in intel/seen/ that report indicators by evaluating well-known events. For example connection_established provides IP addresses or dns_request is used to extract domains. Figure 3 illustrates the data flow.















Figure 3: Data Flow of Bro's Intelligence Framework

Finally there is one detail left, which might be not that intuitive. When it comes to interacting with the intelligence framework, most of the functions, hooks and events use Intel::Item to pass information about indicators. In case an indicator is associated with more than one meta data records, it will be unrolled into a set of multiple items. For example the Intel::match event's items will contain an Intel::Item record for every meta data record that is associated with the matched indicator. So we have been talking about a yet simple but still relational data model and every time it is accessed it gets denormalized. Doesn't seem very smart, right? The reason behind is that the import (intel files) as well as the output (Bro's logfiles) is based on CSV-like plain text files (although writing JSON is possible, nested structures are not supported). All in all the intelligence framework's design realizes an easy to use interface while providing as much flexibility as possible. Theory done. Time for some new features.

Removing Intelligence Items


Prior to the refactoring, the only way to get rid of an intelligence item was to whitelist it using Seth Hall's intel-extensions (we will come back to that). The only way to purge an item from the in-memory datastructure was to restart Bro. In case of long running live systems or frequently changing intelligence data that was a major handicap. In context of the framework update a new function has been added: remove: remove: function(item: Item, purge_indicator: bool &default = F); The Intel::Item type represents a single line of an intelligence file and thus just contains a single meta data record. But keeping in mind the data model there might be multiple meta data records associated to an indicator. In this case, only the meta data record matching the given meta data will be deleted. As meta data records are identified by source, it would be sufficient to specify only the source name inside the item that is passed to the function. In case there is no meta data left, the whole indicator is removed. If purge_indicator is set, the given metadata is ignored and the indicator is removed including all possible instances of meta data associated.

In principal the new remove function allows any script to delete an intel item. Imagine you have accidentally added your webserver's IP and alerts start flooding. Now a small tool would be great to remove that IP from your Bro instance without shutting down Bro. These extensions contain a small python script (utils/delete_intel.py) that connects to Bro using broker and triggers item removal. The corresponding Bro script (scripts/remote_delete.bro) sets up broker and handles incoming deletion requests (Note: As broker is under development, there is a high probability that the scripts do not work with current master as of reading these lines):

event Intel::remote_remove(indicator: string, indicator_type: string)
    {
    local item: Item = [
        $indicator = indicator,
        $indicator_type = type_tbl[indicator_type],
        $meta = record($source = "")
    ];
    remove(item, T);
    }
The only thing that's done here is the composition of an Intel::Item record using the values sent by the python script to call the remove function (type_tbl is a string-indexed table to map a string to the corresponding Intel::Type). Instead of this broker-based solution, one could also write a script, analog to the intelligence import, that reads files containing indicators to delete. While these possibilities are already quite useful, the following new feature provides another excellent use case. So let's continue.

Intelligence Expiration


Intelligence expiration is the new feature I like most. Imagine we are ingesting a large intelligence feed of probably bad IPs into Bro. On the first day there is a hit, that indicates some malware is calling home. On the second day there is nothing. But on the third day the owner of the IP changed (think of agile cloud environments) and the system behind now offers a legitimate service. As users start to use that service, false positives pop up. The bottom line is that most intelligence data has a natural half life (e.g. hashes might be an exception here). So let's put an expiration date on it.

Bro's intelligence framework now allows to configure the Intel::item_expiration interval. Once an indicator expires, the intel framework executes the item_expired hook passing the indicator, its type and the associated meta data as arguments. The hook can be used to handle expiration. By default the intel framework won't do anything except executing the hook, so we are free to use that mechanism for whatever we like. But in case the hook chain is broken (see Bro's script reference for details about hooks), the expired indicator will be removed automatically. Coming back to the IP feed example, all we need to do is configuring the expiration interval and break the hook chain to remove expired indicators. As this is somewhat the default case, Bro ships with a new policy script do_expire.bro:

##! This script enables expiration for intelligence items.

@load base/frameworks/intel

module Intel;

redef Intel::item_expiration = 10min;

hook item_expired(indicator: string, indicator_type: Type,
    metas: set[MetaData]) &priority=-10
    {
    # Trigger removal of the expired item.
    break;
    }
So all that is left to do for us is loading that script and adapt the expiration interval according to our needs:

@load intel/do_expire
redef Intel::item_expiration = 2days;
Neat, isn't it? Something to keep in mind is, that expiration time runs as soon as an item is inserted into Bro. In case the item is "reinserted", the expiration timer is reset. Note: Whenever an intelligence file changes, all items listed in the file are reinserted! Technically this allows to keep the intel files and the intel database inside Bro in sync. For example one could define an expiration interval of 1 hour plus 30 minutes buffer. Now scheduling an update of the intel files every hour would cause an expiration timer reset of all indicators corresponding to items contained in the files, while indicators of items that have been removed from the files will expire in the given time frame.

Extending the Intelligence Framework


The next feature that is worth to discuss is the new extension mechanism. To be precise this feature is not completely new as it is based on the intel extensions created by Seth Hall (see https://github.com/sethhall/intel-ext). The idea is to allow reacting to an intelligence match. As it turned out to be very useful this was integrated into the intelligence framework. Now it is possible to influence the framework's matching behavior via the extend_match hook. The hook receives the info record to log, the seen record that was observed and a set of items that have been matched (remember, the set of items is the unrolled internal representation). A hook may change these values and thus can influence what is logged. Additionally breaking the hook chain will prevent the intelligence framework from logging the match at all. A good example how to use the new mechanism would be whitelisting indicators. That means indicators are kept in memory for matching but logging of matches gets prevented. Bro already ships with a policy script (whitelist.bro, see Bro repository) that implements whitelisting. But as this was already part of Seth's intel extensions, let's discuss another thing that can be achieved using the new extension mechanism.

A desirable functionality would be to allow enriching item's meta data with some extra information, aggregate this information in case of a match and extend the intel log accordingly. For example one could add identifiers for the local Security Information and Event Management system (SIEM). The following script does the job:

module Intel;

export {
    redef record MetaData += {
        ## My SIEM identifier.
        siem_id: string &optional;
    };

    redef record Info += {
        ## Set of SIEM IDs involved.
        siem_ids: set[string] &optional &log;
    };
}

hook extend_match(info: Info, s: Seen, items: set[Item])
    {
    info$siem_ids = set();
    for ( item in items )
        {
        if ( item$meta?$siem_id )
            add info$siem_ids[item$meta$siem_id];
        }
    }
At first the Intel::MetaData record is extended with a SIEM identifier. Then the Intel::Info record is extended to allow logging a set of SIEM identifiers (keep in mind that a single indicator could have been obtained from multiple sources resulting into multiple meta data records associated). Note that the fields added to the info record have to be optional or defined with a default value as the record gets created by the intel framework, which does not know about the field. Finally the hook implements the aggregation logic. It initializes the set, loops the matched items and adds the SIEM identifier, if present, to the set. That's it.

Using this feature, the intelligence framework can be extended in multiple ways. Let me just give one last example. Let's assume we have a feed that publishes domains generated by Domain Generation Algorithms (DGA). These domains are only valid for a certain time window. However, the time window might differ for each of the DGAs. Just ingesting the feed would blow memory and performance sooner or later. So what to do? We could combine the expiration feature and the extension feature and implement per item expiration. The do_item_expire.bro script implements per item expiration by allowing to define individual expiration timeouts using the new meta data value expire.

The small things


Last but not least there are some minor improvements to the intelligence framework. Minor in terms of visible effect, which is definitely just the tip of the iceberg! We don't need to dive into the details. Let's just keep it with the good news: The intelligence framework supports subnets. The new type Intel::SUBNET can be used to ingest subnets in CIDR notation. The subnets are matched against seen addresses. Thus a hit on a single IP could be triggered by an intelligence item describing the exact address or a subnet containing the address or both. To distinguish these cases the new field matched was added to the intel log. As the name might suggest, matched is a set of intelligence types that triggered the hit. Furthermore subnets might overlap. Assume Bro's intelligence database contains 192.168.23.0/26 and 192.168.0.0/16. In this case seeing 192.168.23.42 would as well trigger a single hit, caused by multiple indicators. At this point it could be useful to recall the data model again. A single Intel::Seen record that is reported can trigger multiple indicators. Each indicator can have multiple meta data records attached, as the same indicator can be obtained from different sources. So in case of addresses there are two levels of indirection.

Another couple of small changes hides inside the do_notice.bro policy script. Notice emails are extended to contain the service(s) inferred for the connection that triggered the hit as well as the intel source of the matched indicator. Additionally an identifier is added. Having an identifier allows notice suppression in the notice framework. To suppress intel notices for 12 hours we just need a simple redef:

redef Notice::type_suppression_intervals += {
    [Intel::Notice] = 12hr,
};
The notice identifier is composed of indicator, originator's and responder's IP without considering the direction of the flow. Thus all connections between two IPs regarding the given indicator will ignored for the defined suppression interval. Note that only the corresponding notices are suppressed. The intel log will still contain all hits.

Summary


This blog post discussed the data model of Bro's intelligence framework and the new remove function. Furthermore the intelligence expiration and match extension mechanisms have been explained. Finally the new type for subnets and the changes to the do_notice.bro script have been reviewed. I hope this post could shed some light on the ideas behind Bro's intelligence framework. Have fun integrating the framework into your Bro deployment!

Tuesday, November 29, 2016

Donate to The Bro Project



Bro Community,

As 2016 comes to a close, please consider adding The Bro Project to your list of charitable donations. We are managed by Software Freedom Conservancy, which is a 501(c)(3) organization and therefore exempt from US taxes.

To donate via credit card, click on the "Donate" button below, or go our site for more payment options:



If your commercial organization is considering sponsoring the Bro Project, you can find more information about it on our sponsorship page.

Thank you. And have a happy new year.

The Bro Project

Monday, November 28, 2016

New additions to the Bro Leadership Team

Last year when we announced The Bro Project had joined Software Freedom Conservancy we also announced the formation of Bro Leadership Team. The team consists of key contributors and community representatives working with SFC to set the direction of the project.

The Team has recently added two more members to the group: Johanna Amann and Martin van Hensbergen. As you may know, Johanna is a Bro developer and works on ICSI SSL Notary Service. Martin is a Threat and Malware analyst and the creator of the Bro (RFB)VNC parser.

Welcome Johanna and Martin, thank you for your contributions to the Bro Project!

The complete Leadership Team is now:
  • Johanna Amann, International Computer Science Institute 
  • Seth Hall, International Computer Science Institute
  • Keith Lehigh, Indiana University 
  • Vern Paxson, University of California at Berkeley
  • Michal Purzynski, Mozilla Foundation
  • Aashish Sharma, Lawrence Berkeley Lab 
  • Adam Slagell, National Center for Supercomputing Applications 
  • Robin Sommer, International Computer Science Institute
  • Martin van Hensbergen, Fox-IT

Monday, November 21, 2016

Bro4Pros 2017: February 2nd in San Francisco

Mark your calendars! Bro4Pros 2017 will be on Thursday, February 2nd in San Francisco, CA at Salesforce's Spear St. office (map).

Bro4Pros is a one-day workshop for advanced Bro users (i.e., those who use Bro on a daily basis, feel comfortable customizing its configuration, and have written scripts on their own).

This is a joined community effort and get-together, and the program will depend to a large degree on what people want to talk about. Attendance is limited to ensure an interactive and productive atmosphere.

We scheduled this year's workshop immediately after the Usenix Enigma conference to make travel a little more convenient for out-of-towners.

Registration is free and will open at 11am PST on Thursday, December 1st. Seats are limited and are first-come, first serve. If you have to cancel your registration please contact us to release your seat.

Call for presentations:

We have a few spots available for community presentations.

Send abstracts (max 500 words) to: info@bro.org
Subject: Bro4Pros 2017 Call for Presentations
Submission due date: January 6th, 2017

More details about the event can be found on our event page.

Thank you to Salesforce for sponsoring this event.

Thursday, November 17, 2016

Bro 2.5 released

We are very happy to announce the release of Bro v2.5. The new version is now available for download! Here is a brief summary of some of the new features and improvements:
  • Bro now includes the NetControl framework. This framework allows easy interaction with hard- and software switches, firewalls, etc. 
  • Support for the SMB protocol (SMB1 and SMB2), including GSSAPI and NTLM.
  • Support for the remote framebuffer protocol (RFB), that is used by VNC servers for remote graphical display.
  • The Intelligence framework was refactored and extended. It now supports, for example subnet indicators and item deletion/expiration.
See NEWS for release notes and CHANGES for the exhaustive commit list. Since the first beta version a series of smaller problems were fixed, in particular with the new SMB analyzer. We also added preliminary support for TLS 1.3. There were no significant changes anymore since the second beta version.

Bro 2.5 is currently available as source code, binary packages will come soon.

Thursday, November 3, 2016

Bro 2.5 Beta2

We are happy to announce that the second beta of Bro v2.5 is available for download. The main changes since the first beta are:
  • Lots of small fixes to the SMB analyzer. (Note that the analyzer is disabled by default)
  • Preliminary TLS 1.3 support.
  • Lots of other small fixes.
For a full list of changes see the CHANGES file. For information on the main features added in Bro v2.5, see our NEWS file and the earlier blog post.

Feedback is encouraged and should be sent to the Bro mailing list. As previously stated, we do not recommend using a beta release for production use.

Thursday, October 20, 2016

Contributing to the Bro Project

Recently we have had a number of community members ask us for suggestions for contributing back to the Bro Project. We have updated the Community page on our website to reflect the new options available.

Custom Scripts and/or Plugins

We encourage Bro users to make their custom scripts and/or plugins available to the community by creating a package and submitting it to the Bro Package Source. See the README file of that GitHub repo for more instructions on how to create a package and submit it. Once your package is accepted, it becomes installable via the Bro Package Manager.

Patches and New Functionality

For working on the Bro codebase itself, work from our official GitHub mirrors or clone the master bro.org repositories directly from git://git.bro.org/<repo>. See our contribution guidelines for more information.

Writing Documentation

We are grateful for any corrections or contributions to documentation. Send documentation to info@bro.org or submit a ticket to our issue tracker.

Provide community support

Respond to user questions on the Mailing List, Twitter, IRC, and Gitter.

Financial Support

Become a Bro Future Fund sponsor, make an individual donation, or sponsor Bro events like BroCon.

Monday, October 3, 2016

Introducing the Bro Package Manager

Bro's New Package Manager

After a long period of being on Bro's development projects wishlist, Bro now has a working prototype of a package management tool.  The idea behind it is to provide Bro users with a command-line tool, bro-pkg, that they can use to manage third-party Bro scripts and/or plugins in the form of "packages."  At the same time, the project aims to provide a centralized location for anyone to share the Bro packages that they have developed, making them readily available to users of the package manager.  Ahead, we'll show some examples of its basic functions and capabilities.

Disclaimers

  • bro-pkg is new and there may still be bugs.
  • Packages installed via bro-pkg come with no guarantees.  Anyone is free to submit packages, so don't assume that any particular package is safe to install unless you have reason to trust the author or have reviewed the package's code yourself.

Basic Usage/Workflow

You can see the Bro Package Manager documentation for full usage/setup instructions, but here's a quick example of what using the package manager will look like.

Checking all available packages:
$ bro-pkg list all bro/0xxon/bro-sumstats-counttable - Two-dimensional buckets for sumstats (count occurences per $str). bro/broala/bro-long-connections bro/dopheide/bro_notice_correlation - Adds support for multi-notice correlation. bro/initconf/scan-NG - Clusterized scan-detection based of bro-1.5.3 scan-detection policies bro/jonzeolla/scan-sampling - Modified version of scan.bro to add destination IP sampling. bro/jsiwek/bro-test-package bro/sethhall/preit-card-exposure - Detect and log credit cards. bro/sethhall/domain-tld - Bro script library for getting the effective TLD of a domain. bro/sethhall/ssn-exposure - Detect and log US Social Security numbers.

Searching for interesting packages based on keyword tags:
$ bro-pkg search file analysis bro/sethhall/credit-card-exposure - Detect and log credit cards. bro/sethhall/ssn-exposure - Detect and log US Social Security numbers.

Get more information on a package:
$ bro-pkg info credit-card-exposure "bro/sethhall/credit-card-exposure" info: versions: [] package metadata (from version "master"): build_command = plugin_dir = build script_dir = scripts version = 1.1.0 index metadata: description = Detect and log credit cards. tags = file analysis, credit card, cc, dlp, data loss url = https://github.com/sethhall/credit-card-exposure

Install it:
$ bro-pkg install credit-card-exposure The following packages will be INSTALLED: bro/sethhall/credit-card-exposure (master) Proceed? [Y/n] y Installed "bro/sethhall/credit-card-exposure" (master) Loaded "bro/sethhall/credit-card-exposure

Later on, you'd check if any packages have been updated:
$ bro-pkg refresh Refreshed source packages: no changes Refreshed installed packages: no new outdated packages

And if a new version of any package is available (in this case, it was not), you could upgrade to it:
$ bro-pkg upgrade All packages already up-to-date.

If you're interested in how to get your own packages listed by bro-pkg, checkout the README of the bro/packages GitHub repository.

Roadmap

The only major, planned feature to add to bro-pkg is automatic dependency analysis/resolution.  e.g. packages should be able to specify a particular Bro version that they require and list other packages (and their version) that they depend on.  Then, for packages that specify such dependencies bro-pkg should automatically be able to install/upgrade package dependencies if the user gives their consent.

Feedback

If you have ideas/suggestions for new features or other feedback, you can find how to get in touch w/ the Bro team here.

If you find bugs, you can report them on the project's GitHub page.  Patches and pull requests are also welcome.

Wednesday, September 21, 2016

Bro News #7

Bro News #7

Welcome to the Bro newsletter #7. This time we cover the following topics:
  • Bro Events.
  • Bro Commits: Bro v2.5 beta is here. Get your newest Bro with new features and improvements.
  • Bro Internals: Give Bro a future, join the Future Fund.

Bro Events

BroCon 2016

BroCon 2016 was hosted by TACC in Austin, Texas. About 20 hours of talks within two and a half days, we had talks from Bro team members about the newest developments, low level practical talks to improve every day work life, and also high level research talks. The new SMB analyzer seems to have had the most impact on the user community. You can read all about here.

We hear you: Our post-conference attendee survey had over 90% who liked the topics, and over 95% that they liked the way those topics were presented. Overall, we appreciate all of the feedback that we received, and while we were blown away by the overwhelmingly positive response, perhaps even more important to us are the opportunities for making BroCon even better. We'll keep all of the feedback in mind as we start the process of preparing for BroCon 2017. We had a few comments regarding the lack of talks discussing incident response. If those types of talks interest you, please consider attending Bro4Pros 2017, as that event tends to have more talks about "life in the trenches."

NSF Cybersecurity Summit 2016

Bro held a one day workshop at the NSF Cybersecurity Summit 2016.

Bro Commits: Bro 2.5 beta is here!

Bro 2.5 beta has been released. Here is a brief summary of some of the new features and improvements:

  • Bro now includes the NetControl framework. This framework allows easy interaction with hard- and software switches, firewalls, etc. 
  • Support for the SMB protocol (SMB1 and SMB2), including GSSAPI and NTLM.
  • Support for the remote framebuffer protocol (RFB), that is used by VNC servers for remote graphical display.
  • The Intelligence framework was refactored and extended. It now supports, for example subnet indicators and item deletion/expiration.
Binary packages of the beta are also available. See NEWS for preliminary release notes and CHANGES for the exhaustive commit list. Feedback is encouraged and should be sent to the Bro mailing list. As previously stated, we do not recommend using a beta release for production use.

Bro Internals: Give Bro a future, join the Future Fund.

Bro's future depends on all of you. The Bro community is a wonderful mix of different personalities and skill sets. Many of them will answer all Bro related questions in our IRC channel #bro on Freenode, and for a while now also in our Bro channel on Gitter. Others contribute to the development of Bro. We want to thank everyone who contributes to Bro in any way. We also would like to send out a call to join the Bro Future Fund, so we can continue all the work that cannot be done by volunteers only. If you appreciate Bro in your daily work and think your company or organization truly benefits from it consider a donation to help us keep up the work.

In that spirit, Corelight (formerly known as Broala) announced a donation of $100,000 at BroCon 2016. Thank you Corelight!

Thursday, August 18, 2016

Bro 2.5 Beta

We are happy to announce the beta of Bro v2.5 is available for download! Here is a brief summary of some of the new features and improvements:
  • Bro now includes the NetControl framework. This framework allows easy interaction with hard- and software switches, firewalls, etc. 
  • Support for the SMB protocol (SMB1 and SMB2), including GSSAPI and NTLM.
  • Support for the remote framebuffer protocol (RFB), that is used by VNC servers for remote graphical display.
  • The Intelligence framework was refactored and extended. It now supports, for example subnet indicators and item deletion/expiration.
Binary packages of the beta are also available.

See NEWS for preliminary release notes and CHANGES for the exhaustive commit list.

Feedback is encouraged and should be sent to the Bro mailing list. As previously stated, we do not recommend using a beta release for production use.

Thursday, July 14, 2016

@Bro_IDS: Your Bro News Feed

Since we created the Bro Twitter account @Bro_IDS in 2011, the channel has turned into one of the most effective ways for reaching out to the Bro community. Every Tweet now reaches more than 5000 followers and counting.

While @Bro_IDS serves us as a microphone for our own updates, we have also always been liberal with retweeting news from the broader Bro community, hoping to help create visibility for Bro’s diverse user population around the world. However, with the tremendous audience that @Bro_IDS is now reaching, there comes responsibility, too. To ensure that the @Bro_IDS team’s decisions remain fair and transparent, the Bro Leadership Team has recently devised a set of guidelines for the account that we would like to share.

Overall, we see @Bro_IDS as serving as a distributor of news related to Bro, covering activity from both the Bro Project itself as well as from the broader community. For the project’s own messages, we may tweet about recent developments, events that the team’s involved with, or external pointers that we deem interesting. As a general rule, if a Tweet originates from @Bro_IDS, it represents the voice of the project.

We use a different policy when retweeting from the community. Generally, we are happy to retweet Bro-related news from users and organizations; just make sure to include @Bro_IDS in your Tweet so that we will see it. This does explicitly include corporate announcements—we are happy to provide visibility for, e.g., products and services, or relevant job postings, as long as they involve a substantial Bro component. However, @Bro_IDS does not endorse external organizations or content. When we retweet, we do so from a neutral perspective, and without judgement.

Our rules for deciding what to retweet are pretty straight-forward: the Tweet must be directly related to Bro; it must not substantially overlap with anything we have already passed on recently; and it must not create the impression, directly or indirectly, that the Bro Project would endorse the content. As an exception, for non-commercial activity we may occasionally also forward news that’s not directly Bro-centric if it still appears relevant to a large part of the Bro community; examples would be the newest OpenSSL vulnerability, or an interesting research paper in the space. We usually do not retweet follow-up conversations unless there’s significant additional information that warrants an update on its own.

We believe that through this policy, @Bro_IDS can serve the Bro community as a valuable, fair source of news. To receive all the updates, make sure to follow @Bro_IDS. If you want to reach the Bro community for your announcement, include @Bro_IDS in your Tweet.

The Bro Team

Saturday, June 4, 2016

BroCon ’16 CFP deadline extended to June 10th

Bro Community,

We are extending the BroCon ’16 call for presentations deadline to Friday, June 10th. For more information about the CFP, see our blog post. And don't forget to register!

See you in September,

The Bro Project

Friday, May 27, 2016

Reminder: Upgrade your Bro installation! Stability updates in 2.4.1

Reminder: Upgrade your Bro installation! Stability updates in 2.4.1


Bro 2.5 is not far away, but in the meantime you should upgrade to Bro 2.4.1. This is the latest stable release. If you are running 2.4 the upgrade to 2.4.1 won't break your config. This release contains important fixes without changing Bro's functionality.
Not sure which one your version is? 'bro --version' will tell you.

Check the change log here.

Monday, May 23, 2016

Reminder: BroCon ’16 CFP ends Friday June 3rd

Interested in presenting at BroCon ’16 this year? Our call for presentations ends Friday, June 3rd.

We are looking for talks to represent the many applications of Bro. Suitable topics include, but are not limited to:
  • as a tool for solving problems;
  • interesting user stories, solutions, or research projects;
  • a postmortem analysis of a security incident, emphasizing Bro’s contribution;
  • the value Bro brings to your professional work;
  • and, using Bro for more than intrusion detection.
Criteria for evaluating proposals include whether the topic is applicable to multiple types of organizations, gives people ideas to take home and use, can be understood by a broad audience, or is novel to many in the audience. Scrolling through our YouTube Channel may provide some insight into the types of presentations we wish to feature. Plan on limiting your talk to 30-35 minutes with an additional 10 minutes for questions/comments.

Send abstracts (max 500 words) to: info@bro.org
Subject: BroCon 2016 Call for Presentations
Submission due date: Friday, June 3rd
Target date for announcing speakers: Friday July 1st

Proposals are selected by the Bro Leadership Team:
  • Seth Hall, International Computer Science Institute
  • Keith Lehigh, Indiana University
  • Vern Paxson, University of California at Berkeley / International Computer Science Institute
  • Michal Purzynski, Mozilla Foundation
  • Aashish Sharma, Lawrence Berkeley Lab
  • Adam Slagell, National Center for Supercomputing Applications
  • Robin Sommer, International Computer Science Institute

Tuesday, May 17, 2016

Talk to us! - The Bro team's communication channels

Talk to us! - The Bro team's communication channels

Bro is now more than 20 years old. The community has grown in size and diversity. In response we made some changes to the ways the Bro community can communicate with us.

Gitter


We are currently testing Gitter, a chat system designed for developers. Please join the Bro channel. You can browse to it at gitter.im/bro/bro, download the native apps, or connect via IRC. Currently, we have a Bro room and Broker room. We're looking forward to seeing you there! The test will go on for a couple more weeks. Please give feedback in Gitter or to info@bro.org about this.

IRC


Our IRC channel #bro on Freenode is the well established chat where many people of the community as well as some Bro developers will answer questions.

The Bro Mailing Lists


We also will continue to maintain our mailing lists. The most important ones are bro@bro.org, bro-announce@bro.org, and bro-dev@bro.org.

bro@bro.org is our general user mailing list. If you prefer mail over chat, this should be your first address whenever you get stuck using Bro or want to understand something. Experienced Bro users and members of Bro's developer team answer on this list.

bro-announce@bro.org is a low traffic mailing list used to announce Bro events, code releases, and other important news.

bro-dev@bro.org is the mailing list you should subscribe to if you want to follow or participate in discussions on Bro's future from a developer perspective. On this list we discuss design and feature decisions, and also how to resolve problems and bugs. We recently moved automated mails from our ticket system away from this list to reduce the noise. The immediate effect was an increase in productive discussions.

Twitter


Our Twitter channel is @Bro_IDS. This is our channel for quick and short news, too small for bro-announce or a blog post.

Bro Community and other ways to reach us


More options to listen or talk to us are listed on our Community page.
If you need to talk to us in private about logistics, donation offers, or other special requests, you can write to info@bro.org.

A little reminder and request to the community: As an open source project the Bro team tries to help wherever possible with using and developing Bro. Please send technical questions to one of the mailing lists, though; not to info@bro.org. That way the broader Bro community gets a chance to chime in as well, and everybody will benefit from any responses.

The Bro User Community


We want to take this opportunity to thank all our users and contributors! Please keep talking to us.

Friday, January 29, 2016

BroCon ’16: Sept. 13th - 15th in Austin, TX

We are happy to announce that BroCon ’16 will occur on Tuesday, September 13th - Thursday, September 15th at the Texas Advanced Computing Center in Austin, Texas.

See our event page:
https://www.bro.org/community/brocon2016.html

Early bird registration is open! CFP is open!

Interested in sponsoring BroCon? Contact us at info@bro.org for more information.

Thank you for your continued support, and see you in September!

Regards,
The Bro Project

Tuesday, January 19, 2016

Bro training at Educause Security Professionals Conference, April 18th

The Bro Team is presenting a training at the 2016 Educause Security Professionals Conference on Monday April 18th in Seattle, Washington. Our topic is "Monitoring Your Science DMZ with Bro."

The Science DMZ architecture is spreading throughout higher ed, with both the National Science Foundation and ESNet promoting this more open model to campus cyberinfrastructure providers. NSF has invested in building 10G and 100G research networks to meet the growing demands of the nation's scientists and engineers, but this brings challenges to many traditional ways of securing campus infrastructure. Bro has a successful track record protecting some of the most demanding networks in the country, and it comes well prepared to address the security challenges of bringing data and compute resources outside the firewall for performance. The NSF Bro Center of Expertise is hosting a one-day Bro training workshop aimed at higher ed operators of cyberinfrastructure. This hands-on training will demonstrate Bro's capabilities, teach you how to set up and configure Bro, discuss strategies for deployment on high-speed networks, and present opportunities for further individual assistance from the center.

OUTCOMES:
  • Understand the purpose of Bro and its features
  • Learn how to install Bro with suggested configuration modifications (e.g., load balancing, pinning workers)
  • Learn how to seek assistance from the Bro Center of Expertise

Event link:
http://www.educause.edu/events/security-professionals-conference

Bro Abstract:
http://www.educause.edu/events/security-professionals-conference/2016/monitoring-your-science-dmz-bro