ITSM v2.1.0 and SecOps Apps v2.1.0 for ServiceNow - User Guide


Overview

Depending on what features you have with ServiceNow, Carbon Black offers two main Integration apps:

  • ITSM App: When an alert occurs in Carbon Black Cloud, create a ticket in ServiceNow. The VMware Carbon Black Cloud integration with the ServiceNow IT service management (ITSM) module provides endpoint device context and metadata within tickets to streamline IT workflows and reduce manual data collection.
  • SecOps App: When an alert occurs in Carbon Black Cloud, create an incident in ServiceNow. The VMware Carbon Black Cloud integration with the ServiceNow SecOps module provides access to additional endpoint response actions, threat intelligence and metadata to contextualize and accelerate security investigations.

Both apps have a reliance on the Base App, which is used to manage the connection between Carbon Black Cloud and ServiceNow and integrate relevant endpoint alerts and context directly into ServiceNow ticketing and incident workflows. The Base app is automatically installed when installing the ITSM app or SecOps app

Roles and Permissions

For all actions described in this user guide, the VMware CBC Analyst (x_vmw_cb_connector.analyst) role is required.

Configuration of the application, including of profiles, requires VMware CBC Admin (x_vmw_cb_connector.admin). Details on Roles and Users are on the Configuration page.

Domain Separation (Multi-tenancy)

  • Use the Domain Separation feature to isolate Carbon Black Cloud data from different organizations and manage access controls.
  • You must activate the Domain Support - Domain Extensions Installer plugin to use this feature.
  • Use the Domain Separation feature to create child domains and assign users to a specific domain.
  • Users can have multiple child domains assigned to a Parent domain.
  • Each child domains can have separate Configuration Profiles with different alert records.

Alert Ingestion

Alerts are ingested from Carbon Black Cloud and populate the Alerts table in ServiceNow.

Configure a profile to ingest Alerts from Carbon Black Cloud into ServiceNow.

Three types of alerts are supported for ingestion into ServiceNow, depending on the Carbon Black Cloud subscription you have purchased:

  • CB Analytics Alerts
  • Device Control Alerts
  • Watchlist Alerts

Once you configure the Profile and activate data collection for the REST API approach, the connector app fetches the alerts from Carbon Black Cloud and populates them in the Alerts table in ServiceNow.

• Navigate to VMware Carbon Black Cloud > Alerts.

• Open any Alert record

Automatic Incident Creation

Configure a profile to have ServiceNow ITSM Incidents (ITSM App) or ServiceNow Security Incidents (SecOps App) created automatically when Alerts are ingested, based on Incident Creation and Alert Aggregation settings.

  • If the “Apply Incident Creation” checkbox is enabled, the app will automatically create an Incident based on the Incident Creation and Alert Aggregation criteria specified.
  • If you have provided any conditions for Alert Aggregation, the app will create an Incident and link alerts in the Incident based on that Alert Aggregation conditions.
  • Alert fields are mapped to Incident fields based on the saved profile in the Field Mapping section of the Configuration Profile.

Manual Incident Creation

Incidents can be created manually from alerts; a ServiceNow ITSM Incident if you are using the ITSM App or a ServiceNow Security Incident with the SecOps App. The fields of a manually created Incident are populated based on the Field Mapping settings of the Configuration Profile that ingested the alert.

Incidents can only be created for alerts in an Open state.

You must select “Carbon Black Cloud - ServiceNow SecOps Integration” or “Carbon Black Cloud - ServiceNow ITSM Integration” in the “Select Integration To Create Incident” field in the Configuration profile in order to create Incidents from alerts.

• Navigate to VMware Carbon Black Cloud > Alerts


• Click to view any alert record in an Open state.

• Click on the "Create Incident" button (top/bottom).

• An Incident will be created for that alert, alert fields mapped to the Incident field, and the Security Incident ID displayed in the alert record.

• Open the Incident by clicking "Preview this record" > "Open record".

To view the list of alerts associated with an Incident:
• Scroll down on the Incident Page
• Under "Related Links," click on "Show All Related Lists"
• A new set of tabs will appear underneath.
• Click on the "Alerts" tab to view the list of alerts associated to the Incident.
An Alert can be manually added to an existing Incident.

