Event Message Bus
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 toTrue
.
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.
If the event forwarder does not provide the flexibility or output options you require, then continue to our Message Bus API reference and the Quick Start Guide.
Last modified on May 18, 2021