CB Defense User Guide: CB Predictive Security Cloud
CB Defense User Guide: CB Predictive Security Cloud
Contents
   1   List of Tasks 9
   2   Getting started 11
          Overview 11
          Cb Defense data retention 11
          What this guide contains 11
          Carbon Black technical support 12
          Dashboard 12
              Configure the Dashboard 13
              Attacks Stopped 14
              Potentially Suspicious Activity 14
              Attack Stages 14
              Attacks by Vector 15
              Endpoint Health 15
   3   Manage sensors 17
         View deployed sensors 17
         Update sensors 20
             Update sensors on selected devices 20
         Manage policy assignments 22
             Manually change the default policy for a sensor 22
             Manage sensor groups for automatic policy assignments 23
         Manage Windows sensors from the command line 24
         Enable or disable unattended bypass control for a macOS sensor 25
         Set Windows registry key for Windows Update 26
         Uninstall sensors 27
   4   Manage users 30
         Monitor the Audit Log 31
5 Define premises 32
                  Reputation 38
                  Status 38
                  Policies 38
                  Tags 38
              View search results 39
                  Dismiss alerts 40
          Expand an alert 42
          View primary process affected by an alert 42
          View device details 43
          View and add notes and tags to alerts 43
          Manage alerts across multiple devices 43
   7   Visualize an alert 44
          Process Graph panel 46
          Selected Process panel 47
          Alert origin 48
          Alert behaviors based on severity 49
          Notes & tags 51
   8   Investigate an alert 52
          Search for events to investigate 53
              Filter search results 57
          Investigate events 57
          Investigate applications 58
          Investigate devices 58
          Investigate network connections 58
          Work with Investigate page sub-tabs 58
              View a time line 59
              View the Device sub-tab 59
              View an App sub-tab 59
              View the Notes/Tags sub-tab 60
              View the Alerts sub-tab 60
   9   Respond to incidents 61
          Quarantine a device 61
          Remove malware 62
              Auto-delete known malware 62
              Detected malware 63
              Deleted malware 64
          Use Live Response 65
              Using Live Response 66
              Extend Live Response 71
              Activity logging and downloads 71
   10 Manage reputations 72
        View applications by reputation 73
        Manage reputations from the Investigate page 74
        Manage reputations from the Malware Removal page 74
        Manage reputations by hash 74
        Whitelist IT tools 75
        Whitelist certs 77
        Manage reputations for multiple applications by adding hash 78
        Configure an automatic blacklist 79
List of Tasks
How to . . .
To access notes/tags: 43
To add a connector: 100
To add a new policy: 86
To add a notification: 99
To add a sensor group: 23
To add a user: 30
To automatically remove deregistered sensors: 29
To configure an automatic blacklist: 79
To configure the Dashboard: 13
To copy a rule: 93
To create a local mirror of the Cb Defense local scanning signatures: 137
To create or edit a blocking and isolation rule: 92
To create or edit a permissions rule: 87
To delete a user: 30
To deny or allow upload file paths: 97
To disable Cb Defense WSC integration: 113
To disable Live Response for a set of endpoints (not by policy): 65
To disable unattended bypass control and enable protection: 25
To dismiss an alert on a single device: 40
To dismiss an alert on all devices: 40
To dismiss multiple alerts: 41
To enable background scanning for a policy: 139
To enable Cb Defense WSC integration: 114
To enable cloud analysis: 104
To enable DUO 2FA: 106
To enable Google 2FA: 107
To enable Live Response for a policy: 65
To enable SAML integration with Okta: 107
To enable SAML integration with OneLogin: 111
To enable SAML integration with Ping Identity: 108
To enable unattended bypass control and disable protection: 25
To enable your VMware integration: 147
To end a Live Response session: 71
To generate a company deregistration code: 27
To manage reputations by hash: 74
To manage reputations for multiple applications by adding a hash: 78
To manage reputations from Investigate page: 74
To manage reputations from the Malware Removal page: 74
To manually change the default policy for a sensor or sensors: 22
To manually remove deregistered sensors: 29
To manually request a file upload: 102
To modify user details: 30
Chapt er 1
Getting started
       This chapter describes Cb Defense and this user guide. It explains how to contact Carbon
       Black technical support, and it introduces the Dashboard that serves as the Cb Defense
       home page.
Overview
       Cb Defense is a cloud-based security solution that prevents malware and non-malware
       attacks. It offers streaming prevention technology with detection and response capabilities
       on a single lightweight sensor.
       Cb Defense provides endpoint protection and enables teams to close security gaps by
       providing visibility into endpoints. The Cb Defense technology gathers endpoint telemetry,
       and leverages data science to analyze attacker behavior and respond.
       Cb Defense consists of a lightweight sensor that is deployed to the endpoint and an
       analytics engine on the backend that provides advanced behavioral analytics, searches
       for incident response, configuration, and reporting.
Dashboard
       When you sign in to the PSC, the Dashboard displays as your home page:
       The Dashboard gives you a snapshot of what is going on in your system, and lets you
       quickly navigate to items of interest. It shows you what is occurring on the endpoints that
       Cb Defense protects.
       Use the options at the top of the Dashboard to set the search time for alerts and to specify
       the policy for which alerts should be shown. The default policy selection is All policies.
           Note
           The time window and the optional filtering is applied to the data that is shown
           in each panel with the exception of the Endpoint Health widget — its data is
           not affected by this criteria.
           The time window setting persists across all pages in the Cb Defense
           Management Console unless it is specifically changed on those pages (such
           as Alerts List or Investigate).
       Click Export All to export all the data on the page to a CSV file. Alternatively, you can
       download any individual data set by clicking the down-arrow in that widget. You must have
       pop-ups enabled in your browser for the Export function to work.
           Note
           Cb Defense Management Console sessions timeout after one hour of
           inactivity.
Attacks Stopped
       The Attacks Stopped widget displays a summary of attacks that Cb Defense stopped
       within the specified time frame and policy.
       These attacks were all stopped due to a policy setting (see “Prevent attacks through
       policies”).
       This widget is interactive: you can click any of the attack types to open the Alerts List
       page for the selected type of attack (see “Alerts List page”).
       The attack types are defined in the following table.
Attack Stages
       The Attack Stages widget of the Dashboard contains an attack stages bar graph for the
       specified time frame and policy.
       The bar graph is interactive. You can click on a bar to access the Alerts List page and
       view more details on the associated alerts (see “Alerts List page”).
       The attack stages are defined in the following table:
        Stage                        Description
        Reconnaissance               Research, identify, and select targets.
        Weaponize                    Create a deliverable payload.
        Delivery/Exploitation        Deliver and initiate code.
        Install/Run                  Install a back door to allow persistent access.
        Command & Control            Communicate with the code from an external
                                     device.
        Execute Goal                 Achieve objective.
Attacks by Vector
       The Attacks by Vector widget shows the vectors through which attacks occurred within
       the specified time frame and policy.
       This widget is interactive: you can click any percentage to open the Alerts List page for
       the selected type of vector (see “Alerts List page”).
Endpoint Health
       The Endpoint Health widget displays the status of the sensors on the endpoints. The
       states in this widget are interactive; click any state to go to the Endpoints page and view
       the deployed sensors that are in the selected state. See “View deployed sensors”.
       Red text indicates that a sensor might require some action (for example, take the sensor
       out of quarantine or bypass mode).
       The following table describes the sensor categories:
        Stage                        Description
        Active                       The sensor is registered and has checked in within the
                                     last 30 days.
        Inactive                     The sensor is registered, but it has not checked in for
                                     more than 30 days.
        Deregistered                 The sensor has been uninstalled.
        Eligible for Update          You can update your sensors to a more current
                                     version. See “Update sensors”.
        Quarantined                  An administrator has quarantined the sensor. In this
                                     mode, the sensor host can communicate with Cb
                                     Defense only. See “Quarantine a device”.
        Stage           Description
        Bypass          Either an administrator or an end user has put this
                        sensor into bypass mode. The sensor does not send
                        any data to the Cb Defense backend while it is in this
                        state.
                        Sensor Bypass (User Action) - An end user placed the
                        sensor in bypass from the Sensor UI, if this is enabled.
                        See “Cb Defense Settings tab”.
                        Sensor Bypass (Admin Action) - An administrator
                        placed the sensor in bypass from the Cb Defense
                        Management Console.
Chapt er 2
Manage sensors
      A PSC sensor is installed on every Windows and macOS endpoint that Cb Defense
      protects. The sensor communicates with Carbon Black analytics and the Cb Defense
      Management Console.
      This chapter describes how to view, update, and uninstall PSC sensors, and how to
      manage sensors by using sensor groups.
      To install PSC sensors, see the PSC Sensor Installation Guide.
       Title           Description
       Status          An icon that represents the status of the sensor. See Table
                       6, “Sensor status types”.
       Device          The host name of the endpoint on which the sensor is
       Name            installed.
       User            The user who registered the sensor.
       Device Info     The operating system and sensor version that is running on
                       the endpoint.
       Group/          The sensor group to which the sensor belongs. See
       Policy          “Manage policy assignments”.
                       If the sensor is not a member of a sensor group, and was
                       manually assigned a policy, it is listed here as Manually
                       assigned. If the sensor metadata does not match any group
                       criteria, it is listed as Unassigned.
                       The policy to which the sensor belongs. See “Prevent
                       attacks through policies”.
       T               Target value of the endpoint. See “Target value”.
       Last Check- The last time that the sensor connected with the Cb
       in          Defense backend.
       Title          Description
       Take Action    Three icons can display here:
                      The Investigate icon opens the Investigate page.
The trash can icon deletes a pending sensor from the list.
      You can filter the list by Policy or by Status. To do so, click the corresponding dropdown
      menu. For a list of sensor status types, see Table 6, “Sensor status types”.
      You can sort the table contents by the column headings that have a down-arrow next to
      them, and you can search for specific sensors. You can search using the boolean operator
      NOT to find all sensor versions other than the latest version. For example:
      •   Searching for "NOT 3.2.0.213" returns a list of all sensors that are not at version
          3.2.0.213.
      •   Searching for "-3.2.0.213" returns a list of all sensors older than 3.2.0.213.
      •   Searching for "NOT 3.2.0.213 NOT 3.0.2.2" returns a list of sensors that are not
          version 3.2.0.213 or 3.0.2.2.
      You can view additional sensor information by clicking the > next to a sensor name. This
      action displays the following sensor data:
      •   Device ID
      •   Internal IP address
      •   External IP address
      •   Date that the sensor registered with Cb Defense
      •   Scan engine version
      •   Live Response status
      If you have created sensor groups (see “Manage sensor groups for automatic policy
      assignments”), you can click the name of a sensor group to display only the sensors that
      belong to that sensor group. In this case, the following additional information displays:
      •   Number of sensors that belong to the sensor group.
      •   The operating system of the sensors that belong to the sensor group, based on the
          defined criteria. This can be Any, Windows, or macOS.
      •   The policy assignment for sensors in this sensor group.
      •   The criteria that defines membership in the sensor group. If you have multiple
          conditions for membership, click More to see all of the conditions.
      You can filter the list of displayed sensors by Status.
Update sensors
      It is important to keep your sensors up-to-date. For supported operating systems and
      sensor versions, see Supported Carbon Black sensors and agents.
      There are two ways that you can manage sensor updates:
      •     You can update sensors on devices that you select. In this case, you can update up to
            100 sensors at a time to minimize network degradation. See “Update sensors on
            selected devices”.
      •     You can reinstall the sensors. See the PSC Sensor Installation Guide.
          Notes
          In some cases, updating a sensor can cause Windows to reboot without
          warning. Keep this in mind when updating sensors on critical machines.
          The macOS 3.0 and later sensor requires KEXT approval to upgrade on High
          Sierra+. If the devices are not provisioned with the approval, the sensor enters
          bypass mode. Carbon Black recommends using an MDM solution to push the
          approval before you upgrade.
          See How to approve Mac Sensor 3.0 KEXT for Install/Upgrade.
      5. From the Version dropdown menu, select the sensor version. Select the checkbox to
         acknowledge that devices might be rebooted, and then click the Update button.
        Note
        If you select more than 100 devices to update, a warning displays that you can
        only update 100 sensors at a time. You have the option to update the first 100
        sensors.
          Note
          Sensor groups and automatic enrollment are only available for the Windows
          v3.1 and macOS v3.2 or later sensor versions.
      Metadata for Cb Defense sensors below Windows v3.1 or macOS v3.2 includes:
      •   Operating system (Any, Windows, macOS)
      •   Device host name
      •   Subnet (The subnet filtering is applied to the internal IP address of the sensor.)
          c. Add criteria that is based on the sensor metadata. For example, you can specify
             an Active Directory organizational unit of Finance, or a subnet range that begins
             with 192.
          d. Continue to add criteria until you have completed your specification.
      5. Specify the policy to which the sensors will be added by using the Policy dropdown
         menu. The default policy is the Standard policy.
      6. Click Save.
      The new sensor group is shown as Processing in the top left corner of the Endpoints
      page. Cb Defense waits two minutes for you to continue making changes before it
      processes those changes. The status then changes to Up to Date. Sensors populate the
      new sensor group as they check in with Cb Defense.
      After you create a sensor group, it displays on the left side of the Endpoints page. You
      can click the >> to show additional sensor group information.
      Sensor groups are processed from the top of the list down. For example, a sensor might fit
      into multiple sensor groups based on the criteria that you create. However, a sensor can
      only belong to one sensor group. In this case, the sensor will be added to the first sensor
      group that displays on the page.
      You can reorder the list of sensor groups to change the processing order: click Edit and
      then drag the sensor group to a new location in the list.
      Click any sensor group to view only those sensors that belong to that group. In the right
      pane, the sensors are displayed in the table view that is described in “View deployed
      sensors”.
      The updated status displays on the Sensor Management page, and on the endpoint UI if
      it is enabled.
      After you set ALLOW REGKEY, each Windows 3.1 or later sensor installs the registry key
      the next time that it checks in with Cb Defense.
      After it is successfully installed, the following reg key/value is created:
      Key="HKEY_LOCAL_MACHINE"Subkey="SOFTWARE\Microsoft\Windows\Current
      Version\QualityCompat"
      Value Name="cadca5fe-87d3-4b96-b7fb-a231484277cc"
      Type="REG_DWORD”
      Data="0x00000000”
        Note
        Any user who has admin rights can manually delete the registry key. Microsoft
        recommends that the key not be changed or deleted after it is created.
