Disabled Agent Commands for all users, including "Super Administrators"

Having remote commands that allow servers and workstations to be rebooted, Windows registry modified, files downloaded, and files executed seems to me a very dangerous tool. It provides a Internet reachable, single console, that could provide a means to download and infect hundreds (thousands?) of machines just by knowing a single admin ID.
I would like a feature that could disable the agent commands (especially advanced) from being executed.
This would be for all administrative classes, including the "super user".
One other thought. Since this feature is built-in to endpoint agents, could someone access our endpoints without going through the console

14 replies

Userlevel 7
Badge +35
Thank you for your suggestion, this has been closed due to a lack of kudos from other community members. Please feel free to start a discussion and submit a new feature request if there is additional interest from other members. Thank you!  
Userlevel 4
Maybe the option to disable agent commands could be linked to my suggestion on IP restreictions: https:///t5/Feature-Requests/IP-restricted-access-to-the-console/idi-p/48722
This would let the administrator enable / disable agent commands only from his own IP-adresses, possibly with the option that agent commands only may be done when loging into the portal from his registered IP's.
A locally controlled on/off switch would be great.
Badge +5
I think if there were a local admin override it would negate the need for the remote agent would make more sense to have those commands turned off given that option.
I think the request stems from the "cloud"...those that would want the remote commands turned off would also feel more comfortable having the old model of a local server contacting the endpoints...(different scenario same issues)?
By having a local override and having the cloud commands turned off it would be a hybrid? win-win?
The cloud would then be more for reports and tracking and the local admin override would be the resolution point.
Could be a workable solution...
I for one would still like the local override whether the remote commands are turned on or off. :D
Yes, I would like the ability to have the "agent commands" turned off.
Userlevel 7
Thanks for getting us back on track.  :)

