VMware Carbon Black Cloud on VMware Cloud Services Platform | 16 May 2024

Check for additions and updates to these release notes.

What's New - 16 May 2024

  • 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:

  • Alert Triage Page Updates

    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.

  • 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.

Known Issues

The items listed below are the known issues at the time the software version was released.

For items specific to Carbon Black Cloud on the VMware Cloud Services Platform, see the section Issues Specific to Carbon Black Cloud on the VMware Cloud Services Platform.

All other issues listed in the remaining sections apply to the core Carbon Black Cloud product.

Carbon Black Cloud - 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.

  • CBCUI-5412: UBS data display

    When the Binary Details page shows no UBS data, and the user clicks the Ban button, the page may temporarily display non-UBS data.

  • 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.

  • DSER-46519: Currently users will not be able to find audit logs for downloading files from Inbox

  • DSER-49836: Policy assignment changes

  • 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

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

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

Enterprise EDR

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

  • TPLAT-9183: Signature status is UNKNOWN for valid signatures (first listed: 31 August 2020)

Issues Specific to Carbon Black Cloud on the VMware Cloud Services Platform

  • CBC-17603: Avira upload for Reputation will not be available upon release due to a bug regarding timing out of malware reporting, causing false negative results

    This means the ability to opt-in to automatically upload potential malware to Avira will be temporary disabled.

  • CBC-17619: Some API permissions have an incorrect name, using “threathunter” in place of “org”

  • CBC-17721: The integrationServices routes for audit logs and notification APIs are not yet available

    This only affects the API calls, and not the Notifications via email or the ability to view Audit Logs in the Carbon Black Cloud console.

Archive of 2024 Improvements and Resolved Issues

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

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.

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.

  • 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.

  • 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).

  • 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.

  • 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)

  • 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.

  • 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 will be some difference in the reported CVEs. With the Carbon Black-managed solution, we will now be able to more quickly respond to any data quality concerns raised by our customers.

    • Application vulnerabilities are only reported for 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 false positives and focuses application vulnerability reporting on the most commonly deployed applications, such as browsers, Microsoft applications, and more.

    • The Kenna Risk Score will be replaced with industry standard CVSS. 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 - 14 March 2024

  • 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 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

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

  • DSER-40448: Differing signature states

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

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

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

What's New - 15 February 2024

  • 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.

  • 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.

  • 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 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

  • 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.

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.

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

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

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

What's New - 18 January 2024

Build 1.22

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

To see the changes made in previous years, see:

This release includes:

  • 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.

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

  • 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+.

  • 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. 

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.

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.



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 Keys

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.

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