Uninstall sensors
      You can uninstall sensors on endpoints by using the PSC console or at the endpoint.
      If you are have deployed v3.1 or later sensors, you can protect the action of uninstalling
      the sensor at the endpoint by requiring a unique, randomly-generated code. This setting is
      enabled per policy. Note that the uninstall code is case-sensitive.
      To require a code to uninstall a sensor at the endpoint:
      1. Sign in to the PSC, click Enforce, and then click Policies.
      2. Select the policy for which you want to enable this feature.
      3. On the Cb Defense Settings tab, select the Require code to uninstall sensor
         checkbox.
      4. Click Save to save your changes.
      After you have enabled this setting, a user must have an individual device uninstall code
      or a company deregistration code to uninstall the sensor from the endpoint. No code is
      required to uninstall sensors by using the PSC console.
      An individual device uninstall code is automatically generated when a sensor is registered
      with Cb Defense.
      To view a sensor uninstall code:
      1. Sign in to the PSC and click Endpoints.
      2. Click the > next to the sensor. The uninstall code displays below the basic sensor
         data.
      You can also generate a company deregistration code, and use this code to uninstall any
      sensor in your organization.
        Warning
        The company deregistration code can be used to uninstall all sensors in your
        organization. If you do not want a single code that can be used across your
        organization, do not generate the company deregistration code.
        Tip
        You can uninstall multiple sensors by using batch files or system management
        tools.
        Note
        By default, this mode is interactive and requires a confirmation prompt unless
        you specify the -y parameter. To view all command line parameters, run the
        command together with the -h parameter.
Chapt er 3
Manage users
       Each Cb Defense user must log into Cb Defense by using a user name and password.
       There are three types of users:
       •   Full administrative rights.
       •   Full administrative rights plus Live Response administrator rights.
       •   View-only rights. If a user has view-only rights, some elements of the user interface,
           such as Take Action, do not display.
       The Live Response Administrator role supersedes the Administrator role; this privilege
       can only be granted by another user who has Live Response Administrator rights. For
       existing customers, all users that have the Administrator privilege are promoted to the Live
       Response Administrator role. We encourage you to audit your users and demote any
       administrators who should not have Live Response access.
       This chapter explains how to manage Cb Defense users and view audit logs.
       To view users:
       1. Sign in to the PSC, click Settings, and then click Users.
           A list of all current users displays.You can sort the list by first name, last name, email,
           or role, and you can search for users.
       To add a user:
       1. Sign in to the PSC, click Settings, and then click Users.
       2. Click Add user.
       3. Enter the details for the new user and then click Add.
       4. An email is sent to the new user, inviting the user to log in and create a password.
          Passwords must have the following characteristics:
           -   At least one lowercase letter
           -   At least one uppercase letter
           -   At least one number
           -   At least one special character
           -   Be at least 8 characters long
       To delete a user:
       1. Sign in to the PSC, click Settings, and then click Users.
       2. Click the down-arrow next to the Edit button next to the user to delete.
       3. Click Delete.
       2. Use the Flagged and Verbose slider buttons in the top-right corner to speed up
          performance and remove unnecessary logs from the Audit Log table:
           -   Flagged - When this option is enabled, the Audit Log table contains only flagged
               entries. For example, a user logs into Cb Defense from a suspicious IP address
               (the IP address is not one of the last five IP addresses that the user has used to
               login). This activity is marked as flagged.
           -   Verbose - When this option is disabled, the Audit Log table contains only view
               actions. When enabled, the table contains edit/update/create actions. The default
               setting for this option is Verbose = Off.
Chapter 4
Define premises
       Cb Defense lets you define the boundaries of your organization’s premises. This is useful
       for determining if endpoints are on- or off-premises at the time of an attack.
       This chapter describes how to define your premises.
       The Fully Qualified Domain Name (FQDN) and IP address are two conditions that can be
       used for the sensor to present as on- or off-premises.
       Any device that has a relevant FQDN registered on the network adapter presents a valid
       condition for the device to be recognized as on-premises. If the device is also connected
       to the organization’s network and the sensor can ping one or more of the defined IP
       addresses in Reachable Hosts, then it is also a condition that defines the device as on-
       premises. One or both of the conditions must be met for the device to be considered on-
       premises. If neither condition is met, the device is off-premises.
        Note
        If a home network or remote network device has a matching condition in
        Reachable Hosts, the condition can be met and therefore the sensor reports
        that it is on-premises when it is actually off-premises.
       To set up premises:
       1. Sign in to the PSC, click Settings, and then click General.
       2. Perform one or both of the following actions:
           a. Add your domain in the DNS suffix textbox and click Add.
Chapt er 5
Alert severity
       All alerts detected by Cb Defense are grouped together based on severity. You should
       consider the alert severity and the alert priority when setting up notifications (see
       “Notifications and connectors”).
       •   Threat – Highly likely that this is malicious activity.
       •   Monitored – A set of behavioral data that has not been raised to the level that
           requires a response, but does have interesting behavior that might be destructive.
Priority score
       The priority score prioritizes the relative importance of an alert and is loosely mapped to
       the Attack Stages Panel. (See “Attack Stages”.)
       In general, the higher the score, the further along an adversary or attack has progressed
       toward achieving its goal. For example, if the goal of a particular malware is to persist, this
       does not result in a high alert priority. If its goal is to encrypt user data, steal passwords,
       damage system files, and so on, this alert receives a higher alert priority.
       Examples:
       •   Level 1 and 2 alerts – Detect activities such as port scans, malware drops, changes
           to system configuration files, persistence, and so on.
       •   Level 3, 4, and 5 alerts – Detect activities such as malware running, generic virus-like
           behavior, monitoring user input, potential memory scraping, password theft, and so
           on.
       •   Level 6+ alerts – Typically an active exploit, reverse command shells, process
           hollowing, destructive malware, hidden processes and tool sets, applications that talk
           on the network but should not, and so on.
Target value
       A target value is defined by the policy to which a device belongs (see “Prevent attacks
       through policies”). It acts as a multiplier when calculating the threat level for any threats
       that are detected on a particular device.
       •   Low Target Value – Results in a lower threat level.
       •   Medium Target Value – Represents the baseline (no multiplier).
       •     High and Mission Critical Target Values – Both increase the threat level under the
             same circumstances. As a result, you might see two or more alerts with identical
             descriptions but different alert priorities.
           Tip
           For a visual representation of an alert, see “Visualize an alert”.
       The Alerts page lets you search for alerts, set the time span for searched alerts, toggle
       Group Alerts ON or OFF, and save your search criteria.
       After you select an alert, the top panel of the Alerts page provides information about the
       selected alert, such as the primary process (see “View primary process affected by an
       alert”) or device details (see “View device details”). You can close the top panel by clicking
       the X in the top right corner of the panel. The panel automatically re-opens when you
       select a new alert.
       Select and press Enter to select a key-value pair. Selecting a key-value pair returns faster
       search results.
       If you enter multiple key-value pairs in the search text box, an AND operator automatically
       exists between each key-value pair. You can change the AND operator to OR or NOT.
       Saved searches also display in the search text box as you type in the name of the search.
       For example, the two key-value pairs shown in the following image returns all alerts that
       have a COMMON_WHITE_LIST reputation and that occurred on devices that are running
       the Windows operating system:
The following table lists the key-value pairs for the Alerts page.
        threat source      The vector from which an event        app_store, removable media,
                           or alert was triggered.               other_net_protocol,
                                                                 remote_drive, web, email
       You can toggle key-value pairs OFF by clicking the Enable Advanced Search button. To
       toggle key-value pairs ON, click Disable Advanced Search.
           Note
           Key-value pairs are suggestions, not requirements. You do not have to use
           key-value pairs to make a query.
       You can perform a basic search of key phrases or terms. Single words can be entered
       without any special characters; multiple words or phrases should be surrounded by
       quotation marks. This enables CB Defense to understand the words or phrases as a
       single search term rather than multiple search terms.
       When searching, the term or terms can be found in the alerts. This includes searching for
       items such as the event ID, descriptions of the events, the different tactics, techniques,
       and procedures (TTP), information in the event summary, and others.
       For applications, you can search for specific items such as application names, hashes,
       and reputations. For devices, you can search for specific items such as device names,
       policies, operating systems, and users (that is, the email addresses that were used when
       enrolling sensors). For a network, you can search for on- or off-premises, IP addresses,
       ports, and connection types.
       You can perform powerful searches for events, applications, devices, or network
       information. You can use Boolean operators and wildcards as part of the search. Searches
       are not case sensitive.
       Multiple terms can be combined in searches. Logical operators enable specific conditions
       to be met in matching a search.
       •     OR shows results when either specified condition is true; for example, you can search
             for the domain name OR the IP address.
       •     AND shows results when both conditions are true. For example, you can search for
             both a port AND a protocol, or an application AND the device it ran on.
       •     NOT searches for condition exclusions. For example, a search for KNOWN_
             MALWARE but NOT zbot.exe malware returns all known malware that is not zbot.exe.
       You can use a trailing asterisk after the first three or more characters as a wildcard for one
       or more characters. A trailing question mark matches on phrases with a single character in
       place of the question mark.
       Simple search example:
       powershell*
       This search returns all alerts that contain PowerShell.
       Advanced search example:
       “github.com” OR “192.198.55.55” (TCP AND 443) OR (UDP AND 80)
       KNOWN_MALWARE AND NOT zbot.exe
       This search returns all alerts that originate from github.com or an IP address of
       192.198.55.55 on port 443 or UDP on port 80, that are known malware but are not
       zbot.exe.
           Tips
           You can return all policy actions (blocks/terminations) by searching for
           POLICY_TERMINATE or POLICY_DENY. You can use the OR operator to
           search for both.
           Click the ? next to the Search text box to view more search examples and
           tips.
           See “Advanced search terms” for a complete list of advanced search query
           terms.
       The search results in the table are updated according to your search parameters. The
       searches are cumulative, so if you perform multiple searches, click Clear All before
       starting new searches. Click Save at the top of the page to save your search.
       Category
       The Category list contains two category types and two adjustable filters.
       Threat category
       The Monitored category represents a set of behavioral data that has not yet been raised
       to the level that requires a response, but does have interesting behavior that might be
       destructive.
       The Threat category represents a set of behavioral data and contextual information that
       indicates malicious behavior.
       Target value
       The bar filter to the left contains four bars, which let you filter devices by target value (see
       “Target value”). Click + to increase the target value and click - to decrease the target
       value.
       •     1 = Low
       •     2 = Medium
       •     3 = High
       •     4 = Mission Critical
       Alert Priority
       You can filter alerts by Priority (P) score. The scale is from 1 to 10, with 1 being the lowest
       priority score. (See “Priority score”.) Click - to decrease the priority score, and click + to
       increase the priority score.
       Devices
       The Devices list lets you filter alerts to focus on particular devices. You can display all
       alerts on a single device or on multiple devices.
       Applications
       Many attacks involve multiple applications. You can narrow the list of displayed alerts to
       show only those alerts that involve specific applications.
       Workflow
       The Workflow list filters threats based on whether they are still being monitored by your
       team or have been dismissed. You can dismiss an alert on this page or on the Alert
       Triage page For more information about the Alert Triage page, see “Visualize an alert”.
       Reputation
       The Reputation list lets you filters search results based on the reputation of involved
       objects. The reputations are:
       •   Not listed
       •   Suspected malware
       •   Common white list
       •   PUP
       •   Trusted white list
       •   Known malware
       See “Manage reputations”
       Status
       The Status list lets you filter results to see only those alerts in which a prevention policy
       was applied, or those cases where malware ran or did not run. The status list is as follows:
       •   Did not run
       •   Ran
       •   No policy applied
       •   Policy applied
       Policies
       The Policies list lets you filter results based on the policy to which the sensor was
       assigned when the alert was created. See “Prevent attacks through policies”.
a
       Tags
       The Tags list contains tags (short labels) that you can assign to alerts. You can sort and
       search by tags.
        Note
        If you set Group Alerts to ON, identical threats on multiple devices are
        grouped together in the Alerts Results table. See “Manage alerts across
        multiple devices”.
        Column            Description
        Checkbox          You can select the checkbox next to an alert or group of alerts to
                          select the alerts for dismissal. You can select all viewed alerts by
                          clicking the checkbox above the search results table. Note that this
                          selection only includes those alerts that you can view on the current
                          page - not all alerts in the organization. See “Dismiss alerts” on page
                          40.
        P                 The P column indicates the Priority score that is associated with the
                          alert. See “Priority score”.