• Go to the Alert page
• Clicking on the "Search" button next to the "Incident" field ( i.e. "Looking using list").

• The Incident table will be opened in a new tab.
• Search and select an Incident to attach the alert to the selected Incident.

• The alert is now attached to the Incident. Open the Incident from the reference provided as mentioned in the above steps.

Bi Directional Sync

Updating the status of alerts in either ServiceNow or Carbon Black Cloud will result in the update flowing to the other system.

  • Dismissing an alert in ServiceNow will also dismiss the alert in Carbon Black Cloud. This happens automatically.
  • When an Alert is Dismissed or Undismissed in Carbon Black Cloud, use the “Sync Selected Alerts” function to update the alert’s state in ServiceNow.
  • Note: The alerts table may appear differently in different browsers.

Synchronise Alert Dismissal

Ï If an alert was Dismissed or Undismissed in Carbon Black Cloud, synchronise the ServiceNow status by clicking the “Sync Selected Alerts” button.

  • If an alert is dismissed in Carbon Black Cloud, then in ServiceNow the alert, workflow, remediation status, and close note will update.
  • If an alert is undismissed in Carbon Black Cloud, in ServiceNow the alert status will update to “OPEN,” and the workflow, remediation status and close note will also update.

Use this procedure after Alerts that were ingested to ServiceNow have been Dismissed or Undismissed in the Carbon Black Cloud console.

• In ServiceNow, open the Alerts table.
• Select alerts that were updated in Carbon Black Cloud to synchronise with Service Now.
• Click the "Sync Selected Alerts" button

• A pop-up will display the message "Selected alerts synced successfully with Carbon Black Cloud alerts."

• The app updates the status, workflow, remediation status and close note for each Alert record in ServiceNow based on the status in Carbon Black Cloud.
• Open the selected alerts in ServiceNow and check the status, workflow, remediation status and close note.

Asset Inventory Ingestion

If enabled in the Configuration Profile, asset inventory data from Carbon Black Cloud will be ingested into ServiceNow and stored as Configuration Items in tables in the ServiceNow CMDB, and as entries in the Carbon Black Assets custom table. Note that an alternative term for asset is device, and there are two classes of Carbon Black Cloud assets; Endpoint and Workload.

  • Asset fields that get mapped to Configuration Item fields in CMDB tables will get stored in the cmdb_ci_computer and cmdb_ci_virtual_instance CMDB classes/tables.
  • Asset fields which do not get mapped with CMDB Configuration Item tables will get stored in the custom table Carbon Black Assets, accessible from VMware Carbon Black Cloud > Inventory.
  • The Configuration Item and Carbon Black Asset Custom table entries will be linked.
  • The appropriate CMDB class will be chosen as per the value in the deployment_type field in the device response from Carbon Black Cloud.
    • Assets of type Endpoint will be stored in the cmdb_ci_computer table.
    • Assets of type Workload will be stored in the cmdb_ci_virtual_instance table.

To view the “Computers” CMDB table navigate to “Computers”: Configuration > Base Items > Computers.

To view the “Virtual Machine Instances” CMDB table navigate to Virtual Machine Instances: Configuration > VMware > Virtual Machine Instances.

Use these steps to add the following related lists to the Computers and Virtual Machine Instances tables. This is used to view additional data gathered from Carbon Black Cloud as part of SOAR workflows.

For each of the data types below, the corresponding SOAR action will result in data that can be attached to and viewed from the CMDB entries.
• Asset Information - Get Asset Information
• Events - Get Enriched Events
• Carbon Black Running Processes - Get Running Processes at Carbon Black
• File Systems - Get Directory Information
• Process Metadata - Get Process Metadata
• Registry Keys - Get Registry Key Information on Asset
• Submit Live Query Run - Submit Live Query Run
• Alert Recommendations - Get Policy Recommendations
• Observables - Get File from Asset, Download Binary from UBS

1. Navigate to the CMDB tables for either Computers or Virtual Machine Instances.

2. For example, open the Computers table and a list of Computer records will be shown.

