So Many False Positives
I've found myself white-listing many directories instead of MD5 hashes because hashes change with updates, and TDR is absolutely wild with false-positives. So far, TDR has highlighted Meraki updates, Office (updates and executables), Windows Defender updates, Windows Updates, GoToMeeting updates, Webroot updates, and more, all as suspicious. I spend hours cleaning this up.
What is the best practice here? I know they score low (suspicious), but one in a hundred may be worth sandboxing. With many program directories now white-listed, i would think it would be pretty easy to stash a payload there. Also, since white-listing is locked to hard path or MD5, how do you overcome updates that run in a users temp directory that uses rotating filenames (ie WRupdate_x10038). Would love to white-list using a wildcard against an executable, but sadly can't.
Just getting started with TDR, so forgive the drawn out bleh'ness of the thread... it's been frustrating.
Comments
I missed the second question re: wildcards. FYI you can add wildcards to path names, e.g. C:\users*\mytempfiles. You can also use variables like %username%, but those can have unexpected results depending on when the OS decides to assign the variable value and when TDR observes an object, so wildcards are safer.
One of the links from https://watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/services/tdr/tdr_deploy_tips_c.html includes mention of exclusions.
https://watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/services/tdr/tdr_exclusions_c.html
Remember to include the trailing slash "\" if you want to also exclude subdirectories.
For now, I would suggest removing your whitelist items and exclusions unless they are known-good and creating indicators of 8 or above. If that is happening, please submit a sample of the files to WatchGuard support for review.
Hi Stewy,
I typed up a long reply and accidentally deleted it when editing to add links. I’ll try to recreate my answer here…
It may help to remember that TDR is not a traditional AV type product with Good-Bad signatures. Everything that happens on a host is observed and assigned a score from 0 (whitelist) to 10 (ransomware or multiple correlated scores). As you noted, many files will score 2-5: TDR tracks those, and if it sees other activity (like registry entries, network activity, other processes hooking into the files, etc.) that score higher, those indicators may add to a total indecent score higher or lower that can cause policies to act upon the files/processes. You won’t be able to not create ANY score at all.
You should not be whitelisting or excluding files or directories unless they are interfering with normal activity. If you review the default policies, you’ll see that TDR won’t act upon indicators until they hit a certain threshold (8-10 for the basic ones). It is simply noting that these files or processes exist and tracking them.
It’s a shift in thinking away from old style 0-1 scoring to a 0-10 sliding scale that allows more flexible handling of events based upon what policies you define.
I rarely, if ever, add whitelist entries for files. The only exclusions I generally add are for intrusive AV products, and sometimes custom patch management, backup or remote access software.
When I provision a new environment with TDR, I start by installing it and seeing what indicators are created. I then add AV exclusions, create a group for my server hosts, and create a custom policy to NOT ALLOW host containment on DNS and AD servers. Once those are set, I enable the default policies and set CyberCon 3 so they are active.
The built-in policies will quarantine and kill known-bad stuff (8 or higher) and sandbox suspected files (not ALL files scored— under the hood it’s checking the file types and score, and only submits if they meet certain criteria). I also enable the Host Containment policy (8+ score), but as noted above I have a custom policy to not allow that on DNS servers or AD servers to I don’t lock out the whole network if one of those is infected.
The bottom line is that just because something has a score, it doesn’t mean it’s considered bad—just observed.
See https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/services/tdr/tdr_deploy_tips_c.html for some useful tips.
Thanks for the information, hard to reprogram my brain from responding to indicators. Especially when you're looking at thousands of them, very cluttery! Perhaps they should not show on the dashboard or renamed "Monitoring" instead of "Medium/Low".
Biggest issue with wildcards is that it should include filename wildcards.
Example: WRupdate971018785.exe is a Webroot update in c:\windows\temp. Don't want to exclude that directory for sure, but could set up a wildcard for WRupdate*.exe.
Wildcards work. You could do "c:\windows\temp\WRupdate.exe" or "c:\windows\temp\WRupdate". You can't do just the filename though, you need a path. "WRupdate*.exe" alone will not match.
For WebRoot, there's a guide at https://watchguard.com/help/docs/help-center/en-US/Content/Integration-Guides/TDR/webroot_tdr.html. Usually you don't have to exclude the updater, just the program. Even that is optional, WebRoot and TDR generally play nicely with each other.
Thanks again!
The updater comes in at a score of 8, so definitely wanted to bypass that.I will give your above examples a shot.
So I've also noticed host "noisy" TDR is. I think my biggest issue is have to manually "resolve" the indicators (7+). I think it may make more sense to NOT resolve the indicators, rather the incidents.
Brian, I'm guessing those 7 indicators you have to manually resolve were from network events. TDR is getting updates to better display network events and reduce the noise they generate in the dashboard.
That would be nice considering that the network events are already denied.... should be remediated automatically within TDR without having to do it manually.
@ John, Yes.
@Stewy @BrianSteingraber That's essentially what will happen with network indicators-- since they have actually already been resolved by the Firebox, they'll be marked externally remediated for display purposes. The underlying data will still factor into correlated events, but the extra 7's will be hidden.
@ Stewy, Yes. That would be very helpful.
Look under Settings: General. Try turning off "Generate Uncorrelated Firebox Indicators" and see if that reduces the noise for you. That will suppress display of Firebox actions that do not have an associated actionable process.
Thanks for that recommendation John, I'll check it out!