This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

Carbon Black Cloud | 25 July 2024

Check for additions and updates to these release notes.

To see changes made in previous 2024 releases, see Archive of 2024 Improvements and Resolved Issues.

To see the changes made in previous years, see:

What's New - 25 July 2024

  • Alert Anomaly Classification

    Our machine learning-powered Watchlist Alert Anomaly Classification is available to Enterprise EDR customers in the Tokyo region.

    Note:

    This feature supports Carbon Black Advanced Threats and AMSI Threat Intelligence watchlists.

    For more information, see Anomaly Classification in the Carbon Black Cloud User Guide.

  • Coming Soon: These APIs are being deactivated as of 31 July 2024:

    • Alerts Forwarder v1 Schema

    • Alerts v6 API

    • Devices v3 API

    • Live Response v3 API

    • Enriched Events Search API

    • Policy v3 API

    • Process Search Suggestions v1

    • GET Process Search Validation v1

    • Sensor Update Services v2 API

    Information on how to migrate to replacement APIs is available in the Developer Network’s API and Schema Migration guide: https://developer.carbonblack.com/reference/carbon-black-cloud/api-migration/

Resolved Issues - 25 July 2024

  • CBCUI-6093: refreshed the linkages between Carbon Black Cloud console and associated docs.vmware.com documentation

  • DSEN-25786: Resolved problem with misleading Event counts on the Processes tab of the Investigate page

    Event counts on the Processes tab of the Investigate page report the number of events that were collected by the sensor, when they should report the number of events that were ultimately reported from the sensor to the cloud, factoring in excluded event counts. This can result in misleading event counts for event types that were excluded from reporting.

  • DSER-46519: Resolved issue where users will could not find audit logs for downloading files from Inbox

  • DSER-49742: Resolved issue where the Crossproc events were still being reported for a process with crossproc reporting excluded

    Crossproc events on the Process Analysis page incorrectly swap the initiator and target processes, which can mislead customers into thinking that crossproc events are still being reported for a process with crossproc reporting excluded.

  • DSER-53215: Sensor reporting OSX 15.0 not populating on backend

    CBC Console now supports Mac OS 15.0 for Mass Sensor Management.

  • TPLAT-9183: Resolved issue where the signature status is UNKNOWN for valid signatures (first listed: 31 August 2020)

Known Issues

All

  • CBCUI-2937: Export feature on Observations page

    The export feature on Observations page does not export the grouped counts and results when you have selected a Group By summary.

  • DSEN-21949: On the Observations tab ports are incorrectly swapped on certain netconns

  • DSER-36023: Linux VDI parent/child hierarchy may be reported incorrectly in environments where an appliance is installed (first listed: 27 October 2021)

    There is no known workaround for this issue, but it will be resolved in a future sensor release.

  • DSER-40080: Updated reputation values are sometimes not reflected on the Malware Removal page

    Known malware that has the reputation changed to Trusted Whitelist or Company approved still appears on the malware removal page.

  • DSER-42250: Sensor receives maintenance mode response when trying to authenticate

    Customers can experience connectivity issues with certain endpoints receiving a maintenance mode response instead of the correct response if device data is absent. To resolve the issue, customers must manually uninstall these sensors.

    Associated with: EA-21807, EA-20280.

  • LC-2903: Investigate search doesn't warn the user when they search using a field that isn't indexed for that tab's API

Container Essentials

  • CNS-4066: cb-containers-runtime fails to run on linux kernel 6.5

  • GRC-2222: CLI-created API keys are not deleted after the CLI instance is deleted (first listed: 14 April 2022)

Enterprise EDR

  • DSER-25929: Link from Watchlist Alert to Investigate does not show all relevant metadata (first listed: 17 August 2020)

Event Reporting and Sensor Operation Exclusions

  • DSER-51244 : DuplicateRuleGuidsAcrossPolicies sensor alarms

    If you add Event Reporting and Event Reporting and Sensor Operations exclusions to a policy, both exclusions use the same rule GUID, which results in DuplicateRuleGuidsAcrossPolicies sensor alarms

Archive of 2024 Improvements and Resolved Issues

This section contains the information regarding all 2024 releases prior to this release.

What's New - 18 June 2024

  • Export Alerts

    You can now easily export alerts from both the in-console Alerts page and API. This allows you to easily share alerts with other members of your organization who may not regularly use the Carbon Black Cloud console or APIs. Similar to the export functionality on the Investigate page, you can click on the “Export” button at the top right of the alerts table. 

    This begins a background alert export of up to 25,000 alert records. When the export is complete, a notification displays inside the Notifications table:

    By default, the export will include all available fields available in the Alerts V7 API. If you would like to customize the export output, please use the Alerts V7 export API routes. More information on these routes can be found on the Developer Network.

  • Carbon Black Cloud App for QRadar v2.3.0

    Version 2.3.0 of the Carbon Black Cloud App for QRadar is now available. This version includes compatibility with the current Alerts v7 and Data Forwarder v2 Alert schema.  Read about the new features and how to upgrade in the announcement here: https://developer.carbonblack.com/2024/06/announcing-vmware-carbon-black-cloud-app-for-qradar-v2.3.0

    In addition, we have recently moved the IBM QRadar content to the Carbon Black Cloud User Guide. See IBM QRadar.

  • Rich Text Alert Notes

    Alert notes now support rich text formatting. This includes:

    • Styling: font size, bold, italic, and underline

    • Colors

    • Lists, bulleted or numbered

    • Hyperlinks

  • Updated Links for Getting Started Guides

    • Broadcom has consolidated Customer Support resources from legacy Carbon Black systems to Broadcom support. References to the retired services such as Community.carbonblack.com have been updated. All links to legacy Carbon Black Knowledge Base have been re-linked to their new home, throughout the Carbon Black Cloud console.

  • Dashboard Endpoint Widget Update

    The Dashboard Endpoint widget has been updated so that it is consistent with the Inventory page.

  • Filemod Information for Alerts

    A Filemod information pane now displays in the Alerts page side panel for alerts that have relevant filemod data.

  • Coming Soon: Planned API deactivations on July 31st 2024:

    The following APIs will be deactivated on 31 July 2024:

    • Alerts Forwarder v1 Schema

    • Alerts v6 API

    • Devices v3 API

    • Live Response v3 API

    • Enriched Events Search API

    • Policy v3 API

    • Process Search Suggestions v1

    • GET Process Search Validation v1

    • Sensor Update Services v2 API

    Information on how to migrate to replacement APIs is available on the Developer Network API and Schema Migration guide. https://developer.carbonblack.com/reference/carbon-black-cloud/api-migration/