3. Open any one record.
4. Click on the “Additional actions” button.

5. Click on “Configure” and select the “Related Lists” option.

6. Click on “Edit this view”.

7. Search for the related list that needs to be added here.
8. For example, a related list for Events is shown (Event->Configuration Item). Click on the “>” button(right arrow) to add it to the Selected set of fields.
9. Make sure to add the “Carbon Black Cloud Devices” field alongside any other fields you may require.

10. Click on the “Save” button.

11. On the original CMDB table entry (e.g. Computer record), scroll down to the Related Lists and check that the “Carbon Black Cloud Devices” related list is added.


Close Incident

When an Incident is closed, if there are open alerts associated with it then a consent form appears to select the alerts you want to dismiss before closing the Incident. The consent form will not appear if all alerts associated with the Incident are already dismissed.

• Navigate to the ITSM Incident to be closed.
• Go to the State field, select Closed.
• Fill out the mandatory fields - Caller information, Resolution notes, and Resolution code.

• Right-click on the incident taskbar and select the Save option.

• After clicking Save, a consent form displays.
• Choose the alerts to dismiss when the ITSM Incident is closed.
• Click the Resolve button. Clicking the Resolve button will close the ITSM Incident and dismiss only the selected alerts.

• The ITSM incident is resolved.
• Navigate to Security Incident > Show All Incidents.
• Select the Incident to be closed.
• Go to the State field, select Recover.

• Right-click on security incident taskbar, and select the Save Option

• For "State", select "Closed".

• Provide the appropriate close code and close note in Closure Information.
• Right click on the security incident taskbar and click the Save option.

• After clicking Save, a consent form displays.
• Choose the alerts to dismiss when the Security Incident is closed.
• Click the Resolve button. Clicking the Resolve button will close the Security Incident and dismiss only the selected alerts.

• The incident is resolved.

• The selected alerts will be dismissed.

MITRE TTP Classification - SecOps App Only

Using the Threat Intelligence plugin, TTPs from Carbon Black Cloud alerts are enriched and visualized in ServiceNow Security incident tickets using the MITRE ATT&CK framework .

To perform the MITRE TTP Classification, install and configure the Threat Intelligence plugin.
before performing MITRE TTP classification on a Security Incident.

The Threat Intelligence plugin and MITRE TTP Classification is only available when using the ServiceNow SecOps module.

MITRE TTP classification is compatible with alerts whose Alert Type is CB_ANALYTICS.

  • When a Security Incident is created from an alert which has Alert Type of CB_ANALYTICS, a the MITRE TTPs from the Alert’s Threat Indicators field are mapped to Security Incident’s “MITRE ATT&CK Technique” field. If there are multiple TTP values, they are mapped as a list separated by commas(,).
  • MITRE TTP Classification works on Security Incidents created both manually and automatically.
  • If field mappings are included in the Profile for the MITRE Fields, then they are overridden according to the MITRE TTP present in corresponding Alerts.

• Navigate to Alerts
• Select alerts that are alert type "CB_ANALYTICS".

• On the alert, view the Threat Indicator > TTPS field to check whether the alert has MITRE TTP values. (If not, the MITRE ATT&CK Technique on the incident will not be populated.)

• Click on the Create Security Incident button.

• Once the Security Incident gets created, check its "MITRE ATT&CK Technique" value, which has a comma-separated list of all the TTPs that are part of this Security Incident.

• MITRE ATT&CK Technique will display the MITRE TTP ID and MITRE TTP name from the linked alerts.
• These can be visualized in the matrix above under the "MITRE ATT&CK Card" tab on the Security Incident page.
• Since the Security Incident above has multiple alerts, it has multiple MITRE TTPs values.

SOAR (Security Orchestration, Automation, and Response) Actions

The Apps have a collection of SOAR (Security Orchestration, Automation, and Response) actions that are initiated on Alerts from the Security Incident record page in ServiceNow and execute in Carbon Black Cloud.

To execute a SOAR action:

  • Login to ServiceNow.
  • Navigate to an Incident that has alert(s) linked to it.
  • In the Related Links section, click on Show All Related lists > Alerts.
  • Select one or more alerts.
  • From Actions on Selected Rows, Select the SOAR action to execute.


