FAQs

This FAQ section covers common questions and answers to Carbon Black EDR deployments.

1. What endpoint operating systems do Carbon Black EDR sensors support?

   For the current list of supported operating systems for Carbon Black EDR sensors, see Sensor Operating Environment Requirements at Carbon Black EDR Documentation. Distributions that are not specified in this document, or modified versions of those distribution environments, are not supported.

2. What Carbon Black EDR console/server operating systems are supported?

   For version-specific information, see the release notes for the version of Carbon Black EDR server you are running. For a comprehensive list of supported server operating systems, see Server Versions and Operating Systems.

   Note: Carbon Black discourages pinning dependencies as per the recommendation from CentOS/RHEL.

   Installation and testing are performed on default installations using the minimal distribution and the distribution’s official package repositories. Customized Linux installations must be individually evaluated and are ineligible for support.

3. What processors are supported?

   Carbon Black EDR supports Intel or AMD x86 processors. Carbon Black EDR does not support ARM processors.

4. Is there any difference in CPU core count if vCPUs are used?

   CPU Cores refers to CPU threads. You can allocate 1 vCPU = 1 physical CPU core.

5. What is the sensor impact on the endpoint?

   The Carbon Black EDR sensor is designed to have no performance impact. Endpoint activity levels might impact actual values. Typical ranges for the impact of the Carbon Black EDR sensor are as follows:

   • CPU – < 5% CPU usage, depending on system activity
   • Memory – 12-50 MB RAM
   • Disk Storage – The sensor regularly sends data to the server, requiring minimal storage on the endpoint (500 KB to 3 MB). If the sensor cannot communicate with the server, data queues up to an adjustable threshold (2 GB by default, expected 30-60 days activity on a normal system). The data is synced when server communications are reestablished.
6. Can I use a spinning disk if my deployment size or retention needs are small?

   For installations that have less than 1 TB of data, you can reduce the recommended disk configuration to four SSDs, or use 6 Gb/s SAS 15K RPM spinning drives.

7. How much network bandwidth does Carbon Black EDR require?

   It is difficult to predict the actual network traffic that Carbon Black EDR requires. Network bandwidth depends on many factors, including sensor activity and the number of unique binary files that are uploaded to the server. Apply the following estimates:

   • Per endpoint:
     • 1-4 kilobits per second (kbps) per host
     • 10-40 megabytes (MB) per host per day
   • The following table shows server-side expected average network traffic based on sensor activity estimates (not including network usage for uploading unique binaries to the server):

     Table 1. Average expected server network incoming traffic in MB/s for event data

     Activity Estimate/Sensors Per Server	Low Activity Estimate	Medium Activity Estimate	High Activity Estimate
     1,000	0.12 MB/s	0.24 MB/s	0.5 MB/s
     3,125	0.4 MB/s	0.75 MB/s	1.5 MB/s
     6,250	0.75 MB/s	1.5 MB/s	3 MB/s
     18,750	2.25 MB/s	4.5 MB/s	9 MB/s

   • You can configure throttling per site by using sensor groups, per hour, per day.
     • Throttling limits bandwidth from a group of sensors. Throttling is often used on low-bandwidth sites or sites that are bandwidth-constrained at certain times of day.
       • The trade-off when throttling is invoked is a delay in data sent back to the central server for analysis against watchlists, and the availability of the data in the console.
       • Console users can override the network throttle by enabling sync to any individual host. This override instructs the host to ignore any configured throttles and immediately send all data.
     • Throttles shape the volume of traffic to the server from sensors at particular times. They do not reduce overall traffic. To reduce traffic, you can limited the collection of certain type of events per-process on a per-sensor-group basis. For more information about sensor groups and event collection options, see the Carbon Black EDR User Guide.
   • Maximum sensor check-in rate can be configured through SensorCheckingDelayRate in cb.conf. For more information, see Carbon Black EDR Server Configuration Guide.
     • The default value is 100, which corresponds to a maximum 100 check-ins/second/server node. Reducing this value reduces check-in network traffic, but also reduces how often sensors send statistics and retrieve configuration changes.
   Note: Due to the number of processes that are generated on those endpoints, macOS and Linux sensors can drive higher bandwidth utilization.
