We’re migrating product documentation to docs.vmware.com, starting with Carbon Black Cloud. Learn more.

Cb Defense 3.0 Windows Release Notes.pdf

Cb Defense 3.0 Windows Release Notes.pdf

Comments

When will the elongated activation code take effect? Can we get an exact date and time so we can update our script accordingly(we are part of the group scheduled for 9/25)? When this changes, is there a grace period for the old code?

Is this something I should open up a support case for?

I agree with gbrown4554 when is the exact date. I have several properties I will have to send the updates.

For live response can this be used by Carbon support? Considering this is a hosted platform that is screaming back door to me.

gbrown4554​ to read more about the release schedule please visit Rolling Out the September ‘17 Release of Cb Defense to determine when your environment will be updated. In terms of a grace period, it is up to the admin user when they want to download the new sensor, we just make the sensor available on these dates. However, in order to upgrade your script accordingly, you will likely have to install the new sensor on at least one machine so you can see your new (elongated) activation/company code.

rmathismg​ to read more about the release schedule, please visit Rolling Out the September ‘17 Release of Cb DefenseIn terms of Live Response, this feature cannot be used by support. It can only be used by the user(s) elevated to the new admin role, "Live Response Admin."

Just to be clear, If we continue to push out the old sensor(2.0.1.11) we will use the old code untill the 3.0 sensor is deployed once? What if we deploy the 3.0 sensor with the new code, then have to revert back to the old sensor for some reason... would the old code or the newer longer code be used?

We have 10-20 pc re-imaged or deployed every weekday, so I need to know the exact workflow and timings. If the change to the longer code is something we control then there's not much to talk about. If it changes on it's own, then that could be an issue.

Sorry if I'm being dense, but we always have issues when the company code changes as multiple departments have to be notified to update their scripts.

Kyle,

Can you give those of us that see this as a giant back door a little clarification on your statement of "feature cannot be used by support". How is this the software designed to prevent your support from using this as a troubleshooting tool? Seeing as you have explicit access to all portals that seems like you have inherent access based on that design alone. Is the code you used for the remote access explicitly yours or borrowed from another design like VNC or WebEx?

I really like the idea of the feature don't get me wrong. I'm also very uncomfortable with it as you are a 3rd party that has a way into my environment. Lets face it every company will get breached in it's life time you are no exception nor am I. This in a giant hole to every company that has it enabled. Nothing like seeing an active long running session going to an amazon compute cluster to scare your firewall admins and sec admins.

A very clear explanation of it's design would be helpful to see if version 3 is an option for us or not.

pvz

Hi all,

I am hoping I can calm some fears here. As soon as your backend is updated to the September '17 release, you'll see two company registration codes in [gear icon] > enrollment > company codes. Example below.

Screen Shot 2017-09-15 at 12.12.34.jpg

The shorter code is unchanged and must continue to be used for all new 2.x Sensor deployments. The new (longer) code is used only for 3.x and above Sensor deployments.

Bottom line: no changes required to your existing scripting as long as you are still deploying 2.x Sensors. You are in complete control of when to start using the new (longer) code, since it would be whenever you start using the 3.x Sensor installer.

Hope that helps!

-Patrick

Excellent, that's what I was looking for.

Thanks!

rmathismg​,

I definitely understand your concerns over the possibility to misuse this feature. The feature itself is more extensively documented in the  Cb Defense User Guide,​ however I will touch on a few key points in response to the concerns that you mention above.

  • With the introduction of the 3.0 sensor we have included a newLive Response Admin Role to enable customers to more granularity restrict access to this feature
    • Carbon Black Customer Support Representatives DO NOT have the same permissions as this new role and will not be able to interact with a customer's device through the Live Response Console. Customer Support will continue to respond to customer issues using the procedures that are in place now to request sensor logs with the customer's permission. If the support representative would need to troubleshoot an issue with the Live Response feature itself this would need to be coordinated directly with the customer in a manner that the customer is aware of and approves of, likely through video conference.
  • In addition to this new role the following restrictions allow customers to further control access to Live Response
    • The sensor in question MUST be in a policy with Live Response enabled
    • The Live Response capability can be completely removed from the sensor software package through two mechanisms, both of which would require a re-installation of the sensor to enable the Live Response feature:
      • At install time by providing the command line argument CBLR_KILL=1 (Windows Specific)
      • Post installation of the Cb Defense sensor, by browsing to the Enrollment page selecting a sensor or group of sensors and using the take action menu to "Disable Live Response", this method is further documented in the user guide linked above.
  • The feature itself is proprietary Carbon Black code
  • Finally, the feature is extensively exposed in Cb Defense's audit log which includes not only a record of every Live Response session, but also the administrator that created the session, and when viewing verbose Audit Logs, every command that was issued as part of this Live Response session