Each supported action is described in the following section.

Note: SOAR Actions are available based on their availability in the sensors deployed and the permissions configured for the API credentials.

This action adds the Indicator of Compromise (IOC) to a specific Feed.

• Can be run from Alert.
• The watchlist and report details must be configured in the Actions section of the Configuration Profile.
• Add the IOC to the Feed to impact the alerts generated for the watchlist type.
• If Watchlist is configured correctly in the profile, a pop-up displays.
• Select the Field and provide the values of IOC to be added in the Feed.
• The report is created or updated to add the IOC.

• If the Actions section in the associated Configuration Profile is not configured, a message indicates that you need to configure the action.
This action will add a note to one or more alerts.

• Can be run from Alert.
• Can be run on multiple alerts.
• If the action "Add Note to Alert(s)" is run multiple times with different comments, then each comment will be appended to the alert notes on Carbon Black Cloud.
Approve recommendations related to the policy associated with the Alert.

• Can be run from Alert.
• Can be performed on one Recommendation at a time.
• The "Approve Policy Recommendations" action is available in the related actions in the related list of Alerts.
• After the successful execution of the action, the state of the recommendation will change to ACCEPT from NEW.
• After the successful execution of the action, the recommendation will be in the reviewed state in the Carbon Black Cloud portal.
• Once the recommendation is approved the recommendation record in the "Alert Recommendation" record will be removed.
Control access to USB storage devices by approving access to a USB Device.

• Can be run from Alert.
• Can be performed on one Alert at a time.
• On the success of the action, the status of the USB device will be updated to "APPROVED" from "UNAPPROVED" in ServiceNow.
• If the action is performed on an alert that is APPROVED then the notes and Approval Name will be updated in Carbon Black Cloud based on the input provided by the user.
Ban a process hash for selected alerts.

• Can be run from Alert.
• Selecting the Ban process hash action displays a pop-up with three listed fields:
○ Process Name
○ Process Hash
○ Description

The threat_cause_actor_sha256 field from the alert record is the hash to be banned.
You can update any of the details in the pop-up form before initiating the ban.
Get the registry key information of the selected device or the device associated with the selected alert.

• Can be run from Alert and Device.
• Can be performed on one Alert or Device at a time.
• This action can be performed on windows devices only. If the action is performed on devices other than Windows the error message: "Action can only be performed on devices with WINDOWS OS." will be displayed.
• This action can only be performed on Carbon Black Cloud devices. If the user tries to select a device other than from Carbon Black Cloud the an error message will display in the pop-up box. "Cannot complete action. Asset does not exist"
• When “Create Registry Key” is performed then a registry key will be created at the specified path.
• If a user attempts to create a registry key with the same name at the same path again an error response is returned.
• Registry keys cannot be created as an immediate child for the parent keys "HKEY_USERS" and "HKEY_LOCAL_MACHINE". If the user attempts that an error response will be returned.
This action will delete a file from the Endpoint of selected alerts.

• Can be run from Alert and Device.
• Selecting this action displays a pop-up asking you to confirm that you want to delete the file.
• The file named in the "threat_cause_actor_name" field of the selected alerts will be deleted.
• If the user performs the same action from the device then the path of the file that needs to be deleted must be added.
• If this action is runon an alert that does not have a "threat_cause_actor_name" file attached to it, the action will not execute and a work note is added to the Incident indicating so.
• If the user tries to perform the action and the file does not exist on the selected device then the error will get populated in the work note.
Delete a registry key at the specified path from the selected device, or device associated with an alert.

• Can be run from Alert and Device.
• Can be performed on one Alert or Device at a time.
• This action can be performed on windows devices only. If the action is performed on devices other than Windows the error message: "Action can only be performed on devices with WINDOWS OS." will be displayed.
• This action can only be performed on Carbon Black Cloud devices. If the user tries to select a device other than from Carbon Black Cloud the an error message will display in the pop-up box. "Cannot complete action. Asset does not exist"
• When "Delete Registry Key" is started a popup with text input for the "Registry Key Path" is displayed. The registry key at the specified path will be removed.
• If a user attempts to create a registry key with the same name at the same path again an error response is returned.
• Registry keys cannot be created as an immediate child for the parent keys "HKEY_USERS" and "HKEY_LOCAL_MACHINE". If the user attempts that an error response will be returned.
Remove the Asset from Bypass Mode.

