The ServiceNow VMware Carbon Black integration enables security teams to automatically ingest endpoint detection and response (EDR) alerts as security incidents, streamline threat containment through automated device quarantine workflows, and maintain accurate CMDB records enriched with real-time endpoint health data. This integration is essential for SOC analysts, security engineers, and IT operations teams who need unified visibility and response capabilities across their security infrastructure. The integration primarily uses uni-directional data flows from Carbon Black to ServiceNow for alert ingestion and CMDB enrichment, while supporting bi-directional communication for device quarantine actions triggered by ServiceNow workflows. The integration leverages the Security Incident Response application and CMDB modules, utilizing IntegrationHub spokes and scheduled imports to maintain continuous data synchronization.
Prerequisites
- •ServiceNow Vancouver or later with Security Incident Response plugin activated
- •VMware Carbon Black Cloud Enterprise license with API access enabled
- •IntegrationHub Professional license or higher for spoke-based integrations
- •ITOM Visibility license if enriching CMDB with Carbon Black device data
- •Security Incident Response role (sn_si.admin) for configuring security workflows
- •Admin role for configuring Connection & Credential records
- •MID Server installed and configured if on-premises Carbon Black deployment is used
Architecture Overview
The integration utilizes the IntegrationHub VMware Carbon Black spoke, which provides pre-built actions for retrieving alerts, device information, and executing quarantine operations through RESTful API calls. Authentication is established using API Key authentication stored in ServiceNow Connection & Credential Alias records, with the API key and organization key securely encrypted in the credential store. Data flows primarily from Carbon Black to ServiceNow through scheduled spoke actions that poll for new alerts and device status updates, with response actions flowing back to Carbon Black for quarantine operations triggered by ServiceNow workflows. A MID Server is required only for on-premises Carbon Black deployments, while Carbon Black Cloud integrations can leverage direct cloud-to-cloud connectivity through the ServiceNow instance. API rate limiting considerations include Carbon Black's default limit of 1000 requests per hour per API key, requiring careful scheduling of bulk data operations and implementation of exponential backoff retry mechanisms in spoke configurations.
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Implementation Steps
Create VMware Carbon Black API credentials and configure ServiceNow credential record
Navigate to your Carbon Black Cloud console and access Settings > API Access to generate a new API key with Custom access level, ensuring permissions include org.alerts.read, device.read, and device.quarantine for full integration functionality. Copy the generated API key and note your Organization Key from the console. In ServiceNow, navigate to Connections & Credentials > Credentials and create a new API Key credential record with name 'Carbon Black API Credential', setting the API Key field to your generated key and creating a custom attribute called 'org_key' with your organization key value. Verify the credential is properly encrypted by checking that the API Key field shows masked characters after saving the record.
Configure Connection Alias for Carbon Black Cloud endpoint
Navigate to Connections & Credentials > Connection & Credential Aliases and create a new record with name 'Carbon Black Cloud Connection' and type 'Connection and Credential'. Set the Connection URL to 'https://defense.conferdeploy.net' for US-based Carbon Black Cloud instances or your specific regional endpoint URL. Associate the previously created API Key credential record in the Credential field and configure the connection timeout to 60 seconds to accommodate potential API response delays. Test the connection using the Test Connection button to verify network connectivity and credential validity. Common connection failures at this stage indicate firewall restrictions or incorrect regional endpoint URLs.
Install and configure IntegrationHub VMware Carbon Black spoke
Navigate to System Applications > All Available Applications > All and search for 'VMware Carbon Black' to locate the official IntegrationHub spoke, then click Install to add it to your instance. After installation, navigate to Process Automation > Flow Designer and access the Carbon Black spoke to review available actions including 'Get Alerts', 'Get Device Info', and 'Quarantine Device'. Configure the spoke's default connection by editing the Connection field in each action to reference your previously created Connection Alias. Verify spoke installation by testing the 'Get Device Info' action with a known device ID from your Carbon Black environment, ensuring successful authentication and data retrieval.
Create Security Incident creation flow for Carbon Black alerts
Navigate to Process Automation > Flow Designer and create a new flow called 'Carbon Black Alert to Security Incident' with a schedule trigger set to run every 5 minutes during business hours. Add the Carbon Black 'Get Alerts' action as the first step, configuring it to retrieve alerts with severity 'HIGH' or 'CRITICAL' and status 'OPEN' from the last 10 minutes to avoid duplicate processing. Configure a For Each loop to process each returned alert, with a nested 'Create Record' action targeting the Security Incident table (sn_si_incident), mapping alert fields to incident fields such as alert summary to short_description, alert severity to priority, and alert device information to affected_ci. Include a condition check to prevent duplicate incident creation by querying existing incidents with the same Carbon Black alert ID stored in a custom correlation_id field.
// Custom script step to check for existing incidents
var gr = new GlideRecord('sn_si_incident');
gr.addQuery('correlation_id', fd_data.pill_carbon_black_alert_id);
gr.query();
if (gr.hasNext()) {
// Skip creation - incident already exists
fd_data.skip_creation = true;
} else {
// Proceed with incident creation
fd_data.skip_creation = false;
fd_data.incident_short_description = 'Carbon Black Alert: ' + fd_data.pill_alert_reason;
fd_data.incident_description = 'Device: ' + fd_data.pill_device_name + '\nThreat: ' + fd_data.pill_threat_cause;
}Configure automated device quarantine workflow
Create a Business Rule on the Security Incident table (sn_si_incident) with condition 'state changes to In Progress' and 'priority is 1-Critical' to trigger automatic quarantine evaluation. Navigate to Process Automation > Flow Designer and create a flow called 'Carbon Black Device Quarantine' with a Service Catalog trigger that accepts device ID and quarantine action parameters. Implement the Carbon Black 'Quarantine Device' spoke action with dynamic device ID mapping from the incident's affected CI, including error handling to catch quarantine failures due to device offline status or insufficient permissions. Add a follow-up action to update the Security Incident with quarantine status and timestamp, creating an audit trail of automated response actions taken.
// Business Rule script to trigger quarantine flow
(function executeRule(current, previous) {
if (current.state == '2' && current.priority == '1' && current.correlation_id.indexOf('CB-') == 0) {
var deviceId = current.u_carbon_black_device_id;
if (deviceId) {
// Trigger quarantine flow
var flowAPI = new sn_fd.FlowAPI();
var inputs = {
'device_id': deviceId,
'incident_sys_id': current.sys_id,
'action': 'quarantine'
};
flowAPI.getFlowFromName('Carbon Black Device Quarantine').withInputs(inputs).run();
}
}
})(current, previous);Implement CMDB enrichment with Carbon Black device data
Navigate to System Import Sets > Administration > Data Sources and create a new data source called 'Carbon Black Devices' with type 'Custom' and format 'JSON'. Configure the data source to use a custom script that calls the Carbon Black 'Get Device Info' spoke action to retrieve device health status, OS information, and sensor version details for all managed endpoints. Create a transform map targeting the Computer [cmdb_ci_computer] table, mapping Carbon Black device attributes to CMDB fields such as device policy status to operational_status, last_contact_time to last_discovered, and sensor_version to u_endpoint_agent_version. Schedule the import to run daily during maintenance windows using the Scheduled Script Execution module, implementing incremental updates based on device last_update_time to optimize performance and reduce API calls.
// Custom data source script for Carbon Black device data
var cbDevices = [];
var gr = new GlideRecord('cmdb_ci_computer');
gr.addQuery('install_status', 1); // Only active CIs
gr.query();
while (gr.next()) {
try {
var restMessage = new sn_ws.RESTMessageV2();
restMessage.setEndpoint('https://defense.conferdeploy.net/appservices/v6/orgs/' + gs.getProperty('carbon_black.org_key') + '/devices/' + gr.u_carbon_black_device_id);
restMessage.setHttpMethod('GET');
restMessage.setRequestHeader('X-Auth-Token', gs.getProperty('carbon_black.api_key'));
var response = restMessage.execute();
if (response.getStatusCode() == 200) {
var deviceData = JSON.parse(response.getBody());
cbDevices.push({
sys_id: gr.sys_id.toString(),
operational_status: deviceData.status,
last_discovered: deviceData.last_contact_time
});
}
} catch (e) {
gs.log('Error retrieving Carbon Black device data: ' + e.message, 'CarbonBlackImport');
}
}
return JSON.stringify(cbDevices);Configure alert severity mapping and incident assignment
Navigate to Security Incident Response > Administration > Data Lookup Definitions and create a new lookup table called 'Carbon Black Severity Mapping' with columns for CB_Severity and ServiceNow_Priority, mapping Carbon Black severity levels (1-10) to ServiceNow priority values (1-5). Create assignment rules in Security Incident Response > Administration > Assignment Rules to automatically assign Carbon Black-generated incidents to appropriate security team members based on alert type and severity. Configure the assignment logic to route malware alerts to the malware analysis team, policy violation alerts to compliance teams, and lateral movement alerts to incident response specialists. Implement escalation rules that automatically escalate unassigned critical severity incidents after 15 minutes and high severity incidents after 1 hour to ensure timely response to security events.
// Assignment rule script for Carbon Black incidents
(function process(current) {
var alertType = current.u_carbon_black_alert_type;
var assignmentGroup = '';
switch(alertType) {
case 'MALWARE':
assignmentGroup = 'Malware Analysis Team';
break;
case 'POLICY_VIOLATION':
assignmentGroup = 'Security Compliance';
break;
case 'LATERAL_MOVEMENT':
assignmentGroup = 'Incident Response';
break;
default:
assignmentGroup = 'Security Operations Center';
}
var gr = new GlideRecord('sys_user_group');
if (gr.get('name', assignmentGroup)) {
current.assignment_group = gr.sys_id;
}
})(current);Test integration end-to-end and configure monitoring
Create a test security incident manually with Carbon Black alert details to verify the complete workflow from alert ingestion through quarantine execution and CMDB updates. Navigate to System Logs > Events to verify that Carbon Black API calls are executing successfully and review any authentication or connectivity errors in the Application Logs. Configure monitoring dashboards in Performance Analytics or create custom reports in Security Incident Response to track key metrics such as mean time to quarantine, alert volume trends, and false positive rates. Set up notification rules to alert administrators of integration failures, including API quota exceeded errors, authentication failures, or missing device mappings between Carbon Black and ServiceNow CMDB records. Test the monitoring by temporarily disabling the Carbon Black connection and verifying that appropriate alerts are generated within the expected timeframe.
// Health check script to monitor Carbon Black integration
var healthCheck = {
checkConnectivity: function() {
try {
var restMessage = new sn_ws.RESTMessageV2();
restMessage.setEndpoint('https://defense.conferdeploy.net/appservices/v6/orgs/' + gs.getProperty('carbon_black.org_key') + '/devices?limit=1');
restMessage.setHttpMethod('GET');
restMessage.setRequestHeader('X-Auth-Token', gs.getProperty('carbon_black.api_key'));
var response = restMessage.execute();
return response.getStatusCode() == 200;
} catch (e) {
gs.eventQueue('carbon_black.connection.failed', null, 'Connection test failed: ' + e.message, gs.getUserID());
return false;
}
}
};
if (!healthCheck.checkConnectivity()) {
gs.log('Carbon Black integration health check failed', 'CarbonBlackHealthCheck');
}Common Use Cases
Automated malware incident creation and containment
Carbon Black detects malware execution on an endpoint and generates a high-severity alert that automatically creates a Security Incident in ServiceNow with enriched threat intelligence data. The incident triggers an automated workflow that quarantines the affected device, notifies the security team via email and Slack, and updates the device's CMDB record to reflect its quarantined status. This use case reduces mean time to containment from hours to minutes and ensures consistent response procedures across all malware detections.
Policy violation tracking and compliance reporting
When Carbon Black detects unauthorized software installations or policy violations, the integration automatically creates lower-priority Security Incidents categorized as compliance violations rather than security threats. These incidents are routed to the appropriate compliance team and include detailed policy violation context such as the specific policy rule violated, user context, and recommended remediation steps. The integration maintains audit trails required for compliance frameworks and generates monthly reports showing policy violation trends and resolution times.
Lateral movement detection and investigation workflow
Carbon Black's behavioral analytics detect potential lateral movement activities and create critical-priority Security Incidents that immediately trigger investigation workflows in ServiceNow. The integration automatically enriches these incidents with related device information from the CMDB, creates child incidents for each potentially affected system, and initiates containment procedures including network isolation and credential rotation workflows. Security analysts receive contextual information about affected business services and can coordinate response efforts through ServiceNow's collaboration features.
CMDB health and endpoint visibility management
The integration continuously synchronizes Carbon Black device health data with ServiceNow CMDB records, updating operational status based on sensor connectivity, policy compliance state, and threat detection history. IT operations teams gain visibility into endpoint security posture through CMDB dashboards and can identify devices with outdated sensors, policy violations, or connectivity issues. This use case enables proactive endpoint management and helps maintain accurate asset inventory with security context for risk assessment and compliance reporting.
Threat hunting workflow automation and evidence collection
Security analysts can initiate threat hunting activities through ServiceNow workflows that leverage Carbon Black's Live Response capabilities to collect forensic evidence from suspicious endpoints. The integration creates structured investigation cases with automated evidence collection workflows, file hash lookups, and process tree analysis. Investigation findings are automatically documented in the Security Incident record with proper chain of custody information, and remediation actions can be executed directly through ServiceNow workflows that call Carbon Black APIs for file deletion, registry modification, or system isolation.
Troubleshooting
HTTP 401 Unauthorized when calling Carbon Black APIs
First, verify that the API key stored in the ServiceNow credential record matches exactly with the key generated in Carbon Black console, ensuring no extra spaces or truncation occurred during copy/paste. Check that the organization key is correctly configured as a custom attribute in the credential record and matches your Carbon Black organization. Navigate to System Logs > Outbound HTTP Requests to examine the exact headers being sent and verify the X-Auth-Token format. If the issue persists, regenerate the API key in Carbon Black and update the ServiceNow credential record, as keys may have expired or been revoked.
Carbon Black alerts are creating duplicate Security Incidents
Review the incident creation flow to ensure proper duplicate checking logic using correlation_id fields that map to Carbon Black alert IDs. Navigate to the flow execution history in Process Automation > Executions to identify where the duplicate prevention condition is failing. Check that the GlideRecord query in the duplicate prevention script is using the correct field names and that the correlation_id field exists on the Security Incident table. Implement additional deduplication logic based on alert timestamp and device ID combinations if Carbon Black is generating multiple alerts for the same security event with different alert IDs.
Device quarantine actions fail with 'Device not found' errors
Verify that the device ID stored in ServiceNow CMDB records matches the exact format expected by Carbon Black APIs, as some installations use different device identifier formats (UUID vs integer). Check the Carbon Black console to confirm the device is online and accessible, as offline devices cannot be quarantined remotely. Navigate to System Logs > Application Logs and search for Carbon Black API response details to identify whether the error is due to incorrect device ID format, insufficient API permissions, or device connectivity issues. Update the device ID mapping logic if there's a mismatch between ServiceNow stored identifiers and Carbon Black's expected format.
CMDB enrichment import fails with timeout errors
Review the import script performance by checking execution times in System Import Sets > Import Set History and identify if the script is attempting to process too many devices in a single execution. Implement batching logic to process devices in smaller groups of 50-100 records per execution and add proper error handling with retry mechanisms for individual device API calls. Check Carbon Black API rate limiting by examining response headers for X-RateLimit-Remaining values and implement appropriate delays between API calls. Consider running the import during off-peak hours and increasing the REST message timeout value to 120 seconds for large data retrievals.
IntegrationHub spoke actions fail with 'Connection not found' errors
Navigate to Connections & Credentials > Connection & Credential Aliases and verify that the connection alias name exactly matches the reference used in the spoke action configuration, including case sensitivity and special characters. Test the connection alias independently using the Test Connection button to ensure network connectivity and credential validation are working properly. Check that the Connection URL in the alias points to the correct Carbon Black regional endpoint for your organization, as using the wrong regional URL will cause connection failures. Review the spoke action configuration in Flow Designer to ensure the Connection field is properly mapped to your connection alias and not left blank or pointing to a different connection.
Missing or incomplete alert data in Security Incidents
Examine the Carbon Black API response structure by logging the raw JSON response in the alert retrieval flow to identify field mapping mismatches between the API response and ServiceNow incident fields. Check that the API query parameters in the 'Get Alerts' action are correctly configured to retrieve all required alert details, including threat intelligence data, device information, and alert context. Verify that custom fields created on the Security Incident table have the correct data types and lengths to accommodate Carbon Black data, as truncation can occur with insufficient field sizes. Review the field mapping logic in the incident creation flow to ensure all available alert attributes are properly extracted and mapped to appropriate ServiceNow fields.
Pro Tips
- →Implement exponential backoff retry logic in your Carbon Black API calls using the sn_ws.RESTMessageV2 retry mechanisms to handle temporary network issues and API rate limiting gracefully. Configure retry attempts with increasing delays (1s, 2s, 4s, 8s) and log detailed error information to help diagnose persistent connectivity issues.
- →Create custom Carbon Black alert fields on the Security Incident table to store raw alert JSON data for forensic analysis and debugging purposes. This enables security analysts to access complete alert context even if field mapping doesn't capture all available data, and provides valuable troubleshooting information when investigating integration issues.
- →Use ServiceNow's encrypted property storage for Carbon Black API credentials instead of storing them in plain text custom properties, and implement credential rotation workflows that automatically update API keys before expiration. Set up monitoring to alert administrators 30 days before API key expiration to ensure uninterrupted service.
- →Configure Carbon Black alert polling to use incremental queries based on timestamp ranges rather than retrieving all alerts, and store the last successful poll timestamp in a system property to optimize API usage. Implement circuit breaker patterns that temporarily disable polling if Carbon Black APIs are consistently returning errors to prevent log spam and quota exhaustion.
- →Leverage ServiceNow's Business Rule conditions to implement intelligent alert filtering that reduces noise by suppressing low-value alerts during initial incident creation. Create whitelisting rules for known-good processes and applications based on digital signatures, file paths, and organizational policies to minimize false positives.
- →Implement automated Carbon Black sensor health monitoring by creating scheduled jobs that check device connectivity status and sensor version compliance, automatically creating Change Requests for outdated sensors or opening Incidents for offline devices that haven't communicated within defined SLA timeframes.
Known Limitations
- —Carbon Black Cloud APIs enforce rate limits of 1000 requests per hour per API key, which can impact real-time alert ingestion in large environments with high alert volumes. Consider implementing request queuing and batch processing for environments generating more than 15-20 alerts per minute during peak periods.
- —The IntegrationHub VMware Carbon Black spoke may not support all Carbon Black API endpoints or the latest API version features, potentially requiring custom REST message implementations for advanced functionality like Live Response session management or custom IOC management. Check spoke documentation for supported API version compatibility.
- —Device quarantine operations through the Carbon Black API require devices to be online and connected to the Carbon Black cloud service, with quarantine actions failing for offline devices or those with connectivity issues. Implement retry mechanisms and manual fallback procedures for critical devices that cannot be automatically quarantined.
- —CMDB enrichment with Carbon Black device data can introduce performance impacts if not properly optimized, as the integration may need to make individual API calls for each managed device. Large environments with thousands of endpoints should implement incremental updates and consider MID Server deployment for improved performance.
- —The integration depends on consistent device identification between Carbon Black and ServiceNow CMDB records, which can be challenging in environments with dynamic device provisioning, hostname changes, or multiple endpoint management tools. Implement robust device matching logic using multiple identifiers like MAC addresses, serial numbers, and IP addresses.
Frequently Asked Questions
Can the Carbon Black integration work with on-premises Carbon Black Response installations?
Yes, the integration supports on-premises Carbon Black Response through MID Server deployment, but requires additional configuration for API endpoint URLs and certificate management. You'll need to configure the Connection Alias to point to your on-premises Carbon Black server and ensure the MID Server has network connectivity to both your Carbon Black installation and the ServiceNow instance. The spoke actions may need customization as the API endpoints and authentication methods can differ between Carbon Black Cloud and on-premises Response installations. Consider consulting VMware documentation for specific API compatibility between versions.
How can I customize the alert severity mapping between Carbon Black and ServiceNow incidents?
Create a Data Lookup Definition in Security Incident Response to map Carbon Black severity values to ServiceNow priority and impact values based on your organizational requirements. You can implement custom business rules or modify the incident creation flow to apply additional logic based on alert type, affected device criticality, or business hours. The mapping can consider factors like device location, user role, and business service impact to dynamically adjust incident priority. Use the Transform Maps functionality if you're importing alerts through Import Sets to apply complex mapping rules during data transformation.
What happens if Carbon Black quarantine actions fail due to device connectivity issues?
Failed quarantine actions are logged in the System Event Log and can trigger automated notifications to security teams for manual follow-up procedures. Implement retry logic in your quarantine workflows that attempt the operation multiple times over several hours to account for temporary connectivity issues. Create escalation procedures that automatically generate Change Requests for network-level isolation if Carbon Black quarantine fails repeatedly. You can also integrate with other security tools like firewalls or NAC solutions to provide alternative containment methods when Carbon Black quarantine is unavailable.
How do I handle Carbon Black API rate limiting in high-volume environments?
Implement request queuing using ServiceNow's Queue Management features to distribute API calls evenly across time periods and avoid exceeding rate limits. Configure your alert polling intervals based on your typical alert volume, using more frequent polling during business hours and reduced polling during off-peak times. Use batch processing techniques to retrieve multiple alerts per API call when possible, and implement exponential backoff with jitter for retry attempts. Consider requesting increased API rate limits from VMware for enterprise deployments with consistently high alert volumes that exceed standard quotas.
Can I integrate Carbon Black threat intelligence data with ServiceNow Threat Intelligence applications?
Yes, Carbon Black threat intelligence can be integrated with ServiceNow's Threat Intelligence application by extracting IOCs, file hashes, and threat attribution data from Carbon Black alerts and creating corresponding threat intelligence records. Use the threat intelligence APIs to enrich Security Incidents with contextual information about known threat actors, malware families, and attack techniques. The integration can automatically create STIX/TAXII formatted threat intelligence records and associate them with related security incidents for comprehensive threat tracking. Configure automated workflows to share threat intelligence bidirectionally between Carbon Black and other security tools integrated with ServiceNow.
How do I ensure CMDB data consistency when multiple security tools are updating device records?
Implement data precedence rules using ServiceNow's Identification and Reconciliation Engine (IRE) to establish which data sources have authority over specific CMDB fields and resolve conflicts automatically. Create custom business rules that timestamp and track the source of each CMDB update to maintain audit trails and enable data quality analysis. Use the CMDB Health Dashboard to monitor data conflicts and inconsistencies between Carbon Black and other endpoint management tools. Configure discovery schedules to ensure Carbon Black updates don't conflict with other automated discovery processes, and implement field-level locking for critical attributes that should only be updated by specific authoritative sources.
What permissions are required for the ServiceNow integration user in Carbon Black?
The Carbon Black API user requires Custom access level permissions including org.alerts.read for alert retrieval, device.read for device information queries, device.quarantine for containment actions, and org.search for advanced threat hunting capabilities. Create a dedicated service account in Carbon Black specifically for ServiceNow integration rather than using personal user accounts to ensure consistent access and proper audit trails. The permissions should be regularly reviewed and aligned with the principle of least privilege, granting only the minimum access required for your specific integration use cases. Document the required permissions in your integration runbook and implement monitoring to detect permission changes that could impact integration functionality.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue