Are yesterday created overrides listed in today's All Undetermined Software seen report?

Gyozo,
 
I completely agree. Thanks for posting your findings. I hope Webroot creates a fix for this sometime in the near future.
 
GB

@- you know, the problem is that any undertermined is also suspicious!!!
Webroot should take care of any undetermined found in any of its customer's console as those can be any 0-day malware.
 
I think, we, who purchased a Webroot licence, put our trust into Webroot findong AND taking care of unknowns AND in a reasonlabe time, otherwise how can we be sure that any of these unknowns are not a KGB, FBI, Mosad, etc. targeted attack malware file?
 
Also, a "historical" report can be useful in some cases I agree. But for me it is much more important to see what unknowns we still have after having done the work instead of Webroot (you know, creating my own good overrides) because I want to see clearly what I still have to bother about.
 
Another big problem is that the "undetermined software seen" report does not load all rows into the report interface so we cannot e.g. 1-see how many we have in total, 2-sort the list by any column, the whole report interface is an old-age design, helps nothign in work, the only thing you can use is the export button there.
 
But again, one must take care of unknowns, and being a customer for many years, I still can see 1000s of unknowns in the console that never get claasified by Webroot - but noone knows why.
 
Why?
Why does not WIN (Webroot Intelligence Network) classifiy them?
Why not in 15 minutes like other security vendors (e.g. Palo Alto Netwroks Wildfire or FireEye, etc.)
Why not 1 day? Why not in 2 days? Why not in a week? Why never???
 
The whole securtiy industry is bothering about unknonws. Webroot, who has a WIN for this purpose, why cannot classify these unknowns in our consoles?
 
I woul like to see each and every file is either GOOD or BAD in minutes after found as unknown. Classifiying them later can result in a data breach or other unwanted malware activity.
 
So if anybody ever gets to the point that he ever opened an "unknonw report" in the console, I bet he does want to take care of 0-day attacks and he might need the same I mentioned above. And I bet he does not care of historical data that much he would care about current (even real-time) situation.
 
 
PS. my very simple human logic in my head just keeps telling me that once I set something as GOOD then I do not want to see it again as UKNOWN in any report - or at least not in today's one. I know, my very simple logic migth be very hard to follow but at the same time it is a bed of many quite successful strategies thoguh and I seem to keep trust it works good :)
 
 

@ - screens didn't come through, or at least not showing up in Chrome. I'd like to see the whitelist config's for folders as that usually takes care of all DLLs, etc... within a specific dir and whitelisting MD5s can be painful and cumbersome.
 
PM me directly to discuss some avenues for troubleshooting the OVR file that comes down to the endpoint. scooper@webroot.com
 
@ - you're right regarding the "historical" aspect of undetermines, while nice, they're not useful for day to day activities as it's hard (with the current report) to weed out the "noise".
 
In regards to why WR doesn't whitelist all of the undermines, there's several answers to the question.
1) All uknowns are classified and the majority are actually benign and would just add to the noise in our WIN. For example, several of my test machines, including one of my company laptops has a few undetermines all the time. Some go away as we get them categorized if they're part of a MS patch or what not. Others have been set as undertmined for a while and cause zero issues. So, "cleaning" up all the undertmineds is a bit of overkill and a bit of wasted work. (in my opinion)
2) for zero day undetermineds, they fall into a different category and in most cases are marked within minutes as to what they are based upon heuristics and behaviour analytics, not through a determination. They may be listed in the unknown or undertermined list for a short while, but once discovered as to their intent and what they are, they're marked immediately for all other endpoints to insure their determinations are updated immediately.
 
Again, benign utililties and even some line of business applications never effect the agent, performance on the endpoint nor are even something to worry about. The goal of the Undetermiend report is to simply provide insight into what the agent deems unknown and if there's something obvious, like important LOB applications/utilities/custom software etc... then configure a whitelist so as to err on the side of caution so the agent dosen't break something important, many unknowns can be left alone.
 
In fact, there's less performance degredation on low impactful unknowns than making a million lines of whitelists, which can put undo burden on the agent that has to crawl and log of the whitelisted items.  This is why I recommend to leave a lot of them alone since they're not really creating any issues. If there is something that's affecting performance or breaking production, then whitelist. If it's a COTS product and for some reason we're marking it unknown, then submit a request for review by an actual human analyst. 8-)
 
Net-Net, we've requested, numerous times to create a more useful "audit" log/report so a tech can review it and insure they're getting whitelists in place to NOT break business. We've even asked to at least look into the respective whitelist confiigs on a console (GSM or Site) and display that in the determinations column .

@ - not sure what was up yesterady. Screen showed up fine this morning.
 
Looks like the dir override is configured properly. Overrides are stored in a file locally so the agent has full access whether online or offline. It's named OVR.db in the WRDATA folder. It gets updated on next agent polling cycle. Or, you can Refresh Configuration on the tray icon manually if you have direct access ot the endpoint. The agent will update it's OVR file. You can check the date stamp two ways. Check the windows explorer time/date stamp to insure it's been updated after the override was configured. You can also open this file. The only thing in clear text is the date stamp of when the file details were updated.
 
You can't delete or modify this file as it's locked by the agent, but you can review it. If for some reason it's not updated, the overide may not be readable by the agent, so getting it to update is important. That's the only thing I can think for why it's not working.
 
Also, did you remove the file from qurantine?

I often suggest to NOT use detect if malicious unless it's completely something you're not aware. So, turn that off for sure, because the agent will continue to keep an eye on items in that folder.
 
The other area you may want to double check is, Identity Shield on the endpoint it'self. Got to the gear icon and then Application Protection tab. There's a chance that something else is being monitored there or blocked that's related and you'll need to whitelist that dir as well. Identity Shield monitors do not show up in undetermined or .log file for some reason and have been known to cause issues.