How to track threat disposition for an agent from GSM

  • 9 January 2017
  • 9 replies

Badge +1
Deployed several agents in multiple sites. When a threat appears and then goes away (seemingly by itself), how do you know what the disposition of the threat is (e.g. some AV would indicate is it is in quarintine or deleted at least from the agent GUI). If you are managing via GSM, how do you know the disposition?
Is there a log that can be retrieved from the agent? By GSM?

Best answer by WaymonB 12 January 2017, 02:08

View original

9 replies

Userlevel 7
I'm still relatively new to the Endpoint Console, but I believe what you're wanting would be found by generating a Report of detected threats:
Badge +1
Thanks JP!
Using reports, like the All Threats Seen, I know the threat occurred. What I'd like to know is whether they were moved to a quarantine area or deleted.
From the report the endpoint can be identified and the scan history shown from Group Management. If I select the View from a line that inidcates threat detected and then select the infected file there is "Restore from Quarantine" button which suggests it was quarantined instead of being deleted.
I think my main concern is I'll do something to clean the quarantine area or a dispostion will be to delete the file. Then down the road a client will say something is broken that is tracked to Webroot action. And we will not be able to determine that.
Is there a way to check the quarantine area?
Userlevel 7
My pleasure!

Once again let me reiterate that I'm very new to Endpoint (I come from Consumer Support), but it sounds like what you're wanting is to take a look at the Scan History under Group Management.

If this isn't what you're looking for, please reply so I can ask someone here who knows much better than I do.
Badge +1
I'm looking for something in addition to that. Or to hear that it doesn't exist.
I realize that threat history for endpoint shows threats and has a [Restore from Quarantine] button. There are simiar places in the Site [Stautus] tab (for active threats) and also on the sites page when a site is marked "Needs Attention".
I'm looking for proof the files are in quarantine. For instance one site I populated using the Silent Audit profile as default. Threats are detected. The same places have what appear to be usuable [Restore from Quarantine] buttons. But if I understood correctly no action is taken by Silent Audit profile (so how can there be anything in quarantine)
This is just one concern in switching our clients over to Webroot. I should probably seek answers to some of the other concerns. Maybe it will come together for me.
Hi there, 
My name is Waymon, and I am with the Enterprise Support Team. I was looking over your post and I believe I can help out. 
Knowing what needs to be done when you see the "Needs Attention" flag in the console all depends on the policy that the machine is tied to. For example, the default  policies are auto remediating. Meaning that WSA is going to automatically quarantine threats it encounters, and the alerts you see are simply letting you know what it's removed. The silent audit and the unmanaged policies however are non remediating. Meaning that it's alerting you to what it's found, but its needing you to actually click the cleanup button to finish and quarantine the threat. This is mainly because silent audit and unmanaged are designed for diagnostics and troubelshooting. 
A few things to note:
WSA quarantines items, it does not delete them. But with that said, once an item is quarantined it's essentially gone. 
If you go into Group Management on the site level, then click on a machine, the bottom half of the page will display a scan history. As long as the last scan is showing protected then you are good to go. The console will eventually catch up and remove "Needs Attention" status. However, if the last scan is still showing infected, this is usually a good time to call us so we can do some deeper digging. 
Finally, if you have a custom policy and you're wanting to know if has auto remediation turned on, there is an easy way to check.  While in the policies go to Scan Settings, and make sure "Automatically remove threats found during background scans" is on. 
Hope this Helps, 
Waymon B. 
Badge +1
Hi Waymon,
Thanks for your informative reply and insight. I was concerned that some threats persist when using Recommended Default policy. I tried the Silent Audit on one of many clients  to see how might use for clients were more concerned about breaking something.
Is there guidance on when to call on repeating threat in successive scans (for instance 3 in row or after 2 business days). You indicated to call. Is that best or is it better to open a support ticket? The ticket might be easier for my colleagues and I to share awareness of status.
Is there a doc, best practices guide, ... that helps prepare MSP folks to manage Webroot accross multiple clients? For instance, after install (recommended default policy), saw a threat persist a couple of times, got a good scan, and then the same threat appeared again. Its for a app called weatherbug. If Webroot automatically quarantined the file and then it appeared again, I'm guessing the app broke for the client's user and they re-installed it. Is there a guide that would have tips about addressing common threat patterns (which is why I was hoping to track threat disposition)?
I'll open another post on the following if appropriate. A posting I read suggested checking threat with VirusTotal. That was interesting, but uncertain how to use safely. Note that Webroot doesn't post their findings. For some webroot threats other security sites have a green or the majority do. This is another place I could use tips or best practices. For instance, if threat has old first discovery date, is 90% green on VirusTotal, and client has a history of using app w/o problems this is one that might be whitelisted with somewhat low risk. Any guides to help with decisions about allowing a threat (or way to rank the threat)?
Userlevel 3
Hello Greg,
Welcome to the Webroot community.  My name is Donna Herman and I work with MSP's here at Webroot.  I'm going to send you a private email so we can get you some more specific help with Best Practices.  So keep an eye out for the email.
Hi Greg, 
Sorry for the late response. When it comes to the question of "Should I open a ticket, or call", it really boils down to urgency. We have 24 hour turnaround time on our tickets. Typically our response time is much faster, but this is the window we have for general inquiries. If you're dealing with a threat (or really any issue) that needs immediate attention, a phone call is always going to be the best option. Our phone number is (866) 254-8400. 
I would say for a general rule, if you get a few scans that come up infected in succession, it's a good time to get support involved. Most of the time it's nothing. Usually just junk software that WSA needs several scans to completely remove everything. Other times it can be more serious, needing our Advanced Malware Removal team to get involved. 
One more thing to note from a support standpoint. At the bottom of the post I am going to include the link for our diagnostic tool. Whenever you have an issue with a machine (or several machines), run this before contacting us. This is going to save us a step as pretty much all of our issue cases start with us asking for the admin to grab logs. If you do this and let us know on the phone or in the ticket that the tool has been run, we can go right into digging into the problem. 
One other thing before I go. It looks like Donna is going to get you the documentation you asked for, but if you are new to Webroot and are looking for an MSP best practices call/walkthrough, let me know. I'd be more than happy to set one up. Either send me a private message, or create a trouble ticket through the console referencing either me or this community post and I can get something set up. 
Like always, hope this helps!

Waymon B. 
Webroot local diagnostic tool:
Badge +1
Thanks Waymon,
Donna has arranged a meeting with us to review best practices and check our GSM console.