True, but as you said it's more difficult when the ability to exclude files is obscured by being buried in the settings.
It could be if you eliminated their ability to manipulate it, but that's unworkable.
Trust me, I tried.
In regard to VS blocking the WD platform update, the reason it does so is because its signed with a different digital signature than the rest of Microsoft's files. See here, right side:
View attachment 235119
There's tons of Microsoft-signed files all sporting the same digital signature on my whitelist but none that match this one, so the "Automatically allow items that match a digital signature in the whitelist snapshot" rule wouldn't apply.
Instead of going through each post and confusing everything, I am just going to reply to this one. Before I forget, the "Automatically allow items that match a digital signature in the whitelist snapshot" does not apply to Microsoft sigs. We excluded Microsoft sigs until we are certain that they are not forged. I do not believe they are, but until we know for sure, we had to exclude them from this option. As far as the block goes, it is a very odd one, but we will certainly find a safe way to auto allow it, and that will in turn safely fix other potential blocks we would otherwise encounter down the road. It is the long way to go about it, but it is the only safe way.
I hear what you guys are saying about the prompts, and here is my take...
First and foremost, new, non-whitelisted items should never be able to automatically execute when the user is engaging in risky activity. Some people say "well, the user might just click allow and infect the computer." I guess that is true to a certain extent, but that is much better than the alternative, which is that the file auto executes. By prompting the user, you at least are giving the user a chance and some pause in order to make the correct decision. How many novice or average users do you think would click the Allow button on a Red prompt? Also keep in mind, using the golden rule, pretty much all of the attacks not initiated by the user clicking on the file are resolved before the main prompt is even shown.
In all of the years that VS has been around, there have been only 2 reported infections from the user clicking the allow button, and one of those was a bug in VS that did not deal with the .scr file type correctly, which has been fixed since then. VS has a lot more users than you would guess, and to have that low of an infection rate is remarkable. I could go into a long story about how I work directly with some of our novice and average end users / beta testers and refined the usability throughout the years, but that does nothing for the discussion, simply because no one has seen what I have seen. My hope is that with your suggestions we can refine VS's usability even more to create an even better usability / protection balance.
When it comes to endpoint protection, there are only a few options, and each has a valid use case.
1. Do not lock the endpoint at all and only rely on detection
2. Lock the computer full time
3. Lock the computer when it is at risk with VS
If there is another option I am missing that we can implement into VS, I would love to discuss the possibilities.
Thank you guys, have a great weekend, talk to you soon!
