Is any one else seing this alert - Shh/Updater-B False positives

Very concisely put, Jak

@apeeler (and TWIMC): Probably the first time you've got hit by a FP. As Jak said, the outcome depended on the settings you use - and with the recommended settings there wasn't a real problem at all except for the cluttered QMs (and if your users don't have special rights this too is almost irrelevant).

It's all about probabilities. As long as you don't identify a file byte by byte there's always the risk of mistaking it for another. Assuming you do you'd have to have a complete collection of all malware, present and future, in order to catch polymorphs and their like. Now that's not only improbable, it's impossible as there is not enough storage available in the whole universe. Doing it the other way round (identifying clean files) also won't work - this time in addition because only for small and simple ones you can determine with absolute certainty that they are clean. Again you'd have to have copies of all these available in advance.  

Thus you (i.e. an AV writer) have to deal with probabilities and the risk of false positives and (don't forget) false negatives. Ignoring the latter for the moment, from the above it should be obvious that even forgoing "heuristic" scanning and other generic methods but instead relying on "signatures" only won't eliminate FPs. The only way to avoid them is completely abstaining from scanning (for the price of 100% false negatives of course).

Vendors have to find a balance in both their products and (business) processes, trying to minimize the risk without making their product pointless. As with all tools there's some residual risk for the user and usually the customers have also some options available to adjust their risk according to their environment.

Using aggressive, non-recommended settings one must be aware of the consequences. One could argue that there shouldn't be any Move and Delete options - nevertheless it's somewhat absurd to claim you didn't tell me that delete actually means delete. The out-of.-the-box settings weren't harmful and you weren't required to change them (in fact, the recommendation is to leave them as they are).

The following will rub some the wrong way - no insult intended though

Apart from this - AV is not the only source for disasters (and not even the most common). You are skating on thin ice anyway if you don't have the means and/or procedures to deal with site-wide problems. AFAIK even Delete did not bring machines down or corrupt the OS, made them unmanageable or cut off communication. You may call it a disaster, but among them it's a midget at best. Instead of frantically searching for another supplier (you can always do this later) you should take the opportunity to assess your current setup and to identify potential shortcomings - be it in staff, equipment or processes. The next disaster could be a real one.

Again - this is not meant to offend anyone

Christian

Very concisely put, Jak

@apeeler (and TWIMC): Probably the first time you've got hit by a FP. As Jak said, the outcome depended on the settings you use - and with the recommended settings there wasn't a real problem at all except for the cluttered QMs (and if your users don't have special rights this too is almost irrelevant).

It's all about probabilities. As long as you don't identify a file byte by byte there's always the risk of mistaking it for another. Assuming you do you'd have to have a complete collection of all malware, present and future, in order to catch polymorphs and their like. Now that's not only improbable, it's impossible as there is not enough storage available in the whole universe. Doing it the other way round (identifying clean files) also won't work - this time in addition because only for small and simple ones you can determine with absolute certainty that they are clean. Again you'd have to have copies of all these available in advance.  

Thus you (i.e. an AV writer) have to deal with probabilities and the risk of false positives and (don't forget) false negatives. Ignoring the latter for the moment, from the above it should be obvious that even forgoing "heuristic" scanning and other generic methods but instead relying on "signatures" only won't eliminate FPs. The only way to avoid them is completely abstaining from scanning (for the price of 100% false negatives of course).

Vendors have to find a balance in both their products and (business) processes, trying to minimize the risk without making their product pointless. As with all tools there's some residual risk for the user and usually the customers have also some options available to adjust their risk according to their environment.

Using aggressive, non-recommended settings one must be aware of the consequences. One could argue that there shouldn't be any Move and Delete options - nevertheless it's somewhat absurd to claim you didn't tell me that delete actually means delete. The out-of.-the-box settings weren't harmful and you weren't required to change them (in fact, the recommendation is to leave them as they are).

The following will rub some the wrong way - no insult intended though

Apart from this - AV is not the only source for disasters (and not even the most common). You are skating on thin ice anyway if you don't have the means and/or procedures to deal with site-wide problems. AFAIK even Delete did not bring machines down or corrupt the OS, made them unmanageable or cut off communication. You may call it a disaster, but among them it's a midget at best. Instead of frantically searching for another supplier (you can always do this later) you should take the opportunity to assess your current setup and to identify potential shortcomings - be it in staff, equipment or processes. The next disaster could be a real one.

Again - this is not meant to offend anyone

Christian