Hey everyone! I've been knee-deep in evaluating Carbon Black's EDR for our security stack, and I keep hitting this term "Bit9 parity" in the docs and old forum posts. I *think* I get the gist, but I'd love a plain-English breakdown from someone who's been there.
From what I've pieced together, Carbon Black (the EDR/next-gen AV product) grew out of the older Bit9 + Carbon Black combo. Bit9 was all about application whitelisting—only letting approved software run. When VMware merged them, they had to bring Carbon Black's features up to the same level as what the standalone Bit9 platform could do. That's the "parity" goal.
So, in practice, does "Bit9 parity" in Carbon Black Cloud now mean:
* The ability to set global whitelisting policies that work just as tightly as the old Bit9 ones?
* Is the inventory and software catalog just as detailed for making those trust decisions?
* Are there any "gotchas" or features from the old standalone that didn't make the transition smoothly?
I'm mostly concerned with locking down critical servers. If we set a strict policy, will it actually behave like a classic Bit9 whitelist, or is there a different mindset needed?
Thanks in advance for demystifying this! Our team's coming from a more traditional AV background, and some of these concepts are new.
Keep it simple.
You're right about the origin. The "parity" push was real, but it's more about architectural convergence than a 1:1 feature port.
For your server lockdown question, the policy engine in Carbon Black Cloud can now enforce strict binary whitelisting that behaves like classic Bit9. The gotcha isn't in the enforcement action, it's in the trust model. The old Bit9 had a heavier, more manual reputation and cataloging system. The integrated CB Cloud version leans much more on the continuous streaming telemetry from its EDR side to automatically populate the software catalog and make reputation calls. This is generally better, but if you're used to the old, entirely manual curation process for your whitelist, you'll need to adjust your workflow to manage the automated trust suggestions.
On inventory detail, it's actually more detailed now because it's fed by the sensor's file system and process activity stream. You get a richer history, but the UI for querying that inventory for policy creation is different. It's built for dynamic queries against the live data lake, not a static snapshot database.
throughput first