Resolved Issues - 18 June 2024

  • DSER-46519: Fixed an issue where users could not find audit logs related to downloading files from the Inbox

  • CBCUI-5412: UBS data display

    When the Binary Details page showed no UBS data and the user clicked the Ban button, the page temporarily displayed non-UBS data.

What's New - 28 May 2024

  • In Console MDR Migrations beginning 28 May 2024

    Carbon Black Managed Detection and Managed Detection & Response customers will be migrated to the in console experience over the next few weeks. You’ll receive an In Product Notification (“Notifications” in the upper right of the Carbon Black Cloud console) with your migration date around one week prior to your time slot.

    Learn more about what to expect, find a demo, and provide feedback: https://docs.vmware.com/en/VMware-Carbon-Black-Cloud/index.html#product-announcement-inconsole-managed-detection--response-may-2024-3

  • Updated Links to Support Resources

    Broadcom has consolidated Customer Support resources from legacy Carbon Black systems. The most critical references to the retired services such as Community.carbonblack.com have been updated. The links to such resources have been re-linked to their new home throughout the Carbon Black Cloud console.

What's New - 16 May 2024

  • Alert Triage Page Improvements

    To bring better consistency to the Carbon Black Cloud console, the Alert Triage page is enhanced to use more design and layout elements from the Process Analysis page of the Carbon Black Enterprise EDR product. Details include:

    • The Alert Triage side panel introduces the standardized Process, Device and Event (for example: Netconn, Filemod) cards, with all the available metadata they typically contain.

    • The side panel now dynamically orients to the selected node in the tree diagram.

    • The entire “Alert Origin, Behavior, Notes & Tags” sub-tab of the footer has been removed, and all viable sources of data and functionality migrated elsewhere on the page.

      • Alert Origin is removed, including Vector and Alert origin source, which were redundant.

      • Primary Process remains available in side panel.

      • Alert Behaviors Based on Severity graphic is removed.

      • “All behaviors” TTPs remain available in the side panel.

      • Notes & Tags have moved from the footer to the side panel.

    • Device Details & Actions have moved from the header to the side panel.

    • Current Cloud Reputation, Signature Verification, Process State, and Policy Action no longer have separate icons at the top of the panel and are shown in the Process panel instead.

  • Sensor Update Status Tab Updates

    In the Sensor Update Status tab, Update error now displays when an upgrade does not complete successfully due to failure or inactivity.

    This status replaces Sensor unresponsive, which inaccurately implied all such failures were the result of the sensor being inactive.

  • New Information on Inventory page (macOS endpoints)

    The macOS sensor Inventory: Inventory -> Endpoints page is enhanced to assist Mac Admins identifying macOS deployment errors related to the Full Disk Access and Network Extension - related MDM policy. 

    Display strings for the new error states (displayed in the “LAST CHECK-IN” column) are:

    • FDA Error

    • Network Ext. Not Approved

    • Network Ext. Disabled

    This change was deployed as part of the April 2024 backend release. Please refer to the latest MDM policy recommendations included in the macOS sensor DMG/docs folder and the User Guide for more information:

  • Coming Soon: APIs deactivated on 31 July 2024

    The following APIs will be deactivated on 31 July 2024:

    • Alerts Forwarder v1 Schema

    • Alerts v6 API

    • Devices v3 API

    • Live Response v3 API

    • Enriched Events Search API

    • Policy v3 API

    • Process Search Suggestions v1

    • GET Process Search Validation v1

    • Sensor Update Services v2 API

    Information on how to migrate to replacement APIs is available in the Developer Network API and Schema Migration guide: https://developer.carbonblack.com/reference/carbon-black-cloud/api-migration/.

Resolved Issues - 16 May 2024

  • DSER-31717: Support and Technical Support Role can no longer Initiate & Stop Update Sensor Requests in Customer Org

  • DSER-48447: Bulk actions to put sensors into bypass mode are now captured in the audit log.