T The target value associated with the alert. See “Target value”.
        Device            Contains information about the devices that were associated with the
                          alert. The user email address and device hostname are provided.
                          Note that this column does not display if you are viewing a grouped
                          alert.
        Take Action       The Take Action column presents several options that let you
                          interact with the alert, as shown in Table 9, “Action options”.
        Icon                  Description
                              Indicates a grouped set of alerts. Click this icon to ungroup them.
                              Click this icon to view additional actions that you can perform on the
                              alert:
                              • Dismiss an alert.
                              • View the alert’s notification history.
       Dismiss alerts
       There are several ways to dismiss alerts. You can dismiss an alert on a single device or on
       all devices. You can dismiss multiple alerts at one time, and you can dismiss all future
       occurrences of an alert. Dismissed alerts display in the Audit Log.
       When you dismiss an alert, you can provide an optional reason for the dismissal. The
       following reasons are listed for you:
       •     False positive
       •     Alert list cleanup/duplicate
       •     Known good software/behavior
       •     Investigated/escalated
           Note
           Email notifications are not associated with alert dismissals. If you dismiss
           all future alerts, you will still receive email notifications about the alerts.
           Note: Alerts can present different SHA256 hashes. To dismiss an alert on multiple
           devices, the hash of the object must be the same.
       4. Optionally, to dismiss all future occurrences of the alert, select the checkbox for If this
          alert occurs in the future, automatically dismiss it from all devices.
           Note: The option to dismiss future alerts is based on unique identifiers such as hash
           and TTP. If any identifier changes, you will receive the alert again.
       5. Click Dismiss.
Expand an alert
       To expand an alert, click the > to the left of the Status column. This expands the view of
       the alert to show you additional information:
           Note
           The Product field refers to the name of the product to which the
           application belongs. For example, cmd.exe belongs to the Windows
           operating system.
       To perform actions on the alert, click the down-arrow next to Take Action. You have the
       following options:
       •     Add the application to your organization’s whitelist or blacklist. See “Manage
             reputations”.
       •     Terminate the application process.
       •     Upload the application for analysis. See “Upload suspicious files”.
       •     Find in VirusTotal to see current information about the hash from various sources.
       •     Delete the application. The application is deleted one time from this endpoint only, or
             you can delete the application on all endpoints.
             Important: If you delete the application on all endpoints, this action permanently
             deletes the application from all endpoints in your organization. You cannot undo a
             deletion. You can view the deleted application in your Inbox.
Grouping alerts lets you dismiss an alert across multiple devices. See “Dismiss alerts”.
Chapt er 6
Visualize an alert
       The Alert Triage page provides a visualization of an alert:
       You can access the Alert Triage page from the Alerts page (see “View and take action on
       alerts”) or from the Investigate page (see “Investigate an alert”).
       If you create notifications, the alert link in the notification email takes you directly to the
       Alert Triage page. See “Notifications and connectors”.
       The top panel of the Alert Triage page is called the Alert Triage Reason panel, and it
       provides the information that is listed in the following table.
        Item               Description
        Alert Triage ID    Unique ID that Cb Defense has generated for this alert.
        Attack Type        The type of attack that was detected. For more information about
                           attack types, see Table 2, “Attack types”.
Date and Time Date and time when the alert first occurred.
        Priority Score     The scale is from 1 to 10, with 1 being the lowest priority score. See
                           “Priority score”.
        User               The name of the user who was logged into the host at the time of the
                           alert.
        Operating          The operating system that was running on the host device at the time
        System             of the alert.
        Location           Whether the host device was on- or off-premise at the time of the
                           alert.
Target Value The target value of the device. See “Target value”.
       The attack origin displays on the left side of the image. Each subsequent event in the
       attack stream is shown going from left to right as the attack progressed. You can pan your
       view in this panel, and you can zoom in and out to see more or less detail. You can click
       and drag the entire image around the panel.
       The process tree has four node types:
       •   The root node at the far left of the process tree represents the host device on which
           the original activity took place. The root node icon represents the operating system
           that was running on the device. When applicable, the device name, user name, and IP
           address of the device are also shown.
       •   Processes that have run or are still running are shown as gears in the process tree.
           The name of the process is displayed. You can click any process in the stream to see
           details about that process in the Selected Process panel (see “Selected Process
           panel”).
       •   Files that were created on disk are shown as documents in the process tree. The file
           name is displayed. You cannot click a file for additional information.
       •   IP addresses are shown as network connection icons. You cannot click an IP address
           for additional information.
       If an operation is denied, an exclamation point (!) displays in the graph next to the denied
       process. If a process is terminated, an X displays in the graph next to the terminated
       process.
       The process tree can show four different line types:
       •   Invoked: A solid line indicates that one process invoked another process, file, or
           network connection.
       •   Injected: A dashed line indicates that one process injected code into another process.
       •   Read Memory: A dotted and dashed line indicates that one process attempted to read
           the virtual memory of another process (but did not inject into the process).
       •   Accessed Target: A dotted line indicates that one process attempted to enter another
           process (but did not inject into the process).
        Item              Description
        App Origin        The origin of the selected process.
Date and Time Date and time that the process ran.
        Malware           Whether the application is known malware. This field includes the
                          vector, the malware name, and the malware type.
        Item                  Description
        Signature             Indicates whether the application is signed.
        Verification
        TTP                   The Tactics, Techniques, and Procedures (TTPs) that are associated
                              with the selected process. The color of the circle represents the
                              severity of the TTP. For a color legend, see Table 13, “TTP color
                              severity legend”. See “TTP reference”.
           Important
           If you delete the application on all devices, this action permanently
           deletes the application from all devices in your organization.
Alert origin
       The bottom left panel of the page describes how the primary process for the alert was
       introduced onto the host. The Description field includes detailed information about how
       the primary process was written to disk. Files that pre-existed the install of Cb Defense
       display as Detected by Cb Defense.
       The segments of the graph are labeled by TTP category. Table 12, “Alert behaviors
       categories” describes these categories.
        Category           Description
        Data at Risk       Focuses on behaviors that have the intent of compromising the
                           confidentiality, availability, or integrity of data on the endpoints that
                           Cb Defense is protecting. Examples of TTPs that fall into this
                           category are ransomware type behaviors and attempts to access
                           user credentials.
        Malware &          Represents TTPs that are related to files, either executables or
        Application        common script types, that generally have a known bad reputation - or
        Abuse              applications that are seen executing files with known bad reputations.
                           This category also represents the monitoring of the execution of
                           system applications, although these TTPs are given a lower priority
                           rating because of the high likelihood of being non-malicious actions.
        Network Threat     Contains all TTPs that involve a process that is either communicating
                           over the network or listening for incoming connections.
       You can click any category label on the graph to see its related TTPs. To see all TTPs that
       are associated with the alert, click the blue highlighted section of the graph. See “TTPs”.
       TTPs are shown in colors that reflect the severity of the alert. The colors and their severity
       status are listed in the following table.
        Color              Severity
        Dark red           Severe
Orange Medium
        Color              Severity
        Yellow             Low
Gray None
Chapt er 7
Investigate an alert
       You can examine and analyze alerts on the Investigate page. You can access the
       Investigate page from:
       •   The Navigation bar.
       •   The Alerts List page (see “Alerts List page”).
       •   The Endpoints page (see “View deployed sensors”).
       •   The Alert Triage page (see “Visualize an alert”).
       All tabs contain an Event Time Line sub-tab. See “View a time line”.
       The four main tabs can contain other sub-tabs, depending on your filter selections and the
       characteristics of the event:
       •   Devices sub-tab - See “View the Device sub-tab”.
       •   Parent App, Selected App, and Target App sub-tabs - See “View an App sub-tab”.
       •   Notes/Tags sub-tab - See “View the Notes/Tags sub-tab”.
       •   Threat sub-tab - See “View the Notes/Tags sub-tab”.
The following table lists the key-value pairs for the Investigate page.
        attack stage     Attack stage of the event. See       recon, weaponize, deliver/expl,
                         “Attack Stages”.                     inst/run, cmd+ctrl, execute goal
       You can type in a granular search term to find very specific alerts. For example, each alert
       has multiple types of reputations. You can search for all.reputation, parent.reputation,
       target.reputation, or primary.reputation. The following table lists the available granular
       terms.
       You can toggle key-value pairs OFF by clicking the Enable Advanced Search button. To
       toggle key-value pairs ON, click Disable Advanced Search.
        Note
        Key-value pairs are suggestions, not requirements. You do not have to use
        key-value pairs to make a query.
       You can perform a basic search of key phrases or terms. Single words can be entered
       without any special characters; multiple words or phrases should be surrounded by
       quotation marks. This enables CB Defense to understand the words or phrases as a
       single search term rather than multiple search terms.
       When searching, the term or terms can be found in the events. This includes searching for
       items such as the event ID, descriptions of the events, the different tactics, techniques,
       and procedures (TTP), information in the event summary, and others.
       For applications, you can search for specific items such as application names, hashes,
       and reputations. For devices, you can search for specific items such as device names,
       policies, operating systems, and users (that is, the email addresses that were used when
       enrolling sensors). For a network, you can search for on- or off-premises, IP addresses,
       ports, and connection types.
       You can perform powerful searches for events, applications, devices, or network
       information. You can use Boolean operators and wildcards as part of the search. Searches
       are not case sensitive.
       Multiple terms can be combined in searches. Logical operators enable specific conditions
       to be met in matching a search.
       •     OR shows results when either specified condition is true; for example, you can search
             for the domain name OR the IP address.
       •     AND shows results when both conditions are true. For example, you can search for
             both a port AND a protocol, or an application AND the device it ran on.
       •     NOT searches for condition exclusions. For example, a search for KNOWN_
             MALWARE but NOT zbot.exe malware returns all known malware that is not zbot.exe.
       You can use a trailing asterisk after the first three or more characters as a wildcard for one
       or more characters. A trailing question mark matches on phrases with a single character in
       place of the question mark.
       Simple search example:
       powershell*
       This search returns all events that contain PowerShell.
       Advanced search example:
       “github.com” OR “192.198.55.55” (TCP AND 443) OR (UDP AND 80)
       KNOWN_MALWARE AND NOT zbot.exe
       This search returns all events that originate from github.com or an IP address of
       192.198.55.55 on port 443 or UDP on port 80, that are known malware but is not zbot.exe.
       After you have entered your query, press [Enter].
           Tips
           You can return all policy actions (blocks/terminations) by searching for
           POLICY_TERMINATE or POLICY_DENY. You can use the OR operator to
           search for both.
           Click the ? next to the Search text box to view more search examples and
           tips.
           See “Advanced search terms” for a complete list of advanced search query
           terms.
       Searches are cumulative, so if you perform multiple searches, click Clear All before you
       start a new search. Click Save at the top of the page to save your search.
Investigate events
       On the Investigate page, the Events tab is selected by default. This tab lets you
       investigate the details of every event that is stored in Cb Defense. These events include
       but are not limited to all failed and successful operations that are performed by
       applications that are installed on the device. If the operation was blocked or terminated by
       Cb Defense, then the following TTP(s) will be attached to the event: POLICY_DENY or
       POLICY_TERMINATE.
       You can view all events within the time frame that you specify, and you can sort the table
       by the time of the event.
       The application reputation at the time of the search displays on the tab. For example, an
       application that was previously unknown has a reputation of not listed. However,
       sometime after the event, the reputation is upgraded to common white. In this case,
       common white displays in the search results.
       For more information about application reputation hash values, see
       Cb Defense: How to Confirm Reputation of a Hash at the Time of Policy Action.
       You can click the hyperlinked application name to search for all events that are associated
       with the application, or click the hyperlinked hostname to search for all events on that
       endpoint.
th
       For more information about the displayed data, see the following content:
       •   “Category”
       •   “Attack Stages”
       •   “Priority score”
       •   “Manage reputations”
       •   “TTP reference”
To expand an event, click the > at the left side of the event row.
Investigate applications
       The Applications tab gives a detailed report on the total number of events that the unique
       application hashes generate. You can select any application hash to view additional
       details of that application, as well as manage its reputation and take action. The reputation
       that you assign to the application is applied to all protected endpoints.
       A reputation is the level of trust or distrust that is afforded an object. Cb Defense file
       reputations are based on multiple sources of known good and known bad objects. See
       “Manage reputations”.
th
       To change the reputation of individual applications, click Whitelist or Blacklist next to the
       application.
Investigate devices
       The Devices tab gives a detailed report on the total number of events that devices
       generate. You can select any device to view additional details for that device and take
       action on that device.
For more information, click the > to the left of the event.
Tip: From any sub-tab, you can click the Alert Triage icon to go to the Alert Triage page.
       The Time Line sub-tab contains an interactive time line that lets you view event details for
       a snapshot in time.
       A blue bar shows the date on the graph when the event occurred. You can hover over the
       time line, and the number of events that occurred at the hover point displays.
       You can further refine the time segment. Slide the gray time line bar to the right and left to
       view alert details for the time period in which you are interested. The search results table
       is updated according to your selection.
           Note
           The time line is based on the local time zone of the browser. This might differ
           from the time zones of the individual endpoints and events.
           Notes
           Make sure that you are selecting the correct application to delete. You
           can delete the Selected Application, the Target Application, or the Parent
           Application.
           If you delete an application on all devices, this action permanently deletes
           the application from all devices in your organization. You cannot undo a
           deletion. You can view the deleted application in your Inbox; see “To view
           files in your Inbox:”
       From this tab, you can save a STIX document that contains the alert data.
       To save a STIX document:
       1. Click Share in the upper right corner of the description.
       2. Click Download a STIX document.
Chapt er 8
Respond to incidents
       This chapter describes Cb Defense incident response features.
       Cb Defense provides the following methods for directly responding to threats:
       •   You can quarantine an endpoint from the rest of the network. After being quarantined,
           the endpoint has network access to the Cb Defense backend only.
       •   You can directly remove known malware from endpoints.
       •   You can use Live Response to end a process and perform any other file removal or
           necessary repairs on an endpoint.
Quarantine a device
       There are three ways to quarantine an endpoint into Cb Defense:
       •   On the Investigate page. See “View the Device sub-tab”.
       •   On the Alert Triage page. See “Visualize an alert”.
       •   On the Endpoints page. This method is described here.
