Carbon Black EDR (Endpoint Detection and Response) is the new name for the product formerly called CB Response.

EDR 4.2+ supports a rich array of asynchronous server-side notifications, referred to as the “message bus”. This interface provides a “push” notification service so that your application can receive and process any event that is received or generated by the Carbon Black server. These events include:

• Notification of a watchlist and/or feed
• Notifications when a new binary is discovered on an endpoint
• Every single endpoint event collected by EDR

The message bus enables you to build applications that can:

• Forward events onto a third party service, such as Splunk. This is implemented in the CB Event Forwarder.
• Evaluate network connections against a machine learning model to find potential botnet Command & Control nodes
• React to certain conditions in near-real-time, for example, taking custom actions when a network connection is created by an endpoint. For example, this is how the Infoblox connector is notified when an endpoint contacts an Infoblox-flagged domain and can kill the offending process.
• … and much more

Configuring the Message Bus

By default, CB publishes the feed.* and watchlist.* events over the bus (see the Events documentation for more information). If you want to capture raw sensor events or the binaryinfo.* notifications, you have to enable those features in /etc/cb/cb.conf:

• If you are capturing raw sensor events then you also need to edit the DatastoreBroadcastEventTypes option in /etc/cb/cb.conf to enable broadcast of the raw sensor events you wish to export.
• If you are capturing binary observed events you also need to edit the EnableSolrBinaryInfoNotifications option in /etc/cb/cb.conf and set it to True.

By Default the Message Bus listens on port 5004. Ensure firewall rules allow for incoming and outgoing TCP connections to this port.

Note on enabling Raw Sensor Events

We have seen a performance impact when exporting all raw sensor events onto the enterprise bus. We do not recommend exporting all the events. The performance impacts are seen when the events are broadcast on the bus, by enabling the “DatastoreBroadcastEventTypes”. We recommend that at most, only process and netconn events be broadcast on the event bus.

Carbon Black needs to be restarted if any variables were changed in /etc/cb/cb.conf by executing service cb-enterprise restart.

If you are configuring the cb-event-forwarder on a Carbon Black cluster, the DatastoreBroadcastEventTypes and/or EnableSolrBinaryInfoNotifications settings must be distributed to the /etc/cb/cb.conf configuration file on all minion nodes and the cluster restarted using the /usr/share/cb/cbcluster restart command.

Subscribing to the Message Bus

It’s highly recommended to start with the Event Forwarder when working with the message bus. We also provide a quick start video guide to setting up the event forwarder.

If the event forwarder does not provide the flexibility or output options you require, then continue to our Message Bus API reference.