We’re migrating product documentation to docs.vmware.com, starting with Carbon Black Cloud. Learn more.

Cb Response 6.2 Integration Guide

Cb Response 6.2 Integration Guide

This documentation provides information for administrators who are responsible for integrating Cb Response with various tools. It applies to all current 6.2 versions from 6.2.0 to 6.2.4. It discusses:

  • Integration with Cb Protection (formerly Bit9)
  • Integration with Microsoft Enhanced Mitigation Experience Toolkit (EMET)
  • Supported SAML 2.0 specifications and SAML 2.0 Single Sign-On (SSO) setup. This includes integration with the OKTA, Shibboleth, and ADFS IdPs
  • The Duo plugin, which you can configure two-factor authentication and download the Duo Mobile application on a mobile device
  • Syslog output for Cb Response events
  • Cb Response support for Virtual Desktop Infrastructure (VDI) and how to configure your machines to use it

 

See the Comments below for changes to this version.

 

Labels (1)
Attachments
0 Kudos
Comments

Changes to May 2018 6.2 version since previous (6.1) version:

  1. Converted several broken cross-references to plain text since they were pointing to locations outside of this PDF. [CB-19372]
  2. Updated the "Integrating Cb Response with Cb Protection" chapter to show Cb Protection 8.0.0 rather than Bit9 Platform 7.2.3. Also corrected some inaccurate descriptions of fields available on the Cb Protection Computer Details page and the Cb Protection File Details page. [CB-19373,CB-19585]
  3. In the "Syslog Output for Cb Response Events" chapter, added the missing key-value pair for "report_title" in the "Binary Storage Feed Hits -- Key Value Pairs" table. [CB-16395]
  4. Other minor corrections and improvements were also made.

Changes to August 2018 version since previous (May 2018) version:

  1. In the “Integrating EMET with Cb Response” chapter, added a note that EMET has been deprecated by Microsoft in releases beginning with the Windows 10 Fall Creators Update (Redstone 3).
  2. In the “Setting up Global VDI Support on Windows” section, corrected instructions that mistakenly described stopping the server instead of the sensor.
  3. In the “Troubleshooting” section, changed incorrect cb.flask.api_routes_saml module name to cb.flask.blueprints.api_routes_saml throughout.
  4. Other minor corrections and improvements were also made.

Page 111 "Setting up Global VDI Support on Windows" 

As written currently:

To setup global VDI support on Windows:
1.  Stop the Cb Response services on the server (only the master server if clustered).
     a.  Open a command prompt with administrator privileges.
     b.  Execute the following commands:
          sc stop carbonblack
          sc stop carbonblackk

Should be changed to:

To setup global VDI support on Windows sensors:
1.  Stop the Cb Response services on the sensor (only the master image that will be used for cloning)
     a.   Open a command prompt with administrator privileges.
     b.  Execute the following commands:
          sc stop carbonblack
          sc stop carbonblackk

 

I'm certain that the statement "Stop the Cb Response services on the server (only the master server if clustered)." is wrong because the Cb Response master server can only be a Linux server.

This section should also mention that this information applies to "sensor" endpoints that are cloned, not just sensors in a VDI environment.  Virtual Machines and physical hard drives that are cloned would also need to be treated in the same manner.

Page 109 "Enabling VDI Support"

Really, all of Chapter 6 is pretty confusing.  After a few of my coworkers read and discussed our understanding of how VDI support is supposed to be enabled, this is what we came up with (based on what is written in this guide):

Global VDI support is enabled by editing the cb.conf file and adding the "NewRegistrationCallbackModulePath=" and "NewRegistrationCallbackClassName=" lines, that are described on page 109 of the Integration Guide.

When those have been added, Sensor Group VDI Support settings that you apply to each sensor group are ignored and instead, the NewRegistration Python script will be run for all sensors that attempt to register.  We actually did verify that this is the case with our deployment.

My question is that if you wish to configure Sensor Group VDI Support, what is the process for resolving sensor ID conflicts?  If I specify the "NewRegistrationCallbackModulePath" for the Python script that is supposed to resolve the ID conflicts, then Global VDI Support gets enabled. 

Please revisit the documentation to provide more clarity.  Thank you.  

@tim_duckworth - thank you for your feedback; I have passed along to the doc team.

Ed

@esullivan - I found a document for "Server VDI Support" that was published for Response Version 4.2.5.  It's certainly out dated but helps provide some additional context around the "intent" of how things are supposed to be configured.  Here is a link to the document:  https://community.carbonblack.com/t5/Documentation-Downloads/Carbon-Black-v4-2-5-Server-VDI-Support/...

I'm currently looking to find information on the other options that I can add to the plug-in (such as IP Address and Hostname, instead of just the Hostname) for sensor correlation.  Here is a snippet from the document that references what I'm talking about:

----------------------------------------------------------------------------------------------------------------------------------------------------
The default plug-in provided with the Carbon Black server is shown below:
~~~~~
#
# /usr/share/cb/plugins/default_new_sensor_registration_callback.py
#
from cb.sensor.NewRegistrationCallback import NewRegistrationCallback
from cb.db.core_models import SensorRegistration
class DefaultNewRegistrationCallback (NewRegistrationCallback):
@staticmethod
def get_sensor_id(db_session, sensor_reg_request, logger):
sensor_host_name = sensor_reg_request.ComputerId.ComputerName
sensor_dns_name = sensor_reg_request.ComputerId.ComputerDnsName
sensor = db_session.query(SensorRegistration) \
.filter(SensorRegistration.computer_name == sensor_host_name) \
.filter(SensorRegistration.computer_dns_name == sensor_dns_name) \
.order_by(SensorRegistration.last_checkin_time.desc()) \
.first()

if sensor is not None:
logger.debug("Found sensor id [%d] for hostname [%s @ %s]" % (sensor.id, sensor_return sensor.id
else:
logger.debug("Could not find a sensor id for hostname hostname [%s @ %s]" % (sensor_return 0
~~~~~

The default plug-in (above) performs correlation based on the client hostname. If a
sensor cannot be correlated during registration, the server will treat the registration as a new registration.
The basic requirements for creating a custom plug-in are:
1) Create a python script that contains a class that is a subclass of ’cb.sensor.NewRegistrationCallback.2) Override the static method ’get_sensor_id(db_session, sensor_reg_reguest, logger)’ and perform 3) Configure the server to use the new plug-in

is this applicable for Cb Response Cloud ?

Article Information
Author:
Creation Date:
‎05-31-2018
Views:
5836
Contributors