VMware Carbon Black

EDR Integration Guide

23 June, 2021
VMware Carbon Black EDR 7.5
VMware Carbon Black EDR Integration Guide

You can find the most up-to-date technical documentation on the VMware website at:

https://docs.vmware.com/

VMware, Inc.
3401 Hillview Ave.
Palo Alto, CA 94304
www.vmware.com

©
Copyright 2021 VMware, Inc. All rights reserved. Copyright and trademark information.

VMware, Inc. 2
 Contents

Preface 6

1 Before You Begin 7

What This Document Covers 7
Other Documentation 8
Contacting Technical Support 8
Reporting Problems 9

2 App Control 10
Overview 10
Built-in Compatibility Features 10
Features when Servers are Integrated 11
Activating Integration 12
Creating a Carbon Black EDR User for Integration 12
Configuring and Activating the Integration 12
Viewing Integration Settings in Carbon Black EDR 14
Regenerating the Authorization ID for Server Communication 15
App Control Console 15
Sensor Information 16
File and Process Information 17
Event Information 19
Links to the Carbon Black EDR Console 20
Correlation of Exported Data 20

3 Anti-Malware Scanning Interface 21

Overview of AMSI 21
AMSI Data 21
Using AMSI with Carbon Black EDR (beta) 22
Event Forwarder Settings 22
Sensor Group Settings 23

4 EMET 24
Overview 24
EMET Events 25
Process Search and Analysis for EMET Events 26
EMET Configuration Searches 27
EMET Events and Threat Reports 27
Enabling and Disabling the EMET Protection Feed 29

VMware, Inc. 3
VMware Carbon Black EDR Integration Guide

EMET Status on an Endpoint 29

Disabling Sensor EMET Event Reporting 31

5 SSO Identity Providers 33

Overview 33
Supported SAML 2.0 Specifications 34
Supported SSO Identity Providers 34
SAML 2.0 Single Sign-On Setup 34
Attribute Mapping 35
Example Attribute Mapping Script 36
Integrate OKTA IdP 38
Shibboleth IdP 40
ADFS IdP 42
Troubleshoot SSO Integration 44

6 Third-Party Authentication 46
Overview 46
Set Up Duo Administrator Unix Application Account 46
Configure Duo Plugin 47
Map Carbon Black EDR Users to Duo Users 48
secrets.ini Settings File 48
Enable Two-Factor Authentication 48

7 Syslog 50
Overview of Logging 50
Notification Logs 50
Audit Logs 51
Syslog Format 52
Watchlist Hit on Process 52
Watchlist Hit on Binary 54
Feed Hit on Process Ingress 55
Feed Hit on Process Storage 57
Feed Hit on Binary Ingress 58
Feed Hit on Binary Storage 59
Feed Hit on Host Ingress 61
Feed Hit on Process Query 62
Feed Hit on Binary Query 63
Syslog Integration 64
Setting Up Remote Devices 64
Setting Up Server Data Transmission 64
Sending All Data to a Remote Device 66

VMware, Inc. 4
VMware Carbon Black EDR Integration Guide

Sending Watchlist Data to a Remote Device 66

Enabling Communication Persistence (Spooling) 67
Carbon Black EDR Syslog Architecture 68
Watchlist Log Location 68
Syslog Templates 68
Overriding System Default Templates 70
Available Keys by Event Type 71
binaryinfo.observed 71
binaryinfo.group.observed 71
binaryinfo.host.observed 71
feed.ingress.hit.binary 72
feed.storage.hit.binary 72
feed.ingress.hit.process 74
feed.query.hit.process 75
feed.storage.hit.process 75
watchlist.hit.process 77
watchlist.hit.binary 78
Syslog Common Event Format 80
Applying the Default CEF Templates 80
Extension Dictionary 81

8 VDI Support 82
Overview 82
Configuring the Server for VDI Support 83
Enabling VDI Support 83
Deploying a VDI Support Plug-in 83
Specifying the Scope of VDI Support 84
Global VDI Support 84
Setting up Global VDI Support on Windows 85
Setting up Global VDI Support on macOS 85
Setting up Global VDI Support on Linux 85
Sensor Group VDI Support 86

VMware, Inc. 5
Preface

The VMware Carbon Black Integration Guide provides information for administrators who are
responsible for integrating VMware Carbon Black EDR with other tools and applications.

You can integrate VMware Carbon Black EDR with various tools and applications such as VMware
Carbon Black App Control, SSO identity providers, Syslog and others.

Intended Audience
The information is written for experienced VMware Carbon Black EDR administrators who
integrate VMware Carbon Black EDR with other tools and applications.

VMware, Inc. 6
Before You Begin
1
This preface provides a brief orientation to the VMware Carbon Black EDR Integration Guide
v7.5.

This chapter includes the following topics:

n What This Document Covers

n Other Documentation

n Contacting Technical Support

What This Document Covers

This documentation provides information for administrators who are responsible for integrating
VMware Carbon Black EDR with various tools.

The following table summarizes the contents of this guide:

Chapter Description

Chapter 2 App Control Describes the procedure for integrating Carbon Black EDR with VMware Carbon Black
App Control. It describes the available features when this integration is active, and general
features that contribute to the coexistence of the Carbon Black EDR sensor and App
Control agent on the same computer.

Chapter 3 Anti-Malware Describes the Anti-Malware Scanning Interface (AMSI) support in the Carbon Black EDR
Scanning Interface Event Forwarder. This is a beta release of this feature.

Chapter 4 EMET Describes the procedure for integrating a Carbon Black EDR server with the Microsoft
Enhanced Mitigation Experience Toolkit (EMET).

Chapter 5 SSO Identity Describes supported SAML 2.0 specifications and SAML 2.0 Single Sign-On (SSO) setup. It
Providers also explains how to integrate with the OKTA, Shibboleth, and ADFS IdPs.

Chapter 6 Third-Party Describes how to integrate Duo plug-in; you can configure two-factor authentication and
Authentication download the Duo Mobile application on a mobile device.

Chapter 7 Syslog Describes syslog output for Carbon Black EDR events. It provides descriptions and
examples of the output, and explains how you can use syslog output for notification of
alerts.

Chapter 8 VDI Support Describes Carbon Black EDR support for Virtual Desktop Infrastructure (VDI) and how to
configure your machines to use it.

VMware, Inc. 7
VMware Carbon Black EDR Integration Guide

Other Documentation
To accomplish tasks that are not covered in the VMware Carbon Black EDR Integration Guide,
see the following documentation.

n VMware Carbon Black EDR User Guide – Describes the Carbon Black EDR product and how
to use all of its features and perform administration tasks.

n VMware Carbon Black EDR Operating Environment Requirements (OER) – Describes

performance and scalability considerations in deploying a Carbon Black EDR server. Note that
this was called the Server Sizing Guide in previous releases.

n VMware Carbon Black EDR Server Configuration (cb.conf) Guide – Provides all of the cb.conf
configuration file functions, descriptions, and parameters.

n VMware Carbon Black EDR Unified View Server Guide – Describes how to install and use the
Carbon Black EDR Unified View server, which is a standalone server that ties multiple Carbon
Black EDR servers together and provides a single interface. The Carbon Black EDR Unified
View interface allows you to perform queries across multiple Carbon Black EDR servers with
a unified result set. The Carbon Black EDR Unified View server also allows you to access the
full functionality of a single Carbon Black EDR server.

n VMware Carbon Black EDR Release Notes – Provides information about new and modified
features, issues resolved and general improvements in this release, and known issues and
limitations. It also includes required or suggested preparatory steps before installing the
server.

n VMware Carbon Black EDR API – Documentation for the Carbon Black EDR REST API is
located at https://developer.carbonblack.com/reference/enterprise-response.
Documentation for the Python module that can be used for easy access to the REST API is
hosted at https://cbapi.readthedocs.io.

n VMware Carbon Black EDR Connectors – A connector enables communication between a

third-party product and a Carbon Black EDR server. This content describes how to install,
configure and maintain various VMware Carbon Black connectors: https://
developer.carbonblack.com/guide/enterprise-response/#connectors.

Contacting Technical Support

View our Customer Support Guide on the User Exchange for more information about Technical
Support: https://community.carbonblack.com/t5/Support-Zone/Guide-to-Carbon-Black-Customer-
Support/ta-p/34324

VMware Carbon Black Technical Support offers several channels for resolving support questions.

Technical Support Contact Options

Web: https://community.carbonblack.com

Email: [email protected]

VMware, Inc. 8
VMware Carbon Black EDR Integration Guide

Technical Support Contact Options

Phone: 877.248.9098 or 617.393.7400

Fax: 617.393.7499

Reporting Problems
When you call or email technical support, provide the following information to the support
representative.

Required Information Description

Contact Your name, company name, telephone number, and email address

Product version Product name and version number

Hardware configuration Hardware configuration of the server or computer the product is running on (processor,
memory, and RAM)

Document version For documentation issues, specify the title of the manual you are using.

Problem Action causing the problem, error message returned, and any other appropriate output

Problem severity Critical, serious, minor, or enhancement

VMware, Inc. 9
App Control
2
This chapter describes how to integrate Carbon Black EDR with VMware Carbon Black App
Control.

It describes the features that are available when this integration is active, and general features
that contribute to the coexistence of the Carbon Black EDR sensor and App Control agent.

Note App Control has also been known as the Bit9 Security platform and as CB Protection. You
might see these terms in this document.

This chapter includes the following topics:

n Overview

n Activating Integration

n App Control Console

Overview
Carbon Black EDR provides powerful features for endpoint threat detection and response. App
Control provides its own powerful features for endpoint threat protection.

You can take advantage of their complementary features by installing both the Carbon Black EDR
sensor and the App Control agent on your endpoints, and adding Carbon Black EDR features
inside App Control to improve your security posture.

Note In addition to integrating with each other, both Carbon Black EDR and App Control can
take advantage of information from the VMware Carbon Black Cloud, which provides reputation
information, threat indicators, and attack classification intelligence. See “Threat Intelligence
Feeds” in the VMware Carbon Black EDR User Guide for more information.

Built-in Compatibility Features

The App Control agent recognizes the Carbon Black EDR sensor and reports its presence to the
App Control server.

VMware, Inc. 10
VMware Carbon Black EDR Integration Guide

The App Control server allows efficient operation of both the App Control agent and Carbon
Black EDR sensor on the same endpoint.

n Performance Optimizations – Internal performance optimizations nearly eliminate any

performance impact on either product from having the other product’s agent or sensor
installed.

n Trust for Sensor Updates – Updater rules allows seamless installation and upgrades of
Carbon Black EDR Mac and Linux sensors that would otherwise have been blocked by a App
Control agent in Medium and High enforcement modes. See “Approving by Updater” in the
App Control console Help for more information about updater rules.

n Publisher Trust for Carbon Black EDR – A Publisher rule in App Control instructs agents to
trust (by default) Windows files that are identified as being from the publisher “Carbon Black,
Inc.” This is the publisher for Carbon Black EDR files. See “Approving or Banning by Publisher”
in the App Control console Help.

n Server Integration Interface – The Licensing tab on the App Control System Configuration
page includes a Carbon Black EDR section that you can use to activate integration with a
specific Carbon Black EDR server. Step-by-step instructions are included in Activating
Integration.

Features when Servers are Integrated

Additional Carbon Black EDR-to-App Control integration features become available when you
explicitly configure two servers to work with each other.

Most of these features involve making information from and about Carbon Black EDR available in
the App Control console:

n Carbon Black EDR Sensor Details in the App Control Console – Pages displaying details
about a computer that is running the App Control agent show whether the Carbon Black EDR
sensor is installed, and if so, the version and status of the sensor (for Windows agents only).

n Carbon Black EDR File Statistics in App Control Console – Details about a file on a computer
running the App Control agent show Carbon Black EDR statistics about the file — such as how
many watchlists it is on, the number of computers and processes in which the file has been
seen, and the number of network connections.

n Links to the Carbon Black EDR server in the App Control Console – Menu and inline links
from the App Control console Events table, Computer Details , and File Details pages
connect to the Carbon Black EDR data for the object that is being viewed.

n App Control Agent Status in the Carbon Black EDR Console – The Host Information page for
each computer running a sensor reports whether a App Control agent is installed.

n Process Data Correlation – A globally unique process identifier called a Process Key shows
when events on a Carbon Black EDR server and a App Control server are referencing the
same process. It uniquely identifies an individual instance of the running process. This
identifier is available in Syslog output, and as data that is exported for third-party analysis
tools such as Splunk.

VMware, Inc. 11
VMware Carbon Black EDR Integration Guide

App Control Console for more details on integration features.

Activating Integration
Integration configuration settings appear in both the Carbon Black EDR and App Control
consoles.

You can perform the integration configuration on the Licensing tab of the System Configuration
page in the App Control console. After the integration is set up, you can view the configuration in
the Carbon Black EDR console.

Creating a Carbon Black EDR User for Integration

The user account for the integration must be a Global Administrator.

If you do not already have a user account for App Control integration, perform the following
procedure.

To create a App Control Integration user and API Token:

1 Log into Carbon Black EDR.

2 On the navigation menu, click Users .

3 Click Add User .

4 Define the user to use for the integration:

a In the Username field, enter a meaningful username such as App Control Integration .

b Populate the First Name and Last Name fields. These values appear in the Carbon Black
EDR console.

c Provide an email account for the user. An email account is required for Carbon Black EDR
console users. However, this email account can be fictitious, because it is not used as a
typical account.

d Enter and confirm a password for the account.

e Select the Global administrator check box.

f Click Add User .

Configuring and Activating the Integration

The following procedure involves using both consoles. You can copy information from the
Carbon Black EDR console and paste it into the App Control console.

To activate integration:

1 Review the information in Table 2.1 Integration Settings in App Control for Carbon Black EDR.

2 Log into Carbon Black EDR.

3 Click Username> My Profile .

VMware, Inc. 12
VMware Carbon Black EDR Integration Guide

4 Click API Token .

5 From the API Token field, copy the API token.

6 Open another browser and log into the App Control console using an account that has
Administrator privileges.

7 In the App Control console menu:

a If you are running v7.2.3, select Administration > System Configuration .

b If you are running v8.0.0 or higher, click the Administration (gear) icon and select System
Configuration .

8 Click the Licensing tab.

9 Enter the Carbon Black EDR configuration settings as shown in the following table.

Table 2-1. Integration Settings in App Control for Carbon Black EDR
Field/Button Description

URL The URL of the Carbon Black EDR server to link to the App Control server. Port is only
necessary if you do not use standard ports on the Carbon Black EDR server (80 for HTTP and
443 for HTTPS).
You can copy the base URL (without any page-specific additions) from the Carbon Black EDR
browser and paste it into the relevant section of the App Control Configuration page.

Validate SSL Select this check box to cause a validity check on the Carbon Black EDR server certificate. This
Certificate should be selected only if the Carbon Black EDR server certificate is issued by a trusted
certificate authority. Without manual configuration, Carbon Black EDR uses a self-signed
certificate; this should not be checked.

API Token Enter the Carbon Black EDR server API Token here by pasting it from the Carbon Black EDR
console. Click the Test button to confirm that the server is accessible and that the key works.
The test returns one of the following values:
n Success, version: <Carbon Black EDR product version>
n Invalid API Token
n Server not accessible

Receive Watchlist Select this box to activate delivery of Carbon Black EDR watchlist events from the configured
Events server to the App Control server.

Force Strong SSL Select this box to cause the Carbon Black EDR server to check the App Control server
certificate before sending events. Important: This should not be selected if your App Control
server uses a self-signed App Control certificate on IIS.

VMware, Inc. 13
VMware Carbon Black EDR Integration Guide

10 Click the Test button to determine whether the servers can communicate. Possible causes of
failure and their troubleshooting steps are as follows:

n Invalid API Token – Make sure that the API token for the App Control user has been
copied correctly from the Carbon Black EDR console and pasted into the Configuration
page on the App Control console. Make sure that this user is a Global Administrator.

n Server not accessible – Confirm that the correct URL and port number (if needed) has
been entered in the Configuration page on the App Control console, and that the
Validate SSL certificate check box was not selected when you use a self-signed
certificate. Make sure that access to the Carbon Black EDR server is not blocked by a
network firewall.

n Force Strong SSL – Selecting this check box causes the Carbon Black EDR server to
check the App Control server certificate before sending watchlist events. This should be
checked only if the App Control console certificate is issued by a trusted authority (for
example, not self-signed).

If you cannot create a successful connection, contact VMware Carbon Black Technical
Support .

11 When you have entered and successfully tested the App Control server settings in the App
Control console, click Update on the System Configuration/Licensing page. The configuration
should be complete and the servers should be integrated.

Viewing Integration Settings in Carbon Black EDR

In the Carbon Black EDR console, you can view the current App Control integration settings.

To view integration settings in the Carbon Black EDR console:

1 Log into Carbon Black EDR.

2 Click Username > Settings .

3 Click VMware Carbon Black App Control Server .

Note
n You can change the watchlist and SSL settings in the Carbon Black EDR console. However,
you cannot change the URL or API Token parameters here. If you need to modify these
parameters, use the App Control console.

n The value in the Server URL field on this page must be resolvable by the Carbon Black EDR
server for proper communication with App Control.

To view the App Control integration status in the Carbon Black EDR console:

1 Log into Carbon Black EDR.

2 On the navigation bar, click Server Dashboard .