As a security company we take our customer's security very seriously. Hopefully I have been able to address your concerns, but if you have any further questions or clarifications needed on this feature please don't hesitate to ask

Ed,

  • At install time by providing the command line argument CBLR_KILL=1 (Windows Specific)

Perfect! That's was going to be the next question. Hopefully that option stays in all future releases.

Thank you.

rmathismg​, to add to emurphy​'s excellent answer, Carbon Black Support has a very narrow set of privileges when accessing customer data via Cb Defense Backend. Support privileges have been carefully crafted to balance supportability with security and include many limitations and safety mechanisms. For example, while a Support Engineer might be able to review your company's Whitelist/Blacklist they won't be able to add or remove any items to/from it, etc.

Every time a new feature is added to the product we take great care to review all of the associated risks and benefits and revise Support privileges accordingly. While Live Response would certainly come in handy in many troubleshooting situations, as emurphy had mentioned, it was concluded that this feature is not something that our Support staff would be able to access.

Thanks for the excellent question and I hope we've answered it fully.

--

Alexey Popov | Technical Support Manager, Cb Defense

Should end users be able to delete the canary files?  A user was able to elevate their account to admin and remove them.  I thought this did not work in the EAP testing.

Screen Shot 2017-09-28 at 8.48.19 AM.png

pvz

Yes. And the Sensor will automatically re-create them if they have been deleted.

There's a Carbon Black support person listed in our administrators list and that admin account automatically received Live Response Admin rights along with our other admins when the console was updated to the 3.0 release. As long as Carbon Black controls the back end, which controls the sensors, they have a back door into any endpoint that is running a sensor. What prevents them from using the back door is integrity. It's up to you to decide if you trust Carbon Black.

Hello dbaker​,

To address your immediate concern - Carbon Black Support doesn't get an Admin account in any of our customer's Cb Defense orgs. Support's access to customer data/configuration works differently - via a special console with tightly controlled user privileges (see my earlier reply above for more information on that).

We've checked your specific Cb Defense org and were able to find out that the @carbonblack Admin account you are referring to is in fact a Sales Engineer who assisted with your evaluation of Cb Defense before you made the purchase. Carbon Black Sales Engineers are set up with Admin accounts so they can help prospective customers get the most out of the product during the evaluation period. Once the evaluation is over, Sales Engineer's Admin account is removed from the org. It appears that didn't happen in your case for some reason; We will investigate that internally to make sure we address the underlying cause so it doesn't happen again in the future.

In the meantime, I have deleted the Admin account in question from your org. As a side note, any of your Admins could've done the same from your end.

If you need more information on this, I suggest we redirect this conversation into a Support case. Please reference my reply in your case, so the Support Engineer assisting you gets the necessary context and knows how to proceed.

Thank you.

--

Alexey Popov | Technical Support Manager, Cb Defense

As long as the feature can be turned back on in the policy Carbon Black will have access to endpoints that are running the sensor.  This will continue to be a back door until there's a release of the sensor that doesn't contain the back door code.

Thanks Alexey.  This answers what happened to the account in question that was no longer there when I went to show it to my manager.  It also demonstrates my point that as long as Carbon Black has control of the back end they have access to any endpoint running the version 3 sensor.  This won't change until Carbon Black releases a version of the sensor that does not contain the Live Remote Admin feature (for those customers unwilling to allow Carbon Black this level of access to their endpoints).

By the way, I appreciate the transparency with which you have been addressing this question.

"In the meantime, I have deleted the Admin account in question from your org. As a side note, any of your Admins could've done the same from your end."

How many engineers, sysadmin, support reps have the level of access you do? By saying the above, you are implying that you have access to all portals, which would point to being able to modify settings and in some cases agents. Can you grant access in the same manner?

dbaker​, there is a "kill switch" that you can use to completely disable LR feature in the sensor. This can be done in two ways: 1.) Settings -> Enrollment -> select device(s) -> click 'Take Action' -> Disable Live Response; 2.) By using “--disable-live-response” parameter during unattended installation of Cb Defense sensor. The only way to re-enable LR in either case would be to reinstall the sensor.

Using the “kill switch” will of course prevent LR session to select endpoint(s) from any Admin, regardless of how that Admin account was created or by whom. If you want your Admins to still be able to use the feature, I don’t think there is a practical way to solve this due to the fact that Cb Defense is delivered in SaaS format, i.e. Carbon Black manages the “server” part of the solution for you. If you have any ideas on how this could be addressed in the product, please post those in Idea Central. If you have specific privacy concerns related to Carbon Black’s handling of your company’s sensitive data, I recommend following up with your Customer Success Manager or Account Manager at Carbon Black who will be able to assist with that.

