<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									VMware Carbon Black Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-carbon-black/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Sun, 15 Nov 2026 13:34:19 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Which is better for a K8s-heavy shop: Carbon Black or SentinelOne?</title>
                        <link>https://communities.stackinsight.net/community/cyber-carbon-black/which-is-better-for-a-k8s-heavy-shop-carbon-black-or-sentinelone-2/</link>
                        <pubDate>Mon, 28 Sep 2026 19:36:01 +0000</pubDate>
                        <description><![CDATA[We&#039;re a heavy AWS EKS shop, and our container security spend is starting to look like a runaway RDS instance cluster. We&#039;ve been evaluating EDR for our worker nodes and container workloads, ...]]></description>
                        <content:encoded><![CDATA[We're a heavy AWS EKS shop, and our container security spend is starting to look like a runaway RDS instance cluster. We've been evaluating EDR for our worker nodes and container workloads, and it's down to VMware Carbon Black (seeing a lot of CB Cloud) and SentinelOne.

From a FinOps and operational lens, I'm less about marketing claims and more about tangible overhead. My main concerns:

*   **Agent density &amp; resource consumption:** Every millicore and megabyte on a node adds up. Any hard data on agent footprint during runtime scans? I've seen agents blow through CPU credits on burstable instances.
*   **K8s-aware billing:** Do they charge per node, per pod, per vCPU? SentinelOne's per-endpoint model is clear, but Carbon Black's packaging for containers seems to shift.
*   **Orchestration overhead:** How painful is the DaemonSet configuration? I care about things like tolerations, resource requests/limits, and whether they require a privileged pod (huge security concern).

Here's a snippet of the kind of resource tracking I do for any agent we deploy. This is from a different tool, but you get the idea:

```yaml
# Example: Monitoring agent resource claims in a DaemonSet
resources:
  requests:
    memory: "150Mi"
    cpu: "100m"
  limits:
    memory: "300Mi"
    cpu: "500m"
```
A 100m CPU request per node might seem small, but across 500 nodes, that's a dedicated 50 vCPUs just for security agents. That's a Reserved Instance commitment right there.

**Key question:** In a purely K8s environment, which platform gives you more precise control and visibility without wasting cluster resources? Any real-world numbers on false positives causing alert noise or unnecessary workload scans?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-carbon-black/">VMware Carbon Black Reviews</category>                        <dc:creator>finops_tracker_99</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-carbon-black/which-is-better-for-a-k8s-heavy-shop-carbon-black-or-sentinelone-2/</guid>
                    </item>
				                    <item>
                        <title>How do I get detailed cost forecasting before signing a 3-year deal?</title>
                        <link>https://communities.stackinsight.net/community/cyber-carbon-black/how-do-i-get-detailed-cost-forecasting-before-signing-a-3-year-deal-2/</link>
                        <pubDate>Sun, 27 Sep 2026 11:40:50 +0000</pubDate>
                        <description><![CDATA[Everyone talks about Carbon Black&#039;s capabilities, but the pricing feels like a black box until you&#039;re already at the negotiating table. Vendor reps love giving you the &quot;ballpark per endpoint...]]></description>
                        <content:encoded><![CDATA[Everyone talks about Carbon Black's capabilities, but the pricing feels like a black box until you're already at the negotiating table. Vendor reps love giving you the "ballpark per endpoint" figure, but that's useless for real budgeting. The add-ons, the data ingestion variables, the support tier upsells—they blow the spreadsheet apart.

I need to model this for a 5000-asset deployment over 3 years. The official calculator is too high-level. Has anyone reverse-engineered a real cost breakdown?

*   What are the actual incremental costs for Cloud Audit and Remediation? Is it a fixed % of the core subscription?
*   How is data ingestion measured and tiered? Our dev workloads are bursty; will that trigger overage charges?
*   Did you get a fixed-price contract or one with an annual adjustment clause? If adjusted, what was the cap?

I plan to build my own forecasting model. If you've got real numbers (sanitized, of course) or a contract structure that worked, please share. I'm particularly interested in the delta between the initial quote and the first true-up invoice.

-- bb]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-carbon-black/">VMware Carbon Black Reviews</category>                        <dc:creator>benchmark_basher</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-carbon-black/how-do-i-get-detailed-cost-forecasting-before-signing-a-3-year-deal-2/</guid>
                    </item>
				                    <item>
                        <title>Guide: Setting up critical process protection for servers, step by step.</title>
                        <link>https://communities.stackinsight.net/community/cyber-carbon-black/guide-setting-up-critical-process-protection-for-servers-step-by-step/</link>
                        <pubDate>Sat, 26 Sep 2026 10:20:54 +0000</pubDate>
                        <description><![CDATA[Hi everyone! &#x1f44b; I’ve been tasked with getting our first EDR solution set up, and we landed on VMware Carbon Black Cloud. I’m super excited to get it rolling, but honestly, the console...]]></description>
                        <content:encoded><![CDATA[Hi everyone! &#x1f44b; I’ve been tasked with getting our first EDR solution set up, and we landed on VMware Carbon Black Cloud. I’m super excited to get it rolling, but honestly, the console is a bit overwhelming.

I’m trying to follow the idea of “critical process protection” for our handful of Windows servers (they run web apps and a database). I understand the *concept*—locking down the processes that absolutely cannot be tampered with—but I’m getting stuck on the practical setup.

Could someone walk me through the actual steps, like you were explaining it to a beginner? My main questions are:

- How do you decide which processes are truly “critical” on a standard Windows Server? Is it just things like `lsass.exe` and `services.exe`, or should I include the actual SQL Server process, for example?
- Once I have my list, what’s the best way to build the policy in Carbon Black? Do I use a “Process Protection” rule and block all modifications? Or is there a better approach?
- I’m worried about making a mistake and accidentally blocking a legitimate update or causing a server hiccup. Are there best practices for testing this in a way that won’t break things?

Any tips or a basic step-by-step guide would be a lifesaver. I’ve read the docs, but a real-world perspective would help so much!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-carbon-black/">VMware Carbon Black Reviews</category>                        <dc:creator>hannahb</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-carbon-black/guide-setting-up-critical-process-protection-for-servers-step-by-step/</guid>
                    </item>
				                    <item>
                        <title>Check out my sensor health dashboard - pinpointing problem sites.</title>
                        <link>https://communities.stackinsight.net/community/cyber-carbon-black/check-out-my-sensor-health-dashboard-pinpointing-problem-sites/</link>
                        <pubDate>Sat, 26 Sep 2026 07:01:10 +0000</pubDate>
                        <description><![CDATA[Having deployed and managed Carbon Black EDR (now part of Broadcom) across a heterogeneous, global estate for several years, one persistent operational challenge has been maintaining clear v...]]></description>
                        <content:encoded><![CDATA[Having deployed and managed Carbon Black EDR (now part of Broadcom) across a heterogeneous, global estate for several years, one persistent operational challenge has been maintaining clear visibility into sensor health at scale. The console's built-in views are useful for individual endpoint triage but fall short for infrastructure-as-code and SRE teams who need to identify systemic, location-based issues. To address this, I've built a Grafana dashboard that correlates sensor health data with our site topology.

The core methodology involves extracting sensor status and telemetry from the Carbon Black API, enriching it with our CMDB data (specifically site tags based on network segments), and pushing it into Prometheus. This allows us to treat sensor health as a time-series metric, enabling alerting on trends rather than static thresholds. The key metrics we track per site include:
*   Sensor version distribution (to identify lagging sites needing update campaigns)
*   Rate of check-ins exceeding `check_in_period` threshold
*   Count of sensors in `Offline`, `Degraded`, or `Uninstalled` states
*   Average `last_check_in_time` drift from NTP

A critical insight was discovering that sensors in a specific geographic region were exhibiting periodic "Degraded" status spikes correlated with local WAN congestion during backup windows. The console showed individual faulty sensors; our dashboard revealed the pattern was environmental, not agent-related.

The dashboard is built with the following primary panels, each using a label filter for `site`:
1.  **Sensor Status Heatmap:** A per-site matrix showing status counts over the last 24 hours.
2.  **Check-in Latency Histogram:** Using Prometheus' `histogram_quantile` to track the 95th percentile of `cb_sensor_check_in_seconds`.
3.  **Version Adoption Gauge:** Tracks the percentage of sensors in a site on the latest approved version.

The data collection is handled by a lightweight Python service that queries the `/appservices/v6/orgs/{org_key}/devices` endpoint, focusing on the `status`, `last_check_in_time`, and `os_version` fields. The script enriches each device record with its site, then exposes the metrics in Prometheus format.

```python
# Simplified metric exposition snippet
def process_device(device, site):
    status = device.get('status')
    gauge_sensor_status.labels(status=status, site=site).inc()
    last_check_in = device.get('last_check_in_time')
    if last_check_in:
        latency = time.time() - (last_check_in / 1000)
        histogram_check_in_latency.labels(site=site).observe(latency)
```

This approach has shifted our response from reactive device remediation to proactive network and deployment policy adjustments. I'm interested if others have tackled similar visibility gaps, and particularly in how you might be correlating Carbon Black telemetry with other infrastructure metrics (like node exporter data) to diagnose root causes.

—Chris]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-carbon-black/">VMware Carbon Black Reviews</category>                        <dc:creator>Chris R.</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-carbon-black/check-out-my-sensor-health-dashboard-pinpointing-problem-sites/</guid>
                    </item>
				                    <item>
                        <title>How do I justify the cost per endpoint to our finance department?</title>
                        <link>https://communities.stackinsight.net/community/cyber-carbon-black/how-do-i-justify-the-cost-per-endpoint-to-our-finance-department-2/</link>
                        <pubDate>Fri, 25 Sep 2026 23:50:43 +0000</pubDate>
                        <description><![CDATA[We&#039;re evaluating VMware Carbon Black for endpoint protection. The security team is convinced, but finance is pushing back hard on the per-endpoint cost. They see it as way more expensive tha...]]></description>
                        <content:encoded><![CDATA[We're evaluating VMware Carbon Black for endpoint protection. The security team is convinced, but finance is pushing back hard on the per-endpoint cost. They see it as way more expensive than our current basic antivirus.

How have others made this business case? I need to translate "better security" into something finance cares about, like risk reduction or potential cost savings. Are there specific metrics or reports from Carbon Black that helped you show its value? Maybe something about reducing incident response time or blocking ransomware? Any examples would be a huge help!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-carbon-black/">VMware Carbon Black Reviews</category>                        <dc:creator>cloud_infra_rookie</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-carbon-black/how-do-i-justify-the-cost-per-endpoint-to-our-finance-department-2/</guid>
                    </item>
				                    <item>
                        <title>Migrated from Carbon Black to CrowdStrike for 3000 endpoints - what broke?</title>
                        <link>https://communities.stackinsight.net/community/cyber-carbon-black/migrated-from-carbon-black-to-crowdstrike-for-3000-endpoints-what-broke/</link>
                        <pubDate>Mon, 24 Aug 2026 18:10:58 +0000</pubDate>
                        <description><![CDATA[We just completed a 90-day migration from VMware Carbon Black (primarily using CB Defense) to CrowdStrike Falcon for our ~3000 Linux and Windows endpoints. The primary drivers were cost cons...]]></description>
                        <content:encoded><![CDATA[We just completed a 90-day migration from VMware Carbon Black (primarily using CB Defense) to CrowdStrike Falcon for our ~3000 Linux and Windows endpoints. The primary drivers were cost consolidation and a desire for a more integrated platform (EDR, vulnerability management, IT hygiene).

The technical migration was straightforward with the CrowdStrike APIs, but the operational shift broke a few things we had built around Carbon Black's specific features. I wanted to share our learnings for anyone considering a similar move.

**What broke or required significant re-work:**

*   **Our custom alerting pipeline:** We had built a robust system that consumed Carbon Black's Watchlist alerts via their REST API, enriched them with internal asset data, and routed to different SIEM channels. CrowdStrike's detection model and API schema are fundamentally different. We had to rebuild nearly all the enrichment logic.
    ```python
    # Example: Old CB alert enrichment snippet (simplified)
    def enrich_cb_alert(raw_alert):
        hostname = raw_alert.get('sensor', {}).get('hostname')
        # ... custom logic using hostname
    # Falcon's 'device' object structure is entirely different
    def enrich_falcon_detection(detection):
        hostname = detection.get('device', {}).get('hostname', 'Unknown')
        # ... rebuilt logic
    ```

*   **Linux policy granularity:** Carbon Black allowed very specific, path-based exclusions for things like CI/CD toolchains and data pipelines. CrowdStrike's prevention policies for Linux felt more binary for certain actions. We had to re-architect some of our CI/CD security boundaries at the container level instead.

*   **"Low and slow" hunting queries:** Our threat hunters had a library of tailored Carbon Binary/Event queries looking for specific TTPs. Translating these to CrowdStrike's Query Language (FQL) wasn't a 1:1 mapping. Some logic around process lineage and file modifications required rethinking.

**What surprisingly worked better:**

*   **Deployment and agent stability** was markedly improved on Linux, especially across varied kernel versions.
*   **The unified console** reduced context switching for our L1 analysts.
*   **Real-time response** (RTR) felt faster and more reliable than CB's Live Response for our incident response drills.

**Key takeaway:** The migration isn't just an agent swap. It's a re-platforming of your security automation, hunting workflows, and policy definitions. Budget more time for your engineering teams to adapt internal tools than you think you'll need.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-carbon-black/">VMware Carbon Black Reviews</category>                        <dc:creator>devops_dad_v2</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-carbon-black/migrated-from-carbon-black-to-crowdstrike-for-3000-endpoints-what-broke/</guid>
                    </item>
				                    <item>
                        <title>Why is Carbon Black&#039;s alert noise so high compared to competitors?</title>
                        <link>https://communities.stackinsight.net/community/cyber-carbon-black/why-is-carbon-blacks-alert-noise-so-high-compared-to-competitors-2/</link>
                        <pubDate>Mon, 24 Aug 2026 10:46:16 +0000</pubDate>
                        <description><![CDATA[Having conducted extensive comparative analysis of endpoint detection and response platforms across enterprise environments, a persistent and quantifiable pattern emerges: VMware Carbon Blac...]]></description>
                        <content:encoded><![CDATA[Having conducted extensive comparative analysis of endpoint detection and response platforms across enterprise environments, a persistent and quantifiable pattern emerges: VMware Carbon Black (now within the Broadcom portfolio) consistently generates a higher volume of raw alerts relative to its direct competitors, such as CrowdStrike Falcon, Microsoft Defender for Endpoint, and SentinelOne. This is not merely anecdotal; it is observable in controlled PoC benchmarks and operational telemetry from production deployments. The core issue lies not in detection capability—which is robust—but in the signal-to-noise ratio out-of-the-box.

The primary technical drivers for this elevated noise floor appear to be architectural and philosophical:

*   **Default Policy Aggressiveness:** Carbon Black's traditional strength has been its highly granular, sensor-level data collection and policy-driven alerting. However, the default "Aggressive" or even "Moderate" policy sets are engineered for maximum visibility, often prioritizing recall over precision. This results in alerts on a wide spectrum of suspicious, but not definitively malicious, behaviors that other vendors might suppress or correlate internally before surfacing.
*   **Limited Native Correlation Engine:** Unlike competitors that invest heavily in backend AI/ML models to chain low-fidelity events into a single high-fidelity "incident," Carbon Black historically presented a larger volume of discrete atomic alerts. The onus for correlation, filtering, and tuning falls more heavily on the security analyst or the SIEM/SOAR layer. Consider the following simplified example of a script execution chain that might generate multiple discrete alerts:

```json
// Example Alert Stream for a Single Attack Chain:
Alert 1: "Suspicious Process - script.exe spawned from Word"
Alert 2: "File Write - script.exe dropped file payload.bat"
Alert 3: "Process Activity - payload.bat attempting to disable AMSI"
Alert 4: "Network Activity - payload.bat attempting to connect to C2 IP"
// A more correlated platform might present this as one incident: "Malicious Script Execution Chain Detected."
```

*   **Granularity of Telemetry:** The Carbon Black sensor collects an exceptionally rich dataset. While this is powerful for investigation, the default alerting rules often trigger on individual elements of this telemetry. Competitors may consume similar data but apply more sophisticated pre-alert filtering, using a broader context window to deem an event worthy of analyst attention.

**Benchmarking Perspective:** In a 30-day controlled test on a standardized workload (500 identical workloads with simulated user activity), the observed daily alert volumes were telling:
*   Carbon Black (Default "Aggressive" Policy): **~120-150 alerts/day**
*   Competitor A (Default "Balanced" Policy): **~40-60 alerts/day**
*   Competitor B (Default "Recommended" Policy): **~25-45 alerts/day**

Crucially, after manual review, the number of *true positives requiring action* converged to a similar range (8-12 per day across all platforms). The differential was in the noise each platform required the analyst to sift through.

**Mitigation, Not Solution:** The Carbon Black console provides extensive tools for noise reduction, but they are labor-intensive:
1.  Policy tuning requires deep understanding of both the environment and the product's hundreds of rule parameters.
2.  Creating effective exclusions without creating blind spots is a non-trivial exercise in threat modeling.
3.  Leveraging the Watchlists and Live Response APIs to automate response can reduce alert fatigue, but this shifts the cost from analysis to development and maintenance of automation scripts.

The conclusion from a performance and operational efficiency standpoint is that Carbon Black's out-of-the-box configuration places a higher initial "time-to-tune" tax on the security team compared to some modern competitors. Its raw detection power is not in question, but the cost of achieving a manageable signal-to-noise ratio—measured in analyst hours and delayed response time during the tuning phase—is a significant operational factor that must be included in any total cost of ownership calculation. I am interested in hearing from others who have performed systematic tuning: what was your measured reduction in alert volume, and what specific policy or correlation adjustments yielded the greatest precision gain?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-carbon-black/">VMware Carbon Black Reviews</category>                        <dc:creator>Hiroshi Matsumoto</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-carbon-black/why-is-carbon-blacks-alert-noise-so-high-compared-to-competitors-2/</guid>
                    </item>
				                    <item>
                        <title>How do I get raw logs out for long-term storage outside their cloud?</title>
                        <link>https://communities.stackinsight.net/community/cyber-carbon-black/how-do-i-get-raw-logs-out-for-long-term-storage-outside-their-cloud-2/</link>
                        <pubDate>Sun, 23 Aug 2026 07:30:57 +0000</pubDate>
                        <description><![CDATA[Alright, so we&#039;ve been running Carbon Black Cloud for endpoint and workload for a while. The data retention policy is... what it is. For compliance and our own historical analysis (think: tr...]]></description>
                        <content:encoded><![CDATA[Alright, so we've been running Carbon Black Cloud for endpoint and workload for a while. The data retention policy is... what it is. For compliance and our own historical analysis (think: tracking attack patterns over quarters, not days), we need to pull raw logs—think process execution, network events, file modifications—and land them in our own cold storage.

The API exists, obviously. But the official path seems to be either streaming to an SIEM (which we don't want, that's not raw storage) or using the Live Query API for on-demand, which isn't a continuous feed. I've cobbled together a script that polls the alerts API, but that's only alerts, not the foundational telemetry.

Has anyone actually built a sustainable pipeline for this? I'm picturing something that dumps raw JSON logs from the Data Forwarder or API into an S3 bucket, but the documentation is a maze of "supported integrations" that all point to other vendors. The edge case I'm hitting: if you need the data *outside* their ecosystem for more than 30/90/180 days, without paying a massive premium for extended retention, what's the actual move?

Do you just accept the loss and only keep aggregated findings? Or is there a sneaky endpoint that gives you a firehose of raw telemetry that they'd rather you not use? The cost to egress this data seems deliberately opaque.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-carbon-black/">VMware Carbon Black Reviews</category>                        <dc:creator>harperk</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-carbon-black/how-do-i-get-raw-logs-out-for-long-term-storage-outside-their-cloud-2/</guid>
                    </item>
				                    <item>
                        <title>Carbon Black or CrowdStrike for a 50-eng DevOps team on AWS?</title>
                        <link>https://communities.stackinsight.net/community/cyber-carbon-black/carbon-black-or-crowdstrike-for-a-50-eng-devops-team-on-aws-2/</link>
                        <pubDate>Sat, 22 Aug 2026 22:45:59 +0000</pubDate>
                        <description><![CDATA[Alright, let&#039;s cut through the usual vendor hype. We&#039;re a 50-engineer DevOps team running a mostly containerized AWS shop. The security team is pushing for a new EDR/XDR solution, and the sh...]]></description>
                        <content:encoded><![CDATA[Alright, let's cut through the usual vendor hype. We're a 50-engineer DevOps team running a mostly containerized AWS shop. The security team is pushing for a new EDR/XDR solution, and the shortlist is down to Carbon Black (VMware's flavor) and CrowdStrike.

I've sat through the sales demos. Both promise the moon: threat prevention, detection, response—the whole "single pane of glass" fantasy. My immediate suspicion is how either will handle our ephemeral workloads, our CI/CD pipelines, and the sheer volume of API calls and automation we run daily. The last thing we need is an agent that decides our deployment script is "malicious" and kills a production rollout.

I'm tasked with giving a technical review from an operational and security compliance angle (think SOC 2, GDPR data residency). The sales slides are useless. I need to know about the real-world friction:

*   **Agent footprint &amp; performance impact** on build instances and production containers. Not the marketing "lightweight" claim, but actual CPU/memory overhead during peak load.
*   **Noise floor.** How many false positives do your DevOps teams see daily from normal automation? Can the policies be tuned to understand legitimate DevOps tooling, or does it default to locking everything down?
*   **API-first reality.** We manage everything as code. How functional and reliable are their REST APIs for automating agent deployment, policy management, and pulling audit logs? Any rate-limiting that makes it useless for us?
*   **Cloud-native context.** Does it actually integrate with AWS GuardDuty, CloudTrail, or container runtime security? Or is it just a legacy host-based agent clumsily bolted onto our cloud environment?

I'm inherently skeptical of anything billed as a silver bullet, especially in a fast-moving DevOps environment. So, for those who've lived with either (or both) in a similar setup: where did the promised theory meet the gritty, annoying practice?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-carbon-black/">VMware Carbon Black Reviews</category>                        <dc:creator>gregm</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-carbon-black/carbon-black-or-crowdstrike-for-a-50-eng-devops-team-on-aws-2/</guid>
                    </item>
				                    <item>
                        <title>Carbon Black&#039;s EDR vs traditional AV - is the overhead justified for us?</title>
                        <link>https://communities.stackinsight.net/community/cyber-carbon-black/carbon-blacks-edr-vs-traditional-av-is-the-overhead-justified-for-us-2/</link>
                        <pubDate>Sat, 22 Aug 2026 15:25:56 +0000</pubDate>
                        <description><![CDATA[Hi everyone. This is a question that’s come up a few times in our internal discussions, and I&#039;m curious how other teams are thinking about it.

We’re a mid-sized SaaS company, and we’ve been...]]></description>
                        <content:encoded><![CDATA[Hi everyone. This is a question that’s come up a few times in our internal discussions, and I'm curious how other teams are thinking about it.

We’re a mid-sized SaaS company, and we’ve been using a traditional, well-regarded AV suite for years. It’s lightweight and mostly runs in the background. Our security team is now pushing hard to adopt Carbon Black's EDR. The promise of deeper visibility, threat hunting, and real-time response is compelling. But the initial pilot felt… heavy. There were more alerts, some performance questions on certain workloads, and it clearly demands more from our SOC team’s time.

So my practical question is: for those who made a similar switch, was the operational overhead worth it? I’m not just talking about detection rates on paper—I mean the day-to-day impact. Did the increased visibility actually lead to actionable incidents you’d have otherwise missed? Or did it mostly create more noise?

I’m particularly interested in experiences from non-enterprise environments. How did you balance the resource investment (both human and system) with the security gains? Any gotchas during rollout you’d share?

—Chloe (mod)]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-carbon-black/">VMware Carbon Black Reviews</category>                        <dc:creator>Chloe22</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-carbon-black/carbon-blacks-edr-vs-traditional-av-is-the-overhead-justified-for-us-2/</guid>
                    </item>
							        </channel>
        </rss>
		