Remove malware
       You can remove malware from endpoints by using the Cb Defense Management Console.
       Malware can exist on an endpoint even if Cb Defense prevents the malware from running.
       You can view and delete all malware files in your organization on the Malware Removal
       page. Historical malware data that has been collected over the past six months displays
       on this page. It can take several days for this data to populate.
       Malware removal includes the bulk deletion of a hash. You can delete malware across
       your entire organization by initiating a single action.
           Warning
           You cannot restore a deleted file. The deletion is permanent.
Detected malware
       The following information displays for detected malware on the Malware Removal page.
        Item                     Description
        Hash                     The hash of the malware file. Only the first five characters and
                                 last five characters of the hash display. You can highlight and
                                 right-click the hash to copy the hash. You can click the hash to
                                 open the Investigate page for this item. See “Investigate an
                                 alert”.
First Seen The date and time at which the malware was first detected.
        Last Deleted             The last date and time that the malware was deleted from this
                                 endpoint.
        Auto Delete in           The number of days remaining before this malware is deleted, if
                                 auto-delete is enabled.
       You can search for specific malware by using the Search text box at the top of the page,
       and you can sort the list of items by the following columns:
       •   Hash
       •   File
       •   Device
       •   First Seen
For more information about whitelists and blacklists, see “Manage reputations”.
Deleted malware
The following information for deleted malware displays on the Malware Removal page.
        Item                  Description
        Hash                  The hash of the malware file. Only the first five characters and
                              last five characters of the hash display. You can highlight and
                              right-click the hash to copy the hash. You can click the hash to
                              open the Investigate page for this item. See “Investigate an
                              alert”.
First Seen The date and time at which the malware was first detected.
        Last Delete           The date and time when the delete request was sent to the
        Requested             sensor
        Status                The status of the deletion. The status can be any of the following:
                              • Detected - the malware exists on a device.
                              • Delete Pending - Delete was requested; waiting for the device
                                to perform the deletion.
                              • Deleted - The device reports that the deletion has occurred.
        Notes
        The Live Response feature should be used in compliance with your
        organization's policy on accessing user's computers and files.
        Cb Defense Live Response is programmatically available through an API. For
        more information, see
        https://developer.carbonblack.com/.
        To use Live Response, you must be a Live Response administrator. See
        “Manage users”.
        Note
        If you disable Live Response in this way, you must re-deploy the sensors to
        the endpoints to re-enable Live Response for those endpoints.
       Note: You can only initiate a session with a 3.0 or later sensor that has Live Response
       enabled through policy, and that has checked in within the last 10 minutes.
       The Live Response console appears with a command window on the left and an
       information panel on the right. The command window prompt shows the device ID and the
       current directory in which Live Response is active.
       In the command window, a status indicator and message display. The status indicator
       uses the following color code:
       •   Green – The sensor is connected and a session is established. The host name for the
           endpoint displays.
       •   Yellow – The Cb Defense backend is waiting for the sensor to check in, or no endpoint
           is connected because no session is attached.
       •   Red – A session cannot be established with the sensor because the endpoint is
           offline, the sensor is disabled, or the sensor version does not support Live Response.
       To view a list of the available commands, click in the command window area and type the
       help command. You can get help about a specific command by typing help
       commandname.
       In the Information panel, the following details are displayed:
       •   The name of the endpoint.
       •   The policy to which the sensor belongs.
       •   The operating system.
       •   The sensor version.
       •   The device target value.
       •   Internal and external IP addresses.
           Note
           Use the commands and options as they are documented here. Although some
           of the Live Response commands are the same as commands in the DOS
           command interface, the options are specific to Live Response.
        Command                  Description
        cd [dir]                 Change the current working directory. Options include absolute,
                                 relative, drive-specific, and network share paths.
        clear                    Clear the console screen; you can also use the cls command for
                                 this purpose.
        delete [path]            Delete the file specified in the path argument. The file is
                                 permanently deleted; it is not sent to the Recycle Bin.
        detach                   Detach from the current Live Response session. If a session has
                                 no attachments, it remains live until it times out (five minutes by
                                 default).
drives List the drives on the remote host. This is for Windows only.
        Command            Description
        exec               Execute a background process specified in the processpath
        [processpath]      argument on the current remote host. By default, process
                           execution returns immediately and output is to stdout and stderr.
                           Options can be combined:
                           • exec -o outputfile processpath – Redirect the process
                             output to the specified remote file, which you can download.
                           • exec -w processpath – Wait for the process to exit before
                             returning.
                           You can combine the options as shown in the following example
                           to execute and capture the output from a script:
                           exec -o c:\output.txt -w
                           c:\scripts\some_script.cmd
                           You must provide the full path to the process for the processpath
                           argument. For example:
                           c:\windows\system32\notepad.exe
        get [path]         Obtain the file that is specified in the path argument from the
                           remote host and download it to the local host.
        memdump            Take a full system memory dump and store it to the given file
        [filepath]         path, which must include a file name.
                           Memory dumps can take several minutes, and an (*) icon in the
                           Live Response window indicates that it is still in progress.
                           This is for Windows only.
        put [remotepath]   Put a file from the local host onto the remote host at the specified
                           path. You specify the file in the Open dialog of the browser, after
                           the command is entered in Live Response.
        Command               Description
        reg                   View or modify Windows registry settings (Windows endpoints
                              only). The syntax of this command is:
                              reg [action] [key] [options]
                              Use help reg in the Live Response command window for
                              details.
                              See Table 19, “Live Response registry (reg) command actions”.
       In a Live Response session for a Windows sensor, the reg command provides direct
       access to the remote computer’s Windows Registry.
       Table 19, “Live Response registry (reg) command actions” shows the reg command
       actions and their options. These options are intended to mirror the Windows default
       reg.exe command syntax.
       For all reg command actions, key paths can take hive references in either short or long
       form; for example, HKLM or HKEY_LOCAL_MACHINE. Note that if the key path contains
       spaces, you must enclose the entire key path in quotation marks; for example,
       "HKLM\SOFTWARE\VMware, Inc."
        Action            Description
        query             Format: reg query [key] [options]
                          Options:
                          -v – Query for value instead of the key
                          For example:
                          reg query
                          HKLM\Software\Microsoft\Windows\CurrentVersion\
                          Run
                          reg query -v
                          HKLM\Software\Microsoft\Windows\CurrentVersion\
                          Run\SecurityHealth
       Some commands provide information and other commands let you modify an endpoint.
       We recommend that you issue some of the information commands to become familiar with
       the interface before you make changes to the endpoints.
       Status and error messages inform you of any connection or command error issues. You
       can also use the dir or pwd commands to confirm your connection.
           Note
           To view all commands that were issued during a Live Response session, turn
           the audit log verbose setting to ON. If verbose is OFF, only initializations and
           terminations display in the log.
Chapt er 9
Manage reputations
       This chapter explains how to manage reputations by using whitelisting and blacklisting.
       A reputation is the level of trust or distrust that is given to an object. Cb Defense file
       reputations are based on multiple sources of known good and known bad objects. You can
       whitelist or blacklist applications by hash, IT tools, and certs.
       The following table contains reputation values and their definitions:
the
        Value                         Definition
        COMPANY_WHITE_LIST            An administrator has explicitly whitelisted this application
        (Company Whitelist)           or hash, usually due to unusual behavior that is specific to
                                      the organization.
        NOT_LISTED (Not               The sensor requested reputation from the backend, but
        Listed)                       the backend does not have the hash on any internal lists.
                                      Typically this means the hash is new. No information is
                                      available to determine the reputation from Cb Defense
                                      analytics and intelligence feeds. This reputation helps
                                      protect against zero-day malware and is frequently
                                      assigned to new hashes/updated applications.
        UNKNOWN                       The sensor has not yet sent the reputation request.
                                      Typically this means that the sensor cannot reach the Cb
                                      Defense backend.
        Note
        There is a benefit to explicitly whitelisting a hash so that it is added to your
        Company Whitelist. This can be especially helpful when it comes to dealing
        with alerts that are seen as false positives.
        Cb Defense alerts are based on the reputations of the files involved and
        behaviors that the Cb Defense Sensor observes on an endpoint. The
        algorithm that creates alerts distinguishes between Trusted White and
        Company White reputations, with the latter being a stronger indicator that the
        behavior is less likely to be malicious. Therefore, adding a specific application
        to your Company Whitelist can help eliminate unwanted alerts or lower the
        relative threat level for such alerts.
Whitelist IT tools
       The IT Tools functionality lets you assign an initial elevated trust to code that is dropped by
       known IT Tools. Programs and scripts that are dropped by IT Tools that match created
       rules receive the following trust treatment:
       •   They are not stalled for static analysis or cloud reputation when they are executed.
       •   They are assigned the LOCAL_WHITE reputation and initial trust.
       The benefits of using this functionality and assigning initial trust to code dropped by IT
       Tools include:
       •   Minimized perceived performance impact when IT Tools drop large amounts of new
           code that are immediately executed.
       •   No interference with new code execution. The dropped code is not blocked, even with
           stricter preventative policy rules in place, such as block unknown policy rules.
       To prevent exploitation of this whitelisting functionality, whitelisting of IT Tools is not
       absolute. Deferred analysis of new code occurs in the background as it executes. If the
       files are malware that are known to Cb Defense, configured policy enforcement rules act
       on them after initial execution. In many ways, these files are treated as pre-existing files.
       They are still scanned and analyzed but without the sensor getting in their way, based on
       the initial established trust.
       The following reputations take priority over Whitelist IT tools:
       •   Company White
       •   Company Black
       •   Trusted White
       •   Known Malware
       •   Suspect Malware
       •   PUP Malware
       Use cases for the IT Tools functionality include:
       •   Software Deployment IT tools - known installer tools, such as SCCM or Casper.
       •   Some executable installers, such as *.msi files whose processes act as code
           droppers.
       •   Developer tools, such as compilers/linkers, IDEs or script editors (vi, emacs, etc.).
           Establishing development tools as IT Tools helps improve developer experience while
           enforcing policy existing rules.
       To whitelist IT tools:
       1. Sign in to the PSC, click Enforce, and click Reputation.
       2. Click Add in the top-right corner.
       3. In the Add Reputation dialog, select IT Tools as the type. Whitelist is selected by
          default in the top right corner.
       4. Add the Path field: enter the path of the IT Tool that drops code and should receive
          initial trust and is allowed. For example, **\Trusted_Installer.exe.
           Note: Drive letters and the following wildcards can be used when specifying the IT
           Tools path, as shown in the following table. UNC paths are supported.
       5. Include all child processes - If selected, files dropped by child processes of the IT
          Tool that is defined in the Path field also receive the initial trust. This is useful when IT
          Tools create a child process to delegate work to, and the child process represents a
          generic executable such as a copy command. The rule helps maintain the IT Tool trust
          chain by temporarily treating the child copy command (in that process only) as an IT
          Tool. If the child process is not a generic executable, such as copy, and it fits an IT
          Tool use case, you can create a separate IT Tool rule for that command instead of
          selecting this option.
       6. Comment - Enter a comment to help users understand the reasons for this change.
          This is for tracking purposes only.
       7. Click Add to save the change.
Whitelist certs
       The Certs functionality allows for assigning initial elevated trust to signed code by specific
       trusted certificates. Signed programs and scripts that match the rule receive the following
       trust treatment:
       •   They are not stalled for static analysis or cloud reputation as they are executed.
       •   They are assigned the LOCAL_WHITE reputation and initial trust.
       The benefits of using this functionality are the same as if the files were created by trusted
       IT Tools.
       •   Minimized performance impact.
       •   No blocking on initial execution of files signed with specific certificates.
       Whitelisting is not absolute and the analysis is deferred. If a file signed by a trusted cert is
       a known malware file and runs, it will be terminated and blocked at a later point if blocking
       policies are configured.
       The following reputations take priority over Whitelist Certs:
       •   Company White
       •   Company Black
       •   Trusted White
       •   Known Malware
       •   Suspect Malware
       •   PUP Malware
       Use cases for the Certs functionality include:
       •   Operating system files, such as those signed by Microsoft or Apple, can be treated
           with initial trust and therefore minimize impact during an operating system upgrade.
       •   Priority tools used in the organization signed by a specific certificate.
       To meet the criteria for using the Cert functionality:
       •   The files must be signed and verified by a valid certificate.
       •   The certificate subject and authority must be configured in the Cert rule.
       To whitelist certs:
       1. Sign in to the PSC, click Enforce, and then click Reputation.
       2. Click Add in the top-right corner.
       3. In the Add Reputation dialog, select Certs as the type. Whitelist is selected by
          default in the top right corner.
       4. Signed by - Enter the certificate subject to match. The “*” wildcard character is
          allowed. For example, “My Company Inc.” or “My Company*”.
           Warning: Being as specific as possible when whitelisting certs is a best practice.
           Using wildcards can lead to effectively whitelisting malicious software that appears to
           be signed by a trusted certificate authority.
       5. Certificate Authority - This is a recommended entry but not required.
       6. Comment - Enter a comment that can help users understand the reasons for this
          change. This is for tracking purposes only.
        Note
        MD5 is not supported. The hash must be in SHA256 format and requires six or
        more fields. If a field is empty, use the following format where empty fields are
        denoted by commas:
        Field1, Field2,, Field4,, Field6
        Required fields must be in the following order:
        list type, indicator type, indicator value, description,
        application name
        Where:
        list type is one of the following:
         •   black_list
         •   white_list
        indicator type = indicator sha256
        indicator value = actual file hash (sha256 format)
        description = text to describe this entry
        application name = optional
Chapt er 1 0
Built-in policies
       As of the October 2017 release of Cb Defense, three policies are built in to Cb Defense.
       These policies cannot be deleted, but you can change their settings. These policies are
       devised as templates for common use cases. You can assign sensors to these policies, or
       duplicate a policy’s settings into a new policy that you create.