What's New - 22 April 2024

  • Configure Binary Uploads per Policy

    Carbon Black is pleased to introduce the ability for Enterprise EDR and XDR customers to control the upload of new binaries to Carbon Black Cloud on a per-policy basis.

    Starting today, this feature will be enabled over the coming weeks on a rolling basis. Customers will see an in-product notification when it becomes available.

    Enterprise EDR and XDR customers will have access to the new Upload new binaries and their metadata to Carbon Black for later analysis and download setting on the Sensor tab of the Policies page. This setting applies to Windows sensor versions 3.4+.

    When this setting is enabled, executed binaries and their metadata will be uploaded to Carbon Black Cloud. The binaries’ metadata can be viewed on the Binary Details page, where the binary can also be downloaded for further analysis or added to the banned list.


    Previously, this setting existed as the Upload all new binaries to CB for your later analysis and download (3.4+ Sensor) setting at the top of the Policies page, which applied to all policies. It was a global setting that could be enabled or disabled across all policies and the endpoints to which they applied. Effectively, this setting has been migrated from the global level to the policy level to give Enterprise EDR and XDR customers more control over which endpoints have binary uploads enabled.


    Enterprise EDR and XDR customers’ preexisting binary upload settings have been retained through this migration. If the global Upload all new binaries to CB for your later analysis and download (3.4+ Sensor) setting was disabled, then the per-policy Upload new binaries and their metadata to Carbon Black for later analysis and download setting will be disabled across all policies accordingly. Conversely, if the global Upload all new binaries to CB for your later analysis and download (3.4+ Sensor) setting was enabled, then the Upload new binaries and their metadata to Carbon Black for later analysis and download setting will be enabled across all policies accordingly. From this foundation, customers can tune which policies (and therefore which endpoints) upload new binaries to Carbon Black Cloud.

    Carbon Black acknowledges that some organizations may want to enable the upload of executed binaries for some assets, but not others. For example, an organization may want to enable the upload of executed binaries on most assets, but not on developers’ or executives’ machines, which could have binaries containing sensitive or proprietary information that the organization does not want leaving the network. This feature enables Enterprise EDR and XDR customers to dictate which endpoints have binary uploads enabled and which do not.

    Lastly, due to the release of this feature, Enterprise EDR rule content will no longer be updated on Windows sensor versions less than 3.6, macOS sensor versions less than 3.5.3.82, and Linux sensor versions less than 2.11.0.

    The maximum Enterprise EDR rule set version available on these old sensor versions, which are in End of Support status, is 2.3141. The individual rule versions within rule set version 2.3141 are:

    • Enterprise EDR on Windows Sensor = 181

    • Enterprise EDR on Linux Sensor = 63

    • Enterprise EDR on macOS Sensor = 21

    • Unified Binary Store Metadata on Windows = 38

    • Unified Binary Store Upload on Windows = 40

    New Enterprise EDR content will continue to be released to Windows sensor versions 3.6+, macOS sensor versions 3.5.3.82+, and Linux sensor versions 2.11+.

    To continue receiving new Enterprise EDR content, please ensure you are using sensor versions equal to or greater than those indicated above, and preferably, only those that are in Standard Support or Extended Support status.