VMware, Inc. 14
VMware Carbon Black EDR Integration Guide

The status of the App Control server connection is shown in the Server Communication
Status panel in the top-right corner.

3 Three possible states can occur. You might need to perform more steps depending on the
status:

n App Control Server is connected – Indicates that the integration is configured and the
connection is functioning properly.

n App Control Server not configured – If the App Control server connection has not been
configured, a Settings button appears in the status line for the connection. Do not use
this button. You cannot configure the API Token or URL on this page; they must be
entered in the App Control console.

n Unable to connect to App Control Server – Can indicate network or firewall problems, a
bad URL, or port configuration. It can also occur if Force Strong SSL was chosen on the
App Control console System Configuration page for Carbon Black EDR, when a self-
signed certificate is being used on the App Control console.

Regenerating the Authorization ID for Server Communication

The App Control server creates a hidden token that the Carbon Black EDR server uses to send
back watchlist hits. This token is not visible in the console of either product, but can be retrieved
from the database.

You can also enter the token manually on the Carbon Black EDR side for diagnostic purposes. If
you think this token was compromised, or if your configuration stops working (for example,
because the Carbon Black EDR server lost the token due to a reinstall or a manual token change),
you can regenerate a new key.

To regenerate the authorization key for server communications:

1 In the App Control console:

a If you are running v7.2.3, select Administration > System Configuration and click the
Licensing tab.

b If you are running v8.0.0 or higher, click the Administration (gear) icon, select System
Configuration, and click the Licensing tab.

2 In the Carbon Black EDR panel, uncheck the Receive Watchlist Events box and click the
Update button.

3 Check the Receive Watchlist Events box and click the Update button. A new key is
generated.

4 Verify that there is a successful connection.

App Control Console

You can view various forms of Carbon Black EDR data in the App Control Console.

VMware, Inc. 15
VMware Carbon Black EDR Integration Guide

Sensor Information
If you integrate the App Control server with the Carbon Black EDR server, App Control console
pages show Carbon Black EDR sensor details when they are available.

To view App Control-managed computers that are also running a Carbon Black EDR sensor:

1 In the App Control console menu, click Assets > Computers .

2 On the Saved Views menu, select Carbon Black EDR Deployments to see computers that
have had a Carbon Black EDR sensor installed on them. This view also shows the Carbon
Black EDR sensor version and its current status.

3 Click the hyperlinked Computer Name to see more Carbon Black EDR sensor details on the
Computer Details page. The Carbon Black EDR tab reports the presence, version, status, and
other details of any Carbon Black EDR sensor that is found on a computer that is running the
App Control agent. If a Carbon Black EDR server is not configured or the computer is not
running a Carbon Black EDR sensor, this view shows Not installed . By default, the App
Control server checks Carbon Black EDR status every 30 minutes.

The Carbon Black EDR tab also provides a More information link to the Sensors page in the
Carbon Black EDR console.

Table 2-2. Carbon Black EDR tab fields on the App Control Computer Details page describes the
information that is available on the Carbon Black EDR tab for App Control Computer Details
pages. This information currently shows for Windows agents only. macOS and Linux agents
report that Carbon Black EDR information is Unknown.

VMware, Inc. 16
VMware Carbon Black EDR Integration Guide

Table 2-2. Carbon Black EDR tab fields on the App Control Computer Details page
Field Description

Sensor Version The version of the Carbon Black EDR sensor that is installed on this computer.

Sensor Status Last The last Carbon Black EDR sensor status for this computer, as reported by the App Control
Status (on Details agent to the App Control server. The App Control server checks Carbon Black EDR status
page) every 30 minutes. Status changes might be temporarily out of sync.
The possible values for Carbon Black EDR status are:
n Unknown
n Installed, initializing – sensor installed but not fully initialized
n Installed, running
n Installed, not running
n Not installed
n Stopped
On the Details page, the Last Status field on the Carbon Black EDR tab is similar to Sensor
Status in the table. However, it does not appear if sensor status is Unknown . Its possible
values are:
n Running
n Service not running
n Kernel not running
n Stopped

Note In addition to a 30-minute or less gap between sensor installation and App Control
polling of Carbon Black EDR status, status continues to report as Not installed until the Carbon
Black EDR sensor connects to the Carbon Black EDR server and receives a sensor id. If the App
Control agent is offline or uninstalled, the last Carbon Black EDR sensor status reported by the
agent is displayed in the App Control console, even if sensor status changes.

Uptime Number of minutes and hours that the Carbon Black EDR sensor has been running since it was
last started.

Registration Time The date and time the Carbon Black EDR sensor registered with its server.

Last Checkin The date and time the Carbon Black EDR sensor on this computer last checked in with its
server.

Next Checkin The date and time of the next scheduled server checkin for the Carbon Black EDR sensor.

More Information Connects to the Login page of the Carbon Black EDR server that is configured on the System
Configuration page Licensing tab. Logging in takes you to the Sensors page in Carbon Black
EDR, so you can view additional details about this computer.

Note You must have valid login credentials for the Carbon Black EDR server to successfully
open the Carbon Black EDR console.

File and Process Information

In the App Control console, you can view Carbon Black EDR statistics on files.

n Number of associated watchlists.

VMware, Inc. 17
VMware Carbon Black EDR Integration Guide

n Number of computers and processes in which the file has been found.

Note For Windows 5.1.1 and previous sensors, Carbon Black EDR process information is available
to App Control. Process information is not available in App Control from the Carbon Black EDR
macOS or Linux sensors.

To view Carbon Black EDR details for a file on an App Control-managed computer:

1 In the App Control console, click Assets > Files .

2 Click the File Catalog tab to view a table of unique files that are discovered on computers
that this App Control server manages. You can also select Files on Computers to view a table
of all file instances.

3 Click the View Details icon (file and pencil) on the left of that file row.

Table 2-3. Carbon Black EDR fields on App Control File/File Instance Details pages
Field Description

First Seen Activity The date and time when activity involving this file was first reported to the Carbon Black EDR
server.

Watchlists The number of Carbon Black EDR watchlists on which this file appears. This appears if
watchlist export is configured on the App ControlSystem Configuration page for Carbon
Black EDR.

Frequency Data The frequency of the file is the number of endpoints that have this file associated with a
process. The number of processes is the count of all processes that have been associated
with this file.

Unique Paths The number of unique paths in which this file has been seen (only appears if data is available).

Network Connections Whether there have been any network connections associated with this file, and if so, on how
many computers (only appears if data is available).

Registry Modifications Whether there have been any registry modifications associated with this file, and if so, on
how many computers (only appears if data is available).

VMware, Inc. 18
VMware Carbon Black EDR Integration Guide

Table 2-3. Carbon Black EDR fields on App Control File/File Instance Details pages (continued)
Field Description

File Icon The icon for this file (if any).

More information Link to the Carbon Black EDR console showing more information about this file (from the File
Details page) or a particular instance of this file on a particular computer (from the File
Instance Details page). See Links to the Carbon Black EDR Console.

Event Information
You can see Carbon Black EDR events in unfiltered views of the events table; there is also a
Saved View for Carbon Black EDR events.

The App Control console Events page can display two Carbon Black EDR-related event subtypes:

n Carbon Black EDR sensor status

n Carbon Black EDR watchlist

To view Carbon Black EDR-related events in the App Control Console:

1 In the App Control console menu, click Reports > Events.

2 On the Saved Views menu, click Carbon Black EDR.

The following image shows the Carbon Black EDR view with filters displayed:

Carbon Black EDR exports both process and binary watchlist events to App Control (when export
is activated).

VMware, Inc. 19
VMware Carbon Black EDR Integration Guide

For process watchlist events, you can add a column to display the unique Process Key ID that
correlates process information between App Control and Carbon Black EDR. Correlation of
Exported Data.

When Carbon Black EDR watchlist hits appear in the App Control Events table, the watchlist
name appears in the Rule Name and Description fields of the table.

Links to the Carbon Black EDR Console

Where Carbon Black EDR information is displayed in the App Control console, there is often a link
to the relevant location in the Carbon Black EDR console.

The link is identified with the App Control logo, and uses the server URL that is provided in the
Carbon Black EDR server section of the App Control System Configuration page.

The following example from the Events page in the App Control console shows how such a link
appears.

In other cases, there might be a menu link to Carbon Black EDR Details .

When a user clicks one of these links, the Carbon Black EDR login page appears.

If this browser remains open, the login credentials stay active for 90 minutes, and subsequent
use of links during this period go directly to the relevant page.

Correlation of Exported Data

Carbon Black EDR and App Control servers make event data available for external use.

Carbon Black EDR and App Control users might consider correlating or analyzing data from both
sources.

To facilitate correlation, events that include process data have a unique process key for each
process. The process key is available as follows:

n Syslog output from the Carbon Black EDR server

n Syslog output from the App Control server

n Carbon Black EDR API queries

n App Control Live Inventory SDK/Public API queries

n Data exported specifically for Splunk from the App Control server

n External event exports and event archives from the App Control server

n Carbon Black EDR email alerts

See the App Control console Online Help for information about the App Control features.

VMware, Inc. 20
Anti-Malware Scanning Interface
3
A sensor event called the fileless scriptload event is recorded by the Windows sensor.

This chapter includes the following topics:

n Overview of AMSI

n Using AMSI with Carbon Black EDR (beta)

Overview of AMSI
AMSI support is available as a beta feature in Carbon Black EDR 7.2 and later releases, together
with the Windows 7.1+ sensor.

The fileless scriptload event leverages the Anti-Malware Scanning Interface (AMSI) support
that is available in Windows 10 and Windows 2016. Endpoints must be running Windows 10 RS2
or higher for our sensors to record AMSI data.

The fileless_scriptload event represents each occasion when the sensor detected AMSI-
decoded script content that was executed by any process on the endpoint. This consists only of
fileless script content that was not stored in a file on the file system when that context was
executed.

For example, you can detect when the PowerShell runtime was loaded into another process by
malware, which obtains encoded PowerShell script content from a remote network server and
then executes that script content directly from memory.

The sensor reports events to the Carbon Black EDR server only if they originate from an event
that is not backed by an on-disk file. File-based scripts are logged locally.

Support for decoding fileless script content via AMSI is dependent on the script interpreter that
integrates with the AMSI interface in Windows. Carbon Black EDR currently supports PowerShell.
For information about the AMSI API, see https://docs.microsoft.com/en-us/windows/win32/amsi/
dev-audience .

AMSI Data
AMSI data is part of process execution metadata. A generic event type is added as part of the
AMSI data stream.

VMware, Inc. 21
VMware Carbon Black EDR Integration Guide

To see the raw AMSI data in Event Forwarder, you can expand the fileless_scriptload events .
Other metadata that the fileless script events captures include the script length and the unique
SHA256 hash of the fileless script event.

All AMSI content is logged locally on the endpoint as a text file. The log is located in the sensor
installation directory and is named AmsiEvents.log . This log contains all AMSI content that is
detected by the sensor, including events that are not reported to the Carbon Black EDR server
due to privacy reasons.

AMSIEvents.log on the endpoint is capped at 50 MB, unzipped. After that limit is reached, the log
contents are migrated to a new file ( AMSIEvents.old.log ) before recreating AMSIEvents.log .
After the second 50 MB log fills up, Carbon Black overwrites AMSIEvents.old.log again.
Therefore, no more than two 50 MB local log files exist.

Using AMSI with Carbon Black EDR (beta)

AMSI events can be forwarded through the Event Forwarder in JSON and LEEF.

Carbon Black EDR Windows sensors perform asynchronous RPC calls; the sensor captures
commands and script contents that PowerShell executes.

PowerShell script block logging must be enabled. Verify that this is not turned OFF in
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging

Event Forwarder Settings

In the Carbon Black EDR console, you can enable AMSI events in the Event Forwarder by
checking the ingress.event.filelessscriptload option.

See "Configuring the Event Forwarder" in the VMware Carbon Black EDR User Guide.

VMware, Inc. 22
VMware Carbon Black EDR Integration Guide

Sensor Group Settings

In the Carbon Black EDR Console, you can toggle the collection of AMSI events per sensor group.
This is disabled by default.

To enable AMSI events for a sensor group:

1 On the navigation bar, click Sensors.

2 Select the sensor group.

3 In the Event Collection Settings section, select the checkbox for Fileless script loads.

4 Click Save Group.

See also "Sensor Groups" in the VMware Carbon Black EDR User Guide.

VMware, Inc. 23
EMET
4
This topic describes how to integrate a Carbon Black EDR server with the Microsoft Enhanced
Mitigation Experience Toolkit (EMET).

Important Beginning with Windows 10 version 1709 (Fall Creators Update), also known as
Redstone 3, Microsoft replaced EMET with Windows Defender Exploit Guard. Microsoft also
announced that EMET reached end of life on July 31, 2018.

This chapter includes the following topics:

n Overview

n EMET Events

n Enabling and Disabling the EMET Protection Feed

n EMET Status on an Endpoint

n Disabling Sensor EMET Event Reporting

Overview
An endpoint protection application that you might have on endpoints is the Microsoft Enhanced
Mitigation Experience Toolkit (EMET). EMET is designed to detect and protect against common
attack techniques and actions.

Integrating EMET into the Carbon Black EDR environment gives you a single place to go
investigate attacks detected and stopped by EMET, while taking advantage of the additional
visibility provided by Carbon Black EDR.

VMware, Inc. 24
VMware Carbon Black EDR Integration Guide

When EMET events become part of the Carbon Black EDR database, you can search for them,
use them to trigger alerts, and perform process analysis to understand the relationships between
an EMET event and other events on one or more endpoints in your organization, including the
timeline of those relationships. In addition, EMET events can become part of the syslog output
from the Carbon Black EDR server.

Note
n This documentation uses the term “EMET event” to indicate the case where EMET detects an
exploit attempt. It uses the term “EMET configuration” to indicate the protections enabled by
EMET for that process.

n EMET features and terminology are not detailed in this document. If you need more
information about EMET, see the documentation provided by Microsoft.

n Proper functioning of this integration assumes EMET is installed and configured per Microsoft
recommendations. EMET 5.x versions should be compatible.

n Reporting of EMET events to Carbon Black EDR requires that the Windows Event Log be
selected as one of the Reporting options in the EMET interface on the host.

By default, EMET-enabled sensors report EMET events and configuration to the Carbon Black
EDR server. The integration does not require interaction with another server. For any reporting
sensor, this information appears in several places in the Carbon Black EDR console:

n On the Search Processes page , you can search for processes for which an EMET mitigation
occurred and/or processes whose sensor has EMET protection enabled. See “Process Search
and Analysis” in the VMware Carbon Black EDR User Guide.

n On the Process Analysis page, EMET events are displayed and labeled in the table of events,
and the EMET settings specific to the current process on the reporting sensor are included.
See “Process Search and Analysis” in the VMware Carbon Black EDR User Guide.

n On the Sensor Details page, the general EMET configuration (if any) is shown. See “Managing
Sensors” in the VMware Carbon Black EDR User Guide.

To further enhance the EMET integration, you can enable the EMET Protection Feed on the
Threat Intelligence Feeds page (see “Threat Intelligence Feeds” in the VMware Carbon Black
EDR User Guide ). This does not actually enable/disable delivery of events from sensors, but it
does enable you to:

n Create alerts based on EMET events and manage them on the Triage Alerts page.

n Specify delivery of an email alert when an EMET event occurs.

n Include EMET events in the syslog output from your Carbon Black EDR server.

EMET Events
This section describes the places in the Carbon Black EDR console where you can view and
analyze EMET events.

VMware, Inc. 25
VMware Carbon Black EDR Integration Guide

Process Search and Analysis for EMET Events

If you open the Process Analysis page for a process on a host that has EMET protections enabled
for the process, two types of EMET-related information appear. In both cases, the sensor group
for the host must have EMET reporting enabled.

n Process-specific Protections on the Host – The Process Analysis page includes a list of the
EMET Protections Enabled on the host for the process that is being analyzed . These can
appear even if EMET did not perform any mitigations when an exploit was attempted on the
process.

n EMET Mitigation Events – If EMET took mitigation actions related to an exploit of the
process, the event table lists EMET events for these actions, and can be expanded for
additional details.

VMware, Inc. 26
VMware Carbon Black EDR Integration Guide

EMET Configuration Searches

You can search for processes that are on a host that either has or does not have an EMET
configuration related to that process.

You can thereby determine whether a process might have been reported on a system that did
not have endpoint protection enabled. The EMET configuration search option is available on the
Add Criteria menu on the Search Processes page .

For more information on the Search Processes page , see “Process Search and Analysis” in the
VMware Carbon Black EDR User Guide.

This search will help you determine if EMET is installed on a host and help you determine
process-specific protections.

EMET Events and Threat Reports

EMET threat reports are delivered as part of the EMET Protection Feed.

If this feed is enabled, these reports are searchable and processes with an EMET mitigation event
are tagged with “EMET Protection Feed” and get a score of 90. See “Threat Intelligence Feed
Scores” in the VMware Carbon Black EDR User Guide .

To view EMET threat reports:

1 Log into Carbon Black EDR.

2 On the navigation menu, click Threat Intelligence .

3 On the Threat Intelligence Feeds page, scroll to the EMET Protection panel and click the
Threat Reports link.

VMware, Inc. 27
VMware Carbon Black EDR Integration Guide

4 The Search Threat Reports page appears with the results of the EMET reports search (labeled
as cbemet in the Description column).