Standard policy
       The Standard policy is the default policy that is applied to new sensors. It is the
       recommended starting point for new deployments.
       The Standard policy blocks known and suspected malware. It prevents the riskiest
       operations (memory scraping and code injections).
       If your organization has many in-house or custom software applications, then Carbon
       Black will not have acquired a reputation for these applications when Cb Defense is
       deployed to your environment. In this case, rules in the Standard policy can cause
       unnecessary blocks and false positives. If these applications are system-critical, you
       should review and refine the Standard policy rules to suit your organizational needs.
Monitored policy
       The Monitored policy only monitors the endpoint. It has no preventive capability. It will not
       block any activity, including known malware. However, it monitors all application activity
       and logs these events to the Dashboard, so that you can evaluate all application activity
       prior to any policy rule implementation. Local scan is disabled by default.
       See “Dashboard”.
Advanced policy
       The Advanced policy starts with and then extends the capabilities of the Standard policy. It
       prevents riskier behaviors that are more likely to be false positives. This policy’s settings
       include Office applications for both Windows and macOS endpoints. It blocks operations
       from system utilities.
       We recommend that you conduct a phased roll-out approach to implementing any new or
       Advanced policy rules. For example, you can assign the Advanced policy to a group of
       pilot users. If you do not observe any false positives or blocks on legitimate software, then
       you can add production users to the Advanced policy. Alternatively, you can apply a single
       Advanced policy rule to all users for beta or User Acceptance Testing (UAT). If the addition
       of this new rule does not generate any false positives or blocks on legitimate software,
       then you can continue to introduce more aggressive rules to your environment in the same
       fashion. The Advanced policy rules prevent and defend against advanced attacks.
        Note
        The Blocking and Isolation, Permissions, and Uploads panels of this tab
        are described in “Create policy rules for permissions, blocking, and isolation”.
        Item              Description
        Policy Name       The policy name.
        Target Value      The selected target value that is associated with this policy. Values
                          include: Low, Medium, High, and Mission Critical. See “Target value”.
        Sensor UI:     Select this option to show the sensor UI on the endpoint. You can
        Detail message enter a message that displays on the sensor pop-up dialog. Mail-to
                       links are supported. You can enter HTML markup as part of the text
                       used in the sensor UI. If an HTML hyperlink is entered, the protocol
                       (such as HTTP) is used in the link.
                       For example:
                       <a href="http://www.google.com">google</a>
        Allow user to     If selected, the Cb Defense sensor is displayed with a Protection on/
        disable           off toggle, which lets the end user place the sensor in bypass mode.
        protection        This option is grayed out unless you enable Show Sensor UI: Detail
                          message.
                          The Protection toggle only displays on single-user operating
                          systems. The Protection toggle does not display on terminal
                          servers.
                          This setting applies to version 2.x and later sensors only. The users’
                          ability to disable protection cannot be removed from 1.0.x sensors.
        Enable private    Script files that have unknown reputations are uploaded unless this
        logging level     option is selected. This option also removes potentially sensitive
                          details from the events that are uploaded. This includes:
                          • Redacting command-line arguments
                          • Obfuscating document file names
                          • Not resolving IP addresses to correlating domain names
        Run               If selected, the sensor will perform an initial, one-time inventory scan
        background        in the background to identify malware files that were pre-existing on
        scan              the endpoint. Using this feature helps increase malware blocking
                          efficacy for files that were pre-existing on the endpoint before the
                          sensor installation.
                          The standard background scan takes 3-5 days to complete
                          (depending on number of files on the endpoint). It runs in low-priority
                          mode to consume low system resources. This is the recommended
                          scan.
                          The expedited scan option takes 24 hours to complete, and is only
                          recommended for testing and emergency incidents. System
                          performance is affected. Expedited scanning only applies to
                          Windows sensors version 3.3 and later.
                          The sensors invoke the background scan one time upon deployment.
                          The current background scan state is logged to the NT Event Log or
                          syslog together with the “BACKGROUND_SCAN” tag.
        Item               Description
        Scan files on      If selected, the sensor will scan files on network drives upon READ.
        network drives     The default value for this setting is false.
                           For best performance, deselect this setting.
        Scan execute       If selected, the sensor will scan files on network drives upon
        on network         EXECUTE.
        drives             This setting applies to version 2.0 and later sensors only. 1.0 sensors
                           always scan network drives upon execute.
        Delay Execute      This option specifies whether Cb Defense delays the invocation of an
        for Cloud Scan     executable until reputation information can be retrieved from the
                           backend, if the local scan returns an indefinite result. This is a
                           recommended setting.
                           This setting applies to Windows version 2.0 and later sensors only.
        Create MD5         Select this option to maintain MD5 hashes in logs. This option has no
        hash               effect on the security efficacy of Cb Defense. Deselecting this option
                           prevents Cb Defense from logging MD5 hashes. For best
                           performance, do not select this option.
                           This setting applies to version 2.0 and later sensors only. 1.0 sensors
                           always create MD5 hashes.
        Use Windows        Select this option to set Cb Defense as the endpoints’ antivirus
        Security Center    protection software in conjunction with Windows Security Center.
                           See “Disable or enable Windows Security Center integration”.
                           This setting applies to Windows version 2.10 and later sensors only.
        Enable Live        Select this option to enable Cb Defense Live Response for this
        Response           policy. See “Use Live Response”.
                           This setting applies to version 3.0 and later sensors only.
        Submit             Select this option to enable the upload of unknown binaries for Cloud
        unknown            Analysis by Carbon Black and a third-party. See “Cloud Analysis”.
        binaries for       This setting applies to version 3.2 and later sensors only.
        analysis
        Title            Description
        Policy Name      The policy name.
        Target Value     The selected target value associated with this policy. Values include:
                         Low, Medium, High, and Mission Critical. See “Target value”.
        Update Servers   Lets you add update servers for internal devices. You can use the
        for Internal     default mirror infrastructure (http://updates.cdc.carbonblack.io/
        Devices          update) or use the provided field to enter your own mirror device
                         URL. See “Signature mirror instructions”.
        Update Servers   Lets you update servers for offsite devices. You can use the default
        for Offsite      mirror infrastructure (http://updates.cdc.carbonblack.io/update) or
        Devices          use the provided field to enter your own mirror device URL. See
                         “Signature mirror instructions”.
Add policies
       To add a new policy:
       1. Click New Policy.
       2. In the Add Policy page, enter the required information, and then click Add.
           Notes
           Cb Defense Windows Sensor Versions 1.0.6.178 and greater support using
           drive letters in the policy rules along with the ?, *, and ** syntax as described
           below. macOS is not affected.
           In versions of the Windows Sensor prior to v.1.0.6.178, you cannot define a
           policy rule using the syntax C:\ for volume identification. Only syntax **\, which
           designates C:\, can be used.
           Windows Sensor v.1.0.6.178 and beyond support policy rules using C:\. Policy
           rules that use **\ will continue to work in all supported Cb Defense Windows
           sensor versions, so it is not necessary to recreate an old policy rule to correct
           **\ to C:\. macOS is not affected.
       The following table contains possible policy action values and their definitions:
       Table 24: Policy actions
th
        Value                            Definition
        TERMINATE (process or            According to policy settings, the action is to terminate the
        thread is terminated)            process based on reputation/behavior.
Permissions panel
       You can use permission rules to allow behavior, allow and log behavior, or to have Cb
       Defense bypass a path entirely.
       For example, the following rule When an application at path… _ … tries to perform any
       operation… bypass, causes Cb Defense to ignore any process that matches the
       application path. This bypass rule removes all visibility into behavior that processes at this
       path; it can create security risks. Malware that executes out of matching paths is not
       detected by the sensor or logged on the Cb Defense backend.
       UNC paths are supported in policy rules, including bypass rules.
       Use cases for creating permission rules include:
       •   Setting up exclusions for other AV/security products
       •   Removing impediments for software developer’s workstations
       When you select a policy in the left Policy panel of the Policies page, the associated
       permissions for that policy appear in the Permissions panel to the right.
       To create or edit a permissions rule:
       1. In the left panel, select the policy to view or edit.
       2. In the right panel on the Policy page, click the Cb Defense Settings tab and then
          click the arrow next to Permissions.
       3. Click Add Application Path, or click the pencil icon next to an existing rule to edit it.
       4. Type in the application path. You can add multiple paths separated by commas.
       5. Select the Operation Attempt and desired Action, and then click Confirm. You can
          delete a rule by clicking the trash can icon.
       6. When you are done making changes to the policy, click Save.
       You can copy a rule from one policy to another policy, or to all policies. See “Copy a rule”.
        Note
        Click the Investigate icon next to any rule to open the Investigate page with
        the search parameters that are set to the rule properties. See “Investigate an
        alert”.
        Title              Description
        Process            Describes the first part of the permission rule involving the
                           application. You must enter the application path.
        Operation          Describes the second part of the permission rule involving the
        Attempt            operation. Possible values include:
                           •   Performs any operation
                           •   Performs any API operation
                           •   Runs or is running
                           •   Communicates over the network
                           •   Scrapes memory of another process
                           •   Executes code from memory
                           •   Invokes a command interpreter
                           •   Performs ransomware-like behavior
                           •   Executes a fileless script
                           •   Injects code or modifies memory of another process
                           See Table 26, “Operations overview”.
        Action             Describes the action that occurs based on the Application and
                           Operation selections. Possible values include:
                           • Allow - Allows the specified behavior in the specified path. None
                             of the specified behavior at the path is logged and data is not sent
                             to the Cb Defense backend.
                           • Allow & Log - Allows the specified behavior at the specified path.
                             All activity is logged and reported to the Cb Defense backend.
                           • Bypass - This option is only available when Tries to perform any
                             operation or Tries to perform any API operation is selected.
                             The sensor will not monitor the executable: nothing is blocked and
                             nothing is logged. There is no visibility into activity; therefore, this
                             action should be considered as a last resort only.
        Operation          Description
        Attempt
        Performs any       This operation is similar to Runs or is running, except that Cb
        operation          Defense monitors the executable that is trying to perform an
                           operation.
        Operation        Description
        Attempt
        Performs any     By configuring a permissions rule to bypass any API operation, you
        API operation*   can address interoperability issues with any third-party applications
                         that have performance issues when Cb Defense preventions are
                         enabled. This permissions rule lets those applications execute, but
                         prevents Cb Defense from enforcing preventions for the following
                         policy reviews:
                         •   Tries to scrape memory
                         •   Tries to inject code
                         •   Tries to execute code from memory
                         •   Master Boot Record protection for Performs ransomware-like
                             behavior
        Runs or is       When the initial scan of the endpoint is complete, a reputation should
        running          be assigned for each application on the endpoint. Cb Defense
                         reviews all running processes and then shuts down the application(s)
                         based upon the specified rule. Built-in logic prevents the shutdown of
                         critical systems (such as lsass).
        Communicates     Cb Defense flags all network activity that is related to the specific
        over the         application.
        network
        Executes code    This operation is not targeted and therefore runs a high risk of
        from memory      flagging false positives if it is not used correctly. Associated TTPs are
                         SUSPICIOUS_BEHAVIOR that looks for aplications that are
                         executing code from dynamic memory (for example, from buffer
                         overflow or unpacked code). However, it will also flag scripts in
                         process; for example, if macros are used in the environment, they will
                         be flagged.
        Operation         Description
        Attempt
        Invokes a         There is an attempt to call the shell (command line tools). Supported
        command           command interpreters are:
        interpreter        •   cmd.exe
                           •   powershell.exe
                           •   wscript.exe/cscript.exe
                           •   wmic.exe
                           •   mshta.exe
                           •   sh, bash, dsch, zsh, tcsh, python (macOS)
       3. Click the pencil icon next to a rule to edit it, or click Add Application Path to add a
          new application path. You can add multiple paths separated by commas.
       4. Select the Operation Attempt and desired Action, and then click Confirm. You can
          delete a rule by clicking the trash can icon.
           Note: If you set the Action to Terminate process, you cannot also deny the
           operation.
       5. When you are done making changes to the policy, click Save.
           Note: Click the Investigate icon next to any rule to open the Investigate page with
           the search parameters that are set to the rule properties. See “Investigate an alert”.
       You can copy a rule from one policy to another policy, or to all policies. See “Copy a rule”.
       The following table describes the Blocking and Isolation panel.
        Title              Description
        Process            Describes the first part of the blocking and isolation rule involving the
                           application.
        Operation          Describes the second part of the blocking and isolation rule involving
        Attempt            the operation. Select an Operation Attempt value from the following
                           options:
                            •   Runs or is running
                            •   Communicates over the network
                            •   Scrapes memory of another process
                            •   Executes code from memory
                            •   Invokes a process not on the whitelist
                            •   Invokes a command interpreter
                            •   Performs ransomware-like behavior
                            •   Executes a fileless script
                            •   Injects code or modifies memory of another process
                           See Table 26, “Operations overview”.
        Action             Describes the action that occurs based on the Application and
                           Operation selections. Possible values include:
                            • Deny operation
                            • Terminate process
       Copy a rule
       You can copy a rule from one policy to another policy, or to all policies. After you create a
       rule, a copy icon displays in the left directly below the rule.
       To copy a rule:
       1. Click the copy icon below the rule that you want to copy.
       2. Click All Policies to copy the rule to all policies, or click Select Policies to select a
          policy.
       3. If you click Select Policies, place your cursor in the Search for a policy textbox. The
          existing policies display. You can select one from the list or you can type in the name
          of the policy in the search textbox. You can select multiple policies, one at a time.
       4. Click Copy. You will receive a confirmation message that the policies have been
          updated with the copied rule.
       If the rule set you are copying from conflicts with any rules in a destination policy, a modal
       will appear to let you manage the rule conflicts. You can replace or skip a specific rule, or
       you can replace or skip all conflicting rules at one time by selecting the Apply selection
       to all conflicts checkbox.
       Ransomware
       With the release of the 3.0 Cb Defense sensor, you can set a policy rule to handle
       ransomware-like behavior.
       To set the ransomware policy rule:
       1. In the left panel, click the policy to edit.
       2. In the right panel, in either Permissions or Blocking and Isolation, select Add
          Application Path, enter the application path, and then select Performs
          ransomware-like behavior.
       3. Click Confirm. When you are done making changes to the policy, click Save.
       The only available action for Performs ransomware-like behavior is Terminate
       process. This is because denying ransomware access to the first file that an application
       tries to encrypt would not prevent it from attempting future encryption operations. For
       performance and security, the only supported action is Terminate process.
       We recommend that rules for suspected malware, PUP, not-listed, and unknown
       reputations be added to your policies for protection against ransomware.
       Microsoft PowerShell and Python are popular targets for Windows and OSX, but any
       command interpreter that can receive code as part of its command line is a potential
       source of malicious activity. For stronger protection, consider including path-based rules
       for script interpreters.
       The most secure ransomware policy is a default deny posture that prevents all
       applications except those that are specifically approved from performing ransomware-like
       behavior. This policy requires tuning to handle false positives that are generated by
       applications whose legitimate activity mimics ransomware operations. The advantage of
       the default deny policy is protection from ransomware behaviors that originated from
       compromised applications that have a higher reputation (such as
       TRUSTED_WHITE_LIST), without enumerating all possible applications. For example,
       set the application path to ** and then set Performs ransomeware-like behavior to
       Terminate process.
       You should extensively test default deny policies on a single representative host before
       you apply the policy rules to production systems. After you have addressed false
       positives, perform a gradual rollout by moving small groups of endpoints into the policy. To
       address any new false positives that are discovered, leave a few days between adding
       each group of endpoints.
       If good software is being terminated by the ransomware-like behavior rules, use any of the
       whitelisting methods described in:
       Cb Defense: Methods to Whitelist Applications.
       When a ransomware policy rule is applied on an endpoint, the sensor UI displays a
       message if the sensor UI is enabled. Click Details to see more information about the
       terminated process.
           Tip
           processEffectiveReputation is case-sensitive.
       TTPs are not correlated to Blocking and Isolation operations. However, you can use
       threatIndicators + TTP strings in conjunction with
       processEffectiveReputation + reputation on the Investigate page to generate
       specific search results. This can give you a better idea of which applications might be
       blocked by the specified Blocking and Isolation rule.
       For example, to search for Not Listed applications that can trigger the rule for Tries to
       scrape memory of another process, you can run the following query:
       processEffectiveReputation:NOT_LISTED and
       threatIndicators:RAM_SCRAPING or
       threatIndicators:READ_SECURITY_DATA
        Note
        In the preceding queries, do not include the information in parentheses.
Chapt er 11
Notification types
       You can add three notification types:
       •   Notification based on alert priority – Notifies you if an alert priority crosses a
           threshold. See “Priority score”.
       •   Notification based on Tactics, Techniques, and Procedures (TTPs) – Notifies you
           if an alert exhibits specific TTPs. You can select from a list of TTPs or enter specific
           TTPs. See “TTP reference”.
       •   Notification based on policy action – Notifies you if a policy action is enforced.
           These notifications can be configured based on the action taken by the policy. This
           notification type notifies you when an application, process, or network connection has
           been terminated or denied based on policy rules. See “Prevent attacks through
           policies”.
       Notifications are generated based on the detection of an alert or policy action and can be
       emailed to administrators and/or sent to connected systems if connectors are configured.
View notifications
       To view currently configured notifications:
       1. Sign in to the PSC, click Settings, and click Notifications.
           All currently configured notifications are displayed.
       2. You can edit or a delete a notification by clicking the pencil or x icon to the right of the
          notification.
       3. To view the history of a notification, click the clock icon to the right of the notification.
          Select the time frame of notifications to review.
           A displayed list contains all notifications that are related to the notification rule. The list
           indicates which notifications are scheduled, which were sent, and which were not
           triggered, as well as their associated time-stamps and rules. Notifications that were
           not triggered include an explanation.
           Notifications are categorized and color-coordinated to make it easier to understand
           the context of the notification. The notification types are:
           -   Operational issue - Monitoring (orange)
           -   Operational issue - Resolved (green)
           -   Scheduled maintenance - Downtime (yellow)
           -   Scheduled maintenance - No Downtime (yellow)
           -   Support alert (orange)
Add notifications
       To add a notification:
       1. Sign in to the PSC, click Settings, and click Notifications.
       2. Click Add Notification, enter the notification details in the Add Notification page,
          and then click Add.
       If you have set up both a TTP-based notification and a threat score-based notification,
       there are cases where you will get two emails for the same alert. We recommend that you
       set up two separate email addresses, one for each notification type, to decrease confusion
       on multiple notifications.
        Tip
        Select Send at most one email notification for a given threat type per day
        to reduce the number of emails that you receive from Cb Defense.
        Note
        Email addresses used for this purpose must be associated with registered Cb
        Defense users. See “Manage users”.
        Note
        Connectors inherit the permissions that are available to the user. Treat
        the connector ID and API keys inside the Connectors page the same as
        your Cb Defense console login password. If a connector credential is
        compromised, immediately regenerate the API key for the affected
        connector by following the procedure “To view or regenerate the API key
        for a connector:”.
       Use the following procedure to create a connector, and then associate the SIEM
       connector with the notification rule.
       Each integration point is defined by a connector in Cb Defense.
       To add a connector:
       1. Sign in to the PSC, click Settings, and click Connectors.
       2. Click Add and supply the following information:
           -   Name – this identifies each connector in the console. The name can be anything
               that uniquely identifies the connectors that are associated with your Cb Defense
               organization.
           -   Connector type – SIEM, API, and Live Response.
               SIEM connectors can only receive notifications through the notifications API. Use
               a SIEM connector to configure the Splunk add-on, QRadar app, or the Syslog
               connector.
               API connectors can call any API except for the notifications and Live Response
               API.
               Live Response connectors can call any API except for the notifications API.
           -   Authorized IP addresses – (optional) IP addresses or IP address ranges in
               CIDR notation (for example, 192.0.2.0/24 for all hosts in the 192.0.2.x subnet) that
               are authorized to use this connector. A blank list means that any IP address can
               call the APIs for this connector. Note that RFC 1918 addresses (192.168.0.0/16,
               10.0.0.0/8, and 172.16.0.0/12) are not publicly routable, and cannot be used as
               authorized IP addresses. Find your public IP address and use that address or
               range in this configuration option.
           -   Description – (optional) any text that is associated with this connector.
       3. Click Add.
       If credentials are compromised for a connector, regenerate the API key. The API key must
       be re-entered in the integration.
       To view or regenerate the API key for a connector:
       1. Sign in to the PSC, click Settings, and click Connectors.
       2. Locate the connector and click the down-arrow in the Actions column.
       3. Click API Key. Click the Copy icon to copy the API key, or click Generate new API
          key.
        Note
        If you try to remove a connector without first removing notification rules
        that are associated with the connector, you will receive a “409” error.
        Remove the connector from its associated notification rules first, and then
        remove the connector.
       Carbon Black provides two pre-built connectors that are available for download, and
       sample API scripts to help you create your own integrations. For more information on the
       pre-built integrations from Carbon Black, see the following resources:
       •   Splunk integration:
           -   The Cb Defense add-on for Splunk pulls notifications from Cb Defense into your
               Splunk SIEM. See https://splunkbase.splunk.com/app/3545/#/details for
               instructions on how to download and install this add-on into your Splunk or Splunk
               Cloud instance.
           -   The Cb Defense App for Splunk provides two-way integration between Cb
               Defense and Splunk, including interactive dashboards and API connectivity. See
               https://splunkbase.splunk.com/app/3905/#/details for instructions on how to
               download and install this app into your Splunk or Splunk Cloud instance. Note that
               the Cb Defense Add-On is required before installing the Cb Defense App.
       •   QRadar integration:
           -   Visit the IBM X-Force App Exchange at https://exchange.xforce.ibmcloud.com/
               hub. Search for “Cb Defense App for IBM QRadar” for installation instructions and
               download links to install the Cb Defense integration with IBM QRadar.
       •   Syslog integration:
           -   Carbon Black provides a pre-built Syslog integration to push Cb Defense
               notifications into other SIEMs that accept CEF or JSON style syslog input. See
               https://developer.carbonblack.com/reference/cb-defense/connectors/#cb-
               defense-syslog-connector for more information on the Syslog integration.
       For more information about using the Carbon Black API, see the following resources:
       •   The Cb Integration Network website at https://www.carbonblack.com/why-cb/
           integration-network/ contains information about pre-built integrations from Carbon
           Black and our technology partners.
       •   The Developer Network website at https://developer.carbonblack.com contains API
           reference documentation and other tutorials regarding Cb Defense’s open API. You
           can use this information to develop your own integrations as well as install and
           configure Carbon Black’s pre-built Splunk and QRadar integrations
       •   The cbapi Python module provides an easy-to-use Python interface to Cb Defense
           APIs. The cbapi module is documented at https://cbapi.readthedocs.io and source
           code, including example scripts, are available at https://github.com/carbonblack/
           cbapi-python.
       •   To ask questions or interact with others who are using the APIs, visit the Developer
           Relations space on the User eXchange at https://community.carbonblack.com/
           community/resources/developer-relations.
Chapt er 1 2
               Note
               Uploaded files expire after two weeks. If you try to download an expired file,
               you will receive a timeout error.
• You can submit unknown binaries for cloud analysis. See “Cloud Analysis”.
4. Click Send.
       Windows
           Note
           Windows does not restrict uploading of script files when Private Logging
           Level is enabled.
           See “Cb Defense Settings tab”.
       Windows files that have the following file extensions can be uploaded for analysis in Cb
       Defense:
       •     .exe
       •     .dll
       •     .sys
       •     .ocx
       •     .drv
       •     .scr
       •     .pif
       •     .ex_
       •     .msi
       •     .vb
       •     .vbs
       •     .jar
       macOS
           Note
           With macOS, if Private Logging Level is enabled, scripts are not uploaded. If
           Allow Executable Uploads for Scans is not selected, all script uploads are
           disabled regardless of type.
           For more information, see “Cb Defense Settings tab”.
       Common macOS object types can be uploaded for analysis; for example:
       •     Perl
       •     Python
       •     Ruby
       •     Shell
       •     TCL
       •     PHP
       •     Applescript
       The following objects cannot be uploaded:
           Note
           Magic Cookie refers to the first four bytes of a file that identifies the special file
           format that is relevant to the file.
Cloud Analysis
       This feature improves security efficacy by offering additional analysis of unknown binaries
       by a third-party partner. The local scanner must be turned on for cloud analysis to work,
       and you must be using sensor version 3.2 or above.
       To enable cloud analysis:
       1. Sign in to the PSC, click Enforce, and click Policies.
       2. Select the policy for which to enable cloud binary analysis.
       3. In the right pane, select the checkbox for Submit unknown binaries for analysis.
       4. Confirm that you are opting in, and thereby electing to share data with Carbon Black
          and a third party.
       5. Click Save.
        Note
        If you opt in to this functionality, the binary files (including the content of
        the files) are uploaded to Carbon Black for analysis. Carbon Black uses a
        third-party vendor, Avira Operations GmbH & Co. KG (“Avira”), as a sub-
        processor to assist with the threat analysis. The binary files are sent to
        Avira’s network. Avira only processes the data to meet Carbon Black’s
        obligations under the applicable agreement and for no other purpose.
        Avira has implemented appropriate security and operational methods that
        are designed to secure the data, and will comply with all applicable data
        privacy laws when processing the data. The information will be processed
        by Avira in their US or EU data centers.
        In the course of using the services, you shall have sole responsibility for
        the accuracy, quality, integrity, legality, reliability, appropriateness, and
        intellectual property ownership or right to use and transfer to Carbon
        Black all such data. You can view Carbon Black’s privacy policy at https://
        www.carbonblack.com/privacy-policy/ (which is modified by Carbon Black
        from time to time).
Chapt er 1 3
        Note
        You must have at least two users registered in Cb Defense to enable this
        feature. That way, one user can reset the other user's credentials if necessary.
        See “Manage users”.
           g. Select I’m an Okta customer adding an Internal app and then click Finish.
           h. Click View Setup Instructions.
           i. Copy the value in the Login URL/SignOn URL field and paste it into the Single
              Sign On URL field of the Cb Defense SAML Config page.
           j. Click Save.
       9. Open a new browser tab or window and verify SAML authentication.
          m. For the mail field, click Advanced and enter the fields as shown here. Then click
             Save.
          n. For the SAML subject field, click Advanced and enter the fields as shown here.
             Then click Save.
            Note
            Be careful when you copy the X509 certificate data. Sometimes a
            white space or a carriage return is inadvertently included, which
            results in a "Request failed with status code 400" error message.
            If you receive this message and you have validated your
            configuration, try copying the certificate information line by line
            into the console.
        Note
        End users can disable or enable WSC integration through Security and
        Maintenance in Control Panel.
       For new organizations, WSC integration is enabled by default via a policy setting in the
       Standard policy. You can disable WSC integration; doing so does not disable Cb Defense.
       Existing organizations must explicitly enable WSC integration.
       To disable Cb Defense WSC integration:
       1. Sign in to the PSC, click Enforce, and then click Policies.
       2. In the left panel, click the policy for which to disable WSC integration.
       3. In the right panel, deselect the checkbox for Use Windows Security Center to
          disable WSC integration. Click Save.
Appendix A
TTP reference
       In Cb Defense, behaviors are captured as individual Tactics, Techniques, and Procedures
       (TTPs). They are captured on the device by the sensor and analyzed as a group that is
       compiled into alerts (if applicable) by the Analytics Engine on the backend platform.
       This appendix provides definitions and possible values for TTPs.
Appendix B
Assumptions
       These instructions assume:
       •   A Linux operating system
       •   Definitions are hosted on an HTTP server at a given URL, which are entered in the
           Update Servers field of the Local Scanning settings of a given policy.
          -  avupdate_msg.avr
          -  avupdate.bin
          -  HBEDV.KEY
          -  update_1.cfg
          -  update_2.cfg
          -  update_defs.sh
       4. Create a new signature mirror with this command:
          ./update_defs.sh some_dir
       5. Serve up the some_dir directory using any HTTP server.
       6. Update the Update Servers field to point to the URL that represents the some_dir
          directory.
        Note
        We recommend running the command in step 4 every few hours to pull the
        latest updates from our mirror.
Assumptions
       These instructions assume:
       •   A 64-bit Windows operating system
       •   Definitions are hosted on an HTTP server at a given URL, which are entered in the
           Update Servers field of the Local Scanning settings of a given policy.
        Note
        Because do_update.bat downloads the latest update from Cb Cloud one
        time, we recommend that you use an application such as Task Scheduler for
        Windows to automatically run the script on your mirror server at designated
        time(s) each day. This helps make sure that your mirror server always has the
        latest signature updates. The command generates (and appends to) a log file
        in %TEMP%\scanner\upd.log. You can use this log file to troubleshoot
        issues.
        The Update Servers Master checkbox of the Local Scanning panel in a
        policy setting can impact connections to the mirror server. If you have sensors
        that can’t receive updated signatures from the mirror server, toggle the switch
        on or off to resolve the issue.
Appendix C
      Script files
      •   com
      •   hta
      •   inf
      •   ins
      •   isp
      •   jar
      •   msi
      •   ocx
      •   pl
      •   py
      •   reg
      •   vb
      •   vbe
      •   vbs
      •   ws
      •   wsf
      •   wsh
      •   ps1
      •   ps1xml
      •   psc1
      •   psd1
      •   psm1
      Data files
      •   pdf
      User files
      •   tax
      •   iif
      Corp files
      •   pdf
      •   pps
      •   ppsm
      •   ppsx
      •   ppt
      •   pptm
      •   pptx
      •   rtf
      •   swf
      •   xls
      •   xlsx
      •   xlsm (not yet added)
      •   xlsb (not yet added)
      •   dme
      •   frm
      •   ldf
      •   mdb
      •   mdf
      •   myd
      •   myi
      •   ndf
      •   opt
      Email files
      •   dbx
      •   mbx
      •   ost
      •   pst
      •   snm
      •   toc
      •   edb
      •   oeb
      Contacts files
      •   wab
      •   pab
      •   mab
      •   contact
      •   mml
      •   vcf
      •   aba
      •   na2
      •   ldif
      •   abbu
      •   aby
      •   olk
      Calendar files
      •   ics
      •   icbu
      •   cal
      •   ical
      •   wcd
      •   dba
      Binary files
      •   Apple executables
      •   Apple driver extensions
      •   Apple dynamic libraries
      •   Windows executables
      •   Windows dynamic libraries
      Installer files
      •   Apple installers ( DMG, PKG)
      •   by extension only: Windows MSI files, Android APK installers
      Script files
      •   java (class and jar)
      •   Perl
      •   Python
      •   PHP
      •   Ruby
      •   Shell
      •   Applescript
      •   Any other script files with "#!" file header indicating interpreter association
      Data files
      •   Adobe PDF
      •   MS Office
      •   Open Office
Appendix D
Overview
       The integration functionality of Cb Defense for VMware with VMware AppDefense
       provides security and IT operations teams with enhanced visibility into complex, multi-
       guest applications, their related network traffic, and suspicious endpoint behaviors.
       Recommended security governance best practice is to use both AppDefense and Cb
       Defense for VMware to secure your SDDC.
       This integration:
       •   Decreases Mean Time to Resolution (MTTR) for alert triage process by providing
           relevant application context and VMware details directly into Cb Defense. The
           integration forwards critical alerts from Cb Defense to into the AppDefense console,
           and forwards AppDefense alarms to the Cb Defense Management Console for
           enhanced visibility. You can apply AppDefense remediation actions directly from the
           Cb Defense Management Console and vice versa.
       •   Helps IT and SecOps team to ensure standardized security controls in the software-
           defined data center.
       VMware AppDefense is a data center security tool that uses the VMware hypervisor to
       monitor the intended application state in a virtual machine guest at all levels (OS kernel,
       process behavior, and network connections). AppDefense does not view a guest workload
       in isolation; instead, it manages workloads as part of broader application scopes. This
       allows it to have a deeper understanding of interactive behavior in the data center, instead
       of individual machine behavior only.
General concepts
       Cb Defense and AppDefense have many similarities. However, there are some key
       differences. This section outlines differences in Cb Defense and AppDefense behavior
       and terminology.
       •   Add to Whitelist is a Cb Defense action. It whitelists an application in Cb Defense at
           the organizational level. It does not impact AppDefense settings. See “Manage
           reputations”.
       •   Allow Process is an AppDefense action. It whitelists the application in AppDefense
           for a particular AppDefense Service in a particular AppDefense Scope. It does not
           impact Cb Defense settings.
       •   Allow Behavior is an AppDefense action. It whitelists the granular behavior
           (composed of process + IP address +port) of an application in AppDefense. It does
           not impact Cb Defense settings.
       There are two ways to quarantine a device: by using Cb Defense quarantine, or by using
       VMware NSX quarantine (if it is enabled for the device). See “Quarantine a virtual
       machine”.
Terminology
       Cb Defense and AppDefense use different terminology, as described in the following
       table:
        Cb Defense                                AppDefense
        Alert                                     Alarm
        Device (OS hostname)                      Member (virtual machine name)
        Dismiss                                   Clear
Requirements
       Cb Defense for VMware requires the following VMware virtual machine configuration:
       •     Windows Server 2008 R2 or later operating system
       •     vCenter 6.5+
       •     vSphere ESXi 6.5+
       •     VMware Tools
       •     VM hardware Version 13 or later
       •     The latest AppDefense host module, guest module, and appliance versions, which are
             available in the download section of the AppDefense console.
           Note
           A core principle of AppDefense is structuring security around applications,
           instead of around infrastructure. Therefore, AppDefense provides the ability to
           add unsupported virtual machines to AppDefense scopes and services if they
           belong to an SDDC application. However, virtual machines that do not meet
           the preceding requirements cannot be secured by AppDefense.
       4. To collect the required AppDefense API Key, go to VMware AppDefense and click
          the cog in the bottom left corner of the page. Click Integrations and then click
          Provision New API Key. The generated key displays in a text file. Copy and paste
          this key into the AppDefense API Key field and then click Validate. A list of your
          virtual machines displays.
             Note: If you have a large number of virtual machines, it can take several minutes for
             the list to populate.
       You can also remove the VMware integration. You might want to do this if:
       •     You are removing AppDefense from your environment.
       •     A new AppDefense API key is generated In AppDefense.
       •     For technical troubleshooting.
           Important
           If you disable the integration, all related VMware and application context data
           is removed.
       Synchronization occurs every few minutes. If the synchronization is not successful, the
       page indicates the last successful synchronization time. In this case, the number of failed
       synchronization attempts displays:
       Five or more failed synchronization attempts indicate that there has been no connectivity
       with AppDefense for a considerable time.
       You can search for virtual machines and you can export the displayed list to a CSV file.
       You can also display only those virtual machines that match a selected install status. The
       Install Status options are listed in the following table.
       To collect more detailed information about a virtual machine in AppDefense, click the
       Scope Name hyperlink directly from Cb Defense.
        Status                   Description
        All                      All VMware virtual machines are listed.
        Both Installed           Both Cb Defense and AppDefense are installed on
                                 this virtual machine. All aspects of the integration
                                 are enabled in the Cb Defense and AppDefense
                                 consoles.
        Needs one or both        The virtual machine is eligible for and supports
                                 both AppDefense and Cb Defense, but both
                                 products are not installed.
                                 The virtual machine either:
                                 • Has Cb Defense installed but does not support
                                   AppDefense (for example, the virtual machine is
                                   running an unsupported version of the operating
                                   system, vSphere, or vCenter).
                                 • Has AppDefense installed but does not support
                                   Cb Defense (for example, a Linux virtual
                                   machine).
        All Eligible Installed   All eligible virtual machines have either Cb
                                 Defense or AppDefense installed, but do not meet
                                 requirements to have both Cb Defense or
                                 AppDefense installed.
                                 If a device is eligible for Cb Defense but is not
                                 eligible for AppDefense, and Cb Defense is
                                 installed, the install status is All Eligible Installed.
                                 If a device is eligible for AppDefense but is not
                                 eligible for Cb Defense and AppDefense is
                                 installed, the install status is All Eligible Installed.
        Needs Cb Defense         The virtual machine has AppDefense installed and
                                 is eligible to install Cb Defense, but does not
                                 currently have Cb Defense installed.
        Needs AppDefense         The virtual machine has Cb Defense installed and
                                 is eligible to install AppDefense, but does not
                                 currently have AppDefense installed.
        Needs Both               The virtual machine is eligible for both AppDefense
                                 and Cb Defense, but neither one is installed.
        Ineligible               The virtual machine is not eligible for AppDefense
                                 or Cb Defense.
        VMware Tools Missing     VMware tools is not installed on the virtual
                                 machine. VMware Tools is a prerequisite for
                                 making an install status determination; therefore,
                                 no install status can be determined.
       The install status is color-coded to indicate what actions are required for your virtual
       machines. This color-coding is based on security governance best practices.
       The colored line to the left of the Install Status reflects the following virtual machine
       status:
        Note
        The install status filter Needs one or both does not map to a specific color. It
        contains the Needs both status (red), the Needs Cb Defense status (orange)
        and the Needs AppDefense status (orange).
        Title           Description
        Install         The install status of the virtual machine. See Table 32,
        Status          “VMware virtual machines install status”.
        Device          The operating system hostname of the virtual machine.
        Name
        VMware          The vCenter name of the virtual machine.
        Name
        Title           Description
        OS              The operating system version that is running on the virtual
                        machine.
        AppDefens       The AppDefense scope that applies to the virtual machine.
        e Scope
        AppDefens       The AppDefense service under which the virtual machine is
        e Service       running.
       The Cb Defense Agent Status column indicates the status of the Cb Defense sensor on
       the virtual machine. This can be one of the following:
       •   The sensor version of an installed Cb Defense sensor
       •   Eligible - the virtual machine is eligible for Cb Defense based on the Cb Defense
           operating system requirements, but the Cb Defense sensor is not installed.
       •   Ineligible for the Cb Defense sensor based on Cb Defense operating system
           requirements.
       If there are virtual machines that do not have VMware Tools installed, then VMware Tools
       Missing displays, together with a count of virtual machines that are missing VMware
       Tools.
       To view the specific virtual machines that are included in a category, click the install status.
       The VMware page displays a list of matching virtual machines. See “View VMware alerts”.
       For install status states, see “VMware virtual machines install status”.
        Note
        VMware data on the Dashboard is not eligible for download into a CSV file.
       For an alert that occurs on a VMware virtual machine, additional metadata is displayed.
       To view the VMware metadata:
       1. Go to an Alerts List page.
             Note: To filter alerts to show only VMware alerts, click the VMware Virtual Machines
             filter in the left panel. You can also filter VMware alerts based on severity levels: Info,
             Minor, Serious, and Critical. Cb Defense threats are selected by default.
       2. Select an alert that has occurred on a VMware virtual machine.
       3. Click the VM Virtual Machine tab. The following information is displayed.
For more information about the Alerts List pages, see “View and take action on alerts”.
       Note: All known VMware virtual machines include Install Status, VM name, VM ID, VM
       UUID, vCenter UUID, and MAC Address even if they do not meet the AppDefense
       minimum requirements. Virtual machines that are ineligible to be secured by AppDefense
       can also have Scope and Service information if they have been added to an AppDefense
       scope and service. However, only virtual machines that have AppDefense installed
       include AppDefense Version and AppDefense State.
        AppDefense         Use this value to validate that you are    Integration detail
        Version            running the appropriate version. This
                           is particularly useful in
                           troubleshooting. This field is populated
                           only if AppDefense is installed on the
                           virtual machine.
       The following example describes how you can use the information in the Selected
       Process panel of the Alert Triage page to triage an alert.
        Example
         • Zelda observes a threat alert on a VMware virtual machine and clicks the
           link to the Alert Triage page.
         • Zelda clicks the node in the Process Graph panel of the Alert Triage page
           to view details about the virtual machine in the Selected Process panel.
           She reviews the data to understand the alert severity and the impact of
           taking action on the virtual machine.
         • Zelda views the context metadata. She looks at the AppDefense Scope to
           determine how business-critical the application is, and then views the
           AppDefense Service and AppDefense Service Type metadata to
           determine how technically critical this service is to the application. She
           views the VMs in Service metadata to understand the impact of that virtual
           machine to the service, based on redundancy. She can quickly identify the
           virtual machine by reading the virtual machine identification metadata (VM
           Name, VM ID, VM UUID, vCenter UUID, and MAC address). Zelda can
           now decide on an appropriate course of remediation based on the
           discovered criteria.
         • Zelda contacts the IT department that manages the virtual machine and
           explains what happened and what steps should be taken to address the
           issue.
        By using the data that is available on the Alert Triage page, Zelda determined
        the best remediation action based on business impact, and communicated the
        issue appropriately with the impacted department.
       For information on how to search for alerts on the Alerts List page, see “Search for
       alerts”.
       The following data displays for each alarm in the search results table:
        Column               Description
        Checkbox             You can select the checkbox next to an alarm or group of alarms to
                             select the alerts for dismissal. You can select all viewed alarms by
                             clicking the checkbox above the search results table. Note that this
                             selection only includes those alarms that you can view on the current
                             page - not all alarms in the organization. See “Dismiss alerts”.
        First Seen           The first date and time when this alarm occurred. You can sort on this
                             column.
        Reason               The reason for the alarm. For AppDefense alarms, this data includes
                             the alarm type, scope, and service.
        Device               The AppDefense device name. You can click this name to go to this
                             event on the Investigate page.
        Take Action          The Take Action column lets you view the alarm in AppDefense, or
                             lets you dismiss the alarm. Note that when you dismiss an
                             AppDefense alarm by using the Cb Defense Management Console,
                             the corresponding AppDefense alarm/Cb Defense alert in the
                             AppDefense console gets cleared. You cannot unclear an alarm in
                             AppDefense.
       To expand an alarm to view additional data, click the chevron next to the alarm. The
       following information displays:
        Item                  Description
        Last Seen             The last time that the alarm was detected.
Last Action The last action that was taken on the alarm.
       Table 39: Primary Process tab for VMware alarms - Inbound and Outbound
       Connections
        Item                  Description
        Application           Name of the application.
        Item                Description
        CLI                 Command line interface information. These details indicate
                            which options were used to start the executable.
Table 40: Primary Process tab for VMware alarms - Process Monitoring
        Item                  Description
        Violation Type         The violation type. These are:
                               •   Inbound Connections
                               •   Outbound Connections
                               •   Process Monitoring
                               •   Guest Integrity
                               •   Host Integrity
        Parent Process        The file system location of the parent process executable.
        Path
        Parent CLI            Command line interface information for the parent process.
                              These details indicate which options were used to start the
                              parent executable.
       If the alarm type is Host Integrity or Guest Integrity, the Primary Process tab does not
       display. Instead, the Violation Details tab displays.
       The Violation Details tab shows the following information; there are no actions on this
       tab.
       Table 41: Violation Details tab for VMware alarms - Host Integrity and Guest
       Integrity
        Item                  Description
        Num of Bytes          The number of bytes that were written during the violation.
        Written
       Device tab
       See “View device details”.
       For AppDefense alarms, you can take the following actions on the Device tab.
       To take actions on a device:
       1. Click the alarm in the search results table.
       2. Click the Device tab.
       3. Click the Take Action dropdown menu. In addition to the standard Cb Defense
          actions, you can select one of the following AppDefense actions:
           -   Suspend: Suspend the virtual machine.
           -   Snapshot: Take a snapshot of the virtual machine.
           -   Power off: Power off the virtual machine.
           -   NSX Quarantine: If NSX is enabled on the virtual machine through AppDefense,
               you can use NSX to put the virtual machine into quarantine. See “NSX
               quarantine”.
        Notes
        You can take the same actions on an alarm on the Investigate page. See
        “Investigate an alert”.
        You cannot reverse an AppDefense action from within Cb Defense or
        AppDefense. You can only reverse an action by using vSphere or NSX.
       Notes/Tags tab
       To view notes and tags that are associated with an alarm:
       1. Click the alarm in the search results table.
       2. Click the Notes/Tags tab.
           Actions that have been taken on an alarm are logged as notes in this tab. The notes
           include the following information:
           -   Where the alert was detected (Cb Defense or AppDefense).
           -   What action was taken and by whom.
           -   The time that the action occurred.
           Only actions that can be initiated in both Cb Defense and AppDefense display as
           notes.
       From the AppDefense Alarm View page, you can take the following actions on Cb
       Defense alerts:
       •   AppDefense actions:
           -   Suspend: Suspend the virtual machine.
           -   Snapshot: Take a snapshot of the virtual machine.
           -   Power off: Power off the virtual machine.
           -   NSX Quarantine: Quarantine the virtual machine by using NSX.
       •   Cb Defense actions:
        Notes
        AppDefense remediation actions cannot be undone from within Cb Defense or
        AppDefense. To undo an AppDefense action, you must use vSphere or NSX.
        You can clear an alarm in the AppDefense console, but this action does not
        dismiss the alert in Cb Defense. You cannot undo a clear action in
        AppDefense.
        If you clear an alarm in AppDefense, a note is added to the alarm in Cb
        Defense, indicating that it has been dismissed.
        When you dismiss an AppDefense alarm or Cb Defense alert by using the Cb
        Defense Management Console, the corresponding AppDefense alarm/Cb
        Defense alert in the AppDefense console gets cleared.
       You should not put a device into both Cb quarantine and NSX quarantine at the same
       time. If a device has been put into quarantine by using a product other than Cb Defense,
       the device displays as offline.
Cb Defense quarantine
       Cb Defense quarantine blocks all inbound and outbound traffic at the operating system
       level. If you quarantine a virtual machine in Cb Defense, any products that use hypervisor-
       based communication (as opposed to network-based communication) with the virtual
       machine can connect to it. This functionality is included in the majority of VMware
       products, including AppDefense, vSphere, and NSX.
       Cb Defense retains connectivity to the quarantined virtual machine. This is helpful for
       analysis and remediation purposes. For example, you can perform Live Response actions
       on a Cb Defense quarantined virtual machine (see “Use Live Response”).
       We recommend that you use Cb Defense quarantine if your organization does not have
       NSX, or to maintain connectivity to the virtual machine for remediation from Cb Defense.
       For more information about how to quarantine a device in Cb Defense, see “Quarantine a
       device”.
NSX quarantine
       VMware AppDefense uses NSX to perform this operation. NSX quarantines the virtual
       machine from the rest of the network based on NSX quarantine settings. These settings
       can be customized to allow approved connections by third-party products. NSX quarantine
       stops inbound and outbound network connections at the hypervisor level.
       If you quarantine a device by using NSX quarantine, you terminate the endpoint’s
       connectivity to Cb Defense; therefore, Live Response and other Cb Defense remediation
       options are not available. The virtual machine appears in Cb Defense as offline.
       You cannot unquarantine an NSX-quarantined virtual machine in either Cb Defense or
       AppDefense — you must have administrative access to NSX to unquarantine a virtual
       machine.
Appendix E
Cb Defense communication
      Network proxies and firewalls, if improperly configured, can interfere with communication
      between the Cb Defense Sensor (deployed on Windows and macOS endpoints) and the
      Cb Defense backend (securely operated in the cloud via Amazon Web Services).
      This appendix describes how to configure your network infrastructure and endpoint
      devices to ensure proper communication between the Cb Defense sensors and the Cb
      Defense backend.
          Note
          The Cb Defense backend architecture uses dynamically managed load
          balancers, which results in the public IP changing frequently. Such an
          approach ensures necessary levels of scalability and reliability of our service.
          Therefore, we do not offer a static public IP address. We recommend allowing
          access to the Cb Defense backend by configuring a bypass rule in your
          firewall or proxy to allow outgoing connections over TCP/443 as well as Cb
          Defense's alternate port TCP/54443.
          There is no static IP, range of IPs or subnet to whitelist/exclude in Firewall or
          Proxy settings - only a URL.
          Device services URL varies per backend instance. Check your login URL to
          find out which backend you are in.
Configure a firewall
      A Cb Defense sensor can connect to the Cb Defense backend in a firewall-protected
      network in several ways:
      •     Configure a bypass on the network firewall to allow communication between the
            sensor and the backend over TCP/443. This is often the simplest approach.
      •     Configure a bypass in your network firewall to allow outgoing connections to Cb
            Defense’s alternate port TCP/54443.
      •     If specific network firewall changes are not made to access the Cb Defense backend
            applications, the sensors try to connect through any existing proxies.
Configure a proxy
      The Cb Defense Sensor uses a variety of mechanisms to determine whether a network
      proxy is present. If a proxy is detected (or if one is specified at install time), then the
      sensor attempts to use that proxy. If no proxy is detected, the sensor will attempt a direct
      connection through port 443 or 54443.
      To configure the proxy during an unattended sensor installation, see the PSC Sensor
      Installation Guide.
          Note
          Cb Defense sensors automatically attempt to detect proxy settings during
          initial installation. This should be tested. If the automatic proxy detection
          doesn’t succeed, you must define the parameters to include the Proxy IP and
          Port in the MSI command line during an unattended installation.
          If user authentication is required, the end user might be prompted for
          credentials. This typically does not occur in environments that require proxy
          credentials because the sensor uses an existing configuration that avoids
          requiring end users to enter credentials.
      To avoid going through a network proxy (and/or to avoid being blocked by a firewall), you
      might need to configure a bypass on your proxy server/firewall to allow outgoing
      connections from the sensor to the backend. Options for bypass configuration include the
      following:
          Warning
          The host domain name for the Cb Defense backend server is included in the
          server’s certificate. Some network proxies and gateways might try to validate
          the certificate and deny the Cb Defense backend application connection
          because of a name mismatch between the certificate and real host name of
          the system that is running in AWS. If this occurs, you must configure the proxy
          or gateway so that it does not validate the backend server certificate. Note that
          you cannot access the certificate or hostname in the server’s certificate.
Appendix F
        killChainStatus            Maps to stages of the kill chain. See Table 43, “Kill Chain
                                   Stages - Queries” for possible values.
Device
        email                      Email address that is associated with the install user. The
                                   domain name is not required.
        groupName                  Policy that the sensor was in at the time of the event.
                                   Partial text search is supported.
General
Network
Process
Reputation
        childEffectiveReputation    The reputation for the event's child process used for policy
                                    enforcement. Possible reputations:
                                    COMPANY_WHITE_LIST, COMPANY_BLACK_LIST,
                                    LOCAL_WHITE, COMMON_WHITE_LIST,
                                    TRUSTED_WHITE_LIST, NOT_LISTED,
                                    KNOWN_MALWARE, UNKNOWN, PUP,
                                    SUSPECT_MALWARE.
        parentEffectiveReputation   The reputation for the event's parent process, used for
                                    policy enforcement. Possible reputations:
                                    COMPANY_WHITE_LIST, COMPANY_BLACK_LIST,
                                    LOCAL_WHITE, COMMON_WHITE_LIST,
                                    TRUSTED_WHITE_LIST, NOT_LISTED,
                                    KNOWN_MALWARE, UNKNOWN, PUP,
                                    SUSPECT_MALWARE.
        processEffectiveReputatio   The reputation for the event's primary process, used for
        n                           policy enforcement. Possible reputations:
                                    COMPANY_WHITE_LIST, COMPANY_BLACK_LIST,
                                    LOCAL_WHITE, COMMON_WHITE_LIST,
                                    TRUSTED_WHITE_LIST, NOT_LISTED,
                                    KNOWN_MALWARE, UNKNOWN, PUP,
                                    SUSPECT_MALWARE.
        targetEffectiveReputation    The reputation for the event's child process used for policy
                                     enforcement. Possible reputations:
                                     COMPANY_WHITE_LIST, COMPANY_BLACK_LIST,
                                     LOCAL_WHITE, COMMON_WHITE_LIST,
                                     TRUSTED_WHITE_LIST, NOT_LISTED,
                                     KNOWN_MALWARE, UNKNOWN, PUP,
                                     SUSPECT_MALWARE, NOT_LISTED.
Appendix G
Glossary
        Term                    Definition
        Alert ID                See Incident ID.
        Alert Triage page       A page in the Cb Defense Management Console that lets
                                you visualize an alert. See “Visualize an alert”.
        Alerts List page        A page in the Cb Defense Management Console that lets
                                you search for and respond to alerts. See “View and take
                                action on alerts”.
        Term               Definition
        Dashboard          When you log in to Cb Defense, the Dashboard displays
                           as your home page. The Dashboard gives you a
                           snapshot of what is going on in your system, and lets you
                           quickly navigate to items of interest. It shows you what is
                           occurring on the devices that Cb Defense protects. See
                           “Dashboard”.
        Device user        The user who installed or registered the sensor. This is
                           referred to as User on the Sensor Management page. It is
                           listed as Sensor Installed by on the Device tab and Email
                           in expanded event details on the Investigate page.
        Investigate page   The Investigate page lets you thoroughly examine and
                           analyze alerts. See “Investigate an alert”.
        Term                Definition
        Local scanning      Cb Defense sensors include an optional local scanning
                            feature that enables static file analysis of applications
                            before they are executed. See “Local Scan Settings tab”.
        Process user        The user that ran a process that is under investigation.
                            This is either the logged-on user or a system user.
        Term                      Definition
        PUP                       Potentially Unwanted Program. In the best case, PUPs
                                  produce annoying results (delivering popup ads), but are
                                  sometimes used to deliver malware.
        Quarantine                You can quarantine a device from the rest of the network.
                                  After being quarantined, the device has network access to
                                  the Cb Defense backend only. See “Quarantine a device”.
        Sensor group              You can create sensor groups and add sensors to these
                                  groups. All the sensors in the sensor group receive an
                                  automatic assignment to a policy based on the metadata
                                  that is associated with the sensor, and the criteria that you
                                  define. See “Manage sensor groups for automatic policy
                                  assignments”.
        Term                  Definition
        Target value          A target value is defined by the policy to which a device
                              belongs. It acts as a multiplier when calculating the threat
                              level for any threats that are detected on a particular
                              device.
                              • Low Target Value – Results in a lower threat level.
                              • Medium Target Value – Represents the baseline (no
                                multiplier).
                              • High and Mission Critical Target Values – Both increase
                                the threat level under the same circumstances. As a
                                result, you might see two or more alerts with identical
                                descriptions but different priority scores.