P.S. The “kill switch” method #2 is undocumented, so there is a chance it didn’t make it into the initial 3.0 sensor release. I’m checking on that and will get back to you when I have the answer. 

--

Alexey Popov | Technical Support Manager, Cb Defense

Good question, rmathismg​! The default Support role I wrote about above does not allow a Support Engineer to manage an org's Admins. That includes creating, deleting as well promoting/demoting Admins. In other words, what I was able to do in this particular case to help dbaker is not representative of what a Carbon Black Support Engineer is able to do in general. I hope that addresses your question sufficiently.

--

Alexey Popov | Technical Support Manager, Cb Defense

dbaker​, I was able to confirm that both "kill switch" options (post-install and upon install) are in fact available in the current release. The command line option was overlooked when updating the documentation, but will be added to Cb Defense User Guide in the coming weeks. Thank you.

--

Alexey Popov | Technical Support Manager, Cb Defense

The Carbon Black team has disabled (without our permission) the Live Response feature on all of our endpoints.  The Carbon Black team (without asking our permission) have purged the section of our Audit Log that would show who performed the action.

dbaker, we did not alter the configuration of your Cb Defense org in the ways you are describing. At least not intentionally. The only change that was done from our end is the earlier removal of a Sales Engineer's Admin account, which was mistakenly left over from your evaluation of the product. I know you've spoken with your Account Manager about this and were instructed to open a case. Please allow us to investigate your report and we will get back to you with our detailed findings via the case shortly. Thank you.

--

Alexey Popov | Technical Support Manager, Cb Defense

Both commands work on installation?

CBLR_KILL=1 (Windows Specific)

--disable-live-resonse

Also, will this also work on sensor "upgrade"? Say on the next update install I don't want Response enabled

I owe the Carbon Black team an apology, I should have read the manual before speaking.  Live Response is disabled by default and requires a policy change to turn it on.  Also, the Audit Log only records user activity so there are periods of time where there are no log entries because there's been no user activity.  Sorry Carbon Black support team.

The windows switch to disable live response on install should be DISABLE_LIVE_RESPONSE=1.

The Mac version is --disable-live-response.

Live Response can be disabled through the UI post-install, under enrollment, check the device, and choose "actions" , "disable live response".
You will be warned that if you disable live response, you will be required to reinstall the sensor to re-enable it.

With that all said, Live Response only works if if the computer is put into a policy where live response is enabled, and the currently logged in user of the console is a Live Response Admin.

So, another option is to create a policy where live response is disabled and if needed, move the computers to that policy if Live Response needs to be temporarily disabled for any reason.

Absolutely no worries, dbaker​! Live Response is a very new feature in Cb Defense, so there is a learning curve. In fact, the Support Engineer on your case has also overlooked the fact the feature is disabled by default at first We will all learn from this experience. Thank you for the timely update, patience and understanding.

--

Alexey Popov | Technical Support Manager, Cb Defense

Thank you, dcoty​.

cstamand​, to clarify, "--disable-live-response" is the switch for the upcoming Mac Sensor 3.0 release, which is not yet available; "DISABLE_LIVE_RESPONSE=1" is the correct parameter for the current Windows installer. Sorry for the earlier confusion on the syntax. The correct information will be added to the User Guide shortly.

We do not know yet whether the switch also works on sensor update/upgrade and not just fresh install, but will find out and get back to you with an answer.

Thank you for the excellent question, as always.

--

Alexey Popov | Technical Support Manager, Cb Defense

alexeypopov The install log file shows (on windows) that the command is CBLR_KILL. Would that mean both would work??

Interesting... Thanks for pointing that out, cstamand​. I don't know the answer, but dcoty​ is looking into this and will respond when we have more information.

--

Alexey Popov | Technical Support Manager, Cb Defense

To answer the question if the kill switch works when upgrading, the answer to that is yes.

If you use the DISABLE_LIVE_RESPONSE switch in the unattended install, it will persist despite upgrades.

The only way to reverse it is to uninstall and reinstall the sensor, without that switch.

I'm working to answer the question on if you can use CBLR_KILL as well as the DISABLE_LIVE_RESPONSE switch.

I hope to have that answer shortly. Sorry for the delay!

If you upgrade with the parameter DISABLE_LIVE_RESPONSE=0 then should that enable LR?

This will not re-enable Live Response. Once DISABLE_LIVE_RESPONSE is 1, an uninstall and reinstall is required to re-enable it.

Article Information
Author:
Creation Date:
‎09-14-2017
Views:
7599
Contributors