Tutorial: Splunk Integration Using HEC

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

In this tutorial we will learn how to configure the EDR event forwarder, and Splunk in order to view EDR events within the Splunk interface using the HTTP Event Collector.

Before You Begin

What events would you like to forward from Carbon Black EDR to Splunk? By default, the Event Forwarder will send watchlist & feed hits to Splunk. Additionally, you can choose to forward any of the event types collected by EDR to your Splunk server, including process spawn events, network connections, file modifications, registry modifications, and more.

Of course, adding event types will greatly increase the event rate into Splunk. As a rough order of magnitude, the typical Windows endpoint will generate anywhere between 2-10 events per second, where each event can average between 200-500 bytes in length. If you are considering enabling several endpoint event types, it’s highly recommended to install the event forwarder on a machine separate from your Carbon Black server and also save the output for a few days to disk in order to estimate the flow size before enabling forwarding into Splunk.


  • On the EDR server, install the EDR Event Forwarder - documentation, source code

  • On the Splunk instance, install the VMware Carbon Black EDR On-Prem App and if required by your deployment configuration the TA. Installation and configuration instructions are in the Splunk User Guide


  1. Enable HEC input from the EDR Server

    1. Follow the instructions provided by Splunk to configure an HEC Token
    2. Make note the HEC URL - as it varies between on-prem and cloud Splunk instances.
  2. Configure the EDR Event Forwarder to send data to Splunk HEC

    1. Install the latest cb-event-forwarder using YUM
    2. Configure cb-event-forwarder.conf as shown in the following example:

# Additional configuration options have been ommited

# Configure the specific output.

# Valid options are: 'udp', 'tcp', 'file', 'stdout', 's3'


#  udp - Have the events sent over a UDP socket

#  tcp - Have the events sent over a TCP socket

#  file - Output the events to a rotating file

#  s3 - Place in S3 bucket (not officially supported)

#  syslog - Send the events to a syslog server




# Configure the output format

# valid options are: 'leef', 'json'


# default is 'json'

# Use 'leef' for pushing events to IBM QRadar, 'json' otherwise








Last modified on March 16, 2018