VMware, Inc. 28
VMware Carbon Black EDR Integration Guide

You can click the Details link for any report in the table to get additional information.

See “Searching for Threat Reports” in the VMware Carbon Black EDR User Guide .

Enabling and Disabling the EMET Protection Feed

The Threat Intelligence Feeds page includes an EMET Protection feed. This feed is disabled by
default.

You can enable it to include EMET event reports with the other reports that are received on the
Carbon Black EDR server. When the EMET Protection is enabled, you can enable the following:

n Carbon Black EDR console alerts based on EMET events

n Delivery of an email alert when an EMET event occurs

n Inclusion of EMET events in the syslog output from the Carbon Black EDR server

For instructions on enabling a feed and configuring its alert and syslog features, see “Enabling,
Disabling, and Configuring a Feed” in the VMware Carbon Black EDR User Guide .

For more information on the Threat Intelligence Feeds page, see “Threat Intelligence Feeds” in
the VMware Carbon Black EDR User Guide .

Note The Carbon Black EDR server receives EMET events regardless of whether the EMET
Protection feed is enabled. EMET event collection can be disabled per-sensor group from the
Group Settings page in the Carbon Black EDR console.

EMET Status on an Endpoint

If EMET is installed on a host that is running a Carbon Black EDR sensor, information about that
host’s EMET configuration is provided to the Carbon Black EDR server.

VMware, Inc. 29
VMware Carbon Black EDR Integration Guide

This information is displayed in the Computer Vitals panel on the Sensor Details page for each
sensor. See “Managing Sensors” in the VMware Carbon Black EDR User Guide .

Hosts without EMET installed do not include the fields for EMET status on their Sensor Details
page. If EMET data is not available, that field will be blank.

VMware, Inc. 30
VMware Carbon Black EDR Integration Guide

The following table shows the EMET-related fields that are included on the Computer Vitals
panel.

Table 4-1. EMET Information on the Sensor Details page

Field Description

EMET Version The EMET toolkit version number.

EMET Exploit Action The EMET configuration for what to do when an exploit attempt occurs:
n Audit -- Do not kill the process, when applicable, but log the exploitation attempt.
n Block -- Terminate the program when an exploitation attempt is detected (“Stop” in the
EMET interface)

EMET Telemetry Path If Local Telemetry mode is enabled on EMET, this field shows the path where Early Warning
information is sent on the local machine. See the Microsoft EMET documentation for the Registry
path for this setting.

EMET Report Identifies which Reporting checkboxes are checked in the EMET interface, which controls where
Settings mitigation events are reported on the local host. Options are one or more of:
n Windows Event Log
n Tray Icon
n Early Warning
In addition, for any active option, there will also be an indication of whether the choice is Locally
or GPO configured.

Note If Windows Event Log is not active, Carbon Black EDR will not received EMET events.

EMET Dump Flags If present, identifies the type of MiniDump file created if the LocalTelemetryPath key is set.

EMET Process Count The number of active processes that have EMET mitigations configured on the host.

Disabling Sensor EMET Event Reporting

By default, sensors on any host with EMET installed will include EMET events in the logs that
reported back to their Carbon Black EDR server. However, you can disable EMET event reporting
for all sensors in a sensor group.

To disable EMET event reporting from a sensor group:

1 Log into Carbon Black EDR.

2 On the navigation menu, click Sensors .

3 On the Sensors page, select the sensor group to disable EMET event reporting.

4 When you have selected the sensor group, click the Edit Settings button to display the Edit
Group Settings page.

5 Click on the Event Collection tab, deselect the EMET events checkbox.

6 Click Save Changes .

EMET event collection will no longer be included in the logs sent to the Carbon Black EDR server.

VMware, Inc. 31
VMware Carbon Black EDR Integration Guide

To re-enable EMET event collection for a sensor group, follow the same procedure but select the
EMET events checkbox before saving the changes.

VMware, Inc. 32
SSO Identity Providers
5
This topic describes supported SAML 2.0 specifications and SAML 2.0 Single Sign-On (SSO)
setup. It also explains how to integrate Carbon Black EDR with the OKTA, Shibboleth, and ADFS
IdPs.

This chapter includes the following topics:

n Overview

n Supported SAML 2.0 Specifications

n SAML 2.0 Single Sign-On Setup

n Integrate OKTA IdP

n Shibboleth IdP

n ADFS IdP

n Troubleshoot SSO Integration

Overview
Single Sign-On (SSO) allows multiple systems (possibly more than one vendor) to share a user
authentication provider.

n Users can maintain a single set of credentials for a variety of services.

n Users need not re-authenticate when switching from one system to another since their initial
login.

n Context is remembered after the initial login.

Carbon Black EDR supports the Security Assertion Markup Language (SAML) 2.0 for SSO
integration. The following sections provide a summary of supported capabilities and the
procedures for configuring and troubleshooting SSO integration with external SAML 2.0-
compliant identity providers (IdPs).

VMware, Inc. 33
VMware Carbon Black EDR Integration Guide

Supported SAML 2.0 Specifications

SAML 2.0 is a relatively flexible and generic specification, which allows it be used in many
different scenarios and use cases. It comes with a certain level of complexity.

The SAML 2.0 specification is described in four documents:

n SAML 2.0 Core – Describes basic SAML assertions and protocols

n SAML 2.0 Bindings – Describes various types of HTTP calls supported by the protocol

n SAML 2.0 Profiles – Describes a set of profiles (use-cases), each one defining a set of calls
made through one of the bindings to exchange SAML messages

n SAML 2.0 Metadata – Describes the format of the metadata XML files that must be
exchanged between identity and service providers in order to establish mutual trust

Carbon Black EDR supports a subset of functionality that is described in these specifications:

n Supported SAML 2.0 Bindings :

n HTTP Redirect Binding – Section 3.4

n HTTP POST Binding – Section 3.5

n Supported SAML 2.0 Profiles:

n Web Browser SSO Profile – Section 4.1

Supported SSO Identity Providers

Carbon Black EDR currently supports three SSO IdPs.

n OKTA

n Shibboleth

n ADFS IdP

Any other IdP that implements the SAML 2.0 specification and supports the bindings and profiles
that are listed here will probably work, but VMware Carbon Black has not validated them and
cannot support their configuration or operation.

SAML 2.0 Single Sign-On Setup

Before establishing a trust relationship between a SAML service provider and an IdP, the two
services must have well-established, cryptographically secure identities. This identity information
must be exchanged so that the service provider (SP) knows who its IdP is and vice versa.

The exchange is performed by having each service generate a metadata XML file that is then
provided to the other service. By default, the identity certificate/private key files used by Carbon
Black EDR (acting as the SAML service provider) is /etc/cb/cert/cb-server.[crt,key]. This
identity is also used for server-sensor authentication and for web user interface HTTPS server
authentication.

VMware, Inc. 34
VMware Carbon Black EDR Integration Guide

You can also configure Carbon Black EDR to use a separate set of certificate/key files for SSO by
updating configuration fields in the SSO configuration file.

Attribute Mapping
With Carbon Black EDR (version 5.2 and later), when SSO is configured, users who are
authenticated by the configured IdP can be automatically provisioned in Carbon Black EDR if they
are authorized and if the IdP returns the user’s first name, last name, and email address as user
attributes.

The fields returned by the IdP are not part of the SAML 2.0 specification and vary between IdPs.
For Carbon Black EDR, the attr_map.py script maps the attributes that are returned by an IdP to
the fields that are required by Carbon Black EDR.

Carbon Black EDR supports the following seven attributes:

Table 5-1. Supported Attributes

Attribute Required Use

username Required The username to log in as.

authorized Optional (but strongly Required to authorize access.

recommended) Boolean.
“True” if this user is authorized access to the Carbon Black EDR server.

first_name Optional Required to provision a new user.

last_name Optional Required to provision a new user.

email Optional Required to provision a new user.

builtin_roles Optional Required to set permissions. A list of roles.

Valid roles: “GlobalAdmin”
If None, this field is ignored.
If an empty list ([]), all roles are removed.

teams Optional Required to set permissions.

A list of teams this in which the user is a member.
Names must match an existing configured team.
If None, this field is ignored.
If an empty list ([]), all team associations are removed.

Your IdP administrator is responsible for providing you a list of attributes that are returned by the
IdP. The username, first_name, last_name and email should map directly to the fields returned by
your IdP. You must configure the authorized, builtin_roles, and teams fields, based on your
business policies.

The following diagram describes the attribute mapping process:

VMware, Inc. 35
VMware Carbon Black EDR Integration Guide

Example Attribute Mapping Script

This section provides an example attribute mapping script for Carbon Black EDR only; this section
does not apply to VMware Carbon Black Hosted EDR.

The attribute mapping is contained in a user-defined Python script.

def callback(saml_response, db_session, logger, sso_config):

