Pain Points

JellyKid · June 2019

We went all in on Watchguard this year because the sales team talks a big game but I'm starting to regret it.

Here are my most painful points:
1. Support doesn't understand the product. I always have to try to escalate until I find someone that kind of understands it. Most of the time support wants to connect to one of my firewalls instead of TDR, when the issue has nothing to do with the firewall. Honestly this product is so different from the others, there should be a separate support team for it IMO.
2. Lack of documentation on things like best practices.
3. Loads of indicators on things that should be trusted. We see indicators on files signed by Microsoft. There is no way to exclude indicators based on publisher. Whitelisting doesn't solve the issue as most of the indicators are for updates or patches which is a routine thing that happens everyday and creates unique files.
4. No way to whitelist domains / report false positives. I understand that it's RED on my firewall that is blocking it and I can whitelist in the HTTP proxies but when something like my AV vendor domains are getting level 7 incidents because of RED, wouldn't the better solution be to submit the domain as a false positive and whitelist it?
5. Files don't upload to APT blocker 90% of the time due to file size. When they do upload, if the file is found to be by a trusted vendor the indicator still stays at the original level rather than being remedied.
6. No way to create rules to automatically remedy or take complex actions, there's not enough control over policy actions.
7. It doesn't interact / take advantage of intelligentAV. There are big holes in the intelligentAV product(no proper way to scan MAPI protocol without routing all mail through a single firewall) which could be remedied by directly interacting with TDR.
8. No true baselining. As far as I can tell it doesn't set a network baseline for things like traffic and activity on the host. I thought this was supposed to be an intelligent product that could detect and alert on abnormal behavior on the host. How can it do that if it doesn't set a network activity baseline.
9. Reporting is sparse and uses scary lingo in executive reports. I am yet to bring any of the reports to our board of directors because the language in the reports makes it seem like our network has been infected when in fact it was just a RED false positive or there are outstanding indicators for things like Microsoft patches.

TDR has a lot of potential but right now it seems half baked. It's frustrating how much was promised and how little was actually delivered.

Ricardo_Arroyo · June 2019

Good afternoon @JellyKid. That is fantastic feedback! I'll address each individually.

Support for TDR - I have escalated this comment to Support and will work with them to make sure we provide better support.
Best Practices - Does this documentation address your needs? If not how so?
Trusting items signed by Microsoft and other vendors - While I understand the desire to just ignore those items, we have seen evidence that a signed binary cannot always be trusted, especially when other indicators of maliciousness are present. We are constantly working on efforts to reduce the amount of files marked with a score of 2. I will include this feedback in those efforts.
False Positive Feedback - I understand the frustration behind not having a more fluid and integrated method to provide feedback on false positives for both TDR and the Firebox. If you were to immediately submit a Portal case indicating RED has marked a legitimate URL as malicious, does support not get that remedied in a timely fashion? How would you prefer to submit false positives to WatchGuard?
Failed Sandbox Actions linger - With 5.7.x we have been working on using extra data to remove non-actionable Indicators from view. This sounds like it would be a good candidate to Automatically Externally Remediate. I will add that to the Backlog of developer work.
Lack of complex action rules - What do you mean by "complex actions?" There is automation Policy that is customizable. Are these Policy Rules inadequate? How would you recommend they be enhanced?
IntelligentAV - Right now TDR passively receives Firebox Logs that we convert into an event. Intelligent AV is included, but is not displayed as a separate indicator type. All IntelligentAV results are listed as GAV Indicators. Is this something we should separate?
Network Baselining - The basic TDR Architecture dictates that the Host Sensor monitors File and Process information on the end host while the Firebox monitors the Network. The way you describe Baselining suggests you expected TDR to perform some sort of anomaly detection. The File and Process Baselining we do at the end host is used to determine if malware landed on the end host during times of extended loss of connectivity to ThreatSync, not to provide any sort of anomaly detection. As a potential feature for the future, WatchGuard is doing research on the topic of anomaly detection, but we do not have it listed on our Roadmap as a feature.
Sparse Reporting - TDR is in the middle of integrating directly into WatchGuard Cloud in order to provide the single pane of glass everyone has been asking for. Once we get further along that effort, we will begin using the WatchGuard Cloud Visibility reporting Framework to generate more varied report graphs. Are there any specific individual reports you want to see first?

