While it might be possible to do rollback, WebRoot doesn't do rollback on network drives and unknown applications are allowed access to these resources. Since this is often deployed as a business AV solution, this is unacceptable.
Is there functionality in WebRoot currently, or that could be easily added to straight up block execution of unknown executables (as a configurable option of course) -- ideally whitelisting anything SIGNED by a trusted entity (eg. Microsoft)? Or is there a way I can already do this?
I know that I could use SRP in Windows, but I feel this would be better handled within Webroot since it already has such a vast intelligence pool of known good and bad hashes. Also SRP may be deprecated in future releases based on notes in Win 10 1809. And Applocker requires Windows 10 Enterprise, an expense many businesses are unwilling to budget for.
Thanks in advance for either a configuration setting that would allow this, or to have this feature added to your roadmap.
Best answer by coscooper
There is a feature within the Heuristics area that you can apply to do what you're suggesting. In the Heuristics area you can change the setting to "warn when program launches that's not known good", in effect making it a whitelist function. However, it is a warn so the user can still make a choice.
There are two caveats:
1 - it is vector by vector, meaning you'll have to set this setting on each watched area, like USB etc...
2 - it's a warning popup and the reason is so in the case of a line of business application that is not known to our threat data a user can allow it to run, otherwise, if it was hard set to "always" block unknowns, there would be a higher level of false positives.
NOTE: The Webroot agents heuristics are behavior based and being agnostics take an innocent until proven guilty approach. If you're interesting in more details regarding your test results, you can supply the "files" in question to our threat team for analysis. It could be that the files were detected as benign based upon fake internal content code and the binary was targeted as such in our threat data, meaning our agent saw it as non-malicous.
There are many reasons why the WR agent may have ignored a file, which may require a more in depth analysis with our team.
If it was in an isolated computer and your testing team threw real malware at the agent, then a conversation with our threat team would be helpful for everyone.