"""
Takes a SAML Response object and returns a dictionary
of fields. This is a default implementation, it is
expected to be overridden by a user in the SSO config.

This instance will return empty values for all fields so

behavior maintains backwards compatibility with
existing SSO configurations.
"""
logger.debug("Default SAML attribute map, user authorized, not parsing attributes in SAML
Response.")
result = {}
result["authorized"] = True
result["username"] = None
result["first_name"] = None
result["last_name"] = None
result["email"] = None
result["builtin_roles"] = None
result["teams"] = None

return result

The default callback returns authorized = True and None for all attributes. This keeps behavior
consistent with the current SSO implementation. An example script for a fully featured install is
included in /etc/cb/sso/ together with the example config file:

def callback(saml_response, db_session, logger, sso_config):

result = {}
attrs = saml_response.attrs

result["authorized"] = True if "cbserver" in attrs

VMware, Inc. 36
VMware Carbon Black EDR Integration Guide

["groups"] else False

result["username"] = attrs["uid"][0] if "uid" in attrs

else None
result["first_name"] = attrs["givenName"][0] if
"givenName" in attrs else None
result["last_name"] = attrs["sn"][0] if "sn" in
attrs else None
result["email"] = attrs["mail"][0] if "mail" in
attrs else None

if "cbserver-owners" in attrs["groups"]:
result["builtin_roles"] = ["global_admin",]
result["teams"] = None
else:
result["builtin_roles"] = []
result["teams"] = None

return result

In the example above, the IdP returns the following fields:

n username – The user’s login ID.

n givenName – The user's first name.

n sn – The user's last name (surname).

n mail – The user’s email address.

n groups – A list of relevant group memberships.

The example uses the resource parameter to determine group membership.

Two group names are defined by this IdP:

n cbserver

n cbserver-owners

A user must be a member of cbserver to have access to the Carbon Black EDR server. Any user
part of cbserver-owners is granted global admin and is included in the administrators group.

The following is example debug output of a user being authenticated, authorized, created, added
to global admins and the administrators team.

15:08:06.799 api_routes_saml.py(214): <DEBUG> Attributes returned in SAML response:

15:08:06.800 api_routes_saml.py(216): <DEBUG> mail: ['[email protected]']
15:08:06.801 api_routes_saml.py(216): <DEBUG> givenName: ['Bill']
15:08:06.801 api_routes_saml.py(216): <DEBUG> groups: ['cbserver-owners', 'cbserver']
15:08:06.801 api_routes_saml.py(216): <DEBUG> uid: ['bill']
15:08:06.801 api_routes_saml.py(216): <DEBUG> sn: ['Smith']
15:08:06.801 api_routes_saml.py(218): <DEBUG> Custom SAML attribute map returned:
15:08:06.802 api_routes_saml.py(220): <DEBUG> username: bill
15:08:06.802 api_routes_saml.py(220): <DEBUG> first_name: Bill
15:08:06.802 api_routes_saml.py(220): <DEBUG> last_name: Smith
15:08:06.802 api_routes_saml.py(220): <DEBUG> builtin_roles: ['global_admin']

VMware, Inc. 37
VMware Carbon Black EDR Integration Guide

15:08:06.802 api_routes_saml.py(220): <DEBUG> teams: ['Administrators']

15:08:06.803 api_routes_saml.py(220): <DEBUG> authorized: True
15:08:06.803 api_routes_saml.py(220): <DEBUG> email: [email protected]
15:08:06.806 api_routes_saml.py(242): <WARNING> bill authenticated and authorized, but not found in
user database. Creating user.
15:08:06.812 api_routes_saml.py(261): <DEBUG> Updating bill to Global Admin role.
15:08:06.814 api_routes_saml.py(269): <DEBUG> Updating team membership for bill to [{'id': 1,

Integrate OKTA IdP

This section describes how to integrate the OKTA IdP with Carbon Black EDR.

To integrate the OKTA IdP:

1 Acquire metadata XML from the OKTA IdP and place it in the /etc/cb/sso directory on the
Carbon Black EDR server host. (You are not required to use this directory, but it is a good
default location.)

2 On the Carbon Black EDR server, navigate to /etc/cb/sso and:

a Copy /etc/cb/sso/sso.conf.example.okta to /etc/cb/sso/sso.conf.

b Copy attr_map.py.example.okta to attr_map.py.

c Make appropriate changes to the attr_map.py file based on the attributes returned from
Okta. Each configurable property is accompanied with additional inline documentation in
the attr_map.py file to assist with this process.

3 Review and edit the /etc/cb/sso/sso.conf file as described here.

Caution The syntax of the sso.conf configuration file must fully conform to the JSON data-
interchange format. Failure to do so can create an invalid configuration file, which prevents
the services from launching properly. When changes are made to this file and cb-enterprise is
restarted, check /var/log/cb/coreservices/debug.log to make sure there are no errors.

If an administrator configures the Single Logout (SLO) service in both the IdP Service and
Endpoint sections and a user logs out of the Carbon Black EDR server, the user is also logged
out of the Okta application. This effectively logs the user out of all Okta applications.

a Specify the file path to the location of the metadata XML from the OKTA IdP. For
example:

"metadata": {
"local": [
"<file path to location of IdP XML>"
]
},

b Make sure the attribute_mapper field has the path to the Python Mapper file:

"attribute_mapper": "/etc/cb/sso/attr_map.py",

c Change the accepted_time_diff field if needed:

VMware, Inc. 38
VMware Carbon Black EDR Integration Guide

"accepted_time_diff": 600,

d Update the service / sp / idp section with the appropriate appid from the OKTA IdP. For
example:

"service": {
"sp": {
"nameid_format": "urn:oid:1.3.6.1.4.1.1466.115.121.1.15-NameID",
"idp": {
"http://www.okta.com/<appid>": {

e Update the single_sign_on_service and single_logout_service sections with the

appropriate name and appid from the OKTA IdP For example:

# URLs in this section MUST be updated to match the URLs defined by the
# IdP you are integrating with
"single_sign_on_service": {
"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect": "https://fakeidp.okta.com/app/<name>/
<appid>/sso/saml"
},

"single_logout_service": {
"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect": "https://fakeidp.okta.com/app/<name>/
<appid>"
}

f In the endpoints section, update the assertion_consumer_service and single_logout_service

fields with the appropriate IP address of FQDN of Carbon Black EDR. For example:

"endpoints": {
"assertion_consumer_service": {
"https://<IP Address or FQDN of the CB Server>/api/saml/
assertion":"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
},
"single_logout_service": {
"https://<IP Address or FQDN of the EDR Server>/api/saml/
logout": "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
}
},

g Update the entityid field with the appropriate IP address or FQDN of the Carbon Black
EDR server. For example:

"entityid": "https://<IP Address or FQDN of the EDR Server>/",

h Search the sso.conf file for “TODO” and ensure that all “TODO” tasks are completed.

VMware, Inc. 39
VMware Carbon Black EDR Integration Guide

4 Open the /etc/cb/cb.conf file and edit the SSOConfig property so that it contains the full path
to the SSO configuration file that was previously created. This single property defines
whether Carbon Black EDR server will be started in standalone vs. federated authentication
mode.

Note To deactivate SSO integration, comment out the SSOConfig property.

5 Generate Carbon Black EDR’s SSO service provider metadata XML file by issuing this
command:

/usr/share/cb/cbssl sso --make-metadata > /<your file path>

6 Give the XML file to the IdP to complete the trust.

7 Restart the Carbon Black EDR server by issuing this command:

sudo service cb-enterprise restart

Shibboleth IdP
This section describes how to integrate the Shibboleth IdP with Carbon Black EDR.

To integrate the Shibboleth IdP:

1 Acquire metadata XML from the Shibboleth IdP and place it in the /etc/cb/sso directory on
the Carbon Black EDR server host. (You are not required to use this directory, but it is a good
default location.)

2 On the Carbon Black EDR server, navigate to /etc/cb/sso and:

a Copy /etc/cb/sso/sso.conf.example.shib to /etc/cb/sso/sso.conf .

b Copy attr_map.py.example.shib to attr_map.py .

Note Make appropriate changes to the attr_map.py file based on the attributes returned
from Shibboleth. Each configurable property is accompanied with additional inline
documentation in the attr_map.py file to assist with this process.

VMware, Inc. 40
VMware Carbon Black EDR Integration Guide

3 In the /etc/cb/sso/sso.conf file:

Caution The syntax of this configuration file must fully conform to the JSON data-
interchange format. Failure to do so can create an invalid configuration file, which will prevent
the cb-coreservices services from launching properly. When changes are made to this file
and cb-enterprise is restarted, check /var/log/cb/coreservices/debug.log to for errors.

a Specify the file path to the location of the metadata XML from the Shibboleth IdP. For
example:

"metadata": {
"local": [
"<file path to location of IdP XML>"
]
},

b Make sure the attribute_mapper field has the path to the Python Mapper file:

"attribute_mapper": "/etc/cb/sso/attr_map.py",

c Change the accepted_time_diff field if needed:

"accepted_time_diff": 600,

d Update the service / sp / idp section with the Shibboleth IdP. For example:

"service": {
"sp": {
"idp": {
# EntityId of the IDP
"https://fakeipd.example.com": {

e Update the single_sign_on_service and single_logout_service sections with the

appropriate name and appid from the Shibboleth IdP. For example:

# URLs in this section MUST be updated to match the URLs defined # by the IdP you are
integrating with
"single_sign_on_service": {
"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect": "https://fakeipd.example.com/
saml2/idp/SSOService"
},
"single_logout_service": {
"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect": "https://fakeipd.example.com/
saml2/idp/SingleLogoutService"
}

f In the endpoints section, update the assertion_consumer_service and single_logout_service

fields with the appropriate IP address of FQDN of Carbon Black EDR. For example:

"endpoints": {
"assertion_consumer_service": {
"https://<IP Address or FQDN of the EDR Server>/api/saml/
assertion":"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"

VMware, Inc. 41
VMware Carbon Black EDR Integration Guide

},
"single_logout_service": {
"https://<IP Address or FQDN of the EDR Server>/api/saml/
logout": "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
}
},

g Update the entityid field with the appropriate IP address or FQDN of the Carbon Black
EDR server. For example:

"entityid": "https://<IP Address or FQDN of the EDR server>/",

h Search the sso.conf file for “TODO” and ensure that all “TODO” tasks are also
completed.

4 Open the /etc/cb/cb.conf file and edit the SSOConfig property so that it contains the full path
to the SSO configuration file created in the previous steps. This single property idefines
whether Carbon Black EDR server will be started in standalone vs. federated authentication
mode.

Note To deactivate SSO integration, comment out the SSOConfig property.

5 Generate Carbon Black EDR server’s SSO service provider metadata XML file by issuing this
command:

/usr/share/cb/cbssl sso --make-metadata > /<your file path>

6 After this file is created, you must give it to the identity provider to complete the trust.

7 Restart the Carbon Black EDR server by issuing the following command:

sudo service cb-enterprise restart

ADFS IdP
This section describes how to integrate the ADFS IdP with Carbon Black EDR.

To configure ADFS, see your Microsoft documentation.

To integrate ADFS IdP:

1 Acquire metadata XML from the ADFS IdP and place it in the /etc/cb/sso directory on the
Carbon Black EDR server host. (You are not required to use this directory, but it is a good
default location.)

2 On the Carbon Black EDR server, navigate to /etc/cb/sso and:

a Copy /etc/cb/sso/sso.conf.example.adfs to /etc/cb/sso/sso.conf .

VMware, Inc. 42
VMware Carbon Black EDR Integration Guide

b Copy attr_map.py.example.adfs to attr_map.py .

Note Make appropriate changes to the attr_map.py file based on the attributes that are
returned from ADFS. Each configurable property is accompanied with inline documentation in
the attr_map.py file to assist with this process.

3 In the /etc/cb/sso/sso.conf file:

Caution The syntax of this configuration file must fully conform to the JSON data-
interchange format. Failure to do so can create an invalid configuration file, which prevents
the cb-coreservices services from launching properly. When changes are made to this file and
cb-enterprise is restarted, check / var/log/cb/coreservices/debug.log to make sure that
there are no errors.

a Specify the file path to the location of the metadata XML from the ADFS IdP. For example:

"metadata": {
"local": [
"<file path to location of IdP XML>"
]
},

b Make sure the attribute_mapper field has the path to the Python Mapper file:

"attribute_mapper": "/etc/cb/sso/attr_map.py",

c Change the accepted_time_diff field if needed:

"accepted_time_diff": 600,

d Update the service / sp / idp section with the appropriate appid from the ADFS IdP. For
example:

"service": {
"sp": {
"idp": {
# EntityId of the IDP
"https://fakeipd.example.com": {

e Update the single_sign_on_service and single_logout_service sections with the

appropriate name and appid from the ADFS IdP For example:

# URLs in this section MUST be updated to match the URLs defined

# by the IdP you are integrating with
"single_sign_on_service": {
"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect": "https://fakeipd.adfs.com/adfs/ls/"
},

"single_logout_service": {
"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect": "https://fakeipd.adfs.com/adfs/ls/?
wa=wsignout1.0"
}

VMware, Inc. 43
VMware Carbon Black EDR Integration Guide

f In the endpoints section, update the assertion_consumer_service and single_logout_service

fields with the appropriate IP address of FQDN of Carbon Black EDR. For example:

"endpoints": {
"assertion_consumer_service": {
"https://<IP Address or FQDN of the EDR Server>/api/saml/
assertion":"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
},
"single_logout_service": {
"https://<IP Address or FQDN of the EDR Server>/api/saml/
logout": "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
}
},

g Update the entityid field with the appropriate IP address or FQDN of the Carbon Black
EDR server. For example:

"entityid": "https://<IP Address or FQDN of the EDR Server>/",

h Search the sso.conf file for “TODO” and ensure that all “TODO” tasks are also
completed.

4 Open the /etc/cb/cb.conf file and edit the SSOConfig property so that it contains the full path
to the SSO configuration file created in the previous steps. This single property defines
whether Carbon Black EDR server will be started in standalone vs. federated authentication
mode.

Note To deactivate SSO integration, comment out the SSOConfig property.

5 Generate the Carbon Black EDR server’s SSO service provider metadata XML file by issuing
this command:

/usr/share/cb/cbssl sso --make-metadata > /<your file path>

6 Give the file to the IdP to complete the trust.

7 Restart the Carbon Black EDR server by issuing this command:

sudo service cb-enterprise restart

Troubleshoot SSO Integration

If SSO does not function as expected, review the log file that is located at /var/log/cb/
coreservices/debug.log.

You can also inspect the actual SAML requests being sent and the responses being received by
increasing the logging level of the cb.flask.blueprints.api_routes_saml and saml2 modules.

To increase the logging level of cb.flask.blueprints.api_routes_saml and saml2 modules:

1 Open the /etc/cb/coreservices-logger.conf file.

VMware, Inc. 44
VMware Carbon Black EDR Integration Guide

2 Append cb.flask.blueprints.api_routes_saml and saml2 to the list of keys under the

[loggers] section.

[loggers] section example:

keys=root, gunicorn.access, cb.flask.blueprints.api_routes_saml, saml2

3 Paste the following below the [loggers] section in the coreservices-logger.conf file:

[logger_cb.flask.blueprints.api_routes_saml]

level=DEBUG

handlers=debug_syslog

qualname=cb.flask.blueprints.api_routes_saml

propagate=1

4 Paste the following below the [loggers] section in the coreservices-logger.conf file:

[logger_saml2]

level=DEBUG

handlers=debug_syslog

propagate=0

qualname=saml2

VMware, Inc. 45
Third-Party Authentication
6
Using the Duo plugin, you can configure two-factor authentication and download the Duo Mobile
application on a mobile device.

This chapter includes the following topics:

n Overview

n Set Up Duo Administrator Unix Application Account

n Configure Duo Plugin

n Enable Two-Factor Authentication

Overview
Duo two-factor authentication adds a second authentication factor to your server and facilitates
authentication management and security monitoring.

You can add several device types for two-factor authentication, including mobile phone devices,
tablets, and landlines. For information on how to add these devices using Duo Mobile, see Duo’s
product documentation at https://duo.com.

Set Up Duo Administrator Unix Application Account

The Carbon Black EDR server administrator must create a Unix application account to integrate
with Carbon Black EDR.

To set up a Duo Administrator Unix application account:

1 Go to https://duo.com.

2 Click Sign Up in the top-right corner of this page and follow the prompts to create an account
and activate the Duo Mobile application on your preferred device.

Note If you already have a Duo Mobile account, you can use this. You do not have to create
a new account for the Carbon Black EDR-Duo plugin.

3 When your account is active and you have activated the Duo Mobile application on your
device, log in with your account at https://duo.com .

4 Select Applications in the left panel.

VMware, Inc. 46
VMware Carbon Black EDR Integration Guide

5 Click Protect an Application .

6 Scroll down to locate the Unix Application selection and click the Protect this Application
blue link.

7 Scroll to the Settings > General panel.

8 In the Name field, enter a name for the Unix application, such as "Carbon Black EDR Server".

9 For Username normalization , select the choice that best represents your security posture.
This setting is related to the field specified in the /usr/share/cb/plugins/duo/secrets.ini
settings file for mapping Carbon Black EDR users to Duo users. See Map Carbon Black EDR
Users to Duo Users.

If the Duo Mobile application is setup for Simple normalization of the username, and Carbon
Black EDR-Duo integration is configured for email, then only the name in the Carbon Black
EDR user email field (the value before the “@” symbol) is used to match the Duo user.

If password is setup for None and Carbon Black EDR-Duo integration is configured for email
or username, then the entire string must match a Duo user account.

10 Click Save Changes .

Configure Duo Plugin

To configure the Duo plugin and enable communication of the Duo plugin through an Internet
proxy, edit the settings file.

/usr/share/cb/plugins/duo/secrets.ini

To configure the Duo plugin:

Enter values for the following Duo plug settings. These values are specific to the administrator’s
Duo Mobile application configuration, which is available on the Duo Admin Portal. For more
information on using the Duo Admin Portal, see https://duo.com/docs/administration.

n ikey

n skey

n host

To enable communication of the Duo plugin through an Internet proxy:

Enter values for the following Internet proxy settings:

n hostname

n port

n username

n password

The Duo plugin supports the basic_auth username/password proxy authentication.

VMware, Inc. 47
VMware Carbon Black EDR Integration Guide

Map Carbon Black EDR Users to Duo Users

This mapping specifies the data in the Carbon Black EDR user account that is sent as the
username to the Duo authorization server.

Refer to the following section in the secrets.ini settings file (see secrets.ini Settings File):

# how to map EDR users to Duo users? Choices are “username” or “email”. Default to
“email”

duo_mapping=email

This specifies the data in the Carbon Black EDR user account that will be sent as the username to
the Duo authorization server.

secrets.ini Settings File

This section displays the secrets.ini settings file for your reference.

# Secret keys for your Duo security integration. Get your ikey, skey, and host from your Duo
# Security administrative console.

[duo]
ikey=
skey=
host=

[config]
# number of seconds a "session" should last until 2fa is required again. Default to 60
session_lifetime=500

# how to map EDR users to Duo users? Choices are "username" or "email". Default to "email"
duo_mapping=email

# create a new 2fa session for each source IP address? True or false. Default to "false"
use_ipaddr_session_key=false

# Uncomment the next section if you need a web proxy to reach the outside world

#[proxy]
#hostname=
#port=
#
## if the proxy requires authentication, put the username & password here
#username=
#password=

Enable Two-Factor Authentication

This section describes how to enable two-factor authentication on your Carbon Black EDR server.

1 Search for the following section in the cb.conf configuration file:

VMware, Inc. 48
VMware Carbon Black EDR Integration Guide

# Two factor authentication plugin path

#TwoFactorAuthCallbackModulePath=/usr/share/cb/plugins/duo/
duo_2fa_auth_callback.py

For more information, see the VMware Carbon Black EDR Server Configuration (cb.conf)
Guide.

2 Uncomment the TwoFactorAuthCallbackModulePath setting in the cb.conf configuration file as

follows:

# Two factor authentication plugin path

TwoFactorAuthCallbackModulePath=/usr/share/cb/plugins/duo/
duo_2fa_auth_callback.py

VMware, Inc. 49
Syslog
7
This topic describes Syslog output for Carbon Black EDR events.

It provides descriptions and examples of the output, and explains how you can use Syslog output
for notification of alerts.

This chapter includes the following topics:

n Overview of Logging

n Syslog Format

n Syslog Integration

n Syslog Templates

n Syslog Common Event Format

Overview of Logging
Carbon Black EDR logs events to Syslog.

n Notification logs – for watchlist and feed hits, and binary information events

n Audit logs – for banning, isolation, and Live Response sessions

With audit logging enabled, audit logs include all user API activity, including HTTP request
details. See Audit Logs.

See the VMware Carbon Black EDR Server/Cluster Management Guide for information about all
Carbon Black EDR server logs.

Notification Logs
Carbon Black EDR logs the following events to Syslog.

n Watchlist hit – This event occurs when activity or binaries on an endpoint matches a query in
a watchlist. See “Watchlists” in the VMware Carbon Black EDR User Guide .

n Feed hit – This event occurs when activity or binaries on an endpoint matches an IOC
reported by a threat intelligence feed. See “Threat Intelligence Feeds” in the VMware Carbon
Black EDR User Guide .

VMware, Inc. 50
VMware Carbon Black EDR Integration Guide

By default, a feed hit is logged only at the ingress as feed events arrive at the Carbon Black
EDR server. These are feed.ingress.hit events.

Optionally (when enabled via the EnableSolrFeedNotifications configuration option

in /etc/cb/cb.conf ), the feed hit is also logged when committed to persistent storage. In the
latter case, the notification can contain additional key-value pairs in the binary or process hit.
These are feed.storage.hit events.

n Binary information event – This event occurs when a process execution adds a binary to the
Carbon Black EDR database.

The program name prefix for logged events is cb-notifications- . By default, logged events are
written to log files at /var/log/cb/notifications on the Carbon Black EDR server (based on the
syslog configuration at /etc/rsyslog.d/cb-coreservices ).

Note Currently, binary information events are not published in the cb-all-notifications.log
file.

In the /var/log/cb/notifications directory, there is one file for all hits, one file for each watchlist,
and one file for each feed. Watchlist files include the watchlist ID in the program name and in the
log file name, while feed files include the feed ID in the program name and in the log file name.
Binary information events are logged in a separate file.

For example, the /var/log/cb/notifications directory listing below contains log files for the
following events:

n All watchlist and feed hits

n Hits to Watchlist ID 10

n Hits to Feed ID 8

n All binary information events

[root@localhost coreservices]# ll /var/log/cb/notifications/*.log

-rw-------. Jun 9 15:30 /var/log/cb/notifications/cb-all-notifications.log

-rw-------. Jun 9 15:30 /var/log/cb/notifications/cb-notifications-watchlist-10.log

-rw-------. Jun 9 18:02 /var/log/cb/notifications/cb-notifications-feed-8.log

-rw-------. Jun 9 18:04 /var/log/cb/notifications/cb-notifications-binaryinfo.log

Audit Logs
Carbon Black EDR audit logs are located in /var/log/cb/audit , and are available through Syslog.

They include the following files:

n banning.log – hash banning activity (add, remove, toggle).

n isolation.log – sensor isolation activity (enable and disable).

VMware, Inc. 51
VMware Carbon Black EDR Integration Guide

n live-response.log – endpoint Live Response session activity such as cd , exec , reg , and so
on; does not include commands that are not part of an endpoint session, such as sensor and
help.

n useractivity.log (audit logging enabled only) – all user API activity, including HTTP request
details.

You can enable audit logging with the EnableExtendedApiAuditLogging=True parameter

in /etc/cb/cb.conf . See the VMware Carbon Black EDR Server Configuration Guide
(cb.conf) .

Syslog Format
Each watchlist and feed hit consists of a series of key-value pairs.

This section provides the following information about the different key-value pairs for watchlist
and feed hits:

n Examples of key-value pairs in the different types of hit

n The default process template used to create the key-value pairs for the hit

n Descriptions of the key-value pairs for the different types of hit

Note To improve readability in the examples, line breaks appear between fields. In the template
files, however, fields are separated by spaces.

Watchlist Hit on Process

This section describes the process watchlist hit.

Process Watchlist – Example

Mar 13 10:00:09 [1037] <warning> reason=watchlist.hit type=event

process_guid=00000c42-0000-172c-01d0-5d6cca2adbb2 segment_id=1488563344023 host='WORKSTATION-8LT'
sensor_id=4322 watchlist_id=3 watchlist_name='Netconns to .cn or .ru' timestamp='1426255209.17'
start_time='2014-11-13T09:05:02.34Z' group='Default Group'
process_md5='b9d6d7e6e5c4fcd8dd7f88ec9d563085'
process_sha256=’A31C76B026966D8A01BB929402B17A5C0B35037CF53908770D7F3D1F28F6A7BD’
process_name='chrome.exe' process_path='c:\program files (x86)\google\chrome\application\chrome.exe'
last_update='2014-11-13T13:49:39.361Z'

Process Watchlist – Default Template

reason=watchlist.hit type=event
process_guid={{doc['id']}}
segment_id={{doc["segment_id"]}}
host='{{doc['hostname']}}'
comms_ip='{{doc['comms_ip']}}'
interface_ip='{{doc['interface_ip']}}'
sensor_id={{doc['sensor_id']}}
watchlist_id={{doc['watchlist_id']}}
watchlist_name='{{doc['watchlist_name']}}'

VMware, Inc. 52
VMware Carbon Black EDR Integration Guide

timestamp='{{doc['event_timestamp']}}'
start_time='{{doc['start']}}'
group='{{doc['group']}}'
process_md5='{{doc['process_md5']}}'
process_sha256='{{doc['process_sha256']}}'
process_name='{{doc['process_name']}}'
process_path='{{doc['path']}}'
last_update='{{doc['last_update']}}'
{% for k in doc %}{% if k.startswith("alliance_") %}
{{k}}='{{doc[k]}}'{% endif %}{% endfor %}

Process Watchlist – Key-Value Pairs

Syslog Label Solr Doc Reference Description

reason No doc reference Text that describes the entry. The reason label is hard-coded in the syslog
template and identifies the type of the event as "watchlist.hit," "feed.hit," or
"binaryinfo."

type No doc reference Text that identifies the type of data that is returned with the event. For
example:
n event (process events)
n module (binary modules)
n host (host-level information only)

process_guid id Process doc identifier.

segment_id segment_id Process doc segment identifier.

host hostname Hostname of the computer on which the process executed.

comms_ip comms_ip IP address from which Carbon Black EDR received the event (which could be a
NAT or proxy address, if one is configured for the computer on which the
process executed; otherwise this is the same as interface_ip).

interface_ip Interface_ip IP address of the computer on which the process executed.

sensor_id sensor_id Sensor ID of the computer on which the process executed.

watchlist_id watchlist_id The ID of the watchlist that matched the hit criteria (-1 is the internal syslog test
watchlist ID. When you use the cbsyslog command line tool to test the output of
your custom template, -1 is hard-coded to be the watchlist_id attribute, and is
displayed in place of the actual watchlist_id when you run the test.)

watchlist_name watchlist_name Name of the watchlist that matched the hit criteria.

timestamp event_timestamp Epoch time of the watchlist hit event.

start_time start Start time of this process, in the computer’s local time.

group group Sensor group to which this sensor was assigned at the time of process
execution.

process_md5 process_md5 MD5 hash value of the executable backing this process.

process_sha256 process_sha256 SHA-256 hash value of the executable backing this process.

process_name process_name Filename of the executable backing this process.

process_path path Full path to the executable backing this process.

VMware, Inc. 53
VMware Carbon Black EDR Integration Guide

Syslog Label Solr Doc Reference Description

last_update last_update Last activity in this process, in the computer’s local time.

for/if loops alliance_* ioc_attr n alliance_* identifies and prints all attributes whose names start with
"alliance_" in all documents that contain feed hits, including documents
reported by watchlist hits. These attributes represent feed hits.
n ioc_attr identifies and prints additional attributes on IOC values that were
matched.

Note for/if loops are not required. They report attributes that do not have
predefined sets. You can create customized templates that do not contain them
if you do not need to report on alliance_* or ioc_attr attributes.

Watchlist Hit on Binary

This section describes the binary watchlist hit.

Binary Watchlist – Example

Mar 13 03:50:19 [1037] <warning> reason=watchlist.hit type=module

md5=7931ADC31F0180855E05D6666630B3A3 host=WORKSTATION-2'
sha256=F6F9A4834AFE57EBC0B77CF1E83F0C24B298C2FCBBF214CF6CC4DBD24E8BFB4B
sensor_id=74 watchlist_id=8 watchlist_name='Newly Loaded Modules' timestamp='1426233008.59'
first_seen='2014-11-13T07:47:17.862Z' group=['Default Group'] desc='AntiMalware Definition Update'
company_name='Microsoft Corporation' product_name='Microsoft Malware Protection'
product_version='1.193.2512.0' file_version='1.193.2512.0' signed='Signed'

Binary Watchlist – Default Template

reason=watchlist.hit type=module
md5={{doc["md5"]}}
sha256={{doc["sha256"]}}
host=’{{doc.get(’hostname’)}}’
sensor_id={{doc.get(’sensor_id’)}}
watchlist_id={{doc[’watchlist_id’]}}
watchlist_name=’{{doc[’watchlist_name’]}}’
timestamp=’{{doc[’event_timestamp’]}}’
first_seen=’{{doc["server_added_timestamp"]}}’
group={{doc["group"]}}
desc=’{{doc["file_desc"]}}’ company_name=’{{doc["company_name"]}}’
product_name=’{{doc["product_name"]}}’
product_version=’{{doc["product_version"]}}’
file_version=’{{doc["file_version"]}}’
signed=’{{doc["signed"]}}’
{% for k in doc %}{% ifk.startswith("alliance_") %}
{{k}}=’{{doc[k]}}’{% endif %}{% endfor %}

Binary Watchlist – Key-Value Pairs

VMware, Inc. 54
VMware Carbon Black EDR Integration Guide

Syslog Label Solr Doc Reference Description

reason No doc reference Text that describes the entry. The reason label is hard-coded in the syslog
template and identifies the type of the event as "watchlist.hit," "feed.hit,"
or "binaryinfo."

type No doc reference Text that identifies the type of data that is returned with the event. For
binary modules, the value is module .

md5 md5 MD5 hash value of a process, a parent process, a child process, a loaded
module or a written file.

sha256 sha256 SHA-256 hash value of a process, a parent process, a child process, a
loaded module or a written file.

host hostname Hostname of the computer on which the binary was observed.

sensor_id sensor_id Sensor ID of the computer on which the binary was observed.

watchlist_id watchlist_id The ID of the watchlist that matched the hit criteria (-1 is the internal syslog
test).

watchlist_name watchlist_name Name of the watchlist that matched the hit criteria.

timestamp event_timestamp Epoch time of the watchlist hit event.

first_seen server_added_ Time that this binary was first seen by the Carbon Black EDR server.
timestamp

group group First sensor group in which this binary was observed.

desc file_desc File description string from the class FileVersionInfo.

company_name company_name Company name string from the class FileVersionInfo.

product_name product_name Product name string from the class FileVersionInfo.

product_version product_version Product version string from the class FileVersionInfo.

file_version file_version File version string from the class FileVersionInfo.

signed signed Digital signature status of the binary.

for/if loops _* ioc_attr n alliance_* identifies and prints all attributes whose names start with
"alliance_" in all documents that contain feed hits, including documents
reported by watchlist hits. These attributes represent feed hits.
n ioc_attr identifies and prints additional attributes on IOC values that
were matched.

Note for/if loops are not required. Their purpose is to report attributes
that do not have predefined sets. You can create customized templates
that do not contain them if you do not need to report on alliance_* or
ioc_attr attributes.

Feed Hit on Process Ingress

This section describes the process ingress feed hit.

VMware, Inc. 55
VMware Carbon Black EDR Integration Guide

Process Ingress – Example

Aug 12 14:24:19 [26070] <warning> reason=feed.ingress.hit type=event process_guid=00000001-0000-

de04-01cf-b65a8ecb26cf host=’SERV12R2X64-01’ sensor_id=1 feed_id=10 feed_name=’tor’ ioc_type=’ipv4’
ioc_value=’38.229.70.52’ direction=’Outbound’ protocol=’TCP’ port=’22’ timestamp=’1407867859.64’

Process Ingress – Default Template

reason=feed.ingress.hit type=event
process_guid={{doc[’process_id’]}}
host=’{{doc[’hostname’]}}’
sensor_id={{doc[’sensor_id’]}}
feed_id={{doc[’feed_id’]}}
feed_name=’{{doc[’feed_name’]}}’
ioc_type=’{{doc[’ioc_type’]}}’
ioc_value=’{{doc[’ioc_value’]}}’
{% for k in doc[’ioc_attr’] %}
{{k}}=’{{doc[’ioc_attr’][k]}}’{% endfor %}
timestamp=’{{doc[’event_timestamp’]}}’

Process Ingress – Key-Value Pairs

Syslog Label Solr Doc Reference Description

reason no doc reference Text that describes the entry. The reason label is hard-coded in the syslog
template and identifies the type of the event as "watchlist.hit," "feed.hit," or
"binaryinfo."

type no doc reference Text that identifies the type of data that is returned with the event. For process
events, the value is ‘event’.

process_guid process_id Process doc identifier.

host hostname Hostname of the computer on which the feed hit was detected.

sensor_id sensor_id Sensor ID of endpoint that observed the feed hit.

feed_id feed_id ID of the feed that matched the hit criteria.

feed_name feed_name Name of the feed that matched the hit criteria.

ioc_type ioc_type Type of the IOC that caused the hit.

ioc_value ioc_value Value of the IOC that matched the hit criteria.

for/if loops _* ioc_attr n alliance_* identifies and prints all attributes whose names start with "alliance_"
in all documents that contain feed hits, including documents reported by
watchlist hits. These attributes represent feed hits.
n ioc_attr identifies and prints additional attributes on IOC values that were
matched.

Note for/if loops are not required. Their purpose is to report attributes that do not
have predefined sets. You can create customized templates that do not contain
them if you do not need to report on alliance_* or ioc_attr attributes.

timestamp event_timestamp Epoch time (seconds since 00:00:00 on 1 January 1970) of the feed hit event.

VMware, Inc. 56
VMware Carbon Black EDR Integration Guide

Feed Hit on Process Storage

This section describes the process storage feed hit.

Process Storage Feed Hit – Example

Aug 12 14:26:10 [26070] <warning> reason=feed.storage.hit type=event process_guid=00000001-0000-

de04-01cf-b65a8ecb26cf segment_id=1488563344023 host=’SERV12R2X64-01’ sensor_id=1 feed_id=10
feed_name=’tor’ ioc_type=’ipv4’ ioc_value=’38.229.70.52’ direction=’Outbound’ protocol=’TCP’
port=’22’ timestamp=’1407867970.49’ start_time=’2014-08-12T18:23:47.602Z’ group=’Default Group’
process_md5=’a3ccfd0aa0b17fd23aa9fd0d84b86c05’
process_sha256=’7AFB56DD48565C3C9804F683C80EF47E5333F847F2D3211EC11ED13AD36061E1’
process_name=’putty.exe’ process_path=’c:\users\ssmith\desktop\putty.exe’
last_update=’2014-08-12T18:23:55.415Z’ alliance_link_tor=’http://www.torproject.org’
alliance_score_tor=’0’ alliance_updated_tor=’2014-05-06T17:15:23.000Z’ alliance_data_tor=’TOR-
Node-38.229.70.52’

Process Storage Feed Hit – Default Template

reason=feed.storage.hit type=event
process_guid={{doc['process_id']}
segment_id={{doc['segment_id']}}
host='{{doc['hostname']}}'
comms_ip='{{doc['comms_ip']}}'
interface_ip='{{doc['interface_ip']}}'
sensor_id={{doc['sensor_id']}}
feed_id={{doc['feed_id']}}
feed_name='{{doc['feed_name']}}'
ioc_type='{{doc['ioc_type']}}'
ioc_value='{{doc['ioc_value']}}'
{% for k in doc['ioc_attr'] %}
{{k}}='{{doc['ioc_attr'][k]}}'{% endfor %}
timestamp='{{doc['event_timestamp']}}'
start_time='{{doc['start']}}'
group='{{doc['group']}}'
process_md5='{{doc['process_md5']}}'
process_sha256=’{{doc['process_sha256']}}'
process_name='{{doc['process_name']}}'
process_path='{{doc['path']}}'
last_update='{{doc['last_update']}}'
{% for k in doc %}{% if k.startswith("alliance_") %}
{{k}}='{{doc[k]}}'{% endif %}{% endfor %}

Process Storage Feed Hit – Key-Value Pairs

Syslog Label Solr Doc Reference Description

reason no doc reference Text that describes the entry. The reason label is hard-coded in the syslog
template and identifies the type of the event as "watchlist.hit," "feed.hit," or
"binaryinfo."

type no doc reference Text that identifies the type of data that is returned with the event. For process
events, the value is ‘event’.

process_guid process_id Process doc identifier.

VMware, Inc. 57
VMware Carbon Black EDR Integration Guide

Syslog Label Solr Doc Reference Description

segment_id segment_id Process doc segment identifier.

host hostname Hostname of the computer on which the feed hit was detected.

comms_ip comms_ip IP address from which Carbon Black EDR received the event (which could be a
NAT or proxy address, if one is configured for the computer on which the
process executed; otherwise this is the same as interface_ip).

interface_ip Interface_ip IP address of the computer on which the process executed.

sensor_id sensor_id Sensor ID of endpoint that observed the feed hit.

feed_id feed_id ID of the feed that was matched.

feed_name feed_name Name of the feed that was matched.

report_title report_title Name of the item in the feed that was matched.

ioc_type ioc_type Type of the IOC that caused the hit.

ioc_value ioc_value Value of the IOC that matched.

for/if loops _* ioc_attr n alliance_* identifies and prints all attributes whose names start with
"alliance_" in all documents that contain feed hits, including documents
reported by watchlist hits. These attributes represent feed hits.
n ioc_attr identifies and prints additional attributes on IOC values that were
matched.

Note for/if loops are not required. They report attributes that do not have
predefined sets. You can create customized templates that do not contain them
if you do not need to report on alliance_* or ioc_attr attributes.

timestamp event_timestamp Epoch time of the feed hit event.

start_time start Start time of this process, in the computer’s local time.

group group Sensor group to which the sensor was assigned at the time of process
execution.

process_md5 process_md5 MD5 hash value of the executable backing this process.

process_sha256 process_sha256 SHA-256 hash value of the executable backing this process.

process_name process_name Filename of the executable backing this process.

process_path path Full path to the executable backing this process.

last_update last_update Last activity in this process, in the computer’s local time.

Feed Hit on Binary Ingress

This section describes the binary ingress feed hit.

Binary Ingress Feed Hit – Example

Aug 12 14:06:39 [26070] <warning> reason=feed.ingress.hit type=module

md5=B84E2D174DC84916A536572BB8F691A8
sha256=A23B2D174DC84916A539872CD8F775A8B84F1E234DC84916A564738DC4EA6B76 host=’SERV12R2X64-01’
sensor_id=1 feed_id=2 feed_name=’srstrust’ ioc_type=’md5’
ioc_value=’b84e2d174dc84916a536572bb8f691a8’ timestamp=’1407866781.79’

VMware, Inc. 58
VMware Carbon Black EDR Integration Guide

Binary Ingress Feed Hit – Default Template

reason=feed.ingress.hit type=module
md5={{doc[’md5’]}}
sha256={{doc[’sha256’]}}
host=’{{doc[’hostname’]}}’
sensor_id={{doc[’sensor_id’]}}
feed_id={{doc[’feed_id’]}}
feed_name=’{{doc[’feed_name’]}}’
ioc_type=’{{doc[’ioc_type’]}}’
ioc_value=’{{doc[’ioc_value’]}} ’
{% for k in doc[’ioc_attr’] %} {{k}}=’{{doc[’ioc_attr’][k]}}’{% endfor %}
timestamp=’{{doc[’event_timestamp’]}}’

Binary Ingress Feed Hit – Key-Value Pairs

Syslog Label Solr Doc Reference Description

reason no doc reference Text that describes the entry. The reason label is hard-coded in the syslog template
and identifies the type of the event as "watchlist.hit," "feed.hit," or "binaryinfo."

type no doc reference Text that identifies the type of data that is returned with the event. For example:
n event (process events)
n module (binary modules)
n host (host level information only)

md5 md5 MD5 hash value of a process, a parent process, a child process, a loaded module or
a written file.

sha256 sha256 SHA-256 hash value of a process, a parent process, a child process, a loaded
module or a written file.

host hostname Hostname of the computer on which the feed hit was detected.

sensor_id sensor_id Sensor ID of the endpoint that detected the feed hit.

feed_id feed_id ID of the feed that was matched.

feed_name feed_name Name of the feed that was matched.

ioc_type ioc_type Type of IOC that caused the hit.

ioc_value ioc_value Value of the IOC that matched the hit criteria.

for/if loops _* ioc_attr n alliance_* identifies and prints all attributes whose names start with "alliance_"
in all documents that contain feed hits, including documents reported by
watchlist hits. These attributes represent feed hits.
n ioc_attr identifies and prints additional attributes on IOC values that were
matched.

Note for/if loops are not required. They report attributes that do not have
predefined sets. You can create customized templates that do not contain them if
you do not need to report on alliance_* or ioc_attr attributes.

timestamp event_timestamp Epoch time of the feed hit event.

Feed Hit on Binary Storage

This section describes the binary storage feed hit.

VMware, Inc. 59
VMware Carbon Black EDR Integration Guide

Binary Storage Feed Hit – Example

Aug 12 14:06:39 [26070] <warning> reason=feed.storage.hit type=module

md5=B84E2D174DC84916A536572BB8F691A8
sha256=7AFB56DD48565C3C9804F683C80EF47E5333F847F2D3211EC11ED13AD36061E1 host=’SERV12R2X64-01’
sensor_id=1 feed_id=2 feed_name=’srstrust’ ioc_type=’md5’
ioc_value=’b84e2d174dc84916a536572bb8f691a8’ timestamp=’1407866797.20’
first_seen=’2014-08-12T18:06:22.190Z’ group=[’Default Group’] desc=’Windows Security Center ISV API’
company_name=’Microsoft Corporation’ product_name=’Microsoft® Windows® Operating System’
product_version=’6.1.7600.16385’ file_version=’6.1.7600.16385 (win7_rtm.090713-1255)’ signed=’Signed’
alliance_updated_srstrust=’2014-05-16T04:39:55.000Z’ alliance_score_srstrust=’-100’
alliance_data_srstrust=’[’b84e2d174dc84916a536572bb8f691a8’]’ alliance_link_srstrust=’https://
services.carbonblack.com/Services/extinfo.aspx?
ak=b8b4e631d4884ad1c56f50e4a5ee9279&sg=0313e1735f6cec221b1d686bd4de23ee&md5=b84e2d174dc84916a536572bb8
f691a8’

Binary Storage Feed Hit – Default Template

reason=feed.storage.hit type=module
md5={{doc[’md5’]}}
sha256={{doc[’sha256’]}}
host=’{{doc[’hostname’]}}’
sensor_id={{doc[’sensor_id’]}}
feed_id={{doc[’feed_id’]}}
feed_name=’{{doc[’feed_name’]}}’
ioc_type=’{{doc[’ioc_type’]}}’
ioc_value=’{{doc[’ioc_value’]}} ’
{% for k in doc[’ioc_attr’] %} {{k}}=’{{doc[’ioc_attr’][k]}}’{% endfor %}
timestamp=’{{doc[’event_timestamp’]}}’ first_seen=’{{doc["server_added_timestamp"]}}’
group={{doc["group"]}}
desc=’{{doc["file_desc"]}}’
company_name=’{{doc["company_name"]}}’
product_name=’{{doc["product_name"]}}’
product_version=’{{doc["product_version"]}}’
file_version=’{{doc["file_version"]}}’
signed=’{{doc["digsig_result"]}}’
{% for k in doc %}{% if k.startswith("alliance_") %}
{{k}}=’{{doc[k]}}’{% endif %}{% endfor %}

Binary Storage Feed Hit – Key-Value Pairs

Syslog Label Solr Doc Reference Description

reason no doc reference Text that describes the entry. The reason label is hard-coded in the syslog
template and identifies the type of the event as "watchlist.hit," "feed.hit," or
"binaryinfo."

type no doc reference Text that identifies the type of data that is returned with the event. For
binary events, the value is ‘module’.

md5 md5 MD5 hash value of a process, a parent process, a child process, a loaded
module, or a written file.

sha256 sha256 SHA-256 hash value of a process, a parent process, a child process, a
loaded module, or a written file.

host hostname Hostname of the computer on which the feed hit was detected.

VMware, Inc. 60
VMware Carbon Black EDR Integration Guide

Syslog Label Solr Doc Reference Description

sensor_id sensor_id Sensor ID of the endpoint that observed the feed hit.

feed_id feed_id ID of the feed that was matched.

feed_name feed_name Name of the feed that was matched.

report_title report_title Name of the item in the feed that was matched.

ioc_type ioc_type Type of the IOC that caused the hit.

ioc_value ioc_value Value of the IOC that matched.

for/if loops _* ioc_attr n alliance_* identifies and prints all attributes whose names start with
"alliance_" in all documents that contain feed hits, including documents
reported by watchlist hits. These attributes represent feed hits.
n ioc_attr identifies and prints additional attributes on IOC values that
were matched.

Note for/if loops are not required. They report attributes that do not have
predefined sets. You can create customized templates that do not contain
them if you do not need to report on alliance_* or ioc_attr attributes.

timestamp event_timestamp Epoch time of the feed hit event.

first_seen server_added_ The time that this binary was first seen by the server.
timestamp

group group First sensor group in which this binary was observed.

desc file_desc File description string from the class FileVersionInfo.

company_name company_name Company name string from the class FileVersionInfo.

product_name product_name Product name string from the class FileVersionInfo.

product_version product_version Product version string from the class FileVersionInfo.

file_version file_version File version string from the class FileVersionInfo.

signed signed Digital signature status of the binary.

for/if loops _* ioc_attr n alliance_* identifies and prints all attributes whose names start with
"alliance_" in all documents that contain feed hits, including documents
reported by watchlist hits. These attributes represent feed hits.
n ioc_attr identifies and prints additional attributes on IOC values that
were matched.

Note for/if loops are not required. They report attributes that do not have
predefined sets. You can create customized templates that do not contain
them if you do not need to report on alliance_* or ioc_attr attributes.

Feed Hit on Host Ingress

This section describes host ingress feed hits.

VMware, Inc. 61
VMware Carbon Black EDR Integration Guide

Host Ingress Feed Hit – Example

2015-06-24 17:18:58 [3032] <warning> reason=feed.ingress.hit type=host host='WIN2008R2DC01'

sensor_id=2 feed_id=2 feed_name='cbtamper' ioc_type='class'
ioc_value='com.carbonblack.cbfs.ingress_search.detectors.SensorTamper$Terminate'
hit_field_tamper_type='AlertCBServiceStopped' timestamp='1435180738.63'

Host Ingress Feed Hit – Default Template

reason=feed.ingress.hit type=host host='{{doc['hostname']}}'

sensor_id={{doc['sensor_id']}} feed_id={{doc['feed_id']}}
feed_name='{{doc['feed_name']}}'
ioc_type='{{doc['ioc_type']}}'
ioc_value='{{doc['ioc_value']}}'
{% for k in doc['ioc_attr'] %} {{k}}='{{doc['ioc_attr'][k]}}'{% endfor %}
timestamp='{{doc['event_timestamp']}}'

Host Ingress Feed Hit – Key-Value Pairs

Key-value pairs for host ingress feed hits are a subset of those for binary ingress feed hits. See
Binary Ingress Feed Hit – Key-Value Pairs for descriptions.

Feed Hit on Process Query

This section describes process query feed hits.

Process Query Feed Hit – Example

2015-06-24 14:40:06 [10982] <warning> reason=feed.query.hit type=event

process_guid=0000000d-0000-564b-01d0-aeac18ce56e9 segment_id=1488563344023 host='stress03'
comms_ip='' interface_ip='' sensor_id=13 feed_id=4 feed_name='bit9endpointvisibility'
timestamp='1435171205.89' start_time='2015-06-24T18:32:16.752Z' group='Default Group'
process_md5='ab611b1f6c952654665a4cda027581f4'
process_sha256=’a76b4c204d7e28f0e4dcbb6abc910dC3e7f820416ed744874cba74849067b71’
process_name='cbquery' process_path='/usr/share/cb/cbquery' last_update='2015-06-24T18:32:17.345Z'

Process Query Feed Hit – Default Template

reason=feed.query.hit type=event
process_guid={{doc['process_id']}}
segment_id={{doc["segment_id"]}}
host='{{doc['hostname']}}'
comms_ip='{{doc['comms_ip']}}'
interface_ip='{{doc['interface_ip']}}'
sensor_id={{doc['sensor_id']}}
feed_id={{doc['feed_id']}}
feed_name='{{doc['feed_name']}}'
{% for k in doc['ioc_attr'] %} {{k}}='{{doc['ioc_attr'][k]}}'{% endfor %}
timestamp='{{doc['event_timestamp']}}'
start_time='{{doc['start']}}'
group='{{doc['group']}}'
process_md5='{{doc['process_md5']}}'
process_sha256='{{doc['process_sha256']}}'

VMware, Inc. 62
VMware Carbon Black EDR Integration Guide

process_name='{{doc['process_name']}}'
process_path='{{doc['path']}}'
last_update='{{doc['last_update']}}'
{% for k in doc %}{% if k.startswith("alliance_") %} {{k}}='{{doc[k]}}'{% endif %}{% endfor %}

Process Query Feed Hit – Key-Value Pairs

Key-value pairs for process query feed hits are a subset of those for process storage feed hits.
See Process Storage Feed Hit – Key-Value Pairs for descriptions.

Feed Hit on Binary Query

This section describes binary query feed hits.

Binary Query Feed Hit – Example

2015-06-24 18:30:14 [13031] <warning> reason=feed.query.hit type=module

md5=6D4B29FB9307FBE8781E42B7CFDA4CE1
sha256=F6E9D4834CBA57BCD0E77FE1D83C0B24A298B2CDEEF214ED6CC4BAB24C8DEF4E
host='WIN2008R2DC01' sensor_id=2 feed_id=18 feed_name='cbtestquery' timestamp='1435185013.38'
first_seen='' group='Default Group' desc='XML Resources' company_name='Microsoft Corporation'
product_name='Microsoft XML Core Services' product_version='8.110.7600.16385'
file_version='8.110.7600.16385' signed='Signed'

Binary Query Feed Hit – Default Template

reason=feed.query.hit type=module
md5={{doc["md5"]}}
sha256={{doc["sha256"]}}
host='{{doc.get('hostname')}}'
sensor_id={{doc.get('sensor_id')}}
feed_id={{doc['feed_id']}}
feed_name='{{doc['feed_name']}}'
{% for k in doc['ioc_attr'] %} {{k}}='{{doc['ioc_attr'][k]}}'{% endfor %}
timestamp='{{doc['event_timestamp']}}'
first_seen='{{doc["server_added_timlestamp"]}}'
group='{{doc["group"]}}'
desc='{{doc["file_desc"]}}'
company_name='{{doc["company_name"]}}'
product_name='{{doc["product_name"]}}'
product_version='{{doc["product_version"]}}'
file_version='{{doc["file_version"]}}'
signed='{{doc["signed"]}}'
{% for k in doc %}{% if k.startswith("alliance_") %}
{{k}}='{{doc[k]}}'{% endif %}{% endfor %}

Binary Query Feed Hit – Key-Value Pairs

Key-value pairs for binary query feed hits are a subset of those for binary storage feed hits. See
Binary Storage Feed Hit – Key-Value Pairs for descriptions.

VMware, Inc. 63
VMware Carbon Black EDR Integration Guide

Syslog Integration
You can use Syslog features for notification and data intelligence sharing. Directing Carbon Black
EDR alerts to Syslog files enables a variety of integration options for numerous platforms.

Specific fields vary depending upon the watchlist parameters selected during creation. See
“Advanced Search Queries” in the VMware Carbon Black EDR User Guide for specific fields to
use when creating queries, and “Watchlists” in the same guide for information about watchlists.

Setting Up Remote Devices

Remote devices must be configured with a new receiver to accept the rsyslog feed from Carbon
Black EDR.

Whether the remote device is an instance of SPLUNK, ArcSight, or another manager-of-

managers platform such as Tivoli, the basic setup requirements are the same.

Note The procedure for setting up remote devices differs depending upon the device itself. The
basics are described here. Adapt the procedure to your particular platform.

To set up the remote device for Syslog integration:

1 Add a new UDP receiver to the remote device.

2 Enable the new receiver to communicate using a new and unique UDP port number for the
communication with Carbon Black EDR. Verify that the receiver is working and listening on
the appropriate port.

Note The system might require the Carbon Black EDR IP address to be authorized prior to
accepting data.

Setting Up Server Data Transmission

On the Carbon Black EDR server, the rsyslog feature is used to transmit each watchlist hit to a
remote device or to multiple remote devices.

To set up the Carbon Black EDR server to send Syslog data to remote devices:

1 Access the Carbon Black EDR server either through the console or with a remote terminal
connection using SSH.

2 Edit the rsyslog file to enable Syslog information to be redirected:

/etc/rsyslog.d/cb-coreservices.conf

VMware, Inc. 64
VMware Carbon Black EDR Integration Guide

This example shows example output from an unaltered cb-coreservices.conf file:

Note The contents of the actual /etc/rsyslog.d/cb-coreservices.conf file can be different.

# By default the value of this directive is 'on' so that any special character (ASCII < 32) is
escaped. However,
# that causes multiline messages to be rather unreadable. While the practice of printing multiple
lines in a log
# should be discouraged, it is useful when error exception stack tracers are being reported. This
option might
# also cause problems if other log file reader software is being used as it may not be able to read
additional
# lines as those lines wouldn't have any timestamp/souce information.
#
# If this option is causing problems, it can be disabled which would make interpretting stack traces
a bit more
# difficult. However, the following command can be used when reading log files to make stack traces
readable again:
# cat /path/to/log/file | sed 's/#012/\n\t/g'
#
$EscapeControlCharactersOnReceive off

$template AccessLogFormat,"%msg%\n"
$template CbLogFormatWithPID,"%timegenerated:1:10:date-rfc3339% %timegenerated:8:15:% [%procid%] <
%syslogseverity-text%> %msg%\n"
$template CbSyslogStandardFormatWithPID,"%timegenerated% [%procid%] <%syslogseverity-text%> %msg%\n"

$template DynaFile,"/var/log/cb/notifications/%PROGRAMNAME%.log"

if $programname startswith 'process' then -?DynaFile

if $programname == 'cb-coreservices' and $syslogfacility-text == 'local0' then /var/log/cb/

coreservices/debug.log;CbLogFormatWithPID
& ~
if $programname == 'cb-coreservices' and $syslogfacility-text == 'local7' then /var/log/cb/
coreservices/access.log;AccessLogFormat
& ~
if $programname == 'cb-sensorservices' and $syslogfacility-text == 'local0' then /var/log/cb/
sensorservices/debug.log;CbLogFormatWithPID
& ~
if $programname == 'cb-sensorservices' and $syslogfacility-text == 'local7' then /var/log/cb/
sensorservices/access.log;AccessLogFormat
& ~
if $programname == 'cb-allianceclient' and $syslogfacility-text == 'local0' then /var/log/cb/
allianceclient/allianceclient.log;CbLogFormatWithPID
& ~
if $programname == 'cb-job-runner' then /var/log/cb/job-runner/job-runner.log;CbLogFormatWithPID
& ~
if $programname == 'cb-notifications' then /var/log/cb/notifications/cb-all-
notifications.log;CbSyslogStandardFormatWithPID
& ~
if $programname startswith 'cb-notifications-' then -?DynaFile;CbSyslogStandardFormatWithPID
& ~
if $programname == 'cb-services' then /var/log/cb/services/init.log;CbLogFormatWithPID

VMware, Inc. 65
VMware Carbon Black EDR Integration Guide

& ~
if $programname == 'cb-enterprised' then /var/log/cb/enterprise/enterprise.log;CbLogFormatWithPID
& ~
if $programname == 'cb-liveresponse' and $syslogfacility-text == 'local0' then /var/log/cb/
liveresponse/debug.log;CbLogFormatWithPID
& ~
if $programname == 'cb-liveresponse' and $syslogfacility-text == 'local7' then /var/log/cb/
liveresponse/access.log;AccessLogFormat

Sending All Data to a Remote Device

You can direct all watchlist output a specific remote device by adding the remote device IP
address to the cb-all-notifications parameter in the /etc/rsyslog.d/cb-coreservices.conf
file.

To set up the Carbon Black EDR server to send data to a remote device:

1 Log into the Carbon Black EDR console.

2 Edit the cb-coreservices.conf file as shown in the following example: vi /etc/

rsyslog.d/cb-coreservices.conf

3 Add the following line ( highlighted ) to the configuration file under the cb-allnotifications
line:

if $programname == 'cb-notifications' then /var/log/cb/notifications/cb-

allnotifications.log;CbLogFormatWithPID
& @<remote device IP address>:<UDP port>;CbLogFormatWithPID & ~

4 Restart the rsyslog daemon so that the changes take effect: service rsyslog restart

5 Verify that the data is now present on the remote device.

Sending Watchlist Data to a Remote Device

To direct specific watchlist output to a remote device, you must configure Carbon Black EDR to
filter each watchlist independently.

To configure Carbon Black EDR to send watchlist data to a remote device:

1 Login to the Carbon Black EDR console.

2 Edit the cb-coreservices.conf file: vi /etc/rsyslog.d/cb-coreservices.conf

VMware, Inc. 66
VMware Carbon Black EDR Integration Guide

3 Add the following line to the configuration file: if $programname == 'cb-notifications-

watchlist-105' then /var/log/cb/notifications/cb-notifications-
watchlist-105.log;CbLogFormatWithPID & @<remote device IP address>:<UDP
port>;CbLogFormatWithPID & ~

Note
n The entire section below must be added to the cb-coreservices.conf file. The example
here specifies watchlist number 105.

n Ensure that the correct watchlist is specified. To ensure that the correct watchlist is sent
to the remote device, verify the watchlist ID from the Carbon Black EDR console before
you add these lines to the cb-coreservices.conf file.

4 Restart the rsyslog daemon so that the changes take effect:

service rsyslog restart

5 Verify that the data is present on the remote device.

Enabling Communication Persistence (Spooling)

If communication with the remote device is interrupted, you can enable spooling for notifications
on the Carbon Black EDR server.

To enable spooling of notifications:

1 Log into the Carbon Black EDR console.

2 Locate and open the /etc/rsyslog.d/cb-coreservices.conf file.

3 Add the following lines after the section in which you are capturing logs (this line starts with
if $programname ) and before each action item for that section:

//
# An on-disk queue is created for this action.If the remote host is
# down, messages are spooled to disk and sent when it is up again.
$WorkDirectory /var/lib/rsyslog # where to place spool files
$ActionQueueFileName fwdRule1 # unique name prefix for spoolfiles
$ActionQueueMaxDiskSpace 1g # 1gb space limit (use as much as possible)
$ActionQueueSaveOnShutdown on # save messages to disk on shutdown
$ActionQueueType LinkedList # run asynchronously
$ActionResumeRetryCount -1 # infinite retries if host is down
//

The following is an example:

if $programname startswith 'cb-notifications-' then -?DynaFile;CbSyslogStandardFormatWithPID

$WorkDirectory /var/lib/rsyslog # location of spoolfiles on the disk
$ActionQueueFileName cbtest # unique name prefix for spool files
$ActionQueueMaxDiskSpace 1g # 1gb space limit (use as much as possible)
$ActionQueueSaveOnShutdown on # save messages to disk on shutdown

VMware, Inc. 67
VMware Carbon Black EDR Integration Guide

$ActionQueueType LinkedList # run asynchronously

$ActionResumeRetryCount -1 # infinite retries if host is down
& @@192.168.10.252:514;CbSyslogStandardFormatWithPID
& ~

Carbon Black EDR Syslog Architecture

Carbon Black EDR stores all logged information in the /var/log/cb/ directory.

When you troubleshoot any server-side activity, start with the logs in this directory.

Watchlist Log Location

Carbon Black EDR maintains two separate syslog files for watchlists created in the Carbon Black
EDR console.

The first syslog file is a single file with all watchlist hits consolidated in one place.

The second syslog file saves each watchlist hit to its own file. All the watchlist syslog files are
stored in the following location on the Carbon Black EDR server:

/var/log/cb/notifications

Each watchlist is assigned a specific number, which can be viewed from the Carbon Black EDR
server per this example:

https://<server name>/#/watchlist/105

In this example the watchlist number is 105.

Carbon Black EDR creates a numbered syslog that matches the watchlist number. In the example
above, the watchlist 105 syslog creates the output file:

cb-notifications-watchlist-105.log-20131031

The syslog file name format follows a standard convention for all watchlists as shown below:

cb-notifications-watchlist-<watchlist#>.log-YYYYMMDD

The single summary syslog with all watchlist hits in one consolidated file uses the following
naming convention:

cb-all-notifications.log-YYYYMMDD

Binary Information events are not published in the cb-all-notifications.log file.

Syslog Templates
You can use Carbon Black EDR syslog templates to build custom-formatted syslog notifications
for Carbon Black EDR watchlist hits, feed hits, and binary information events.

Syslog output is formatted using Jinja2 templates. A command line utility at:

/usr/share/cb/cbsyslog

supports:

VMware, Inc. 68
VMware Carbon Black EDR Integration Guide

# /usr/share/cb/cbsyslog --help

Usage: cbsyslog.py [options]

This utility provides an interface for testing Carbon Black EDR’s notifications syslog output. The
interface options are as follows:

Syslog notification testing utility (cbsyslog) options

Option Description

-h, --help Displays a help message and then closes the message.

-v, --verbose Provides detailed output.

-l, --list-events Outputs the list of events, which can be sent to syslog, and then exits.

-e EVENT_NAME, -- Identifies specific event types. Use the --listevents option for a list of event
event=EVENT_NAME names that can be passed here.

Note Some event output of the cbsyslog -e contains sample data, while other
output contains the results from actual database queries. See the output results to
determine if the data is sample data; sample data contains a string such as " "***
Note: This event type uses example content for testing ***" .

-g, --get Saves the system default templates to the current directory.

-t TEMPLATE, -- Formats the syslog message using the specified template instead of the system
template=TEMPLATE default.

-f, --fire Formats and sends an event through the syslog message system. For example,
you can use this option to manually execute the same process that occurs when
the Carbon Black EDR server sends an event to syslog when there is a hit.

-q QUERY, --query=QUERY Processes the first Solr doc that matches the query string. You can use this query
to identify which document to test with.

To build custom-formatted syslog notifications:

1 Use the --get switch to write the system default templates to the local directory:

# /usr/share/cb/cbsyslog --get
# ll
-rw-rw-r--. 1 root root 246 May 22 00:16 binaryinfo.group.observed.template
-rw-rw-r--. 1 root root 285 May 22 00:16 binaryinfo.host.observed.template
-rw-rw-r--. 1 root root 221 May 22 00:16 binaryinfo.observed.template
-rw-rw-r--. 1 root root 194 May 22 00:16 feed.ingress.hit.binary.template
-rw-rw-r--. 1 root root 210 May 22 00:16 feed.ingress.hit.process.template
-rw-rw-r--. 1 root root 194 May 22 00:16 feed.storage.hit.binary.template
-rw-rw-r--. 1 root root 243 May 22 00:16 feed.storage.hit.process.template
-rw-rw-r--. 1 root root 575 May 22 00:16 watchlist.hit.binary.template
-rw-rw-r--. 1 root root 460 May 22 00:16 watchlist.hit.process.template

The templates are given a context with a single python dictionary called doc that contains the
set of all possible key-value pairs.

VMware, Inc. 69
VMware Carbon Black EDR Integration Guide

2 To view the set of all possible keys, use the Jinja For loop to iterate over the indexed fields in
the Solr document with this template:

a Create a ‘forloop.txt’ template with the following contents:

{% for k in doc %}{{k}}={{doc[k]}} {% endfor %}

b Use the --template switch to output all of the available keys for a specific event type:

# /usr/share/cb/cbsyslog --template ./forloop.txt --event watchlist.hit.process

process_md5=506708142bc63daba64f2d3ad1dcd5bf
process_sha256=6635a659bc80def44859f36719ed30618589c4b50abc17def38ee7dd913721 sensor_id=15
modload_count=45
filemod_count=0 servername=cbent-qa-nodesvr02 watchlist_id=-1
watchlist_name=SyslogTest id=1068044553602656801 group=SetSensor
hostname=CB-WIN81X64-01 last_update=2014-02-28T02:29:00.09Z
start=2014-02-28T02:29:00.043Z netconn_count=0 username=SYSTEM
process_name=googleupdate.exe path=c:\program files (x86)\google\update\googleupdate.exe
regmod_count=1 segment_id=1488563344023 host_type=workstation cb_version=4.1.1.140225.1913
childproc_count=0 unique_id=00000c42-0000-172c-01d0-5d6cca2adbb2-015A954A1297

3 To get a list of available event types, use the –list-events option:

[root@localhost mytemplates]# /usr/share/cb/cbsyslog --list-events

binaryinfo.group.observed
binaryinfo.host.observed
binaryinfo.observed
feed.ingress.hit.binary
feed.ingress.hit.host
feed.ingress.hit.process
feed.storage.hit.binary
feed.storage.hit.process
watchlist.hit.binary
watchlist.hit.process
feed.query.hit.binary
feed.query.hit.process

Overriding System Default Templates

You can override the system default syslog templates.

1 To use a new template, add one of the following entries to /etc/cb/cb.conf :

BinaryInfoSyslogTemplateGroupObserved=/etc/cb/my_bininfo_group_observed_template.txt
BinaryInfoSyslogTemplateHostObserved=/etc/cb/my_bininfo_host_observed_template.txt
BinaryInfoSyslogTemplateObserved=/etc/cb/my_bininfo_observed_template.txt
FeedIngressSyslogTemplateBinary=/etc/cb/my_feed_ingress_binary_template.txtx
FeedIngressSyslogTemplateProcess=/etc/cb/my_feed_ingress_process_template.txt
FeedStorageSyslogTemplateBinary=/etc/cb/my_feed_storage_binary_template.txt
FeedStorageSyslogTemplateProcess=/etc/cb/my_feed_storage_process_template.txt

VMware, Inc. 70
VMware Carbon Black EDR Integration Guide

WatchlistSyslogTemplateBinary=/etc/cb/my_wathlist_process_template.txt
WatchlistSyslogTemplateProcess=/etc/cb/my_watchlist_binary_template.txt
FeedQuerySyslogTemplateBinary=/etc/cb/my_feed_query_binary_template.txt
FeedQuerySyslogTemplateProcess=/etc/cb/my_feed_query_process_template.txt

2 The watchlist search process will automatically pick up the new template when the next
watchlist hit occurs.

Available Keys by Event Type

This section describes available keys by event type.

binaryinfo.observed

Key Description Example

md5 MD5 hash value of the observed binary module. 44C0CBADFF00F3930B6A01EEAA40

5C6F

sha256 SHA-256 hash value of the observed binary module. 12B0DCFFEE00FA405C6F3930B6A01

EEAA405C6F44C0CBADFF00F3930B
6A01EEA

scores List of threat intelligence feed scores with which the [50, 100, 75]
binary is tagged.

watchlists List of strings, each one identifying a watchlist that was [“x”, “a”]
matched with a binary.

event_timestamp Event timestamp. 1400695113.17

binaryinfo.group.observed

Key Description Example

md5 MD5 hash value of the observed binary module. 44C0CBADFF00F3930B6A01EEAA40

5C6F

sha256 SHA-256 hash value of the observed binary module. 1123A659BC80DEF22859F36719ED306

18589C4B50ABC17DEF38EE7DDB9137
21

scores List of threat intelligence feed scores with which the [50, 100, 75]
binary is tagged.

watchlists List of strings, each one identifying a watchlist that was [“x”, “a”]
matched with a binary.

event_timestamp Event timestamp. 1400695113.17

group Name of the sensor group in which a binary was Default Group
observed.

binaryinfo.host.observed

VMware, Inc. 71
VMware Carbon Black EDR Integration Guide

Key Description Example

md5 MD5 hash value of the observed binary module. 44C0CBADFF00F3930B6A0

1EEAA405C6F

sha256 SHA-256 hash value of the observed binary module. 1123A659BC80DEF22859F36719ED306

18589C4B50ABC17DEF38EE7DDB9137
21

scores List of threat intelligence feed scores with which the [50, 100, 75]
binary is tagged.

watchlists List of strings, each one identifying a watchlist that was [“x”, “a”]
matched with a binary.

event_timestamp Event timestamp. 1400695113.17

hostname Name of the host endpoint on which a binary was PANTHER

observed.

sensor_id Sensor identifier of the endpoint on which a binary was 1

observed.

feed.ingress.hit.binary

Key Description Example

md5 MD5 hash value of a binary module that triggered a feed 44C0CBADFF00F3930B6A01EEAA40
hit. 5C6F

sha256 SHA-256 hash value of a binary module that triggered a 1123A659BC80DEF22859F36719ED306

feed hit. 18589C4B50ABC17DEF38EE7DDB9137
21

report_id ID of the report that was matched. report_01

ioc_type Type of the IOC that was matched. dns

ioc_value IOC value that was matched. www.google.com

ioc_attr Additional attributes on the IOC value that were matched. {port:80, protocol:tcp}

hostname Hostname of the computer on which the feed hit was PANTHER
detected.

sensor_id Sensor ID of the endpoint. 1

cb_version Carbon Black EDR server version. 5.0.0.140204.501

server_name Name of the Carbon Black EDR server edrserver

feed_id ID of the feed that was matched. 15

feed_name Name of the feed that was matched. mdl

event_timestamp Time of the event. 1400695113.17

feed.storage.hit.binary

VMware, Inc. 72
VMware Carbon Black EDR Integration Guide

Key Description Example

md5 MD5 hash value of a binary module that triggered a feed 44C0CBADFF00F3930B6A01EEAA40
hit. 5C6F

sha256 SHA-256 hash value of a binary module that triggered a 1123A659BC80DEF22859F36719ED306

feed hit. 18589C4B50ABC17DEF38EE7DDB9137
21

report_id ID of the report that was matched. report_01

ioc_type Type of the IOC that was matched. dns

ioc_value IOC value that was matched. www.google.com

ioc_attr Additional attributes on the IOC value that were matched. {port:80, protocol:tcp}

hostname Name of the host on which the feed hit was detected. PANTHER

sensor_id Sensor ID of the endpoint. 1

cb_version Carbon Black EDR server version. 5.0.0.140204.501

server_name Name of the Carbon Black EDR server. cbserver

feed_id ID of the feed that was matched. 15

feed_name Name of the feed that was matched. mdl

event_timestamp Time of the event. 1400695113.17

copied_mod_len Number of bytes collected. 73544

endpoint Hostname and sensor ID of the endpoint on which the [PANTHER|2]

binary was first observed.

group First sensor group in which this binary was observed. [Default Group]

digsig_issuer If digitally signed, the issuer. VeriSign Class 3 Code Signing 2010 CA

digsig_publisher If digitally signed, the publisher. Google Inc

digsig_result If digitally signed, the result. Contains one of the following Signed
eight possible values:
n Signed
n Unsigned
n Bad Signature
n Invalid Signature
n Expired
n Invalid Chain
n Untrusted Root
n Explicit Distrust

digsig_result_code Internal use. 0

digsig_sign_time If digitally signed, the time of signing. 2015-02-02T04:42:00Z

digsig_subject If digitally signed, the subject. Google Inc

is_executable_ima True if the binary is an EXE (versus DLL or SYS). True

ge

is_64bit True if the architecture is x64. True

VMware, Inc. 73
VMware Carbon Black EDR Integration Guide

Key Description Example

md5 MD5 hash value of a process, a parent process, a child 44C0CBADFF00F3930B6A0

process, a loaded module or a written file. 1EEAA405C6F

sha256 SHA-256 hash value of a process, a parent process, a 1EEAA405C6F44C0CBADFF00F3930B

child process, a loaded module or a written file. 6A044C0CBADFF00F3930B6A01EEA
A405C6F

observed_filenam Full path to the executable backing this process. c:\program files(x86)\google\chrome
e \application\wow_helper.exe

orig_mod_len Size, in bytes, of a binary at the time of collection. 73544

os_type Operating system type of the host. Windows

server_added_tim The time this binary was first seen by the server. 2014-02-04T07:50:56.9 17Z
estamp

server_name Name of the Carbon Black EDR server edrserver

watchlist_<id> For each watchlist that matched a binary, the timestamp ‘2014-02-04T07:55:03. 007Z’
of the match.

file_version File version string from the class FileVersionInfo.

product_name Product name string from the class FileVersionInfo.

company_name Company name string from the class FileVersionInfo.

internal_name Internal name string from the class FileVersionInfo.

original_filename Original name string from the class FileVersionInfo.

file_desc File description string from the class FileVersionInfo.

product_desc Product description string from the class FileVersionInfo.

comments Comment string from the class FileVersionInfo.

legal_copyright Legal copyright string from the class FileVersionInfo.

legal_trademark Legal trademark string from the class FileVersionInfo.

private_build Private build string from the class FileVersionInfo.

special_build Special build string from the class FileVersionInfo.

product_version Product name string from the class FileVersionInfo.

feed.ingress.hit.process

Key Description Example

process_id Process doc identifier. 00000064-0000-07f0-01d2-8e03fc88

f25e

report_id ID of the report that was matched. report_01

ioc_type Type of the IOC that was matched. dns

ioc_value IOC value that was matched. www.google.com

ioc_attr Additional attributes on the IOC value that were matched. {port:80, protocol:tcp, direction:
‘Outbound’}

VMware, Inc. 74
VMware Carbon Black EDR Integration Guide

Key Description Example

hostname Hostname of the computer on which the feed hit was PANTHER
detected.

sensor_id Sensor ID of the endpoint. 1

cb_version Carbon Black EDR server version. 5.0.0.140204.501

server_name Name of the Carbon Black EDR server. cbserver

feed_id ID of the feed that was matched. 15

feed_name Name of the feed that was matched. mdl

event_timestamp Time of the event. 1400695113.17

feed.query.hit.process

Key Description Example

process_id Process doc identifier. 00000064-0000-07f0-01d2-8e03fc88

f25e

segment_id Process Solr doc segment identifier. 1

hostname Hostname of the computer on which the feed hit was PANTHER
detected.

comms_ip IP address from which Carbon Black EDR received the

event (which could be a NAT or proxy address, if one is
configured for the computer on which the process
executed; otherwise this is the same as interface_ip).

interface_ip IP address of the computer on which the process

executed.

sensor_id Sensor ID of the endpoint. 1

feed_id ID of the feed that was matched. 15

feed_name Name of the feed that was matched. mdl

event_timestamp Time of the event. 1400695113.17

start 2015-06-24T18:32:16.752Z

process_md5 MD5 hash value of the executable backing this process. 506708142bc63daba64f2d3ad1dcd5bf

process_sha256 SHA-256 hash value of the executable backing this 2bc63daba64f2d3ad1dcd5bf50670814

process. 2bc63daba64f2d3ad1dcd5bf50670814

process_name Filename of the executable backing this process. googleupdate.exe

path Full path to the executable backing this process. c:\program files(x86)\google\update
\googleupdate.exe

last_update Last activity in this process, in the computer’s local time. 2014-02-04T16:23:22.5 47Z

feed.storage.hit.process

VMware, Inc. 75
VMware Carbon Black EDR Integration Guide

Key Description Example

process_id Process Solr doc identifier. 00000064-0000-07f0-01d2-8e03fc88

f25e

segment_id Process Solr doc segment identifier. 1488563344023

report_id ID of the report that was matched. report_01

ioc_type Type of the IOC that was matched. dns

ioc_value IOC value that was matched. www.google.com

ioc_attr Additional attributes on the IOC value that were matched. {port:80, protocol:tcp,
direction:’Outbound’}

hostname Hostname of the computer on which the feed hit was PANTHER
detected.

comms_ip IP address from which Carbon Black EDR received the 10.101.301.4
event (which could be a NAT or proxy address, if one is
configured for the computer on which the process
executed; otherwise this is the same as interface_ip).

interface_ip IP address of the computer on which the process 10.101.301.4

executed.

sensor_id Sensor ID of the endpoint. 1

cb_version Carbon Black EDR server version. 5.0.0.140204.501

server_name Name of the Carbon Black EDR server. edrserver

feed_id ID of the feed that was matched. 15

feed_name Name of the feed that was matched. mdl

event_timestamp Time of the event. 1400695113.17

childproc_count Total count of child processes that were created by this 0

process.

cmdline Process command line. “c:\net.exe” /user

filemod_count Total count of files that were modified by this process. 0

group Sensor group to which this sensor was assigned at the Default Group
time of process execution.

host_type Type of the computer: workstation, server, or domain server

controller.

last_update Last activity in this process, in the computer’s local time. 2014-02-04T16:23:22.5 47Z

modload_count Total count of modules that were loaded by this process. 45

netconn_count Total count of network connections made by this process. 0

os_type Operating system type of the host. Windows

parent_name Name of the parent process. svchost.exe

parent_md5 MD5 hash value of the parent process. 506708142bc63daba64f2d3ad1dcd5bf

parent_sha256 SHA-256 hash value of the parent process. 1123a659bc80def22859f36719ed30618

589c4b50abc17def38ff7eed913721

parent_pid Parent process PID. 2532

VMware, Inc. 76
VMware Carbon Black EDR Integration Guide

Key Description Example

parent_unique_id Parent process unique ID. 00000c42-0000-172c-01d0-5d6cca2a

dbb2-000000000001

path Full path to the executable backing this process. c:\program files(x86)\google\update
\googleupdate.exe

process_md5 MD5 hash value of the executable backing this process. 506708142bc63daba64f2d3ad1dcd5bf

process_sha256 SHA-256 hash value of the executable backing this 1123a659bc80def22859f36719ed30618

process. 589c4b50abc17def38ff7eed913721

process_name Filename of the executable backing this process. googleupdate.exe

process_pid Process PID. 44988

regmod_count Total count of registry modifications made by this 0

process.

start Start time of this process, in the computer’s local time. 2014-02-04T16:23:22.5 16Z

unique_id Process unique ID. 00000c42-0000-172c-01d0-5d6cca2a

dbb2-015A954A1297

username User context in which the process was executed. SYSTEM

watchlist_id Watchlist that matched (-1 is the internal syslog test). -1

watchlist_name Name of the watchlist that matched. SyslogTest

watchlist.hit.process

Key Description Example

cb_version Carbon Black EDR server version. 5.0.0.140204.501

childproc_count Total count of child processes that were created by this 0

process.

cmdline Process command line. “c:\net.exe” /user

filemod_count Total count of files that were modified by this process. 0

group Sensor group to which this sensor was assigned at the Default Group
time of process execution.

host_type Type of the computer: workstation, server, or domain server

controller.

hostname Hostname of the computer on which the process PANTHER

executed.

id Internal use. 7553512292948143354

last_update Last activity in this process, in the computer’s local time. 2014-02-04T16:23:22.5 47Z

modload_count Total count of modules that were loaded by this process. 45

netconn_count Total count of network connections made by this process. 0

os_type Operating system type of the host. Windows

parent_unique_id Parent process unique ID. 00000c42-0000-172c-01d0-5d6cca2a

dbb2

VMware, Inc. 77
VMware Carbon Black EDR Integration Guide

Key Description Example

path Full path to the executable backing this process. c:\program files (x86)\google\update
\googleupdate.exe

process_md5 MD5 hash value of the executable backing this process. 506708142bc63daba64f2d3ad1dcd5bf

process_sha256 SHA-256 hash value of the executable backing this 1123a659bc80def22859f36719ed30618

process. 589c4b50abc17def38ff7eed913721

parent_pid Parent process PID. 2532

process_name Filename of the executable backing this process. googleupdate.exe

process_pid Process PID. 44988

regmod_count Total count of registry modifications made by this 0

process.

segment_id Internal use. 1488563344023

comms_ip IP address from which Carbon Black EDR received the 123.101.301.4
event (which could be a NAT or proxy address, if one is
configured for the computer on which the process
executed; otherwise this is the same as interface_ip).

interface_ip IP address of the computer on which the process 10.432.123.9

executed.

sensor_id The internal Carbon Black EDR sensor Global Unique 6

Identifier (GUID) of the computer on which this process
was executed.

server_name Name of the Carbon Black EDR server. edrserver

start Start time of this process, in the computer’s local time. 2014-02-04T16:23:22.5 16Z

unique_id Process unique ID. 00000c42-0000-172c-01d0-5d6cca2a

dbb2-015A954A1297

username User context in which the process was executed. SYSTEM

watchlist_id Watchlist that matched (-1 is the internal syslog test). -1

watchlist_name Name of the watchlist that matched. SyslogTest

watchlist.hit.binary

Key Description Example

cb_version Carbon Black EDR server version. 5.0.0.140204.501

copied_mod_len Number of bytes collected. 73544

endpoint Hostname and sensor ID of the endpoint on which the [PANTHER|2]

binary was first observed.

group First sensor group in which this binary was observed. [Default Group]

digsig_issuer If digitally signed, the issuer. VeriSign Class 3 Code Signing 2010 CA

digsig_publisher If digitally signed, the publisher. Google Inc

VMware, Inc. 78
VMware Carbon Black EDR Integration Guide

Key Description Example

digsig_result If digitally signed, the result. Contains one of the following Signed
eight possible values:
n Signed
n Unsigned
n Bad Signature
n Invalid Signature
n Expired
n Invalid Chain
n Untrusted Root
n Explicit Distrust

digsig_result_code Internal use. 0

digsig_sign_time If digitally signed, the time of signing. 2015-02-02T04:42:00Z

digsig_subject If digitally signed, the subject. Google Inc

is_executable_ima True if the binary is an EXE (versus DLL or SYS). True

ge

is_64bit True if architecture is x64. True

md5 MD5 hash value of the process, the parent process, a 44C0CBADFF00F3930B6A01EEAA40
child process, a loaded module, or a written file. 5C6F

sha256 SHA-256 hash value of the process, parent process, a 1123a659bc80def22859f36719ed30618

child process, a loaded module, or a written file 589c4b50abc17def38ff7eed913721

observed_filenam Full path to the executable backing this process. c:\program files(x86)\google\chrome
e \application\wow_helper.exe

orig_mod_len Size, in bytes, of binary at time of collection. 73544

os_type Operating system type of the host. Windows

server_added_tim The time that this binary was first seen by the server. 2014-02-04T07:50:56.9 17Z
estamp

server_name Name of Carbon Black EDR server. edrserver

signed Internal use. Signed

timestamp Time that the binary was seen. 2014-02-04T07:50:56.9 17Z

watchlist_name Name of the watchlist that matched this binary. SyslogTest

watchlists All watchlists that matched this binary. [{‘wid’: ‘5’, ‘value’:
‘2014-02-04T07:55:03. 007Z’}]

watchlist_<id> For each watchlist that matched this binary, the ‘2014-02-04T07:55:03. 007Z’
timestamp of the match.

file_version File version string from the class FileVersionInfo.

product_name Product name string from the class FileVersionInfo.

company_name Company name string from the class FileVersionInfo.

internal_name Internal name string from the class FileVersionInfo.

original_filename Original name string from the class FileVersionInfo.

file_desc File description string from the class FileVersionInfo.

VMware, Inc. 79
VMware Carbon Black EDR Integration Guide

Key Description Example

product_desc Product description string from the class FileVersionInfo.

comments Comment string from the class FileVersionInfo.

legal_copyright Legal copyright string from the class FileVersionInfo.

legal_trademark Legal trademark string from the class FileVersionInfo.

private_build Private build string from the class FileVersionInfo.

special_build Special build string from the class FileVersionInfo.

product_version Product name string from the class FileVersionInfo.

Syslog Common Event Format

The Common Event Format (CEF) is an ArcSight standard that aligns the output format of various
technology vendors into a common form.

Carbon Black EDR watchlist syslog output supports fully-templated formats, enabling easy
modification of the template to match the CEF-defined format.

Applying the Default CEF Templates

CEF syslog templates are located at /usr/share/cb/syslog_templates .

To use the CEF syslog templates, add the following lines to /etc/cb/cb.conf :

WatchlistSyslogTemplateProcess=/usr/share/cb/syslog_templates/process_cef.txt
WatchlistSyslogTemplateBinary=/usr/share/cb/syslog_templates/binary_cef.txt

The watchlist searcher process automatically picks up the new template when the next watchlist
hit occurs.

n The following is an example process watchlist hit in CEF format:

CEF:0|Carbon Black|Carbon Black|4.1.0.131118.1540|reason=process_watchlist_-1|

SyslogTest|10|dproc=wmiprvse.exe fname=c:\\windows\\system32\\wbem\\wmiprvse.exe
start=2014-01-14T20:36:19.526Z dhost=J-8205A0C27A0C4 msg=group:Default Group
process_md5:0ffae66e6d5b1c87cbd22d1f3b6079fd last_update:2014-01-14T20:36:19.526Z
guid:-5850106436655859636 segment_id:1488563344023

n The following is an example binary watchlist hit in CEF format:

CEF:0|Carbon Black|Carbon Black|4.1.0.131118.1540|reason=binary_watchlist_-1|

SyslogTest|10|start=2014-01-13T14:49:55.189Z msg=md5:6D778E0F95447E6546553EEEA709D03C
desc:Windows Command Processor company_name:Microsoft Corporation
product_name:MicrosoftÂ:registered: WindowsÂ:registered: Operating System
product_version:5.1.2600.5512 file_version:5.1.2600.5512 (xpsp.080413-2111)
signed:Signed

VMware, Inc. 80
VMware Carbon Black EDR Integration Guide

Extension Dictionary
The CEF specification is influenced by network device vendors and, to a lesser extent, host-
based antivirus products. Products like Carbon Black EDR, with rich endpoint visibility, did not
exist when the specification was developed and, as a result, the built-in key names supported by
the extension dictionary do not map well to the data in Carbon Black EDR.

In the default template, the catch-all msg parameter is used for the fields that do not map well to
the specified list of default keys. This limits required configuration and avoids the limitations of
custom extensions.

To use custom extension keys, configure your SIEM device to support the custom keys and
modify the Carbon Black EDR default CEF template. Details are available in the CEF specification
and in Syslog Templates. Contact your support representative with any questions.

VMware, Inc. 81
VDI Support
8
This topic describes Carbon Black EDR support for Virtual Desktop Infrastructure (VDI) and how
to configure your machines to use it.

This chapter includes the following topics:

n Overview

n Configuring the Server for VDI Support

n Specifying the Scope of VDI Support

Overview
Carbon Black EDR provides support for environments in which client machines are frequently re-
imaged or reverted back to a master image.

In these environments, agent-based software can experience complex agent management issues
such as duplicate systems or sensor id collisions. These issues are typical in environments where
the sensors are installed on a master image or on Virtual Desktop Infrastructure (VDI) images,
particularly when using non-persistent images.

Carbon Black EDR provides a means to resolve these VDI issues. If VDI behavior is configured
and enabled for some or all sensors, the sensor communicates first with the Carbon Black EDR
server (single or clustered), attempting to register itself. The server then tries to correlate that
sensor’s and client machine’s characteristics (i.e., hostname and DNS name) to an existing sensor.
If the server can correlate the new client to a sensor it has seen already, it assigns that sensor its
previous Sensor ID. If there is no correlation, the server performs a new registration for that
client. This allows the client machine to report to the server with the same Sensor ID, maintaining
the client event history despite having been re-imaged. If the endpoint's System ID (SID)
changes, VMware Carbon Black must create a new Sensor ID for that endpoint.

The process for setting up VDI support can be divided into two stages:

1 Configuring the Carbon Black EDR server to support the VDI behavior.

2 Choosing the appropriate VDI support implementation option (global or sensor group).

VMware, Inc. 82
VMware Carbon Black EDR Integration Guide

Configuring the Server for VDI Support

The process of configuring the server includes two tasks.

n Enable VDI support in the cb.conf file.

n Deploy a VDI support plug-in that correlates a sensor to a Sensor ID.

Note To configure VDI support, the Carbon Black EDR server must be version 5.0 or later.

Enabling VDI Support

If you have a Carbon Black EDR cluster, this configuration change is required on the primary and
on all minions.

To enable VDI support:

1 Add the following configuration options to the /etc/cb/cb.conf file.

Note If you are copying the following lines of code to paste directly into the file and a line
break occurs or special characters appear, delete the line break and any special characters.
Ensure that each line is added to the file as one continuous line.

NewRegistrationCallbackModulePath=/usr/share/cb/plugins/
default_new_sensor_registration_callback.py
NewRegistrationCallbackClassName=DefaultNewRegistrationCallback

2 With root-level access, restart cb-enterprise:

service cb-enterprise restart

For clustered Carbon Black EDR servers:

/usr/share/cb/cbcluster stop
/usr/share/cb/cbcluster start

Deploying a VDI Support Plug-in

When implementing VDI, you can use the existing default plug-in or create your own.

The default plug-in uses a sensor-provided client hostname and DNS name to correlate to an
existing Sensor ID. You can create additional plug-ins that correlate the sensor to an existing
Sensor ID based on other characteristics of the system, for example, a MAC address or an IP
address.

The default plug-in provided with the Carbon Black EDR server is located here:

/usr/share/cb/plugins/default_new_sensor_registration_callback.py

VMware, Inc. 83
VMware Carbon Black EDR Integration Guide

Specifying the Scope of VDI Support

An integral part of implementing VDI support is the installation and configuration of Carbon Black
EDR sensors. Each sensor collects data on running processes and binaries.

VDI support can be implemented using one of two approaches:

n Global VDI support

n Sensor group VDI support

When installing a Carbon Black EDR sensor on a master image, we recommend that you use
Global VDI Support. While not required for sensor-group-based VDI support, the combination of
the two solutions provides additional assurance that the master image does not cause any
sensor conflicts.

A sensor collects data upon installation and its collection process can be optimized by clearing
out two types of Carbon Black EDR directories: those storing binary or event log data. Clearing
out these directories before the sensor becomes operational ensures that the sensor does not
propagate a backlog of data from processes that ran while installing Carbon Black EDR to any or
all of the images. Such a propagation can have adverse effects while deploying the image.

After stopping Carbon Black EDR sensor services on the client, clear the directories and files for
the following types of data:

n Windows binary data

n Directory: %WINDIR%\CarbonBlack\store

n Sub-directories: MD5_*

n Windows event data

n Directory: %WINDIR%\CarbonBlack\EventLogs

n Files: eventlog_*.log.zip and active-event.log

n OSX binary data

n Directory:/var/lib/cb/store

n Files: MD5_*

n OSX event data

n Directory: /var/lib/cb

n Files: event.log*

After the directories are cleared, you can configure either global or sensor group VDI support.

Global VDI Support

With the global VDI option configured on the Carbon Black EDR sensor, the server attempts to
correlate all sensors registering with it to a previously registered sensor, regardless of the

VMware, Inc. 84
VMware Carbon Black EDR Integration Guide

assigned sensor group. For this to occur, the client’s sensor must be configured to initially
register/check-in with a Sensor ID of 0. This setting is globally enabled on the server by default.

Before you can install a sensor on a master image, you must download a sensor package from
the appropriate sensor group. When you install the sensor, ensure that the client is in “private
mode” so that the sensor will not make any connections yet, such as checking in or registering
with the Carbon Black EDR server.

Once installed, you can select the procedure for one of the following operating systems:

n Windows

n macOS

n Linux

Setting up Global VDI Support on Windows

This topic describes how to set up global VDI support on Windows.

1 Stop the Carbon Black EDR services on the endpoint.

a Open a command prompt with administrator privileges.

b Execute the following commands:

sc stop carbonblack

sc stop carbonblackk

2 Set the Sensor ID by setting the registry value SensorId in the registry key /
HKEY_LOCAL_MACHINE/SOFTWARE/CarbonBlack/config to 0 .

Note If the SensorId value does not already exist, create it as a QWORD value.

3 Save the image and deploy.

Setting up Global VDI Support on macOS

This topic describes how to set up global VDI support on macOS.

1 Stop the Carbon Black EDR services on the endpoint.

a Open a terminal.

b Execute the following commands:

sudo launchctl unload /Library/LaunchDaemons/com.carbonblack.daemon.plistSet

2 Set the Sensor ID by editing /var/lib/cb/sensor.id and replacing current id with 0.

3 Save the image and deploy.

Setting up Global VDI Support on Linux

This topic describes how to set up global VDI support on Linux.

VMware, Inc. 85
VMware Carbon Black EDR Integration Guide

Procedure

1 Install the Linux sensor.

2 Stop cbdaemon: systemctlstop cbdaemon

3 Remove any stored binary or event data:

rm-rf /var/opt/carbonblack/response/store/*
rm-rf /var/opt/carbonblack/response/eventlogs/*

4 Enable VDI in config.ini:

vim /var/opt/carbonblack/response/sensorsetting.ini
VdiEnabled=1

5 Set the Sensor ID to 0. This allows the Carbon Black EDR to assign new Sensor IDs to new
VMs.

vim /var/opt/carbonblack/response/config.ini
SensorId=0
SensorIdforDisplay=0

6 Start the cbdaemon in the primary image VM:

systemctl start cbdaemon

Sensor Group VDI Support

With the sensor group VDI option, the server attempts to correlate only sensors that are in a
VDI-enabled group. For this to occur, the desired sensor group VDI behavior setting must be
enabled.

To set up group-based VDI support:

1 Login to the Carbon Black EDR console.

2 To configure a group for VDI support, click Sensors on the navigation bar.

3 From the Sensors menu, select the sensor group to configure for VDI support.

4 Click the Edit Settings tab. The Edit Settings page appears.

5 On the Advanced tab, select the VDI Behavior Enabled checkbox.

6 Click the Save Changes button to enable the configuration.

For more information about creating and editing sensor groups, see “Sensor Groups” in the
VMware Carbon Black EDR User Guide .

VMware, Inc. 86