greggmh123 · June 2019

Regarding point 7, "IntelligentAV - Right now TDR passively receives Firebox Logs that we convert into an event", is there some way NOT to see what the firewall does in a TDR report? If I want to see firewall events, I'll at firewall logs. If I want to see TDR events for a HOST, I'll look at those logs. I have no need to have my hosts' logs duplicating firewall events.

Ricardo_Arroyo · June 2019

Hello Gregg! I can add it to the backlog. How would you like the option to be available? Would a simple checkbox to include Network Graphs suffice?

greggmh123 · June 2019

Ricardo, I am not sure how you would implement what I mean. I don't see the point of TDR reporting to me what the firewall is doing; I have Dimension and FSM traffic for that. I only need TDR to report what each host is doing locally. It has been a long time since I have looked at TDR due to its information overload, so I need to check now for what it shows before I can answer your question.

Ricardo_Arroyo · June 2019

I will anxiously await your feedback

Bruce_Briggs · June 2019

TDR - System -> Network Events shows many pages of dnsQuestionMatch, and there is no way that I see to see exactly what the DNS question was in the Event Data. This is all that I see:
"<?xml version="1.0" encoding="UTF-8" standalone="yes"?>6366</account..."
How is it helpful to have this recorded for anyone ?
It is not at all useful to me.
And there does not seem to be any way to select "everything but" to easily see the entries which are not dnsQuestionMatch.

Ricardo_Arroyo · June 2019

Thank you for the feedback Bruce. The System -> Network Events Page is intended to be used as a troubleshooting page to ensure the Log generated by your Firebox made it to TDR. That is the reason why we don't provide any advanced sorting and filtering functionality. It was never intended to be a page to used to take actions or make decisions. Firebox Events that correspond to a Host then are processed to become an Indicator. If a Firebox Event gets generated and does not correspond to a Host with a Host Sensor, there's nothing TDR can do about it so we decided to not generate an Indicator. In our new paradigm of Network to Process Correlation, on most Operating systems DNS questions are made by the OS, not the application requesting a name be translated to an IP. Therefore, that specific indicator might not be as useful as originally intended.

JellyKid · June 2019

I think a lot of the pain boils down to too much noise and no way to reduce it. The only tool you give us to reduce the indicator noise is whitelisting which in a static environment might work but what environment remains static? We are constantly pushing vendor updates. When we push out Windows updates or Chrome updates I don’t expect to see 300 new level 3/4 indicators as that’s a common thing we are going to do everyday. If there is no way to cut through the noise, there is no way to see what’s actually happening in the environment and detect real threats.

I’m not a WatchGuard engineer, but it seems like giving us more flexibility to tailor TDR to our environment would be a step in the right direction. I’ll go back to the complex rules. Here is an example of a complex rule I would like to be able to create:

IF 
Executable is signed by “Google“ AND
Executable name is “setup.exe” AND
Heuristics indicator is “Temp Dir EXE Location” AND
No other Heuristics indicators
DO
Set score to 1

I think my complaint with best practices is that I couldn’t find any way to do the above and assumed it was missing. I remember being frustrated with initial setup and thinking that the guide was missing something.
Is support supposed to take false positive feedback and submit it? The last case I created about it had to be escalated and I’m still seeing the issue since the recommend solution was to go to every Firebox and add an exception to every proxy, which if you have a lot of devices and proxies can be tedious. I feel like there should be a way on the support portal or through the product itself to report false positives, without having to open a case about it.
I think my comment about IntelligentAV is more of a problem with IntelligentAV. I was unaware that it was just another form of gateway AV. Gateway AV can’t scan everything the way a host based AV can. If something came through an encrypted email, only the host would see the decrypted contents. Since TDR is host based it could further extend IntelligentAV capabilities by submitting suspicious items to the IntelligentAV service. I mean look at your pitch page, where does it say “well only if it came through a certain proxy and was decrypted and was one of these file types”
The executive reporting is where I would like to see improvement. Maybe have a way when remediating an incident be able set whether it was a false positive or not, that way it doesn’t look like we have hundreds of attacks that we’ve remediated.

Pain Points

Comments