• Can be run from Alert and Device.
• Once the endpoint is removed from Bypass mode in Carbon Black Cloud, the status will display as "REGISTERED" in ServiceNow after the next device sync in the Carbon Black Cloud device table.
• If the endpoint associated with an alert is unbypassed then a note is displayed in Carbon Black Cloud for that alert.
• To directly bypass the endpoint user needs to add configuration items (affected CIs) to the related Security Incident.
Dismiss Alerts in ServiceNow, and the workflow change will be sent to Carbon Black Cloud. Alerts must be in the Open state to be dismissed.

• Can be run from Alert.
• Navigate to Alerts.
• Select any alert record that is in the Open state.
• Click on Dismiss Alert (top/bottom).

• Select an appropriate value from the Reason dropdown field and optionally add a comment. This comment will be written to the alert and visible in Carbon Black Cloud.

• Click on OK to dismiss the alert.
• That alert is dismissed in ServiceNow and in Carbon Black Cloud.
• After successful dismissal, alert state is updated to Dismissed.

• Workflow, Remediation State and Close Note are also updated for that alert.
Dismiss future alerts based on the selected alert’s threat id using the "Dismiss All Future Alerts" action.

• Can be run from Alert.
• Can be run on multiple alerts.
• After successful execution a note will be added in the alerts section in Carbon Black Cloud saying “Threat was dismissed with the comment: <comment>”.
• Future alerts with the same threat will be dismissed and alerts will not be generated for the same threat id.
• If this action is performed multiple times on the same alerts then a new note will be appended in Carbon Black Cloud.
Get the binary file associated with particular alerts from the Incident related list.

• Can be run from Alert.
• The downloaded Binary File is stored as an attachment in the "Secured Attachment" table record which can be accessed from the "Secured Attachment" field of the "Observable" record.
• File details are available in the "Observables" related list of alert records on which the action is performed.
Put the Asset into Bypass Mode.

• Can be run from Alert and Device.
• Once the endpoint is in Bypass mode in Carbon Black Cloud, the status will display as "BYPASS" in ServiceNow after the next device sync in the Carbon Black Cloud device table.
• If the endpoint associated with an alert is bypassed then a note is displayed in the Carbon Black Cloud for that alert.
• To directly bypass the endpoint user needs to add configuration items (affected CIs) to the related Security Incident.
Run a custom script on the selected endpoint, or endpoint associated with the selected alerts.

• Can be run from Alert and Device.
• Can be performed on one Alert or Device at a time.
• The custom script is on the selected endpoint with a valid path and command.
• Output is written to the path and file name specified in the output field.
Get recommendations related to the policy associated with the Alert.

• Can be run from Alert.
• Can be performed on one Alert at a time.
• The "Get Policy Recommendations" action is available in the related actions in the related list of Alerts.
• The fetched recommendations are shown on the alerts form view.
• On successful execution of the action, the "Alert Recommendations" related list in the alert will be populated with the record.
• Requests with the same recommendation id will get updated on multiple executions of action.
Get the metadata of the binary file associated with particular alerts from the Security incident related list.

• Can be run from Alert.
• Update the Binary file metadata field of selected alerts so you can navigate to its binary file metadata record from the alert.
• View the Binary file metadata record by navigating through the Alerts record page.
Get the information about the specified directory from the device / asset / endpoint.

• Can be run from Alert and Device.
• Tips on getting directory information:
○ c:\users - This path will get you only users' directory information.
○ c:\users\ - Note the extra "\" - this path will get you all files and directory information that fall under the user's directory.
• If the action is performed on CMDB devices, the user can see the File Systems related list in the configuration item (e.g. WIN-7K2KTN5JGVD).
• If the action is performed on alert, the user can see the File Systems related list in the alert. The same information can be used for Linux as well.
Get Asset Information of the device associated with selected alerts or a device from the security incidents related list.

