Data Flow Diagrams

This section describes Carbon Black Hosted EDR and Carbon Black EDR data flows.

The following diagram illustrates the Carbon Black Hosted EDR data flow:

The following diagram illustrates the Carbon Black EDR data flow:

As soon as a sensor is installed, it begins buffering activity to report to the cloud service. This includes:

• Currently running processes that create events

• Binary executions

• File executions and modifications

• Network connections

• Registry modifications

• Cross-process events (events that cross the security boundaries of other processes)

• PowerShell fileless scriptload events

Every few minutes, sensors check in with the cloud service to report what they have buffered, even if they are reporting that they have nothing buffered. When a sensor checks in, the cloud service responds, letting the sensor know when to send the data and how much data to send.

As the cloud service records data from sensors, the data is compared with the latest synchronization from any enabled Carbon Black Threat Intel feed partner. In most cases, incremental synchronizations occur hourly. Full synchronizations occur once every 24 hours by default.

Some Carbon Black Threat Intel feeds provide a list of all of the IOCs they track. Some feeds only include reports on files (identified through their MD5 or SHA-256 hashes) that are observed in your enterprise.

If you enable data sharing with the Carbon Black Threat Intel partners, Carbon Black EDR pushes MD5 hashes that are observed by sensors and binaries originating from your enterprise to their cloud services. If there is a corresponding report or record, the feed is updated to include that information. If there is no corresponding third party-report, one is requested and when available, included in the feed.

When information about a specific binary is included in these feeds, the information remains there, even if the binary it is associated with is deleted from your endpoints and is no longer present in your environment.

The following table provides key additional information about data flows:

Data Flow	Description
Sensor to Server	All communications are through HTTPS. The TCP port is 443 by default, but is configurable. Communications are always initiated from sensor to server (never from server to sensor). By default, communications are mutually authenticated by statically pinned TLS certificates, both client and server. There is also an option to substitute user-provided certificates and use stricter validation. Sensors have the server’s certificate embedded, and the server has all client certificates embedded. See See Managing Certificates for more information. All communications require a minimum of TLSv1+; only allow FIPS-compliant ciphers and use a 2048-bit Diffie Hellman key. Sensor communication through a proxy is unsupported, unless the proxy is deployed in a transparent, in-line configuration. Sensor communication is supported through transparent proxies. Due to certificate pinning, communication is not supported through traffic inspection proxies, or any other device that would affect SSL certificates. The Windows sensor honors settings that are configured via a proxy.pac file. (This does not change the requirement that any proxy that is used must not modify SSL certificates or otherwise attempt to bypass the secure communications between sensor and server.) Sensor communication through an TLS intercept/decryption device is not currently supported, even for in-line proxy configurations. The server’s sensor-facing interface can be configured in a DMZ to support endpoints outside the corporate LAN
Server to Alliance Server and Carbon Black Threat Intel	All communications are explicitly opt-in. All communications are HTTPS. This connection is required for threat intelligence that is provided by Carbon Black EDR. TCP is 443 to api.alliance.carbonblack.com and threatintel.bit9.com. Proxies are supported.
Server to yum Repository	TCP is 443 for HTTPS to yum.distro.carbonblack.io. TCP is 80 to a CentOS or RHEL.