Just so I understand properly, you're asking for the ability to send agent commands to be shut off entirely, presumably by our support agents, correct?  Then to turn it back on, you'd presumably contact our support?
Thank you for the responses.  I'm not sure if the basic feature request is being understood.   Too much centralized access is being provided through the admin console.  All the security and protections (2 factor authentication) are nice, but the simple fact is that it should be left up to the purchaser of the product to decide how much remote access is needed.
Turning off the "agent commands" from an admin by the super admin has been the stock response for the last 12 months.  
Please setup a feature that would turn off the "agent commands" to download and execute programs (modify registry!) to each endpoint.  The benefits are not enought to risk damage to hundreds of machines.
When a business owner of Webroot has damage caused by malicious actions through the super admin ID I'm guessing the cause will be a compromised or old password.   Since this is a very likely scenario, why not provide a way to mitigate the risk?
Userlevel 7
"When I say monitoring I mean monitoring of the keyboard and screen of the computer to figure out the password and passcode[1]. If someone has my password, that means they probably already have access to my keyboard (and most likely my screen) meaning that the Identity Shield has already failed and is not protecting me."
That's a highly unlikely scenario based on how the Identity Shield works.  Any file that isn't flagged as good is going to be treated as a potential keylogger or screengrabber and be blocked from completing those kinds of actions.
Regarding the hardware solution, it's not as though that's a perfect solution either.  Just as you pointed out, certainly it's possible that somebody you've allowed access to the console might inadvisably log into it from a computer not protected by WSA.  But that would be user error and hopefully a breach of policy at your workplace.  Ultimately, you can have user error with any two-factor authentication.  What if the user's Yubikey is stolen for instance and the attacker already has the password half of it from the scenario you presented about an unprotected computer?
Userlevel 7
When I say monitoring I mean monitoring of the keyboard and screen of the computer to figure out the password and passcode[1]. If someone has my password, that means they probably already have access to my keyboard (and most likely my screen) meaning that the Identity Shield has already failed and is not protecting me. After just a few logins they know enough of the letters to refresh the page until the console login asks them for the letters they already know. Considering I log into the console multiple times per day, they would not need a large window.
A second factor is supposed to ensure that knowledge is not enough. A second factor is something that requires ownership of to grant access to the system, be it a hardware key or biometric solution. And it is supposed to protect the careless. It's unlikely that an attacker will gain access to my computer and then the WSA console password. But I am not the only one with access.Even view-only helpdesk account has access to monitor the progress of an APT attack or embarass my company with screenshots of my antivirus console. Plus, the console is exposed to the internet; I can't assure computers logging into it have WSA installed to protect against loggers.
The power of the WSA console and its exposure to the internet means I believe every possible option should be given to an administrator in protecting a crown jewel of their security solution. I am already being asked to trust Webroot to properly partition access between users and consoles and give up my ability to who can access the login screen. Compromise of this product means compromise of my company, and the loss of my job.
I accept your criticism of my language implying the majority of people should not feel the security code offers additional protection. But I will continue to see it as a stop-gap measure designed around the failings of the common user, rather than a true enterprise-grade solution to keep my company safe from the motivated.
[1] Many people are going to have terrible passcodes that are probably going to their their name or company name. If the attacker knows the positions of the letters and enough of them they can use hangman game solution software to ferret out the entire code. Especially since Webroot only seems to ask for the first 6 letters.
Userlevel 7
When you say "with enough monitoring," I'm assuming you mean "with enough brute forcing," because otherwise I'm not sure what you mean in terms of threats not already covered in other ways by WSA.  There are actually lockouts in place to block a fraudulent user from trying to get in too many times unsuccessfully, which would cover the secondary brute forcing attack.
Screen monitoring and keylogging are covered by the Identity Shield.
Is a hardware lock still better?  Technically yes, because as you mentioned, it's a rotating or randomized code, but the additional security provided by that is not significant by comparison to the technology already in place.
Userlevel 7
Hi Jim, I understand your objection. Before I say more, that was a draft although language similar to that would have ended up in the final version.
However, your solution uses an unchanging set of letters and is really just an extension to the password. With enough monitoring the static key can be determined. A hardware or mobile device 2nd factor solution would not be vulnerable to that.
(Of course, when an attacker has screen/keyboard monitoring of your computer they could just redirect all your entry into letting them login on their computer anyway)
I accept that my criticism about the security code in the draft is too hard. For 99% of people it is a drastic increase in security since it forces them out the same password granting access to everything they have. It also forces the attacker to have prolonged access to an administrative computer and specifically target the WSA console. However, in the context of a security solution that will go up against motivated organizational attackers I think it is not entirely unfair. 
Userlevel 7
Not to take us too far off-topic Explanoit, but I really have to disagree with the statement that nobody should feel any stronger sense of security when using our two-factor authentication.  It's intended to thwart brute forcers, rainbow tables, etc. and it should provide a stronger sense of security by using it.  I know you're partial to Yubikeys, but that doesn't diminish the effectiveness of soft two-factor methods.
Userlevel 7
Funny story, I started writing a guide on access control to the WSA console but stopped since I figured no one would care.

Userlevel 7
Userlevel 3
Badge +10
In answer to your query there is a way to restrict your admins and console users from executing Agent Commands from the console. 
  1. Click on your email/login in the top right of your console and select Manage Users from the dropdown menu
  2. Next click on the person icon to the right of the account you would like to restrict to Access the Account Settings menu
  3. Click the Access & Permissions tab
  4. In the Commands subsection you have a choice to set Agent Command access to None, Simple, Advanced or Expert. To completely restrict commands select None
  5. Finally click on the Save Access and Permissions button at the bottom of the screen to save changes and repeat this process for any other agents you may want to restrict
I see that perhaps this could be better explained from the console so I will request some changes to our console's Help section to make this clearer. Thank you.
In answer to your second query no external user or process will be allowed to compromise your Webroot SecureAnywhere Agents without Console access. Our password, trustpass and security code combined will keep your accounts safe unless someone can get access to the first two passwords and then the device (such as mobile phone) or email account that the trustpass gets sent to.
Changing your password for access every couple of months will help keep your account even safer.

The Logs section of your Console also has a Change Log and Command Log that will help you monitor changes and logons to your console and the Alerts section can inform you immediately of similar changes.

Please don't hesitate to reply with any further queries.
The Threat Research Team