• Can be run from Alert and Device.
• Endpoint / Asset information is displayed the table "Carbon Black Asset Snapshot" for the selected alerts at the bottom of the alert record page after the "Get Endpoint Info" is performed successfully.
• Associated alerts are displayed in the Endpoint Info record related list.
• Associated Endpoint Information is displayed in the alerts table’s related list.
• If the Action is performed multiple times then the data will be stored multiple times in the “Carbon Black Asset Snapshots".
Get the enriched events for particular alerts from the Security incident’s related alert list.

• Can be run from Alert.
• Store the Enriched Events data of selected alerts in a table named "Events" at the bottom of the Alert record page.
• A list field is added in the Enriched Events table that stores the alert ids of the alerts associated with the enriched event.
• This is only available for alerts of type CB_ANALYTICS.
Get the file from the device id associated with selected alerts from the "Alerts" related list or the "Configuration Items" related list on Security Incident.

• Can be run from Alert and Device.
• The file is stored as an attachment in the "Secured Attachment" table record which can be accessed from the "Secured Attachment" field of the "Observable" record.
• File details are available in the "Observables" related list of alert records as well as in the"Associated Observables" related list of the incident on which the action is performed.
Get the process details by searching Carbon Black Cloud events for the process_hash associated with the selected alert from the Security Incident related list.

• Can be run from Alert.
• Can be performed on one Alert at a time.
• The process details will be available in the "Process metadata" related list of alerts.
Fetch process details of selected alerts from the Security Incident’s related list.

• Can be run from Alert.
• Update the Process Metadata field of selected alerts.
• View the Process Metadata record by navigating through the Alerts record.
Get the registry key information based on the selected alert or device.

• Can be run from Alert and Device.
• When the action "Get Registry Key Information" is run a pop-up telling the user that the process is started is displayed.
• Registry key information will be added to the table "Registry Key Information" in the alert or device record.
• Work notes will be added for the process started, a process completed successfully, API failures and exception scenarios.
Get a list of running processes on an endpoint (device ID) associated with the alerts in the Security Incident’s related alert list. The action can also be performed from the Affected CI from the related list of Security Incidents.

• Can be run from Alert and Device.
• The action can be performed from the Affected CI from the related list of Incident.
• The action will fetch the running process, child processes, and parent processes from the selected devices.
• After successful execution of the action or in case of any failure or exception, the work note will be captured.
• A confirmation pop-up is displayed after performing "Get Running Process"
• Processes are displayed in the "Running processes" table at the bottom of the Alert record page.
• There is a reference to the alert included. Use this to navigate from the running process record to its associated alert(s) and back.
This action ignores an IOC in a specific Feed, meaning it will not trigger watchlist hits.

• Can be run from Alert.
• Can be performed on one Alert at a time.
• The report is updated by disabling the IOC.
• The action can be performed from the related list of the Security Incident table.
Kill the running process on an endpoint of selected alerts.

• Can be run from Alert and Device.
• Perform this action from the related list of Running Processes table from the Alert record page.

• A confirmation dialog displays indicating that the kill process action has begun.
• On successful killing of the process, the state in the Running Processes table for that process updates to "KILLED" and that process no longer displays in the "Running Processes" related list in the Alerts table.
• Since this action is executed from the "Running Processes" related list from the Alert record page, a Worknote is created in the Security Incident for "Kill Process"
Set the value of an existing Registry Key.

• Can be run from Alert and Device.
• Can be performed on one Alert or one Device at a time.
• This action can be performed on windows devices only. If the action is performed on devices other than Windows the error message: "Action can only be performed on devices with WINDOWS OS." will be displayed.
• When the action is performed the pop-up will show the "Registry key path", "Registry value name", "Registry value data" and "Registry value type" as mandatory input fields.
• "Registry value type" options are:
○ REG_SZ (default)
○ REG_BINARY
○ REG_DWORD
○ REG_EXPAND_SZ
○ REG_MULTI_SZ
○ REG_QWORD
• For "REG_DWORD" and "REG_QWORD" value types only integer values are allowed. An error response is returned for other data types.
• For the "REG_BINARY" value type only binary string will be allowed. An error response is returned for other data types.
• After successful completion of "Modify Registry Key Information on Asset", the new value will be visible in the specified path in the Registry Editor of the endpoint.
Put the last file attached to the security incident on the endpoint on the specified path.