8. I have remote locations and/or users who travel. How does Carbon Black EDR work for those users? Do I need to consider the impact on server sizing and configuration?
   • If endpoints at remote locations (for example, outside the organization’s network) can reach the Carbon Black EDR server, all operations are identical to when the endpoint is in the network.
   • When they are not connected to the server, Carbon Black EDR sensors queue data on the endpoint (up to a configurable threshold) until the server is reconnected.
     • Default storage on the endpoint is 2 GB or 2% of total disk storage (whichever is reached first). This should be sufficient for multiple months of data. The default is configurable by sensor group.
     • After the local data storage limit is reached, the sensor stops storing new log messages.
   • The Carbon Black EDR server can be deployed in the DMZ or directly on the Internet.
   • For installations in a DMZ or with direct Internet access, it is best practice to configure Carbon Black EDR to restrict access to the management interface (the console) to a separate, internal network interface.
   • This behavior does not impact server sizing.
9. What is the impact if I do not have sufficient server resources?

   If there are insufficient resources, the server will throttle the sensors in their sending of data. If the CPU, RAM, or storage resources or performance are insufficient for the stored process documents, the search performance of Carbon Black EDR is impacted and the environment will be ineligible for support until the environment is brought into alignment with the resource requirements that are outlined in this document.

   If the server throttles sensor uploads (or an external throttle, such as network level QoS or traffic shaping is implemented), the data queues up at the endpoints until one of two things occurs: the server can handle the load, or the sensors meet the local threshold for how much data to queue. Endpoints continue to operate without any noticeable performance impact.

10. Is there a way to avoid storing data for high volume processes?

    You can deploy event filters on the server to limit particularly noisy processes. This mechanism should only be used in extreme cases where a large amount of process activity can be attributed to a few processes. We recommend that you engage with Professional Services to enable event filtering.

    You can reduce the data that is recorded per-process on a per-sensor-group basis. In the sensor group’s configuration page, one can limit the collection of the following:

    • Process information
    • File modifications
    • Registry modifications
    • Binary module (.dll, .sys, .exe) loads
    • Network connections
    • Binaries
    • Binary info
    • Process user context
    • Non-binary file writes
    • Cross process events

    Eliminating these events reduces data volumes, but at a loss of forensic visibility. In a typical enterprise, the most frequent events are file modifications, registry modifications, and binary module loads. The performance impact of disabling specific event types is highly variable and depends on the endpoint environment. Engage with Sales Engineering or Professional Services to determine the best approach.

11. What are the concerns if I want to store more than the recommended number of days’ worth of data?

    Days stored increase the required data storage and can impact the number of servers that are required to process the stored data. A performance degradation occurs when the number of stored process documents exceeds the recommended number of days stored. Use the Sizing Estimator together with Sales Engineering or Professional Services for tailored guidance. Forwarding select or all events to a separate SIEM solution for longer retention is a recommended best practice.

12. Are virtual servers supported?

    Yes. See Virtual Server Deployments

13. Do sensors support VDI environments?

    Yes. Sensors running on a Virtual Desktop Infrastructure (VDI) are supported for both persistent and non-persistent VDI setups. To maintain continuity through non-persistent sessions, Carbon Black EDR has developed logic in the sensor to make sure that the VDI session maintains the sensor ID. This persistence ensures that each sensor is depicted one time only in the console. For VDI, Carbon Black EDR limits the disk writes for both persistent and non-persistent sessions to optimize for zero or thin sessions. See the Carbon Black EDR Integration Guide.

14. How does Carbon Black EDR support disaster recovery (DR), high availability (HA) and backups?
    • Carbon Black EDR relies on existing system administration procedures for backup and recovery. See the Carbon Black EDR Server Cluster Management Guide.
      • Best practices when using virtual infrastructure include taking snapshots and backing up using your enterprise’s IT management procedures.
      • Best practices on physical hardware use RAID to help against hard drive failures; maintain cold spares.
    • Typical Linux tools can (and should) be used to make backups of your certificates, configuration database, and settings to assist in DR and HA.
    • Sensors store data locally (if they cannot connect to the server) and transmit the data when the connection is re-established. In the Carbon Black EDR console, you can configure the data that is stored on the endpoint.
    • For backup, send critical Carbon Black EDR events to SIEMs as a best practice.
    • You can backup and archive the Carbon Black EDR event data, but this requires custom scripting and can be large.
15. Can agent-based software (antivirus, performance monitoring, backup utilities) be installed on a Carbon Black EDR server?

    Yes — configure agent-based software according to Carbon Black and industry best practices.