Hello All,

We had an incident yesterday where the scheduled virus scan (using the latest antivirus definition) removed a custom dll associated with an application. Apart from affecting a few hundred users[:@], who had to re-install their application, we also created an exemption in the antivirus real time scan to exempt the dll until the next definition was released.

I was wondering if there is a recommended way to prevent this happening with future packages (it wasn't one of ours, but it could have been). The dll in question is dwspy36.dll; which has had some issues with it's name before. Can we protect certain dll's etc from being replaced with spyware, or as in this case removed by a 'false' positive[8D].
Any thoughts, recommendations, greatly appreciated.

Cheers
Wayne
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
You can lock down files from the Virus scanner if you really want to but that might just create another bad situation if a bad dll gets placed on the machine in a secured location. I'd be more inclined to beat on the AV vendor for putting out a bad signature.
Answered 02/09/2006 by: kkaminsk
Ninth Degree Black Belt

Please log in to comment
0
Thanks kkaminsk,

Yeh, we got onto them pretty smart, but the damage was already done. As mentioned the dwspy36.dll (and dwspy5.dll) has had issues associated with it ,since spyware became a major headache in enterprise networks.
Is there a case for us, as network support, to request the application vendor to look at repackaging/redesigning their application to not include 'sus' named files that give false positives like this? The said file was also installed in the system32 directory, I believe this should be changed.

I appreciate your feedback, thanks.

Wayne
Answered 02/09/2006 by: WayneB
Blue Belt

Please log in to comment
Answer this question or Comment on this question for clarity