• Can be run from Alert and Device.
• Can be run on one alert or device at a time.
• Can be performed from the Affected CI or Alerts from the related list on Security Incidents.
• The action will put the selected file on the inserted path.
• After successful execution of the action or in case of any failure or exception, the work note will be captured.
• All types of scripting files can be put on the destination device.
Quarantines the selected devices (assets, endpoints) or the endpoints associated with the selected alerts.

• Can be run from Alert and Device.
• Can be run on multiple alerts or devices.
• On successful execution, a note is posted to Carbon Black Cloud that reads, "Device associated with this alert has been quarantined from ServiceNow."
• If this action is run on alerts whose device OS is "LINUX" or "MAC" and sensor version is less than "2.13", a note displays in Carbon Black Cloud that reads, "This action is not supported on Linux devices with sensor version less than 2.13 installed."
• If the action is successful, a worknote message is added to the Incident record indicating that the action occurred.
• There may be a delay which reflects the timing of communication between Service Now, Carbon Black Cloud, and the endpoint.
Reject recommendations related to the policy associated with the Alert.

• Can be run from Alert.
• Can be performed on one Recommendation at a time.
• The "Reject Policy Recommendations" action is available in the related actions in the related list of Alerts.
• After the successful execution of the action, the state of the recommendation will change to REJECT from NEW and the entered comment will be stored.
• After the successful execution of the action, the recommendation will be in the reviewed state in the Carbon Black Cloud portal.
• Once the recommendation is rejected the recommendation record in the "Alert Recommendation" record will be removed.
This action removes an IOC from a specific Feed.

• Can be run from Alert.
• The watchlist and report details must be configured in the Actions section of the Configuration Profile.
• Removing the IOC from the Feed can impact the alerts generated for watchlist type.
• If a Watchlist is configured correctly in the profile, a pop-up displays.
• Select the Field and provide the values of IOC to be removed from the Feed.
• The report is updated by removing the IOC.

• If the Actions section in the associated Configuration Profile is not configured, a message indicates that you need to configure the action.
This action starts a live query run on the selected devices, or devices associated with the selected alerts.

• Can be run from Alert and Device.
• Custom SQL queries can be executed on the selected alerts or devices.
• Details of the live query for the associated endpoints are visible in the related list of alerts or devices after the execution of the selected action is completed successfully.
• More information on Live Query is in the Carbon Black Cloud User Guide.
Unban a process hash for selected alerts.

• Can be run from Alert.
• Selecting the Unban process hash action displays a pop-up with the field:
○ Process Hash

The threat_cause_actor_sha256 field from the alert record is the hash to be unbanned.
You can update the process hash field from the pop-up form before initiating the ban.
Unquarantines the selected devices (assets, endpoints) or the endpoints associated with the selected alerts.

• Can be run from Alert and Device.
• Can be run on multiple alerts or devices.
• On successful execution, a note is posted to Carbon Black Cloud that reads, "Device associated with this alert has been unquarantined from ServiceNow."
• If this action is run on alerts whose device OS is "LINUX" and sensor version is less than "2.13", a note displays in Carbon Black Cloud that reads, "This action is not supported on Linux devices with sensor version less than 2.13 installed."
• If the action is successful, a worknote message is added to the Incident record indicating that the action occurred.
Update the policy for the endpoint of selected alerts.

• Can be run from Alert and Device.
• Enter the Policy ID of the new Policy to apply to the endpoint.
• The updated Policy ID and Policy Name will display in the Selected alerts record.

To get the Policy ID in Carbon Black Cloud:
• Login to Carbon Black Cloud.
• Click on Enforce from the left side menu.
• Click on the Policies option and select a specific Policy from the list.
• The Policy ID is on the General tab.

Support and Resources


Last modified on February 28, 2024