I actually have to answer myself.

EXCEL rulez!

 

So comparing today's MD5 list of undetermined software and the list of MD5 overrides I created 2 days ago I found that the console does not care about manula overrides at all, those MD5's I added as GOOD are still listed in every later undetermined sofware seen report.

 

THIS IS REALLY BAD BAD BAD!

I explicitly told my WSA console that these were GOOD! Do not tell me these are undetermined again!

 

---

Gyozo,

 

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

 

GB

---

@ and @ - let me explain how overrides work and what the determination column means.

 

> Determination column - this is what our central intellegence knows about the MD5, not what you configured. Your override is only meant to work until our central intellegence either gets updated through customer input, or you submit a known commercial product or any MD5 product to our threat team, who will determine if it's appropriate enought to include across our customer base and all users.

- To request a product be whitelisted centrally, open a support ticket OR got to this link and submit the said file/MD5: Submit Link

- Submit a support ticket request with the MD5 details and they will escalate to AMR and/or Threat.

 

> Undetermined Software Report - is a historical report that shows what agents have listed as undetermined. It will not update or purge as you whitelist, it's strictly for auditing purposes. Once your've whitelisted, the last date seen should become static. Also, whitelisted items in your console will NOT display in the undetermined report.

 

How whitelisted folders work: When you configure a new whitelisted MD5, if you see the determination as good, then there's no need to configure it locally as it adds work to the agent. After the override has been configured, the next time the agent calls home, (Polling cycle - best practice to make this 15 minutes). The respective endpoints will recieve it's informaiton and going forward will respect the overrides.

 

Couple of caveats about configuring overrides as I've seen a lot of misconfigured folders.

> Wildcards are not supported within a folder/dir, you have to either use explicit or dynamic. Explicit, specify the folder "c:myapp" or "%program foldermyapp%" - the second pulls from registry. To see that list, type a percent sign and see what's supported. If you type %myappmore programs% - this will not work. or %myapp* will not work etc...

 

Whitelisting or Overrides are only designed to be used for appliations and utilities that our central intelligence is now aware. Use them spareingly as they put a lot of processing on and end point, especially if they push hundreds.

 

Hope this helps.

Shane

 

---

@- 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 :)

 

 

---

Hi Shane,

 

Thanks for your detailed response. Unfortunately, the "Last Seen" date is not static in the Undetermined Software Seen report. It has been changing with each passing day. I've included a screen shot (below), as an example, so you can see that it still marks the dll as undetermined and the Last Seen date is today's date.

 

 

 

This is after we've whitelisted (screen shot below) the directory, and made sure that the dll had the determination flags modified in the WRLog.log.

 

 

 

 

Mon 2016-10-24 14:04:05.0237 Determination flags modified: c:program files (x86)extylesomserverxerces.dll - MD5: 3BD624F0BF17AF75E2D07BB4055A9EAC, Size: 1269839 bytes, Flags: 00000008

 

I wouldn't have as much of a problem with the report if the "Last Seen" date was static in the report, but because it lists it every day, it makes it difficult for us to know if our overrides have been working or not, without having to visit each machine and check it's WRLog.log to see if it had the determination flags modified.

 

Ideally we would not want the item(s) we whitelisted to show up in this report, because technically they are no longer undertermined.

 

Also, we have a lot of undetermined software. It's unrealistic to expect us to submit MD5s for each file that gets classified as undetermined. Some program directories we have, have at least a hundred DLLs, OCXs, EXEs, and other files. That's why the directory exclusion was an especially important addition for us.

 

Let me know your thoughts. If you would like more information, please let me know and I will happily provide it. So far, this has not been a major setback... yet, just more of an inconvenience. If we end up having to visit a bunch of machines and check the WRLog.log for determination flags modified, then I would say that it's a setback.

 

Thanks!

 

GB

---

@ - 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 .

---

The screen shots are there when I sign in, but if I'm not signed in, they don't show. Is there somewhere I can upload them to?

---

@ - 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 checked the Ovr.db file in the WRData folder. It is getting updated. As of right now, it has a date stamp of 11/7/2016 (yesterday) in Windows Explorer. When I opened the file last week and checked, I saw it wasn't clear text and closed out of it, without noticing that there's a date stamp in it. I just checked it and the date that it has in there is 2016-11-03... so still somewhat current.

 

The file was not quarantined, it was only being monitored by Webroot, which was slowing down processes. My only issue was that it's showing in the "All Undetermined Software Seen" report with a Last Seen date of today. It should either show up in the report with a static Last Seen date or it should not show up in the report at all - that way we'd know that the override took.

 

When I had opened a case with Support, they said,

 

"..the Undetermined Software report uses the cloud determination and will *not* respect your overrides - so this is expected.

 

The fact that the ovr.db file is up-to-date and you also see that the Determination flags modified entries in the WRLog does indicate that the override is working (and this is currently the only way to confirm that they are working).."

 

Would the "Detect if Malicious" option (see screen shot below) factor into the Last Seen Date?

 

 

I'm wondering if we selected "No", if the Last Seen date would continue to get updated...

 

---

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.

---

@ - sorry for the delay. Yes, detect Malicious may cause a bit of contention. I suggest this setting is rarely used unless the product being whitelisted is something you do not fully understand or is possibly a questionable utility.

 

For known business applications or utilities, do not use Detect if Malicious.

 

Thanks,

Shane

---