What's New - 18 April 2024

  • Email Notifications for Non Carbon Black Cloud Users

    Previously, email notifications could only be sent to existing Carbon Black Cloud users. This update makes it possible to notify other emails, such as distribution groups.

    From the Carbon Black Cloud console Settings → Notification, add or edit a notification.

    • Select 0 or more Carbon Black Cloud users from the dropdown or begin typing to filter the list.

    • Add 0 or more email addresses, such as a distribution group.

      Be sure to hit ENTER after each email address, or changes will not be saved.

    Each notification rule requires at least one user, email address, or legacy API key.

  • New information on Alert Card Details

    This feature further enhances the explainability for the anomaly scores enriched by watchlist Alert Classification. The current version of the explanation provided by alert classification for the anomaly scores is mainly based of prevalence (frequency of occurrence) attributes. This release adds a much more enhanced version of explainability by looking across various behavioral features associated with the alerts. This enhancement helps security analysts understand why certain behaviors were flagged, enabling quicker and more accurate responses to potential threats.

  • Update to IP Address information on Triage Page

    The triage page header previously showed internal & external IP address values from the most recent device check in.  Since this page is alert-oriented, these are now sourced from the alert & represent the values at the time of the event.  External IP address will also be displayed on Device nodes in the Triage tree (typically the root node).

  • Setting Alert Determination to True Positive

    Setting the alert’s determination to “True Positive” must now be done on an individual alert.

    The determinations of “None” and “False Positive” can still be assigned to a group of alerts.

    Important:

    This change is intended to improve the accuracy of “True Positive” determinations.

  • Script Telemetry improvements

    • Carbon Black Cloud now makes a clear distinction between “path to the script interpreter that executes script content” and “path to the script file that was opened by the script interpreter”

      1. Previously in cases where a script was executed at the start of a process launch, the Endpoint Standard product would report e.g. process_name:script.ps1, such as when powershell.exe was the executable performing the script interpretation & execution of script.ps1.

      2. Now Carbon Black Cloud will report both of these data in two separate fields: the script interpreter/script host will be reported in process_name just as Enterprise EDR has always reported executables (e.g. process_name:powershell.exe) and the script file will be reported as scriptload_name (e.g. scriptload_name:script.ps1)

    • This means the Alert Triage tree will no longer populate tree nodes with the name of the script (e.g. exea12.bat) but instead just report the name of the process executing that script file.

    • Carbon Black Cloud will report and index all script files as scriptload_name, whether the scripts that are loaded by the process at process launch (e.g. passed in as a command line parameter) or are loaded by that process anytime throughout the lifetime of the process. This means the field scriptload_name now includes all telemetry that was published in the past as process_loaded_script_name

      1. Both process_loaded_script_name and process_loaded_script_hash are now deprecated and will no longer be populated in Carbon Black Cloud

      2. These process_loaded_script_* fields have been removed from documentation and inline suggestions in the Investigate page

      3. These process_loaded_script_* fields will remain populated in pre-existing search data until that data ages out of your Carbon Black Cloud tenant

      4. These process_loaded_script_* fields will completely disappear from CBC data no later than October 2024

    • The scriptload_content field continues to track the AMSI-deobfuscated code that is recorded and reported by the Carbon Black Cloud Windows sensors.

    • All Events and Observations that include any script activity are now discoverable by searching or filtering on the "scriptload" or “fileless_scriptload” event types

      1. Searches and Filtering on event_type:scriptload will uncover all script activity attributable to file-backed script activity 

      2. Searches and Filtering on event_type:fileless_scriptload will uncover all script activity that cannot be attributed to file-backed scripts 

    • All events where fileless_scriptload_cmdline is populated are now discoverable by searching or filtering on the "fileless_scriptload" event type

    • The “Test Rule” feature of the Enforce > Policies page has been enhanced to support script files with the new scriptload_name support. This change will ensure that when users have included a script file with known filename extensions (e.g. .ps1, .xlsx, .py, etc) in the File Path for Permissions or Blocking and Isolation rules, the “Test Rule” feature will search for the specified script files using the scriptload_name field. Note that the Test Rule feature will only validate the specific script types supported by the CBC sensors, as specified in Figure 1 of this article.

    • Your Watchlists may need to be updated: as communicated elsewhere (via a Carbon Black Community article and in-product Notifications), you may need to update your custom Watchlists. Any custom Watchlists you may have implemented could potentially stop identifying matching processes if you were previously searching for script activity. For example, if you have a watchlist whose query currently looks for process_name:*.ps1, that watchlist will no longer generate Alerts to identify when .ps1 files are being executed. To ensure you are receiving the same quantity & quality of Alerts that you were in the past, you will need to update your watchlist IOCs to replace e.g. process_name:*.ps1 with scriptload_name:*.ps1.

    • Threat Intel Feed support: all Carbon Black Cloud-provided threat intel feeds (e.g. Advanced Threat Indicators, AMSI Threat Intelligence - documented here) have been updated to ensure any script-centric detections are now using scriptload_name appropriately. This means all CBC-provided watchlists you’ve subscribed need no action on your part to accurately detect intended script behaviors.

    • API users who have previously searched for process_name will have to update their logic to find script names using scriptload_name.

    • SIEM applications that only query for process_name to find script activity will need to be updated.

    In the near future, we intend to expose additional details reported by AMSI (app name, content name, sessions) and clarify the sequence of events when script content is reported multiple times by AMSI, so that a script whose execution is reported multiple times by AMSI are clearly associated together.

    For more guidance on how to operationalize these changes, please see this article on our Carbon Black Community:

    https://community.carbonblack.com/t5/Carbon-Black-Cloud-Discussions/Script-Search-Simplification-and-Impact-on-Watchlists-Feeds/m-p/124683

  • Removing event_type from Processes search

    The event_type field will no longer be suggested, indexed or returned on /processes API and Investigate > Processes tab.

    This field has been unreliable (does not and cannot consistently return all processes where the named event type has been reported for at least one event during that process' lifetime), and has created significant confusion for customers. No longer indexing this field removes this confusion.

    This event_type field will continue to be indexed and returned on all other supported Search routes (/observations, /events APIs) and on both Investigate > Observations and on Process Analysis pages.

  • Alert Forwarder de-duplication

    Starting with this release, Carbon Black Cloud Data Forwarder will only be issuing updated versions of existing CBC Alerts when the following occur:

    • User sets a Determination (e.g. False Positive, True Positive)

    • Managed Detection & Response team sets a Determination (e.g. False Positive, True Positive)

    • Carbon Black Cloud determines that the “threat cause” of a CB_ANALYTICS alert has changed

    • Carbon Black Cloud determines that the “threat score” has increased

    Starting with this release, Data Forwarder will no longer issue updated versions of a CBC Alert if the following occur, as these do not cause the Alert to carry any new or updated data values other than backend_timestamp:

    • User updates the Workflow of the Alert from Open to In Progress or Closed (reasoning: customers should be triaging and acting on Alerts either in their SIEM or in the Carbon Black Cloud, not both)

    • Managed Detection & Response team updates the Workflow value

    • User adds, updates or deletes the Notes on the Alert (reasoning: the Notes data is not stored with Alerts, but as a separate data stream; as well, updating the Threat ID Notes would cause hundreds or thousands of Alerts to be updated all at once)

  • Improvements to Asset Groups

    • The maximum number of asset groups per org has increased to 125 groups.

      The previous limit was 100 groups.

    • Three new criteria options have been added to the Criteria and Query builder:

      • Bypass:  can be set to equal or not equal “True.”

      • Quarantine:  can be set to equal or not equal “True.”

      • External IP:  has the same options as many of the other criteria options.

    • You can now export your Asset Groups data from the main Asset Groups page. The exported data contains Group ID, Group Name, Description, Group Created Time, Group Updated Time, the query used for each group, the member count of each group, the Policy ID, and Policy Name. See Export Asset Groups.

    • A new filter named Policy Assigned By is available on the Inventory pages.

      You can use the facet to filter your view by assets that have had their policy assigned by Group, Default, or Manually Assigned.

    • You can now provide direct feedback to Carbon Black by clicking on the new Share Feedback button on the main Asset Groups page. See Share Asset Group Feedback.

  • Splunk App v2.1

    The Carbon Blac Cloud Splunk App version 2.1 is now available on Splunkbase and certified for Splunk Cloud.

    • New Features

      • Asset Inventory Input

        (Includes USB Devices & Asset Groups)

      • Asset Details Dashboard

    • Bug Fixes

      • Index dropdowns will support more than 30 indexes.

      • The Input Addon was missing the App Configuration XML Dashboard.

    See: Carbon Black Cloud Splunk App for more information.

  • Vulnerability Management Updates to Backend Services

    Carbon Black’s Vulnerability Management service has been migrated onto an internally developed vulnerability data feed. This transition enables Carbon Black to deliver more rapid updates and bug fixes with a solution that is directly managed by our team. It also provides a path to create tailored risk prioritization that leverages the combined knowledge of the Symantec and Carbon Black products.

    There are a few key differences that appear in the Vulnerability Management feature as part of this transition:

    • There are some difference in the reported CVEs due to the new algorithm being used to match installed OSes and Applications against known CVEs. With the internally managed solution, we are better positioned to quickly respond to any data quality concerns raised by our customers.

    • Application vulnerabilities now focus only on fully verified and qualified products.

      The previous Vulnerability Management solution provided CVE data for all discovered applications, but this created false positives for applications which had not been fully verified. This improvement reduces the false positives and focuses application vulnerability reporting on the most commonly deployed applications, such as browsers, Microsoft applications, and more.

    • The Kenna Risk Score has been removed and we now exclusively use the industry standard CVSS score.

      This change will create a difference in the numerical severity score assigned to a CVE and will therefore impact the number of CVEs in each category of critical, important, moderate, and low. The move to a Carbon Black-owned solution enables us to develop a more tailored risk score over time.

    We appreciate your patience with the changes in this transition, and we are excited to deliver an even better Vulnerability Management solution to you all going forward.

  • DNS Protocol Parsing

    In addition to TLS and HTTP, we added DNS protocol parsing exclusively to our XDR offering.

    With this enhancement to network telemetry, DNS netconn events will be inspected and DNS message contents will be reported in the process analysis event view. In addition, this new telemetry comes with new event search fields, allowing customers to query DNS traffic by specific fields such as query name, record types, and even TTL.

    These additional search fields can be identified by the prefix netconn_dns_.

    Note:

    For more information, check out the search fields documentation here.

  • New Sensor Update Failure Reason

    Sensor upgrades will fast-fail when an unsupported upgrade is requested for the upcoming Linux 2.16 sensor and a new failure reason will communicate this. A Linux sensor upgrade to 2.16+ is supported when the current sensor is running 2.15+.

  • Removed the quick tour of observations banner and modal

    The "quick tour" option has been removed from the Observations page header. Help content is now available in the User Guide.

Resolved Issues - 18 April 2024

  • DSER-41165: Fixed an issue where the sensor sent 0s for the local IP or remote port

    This resulted in the UI displaying unexpected characters.

  • EA-24443, LC-4795: Updates to netconn_location and netconn_remote_location Fields

    Important:

    Technically, this fix is not included in 1.25; it was released async from our standard release cadence on April 4, 2024, but it is documented here since 1.25 is the closest subsequent release.

    The netconn_location field (supported in Investigate search) and netconn_remote_location field (supported in Process Analysis search) leverage a geolocation database to report the location associated with a remote IP address value. It is important to note that this geolocation database only contains public IP addresses. The reported location is in the format “City,Region/State,Country”. Originally, if the geolocation database did not contain the IP address or if the IP address is not public, the reported City, Region/State, and Country values would be blank, reported as “,,,” in the UI. In an effort to make these fields more informative and valuable, we updated them to report “,,Unknown” if the geolocation database does not contain the IP address and “,,Private” if the geolocation database does not content the IP address, but the IP address is in the range of private IP addresses, as defined by RFC 1918. However, after making this change, we realized the “Private” classification is too narrow since “Private” is a subcategory of “Reserved”, meaning IP addresses that are reserved for special purposes. Therefore, we decided to create a new “Reserved” classification, which includes IP address ranges that were formerly classified as “Private” plus additional ranges that are classified as reserved for special use, and we deprecated the “Private” classification. This fix yields the following behavior:

    • A specific “City,Region/State,Country” value is reported if the remote IP address is public and the geolocation database contains the associated location.

    • “Unknown” is reported if the geolocation database does not contain the remote IP address.

    • “Reserved” is reported if the geolocation database does not contain the remote IP address, but the IP address is within one of the following ranges that are reserved for special use:

      • IPv4: 0.0.0.0/8, 0.0.0.0/32, 10.0.0.0/8, 100.64.0.0/10, 127.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, 192.0.0.0/24, 192.0.0.0/29, 192.0.0.8/32, 192.0.0.9/32, 192.0.0.10/32, 192.0.0.170/32, 192.0.0.171/32, 192.0.2.0/24, 192.31.196.0/24, 192.52.193.0/24, 192.88.99.0/24, 192.168.0.0/16, 192.175.48.0/24, 198.18.0.0/15, 198.51.100.0/24, 203.0.113.0/24, 224.0.0.0/4, 233.252.0.0/24, 240.0.0.0/4, 255.255.255.255/32

      • IPv6: ::1/128, ::/128, ::ffff:0:0/96, 64:ff9b::/96, 64:ff9b:1::/48, 100::/64, 2001::/23, 2001::/32, 2001:1::1/128, 2001:1::2/128, 2001:2::/48, 2001:3::/32, 2001:4:112::/48, 2001:10::/28, 2001:20::/28, 2001:30::/28, 2001:db8::/32, 2002::/16, 2620:4f:8000::/48, fc00::/7, fe80::/10

What's New - 27 March 2024

  • New Audit Logs API

    A new Audit Log API is available with export, search and queue endpoints.

    • The API uses a new path /audit_log/v1/orgs/{org_key}/logs/ which conforms to standards and uses an API Key with a Custom access level type

    • Search - Use the same query, criteria and exclusion operators in the request as other API endpoints

    • Export - An asynchronous request that uses the same request structure as Search to submit the job.  Then use the Jobs service to download results in CSV or JSON format.

    • Queue - equivalent functionality to the legacy route, updated to conform to URL and field naming standards.

    Get details in the Developer Network Blog https://developer.carbonblack.com/2024/03/announcing-the-carbon-black-cloud-audit-logs-api-release/

  • MDR Platform Migration Banner

    Carbon Black Managed Detection & Managed Detection and Response customers have an announcement banner on the Dashboard & Alerts page. These customers will soon be migrated to the new in-console MDR experience. Currently, communication of likely threats occurs through email only. Once migrated to the new experience, customers will see MDR context on eligible alerts on the Alerts page of the Carbon Black Cloud console. Email notifications are still available and will be configured through Settings → Notifications.

    The target for migrations is April - May, 2024. An exact date will be communicated with customers through an In Product Notification one to two weeks prior to migration.

    Customers can learn more, provide feedback, and ask questions in Product Board: https://portal.productboard.com/b6blafajly4nkk5mkt8shcpd/c/125-in-console-managed-detection-response


Resolved Issues - 27 March 2024

  • CBC-27346: Console does not display selected set of TTPs while updating a TTP rule

    When updating a TTP (Tactics, Techniques, and Procedures) rule type, the console now displays the previously selected set of TTPs.

What's New - 14 March 2024

Build 1.24

  • Digital Signature Improvements

    In response to customer feedback, Carbon Black Cloud has improved the way we render the state of the digital signature associated with processes and files. We now distinguish the three ways by which Carbon Black Cloud captures digital signature telemetry, and clearly label the approaches that were used to capture this data.

    These enhancements can improve your ability to determine whether the executables and other files observed on your endpoints are legitimate or anomalous, and how you can prevent future unwanted activity. You can compare:

    1. Effective Signature: What the sensor knew about the file signature at the time of a specific read, write, or execute event.

    2. Most Prevalent Signature: What has been observed for this file across your fleet of endpoints for the past 90 days (for customers who have Enterprise EDR with Windows endpoints).

    3. First Seen Signature: What was observed the first time the file was noticed by Carbon Black Cloud on the first endpoint that reported it (for customers who have Endpoint Standard).

    Carbon Black Cloud shows the Effective Signature whenever the effective signature data is available, then prioritizes to make Most Prevalent Signature available where possible, and only shows First Seen Signature when Most Prevalent Signature is not available.

    The Signature section is clearly labeled:

    • Each displayed signature is labeled Effective Signature, Most Prevalent Signature, or First Seen Signature.

    • "Signed" is now spelled out "Signature Status" and the status value displays next to it.

    • "Publisher" value is  shown only one time.

    • "CA" is spelled out "Certificate Authority".

    • Publisher and Certificate Authority are grouped together.

    Previous approach.

    Current approach:.

    These changes ensure that you will no longer see Signature values that vary (because they used different inputs) when tracking an investigation from page to page, when comparing API responses to the console, or when comparing console and API to Data Forwarder output.

    For more information, see About Digital Signatures in the Carbon Black Cloud User Guide.

  • Multi-Factor Authentication

    • Duo Security - Carbon Black Cloud has been updated to support the Duo SDK v4 Universal Prompt.

    • In multi-tenancy environments, to switch to a child organization that has MFA enabled, the parent organization is also required to have MFA or SAML enabled.

  • Improvements to Ban/Approve

    The Ban/Approve popup window has been updated to source "This hash has been seen on X devices" data from Investigate. There are two visible changes:

    • The time window for this value is now 30 days instead of 3 months.

    • The "X devices" text is now a link that pivots to the Investigate page by hash so that users can further examine the devices where the hash was seen. 

Resolved Issues - 14 March 2024

  • CBC-32547: Some Observations data that are based on fileless scriptload activity (and which include fields prefixed fileless_scriptload_*) were being labeled as event_type:scriptload

    They are now labeled event_type:fileless_scriptload.

  • DSER-50831: Users were unable to delete assets from the Inventory pages when an asset was in "Pending install" state

  • CBCUI-4877: Command lines in the right panel were sometimes not wrapping, forcing users to find and click the popup window

  • DSER-45780: Endpoint Standard-only environments are experiencing inconsistencies in hash signatures

    Add Hash to Company Approved List showed the file had one signature state (for example, Signed), while the Alert Triage page showed the file had a different signature state (for example, Not Signed).

  • DSER-40448: Differing signature states

    Some binaries reported one signature state in the console and a different state in the Data Forwarder output as seen in integrations like the Splunk app.

  • DSER-50283: The right pane of the Alert Triage page was not wrapping correctly

What's New - 28 February 2024

  • Data Forwarder support for Auth Events

    As an Enterprise EDR customer, you now have the option to add a new type of Forwarder to send all Authentication Events to a Forwarder destination (AWS S3, Azure Blob Storage Container) as they are reported by your Windows sensors. The Auth Events forwarder type fully supports Semantic Versioning, and initially releases with a v1.0.0 schema and can be configured with Schema updates (version_constraint in the API) of 1.0.0 (pinned), 1.0.* (patch) or 1.*.* (minor).

    This also means that Data Forwarder users can opt-in for automatic upgrades of their Auth Events forwarder, as and when new Auth Event forwarder schemas are released in the future, just like with all other Data Forwarder types that support Semantic Versioning.

  • Data Forwarder versioning improvements

    Finalizing our support for Semantic Versioning in the Data Forwarder, we are making the following changes:

    • Improvements to the Endpoint Event filtering capability, which will ensure that all filters assigned to a single Endpoint Event forwarder instance include only those fields that are available in the schema version that your Endpoint Event Forwarder instance has currently selected. 

      • For example, you cannot set a filter on an Endpoint Event forwarder of version "1.0.0" that includes the netconn_application_protocol field.

      • When using the Add Forwarder and Edit Forwarder pages, the Custom Query filter section no longer suggests field names that are not valid for the version of the schema currently selected for your Forwarder.

    • Validating Endpoint Event filter when editing a Forwarder: when you update Endpoint Event filters on an existing Forwarder - or if you change the Schema version/constraint assigned to your Endpoint Event forwarder - the Carbon Black Cloud Data Forwarder service compares the new combination of Schema version and filters. 

      • If you select an older Schema version for your existing Endpoint Event forwarder, and one of your filters includes a field that isn't available in that schema version, the Forwarder service will not accept your requested change - the filters will have to be modified to use only compatible fields.

      • If you attempt to change a filter for your existing Endpoint Event forwarder and add a field that's not available in the current schema version, the Forwarder service will also reject this change

      • An error message will indicate; for example "netconn_application_protocol is not valid for version 1.0.0"

  • Data Forwarder Config API adds optional field to two API endpoints

    • The /validate_filter API route now includes version_constraint as an optional input. This will enable the CBC console and the API consumer to determine exactly which fields are supported in the selected schema version. If version_constraint is not included in the request, the API will validate against the lowest supported schema version (currently 1.0.0 version of Endpoint Events schema).

    • When using the Filterable Event Schema API route, caller can specify version_constraint URL parameter. When specified, the API will return all filterable fields available for that schema version; if not specified, the API will return all filterable fields for the lowest supported schema version (that is, version "1.0.0" of the Endpoint Event schema).

  • Data Forwarder APIs now enforce schema compatibility

    • Create Filter or Edit Filter API routes, the API will check the version_constraint value for the associated config ID; if any field in the query is not available in that schema version, the API will return an error indicating which field(s) are not valid.

    • When using Edit Forwarder API route, the API will check the fields used in all query values for all Filters assigned to that forwarder; if any field in any Filter's query is not available in the specified (or default) version_constraint, the API will return an error indicating which field(s) are not valid.

What's New - 15 February 2024

Build 1.23

Alerts

  • Anomaly Classification

    The Watchlist alert Anomaly Classification is now available in the Sydney region. 

    Note: This feature supports Carbon Black Advanced Threats and AMSI Threat Intelligence watchlists.

    For more information, see Anomaly Classification in the VMware Carbon Black Cloud User Guide.

  • Enhancements to Alert Email Notifications

    We are excited to announce that we have completed enhancements to alert email notifications. We have introduced additional fields such as parent and child process information, process username, MITRE ATT&CK information, and other highly requested fields.

Container Essentials

  • Kubernetes Cluster Deployment

    We are excited to announce significant updates to our Kubernetes Sensor setup, a response to valuable feedback from our customer base. To simplify the setup process, customers can now pull images from private registries to enable seamless integration with various image repositories. In this release, we've also introduced native support for Helm charts to, thereby offering users a choice between Helm and traditional kubectl for deploying their clusters. This addition provides greater flexibility and efficiency in managing Kubernetes applications. These improvements are not just limited to new installations; existing users can also benefit from these features through both manual and remote updates of the sensor. This release represents our commitment to continuous improvement and customer-centric development, ensuring our Kubernetes Sensor setup remains a simple, efficient, and versatile tool for your orchestration needs.

    Additional Setting (CNS-3276):

    DevOpsteams can now configure advanced sensor setup options seamlessly within the existing experience.

    Properties such as Proxy server (with URL or empty) and Private registry (with URL or empty, acknowledging limitations) are now user-configurable.

    Helm Integration (CNS-3159):

    DevOps and DevSecOps professionals can leverage Helm for Carbon Black Kubernetes sensor setup.

Data Forwarder

  • Data Forwarder Versioning Improvements

    Investing further in our support for Semantic Versioning in the Data Forwarder, we are making the following change:

    • Adding and Editing forwarders via the console now allows every Forwarder type (Alerts, Endpoint Events, Watchlist Hits) to select "Schema updates" and "Schema version/constraint" options. Specifically this adds "Schema updates" support to Alert forwarder, and both "Schema updates" and "Schema version/constraint" support to Watchlist Hit forwarder

Workloads

  • Auto Sensor Installation

    We are excited to announce a new feature for workloads  "Auto Sensor installation". As part of this feature, whenever a workload is detected on a given vCenter and the workload is in an eligible state, the auto-sensor install will be triggered. There are no Rule definitions: every eligible workload will be automatically triggered for sensor installation. This will require a one time consent from the end user as part of system settings.

XDR

Resolved Issues - 15 February 2024

  • DSER-49788: API results not displayed

    Although the API successfully fetched results for customers who have enabled APC uploads, they were not displayed in the Cloud Analysis user interface.

  • DSER-47090: An alert with 4758 events prevented the generation of an alert triage tree

    This led to a visually cluttered page with numerous lines, and ultimately caused browser crashes.

  • CBCUI-4724: Policy permissions file path deletes if no actions are selected

    When no actions were selected on existing policy rules, the Policy Permissions Paths were deleted.

Container Essentials

  • CNS-3353: Deleting a cluster did not delete all the images data

  • CNS-1290: Increase the runtime scanning image size limit to 2GB

Managed Detection & Response

  • DSER-51353: Fixed MDR search and facet criteria exclusion

Update - 31 January 2024

In this release:

Event Reporting and Sensor Operation Exclusions

VMware Carbon Black is pleased to announce the release of the Event Reporting and Sensor Operation Exclusions feature. Event Reporting and Sensor Operation Exclusions increase the ability of VMware Carbon Black Endpoint Standard and VMware Carbon Black Enterprise EDR customers to tune product behavior to resolve operational issues and meet business needs.

VMware Carbon Black Endpoint Standard and VMware Carbon Black Enterprise EDR are powerful security solutions that collect large volumes of data and constantly evaluate endpoint activity to keep organizations safe from cyber attacks. Normally, these products’ default behaviors do not need to be suppressed, but in some cases, it can be necessary to tune their event reporting and/or sensor operation behaviors to resolve operational issues such as network performance issues, endpoint performance issues, or interoperability issues with third-party software.

There are two main types of exclusions:

  1. Event Reporting Exclusions

  2. Event Reporting and Sensor Operation Exclusions

Event Reporting Exclusions are the appropriate solution for network performance issues, while Event Reporting and Sensor Operation Exclusions are the appropriate solution for endpoint performance and interoperability issues.

Event Reporting Exclusions decrease the number of events that are reported by the sensor to the Cloud, therefore reducing network bandwidth consumption, and only apply to Carbon Black Enterprise EDR.

Event Reporting and Sensor Operation Exclusions decrease the number of events the sensor reports to the cloud and the number of operations the sensor performs, such as generating a hash, gathering signature information, evaluating reputation, performing detections, etc.

Event Reporting and Sensor Operation Exclusions are applied on a per-process basis and are highly customizable to allow you to resolve operational issues with the narrowest exclusion possible, and therefore the minimal detriment to endpoint visibility and security efficacy.

Event Reporting and Sensor Operation Exclusions are supported on Windows sensors 3.6+, but are most effective on Windows sensors 4.0+.

For more information, see Event Reporting and Sensor Operation Exclusions and Comparing Permissions to Exclusions in the VMware Carbon Black Cloud User Guide. VMware Carbon Black strongly advises customers to review this User Guide documentation before using the feature.

Update - 30 January 2024

In this release:

Improved security posture for API Key Management

When you create a new API key, store the API Secret securely as you would a password.

Important:

Get more tips for security API Access in this blog: Reminders of Recommended Practices for Securing API Access

What's New - 18 January 2024

Build 1.22

This release includes:

Endpoint Standard

  • You can now craft Core Prevention Exclusions directly from the Alerts page and leverage elements of the alert itself to auto-fill exclusion criteria

    To start this process, find an alert that was generated from a Core Prevention category, such as the one below:


    In this case, this alert is from a Credential Theft Core Prevention. From the alert, navigate to the Remediation section where you will find a new Add exclusion option:


    After clicking the Add button, you can check off the attributes to include in your exclusion. After checking the boxes, the metadata from that attribute will auto-fill into the exclusion creation window. You can add, edit, or modify attributes.


    This new functionality should help reduce the time required to craft Core Prevention Exclusions.

Audit and Remediation

  • Live Query API - Scroll Query Results

    You can now retrieve query results for devices across multiple runs. This API endpoint supports pagination beyond 10k results. After requesting the initial results, make additional requests to view the remaining results as they become available. These requests can be repeated until all responses have been requested. 

    More information can be found on the Carbon Black Developers website. 

  • New Recommended Queries - Sensor Analysis

    The Windows Live Query Extension Tables have been expanded with the release of the Windows 3.9 Sensor release. New Recommended Queries based on these tables are now available on the Live Query > New Query > Recommended tab.

    New Recommended Queries

    • Canary File Information - Collect and view information about canary files managed by the CBC Windows sensor. Requires Carbon Black Cloud Windows sensor versions 3.9+.

    • Curl Connection Information - Review information about curl requests made by the CBC Windows sensor to validate connectivity. This can help diagnose intermittent connectivity issues or provide insight into sensor network activities. Requires Carbon Black Cloud Windows sensor versions 3.9+.

    • Interactive Logon Session Information - Review the logon session information gathered by the CBC Windows sensor for interactive logon types. Requires Carbon Black Cloud Windows sensor versions 3.9+.

    • Non-interactive Logon Session Information - Review the logon session information gathered by the CBC Windows sensor for non-interactive logon types. Requires Carbon Black Cloud Windows sensor versions 3.9+.

    See the VMware Carbon Black Cloud User Guide for more information on our Live Query Extension Tables.

Vulnerability Management

  • Additional Data Columns

    This release improves the ability to view and customize data in Carbon Black Cloud’s Vulnerability Management UI.

    • In order to quickly understand what patch or update can be applied to remediate a specific vulnerability, the Resource column has been added when viewing by vulnerabilities.

    • Information of when the vulnerability data for a specific asset was last updated is now available as the Last Daily Assessment column when viewing by asset.

    Both of these data points are still available in the details pane of their respective views. In addition, the ability to configure which columns are displayed and in what order has been added to the Vulnerability Management UI.

Asset Groups

  • Each org now has a limit of 100 asset groups. This increased from 50

  • A new facet item for “None” has been added to the Asset Groups facet list on the Inventory pages

    Selecting “None” displays all assets that are not assigned to an asset group.

    TIP: When performing a search on the inventory page, any field search containing only “none” (example: asset_group_name: none) will result in a display of all assets that do not belong to a group.

  • The asset counts on the Preview Impact screen are now clickable and will display the full list of all assets in the list you selected


Data Forwarder

  • Data Forwarder now supports Azure Blob Storage Containers

    Users of the Data Forwarder now have two destinations to deliver data using the Data Forwarder: AWS S3 and Azure Blob Storage.

    This release adds support to the Data Forwarder to deliver forwarded data to Azure Storage Containers. This new option is available today for Alert and Watchlist Hit forwarders; this will be made available as a paid add-on later this year for the Endpoint Event forwarder, to pass through the costs of delivering high-volume data outside of the AWS data centers.



    For more information, see the UEX post: Announcing Azure Support for the Carbon Black Data Forwarder

Container Essentials

  • Alert and report on TLS version

    You can now identify workloads that violate your TLS compliance or security standards.

    You can show all TLS connections which are lower than user-defined version (default is 1.2).

    To view your TLS connections, navigate to Inventory -> Containers -> k8s network -> TLS compliance tab.

    In addition, you can now create an Alert on a TLS connection lower than the user-defined version (default is 1.2).

API Key

  • On the API Access Level Page, the time the API Session was last renewed is displayed making it easier to determine which API keys are in active use

    This makes it easier to determine which API keys are in active use; for example, regular polling for an integration.  An Audit Log is also written each time the API Session is renewed.

Resolved Issues - 18 January 2024

  • CNS-1241: Image scanning data is now deleted after 90 days

  • DSER-49561: There is a reported anomaly on the Watchlists page in the Processes tab

    The report name is not populating correctly; it appears as "(Deleted).

    Note: This was fixed in build 1.21.

  • DSER-50376: Fixed various Asset Groups operations to properly record user IP address in Audit Logs

  • DSER-50824: Fixed defect preventing customers with MSM groups from deleting old policies without endpoints after upgrading to Asset Groups and re-assigning endpoints to new policies

  • EA-24040: Mismatch with the CSV export data compared to the console between Nov 22 and Nov 24

    Note: This was fixed in build 1.21.

Update - 09 January 2024

Host-Based Firewall

  • Location-aware Network Profiles

    Host-based firewall has introduced a capability for users to assign different host-based firewall rules to an asset based on its location. You can now apply each rule to any combination of three available profiles: Domain, Private, and Public. The network profile itself is inherited from the Windows OS, but can now be applied for specific host-based firewall rules. This functionality is available for Windows sensor 4.0 and above. Existing rules and older sensor versions have host-based firewall rules applied to all profiles.

check-circle-line exclamation-circle-line close-line
Scroll to top icon